[15:29] <lotuspsychje> tjaalton: could you take a look at bug #1958191 when you have time, its an older bug that occured on bionic, skipped focal and now reviving on jammy devel since 5.15
[15:30] <lotuspsychje> today i found a second volunteer reporting flickering aswell on a dell/kubuntu/jammy on 5.15 -18 and tested that cstate param to improve the flickering
[15:33] <lotuspsychje> the dell is also an intel 620
[15:33] <tjaalton> lotuspsychje: try booting with i915.enable_psr=0
[15:33] <lotuspsychje> ok
[15:40] <lotuspsychje> no dice tjaalton
[15:44] <tjaalton> try latest mainline 5.15.x
[15:45] <lotuspsychje> ok
[15:45] <tjaalton> I don't have a silver bullet, so basically you need to do the easy bisecting first with mainline builds and if those won't help, file it upstream
[15:46] <lotuspsychje> kk
[15:46] <tjaalton> -17 is a month old now
[15:46] <lotuspsychje> tnx for the advice


[00:16] <xnox> are diffs in the merge proposals update themselves?
[00:16] <xnox> on the web that is
[00:16] <geser> IIRC yes
[00:26] <xnox> geser: force reloaded page and now it updated ;-)
[01:27] <Noldorin> hi. is launchpad bzr down atm?
[01:38] <Noldorin> hmm, seemso
[01:46] <ovnicraft> hi folk, how i can fork a project from launchpad i see add branch button but it create and empty branch
[01:47] <xnox> well easier is to do it with bzr
[01:47] <xnox> bzr branch lp:project
[01:48] <xnox> bzr push lp:~my-id/project/my-fork
[01:48] <xnox> the tip of lp:project and my-fork will be the same
[01:48] <xnox> alternativly if you like your branch you create with web
[01:49] <xnox> just push to it
[01:49] <xnox> bzr push lp:~my-id/project/branch-name-created-online
[01:49] <xnox> and voila ovnicraft has a fork of a project
[01:51] <ovnicraft> xnox, i was thinking in use lp for a personal project i am use bitbucket now, but with this i am going to forget it :) thx
[01:51] <xnox> why
[01:51] <xnox> you can push branches to launchpad without a project created
[01:51] <xnox> or if you want bugtracker and stuff than just create a project
[01:52] <xnox> ovnicraft: what do you actually want to achieve?
[01:52] <ovnicraft> with bitbucket i just click in fork button and him does everything
[01:52] <Noldorin> hi. is launchpad bzr down atm?
[01:55] <xnox> ovnicraft: well launchpad is different for one it doesn't use hg as backend so such analogy is not possible. You can't fork *all* branches of a project
[01:55] <ovnicraft> xnox, btw thx
[01:55] <xnox> ovnicraft: your welcome
[04:12] <maxb> The fork button in bitbucket is just a workaround for hg's lack of stacked branches, AIUI
[04:14]  * wgrant finds such a fork button to be a far worse UI than just pushing a new branch...
[04:14] <wgrant> But GitHub does it too.
[04:20] <maxb> considerable timesaver to re-uploading a lot of history, though
[04:23] <wgrant> maxb: Yes, but if you have to do that then your VCS or configuration sucks.
[04:24] <stgraber> you can use bzr branch with two remote branches though, not sure if it gets everything locally and then re-upload to the new branch when it's the same server
[04:52] <spiv> stgraber: in the case of launchpad it will download and upload more than is strictly necessary, but *far* from the whole history.
[04:53] <spiv> stgraber: that is, there's no particular smarts to do the branch operation entirely server-side, but because of automatic branch stacking that doesn't really matter.
[04:55] <stgraber> well, anyway, even if you do the branching server-side, you still need to get it on your machine at some point. Only real benefit from it would be using download bandwidth instead of upload bandwidth which for regular users would usually mean faster branching.
[05:00] <spiv> stgraber: right.
[07:00] <crimsun> is soyuz processing uploads?
[07:01] <crimsun> ..yes. Appears to be some lag.
[11:41] <geser> is the build dispatcher broken? as the build queues are filling but the buildds being idle (https://edge.launchpad.net/builders/)
[11:45] <geser> and the ones that are claiming to be building something, are building packages which finished two weeks ago (wth?) (https://edge.launchpad.net/~pgquiles/+archive/ppa/+build/1401930)
[12:32] <Cerveja> Hi, who is the current help contact
[12:55] <maxb> Yikes, the build farm is totally broken :-(
[12:56] <maxb> Chances of finding a LOSA on New Year's Day seem slim
[12:58] <maxb> For the record, all of these appear stuck: hassium iridium samarium bohrium osmium promethium mercury nobelium
[13:00] <wgrant> Arrrrgh.
[13:00] <wgrant> It's build #1226841 again.
[13:00] <wgrant> I thought that was fixed.
[13:00] <wgrant> At least twice.
[13:01] <rdb> is there something wrong with soyuz?
[13:01] <maxb> yes
[13:01] <rdb> aw, darn
[13:01] <rdb> got any specifics?
[13:02] <maxb> Not really, other than it seems to have got totally stuck and we need an admin to fix it.
[13:02] <geser> does this build also block that other builds get dispatched?
[13:03] <wgrant> geser: Yes.
[13:03] <wgrant> There are at least a couple of insane builds building.
[13:03] <wgrant> Probably more.
[13:03] <elmo> it's the duplicate build record thing
[13:03] <elmo> I've just run the SQL to clear it
[13:05] <rdb> great!
[13:05] <maxb> Good thing most people will be holidaying not uploading for a bit... give the queues time to ease :-)
[13:08] <elmo> it's only been broken for 8 hours; with all the builders available, it shouldn't take long at all for that queue to clear
[13:08] <maxb> elmo: Should we be concerned that hassium has gone right back to building the problem build?
[13:09] <elmo> maxb: I don't think so no?  what is the problem build from your point of view?
[13:09] <maxb> oh, sorry, browser cache fail
[13:09] <maxb> or perhaps launchpad cache fail
[13:11] <wgrant> maxb: While I often see three different versions of /builders by repeatedly refreshing, I'm pretty sure hassium is really building that build now.
[13:11] <maxb> The seven other buildds that I mentioned above still look stuck, though
[13:11] <wgrant> (bug #499095, that one is. there are several others)
[13:12] <elmo> blink
[13:13] <elmo> god damn it, I despise the build manager
[13:13] <wgrant> elmo: What's it doing now?
[13:13] <wgrant> (I think everyone hates it)
[13:13] <elmo> wgrant: https://launchpad.net/builders/mercury
[13:13] <elmo> (and the others maxb pointed out)
[13:13] <elmo> I can re-PPA-ize most of them, but some of these are permanent builders
[13:14] <maxb> Also, /builders/hassium claims to be idle whilst /ubuntu/+archive/test-rebuild-20090909/+build/1226841 claims to be currently building on hassium :-)
[13:14] <wgrant> The data model changes seem to have basically caused everything to explode in ways that should really be rejected by the database constraints.
[13:15] <wgrant> elmo: By 're-PPA-ize' you mean reset the VM? I'm not sure that'll help much, for some of them.
[13:16] <elmo> wgrant: it's a little more dramatic than that, it's a complete reinstall of the machine to a known good state.  which is massive overkill, but it's trivial and invokes the right magic to (usually) make LP "forget" whatever the heck it thinks it was building
[13:17] <elmo> (basically I pretend to be Marc Tardif and claim I'm taking the machine to do enablement work on it - and then immediately give it back again)
[13:18] <elmo> I'll try it on hassium first in any event
[13:18] <wgrant> elmo: Have you read the bug about that build?
[13:19] <elmo> oh, err, no
[13:19] <wgrant> That one has been problematic a number of times already, and there is SQL there to fix it... although it seems to like unfixing itself.
[13:20] <wgrant> Oh, hm, maybe it wasn't ever actually properly fixed after last time.
[13:20] <elmo> AAAA
[13:20] <elmo> there's 6 of them now
[13:20] <wgrant> Of what?
[13:21] <elmo> if I run the SQL to detect them from the bug, I see 6 build record ids, not 1
[13:21] <wgrant> Also, that build OOPSes consistently for me now. It didn't 20 minutes ago.
[13:21] <wgrant> elmo: Ew.
[13:21] <elmo> http://paste.ubuntu.com/349929/
[13:22] <elmo> wgrant: what were the changes to the data model for?
[13:22] <geser> is there a reason why the official lpia buildds sit idle with 9 jobs in the queue while the other official buildds get new jobs dispatched?
[13:23] <wgrant> geser: Yes.
[13:23] <wgrant> geser: Those are lucid builds that have yet to be destroyed.
[13:24] <wgrant> They will not be dispatched, since the chroot has been removed.
[13:24] <wgrant> They must have been waiting to build at the moment the chroot was removed, so they are stuck until somebody removes the DAS or kills them manually.
[13:24] <wgrant> So there's nothing going wrong here.
[13:24] <geser> ok
[13:26] <wgrant> elmo: Sorry, missed the question. buildd generalisation.
[13:26] <elmo> gack
[13:26] <wgrant> elmo: Parts of (currently Soyuz-only, but this will change in a week) buildqueue table were split out into the (previously Code-only) job table.
[13:28] <wgrant> The interactions between them all now seem to be... imperfect.
[13:31] <Noldorin> hi
[13:31] <Noldorin> i'm getting the following error when i try to push to LP
[13:31] <Noldorin> Permission denied (publickey).
[13:31] <Noldorin> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectiv
[13:31] <Noldorin> ity and permissions, and report a bug if problems persist.
[13:31] <Noldorin> no idea why this is occurring though :S
[13:31] <wgrant> Noldorin: You do not have the appropriate SSH key set up.
[13:32] <Noldorin> wgrant: strange thing is, it always worked before i upgraded to bzr 2.0
[13:32] <wgrant> Noldorin: You need to have an SSH key on your machine associated with your Launchpad account.
[13:32] <Noldorin> any suggestions? i'm running windows 7 btw
[13:32] <Noldorin> wgrant: i have it configured through pageant
[13:32] <wgrant> Ah. You might find more help in #bzr. This is not a Launchpad-specific problem.
[13:32] <Noldorin> and i've checked its the same key that's online
[13:33] <Noldorin> hmm ok
[13:33] <Noldorin> not having problems pushing anywhere else though, oddlyt
[13:33] <wgrant> You're using bzr+ssh to other servers?
[13:34] <fta> hi, happy new year everyone!
[13:34] <Noldorin> no... i see your point
[13:34] <fta> any losa around? https://answers.edge.launchpad.net/launchpad/+question/93418
[13:35] <Noldorin> wgrant: only reason i think this might be LP-related is that launchpad is meant to store my SSH key, but doesn't seem to be doing so correctly.
[13:35] <Noldorin> https://launchpad.net/~noldorin
[13:35]  * maxb chuckles at "Disabled for Enablement"
[13:35] <wgrant> Noldorin: I see a key configured there. What suggests that it is not stored correctly?
[13:36] <Noldorin> wgrant: the fact that launchpad isn't recognising it?
[13:36] <Noldorin> of course, it could just as well be a problem with pageant
[13:36] <wgrant> I suspect that you have not configured Pageant properly.
[13:36] <wgrant> I do not know how SSH keys work on Windows, however.
[13:37] <Noldorin> wgrant: does it need any special config for bzr 2.0?
[13:37] <Noldorin> always worked for bzr 1.x hmm
[13:37] <elmo> so hassium is now building something else
[13:38] <elmo> I'm going to assume I can't make anything work by throwing the others back through the airlock process
[13:38] <elmo> err
[13:38] <elmo> anything WORSE
[13:38] <wgrant> Noldorin: I do not know.
[13:39] <wgrant> elmo: Worth a try.
[13:39] <Noldorin> wgrant: ok, thanks anyway
[13:39] <Noldorin> i'll try #bzr
[15:23] <maxb> Looks like all but samarium and promethium are back in business now
[15:23] <elmo> yeah, I can't reset those through the webui (awesome), I'll do the SQL by hand in a bit
[15:33] <fta> anyone to boost a quota? please :)
[16:12] <RenatoSilva> Happy new Year!
[17:06] <Ekushey-> I can't find the button to report new bug on LP... what's wrong with me?
[17:12] <crimsun> Report a bug. trailing vertical side
[17:22] <Ekushey-> thanks
[18:05] <njn> Hi, is there a help contact around
[18:05] <lfaraone> Can sonebody restart https://code.edge.launchpad.net/~vcs-imports/rainbow-olpc/mstone-trunk-new for me?
[18:09] <RenatoSilva> translation licensing docs are confusing
[18:11] <njn> Do answers get automatically solved if there are no further comments by the author in a certain time period?
[18:12] <njn> It gets fiddly having to keep checking on an answer that I provided, marked as 'Answered', and there has been no further comments by the author, so surely it should be 'Solved'?
[18:15] <darthanubis> I can't file a bug
[18:16] <njn> darthanubis: What bug
[18:16] <darthanubis> bug for mythbuntu
[18:16] <darthanubis> I keep getting the oops page
[18:17] <darthanubis> (Error ID: OOPS-1462C1577)
[18:18] <darthanubis> I've tried over the past 5hrs to no avail
[18:23] <njn> darthanubis: Done. #502129
[18:23] <darthanubis> thank you
[18:24] <njn> darthanubis: Is that your lp username?
[18:24] <darthanubis> yes
[18:25] <njn> darthanubis: I've subscribed you too that bug
[18:25] <darthanubis> ty
[18:31] <njn> Does anyone know how often Karma gets updated on a user profile?
[18:31] <micahg> njn: should be daily again
[18:31] <njn> micahg: Ah, ok. So just once a day?
[18:32] <micahg> njn: yep
[18:32] <njn> micahg: Thanks
[21:58] <crimsun> hmm
[21:59] <crimsun> has there been a change in the cronned acceptance of source packages?
[21:59] <crimsun> it used to be every five minutes
[21:59] <crimsun> (this is to Ubuntu proper)
[22:02]  * xnox was under impression it's every 20mins
[22:09] <crimsun> that would be a change from the previous
[22:09] <crimsun> and it would have changed fairly recently in my recollection, i.e., within the last couple weeks
[22:13] <geser> if my memory serves me right then the 20 min is the time between PPA publisher runs and the upload queue is still processed every 5 min
[22:14] <geser> (of course if nothing broke, you know it's vacation time and services find it a good time to break)
[22:16] <crimsun> I've managed to upload at :49 for one and at :54 for two source packages now, and each one hasn't been processed until :00
[22:16] <geser> hmm
[22:17] <crimsun> builds are also quite delayed, it seems
[22:18] <geser> the build dispatcher broke this night, but it got fixed already
[22:23] <geser> crimsun: I've looked at my archived accepted mails for my uploads and the time between the timestamp in the signature and the date header in the accepted mail was max 5 min (sample size: 3)
[22:24] <geser> all mails had a date header a few seconds past a mutiple of 5 min
[22:37] <maxb> I believe the upload-processor and publisher were running */5 last time I heard
[22:37] <wgrant> That is indeed the case.
[22:38] <wgrant> Well, the intention.
[22:38] <maxb> Come to think of it, is there any good reason why the upload processor isn't triggered by orderly shutdown of an FTP connection?
[22:39] <wgrant> poppy sucks.
[22:41] <wgrant> poppy should eventually be replaced by some SFTP server that automatically processes the upload and immediately returns a success or failure message across the existing connection.
[22:44] <maxb> Does SFTP allow that sort of feedback?
[22:49] <Noldorin> hello
[22:49] <Noldorin> does launchpad have git-serve installed currently?
[22:49] <wgrant> maxb: We should be able to just send it over stderr.
[22:49] <wgrant> Noldorin: No.
[22:49] <Noldorin> wgrant: rubbish. so ma i out of luck when it comes to mirroring on github?
[22:50] <Noldorin> am i*
[22:50] <wgrant> maxb: There might be some better method of sending arbitrary text, but I haven't read the spec enough to find out.
[22:50] <wgrant> Noldorin: Launchpad can mirror from a git repository, but it only exposes bzr branches.
[22:51] <Noldorin> wgrant: so no luck mirroring a bzr branch that exists on Launchpad on github?
[22:54] <wgrant> Noldorin: I don't know what GitHub supports.
[22:54] <wgrant> That would seem to be more of a GitHub issue.
[22:54] <Noldorin> wgrant: fair enough. i'm asking the git guys too..
[22:54] <Noldorin> thanks anyway
[22:55] <Noldorin> wgrant: hmm. would i have any better luck with SVN? i mean, is bzr-svn installed ont the LP servers?
[22:55] <wgrant> Noldorin: Again, from svn, but not to svn.
[22:56] <Noldorin> heh i see...
[22:56] <wgrant> Pushing to svn would require that LP have credentials for every user, which seems ridiculous.
[22:56] <Noldorin> wgrant: can bzr/launchpad mirror *to* anythiung then?
[22:56] <Noldorin> that's true...
[22:56] <Noldorin> guess i haven't thought it through thoroughly
[22:56] <wgrant> No, it cannot.
[22:58] <wgrant> Noldorin: Well, you can use bzr to push to svn or git, but Launchpad will not do it for you.
[23:01] <Noldorin> wgrant: oh, i see. that might be the least evil solution then.
[23:02] <Noldorin> wgrant: so i could in theory do something like "bzr push-git ...." (i have no idea of the actual syntax) after each commit/push to LP to keep my branches in sync?
[23:04] <wgrant> Noldorin: 'bzr dpush' for git, I think, but I'm not entirely sure.
[23:04] <wgrant> You can work just like normal on a bound svn branch. I'm not sure about git.
[23:04] <Noldorin> excellent - well, i'll take a look into it myself now
[23:04] <Noldorin> right
[23:05] <Noldorin> i need the bzr-git plugin, or does that come with the default windows distribution?
[23:05] <wgrant> You'll probably need to install the plugin, but I do not know what the Windows distribution includes.
[23:05] <Noldorin> right ho
[23:05] <Noldorin> wgrant: thanks for the help :) will report back if there are any major probs.


[07:39] <didrocks> Trevinho: hey, around?
[08:06] <didrocks> popey: hey! once you are around, some more free karma:
[08:06] <didrocks> https://code.launchpad.net/~didrocks/dbus-test-runner/bootstrap/+merge/142258
[08:06] <didrocks> https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256
[08:16] <popey> morning didrocks
[08:17] <didrocks> hey popey! how is the weather in uk?
[08:18] <popey> Grey. As always. ☺
[08:20] <didrocks> I share the same sky today! :)
[08:20] <didrocks> what have you done to Lyon? You have broken my weather! :-)
[08:41] <didrocks> thanks popey ;)
[08:41]  * didrocks adds 2 to the list of bootstrapped projects now
[08:41] <popey> np
[08:43] <didrocks> seb128: popey: do you use standard icon size for unity?
[08:43] <didrocks> or reduced one?
[08:43] <popey> depends which way the wind is blowing
[08:43] <popey> and which machine
[08:43] <didrocks> :)
[08:44] <seb128> didrocks, standard
[08:44] <popey> reduced on laptop, not on desktop
[08:44] <didrocks> seb128: when you press super, with the daily build ppa, you don't see any empty space between the launcher and the dash?
[08:44] <seb128> didrocks, btw ppa from yesterday works fine on my laptop, no issue so far ... should I try tweaking the launcher settings?
[08:44]  * popey tries
[08:44] <didrocks> popey: you do use the daily build ppa, right?
[08:45] <popey> on my desktop, yeah
[08:45]  * popey boots it
[08:45] <didrocks> seb128: well, I can reproduce it right away ;)
[08:45] <didrocks> I see that: http://people.canonical.com/~didrocks/tmp/space_in_unity.png
[08:46] <seb128> didrocks, I don't see it with the default icon size but I confirm when playing with the slider to change the setting
[08:46] <seb128> it does it for some values
[08:46] <didrocks> ok, let me open a bug :)
[08:46] <didrocks> I see as well a bigger size at initialization for half a second
[08:47] <seb128> k
[08:49] <didrocks> seb128: mterry mentionned to me to have a super key which seems wonkey for him, I can't reproduce though
[08:49] <didrocks> like some super press doesn't seem to be acked by the system
[08:49] <didrocks> popey: if you can try to see if you reproduce this one ^
[08:50] <didrocks> seb128: also, if you want to confirm https://bugs.launchpad.net/unity/+bug/1097184
[08:51] <popey> didrocks: i can't reproduce a gap between launcher and dash, with any size dash
[08:51] <popey> s/dash/launcher/ ☺
[08:52] <sil2100> Oh, I have the same issue
[08:52] <popey> i did manage to catch it once as it shrunk while the dash was open
[08:52] <sil2100> With the Super key
[08:52] <didrocks> sil2100: ah, please file a bug, not sure if you have the time to investigate, nice to know you are not alone :)
[08:52] <sil2100> Not sure what happened, but since some update in staging sometimes I have to wank Super key more than once to get it working now
[08:52] <popey> hmm, not got latest unity from the ppa.. that'll be why
[08:52] <didrocks> popey: interesting… maybe try to set it to 32 and restart unity
[08:52] <didrocks> popey: ahhhh :)
[08:53] <didrocks> popey: yeah, that's it! :)
[08:53] <didrocks> sil2100: please signal that as soon as you catch it
[08:53] <popey> i dist-upgraded, still showing archive version...
[08:53] <popey> hmmm
[08:53] <didrocks> sil2100: it's easier then to find where the regression comes from :)
[08:53] <didrocks> popey: do you really have the daily-build ppa?
[08:54] <seb128> didrocks, I had some issues opening the dash with super as well
[08:54]  * popey stabs ppa-purge and add-apt-repository
[08:54] <popey> ppa-purge adds a # in .list files, add-apt-repository doesn't notice this
[08:54] <popey> so blindly says "okay, added repo" but actually doesn't uncomment the list file
[08:54] <seb128> didrocks, it seems like if you act fat-finger and stay a bit too long on the key the tap doesn't work
[08:55] <seb128> didrocks, not sure if that's new I tend to use the mouse rather than the keyboard to go to the dash
[08:55] <didrocks> seb128: ah, indeed, with fat-finger
[08:55] <didrocks> but the press was 250ms IIRC
[08:55] <didrocks> maybe the delay should be a little bit longer, not sure if it changed though, didn't see that in the merges
[08:56] <didrocks> sil2100: want to give it a shot? IIRC, it's a simple #define, you can try increment it
[08:56] <seb128> didrocks, well in "normal" tapping it seems to work fine in any case
[08:56] <didrocks> yeah, but slow tapping isn't triggered
[08:56] <didrocks> and I think in some case of testing, it should
[08:56] <didrocks> popey: interesting :)
[08:57] <popey> annoying!
[08:57] <didrocks> interestingly annoying? :)
[08:57] <popey> very
[08:58] <popey> didrocks: ok, i have a gap now ☺
[08:58] <popey> "thanks"
[08:58] <didrocks> popey: you can put a sticker on it, that's handy! :)
[08:58] <didrocks> ok, a small one :p
[08:58] <popey> and yes, it's losing super keypresses
[08:59] <didrocks> ok, so 2 noticed issues to be fixed before releasing to distro
[08:59] <didrocks> popey: seb128: do you mind if one of you open the bug for it?
[09:01] <popey> sure, will do
[09:01] <sil2100> didrocks: for fixing the Super key-press issue you mean?
[09:02] <didrocks> yep :)
[09:02] <sil2100> didrocks: will try, I'll dig and see if they actually changed something that could have caused it to (if the delay changed, or maybe the method how the delay is treated)
[09:03] <didrocks> sil2100: thanks! :)
[09:06] <popey> sil2100: bug 1097189
[09:07] <davidcalle> didrocks, hey. mhr3 told me you would prefer a branch per scope (and I know why), but do you know how to deal with automated translations in this case?
[09:08] <didrocks> davidcalle: I think we'll go on translation in the ubuntu package, or do you mean you want to activate the possibility to translate in the upstream project?
[09:08] <davidcalle> didrocks, oh right, forgot about this possibility. Fine for me then.
[09:09] <didrocks> because if you want to do that, it will be one launchpad project per scope, and it's not fun for you I guess :/
[09:09] <didrocks> davidcalle: yeah, so don't enable the translation in the ubuntu-scopes launchpad projects
[09:09] <didrocks> davidcalle: I think it's the easiest, I gave it another thought this week-end, that's why it changed since Friday ;)
[09:09] <didrocks> and when I thought about it again, I guess you were during your lunch break, not online! :-)
[09:10] <davidcalle> didrocks, no problem. ;-)
[09:17] <didrocks> hey mmrazik, can you give it a look? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 it succeeded in one arch, not the other one
[09:17] <didrocks> and the two pre-merging archs succeded
[09:17] <didrocks> succeedeed*
[09:18] <mmrazik> didrocks: looking at it but "xvfb-run: error: Xvfb failed to start" doesn't look very familiar
[09:21] <didrocks> mmrazik: seems a configuration issue not making it runnable as it ran on i386 before the commit phase and succeeded in http://jenkins.qa.ubuntu.com/job/dbusmenu-ci/./build=pbuilder,distribution=raring,flavor=i386/20/console
[09:22] <mmrazik> didrocks: don't understand
[09:22] <didrocks> mmrazik: well, this one PASSED, isn't it? it's the same arch
[09:22] <mmrazik> sure
[09:22] <mmrazik> but I just don't see why xvfb-run suddenly stopped working
[09:23] <mmrazik> not aware of any specific configuration for xvfb-run
[09:23] <didrocks> mmrazik: if the machine you run on/the configuration is different, maybe there is a different X server started?
[09:23] <didrocks> maybe just try otherwise rekicking it…
[09:23] <mmrazik> didrocks: yes please, try to re-approve
[09:24] <mmrazik> didrocks: the builder machine is shared so maybe some other test/build influenced the build
[09:24] <mmrazik> but in case of xvfb-run I would expect it doesn't really care
[09:24] <mmrazik> there is no X running on those builder machines
[09:25] <didrocks> weird…
[09:25] <didrocks> hey andyrock, how are you?
[09:26] <andyrock> didrocks, good what's up?
[09:26] <didrocks> andyrock: there is a regression in unity trunk, maybe you will know what happened: bug #1097184
[09:27] <didrocks> andyrock: do you think you can/have time to work on it? As told on the bug report, the first hint is that on startup, the launcher has the regular size for 0.5s
[09:28] <andyrock> didrocks, "the launcher has the regular size for 0.5s" it should not be the problem
[09:28] <didrocks> ok, so another bug? :)
[09:28] <andyrock> yup let me check DashController.cpp :)
[09:29] <didrocks> thanks! :)
[09:33] <duflu> didrocks, sil2100, popey: lp:unity 2970 made the timeout configurable and changed the default from 250 to 130ms. Change it back to 250 if you like :)
[09:33] <didrocks> yeah, I think this will be saner value, most of tapping are between 250 and 300ms (it's 300ms on android)
[09:33] <sil2100> I think 250ms was fine ;p
[09:34] <sil2100> duflu: thanks for the info!
[09:34]  * sil2100 prepares a merge request
[09:34] <duflu> didrocks: In independent tests by myself and Brandon we both concluded anything above 130 was "too long". But I don't mind...
[09:34] <duflu> didrocks: It's because Compiz reliable tap detection is turned off. If the Super timeout is 250 then it's too easy for Super+other_keys to trigger the dash
[09:35] <didrocks> duflu: any reason than compiz reliable tap detection to be turned off btw?
[09:35] <didrocks> sil2100: gimme gimme :)
[09:35] <duflu> didrocks: To fix: https://bugs.launchpad.net/bugs/950160
[09:36] <didrocks> and we don't have anymore issue with alt + something?
[09:36] <duflu> didrocks: It's not turned off for Alt. So not a problem :)
[09:36] <didrocks> ah ok :)
[09:45] <andyrock> didrocks, https://code.launchpad.net/~3v1n0/unity/launcher-options-single-emission
[09:45] <andyrock> didrocks, i think it's causing the regression
[09:46] <andyrock> fixing it
[09:46] <didrocks> andyrock: ah, nice that you spotted the cause, yeah, it seems to be linked
[09:46] <didrocks> andyrock: do you think that this position is testable?
[09:47] <andyrock> maybe with autopilot
[09:51] <didrocks> sil2100: so, now that I've been able to run against latest unity the indicator-unity tests, here are the results:
[09:51] <Mirv> added a note to the bug report about the side effect reported by smagoun that brandon is currently looking at
[09:51] <didrocks> sil2100: http://<IP_ADDRESS>:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-ati/testReport/
[09:51] <didrocks> sil2100: http://<IP_ADDRESS>:8080/job/ps-indicators-autopilot-release-testing/40/label=autopilot-nvidia/testReport/
[09:51] <didrocks> so 7/8 to fix still (-4 you really did fix, isn't it?)
[09:53] <sil2100> huh, still failures?
[09:53] <sil2100> Let me see that :/
[09:54] <sil2100> test_gedit_undo again?!
[09:54] <didrocks> seems :/
[09:54] <sil2100> This means war
[09:54] <didrocks> on both
[09:54] <didrocks> at least, the failing ones are common to both
[09:57] <sil2100> Ok, but now gedit_undo fails differently
[09:57] <sil2100> And a new failure
[09:58] <didrocks> ah, at least, what you have done had an impact :)
[09:59] <didrocks> sil2100: not sure how your load is, but maybe just finish the tap thing so that it's merged, then, I'll approve it and you can go on the failures?
[10:03] <sil2100> didrocks: the tap thing is submitted for review, so I will look into those failures
[10:03] <sil2100> (actually am now)
[10:03] <didrocks> sil2100: jumping on your MP! :-)
[10:03] <didrocks> sil2100: thanks ;)
[10:03] <sil2100> https://code.launchpad.net/~sil2100/unity/unity_dash_tap_duration/+merge/142273
[10:03] <didrocks> if only that was giving ingress points :)
[10:04] <didrocks> sil2100: oh, yo udidn't link it to the bug report
[10:04] <didrocks> let me do it
[10:04] <sil2100> The undo and the one new failure I can try fixing, but the next/prev ones are really mystical - I thought that introducing a wait for the started application will help, but in the end it didn't
[10:04] <sil2100> But I'll try looking a bit deeper
[10:04] <sil2100> oh, sorry about that ;)
[10:05] <didrocks> the 4 test_dash_hud is the one you fix and need another review, right?
[10:05] <didrocks> maybe after the gedit_undo, you can try unity.tests.test_hud.HudBehaviorTests.test_closes_then_focuses_window_on_mouse_down before the next/prev black magic :)
[10:37] <andyrock> didrocks, that was the problem. it's fixed now
[10:37] <andyrock> need to write an ap test
[10:37] <didrocks> andyrock: you rock! :-)
[10:38] <andyrock> ;)
[11:06] <didrocks> mmrazik: is this one stalled? https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256
[11:06] <mmrazik> didrocks: I just received an e-mail about that
[11:06] <didrocks> ah? good timing then :)
[11:37] <didrocks> mmrazik: we disable the autopilot job as jibel is trying to make the intel box working with raring
[11:37] <mmrazik> didrocks: ok
[11:38] <didrocks> and then, once we have the daily build running, this will enable us to kill the staging ppa and this job :)
[11:38] <mmrazik> didrocks: mhm. the dbusmenu job still failing :-/
[11:38] <didrocks> mmrazik: urgh, I can't reproduce it here, with a pbuilder, everything is working
[11:39] <mmrazik> randomly, as now it failed on differen builder host (the same where it passed previously) and different arch
[12:45] <didrocks> sil2100: any progress btw? :)
[13:20] <petko10> hey guys , I have a question about developing for the Ubuntu phone OS - the native language is QML/Qt5/C++ right ?
[13:22] <larsu> petko10, yes: http://developer.ubuntu.com/get-started/gomobile/
[13:27] <petko10> ok ,nice (I asked , because , though i read most of the info on the gomobile, I didn't see any C++ code , but it's not hard to figure that qt=c++ as I think of it)
[13:38] <sil2100> didrocks: yes, but now a short break for preparing lunch
[16:27] <didrocks> mterry: hey! I think you saw that your regression you found was a real one :)
[16:27] <mterry> didrocks, yeah, looks like it got fixed already
[16:28] <didrocks> mterry: yeah, I pinged and harassed people
[16:28] <didrocks> mterry: how full is our plate? do you have time for indicators and unity tests issues?
[16:29] <mterry> didrocks, mmm, I've got stuff.  I can take some of it off your plate...
[16:29] <didrocks> mterry: yeah, there are basically 2 kinds of thing, and they are quite urgent to have daily unity release
[16:29] <mterry> didrocks, OK
[16:30] <didrocks> mterry: first one is about bootstrapping dbusmenu and libappindicator
[16:30] <didrocks> dbusmenu still has a test stability issue when merging
[16:30] <didrocks> see https://code.launchpad.net/~didrocks/libdbusmenu/bootstrap/+merge/142256 for instance
[16:30] <didrocks> so if you can give it a look, why it's failing on some archs…
[16:32] <didrocks> the second is libappindicator, which needs bootstrapping and test passing during build, see it with cyphermox about where he stops
[16:32] <didrocks> lp:~mathieu-tl/+junk/libappindicator for some debug infos
[16:33] <didrocks> the second issue is what sil2100 is working on
[16:33] <cyphermox> well, that's basically where I'm at
[16:33] <cyphermox> didrocks: seems to me like dbusmenu is failing because the script run-xfvb.sh is probably very broken in some way
[16:33] <sil2100> o/
[16:34] <cyphermox> mterry: libappindicator: i'm trying to figure out what might be different between the gtk2 tests and gtk3 tests that would explain why the gtk3 tests reproducibly fail while the gtk2 tests pass
[16:34] <didrocks> mterry: if you have knowledge about that, that would be great ^
[16:35] <didrocks> mterry: second things is about indicator autopilot tests
[16:36] <didrocks> mterry: we need to fix them all to be able to start releasing daily unity
[16:36] <didrocks> the list is at jenkins-qa/job/ps-indicators-autopilot-release-testing/
[16:36] <didrocks> you can see the 3 archs
[16:37] <mterry> didrocks,  https://jenkins.qa.ubuntu.com/view/PS/job/ps-indicators-autopilot-release-testing/
[16:37] <mterry> oh
[16:37] <mterry> OK, cool
[16:37] <didrocks> we have 10/7/10 failures
[16:37] <mterry> Was about to ask if that was right url
[16:37] <didrocks> yeah, this is the public mirroring :)
[16:37] <didrocks> so sil2100 has a regression fix for 4 of them
[16:37] <didrocks> so normally this would be 6/3/6 remaining
[16:38] <didrocks> can you please coordinate with sil2100 and bregma (who will put brandon on line) to get that to 0?
[16:38] <didrocks> this can be either tests not stable
[16:38] <mterry> OK
[16:38] <didrocks> or real issues
[16:38] <didrocks> mterry: sil2100 can help you to run autopilot
[16:40] <sil2100> I see that some issues are still AP typical issues
[16:45] <mterry> sil2100, is there a wiki for getting myself able to run the indicator autopilot tests?
[16:51] <sil2100> mterry: a wiki? hm, not really, sadly...
[16:54]  * mterry goes on lunch+errands, but will come back.  sil2100, if you could leave some notes on running autopilot, unless it's literally as simple as running autopilot inside the indicator source somewhere
[17:02] <sil2100> mterry: I'll send you an e-mail if that's fine with you?
[17:03] <didrocks> sil2100: mterry is in the US, so if you can do that before going EOD, it would be awesome :)
[17:17] <bschaefer> sil2100, mterry hey, I hear you guys are work on fixing the AP tests?
[17:18] <sil2100> Yes, some failures regarding the indicators mostly
[17:18] <bschaefer> sil2100, well I was going to join in, and wanted to make sure I didn't step on anyones toes :)
[17:20] <sil2100> bschaefer: some of the failing tests, for instance, are due to AP not waiting for the application to get focus
[17:20] <sil2100> (at least that's how it looks like it)
[17:20] <bschaefer> sil2100, o dang...thomi had a nice ap-view branch that made a list of all the failing AP tests along with the video
[17:21] <bschaefer> though the video isn't that hard to get from jenkins
[17:21] <bschaefer> sil2100, this is the list your working through right? http://paste.ubuntu.com/1510013/
[17:21] <sil2100> Yes, I'm using it all the time ;)
[17:21] <sil2100> apview.html banzai!
[17:21] <bschaefer> :)
[17:21] <bschaefer> yup!
[17:22] <sil2100> bschaefer: yes, more or less - there are even some more, since the latest indicator ap results have more test failed
[17:23] <bschaefer> alright, ill keep checking jeninks for more.
[17:23] <bschaefer> sil2100, I think i've noticed a bug in unity though....when you do a 'unity' and something is striping focus off the windows in the first say 60 seconds
[17:24] <bschaefer> though i wasn't sure if it was something I was doing :)
[17:24] <bschaefer> which could explain the AP tests losing focus of an application (since its a fresh reboot)
[17:24] <sil2100> oh!
[17:25] <sil2100> That would, hm, really answer the question of why gedit_undo failed last time
[17:25] <sil2100> hm
[17:25] <bschaefer> yeah... i was going to dig into it after I got over a bunch of other work I was doing
[17:26] <bschaefer> im thinking it could be the switcher, but it would be nice to have someone else confirm it :)
[17:26] <sil2100> Never noticed it though - you say it happens after start of unity?
[17:26] <bschaefer> yeah
[17:26] <sil2100> I'll try on a guest session now
[17:26] <bschaefer> as I have been restarting unity a bunch now
[17:26] <bschaefer> sil2100, well a compiz --replace
[17:28]  * bschaefer goes to add debuging statment to nux event loop
[17:35] <sil2100> Holy shat, you're right
[17:36] <bschaefer> well dam...I should have filed a bug about it
[17:36] <bschaefer> well either way, Ill work on fixing that
[17:36] <sil2100> After like 20-25 seconds suddenly all apps loose focus
[17:36] <bschaefer> yeah, its strange, ill see what window is doing this in the nux event loop...ill see shortly!
[17:38] <sil2100> bschaefer: should I fill a bug?
[17:38] <bschaefer> sil2100, sure, and assign it to me :)
[17:39]  * bschaefer hopes this is the cause of the problems in the AP tests
[17:42] <sil2100> This would make sense, since I tried fixing the issues by adding an assertion of window focus, but it didn't help - and it also answers the question why I was unable to reproduce it here
[17:42] <sil2100> I only once reproduced one of the problems, and I think it might have been right after unity --replace
[17:42] <bschaefer> sil2100, yeah, interesting, it looks like the switcher steals focus for some reason....
[17:42] <sil2100> I didn't notice it
[17:42] <sil2100> \o/
[17:43] <bschaefer> though let me double check
[17:43] <sil2100> bschaefer: anyway, great catch!
[17:43] <bschaefer> a bunch of events when through when it happened
[17:43] <bschaefer> thanks! You have no idea how annoying that bug was when trying to reset/compile/test/repeat haha
[17:44] <bschaefer> sil2100, definitely the switcher....
[17:45] <bschaefer> it sends a bunch of PropertyNotify events when it happens ... interesting ... time to go fix it
[17:48] <sil2100> bschaefer: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1097368
[17:48] <bschaefer> sil2100, thanks for filing that!
[17:49] <bschaefer> sil2100, sorry I hadnt yet, that could have saved you some time ...
[17:52] <sil2100> bschaefer: no problem, good that you spotted it even now ;)
[17:54] <bschaefer> yeah, hopefully the fix will be simple!
[18:09] <bschaefer> sil2100, interesting, the problem appears to be in SwitcherController::ContructWindow, view_window_->EnableInputWindow(true, "Switcher", false, false);
[18:09] <bschaefer> if you remove that line, everything works, as that chunk of code should be in ShowView (which it is)
[18:10] <bschaefer> the switcher window it self was being focus (but since its just an nux::XInputWindow really there is no title)
[18:12] <sil2100> bschaefer: does it need to steal focus?
[18:12] <sil2100> I mean, hm
[18:12] <bschaefer> sil2100, nope, it was happening when it was being created
[18:12] <bschaefer> as there is a bit of a delay when things get created unless you force it
[18:12] <bschaefer> like with the dash
[18:13] <sil2100> bschaefer: excellent, well, we don't want it doing that then ;p!
[18:13] <bschaefer> sil2100, it needs to take the focus when the switcher is started, but there is code in ShowView to do that, which it does :)
[18:13] <bschaefer> sil2100, sooo now to test this ... hmm
[18:13] <bschaefer> I don't want to have an AP test that is 30+ seconds long...for each arc
[18:13] <sil2100> Not sure if that's easy autopilot-testable...
[18:14] <bschaefer> yeha...
[18:14] <sil2100> Right, and besides it would require a clean unity start
[18:14] <bschaefer> plus having to do a compiz  --replace
[18:14] <bschaefer> yup
[18:14] <bschaefer> a unit test no...
[18:14] <sil2100> So maybe an unit test? I know they're not really meant for such things
[18:14] <bschaefer> i mean...
[18:14] <bschaefer> hmm...well we could fake creating a the switcher
[18:15] <bschaefer> which then we could possibly check the panel title
[18:15] <bschaefer> as it will be empty if it steals focus
[18:15] <sil2100> hoo, ok, that sounds nice
[18:15] <bschaefer> well im not sure if I have access to the panel in a unit test
[18:16] <bschaefer> but I think I can find something to check, I can dig into
[18:16] <sil2100> Since normally I would say 'let's not test it', but then we'll forget about this issue and again after a while, if it gets reintroduced, we'll be thinking 'what the heck is going on' unnecessarily
[18:17] <bschaefer> sil2100, yeah I agree, this is one of those regressions that is hard to detect
[18:17] <bschaefer> as looking at the rev, it was introduced by me :), at like 2500
[18:18] <bschaefer> sil2100, what are you running? 13.04 or 12.10?
[18:18]  * bschaefer hopes this wasn't back ported to 12.04
[18:20] <sil2100> I'm running 12.10, but from staging
[18:20] <sil2100> I'll check on precise if it's there ;)
[18:20] <bschaefer> cool, thanks!
[18:22] <bschaefer> o interesting, it is on a 75ms timer, which is why the unit test atm don't catch it either
[18:24] <bschaefer> actually no its 20 seconds...
[18:24] <bschaefer> dam variables looking the same
[18:30] <sil2100> heh ;)
[18:30] <sil2100> See you tomorrow!
[18:34] <bregma> bschaefer, what was the issue with the switcher messing up the AP tests?
[18:35] <bschaefer> bregma, i haven't confirmed it, but I should run those AP tests
[18:35] <bschaefer> bregma, it is leaning towards that
[18:35] <bregma> I'm just looking at what needs to be done to get proper unit tests set up for the switcher
[18:36] <bregma> so I'm particularly interested
[18:37] <bschaefer> oo yeah, hmm well I was looking at the unit test, and creating the switcher doesn't appear to make it lose focus :(
[18:37] <bschaefer> soo that either means there is a deeper problem...or you need to run the unity stack to get it to lose focus
[18:44] <bregma> the unit tests don't take into account of the fact that a significant portion of the logic of the switcher is in the Unity compiz plugin:  there's a signal fired off when the Switcher is initialized later after its creation, and it's connected to something in the nuityshell somewhere
[18:45] <bschaefer> bregma, hmm well that could explain that, it would just be nice to fail in a simple unit test :)
[18:46] <bschaefer> there are bits in the unityshell.cpp that should be moved into the switchercontroller
[18:46] <bschaefer> .cpp
[18:46] <bregma> bschaefer, absolutely -- I'm working on a task list for that
[18:46] <bregma> part of our new focus on total QA
[18:47] <bschaefer> bregma, awesome, im guessing that is why we need those books haha
[18:47] <bregma> Switcher seems like a good place to start because it (should be) pretty much self contained
[18:47] <bschaefer> yes it should!
[18:48]  * bschaefer wonders why autopilot is being mean
[18:51] <bregma> hmm, nothing activated by that Switcher signal should be stealing focus
[18:51] <bschaefer> well I need to dig into why EnableInput for the view steals focus when running unity vs a unit test
[18:52] <bschaefer> as the problem is in SwitcherController::ContructWindow()
[18:52] <bregma> how can you tell?
[18:53] <bschaefer> if you do a compiz --replace and wait 20 secods
[18:53] <bschaefer> seconds you lose window focus
[18:53] <bschaefer> and by adding print statements I found it was in construct window, and I commented out enableinputs and then did a compiz --replace
[18:53] <bschaefer> and then the window focus was no longer being lost
[18:53] <bregma> ConstructWIndow() calls EnableInputWindow() (from Nux) ... would that do it?
[18:54] <bschaefer> yeah, that is what the problem was
[18:54] <bschaefer> but ... doing a unit test that just creates a switcher, and gets to that function doesn't cause unity to lose window focus...
[18:55] <bschaefer> though...do the unit tests run on a different X Server?
[18:55] <bschaefer> besides the :)
[18:55] <bschaefer> :0
[18:56] <bregma> technically, the unit tests should not need a server and should not uncover this problem
[18:56] <bregma> that's another story
[18:57] <bschaefer> very true, I don't think a unit test is proper for this...
[18:57] <bschaefer> nor is an AP test
[18:58] <bregma> either way, nux::BaseWindow::EnableInputWindow() is being called with take_focus set to false, so I would expect it to not grab the focus
[18:58] <bschaefer> yeah I noticed that as well...I need to spend some more time in figuring out *why* that is enable input is causing it to lose window focus
[18:58] <bregma> ...unless the Nux ABO has changed again and there's a misalignment, but I think that's unlikely
[18:59] <bregma> *ABI
[18:59] <bschaefer> yeah, ill do some digging into Nux to figure out why...
[19:00] <bschaefer> also you can see something is sending the UBUS message to the panel, saying we lost focus
[19:00] <bschaefer> but it doesn't know the name of the window
[19:01] <bschaefer> bregma, looking at BaseWindow...it shows the window if the first bool is true
[19:01] <bschaefer> which simply showing the window could be the problem
[19:02] <bregma> gorram badly named variables, we need to bring in the daeth penlaty for those
[19:02] <bschaefer> yes... very
[19:02] <bregma> no, daeth is too good for 'em
[19:03] <bschaefer> the take_focus is just for the XInputWindow
[19:03] <bregma> a boolean variable name 'b'
[19:03] <bschaefer> haha
[19:03] <bregma> it answers the question, 'is it b?'
[19:03] <bschaefer> yes it is a b!
[19:04] <bschaefer> now everyone knows, though since its an explicit typing system it should be easy to tell!
[19:05] <bregma> well, it seems to be that creating an XInputWindow without take_focus set shouldn;t steal the focus, but now I have to brush up on XInputWindow
[19:06] <bschaefer> yeah, the XInputWindow uses the the take_focus to send an PropertyNotify that it is taking focus
[19:06] <bschaefer> so it sends an XEvent
[19:06] <bschaefer> which is the event I was receiving  when the switcher was stealing focus
[19:07] <bregma> so how has this ever worked properly?
[19:08]  * bschaefer wonders the same thing
[19:08] <bregma> second question:  why is the Switcher created as a persistent object and not created when needed?
[19:08] <bschaefer> its the SwitcherController that is just created once
[19:08] <bschaefer> the model gets created each time you hit alt+tab
[19:09] <bschaefer> and why there is a timer...im guessing so there is a better start up time....(its done with the dash and the lenses as well)
[19:10] <bregma> that's my guess, but having the Switcher (and dash et al) created when needed also saves time, and makes simpler more reliable code
[19:11] <bregma> one of the things on my list is to see comparative timings of persistent vs. as-needed design for the Switcher
[19:11] <bschaefer> yes...hmm ill see if the EnableTakeFocus is called when the switcher steals focus...
[19:11] <bschaefer> that would be nice, we still need to get some timing done to work on improving the dash speed
[19:11]  * bschaefer wonders who that was passed onto
[23:34] <Stewi3_89> Hi can someone help me restoring unity desktop? I've tryied some Google tips but still not working
[23:37] <bschaefer> Stewi3_89, could you explain the problem a bit more?


[11:15] <Odd_Bloke> smoser: We've been asked to stop updating the hostname on reboot on Azure, but still set it at first boot (and when we bounce the connection).
[11:15] <Odd_Bloke> smoser: We can do this using update_hostname; is there any way that cloud.cfg.d can stop update_hostname from running?
[11:20] <Odd_Bloke> s/using/by disabling/
[12:39] <smoser> Odd_Bloke, sure. you can remove it from the list of modules.
[12:39] <smoser> but i thought it should only do it if you had not changed it.
[13:24] <Odd_Bloke> smoser: This is the issue where Azure only want hostname set on first boot.
[13:24] <Odd_Bloke> s/set/set to the value they provide/
[13:25] <Odd_Bloke> smoser: So update_hostname does explicitly the opposite of what Azure want. :p
[13:28] <Odd_Bloke> smoser: So can I pop something off the cloud_init_modules list in cloud.cfg.d (or the data source?), or would I have to redefine the entire list?
[13:28] <Odd_Bloke> (Or just modify cloud.cfg)
[14:16] <smoser> Odd_Bloke, you have to redefine the entire list.
[14:16] <smoser> Odd_Bloke, but above, only set to the value they provide on first boot.
[14:17] <smoser> i *think* htats the behavior you get.
[14:17] <smoser> ie, boot, changes from ubuntu to some azure-provided name
[14:17] <smoser> if the user modifies /etc/hostname subsequently, it shouldnt do this agian
[14:17] <smoser> as it checks to see if the previous version is different than the current
[14:17] <smoser> and if it is, then doesn't do it.
[14:17] <Odd_Bloke> Hmm, I don't _think_ that's what I've been seeing.
[14:18] <Odd_Bloke> But I might have been bitten by that race condition.
[14:18] <Odd_Bloke> So I'll check again before I do anything else.
[14:18] <smoser> hm.. i dont see it either.. wher eis that.. i know i did that somewher.e
[14:19] <smoser> ah. update_hostname does that. but set_hostname does not.
[14:20] <smoser> update_hostname is PER_ALWAYS
[14:20] <smoser> set_hostname is PER_INSTANCE
[14:37] <devicenull> https://bugs.launchpad.net/cloud-init/+bug/1424710
[14:37] <devicenull> is there anything I can do to actually get this patch applied?
[14:42] <Odd_Bloke> devicenull: Lennert says that he worked around this problem by installing a different version of cloud-init; does that mean that this patch has been applied downstream in Fedora/EPEL?
[14:43] <devicenull> I don't see any relevant patches in the epel rpm for this
[14:47] <devicenull> hah
[14:47] <devicenull> the epel rpm "works" because it doesn't know about centos 7 using systemd
[14:47] <devicenull> so it falls back to the old working method
[14:51] <Odd_Bloke> <3
[14:52] <Odd_Bloke> devicenull: Your best bet is probably to open up a merge proposal in to lp:cloud-init with your change as a commit.
[14:53] <devicenull> ok
[15:35] <smoser> devicenull, yeah, open a MP. i can pull it fairly quickly as it looks sane. i'd *like* a non-name-based approach to "does this use systemd"
[15:37] <devicenull> will do
[19:48] <harlowja> arg, smoser stackforge cloud-init is behind like by 100+ patches :(
[19:48] <harlowja> suck
[19:48] <harlowja> *behind bzr
[19:48] <harlowja> on the 0.7.x branch...
[19:50] <harlowja> http://paste.ubuntu.com/10823678/
[19:50] <harlowja> poopy
[19:50]  * harlowja wonder how we can get all those in without 155 openstack reviews, lol
[19:51] <harlowja> oddly not all 155 just cleanily apploy
[19:51] <harlowja> *apply
[19:51] <harlowja> which is weird
[19:51] <harlowja> smoser how did u make https://github.com/cloud-init/cloud-init initially?
[19:52]  * harlowja doesn't make sense that those patches wouldn't apply (since they came from git<->bzr layer)
[19:52] <harlowja> 0047-Remove-a-comment-turd.patch
[19:52] <harlowja> lol
[19:52] <harlowja> 0051-Remove-debugging-turd.patch
[19:52] <harlowja> lol
[19:53] <smoser> i used bzr fast export / git fast import probably
[19:53] <harlowja> hmmm, intersting
[19:54] <harlowja> maybe i should try that vs https://github.com/felipec/git-remote-bzr (or simiar)
[19:55] <harlowja> hmmm
[20:02] <harlowja> weird, ya, still doesn't cleanly apply, oddness
[20:03] <harlowja> http://paste.ubuntu.com/10823722/ seemingly weird that that happens at all...
[20:05] <smoser> yeah, that is odd
[20:05] <harlowja> def
[21:52] <devicenull> actually, I'm looking at this again and I can't figure out how update_hostname is supposed to work
[21:52] <devicenull> based on "LOG.debug("%s differs from %s, assuming user maintained hostname.","
[21:53] <devicenull> I assume it's not supposed to update the hostname if it's different from what it expects (cloud-init set the hostname once, then the user changed it)
[21:53] <devicenull> but that doesn't seem to be what the code does
[21:53] <devicenull> is my assumption that it's not supposed to be overwriting user changes correct?
[22:09] <harlowja> user changes being something out of band updating the hostname?
[22:09] <harlowja> i forget what the code is doing, but maybe is what u sy
[22:09] <harlowja> *say
[23:04] <devicenull> yea
[23:05] <devicenull> it looks like a bug tbh, I'll be looking into it more tomorrow
[23:27] <harlowja> k
[23:49] <harlowja> smoser arg, got closer
[23:49] <harlowja> http://paste.ubuntu.com/10824510/
[23:49] <harlowja> did we turn on the ccla check in that repo :-/
[23:49] <harlowja> or need other way to make it ignore the committer...
[23:50] <harlowja> but nearly got it to work, ha


[20:09] <Jay2k1> Xin: in /etc/mythtv/config.xml you can define a mysql server
[20:10] <Xin> Jay2k1; LOL PRETTY SURE I ASKED LIKE A DAY OR TWO AGO
[20:10] <Xin> xDDD
[20:11] <Jay2k1> about one day and 14 hours, yes


[08:59] <cyberanger> #swissknife-router
[09:00]  * cyberanger really dislikes tab complete sometimes
[09:27] <Unit193> Heh.


[05:35] <troy_s> DID I JUST READ THAT EMAIL ON THE LIST?
[05:35] <troy_s> grr.
[06:38] <melaren> If you send a message to<EMAIL_ADDRESS>without signing up does it still send to the list?
[07:15] <troy_s> melaren: It sits in a slush until an admin visually filters it iirc.
[07:15] <troy_s> melaren: If you want to be certain the list gets the message, the only way that I know of is to sign up for the list.
[07:24] <troy_s> melaren: That help?
[07:59] <melaren> troy_s, Sure does, thanks!
[09:12] <yoshiznit124> has anyone considered incorporating the release's animal (like a heron) into the default wallpaper?
[09:37] <BHSPitLappy> I CANNOT BELIEVE WE FORGOT TO CONSIDER THAT
[10:08] <BHSPitLappy> troy_s, what post enraged you so?
[10:09] <troy_s> BHSPitLappy: just the same old rubbish.
[10:09] <troy_s> BHSPitLappy: and lol to your last comment.
[10:09] <troy_s> BHSPitLappy: I was rather disappointed for having wasted Justin's time with the list.
[10:10] <BHSPitLappy> this Gelatin business doesn't do anything for me
[10:10] <BHSPitLappy> it's very well-polished-looking though
[10:11] <BHSPitLappy> never mind, mockups can't be polished
[10:35] <troy_s> BHSPitLappy: What gelatin link?
[10:36] <BHSPitLappy> troy_s, https://wiki.ubuntu.com/Artwork/Incoming/Hardy/Alternate/gelatin
[10:36] <BHSPitLappy> it's on the top of the linux section of digg
[10:37] <troy_s> BHSPitCSP: I thought the choice of wallpapers has been getting closer to Ubuntu however -- the grain from Ken's effort.  Laren's submission is marred by the fact that the tonal range is balanced out with the natural greens in the snapshots -- a bit of a cheat.  The wall alone (with theme details) is back into the monotone mode slightly (not _quite_ as bad as Ubuntu default)
[10:37] <troy_s> BHSPitLappy: It is probably the best wallpaper choice thematically.    You missed another helpful guy earlier... I'll copy and paste to share the wisdom...
 has anyone considered incorporating the release's animal (like a heron) into the default wallpaper?
[20:53] <troy_s>  /join #jadedfeckerclub
[20:53] <thorwil> wow!
[20:53] <troy_s> thorwil: WOW
[20:53] <troy_s> thorwil: Let me look deeper into rainwalker's thinking...
[20:54] <thorwil> troy_s: wait, wait, we could combine that_ a non-glossy heron
[20:54] <troy_s> thorwil: GLOSS = MODERN
[20:54] <troy_s> thorwil: Which about tells you the validity of the statement to begin with.
[20:54] <Tm_T> troy_s: true
[20:54] <troy_s> thorwil: WOOO WHAT ABOUT A GLOSSY HERON!
[20:54] <thorwil> troy_s: no problem, i think we are in the post pots modern era
[20:54] <troy_s> modern!
[20:55] <troy_s> I unfortunately end up sounding like someone who believes that gloss is the sole root of Ubuntu's problem (which has been actually gone for a bit -- but seems to pop up in every tacky mock I see)
[20:55] <troy_s> Glossy is symptomatic.  It still leaves us as we are now -- without style.
[20:55] <troy_s> (in addition to a few other intangibles such as context, audience, motif, thematic, etc.)
[20:56] <troy_s> Does anyone see an interesting 'style' developing out there in the wild?
[20:56] <troy_s> thorwil: LOL -- wtf is "PostPotsModern" LOL -- I love it.
[20:57] <thorwil> troy_s: the pots was meant to be a second post
[20:57] <troy_s> "We aren't po-mo, we are po-pot-mo."
[20:57] <troy_s> i know
[20:57] <troy_s> it looks better as pots!
[20:57] <thorwil> troy_s: well, post modernism needs closure, but what comes afterwards?
[20:58] <troy_s> thorwil: Modernism got closure.  Post-Modernism.  But a good question.  I suppose we have been stuck in Post-Modernism-Oops-Britney-Spearsism for a while.
[20:58] <thorwil> oopism!
[20:59] <troy_s> thorwil: In our world, something like a neo-ren (done 19th late cen to early 20th) or neo-romaticism.
[20:59] <troy_s> probably most appropriate.
[20:59] <thorwil> how dare firefox freeze when i'm writing  a post pots modern post!
[21:00] <troy_s> unfortunately we have not enough style or class to get anywhere close to that just yet.  we need a bastion of style and class to have a bloody movement.  we are a _wee_ tad off from that.
[21:00] <troy_s> lol
[21:00] <thorwil> troy_s: isn't neo-romaticism an aspect of post modernism?
[21:00] <troy_s> thorwil: Po-mo gets thrown around just about everywhere.
[21:00] <troy_s> thorwil: From the time I was in school, I can honestly say that it has gotten even cloudier than when it started.
[21:01] <thorwil> heh yeah, another term that is everyones bitch, if i may say :)
[21:03] <troy_s> thorwil: Probably apt.  When I was studying, po-mo had elements of what is commonplace today -- the idea of the subject involvement / third wall removal and non-linear was rather hip (especially in novels)
[21:04] <troy_s> thorwil: Memento was sort of a 'mainstream' po-mo example, followed up by a far more adept 21Grams (although still rather bound up in narrative linearism).  Of course anyone from Europe familiar with decent cinema could probably cite a few auteurs who were doing that sort of thing before those hit mainline.
[21:04] <thorwil> the way i got to know it was taking modern lines and adding stuff in eclectic ways
[21:06]  * thorwil goes on a 3rd try to post a picture
[21:08] <thorwil> http://thorwil.wordpress.com/2008/01/02/ubuntu-brainstorm-5/
[21:08] <thorwil> not too happy, but had to try it
[21:10] <troy_s> yeah i don't know if I could say that was po -mo... most of what i "know" as po-mo is somewhere between dadaist / surrealist meets "trendy".
[21:11] <troy_s> it is something like imagining a pop-culture sales brochure or building architecture warped out in some way that makes it almost unattractive to that very audience.
[21:11] <troy_s> i remember someone pointed me to a good gallery on po-mo stuffs... i wonder if i could find it.
[21:12] <thorwil> i'll be off in seconds
[21:12] <troy_s> thorwil: Ditto...
[21:13] <troy_s> this to me is rather po-mo
[21:13] <troy_s> http://www.whitelead.com/jrh/screenshots/cafeteria.JPG
[21:14] <thorwil> jepp, i can agree to that :)
[21:14] <troy_s> http://www.whitelead.com/jrh/screenshots/
[21:14] <troy_s> he did a whole series... rather... good commentary.
[21:14] <thorwil> troy_s: i know a video in that style
[21:14] <thorwil> troy_s: gotta run, see you!
[21:14] <troy_s> thorwil: Ciao thorwil
[21:25] <lassegul_> :q!
[21:54] <_MMA_> http://betatype.com/node/36


[03:45] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 498 for the week February 6 - 12, 2017 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue498


[02:05] <callmepk> good morning
[02:05] <sarnold> hey callmepk
[02:06] <callmepk> hi sarnold
[02:38] <duflu> Hi callmepk and sarnold
[02:38] <callmepk> hi duflu
[04:34] <KGB-2> gnome-control-center ubuntu/master b485c0a Robert Ancell debian/ changelog patches/ubuntu/Allow-tweaking-some-settings-for-Ubuntu-Dock.patch * releasing package gnome-control-center version 1:40.0-1ubuntu4 * https://deb.li/3ggGs
[06:49] <jpnurmi> good morning
[06:49] <jibel> Good morning all
[06:58] <duflu_> Hi jpnurmi and jibel
[06:58] <jpnurmi> hi duflu_ callmepk jibel
[07:00] <didrocks> hey duflu_, jpnurmi, jibel
[07:00] <jpnurmi> hey didrocks
[07:11] <duflu_> Hi didrocks
[07:13] <jibel> Hi jpnurmi duflu didrocks
[07:24] <oSoMoN> good morning desktoppers
[07:24] <duflu> Hi oSoMoN
[07:24] <oSoMoN> hey duflu
[07:24] <jpnurmi> hey oSoMoN
[07:25] <ricotz> good morning everyone
[07:26] <oSoMoN> good morning jpnurmi, ricotz
[07:27] <jpnurmi> hi ricotz
[07:48] <duflu> Hi ricotz
[08:05] <didrocks> salut oSoMoN, ricotz
[08:05] <oSoMoN> salut didrocks
[08:06] <laney> yo
[08:08] <duflu> Hi laney
[08:09] <oSoMoN> yo laney
[08:13] <laney> hey duflu & oSoMoN
[08:13] <laney> what's the news
[08:17] <didrocks> hey laney
[08:18] <oSoMoN> not much, the heat is back today…
[08:24] <laney> moin didrocks
[08:25] <laney> oSoMoN: oh yeah, I saw something about a southern european heatwave
[08:25] <laney> is that touching you then?
[08:26] <oSoMoN> I must admit I haven't really checked the news lately, but seeing my weather station's readings it looks like it's gonna be a hot day
[08:26] <callmepk> hi jpnurmi jibel didrocks oSoMoN ricotz laney
[08:26] <laney> it said something like 'extreme danger' for some places
[08:26] <laney> :S
[08:27] <laney> hey there callmepk
[08:27] <oSoMoN> hey callmepk
[08:27] <jpnurmi> hey laney
[08:27] <oSoMoN> one outdoor sensor (which is exposed to the sun at this time of the day) currently reads 42.9°C
[08:28] <laney> 😭
[08:28] <laney> I guess there's only a limited window to be outside when it's like that
[08:29] <laney> \o jpnurmi
[08:29] <oSoMoN> best time of the day to be outside is before 9am
[14:17] <KGB-0> orca pristine-tar 2d3d62b Samuel Thibault orca_41~alpha.orig.tar.xz.delta orca_41~alpha.orig.tar.xz.id * pristine-tar data for orca_41~alpha.orig.tar.xz * https://deb.li/3WBxR
[14:17] <KGB-0> orca upstream/beta 0107991 Samuel Thibault * pushed 67 commits (first 5 follow) * https://deb.li/ecND
[14:17] <KGB-0> orca upstream/beta 5555a59 Joanmarie Diggs src/orca/event_manager.py * Event Manager: Lower thresholds for flood and deluge again * https://deb.li/3AXEz
[14:17] <KGB-0> orca upstream/beta 7fb7075 Joanmarie Diggs src/orca/event_manager.py * Event Manager: Add state-changed:sensitive to ignore worthy during floods * https://deb.li/FXVl
[14:17] <KGB-0> orca upstream/beta 04be36d Joanmarie Diggs src/orca/ event_manager.py scripts/terminal/script.py * Event Manager: Don't switch scripts for activate on already-active window * https://deb.li/SFIA
[14:17] <KGB-0> orca upstream/beta 64a5f70 Joanmarie Diggs src/orca/event_manager.py * Event Manager: Add state-changed:showing to ignore worthy during floods * https://deb.li/3bBpi
[14:17] <KGB-0> orca upstream/beta 3f34a4d Joanmarie Diggs src/orca/event_manager.py * Event Manager: Add window:deactivate and state-changed:active to spam clearers * https://deb.li/3gcA0
[14:34] <KGB-0> orca tags 559ec25 Samuel Thibault upstream/41_alpha * Upstream version 41~alpha * https://deb.li/72Q7


[04:24] <mxpxpod> BenC: ping
[10:52] <marcreichelt> hi there
[10:57] <marcreichelt> my ubuntu kernel seems to have problems with acpi - nearly every time when my laptop is under heavy use (e.g. reading big files from my external usb disk or burning a cd) it just hangs up with a kernel panic
[10:59] <marcreichelt> a shot of the screen can be found here: http://www.marcreichelt.de/misc/kernelpanic.jpg
[10:59] <marcreichelt> I tried to deactivate all modules containing the word "acpi", but this didn't fix the problem
[11:00] <marcreichelt> I also tried to deactivate acpi on boot, with "acpi=off" as kernel parameter
[11:01] <marcreichelt> the result was that the system frozed after approx. 30 seconds after boot time
[11:01] <marcreichelt> do you have any ideas? is this a bug in the ubuntu kernel? what can I do?
[11:40] <mjg59> marc_learning: "acpi_processor_idle" just means that the system wasn't doing anything at the time
[11:40] <mjg59> But you can check by unloading the "processor" module
[01:29] <marcreichelt> back again
[01:34] <marcreichelt> hmm
[01:35] <marcreichelt> processor depends on speedstep_centrino, and I can't unload that one, because it is in use
[01:41] <marcreichelt> but it doesn't say by which module it is used
[01:42] <Mithrandir> it's probably used by powernowd or something similar.
[01:43] <infinity> No, you can't unload centrino.  mjg59 and I ran into that a week or two ago.  It's thpethul.
[01:44] <infinity> The only way I could "unload" it was to not load it in the first place.
[01:45] <marcreichelt> k
[01:45] <marcreichelt> how can I deactivate it on boot?
[01:45] <marcreichelt> so that "processor" and speedstep_centrino aren't started at boot time?
[01:45] <infinity> Blacklist them in modprobe.
[01:45] <marcreichelt> Mithrandir, I killed powernowd
[01:46] <infinity> Alternately, move the files somewhere else so you're sure nothing can load them. :)
[01:48] <marcreichelt> moment...
[01:48] <marcreichelt> brb
[01:57] <marcreichelt> ok, I created the file /etc/hotplug/blacklist.d/asuslaptop-problems and wrote the line "processor" into it
[01:57] <marcreichelt> is this correct?
[01:59] <marcreichelt> I think it should be
[01:59] <marcreichelt> well, I'm going to reboot now
[02:00] <marcreichelt> see you in a few minutes
[02:12] <marcreichelt> hello again
[02:12] <marcreichelt> my module "processor" is still running
[02:12] <marcreichelt> even a line in /etc/hotplug/blacklist did not work
[02:13] <marcreichelt> you still mean that it would be good to rename the module?
[02:14] <marcreichelt> k, I renamed the processor module
[02:14] <marcreichelt> brb
[02:19] <marcreichelt> hi again
[02:20] <marcreichelt> he still loads the module "processor" - but I renamed processor.ko to processor.ko.old... :-/
[02:20] <marcreichelt> maybe I have to create a new initrd?
[02:21] <marcreichelt> or kernel?
[02:22] <marcreichelt> or is there another way to fix my problem?
[02:23] <marcreichelt> I would hack myself into the kernel to solve this problem if I would have the time to
[02:24] <marcreichelt> the problem seems to be in processor.c
[02:36] <marcreichelt> :-(
[02:47] <marcreichelt> brr
[02:48] <marcreichelt> again a kernel panic
[02:49] <makx> what ubuntu version are you using
[02:49] <makx> blacklists should be under /etc/modprobe.d
[02:49] <marcreichelt> Breezy
[02:50] <marcreichelt> Kernel: 2.6.12-10-386
[02:50] <makx> yes put it there
[02:50] <marcreichelt> moment
[02:51] <marcreichelt> makx, how should the blacklist look like?
[02:51] <marcreichelt> just a file containing the line "processor"?
[02:55] <marcreichelt> ?
[02:56] <makx> blacklist evbug
[02:56] <makx> for example
[02:56] <marcreichelt> k
[02:56] <marcreichelt> for me it is blacklist processor, then
[02:57] <marcreichelt> ok, brb
[03:02] <marcreichelt> no, it didn't work
[03:02] <marcreichelt> he is still loading the module "processor"
[03:03] <marcreichelt> is there a kernel version which does not contain this bug?
[03:32] <zul> heylo
[03:50] <BenC> marcreichelt: dpkg-reconfigure linux-image-`uname -r`
[03:50] <BenC> that will generate a new initramfs
[03:52] <mxpxpod> BenC: have you had any problems lately with your ae?
[03:52] <BenC> none
[03:52] <BenC> other than the weird eth0_clashed thing, but that's not particular to ae
[03:53] <mxpxpod> BenC: check this out... someone in my apartment installed a wireless router with authentication on the same channel as mine and my ae gets a ton of DEAUTH messages from it
[03:53] <mxpxpod> this causes klogd to go crazy and take up like 10% cpu
[03:53] <BenC> hmm, sounds like softmac actually
[03:53] <mxpxpod> if I switch to another channel, I don't get it
[03:54] <mxpxpod> oh, really?
[03:54] <BenC> maybe I need to turn down the verbosity
[03:54] <BenC> the messages I think come from softmac
[03:54] <mxpxpod> yeah, dmesg is full of DEAUTH's
[03:54] <mxpxpod> it's quite frustrating... so I switched channels
[03:55] <BenC> actually, it's right from ieee80211.ko
[06:09] <lamont> BenC: can you easily tell me when the last update of the hppa patch in 2.6.15 happened?  (was -13 built with the hppa patchset, or without, to be specific...)
[06:13] <BenC> I've never applied an hppa patchset per se
[06:13] <BenC> I merely got what was there to work
[06:14] <BenC> lamont: so it's 99% stock 2.6.15 code for hppa, with just one backport for a compat syscall I can't recall off hand
[06:19] <lamont> BenC: please consider merging the following patches (minimum) from ftp://ftp.parisc-linux.org/patches
[06:19] <lamont> diff-2.6.12-rc3-tulip_21142_phyinit, diff-2.6.3-tulip, diff-2.6.6-tulip_stop_rxtx, diff-tulip_phy_reset-03
[06:19] <lamont> all 4 are in akpm's tree
[06:22] <lamont> those patches make tulip work on modern hardware...  bug exists on hppa as well as some i386 platforms
[07:16] <marcreichelt> BenC: just leave the processor blacklisted and generate a new initramfs?
[07:21] <fs> what's the current status of the megaraid newgen/legacy patch?
[07:33] <fs> never mind, found it: it's merged upstream.
[07:35] <lamont> BenC: I'll start working through the hppa patchset to see what makes sense for us to include
[07:36] <lamont> as in, what's low-risk and/or hppa specific
[08:44] <marcreichelt> ok, I give up
[08:44] <marcreichelt> the module 'processor' is still running
[08:45] <marcreichelt> maybe I'm just too stupid for this :-/
[09:03] <BenC> marcreichelt: rm -f the module
[09:07] <marcreichelt> hmm
[09:07] <marcreichelt> or better mv module module.bak?
[09:09] <marcreichelt> ok
[09:09] <marcreichelt> root@tux:/lib/modules/2.6.12-10-386/kernel/drivers/acpi # mv processor.ko processor.ko.bak
[09:09] <marcreichelt> now I do dpkg-reconfigure linux-image-`uname -r`
[09:10] <marcreichelt> hmm
[09:10] <marcreichelt> root@tux:/lib/modules/2.6.12-10-386/kernel/drivers/acpi # dpkg-reconfigure linux-image-`uname -r`
[09:10] <marcreichelt> Not touching initrd symlinks since we are being reinstalled (2.6.12-10.26)
[09:10] <marcreichelt> Not updating image symbolic links since we are being updated (2.6.12-10.26)
[09:10] <marcreichelt> it seems that he didn't noticed anything
[10:23] <marcreichelt> I have to go
[10:23] <marcreichelt> see you


[04:52] <buggix> hi, I want to install vista additionally in a free partition. but it seems to be not possible. is it true?
[15:01]  * persia waves
[15:03] <beuno> persia!
[15:03] <beuno> hi
[15:05] <amachu2> elkbuntu: persia: Hi
[15:05] <amachu2> lifeless: Hi
[15:06] <persia> amachu2, Unless I am mistaken, I suspect our Australian counterparts will not be in attendance this evening, as it's very late there.
[15:07] <persia> Unless some of our often absent companions arrive, I believe it's just you and I.
[15:07] <amachu2> persia: Ok
[15:07] <cody-somerville> What meeting is this?
[15:08] <persia> cody-somerville, AsiaOceania RMB, although I suspect we won't reach quorum, as we need to increase our size in the western part of our region.
[15:08] <amachu2> persia: fine. Long since we met too..
[15:09] <persia> amachu2, Indeed.  Given the wide celebration of new years, I suggest we next look at 9:00 on the 6th.
[15:09] <amachu2> persia: that Ok for me
[15:10] <amachu2> and any thoughts you have on increasing the Board strength?
[15:10] <persia> I've been looking at long-standing members in the region, but don't have any strong nominations yet: hard to judge the combination of activity and location well.
[15:11] <persia> You?
[15:11] <amachu2> no not yet..
[15:12] <persia> The next couple weeks should be quiet, as so many of us are in Europe or the Americas, where the holidays are nearly started.  Perhaps we can use that gap to identify some people?
[15:13] <amachu2> we should..
[15:14] <persia> As much as I like them, I think we don't want more Australians, given the timezones.
[15:14] <amachu2> there are plenty I feel too :-)
[15:15] <amachu2> yourself, me, elky, lifeless and muso five of us have shown continuity
[15:16] <amachu2> belutz, zakame we need to check again. I hope belutz can make it. We need to identify two now
[15:18] <amachu2> if zakame isn't going to make it, it is going to be three
[15:18] <persia> Then let's each try to send a nomination for consideration by the team before the new year.  We can select two or three from that set for submission to the CC.
[15:19] <amachu2> we should have more nominations than the required no.. atleast +1..
[15:19] <amachu2> yes..
[15:19] <persia> Right.  There are 5-7 of us.  With luck, we can get 3-5 internal nominations in the next week.  From that, we can select submissions to the CC.
[15:20] <amachu2> that should be fine.
[15:21] <persia> OK.  Any other business?  Our candidate doesn't appear to be present.
[15:22] <amachu2> persia: nope
[15:23] <persia> OK.  I have one: do we want a procedure to roll over the post of secretary?  (or are you happy holding that role indefinitely)
[15:23] <amachu2> lets wind up for now.. :-)
[15:24] <amachu2> i thought I propose that after six months
[15:24] <persia> That works.  Let's do it then, with our expanded numbers.
[15:24] <amachu2> how long I have been holding the reponsibilty
[15:24] <amachu2> from June
[15:25] <amachu2> its time for that too..
[15:25] <persia> Right, so in six months means a one-year term, which doesn't seem bad.
[15:25] <persia> Oh, you want only a six-month term?  I thought you meant six more months.
[15:26] <amachu2> well if there are people willing to take up responsibility, I can hand over..
[15:26] <amachu2> I am fine though
[15:26] <persia> heh.
[15:26] <persia> If you're fine, let's let it go another six months, just so we can get the expanded team and the moving schedule stable.
[15:27] <amachu2> persia: that should be fine
[15:27] <persia> OK Great.  IN that case, have a good new years.
[15:28] <amachu2> wish you the same :-)
[15:28] <amachu2> bye bye
[15:28] <amachu2> elkbuntu: lifeless: if you people wake, wishing you both too :-)
[16:02] <nealmcb> is there a server team meeting today?
[16:03] <sommer> I thought there was, but I'm not sure we realized how close to christmas it was last week
[16:04] <sgbirch> According to the UbuntuWeekly newsletter there was one scheduled. https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue122
[16:06] <nealmcb> zul chaired the meeting last week
[16:07] <persia> Are there enough people here to have the meeting?
[16:07] <nealmcb> we decided to have a meeting again this time.  I don't remember any minutes or announcement of the meeting
[16:09] <sommer> I'm thinking everyone's already on x-mas break
[16:09] <sommer> but that's just my though :)
[16:10] <sommer> err thought
[16:10] <nealmcb> yup - and I've got a guest, and something else just came up
[16:11] <persia> So perhaps this meeting is just waived then, and the next is the 6th?
[16:11] <nealmcb> Seems like it to me.  Enjoy the holidays!
[16:13] <sommer> have a good one nealmcb
[16:13] <nealmcb> sommer: and to you!
[16:27] <brainac0cult> hi my name is brainac0cult


[03:50] <Unit193> https://www.ohioturnpike.org/media/2022-name-a-snowplow-contest
[04:01] <Unit193> Dang, I never responded to the OLF people. :/


[07:20] <Anon007_> hi if I remove my nvidia graphics card and replace it with a better one will it work ok without having to do anything or what do i need to do please thanks
[07:21] <Anon007_> hello?
[23:39] <aeGIs> Classy