[00:05] <doctormo> If I do a bzr pull, will it kill all changes done in this branch and revert it?
[00:06] <doctormo> So if there are uncommited changes, or commited changes, they'll all be reverted.
[00:08] <spiv> pull will never discard uncommitted changes.
[00:09] <doctormo> spiv: But it will do away with commited changes?
[00:10] <spiv> If you pull --overwrite to an older revision, then the later revisions will no longer be in that branch's ancestry, yes.
[00:10] <lifeless> if they aren't in the new history, yes
[00:10] <spiv> (The revisions will still exist in the repository, though)
[00:11] <doctormo> spiv: I'm just trying to work out what I'm doing in my pull code, perhaps what I mean to do is not pull but merge.
[00:11] <doctormo> What would you do if you had a parent directory that had moved forwards and you wanted to resync your working branch with it.
[00:12] <maxb> If you did pull in that case, it would tell you 'branches have diverged'
[00:12] <spiv> I'm not sure about "parent directory that had moved forwards", but generally speaking if I have a branch that I've made changes in, and I want to incorporate changes from elsewhere to the same branch, I would use 'bzr merge'.
[00:13] <doctormo> s/parent directory/parent branch/
[00:13] <maxb> It's hard to tell what you mean by 'resync'
[00:13] <doctormo> Translating bazaar speak into something your holiday developer will understanding is making my terms diverge maxb.
[00:14] <spiv> maxb: ('branches have diverged' is right if we assume the working branch has had commits made, rather than just uncommitted changes)
[00:14] <maxb> a good point
[00:15] <doctormo> So what i really mean is `bzr merge` when I have local commits and `bzr pull` when I don't have local commits (but local changes ok)
[00:15] <spiv> doctormo: in relatively simple terms, if two people both have a copy of a branch, and they have made different commits to their copies, you probably want 'bzr merge' to combine those different changes.
[00:16] <spiv> doctormo: there's "bzr merge --pull", btw, which automates "'bzr pull' if no divergence, otherwise 'bzr merge'"
[00:16] <doctormo> spiv: I think I'll try and hook into builtins for that then, I had a bad time intergrating builtins into my threaded code though.
[00:18] <spiv> doctormo: you can always take a look at the code to see how its implemented.
[00:18] <spiv> doctormo: the code in builtins.py is mostly fairly readable
[00:19] <doctormo> spiv: It is, but I'm feeling bad about copying bits out of it, like I'm removing all the checks.
[00:19] <doctormo> http://bazaar.launchpad.net/~groundcontrollers/groundcontrol/trunk/annotate/head%3A/GroundControl/bazaar.py
[00:20] <doctormo> If interested, look at the do_action methods, I think they probably should be going through builtins.
[00:22] <spiv> doctormo: perhaps you should be reusing some code from the bzr-gtk plugin?
[00:22] <spiv> (or even the qbzr plugin?)
[00:23] <spiv> They've both already wrapped lots of builtin actions into a GUI-friendly form.
[00:23] <doctormo> spiv: I already am, as much as I could. But the problem is that I have really bad constraints because of nautilus.
[00:23] <spiv> Ah ok.
[00:24] <doctormo> It took me 3 weeks to work out how to get around those contrains too, I've lost an inch of hairline ;-)
[01:53]  * spiv lunches
[03:59] <igc> hi all
[04:04] <spiv> hi igc
[04:04] <igc> hi spiv!
[07:37]  * spiv finishes up for the day
[07:52] <vila> poolie: you broke my toy ! https://bugs.edge.launchpad.net/bzr/+bug/516934
[07:57] <fullermd> Pfft.  Your toy is just too slow   :p
[08:31]  * igc dinner
[08:43] <poolie> hi vila
[08:43] <poolie> hi igc?
[08:47] <smartgpx> Greetings. Are there any Win32 supporters in - I've just encountered an odd crash that is making me feel panicky
[08:48] <smartgpx> 'Out of the blue', > bzr explore has stated throwing a MS Visual C++ runtime error.
[08:49] <smartgpx> Console reports "QVariant::load(QDataStream &s): type list unknown to QVariant." Nothing in .bzr.log
[08:51] <fullermd> I presume that's Qt-related.
[08:52] <smartgpx> Yes, so do I. But this is a setup.exe binary installer machine, so as far as I know the only Qt is in the bzr bundle
[08:52] <fullermd> Which version?
[08:53] <fullermd> (I have no idea what solutions might be BTW, so don't expect answers from me  :)
[08:53] <smartgpx> freshly re-installed bzr2.1.0rc1-1.exe AFTER first hitting the problem
[09:00] <smartgpx> other tools from the qbzr suite run OK. qlog, qplugins both look normal.
[09:01] <smartgpx> Since re-installing from the binary installer doesn't fix it I'm fearing something is trashed in my OS. But what and how/why? AV scan running now!
[09:17]  * bialix calls for Gary
[09:17]  * fullermd isn't Gary  8-}
[09:22]  * bialix waves at fullermd
[09:25] <vila> smartgpx: Don't Panic
[09:26] <vila> smartgpx: I don't know the details but igc mentioned some Qt compatibility problems citing QVariant, so at least the problem is not unknown
[09:26] <vila> smartgpx: please file a bug against bzr-explorer though better a dupe than no report
[09:27] <vila> bialix, fullermd : hey guys !
[09:27] <fullermd> Oh, no, go ahead and panic.  It's good aerobic exercise.
[09:27] <bialix> heya vila!
[09:27]  * fullermd waves at vila.
[09:27]  * vila checks its hitchhiker's guide about aerobic....
[09:28] <bialix> smartgpx: what's up?
[09:28] <vila> . o 0 (aerobic raises EBADFORCHOLESTEROL)
[09:29]  * bialix thinks we have to upgrade windows installer to pyqt 4.7 so igc won't need to break backward compatibility at such high rate
[09:31] <smartgpx> NO - I've been told to get my HDL levels down! bialix - summary on Bazaar ML
[09:31] <bialix> HDL?
[09:38] <smartgpx> High Density Lipids I think - 'Bad Cholesterol'.
[09:38] <smartgpx> Bugged as Bug#516968
[09:41] <fullermd> Lipoprotein to be precise.
[09:41] <fullermd> (and actually HDL is the soi-disant 'good' variant)
[09:42] <fullermd> So whoever wants you to get those levels _down_ is...   well...    are they in your will?   ;>
[09:42] <bialix> ubottu: please tell me about bug #516968
[09:43] <bialix> thank you!
[09:44] <bialix> smartgpx: can you try to remove explorer.conf file?
[09:44] <bialix> or something similar
[09:44] <vila> fullermd: That should be obvious but how do I make a shell script change my current working directory ?
[09:45] <fullermd> vila: Well, if I understand you, you don't, since a script (by definition) runs in its own process, and $CWD is an attribute of each process.
[09:45] <smartgpx> CONFIRM that removing explorer.conf gets Explorer running again.
[09:45] <bialix> close explorer, open again and you'll get a crash?
[09:46] <fullermd> vila: So to change the $CWD of your current shell, it would have to run in that process, not external, with all that implies.
[09:46] <vila> fullermd: so I have to . shell-script ?
[09:46]  * fullermd nods.
[09:46] <vila> rats, . `which shell` args.... how ugly :-/
[09:47] <vila> funny I never encounter the problem before...
[09:47] <smartgpx> Thanks to Simon Kersey for suggesting this.
[09:47] <fullermd> Well, maybe you could reach into /proc and manually fudge in the other process's memory.  Is that less ugly?   ;)
[09:47] <vila> fullermd: Brilliant !
[09:47] <vila> :-P
[09:48] <fullermd> Well, naturally.  I said it, didn't I?
[09:48] <bialix> smartgpx: perhaps this is because explorer in big flux
[09:48] <smartgpx> bialix - no, it re-runs OK. I didn't think to mention that I had been exploring the new preferences in r405!
[09:48] <bialix> we need to test how smooth it will upgrade from 0.11.x to 1.0
[09:49] <bialix> oh, sorry, just saw your mails in bzr ML
[09:51] <bialix> smartgpx: anyway, thanks for testing bleeding edge changes and reporting!
[09:56] <smartgpx> maybe it isn't a recent problem? Anyway, rebugged as #516976
[09:59] <bialix> bug #516976
[09:59] <vila> ubottu: pay attention please, when someone says #516976, just interpret it as bug #516976, thanks
[10:00] <vila> bialix: faster than me !
[10:00] <bialix> :-)
[10:00] <bialix> smartgpx: I will try to look on this today
[10:01] <smartgpx> fullermd: [OT] thanks for making me re-think my knowledge of cholesterol! More reading required.
[10:02] <fullermd> Amazing the things version control can lead you to thinking of   8-}
[10:08] <igc> smartgpx: see my email on the Qt issue
[10:22] <vila> fullermd: alias is my friend :D alias bzr-review='. `which bzr-review.sh`'
[10:26] <bialix> hi igc :-)
[10:32] <bialix> igc: we have to update explorer's setup.py otherwise your new fancy wear things won't go to installer/package. can we elaborate on this?
[10:45] <igc> bialix: understood. On my list for tonight.
[10:45] <bialix> ok
[10:45]  * bialix working on preparing qbzr 0.18.1
[10:46] <bialix> anybody seen garyvdm there these days?
[10:46] <igc> bialix: I'm going to fix bug 516976 asap btw
[10:47] <bialix> igc: that's will be nice. if you need quick testing ping me
[10:47] <igc> shall do
[10:51] <poolie> igc, +1 on that mail
[10:51] <poolie> vila, testing.txt says it's _test_needs_feature=[...] but that seems wrong
[10:52] <poolie> nm
[10:52] <vila> what is... err
[10:53] <poolie> i was confused
[11:02] <poolie> vila, so you're going to delete the redundant 'requireFeature(Apport..)'
[11:04] <vila> poolie: Yes, I deleted it from your test and keep it only in the deprecation test reproducing the bug
[11:06] <vila> I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
[11:06] <vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
[11:08] <Kamping_Kaiser> AIUI, merging a single file into a bzr repo is the same as copying it from its original repo, because bzr only tracks commits, not files. have i got that correct?
[11:09] <Kamping_Kaiser> when i say 'copying' i mean 'cp /this/file ./repo/'
[11:09] <vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
[11:09] <vila> s/It/Is/
[11:10] <fullermd> Kamping_Kaiser: I think merge will preserve the file-id, but that's probably the only difference.
[11:11] <Kamping_Kaiser> fullermd: i still have the files original bzr repo in future i can use the file id to track its history by searching in the old bzr repo?
[11:12] <Kamping_Kaiser> *if i
[11:12] <fullermd> Conceptually (though I don't think there's anything in the implementation to automate any of that)
[11:13] <Kamping_Kaiser> hm, ok. its only a few dozen lines of shell, i might just reimpliment it this time. i'll come back and sook when i want something more complex ;)
[12:08] <igc> bialix: please test preference saving in rev 407. bug 516976 ought to be fixed now
[12:11] <bialix> igc: revno 405 don't want to start at all for me. unicode error (again)
[12:11] <igc> bialix: try rev 407
[12:12] <bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517036
[12:13] <bialix> igc: 407 starts but the console full of tracebacks: http://pastebin.com/m57981d80
[12:15] <igc> bialix: delete the tools.xml file in your explorer directory and start the app again please
[12:15] <bialix> https://bugs.launchpad.net/bzr-explorer/+bug/517040
[12:16] <bialix> igc: deleted. now I have unicode error again
[12:16] <igc> bialix: pastebin?
[12:17] <bialix> see it there https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/1
[12:17] <bialix> igc: ^
[12:18] <bialix> igc: last time it was last month and you decide to move from text to pickle, or something similar
[12:18] <bialix> again: this is bad idea to write localized text to conf files
[12:20] <igc> bialix: well the history file doesn't need to be human readable. explorer.conf does need to be IMO
[12:32] <bialix> igc: https://bugs.launchpad.net/bzr-explorer/+bug/517040/comments/2
[12:35] <bialix> igc: empty toolbars.xml was the raeson of element tree tracebacks
[12:40] <igc> bialix: how did you get an empty toolbars.xml? Maybe that was there once but lib/extensions/__init__.py suggests it should always have content now
[12:41] <bialix> igc: have no idea
[12:41] <bialix> I don't edit anything by hands in explorer/ directory
[12:45] <igc> bialix: I wonder what effort we should make to check bzr vs qbzr vs explorer compatbility?
[12:45] <bialix> what do you mean/
[12:45] <bialix> &
[12:46] <bialix> ?
[12:46] <igc> bialix: I'm seeing quite a few bugs with old explorer and new qbzr or vice versa
[12:46] <bialix> rats
[12:46] <bialix> I'd say in explorer 1.0 you need to force some minimal qbzr version
[12:46] <bialix> I'm ok with this
[12:46] <igc> what's the minimum bzr version for qbzr 0.18?
[12:47] <bialix> there was check in explorer/__init__.py, is not?
[12:47] <bialix> qbzr 0.18 intended to be used with 2.1
[12:47] <bialix> but it should work with 2.0
[12:47] <bialix> I can check, but I don't think we made any special changes in this area
[12:48] <igc> bialix: I can't find that version check. Maybe we moved it?
[12:48] <timour> Hi all, can someone suggest how to disable commit emails in a specific repository?
[12:49] <bialix> igc: perhaps I've confused it with the check in qbzr itself
[12:49] <timour> Specifically, I use etc-keeper with Bazaar, and I don't want commits in etc to be sent to the mailing list of my project.
[12:50] <bialix> timour: do you have enabled mails in bazaar.conf?
[12:50] <bialix> timour: take a look at locations.conf
[12:50] <timour> bialix, yes
[12:50] <bialix> the best place to enable things by directory level is locations.conf
[12:50] <timour> bialix, so this is the config file where one can specify for what local repositories to send commit emails?
[12:51] <bialix> igc: qbzr has check which insist we need bzrlib api >= 1.17
[12:51] <timour> bialix, is this file in .bazaar?
[12:51] <bialix> timour: yes
[12:51] <timour> bialix, thanks a lot!
[12:51] <bialix> check the docs on config files
[12:52] <igc> bialix: what about the progress monitoring changes made in 2.1?
[12:52] <bialix> I don't know
[12:52] <bialix> I did not touch the code, garyvdm too. It seems we don;t support this feature yet
[12:52] <bialix> of course Gary may know better
[12:58] <igc> bialix: I thought garyvdm made some changes following poolie's changes to bzr core. Maybe none were needed?
[12:59] <bialix> I cant say right now
[13:22] <igc> bialix, re bug 517036, please try rev 409
[13:23]  * bialix pulling
[13:24] <bialix> igc: fixed now
[13:24] <bialix> thx
[13:24] <igc> bialix: what does your toolbars.xml file look like?
[13:27] <bialix> igc: now http://pastebin.com/m336afd8a
[13:27] <bialix> I've removed it hour ago, this one created by explorer I suppose
[13:28] <igc> bialix: yes, it will create one if missing
[13:28] <igc> bialix: any other files just creaed there for you?
[13:28] <igc> created
[13:28] <bialix> checking with empty one now
[13:29] <bialix> igc: if the file has size of 0 bytes it's not re-created with valid content then
[13:29] <igc> bialix: right. It was the Unicode Error that was giving your a zero length file though :-(
[13:30] <bialix> igc: http://pastebin.com/d68d7eac5 this is the files created if I remove explorer dir
[13:31] <igc> bialix: that looks good to me
[13:31] <bialix> ok
[13:31] <poolie> hi all
[13:31] <vila> poolie: hey
[13:31] <vila> poolie: It http://paste.ubuntu.com/368802/  less magical with that comment ?
[13:32] <vila> poolie: I said earlier: I can delete the all the deprecated features if you want or keep only the ApportFeature one, we have a test covering the CompatibilityFeature thunk anyway,
[13:33] <vila> regarding ApportFeature, I doubt anybody had the opportunity to use it...
[13:33] <bialix> heya poolie
[13:40] <poolie> vila, a bit less magical
[13:40] <poolie> i was suggesting removing just ApportFetaure
[13:40] <poolie> but either is fine
[13:40] <vila> oh, ok, I'll tweak and merge then
[13:40] <poolie> it was more just a  general comment about not doing too much work in deprecation
[13:41] <poolie> i'll try to read your merge rfc and patch
[13:41] <poolie> not sure when i will get uninterrupted time
[13:41] <vila> poolie: ok, thanks
[13:42] <poolie> yo ucan nag jam or igc
[13:43] <vila> for the conflict handling one ? That's what my last comment was, wasn't it ? :D
[13:43] <vila> oh, silly me, you can't see that, they are CCed
[13:46]  * bialix -> lunch
[13:51] <vila> gorgeous, clicking on the bug link in qlog opens my browser, nice one bialix/garyvdm
[13:54] <bialix> it was luks
[13:55] <bialix> something bad with lp right now
[13:55] <vila> bialix: yup, oopsing all over the place :-/
[13:55]  * bialix goes outside
[13:56] <poolie> srsly?
[13:56] <poolie> vila, which page?
[13:57] <poolie> escalate it if it's persistent
[13:57] <vila> poolie: just checked, mthaddon is restarting apps servers
[13:58] <vila> They oops look like timeouts to me since refreshing succeed half of the time
[14:05] <ddaa> Hello there
[14:06] <ddaa> the rebase plugin works well to rebase to a newer version
[14:06] <ddaa> but I cannot find how to make it rebase to an older version
[14:07] <ddaa> my use case is backporting an independent patch that was committed on a feature branch
[14:07] <ddaa> How can I backport one or several patch while preserving committer, date, etc, like rebase does?
[14:10] <vila> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc1 and 2.0.4 have gone gold
[14:10] <vila> bah
[14:11] <vila> meh, I can't change the topic anymore ? When did that occur ?
[14:18] <poolie> ddaa, sorry, i don't know, it sounds like a bug/limit in bzr-rebase
[14:19] <ddaa> hey poolie
[14:19] <poolie> hi there
[14:20] <poolie> vila, i'm nervous of landing such a large patch to 2.1
[14:20] <poolie> also i can't understand your comment that
[14:20] <poolie> ... oh, i see, you're saying it's too late to add testtools as a dependency
[14:20] <poolie> and it is
[14:21] <vila> yeah, but the patch isn't large, it's only because a lot of code has been moved, but I didn't change the moved code
[14:21] <jelmer> ddaa: bzr replay should be able to do that
[14:21] <poolie> right
[14:22] <ddaa> jelmer: I tried tying that on the command line, and I looked on the bzr plugin guide, http://doc.bazaar.canonical.com/plugins/en/index.html, and I did not see any "bzr replay".
[14:22] <ddaa> oops
[14:22] <vila> poolie: well, I can understand the feeling about SRU, but almost nothing has been changed in the "code" most of the patch is related to the tests
[14:22] <ddaa> actually, it works on the command line
[14:23] <ddaa> jelmer: thanks jelmer, sorry for the noise
[14:23] <jam> morning all
[14:23] <jelmer> ddaa: np
[14:23] <vila> morning jam http://instantrimshot.com/
[14:24] <poolie> vila, did you see igc's mail asking jam to delay the rc?
[14:24] <vila> no :-(
[14:24] <poolie> so i think this should be ok for this too
[14:24] <jam> poolie: well, to do an rc3 today, and to delay final to next week, yes
[14:24] <jam> jelmer: something is wrong with lp:bzr-rewrite
[14:24] <jam> it points to:
[14:24] <jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
[14:24] <jam> which points to http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred
[14:24] <jam> but that branch doesn't exist
[14:24] <jam> http://people.samba.org/bzr/jelmer/bzr-rebase/trunk does
[14:24] <poolie> jam, well, specifically after bzr-explorer works
[14:25] <jam> so lp:bzr-rewrite doesn't have 0.5.5 available
[14:25] <poolie> s/works/releases 1.0
[14:25] <poolie> jam/igc "Updated Bazaar 2.1.0 release plane"
[14:26] <poolie> plaan*
[14:26] <poolie> plan*
[14:26] <poolie> laggy connection
[14:26] <fullermd> Hm.  There isn't a bzrtools release to match 2.1 yet either.
[14:26] <jelmer> jam: http://people.samba.org/bzr/jelmer/bzr-rebase/trunk-mirrorred exists here
[14:26] <jam> I'd rather a release plane ...
[14:26] <jam> hmm.. I was spelling it with 1 too few r's :)
[14:27] <jam> however, the launchpad branch is still unhappy
[14:27] <jam> Next Mirror: Disabled
[14:27] <jam> https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred
[14:27] <jelmer> I wished launchpad did exponential backoff on failures
[14:27] <poolie> on import failures?
[14:28] <jam> this was a mirror failure
[14:28] <jam> probably had a 1 day outage, and got 5 hiccups in a day
[14:28] <jelmer> poolie: mirror and import failures
[14:29] <jelmer> jam: strangely enough I don't seem to have the authority to reenable the mirror
[14:29] <vila> anybody knows how to change the topic ?
[14:29] <jam> jelmer: neither do I
[14:29] <jam> vila:  /topic ?
[14:29] <poolie> jelmer: you should file a bug for the lack of ability to do that
[14:29] <jam> I use pidgin and just double click
[14:29] <jam> which opens a dialog
[14:29] <poolie> vila, i'll try
[14:29] <poolie> what do you want to add to it?
[14:29] <jam> poolie: he's the PP this week
[14:30] <vila> jam: I tried that but got : #bzr :You're not channel operator
[14:30] <vila> poolie: s/igc/vila/ for pp
[14:30] <jam> vila: I just got the same
[14:30] <jam> that hasn't ever happened before
[14:30] <vila> I was wondering if things have changed because of the recent storms
[14:30] <jam> I wonder who locked down topics to only ops
[14:30] <jam> Looking at the list, I don't think I see any ops ... ?
[14:30] <maxb> I think it might have happened as part of the ircd upgrade
[14:31] <fullermd> Maybe it was just fallout from the ircd change.
[14:31] <vila> -Martinp23- Hi everyone. We've disabled the +S chanmode for the time being. Normally, +S blocks users from joining a channel if they aren't connecting with SSL. If you still see +S in your channel's modelist, it will have *no effect*. For the now, you will be unable to add or remove this mode. We'll have a more permanent resolution asap. We're sorry for the inconvenience caused by our earlier technical difficulties.
[14:32] <vila> on 31/01 1:54
[14:32] <fullermd> Yeah, but it's [probably] the +t that's in effect here.
[14:33] <maxb> yes
[14:33]  * fullermd has a dream that someday there will be an ircd that actually _documents_ all its stuff...
[14:34] <maxb> abentley can op people. lifeless can bestow that ability upon others
[14:35] <vila> maxb: where did you get that info ? 8-)
[14:35] <maxb>  /msg chanserv access #bzr list
[14:36] <maxb>  /msg chanserv help flags  -- for the definitions of the various privilege flags
[14:40] <vila> ok, so someone on the access list just needs to /mode -t
[14:40] <vila> abentley, lifeless: ^
[14:40] <alf__> Hi all, I accidentally pushed a series of revisions to a (local) branch. Is there a way to remove those revisions from the branch?
[14:41] <vila> alf__: push --ovwrwrite
[14:41] <vila> alf__: push --overwrite
[14:41] <vila> grr
[14:41] <jml> poolie, http://robertcorr.com/2010/02/afact-v-iinet/
[14:42] <alf__> vila: What should I push?
[14:43] <vila> alf__: you tell me :D
[14:43] <vila> alf__: the revision you want to be the tip of your remote branch
[14:43] <alf__> vila: Yes ok, let me be more clear :)
[14:44] <vila> alf__: if the branch is local, you can just go there and : bzr pull -r<the_good_one> --overwrite
[14:44]  * vila applauses abentley
[14:45] <abentley> Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: igc | bzr 2.1.0rc1 and 2.0.4 have gone goldd
[14:45]  * vila applauses abentley
[14:46] <alf__> vila: Ah, yes that is what I was looking for, thanks!
[14:46] <poolie> hi abentley
[14:46] <bialix> hi jam
[14:46] <abentley> poolie, hi.
[14:57] <gerard_> hey
[14:58] <rubbs> gerard_: hello
[15:00] <gerard_> anyone has some time to review https://code.launchpad.net/~gerard-/bzr/update/+merge/18464 ?
[15:00] <gerard_> vila perhaps?

[15:01] <vila> gerard_: Just got promoted patch pilot, I'm cleaning up the easy bits first and will have a look
[15:01] <vila> gerard_: thanks for your patience
[15:02] <fullermd> poolie: "update --2a"?
[15:03] <vila> fullermd: upgrade ?
[15:03] <fullermd> I dunno which part of it he meant...
[15:03] <gerard_> vila: that's ok
[15:04] <gerard_> I just noticed the unused local "update_dash_r", don't mind that, will remove it tonight
[15:07] <jam> fullermd: I think he actually needs to do 'reconcile' (though just of the branch), but I'm sort of staying away for now
[15:20] <maxb> Yikes. branching a 2a branch locally without stacking or a shared repository feels slower than branching it over the network :-(
[15:56] <doctormo> Hmm, I'm trying to work out why the cmd_revert in builtins is one of the few commands to not accept a directory input.
[15:57] <doctormo> I presume it's because it uses tree_files(..) with default_branch instead
[16:16] <doctormo> how do I use bzr to remove all unknown files?
[16:22] <mzz> doctormo: see "bzr help clean-tree"
[16:31] <doctormo> thanks mzz, worked like a charm
[16:48] <poolie> igc i hope you didn't get up this early for my sake
[16:49] <igc>  poolie: I'm about to grab some sleep actually. Getting up is planned for 6 hours from now :-)
[16:50] <poolie> ok :)
[16:54] <igc> night all
[16:55] <rubbs> night
[16:55] <poolie> night
[17:00] <lifeless> moin moin
[17:19] <jam> lifeless: /wave
[17:19]  * jam away to lunch
[17:19] <mkanat> james_w: You mentioned the other day that it wouldn't be too hard to get *one* point where a revision was merged in. What about getting *all* the points? Does that require graph walking?
[17:20] <lifeless> mkanat: yes
[17:20] <mkanat> Okay.
[17:20] <lifeless> revsions point at parents. merged-in is children
[17:21] <mkanat> Yeah.
[17:21] <mkanat> And merge_sort is the only thing that will tell me where those children show up, right?
[17:22] <lifeless> merge_sort is the sort we use for log
[17:22] <lifeless> if you want revnos you need to use it (directly or indirectly)
[17:23] <vila> lifeless: /wave
[17:24] <vila> lifeless: what kind of dependency should be used for testtools in the bzr package ?
[17:37] <mkanat> lifeless: *nod* And it's also the only built-in way to find out where a revision was merged in, right, other than walking the entire graph myself?
[17:40] <lifeless> vila: arch independent  build depends
[17:40] <lifeless> mkanat: no, there are iterators on branch and so forth
[17:42] <mkanat> Oh, yeah, I see iter_merge_sorted_revisions.
[17:42] <gerard_> hey
[17:54] <gerard_> vila: need any help with the simple stuff?
[19:12] <beuno> http://blog.digital-scurf.org/2010/02/04#comparative-publishing
[19:12] <beuno> \o/
[19:23] <MvG> http://doc.bazaar.canonical.com/bzr.dev/developers/plugin-api.html#metadata-protocol states that bzr_plugin_version should be "a version_info 5-tuple". Does that imply any restrictions on its format? Is there a relation with http://docs.python.org/library/sys.html#sys.version_info ? Not all plugins seem to follow the latter format, is that OK for new plugins as well?
[19:25] <Peng> MvG: The restriction I know of is that it shouldn't make bzrlib._format_version_tuple() throw an exception. :P
[19:28] <MvG> Peng: thx
[20:29] <mwhudson> jelmer: ayt?
[20:51] <maxb> I'm trying to locate the code that is responsible for post_change_branch_tip firing conditional on whether the tip actually changed when doing a "bzr pull", but firing unconditionally with a "bzr pull --overwrite" - can anyone help?
[20:53] <maxb> ah, I think I've found it. GenericInterBranch.update_revisions
[20:58] <mwhudson> mkanat: the revid_to_revno map is definitely not small enough to cache in memory for many branches :(
[20:59] <mkanat> mwhudson: 100,000 revisions, that's going to be...what, maybe 512K of RAM?
[20:59] <mkanat> Well, maybe more.
[20:59] <mkanat> Maybe a few MB.
[21:00] <mwhudson> and loggerhead can examine a few thousand branches...
[21:00] <mkanat> mwhudson: We already are caching it in memory.
[21:00] <mwhudson> mkanat: only 10 at a time
[21:00] <mkanat> mwhudson: Fair enough.
[21:00] <mkanat> mwhudson: But still, we could move the caching to the branch object.
[21:00] <mkanat> mwhudson: And historycache.
[21:01] <mwhudson> mkanat: loggerhead _used_ to cache a lot more in memory, and stopping it doing that helped the memory footprint immensely
[21:01] <mkanat> mwhudson: I can imagine. :-)
[21:01] <mkanat> mwhudson: I'm actually proposing that we cache less than we do now, BTW.
[21:01] <mkanat> (Except my bit about the 100 branches.)
[21:01] <mwhudson> i think using historycache makes a lot of sense though
[21:02] <mwhudson> mkanat: also
[21:02] <mwhudson> I imagine
[21:02] <mwhudson> it'd be fairly safe to use the same branch object across all our
[21:02] <mwhudson> threads.
[21:03] <mwhudson> that sentence doesn't give warm fuzzy thoughts
[21:03] <mkanat> mwhudson: Right, I was wondering about that. :-)
[21:04] <mkanat> mwhudson: One possibility is to put locks around the places that aren't thread-safe.
[21:04] <mkanat> mwhudson: One of the things I'm also trying to accomplish is building the caches lazily.
[21:05] <mkanat> mwhudson: Because, for example, we don't need them at all to display ChangeLogUI, but they're built anyway, because we called History()
[21:05] <Peng> With modern disk formats, how much does Loggerhead still need the caching?
[21:05] <Peng> s/disk/repo/
[21:05] <mwhudson> mkanat: +1 on that
[21:05] <mkanat> Peng: I'm actually not sure.
[21:05] <mwhudson> Peng: sorting the revision graph is still slow
[21:05] <mkanat> Oh, yes, that is needed.
[21:05] <mkanat> I am sure about that.
[21:05] <Peng> How often does it really need the whole revision graph?
[21:05] <mkanat> I did some testing--it takes about 4 seconds to run through iter_merge_sorted_revisions on a loggerhead devel branch.
[21:06] <mkanat> Peng: That's exactly what I just researched.
[21:06] <mkanat> Peng: It only needs it when it has to know where a revision was merged in or from.
[21:06] <mkanat> Peng: So even if we just built the current cache lazily, we'd reduce building that part of the cache to RevisionLogUI and RevisionUI.
[21:08] <mkanat> mwhudson: The only thread-unsafe thing I can imagine about using a branch read-only would be its internal caches.
[21:08] <mkanat> mwhudson: Though of course there could be other things I don't know about.
[21:08] <mwhudson> mkanat: i don't have any specifc worries
[21:08] <Peng> mkanat: <3
[21:08] <mwhudson> mkanat: just general ones :-)
[21:08] <mwhudson> maybe it would be fine
[21:09] <Peng> Yeah, "maybe it would be fine" in regards to thread safety _always_ ends well. ;P
[21:09] <mkanat> mwhudson: Okay. But if we find out that it isn't, instead we can build those three simplified caches that I mentioned on-demand, instead of whenever we instantiate a History.
[21:12] <maxb> What's the most lightweight way to ask bzrlib "Is this specific directory a branch?"
[21:13] <mkanat> maxb: I think Branch.open?
[21:13] <Peng> But that isn't necessarily lightweight, e.g. if it's a branch reference to a remote location, or maybe even a lightweight checkout.
[21:14] <mkanat> maxb: You could check if it has a .bzr first, right?
[21:14] <maxb> yeah, probably not worth that much code
[21:15] <maxb> find_branches is out, because I want not to recurse
[21:15] <mkanat> Yeah. Although I suppose that directory could be a repo, too, if it just has a .bzr in it.
[21:15] <Peng> I've checked for .bzr/branch in the past, but it's evil.
[21:16] <mwhudson> mkanat: yeah
[21:16] <mkanat> Maybe BzrDir.open_branch? I dunnow.
[21:16] <maxb> Ironically the reason I'm caring is because the existing code is finding git repositories that I don't want, since bzr-git is installed :-)
[21:16] <mkanat> mwhudson: Okay. So I'll update the bug with that proposal.
[21:16] <Peng> maxb: :D
[21:17] <Peng> maxb: I'm sure it's possible to work around that, but I dunno how. You can check for some property of foreign branches that doesn't apply to real bzr branches.
[21:19] <Noldorin> hi jelmer
[21:19] <mkanat> mwhudson: With that adjustment, does the rest of the plan sound like what we want to do?
[21:21] <maxb> What's the right API to turn a local pathname into an URL for Branch.open(...) ?
[21:24] <mkanat> maxb: I've always just passed in the local pathname.... :-)
[21:28] <Peng> maxb: IIRC there's something in urlutils, but if passing the local pathname works, just do that.
[21:28] <Peng> If you don't care about errors caused by directories actually called "bzr+ssh" or whatever. :D
[21:34] <mwhudson> urlutils.local_url_to_path
[21:34] <mwhudson> er
[21:35] <mwhudson> *from_path
[22:18] <mkanat> mwhudson: Did you see my question above?
[22:21] <mwhudson> mkanat: i think it sounds reasonable, yes
[22:22] <mkanat> mwhudson: Okay, cool.
[22:27] <knapsack> So my index is corrupt and I'd like to rebuild or repair it.
[22:28] <knapsack> Unfortunately even the results of 'bzr dump-btree' on the indices aren't usable: bzr: ERROR: No such file: u'/home/knapsack/new/.bzr/repository/indices/e5041e9b52c7ccc987767381885f62eb.rix': [Errno 2]
[22:29] <knapsack> Apparently this is referred to in the pack-names file, but doesn't exist. The repository itself is in a Dropbox folder, so may have been modified.
[22:30] <knapsack> The answer at https://answers.launchpad.net/bzr/+question/96346 hasn't helped me, since I can't create any branches.
[22:30] <knapsack> Any way for me to recover from this?
[22:32] <lifeless> perhaps the file is in your dropbox history ?
[22:32] <knapsack> Wow, lessee.
[22:38] <knapsack> That worked.
[22:38] <knapsack> Ever feel kind of embarrassed, but relieved and thankful at the same time?
[22:38] <lifeless> Glad I could help
[22:38] <lifeless> when you're in a crisis outsiders can often offer useful suggestions :)
[22:38] <knapsack> lifeless: Absolutely. Thanks lifeless!
[23:09] <lifeless> spiv: bug 517275 would be lovely to fix for james_w
[23:15] <spiv> lifeless: I'll take a look, sounds like my sort of thing :)
[23:19] <mneptok> ugh. "fragile cleanups" reminds me i need to make a dentist appointment.
[23:24] <lifeless> oh spiv, did I show you testrepository? I think you might have been on leave when I announced it
[23:25] <spiv> lifeless: I think you mentioned it at least, although I haven't taken a look
[23:27] <lifeless> spiv: ok, c ool


[00:34] <RAOF> Hm.  How can I take a bug off the QA sponsoring list?  Bug #644644 has had it's gstreamer task sponsored, but there's still a valid pulseaudio task up, and that doesn't have a sponsoring candidate.
[00:43] <broder> RAOF: just unsubscribe -sponsors
[00:44] <broder> (if you're not in the group, i can do it, but you should ping persia and ask him to add you)
[00:44] <RAOF> broder: Ta.
[01:11]  * persia isn't the *only* admin of -sponsors, but is always happy to add folk
[01:13] <ari-tczew> +1 ^^
[01:13] <ari-tczew> IIRC dholbach and kees as well
[01:14] <RAOF> Piloting will me a more rewarding experience in core-dev :/
[01:14] <s0ullight> when will support for the newer elan smartpad be added?
[01:14] <ari-tczew> RAOF: is that wrong?
[01:15] <lifeless> RAOF: l2english?
[01:15] <RAOF> lifeless, ari-tczew: Like you can't mentally translate a bistaken 'm' :)
[01:15] <lifeless> RAOF: haha
[01:16] <ari-tczew> RAOF: I guess while reading s/me/be
[01:19] <persia> RAOF, For those you can't sponsor, if they look generally useful, consider helping them get upstream, which may be almost as satisfying if they land.
[01:19] <RAOF> Yeah, when that's appropriate.
[01:27] <RAOF> If a core-dev would like to sponsor http://cooperteam.net/Packages/mtdev_1.1.0-0ubuntu1_source.changes I'd appreciate it :)
[01:27] <lifeless> Hobbsee: don't suppose you're on irc atm ?
[01:27] <RAOF> And I'm sure the ubuntu-touch team would appreciate it, too :)
[02:15] <RAOF> @pilot out
[04:45] <jdong> have I heard correctly that Keybuk is (already? going to be?) in Mountain View?
[04:51] <psusi> Mountain View?
[04:52] <micahg> psusi: MOuntain View is Google HQ
[04:52] <psusi> ahh
[04:54] <RAOF> jdong: Yes; already.
[04:55] <jdong> RAOF: ah cool. I'
[04:55] <jdong> ll have to look him up for a beer or something :)
[07:26] <broder> jdong: wait, are you still out here?
[07:26] <jdong> broder: out here? where's here?
[07:27] <broder> bay area
[07:27] <jdong> yeah, moved out here for good (for now) :)
[07:27] <jdong> accepted a job at evil fruity world ;-)
[07:27] <broder> sweet. i think i thought you were grad schooling or something
[07:27] <jdong> you're still in the bay area too?
[07:27] <broder> we should totally catch up for a beer at some point
[07:27] <broder> yeah
[07:28] <jdong> neat!
[07:28] <jdong> yeah, definitely
[07:28] <jdong> yeah, I still plan on grad school in the near future. But for now a job is a refreshing change
[07:28]  * broder knows the feeling
[07:28] <jussi> cripes, its a jdong!
[07:29]  * jussi waves
[07:29] <jdong> hey :)
[07:29] <jussi> not seen you around for a while - do fruity companies block irc? :D
[07:29] <jdong> no they don't, actually
[07:29] <jdong> just my busy nature has inhibited IRC :)
[07:30] <jussi> Ahh, fair enough.
[07:30] <jussi> good to see you are still kicking though :)
[07:30] <jdong> haha thanks :)
[07:30] <jdong> still adjusting to this silly time zone though
[07:30] <jdong> getting ready to go to bed at 11:30!
[07:30] <jussi> lol
[07:31] <jussi> anyway, its like 9.30 am here, and I should really go do work...
[07:31] <dholbach> good morning
[07:39] <pitti> Good morning
[07:40] <RAOF> Oh, oh!  It's pitti!
[07:40] <RAOF> Good morning pitti  :)
[07:41] <pitti> kees: are you sure that the gdm uid patch is still required? the logic which users to filter out should be much better now; but if you have a ported patch for the current gdm, please go ahead and commit it
[07:42] <pitti> hey RAOF, how are you?
[07:42] <RAOF> pitti: I'm ok.
[07:43] <RAOF> I'm discovering some stupidity in thinking that builds == works, though :/
[07:43] <RAOF> On the plus side, this is in the pre-upload testing, so no-one need know!
[07:44] <micahg> hi pitti, I wanted to ask about Thunderbird for natty alpha 2, would it be better to have it be updated to 3.1.8 on arm, but w/out Breakpad enabled (submit crashes to Mozilla) (not parity with i386/amd64) or leave it at 3.1.7?  There might be the other option of actually fixing breakpad, but idk if that can happen before alpha 2
[07:51] <pitti> micahg: my gut feeling is to update without breakpad, but ogra_'s or persia's opinion here is more important
[07:52] <micahg> pitti: I"ll check with chrisccoulson as well either before I go to sleep or when I wake up (and might find it mysteriously fixed :))
[08:11] <didrocks> good morning
[08:12] <JackyAlcine> Morning, didrocks.
[08:12] <didrocks> hey JackyAlcine
[08:29] <pitti> bonjour didrocks
[08:30] <didrocks> Guten Morgen pitti :)
[08:52] <DktrKranz> mvo: hi! during weekend I spent some time doing gdebi bug triage, and noticed you were working on gio support (lp:~mvo/gdebi/gio). Do you think it's functional enough to be merged, or does it need polishing?
[08:52] <mvo> DktrKranz: thanks for the triage :) there was/were issues with gio, but I don't remember the details, let me look at the code again (its been a while)
[08:54] <janimo> @pilot in
[08:55]  * micahg waves to janimo
[08:55] <mvo> DktrKranz: one problem was that gio will not support remove downloads as root. that should be fine most of the time (as we run as user by default) though
[08:56] <DktrKranz> ah, yeah
[08:57] <janimo> micahg, hi
[08:58] <micahg> janimo: hi, we've got another failure on thunderbird on ARM, I was looking for the ARM xulrunner tree to see if anyone fixed it, but it seems to no longer exist
[08:58] <janimo> micahg, those fixes are easy, I saw that too, I'll provide a patch today - not debidff though
[08:58] <janimo> I wonder though why mozilla keep adding asm code :)
[08:59] <micahg> janimo: awesome, thanks
[08:59] <micahg> janimo: we enabled a new module (breakpad)
[09:00] <janimo> ah, makes sense
[09:02] <mvo> DktrKranz: nice work on trunk btw, many thanks :)
[09:17] <DktrKranz> mvo: thanks, I plan to commit a couple of things, then upload and sync in natty
[09:22] <mvo> DktrKranz: sounds good to me,  I play a little bit with the gio stuff in the meantime
[09:25] <DktrKranz> mvo: cool, thanks!
[09:32] <mvo> DktrKranz: could you merge the gio branch to trunk and play a bit with it? it should be good now
[09:33] <ogra_> mvo, any chance that we get a working update-manager soon so we can build non x86 images again ?
[09:33] <ogra_> (why is it depending on fglrx-modaliases ?)
[09:37] <janimo> micahg, so mozilla will  not report via apport? How do apport and breakpad get along?
[09:37] <micahg> janimo: apport should be blacklisted if breakpad is enabled
[09:37] <janimo> ok
[09:38] <micahg> janimo: you should still be able to use ubuntu-bug though to report non-crashes
[09:38] <janimo> micahg, does the mozilla team upstream patches (I am thinking of the arm ones in particular)?
[09:38] <micahg> janimo: we should be :)
[09:39] <janimo> micahg, ok. There's no easy way I know of - short of looking at he buglist and upstream resources - what the status of various packages is wrt upstreaming
[09:40] <micahg> janimo: generally I think we do, occasionally one slips through the cracks
[09:44] <mvo> ogra_: yes, on my list for today :) its a quirk handler because fglrx used to drop support for older cards so we like to tell users (and transition them)
[09:44] <ogra_> ah
[09:44] <ogra_> great, thanks
[09:53] <cjwatson> broder: thanks for pushing the libpipeline backport :-)
[10:04] <\sh> guys, who is responsible for upstart in ubuntu right now?
[10:05] <micahg> \sh: I think jhunt is working on it
[10:06] <\sh> micahg: thx...I'll get in touch with him...looks like we still have problems with upstart + virtual nic interfaces
[10:07] <micahg> \sh: bug 678425?
[10:09] <\sh> micahg: nope, this looks just like the reporter is not following the exmaple of ifenslave for new upstart behaviour
[10:10] <\sh> micahg: it's more : bond0 -> slaves eth0 eth1 -> mode 4 / bond1 -> slaves eth2 eth3 -> mode 4 <- those are available, and now you device a bond2 -> slaves bond0 bond1 and bond2 doesn't work
[10:11] <micahg> \sh: way too late at night for me to follow that :)
[10:12] <\sh> micahg: hehe...I can imagine that...
[10:14] <DktrKranz> mvo: sure, I'll have a go this eve
[10:16] <\sh> micahg: I commented on bug #678425
[10:17] <cjwatson> smb,sconklin-gone: we need an urgent upload for bug 709694, IMO, because now lucid-updates has regressed for people with the backports modules installed
[10:20] <\sh> cjwatson: don't know if you are the right man for initramfs-tools, but the correct fix for bug #415353 is now in initramfs-tools 0.98.8 in unstable...we should take a look at it and eventually push that to natty
[10:24] <cjwatson> \sh: yes I'm going to do that this week
[10:24] <cjwatson> maks already asked me about it
[10:25] <cjwatson> pitti: given that you removed the fglrx-modaliases package, do you have an idea for how to make update-manager not dep-wait on it in natty?
[10:25] <\sh> cjwatson: cool...thx :)
[10:25] <pitti> cjwatson: oh, I'll look into it and discuss with mvo
[10:25] <pitti> sounds like an obsolete workaround anyway
[10:26] <ogra_> cjwatson, see above, mvo said he'd work on it today
[10:26] <cjwatson>   * DistUpgrade/DistUpgradeQuirks.py:
[10:26] <cjwatson>     - add detection for cards no longer supported via fglrx
[10:26] <cjwatson>       and ensure transition to "ati" (LP: #284408)
[10:26] <cjwatson> ogra_: ah, thanks
[10:26] <cjwatson> I missed that
[10:26] <pitti> mvo: do we still need that? would it help if I send you a snippet of code which determines the vendor/product IDs in the new "package header" world?
[10:27]  * ogra_ grumbles at freenode
[10:27] <Tm_T> ogra_: that's not freenode's fault (:
[10:28] <ogra_> Tm_T, that my nick gets cked for 2h if i nistype my PW ?
[10:28] <ogra_> *mis
[10:28] <Tm_T> ogra_: I believe you have turned on nick-guard
[10:28] <ogra_> *locked ...
[10:28] <ogra_> i havent turned on anything
[10:29] <ogra_> i'm using IRc like i do since 8 years
[10:29] <Tm_T> hmm, interesting, it shouldn't force nick-change without the nick protection
[10:29] <ogra_> if i mistype my pw and am not fast enough to retype in time i get a Guest account
[10:29] <ogra_> after that my nick is locked for about 2h
[10:30] <Tm_T> haven't heard of locks before
[10:30] <ogra_> * ogra :Nick/channel is temporarily unavailable
[10:30] <ogra_> thats what nickserv replies
[10:30] <Tm_T> ogra_: you can still identify
[10:31] <ogra_> i cant change my nick, so no
[10:31] <Tm_T> ogra_: /msg nickserv identify <account> <password>
[10:32] <ogra_> yes, that works, but i cant change my nick
[10:32] <Tm_T> as identified?
[10:32] <ogra_> yes
[10:32] <ogra_> same message as above
[10:32] <Tm_T> what happens if you try to ghost that nick?
[10:33] <ogra_> -NickServ- ogra is not online.
[10:33] <ogra_> :P
[10:33] <Tm_T> interesting
[10:33] <Tm_T> -NickServ(NickServ@services.)- ogra has enabled nick protection
[10:33] <ogra_> well, i'll live with the tail for 2h
[10:34] <Tm_T> ogra_: you might like to group that tailed nick to your account too (:
[10:34] <ogra_> to have that locked as well ?
[10:34] <ogra_> no, thanks :)
[10:35] <Tm_T> ogra_: well, now someone else can register it
[10:36] <ogra_> nobody has in the last years ... and i still own the toplevel
[10:36] <Tm_T> true
[10:36]  * cjwatson looks sideways at http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html
[10:36] <ogra_> i like to have a working fallback
[10:36] <cjwatson> we're producing an alpha this week, right? :-(
[10:38] <ogra_> cjwatson, armel looks worse than it is for images
[10:38] <ogra_> we only miss u-m currently afaik
[10:38] <cjwatson> ogra_: I was actually mostly looking at x86
[10:38] <ogra_> ah
[10:44] <geser> cjwatson: a binary promotion of "libsmokebase3" should resolve the "libsmoke*" ones (kdebindings)
[10:47] <cjwatson> geser: thanks, will poke at component-mismatches
[10:47] <cjwatson> there's a qscintilla2 rebuild needed too
[10:51] <JackyAlcine> Is NAS (Network Audio System) is shipped with Ubuntu?
[10:51] <JackyAlcine> Qt seems to rely on it.
[10:59] <cjwatson> Riddell: I've uploaded qscintilla2 to fix its sip-api-* dependency - hopefully it still works
[11:00] <jibel> ev: Hi, can you look at bug 710582, looks like a webkit bug rather than ubiquity.
[11:00] <cjwatson> Riddell: is somebody working on the kdebindings FTBFS on armel?
[11:01] <ev> jibel: ugh, it seems like we get these once a cycle.  Sure, will do.
[11:01] <jibel> ev: thanks
[11:08] <Riddell> cjwatson: I can't work out the problem (it's failing to typecast double as qreal). I've pinged upstreams who havn't so far helped
[11:09] <ev> jibel: I've followed up on the bug
[11:10] <cjwatson> Riddell: maybe I should work my way through the problems I'm more likely to be able to solve then ;-)
[11:38] <JackyAlcine> When will Ubuntu replace X for Wayland?
[11:51] <cjwatson> RAOF: I just uploaded xserver-xorg-input-evdev to fix a udeb dependency problem which was showing up in component-mismatches.  I don't suppose you could sync that upload into wherever x-s-i-e is maintained?
[11:59] <RAOF> cjwatson: Yeah, ok.
[11:59] <cjwatson> Riddell: qtmobility 1.1.0-0ubuntu3 removed libqtmessaging1, I think, but qtmobility-dbg still seems to depend on it?
[11:59] <cjwatson> RAOF: thanks
[12:00] <cjwatson> ... and I think that should be the last of the x86 uninstallables
[12:00] <cjwatson> JackyAlcine: http://www.markshuttleworth.com/archives/551 is the most authoritative answer to that I know of
[12:01] <bdrung> cjwatson: re libkibi: it wasn't as easy as i assumed. https://bugzilla.gnome.org/show_bug.cgi?id=640432
[12:01] <Riddell> cjwatson: ok I'll look at that along with the arm build failures of qtmobility today
[12:01] <cjwatson> Riddell: thanks
[12:02] <cjwatson> bdrung: well, I'm not hugely surprised, but we can't leave the c-m status the way it is forever
[12:02] <bdrung> cjwatson: c-m?
[12:02] <cjwatson> bdrung: we could demote it and bump the MIR bug back to Fix Committed pending app changes?
[12:02] <cjwatson> bdrung: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[12:02] <JackyAlcine> Fantastic, cjwatson.
[12:02] <bdrung> cjwatson: i'll can start to port non-glib C programs.
[12:05] <RAOF> cjwatson: Ah, I guess -evdev hasn't been published yet?  I'll leave that for Bryce then.  Time for me to hit the sack :)
[12:07] <mvo> pitti: I'm working on that now, it should be fine
[12:08]  * pitti hugs mvo, danke
[12:09] <cjwatson> RAOF: not quite.  https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.6.0-1ubuntu3
[12:13] <om26er> hey janimo
[12:13] <janimo> om26er, hello
[12:13] <om26er> janimo, could you please sponsor https://code.launchpad.net/~om26er/ubuntu/natty/totem/totem-fix-647607/+merge/47903
[12:13] <jibel> ev: I'll submit the bt after lunch. In the mean time I caught another blocker but this time on Kubuntu bug 710612 . Looks like a problem with debconf.
[12:13] <janimo> om26er, looking
[12:16] <janimo> om26er, have you built this and it works?
[12:17] <om26er> janimo, I have not build since it seemed like a one line fix, should I now, will take a few minutes if you say
[12:18] <janimo> om26er, ok, just to make sure, please do, thanks
[12:18] <janimo> since you know the best how to test if it indeed fixes the bug
[12:22] <mvo> pitti: what does a line with multiple seperators in modaliases looks like? i.e. what is the seperator? Modaliases: fglrx(..), fglrx2(..) ?
[12:22] <mvo> pitti: in the Packages header
[12:22] <pitti> mvo: right, modulename(alias, alias, ...), modulename(alias, ...), ...
[12:22] <mvo> ok, thanks
[12:23] <cjwatson> jibel: it's rare for such things to be a problem with debconf, just as compiler errors are rarely a problem with gcc
[12:24] <pitti> mvo: http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/view/head:/jockey/oslib.py#L716 is what jockey uses
[12:24] <cjwatson> FYI
[12:24] <mvo> thanks pitti
[12:25] <bdrung> mvo: bug #710618 - that's the try to comply to ubuntu's units policy
[12:26] <bdrung> mvo: libkibi is in NEW in Debian
[12:26] <mvo> bdrung: thanks, I have a look. also I tend to be very reluctant to add dependencies to libapt
[12:27] <bdrung> mvo: libkibi is very small for that reason
[12:28] <mvo> pitti: hm, the old modalias files had a "xorgdriver" as part of their data, that got dropped now?
[12:29] <mvo> pitti: it should not affect u-m much though, just curious
[12:29] <pitti> mvo: where was that?
[12:30] <hyperair> cjwatson: ping
[12:30] <juliank> bdrung: I share mvo's opinion with dependencies, and APT seems compliant already
[12:30] <hyperair> cjwatson: is there a possibility of enabling busybox's httpd?
[12:31] <cjwatson> hyperair: why?
[12:31] <cjwatson> and in which build?
[12:31] <hyperair> cjwatson: any one of them -- i think it would be useful for testing of stuff that should run on embedded environments.
[12:31] <mvo> pitti: e.g. http://paste.ubuntu.com/560591/
[12:32] <mvo> pitti: alas, it looks like its the module, not the xorg driver
[12:32] <cjwatson> hyperair: well, we certainly can't do it in the udeb, for instance, it would clash confusingly with save-logs
[12:32] <hyperair> cjwatson: save-logs?
[12:32] <cjwatson> hyperair: a d-i component
[12:32] <hyperair> cjwatson: how about busybox-static? or busybox?
[12:32] <pitti> mvo: right, first is the module name (before the () now), second the package name (Package: field)
[12:32] <cjwatson> hyperair: httpd is already enabled in those.
[12:32] <cjwatson> debian/config/pkg/static:722:CONFIG_HTTPD=y
[12:33] <cjwatson> debian/config/pkg/deb:721:CONFIG_HTTPD=y
[12:33] <hyperair> eh wait a sec..
[12:33] <hyperair> oh sorry
[12:33] <hyperair> i meant... busybox cgi support
[12:33] <cjwatson> feel free to file a bug for that
[12:33] <cjwatson> seems reasonable enough
[12:33] <hyperair> +CONFIG_FEATURE_HTTPD_CGI=y
[12:33] <hyperair> +CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR=y
[12:33] <hyperair> +CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV=y
[12:33] <hyperair> okay
[12:34] <hyperair> cjwatson: by the way, is there a special use case for busybox-static?
[12:34] <cjwatson> no idea, it predates me
[12:34] <cjwatson> I imagine it's recovery shells and the like
[12:34] <hyperair> ah okay
[12:34] <om26er> janimo, builds fine on 32bit install. youtube video does not play for me at the moment due to other reasons
[12:35] <cjwatson> certainly that's why it's in ubuntu-standard
[12:35] <hyperair> cjwatson: wasn't that the job of busybox-initramfs?
[12:36] <cjwatson> hyperair: no
[12:36] <hyperair> ah
[12:37] <cjwatson> its purpose is to be /bin/sh and tools in the initramfs, not in the main system
[12:37] <janimo> om26er, ok
[12:39] <apw> pitti, when you copy out kernels for lucid SRUs (from the canonical-kernel-team PPA) do you include the LBM packages?  i assume you are copying out those packages you are asked to
[12:41] <pitti> apw: sconklin-gone sends me a list to copy, as there is often old/other stuff
[12:42] <apw> pitti, ok so the disconnect is at his end, seems he did not include LBM in the lucid update last time, as that is uninstallable rgith now.  there seems to be a valid build in the PPA however
[12:42] <pitti> apw: ok, so I'll copy that then
[12:43] <apw> pitti, it looks to be the right version to my eye and matching the git repo, so that seems appropriate
[12:43] <apw> cjwatson, ^^
[12:44] <cjwatson> pitti: thanks
[12:44] <apw> cjwatson, pitti i will close the loop with the stable team to make sure the process hole here is closed
[12:44] <cjwatson> pitti: this is a regression in -updates right now - do you think we can waive the waiting period to some extent?
[12:44] <pitti> so it seems neither cert nor qa even test these
[12:44] <pitti> cjwatson: yes, absolutely
[12:45] <pitti> cjwatson: I thought we push it to -proposed now, and perhaps to -updates tonight?
[12:45] <cjwatson> right, once somebody has test-installed it and confirmed it doesn't explode
[12:45] <apw> pitti, my understanding always has been that they are 'backports' and therefore more like the backports pocket from a process point of view
[12:45] <pitti> oh, it's not just a no-change rebuild
[12:45] <apw> pitti, indeed, seems to be some updates from upstream there too ...
[12:46] <pitti> http://launchpadlibrarian.net/62531555/linux-backports-modules-2.6.32_2.6.32-27.26_2.6.32-28.27.diff.gz is quite nontrivial, so it should be tested at least
[12:46] <apw> pitti, if you get it into -proposed, i'll get some people in my team to 'feel the pain' testing it
[12:47]  * apw looks grumpy
[12:47] <pitti> apw: that'd be great; copied now, and updated bug 606278 (which should get the testing results)
[12:47] <pitti> sorry for the process fail
[12:47] <apw> pitti, i don't see you have any fault in the matter
[12:48] <pitti> forgot about lbm
[12:48] <apw> pitti, i am sure you reviewed what you are asked to release ...
[12:48] <apw> pitti, i don't think you should be having to remember
[12:59] <juliank> bdrung: Why did you create a type filesize_t (that falls into a POSIX-reserved space), instead of using the off(64)_t type which is a standardized type for file sizes?
[13:00] <hyperair> say... is rmadison going mad? it says busybox is in universe
[13:00] <hyperair>    busybox | 1:1.17.1-8ubuntu1 |         natty | source
[13:00] <hyperair>    busybox | 1:1.17.1-8ubuntu1 | natty/universe | amd64, i386
[13:00] <hyperair> cjwatson: ^^
[13:00] <hyperair> but launchpad.net/ubuntu/+source/busybox says it's in main.
[13:00] <hyperair> as does apt-get source
[13:00] <hyperair> er apt-get show(src)
[13:00] <juliank> hyperair: source is in main, binary in universe
[13:01] <hyperair> O_o
[13:01] <hyperair> oh i see.
[13:01] <hyperair> juliank: thanks
[13:08] <cjwatson> juliank: C99-reserved, too
[13:11] <juliank> cjwatson: Can't find it in C99, at least not in "7.1.3 Reserved identifiers"
[13:12] <juliank> 7.26.8 defines types matching u?int.*_t as possible future additions
[13:12] <cjwatson> juliank: hm, looks like you're right, sorry
[13:14] <ari-tczew> then rebuild
[14:09] <ScottK> lamont: Is Postfix 2.8 high enough on your list that you're likely to get it done before feature freeze?
[14:09] <lamont> when is feature freeze?
[14:10]  * ScottK looks
[14:10] <lamont> feb24
[14:10] <lamont> I expect so
[14:10] <lamont> there's also a new util-linux, which I think would be nice to get in, too.
[14:11] <lamont> and nmap
[14:11] <lamont> and prolly bind9 (rc bits are out now)
[14:11] <ScottK> Debian should be unfrozen this time next week.
[14:11] <lamont> that's what I've been stalling on
[14:11] <ari-tczew> ScottK: I heard about 5/6 feb.
[14:12] <janimo> @pilot out
[14:12] <ScottK> ari-tczew: Yes.
[14:12] <lamont> ari-tczew: that'd be "by next week"
[14:13]  * lamont makes a note to prep and take his laptop to the thing this weekend, since he'll prolly be a bit bored at least part of the time
[14:20] <bdrung> juliank: off64_t doesn't seems to be portable. maybe i should only use uint64_t from stdint.h
[14:20]  * dholbach hugs janimo
[14:25] <juliank> bdrung: Well, the important part would be to not use a name ending in _t, so kibi_filesize would be better
[14:27]  * janimo hugs dholbach
[14:28] <janimo> dholbach, piloting was a bit hectic for the first time. I am not too familiar with UDD
[14:28] <jelmer> hi janimo
[14:28] <janimo> the diversity of branches and who owns what confuses me still
[14:28] <janimo> jelmer, hi
[14:28] <dholbach> janimo, did you take "notes"? :)
[14:28] <jelmer> janimo: just getting more familiar with it, or are there things you think we can improve?
[14:29]  * janimo will be back after 1-on-1 call with manager
[14:29] <janimo> jelmer, need to get more familiar that;s for sure, but there are probably things to be improved
[14:29] <dholbach> might be good to send a short followup mail to ubuntu-devel@ so we can talk about
[14:30] <dholbach> I'm sure you're not the only one
[14:30] <janimo> for instance merging would be easier done only from the web UI wihtith the need to get locally then merge then push
[14:31] <janimo> dholbach, yes, I'll write one up. It will definitely be short, as there's not much to tell :)
[14:31] <jelmer> janimo: Yeah, agreed
[14:31]  * dholbach hugs janimo
[14:31] <dholbach> thanks
[14:31] <janimo> dholbach, np
[14:32] <janimo> jelmer, but I guess there are things which are not technical - such as making sure I am not stepping on other devs toes. From the ~46 sponsoring requets I was not sure which other sponsor has their eyes on
[14:32] <janimo> the last commented field helps
[14:33] <Laney> you can always shoot them a quick ping to check :)
[14:33] <janimo> but with recent bugs (as it actually happened with a U1-sso) upload I think teammate usually help eachother and there's no need for othewr sponsors
[14:34] <jelmer> janimo: how do you do it for non-UDD sponsoring ?
[14:34] <janimo> jelmer, the reason it was a bit slow for me is that I did not really do much sponsoring before
[14:35] <janimo> however I am more familiar with 'here's a debdiff for agains the latest source' approach
[14:35] <jelmer> janimo: you should be able to use the "Claim Review" link on the merge proposal to indicate you're processing it
[14:35] <janimo> with bzr seems I need to merge and push to bzr (making sure I push to the right branch i.e ubuntu/totem vs desktop-team/totem)
[14:35] <jelmer> perhaps we should mention that on the UDD pages
[14:36] <janimo> then I need to do the same change in the package
[14:36] <janimo> espeically if the request comes only as a bzr request and orig tgz needs to be found and fetched separately
[14:36] <ogra> janimo, you can do it the other way round, upload, wait until it shows up in the package branch and then merge back
[14:36] <janimo> jelmer, I found and used that actually
[14:39] <jelmer> janimo: Thanks for the feedback :)
[14:41] <Laney> bzr bd usually manages to find the orig
[14:43] <janimo> I am sure large part of my troubles was not having read the UDD docs thoroughly and not had peeked over anyone else's shoulder doing sponsoring work
[15:12] <smb> pitti, apw sconklin Did a quick install test for lbm-lucid. AFAICT all packages are installable from proposed now
[15:12] <sconklin> smb: thanks
[15:13] <barry> does anybody know what "System program problem detected" means?  i see this popup on login after today's updates, but it does not appear to be hooked into apport because "report problem..." does nothing
[15:15] <barry> i do see an indicator-applet file in /var/crash and one from network manager, but those are the only files from today
[15:17] <seb128> barry, it's what update-notifier displays when there is a crash from another uid that yours
[15:18] <seb128> barry, it's to avoid locking the screen asking for a gksudo password to report those
[15:18] <seb128> it should call apport, maybe check .xsession-errors
[15:18] <barry> seb128: okay, thanks.  note that when i click on "report problem" nothing happens
[15:19] <seb128> does apport work?
[15:19] <barry> seb128: unsure.  the other crash was from indicator-applet, and no apport opup came up for that one either
[15:20] <seb128> barry, try running ubuntu-bug /var/crash/...
[15:23] <barry> seb128: that worked for the indicator applet crash.  the network-manager crash file from earlier today though "problem cannot be reported".  also looks up u-b tracebacks ;)
[15:23] <pitti> smb: ah, thanks; so I'll move them to -updates, and then to -security
[15:23] <barry> seb128: i'll report what i can, thanks
[15:24] <mterry> dholbach, heyo, can you put me in the patch pilot calendar for tomorrow (as a one-time thing?  i forgot to do it on Friday)
[15:24] <seb128> barry, yw
[15:24] <dholbach> sure
[15:26] <dholbach> mterry, I'll give you access to the calendar too - unfortunately I can't do it "automatically for everyone" :(
[15:26] <dholbach> anyone else while I'm at it?
[15:27] <dholbach> mterry, done
[15:28] <mterry> dholbach, thanks
[15:39] <Kano> cjwatson: why are u images still not hybrid?
[15:39] <Kano> cjwatson: https://bugs.launchpad.net/ubuntu-cdimage/+bug/524803
[15:40] <Kano> no response too...
[15:41] <Kano> cjwatson: btw. i have got a patch for os-prober to fix gentoo detection, and you upload to d too?
[15:42] <cjwatson> Kano: don't expect me to respond to questions in that tone
[15:42] <cjwatson> if you have an os-prober patch, it's probably best to file a Debian bug for it and I/we can pick it up there
[15:43] <Kano> well i told the one i wrote the patch for to do that
[15:43] <cjwatson> if you'd asked politely about isohybrid, I would have given a detailed status update
[15:43] <Kano> just update the bug?
[15:43] <cjwatson> but not now
[15:43] <cjwatson> no, you were rude in the bug
[15:43] <cjwatson> I don't reward people who are rude with details
[15:44] <cjwatson> sorry
[15:45] <Kano> well every other distro uses hybrid mode, even live-build creates binary-hybrid.iso
[15:46] <cjwatson> we will be moving to hybrid mode; if you'd been polite I would have given details of the plan
[15:46] <cjwatson> as it is I'm afraid you'll have to wait
[15:46] <Kano> well i can execute isohybird on the iso, but do others know that?
[15:49] <Kano> ntfs-3g seems to be a bit old too
[15:49] <Kano> 2 stable releases after 8.8. already
[15:51] <Kano> would be interesting too for u, as it does not need any patch most likely
[15:51] <Kano> New: implemented the ’sync’ mount option.
[15:51] <Kano> http://www.tuxera.com/community/release-history/
[16:02] <kirkland> slangasek: howdy, around?  wanted to chat with you (again) about bug #313812
[16:07] <elif> Hi, as vim user I would like to know when 7.3 will arrive at ubuntu ?
[16:08] <davmor2> apw: Hey dude Latest natty upgrade seems to kill my wireless and drop me into flight mode no nm
[16:10] <apw> davmor2, did you use to be using linux-backports-modules-wireless ?
[16:11] <cjwatson> elif: natty already has it; earlier releases will remain at their current versions
[16:11] <davmor2> apw: If it wasn't in the standard install nope,  I've just checked on a fresh cd from this morning same issue.
[16:14] <davmor2> apw: is it best to ubuntu-bug the kernel and point you at the bug?
[16:14] <apw> davmor2, definatly want a bug yes please
[16:14] <davmor2> no probs one minute
[16:15] <bdrung> cjwatson: do it
[16:15]  * apw wonders if we have a firmware name change or something
[16:15] <cjwatson> bdrung: do which?
[16:16] <bdrung> cjwatson: demote libkibi and bump the MIR bug back to Fix Committed
[16:16] <cjwatson> ok
[16:17] <cjwatson> done
[16:23] <davmor2> apw: bug #710738
[16:25] <apw> davmor2, and you are ok if you boot back to the .37 kernel ?
[16:26] <davmor2> apw: I'll check if it's still listed
[16:28] <davmor2> apw: 2.6.37-12-generic is fine I have wireless
[16:28] <elif> cjwatson: I saw something strange, I know I'm using 10.10 (maverick), but system->About Ubuntu is saying I'm using 11.04 (Natty), It's just curious thing.
[16:28] <apw> davmor2, could you get a dmesg from that too please, and add it to the bug
[16:30] <micahg> cjwatson: or pitti can I get one of you to reject thunderbird-locales from maverick-proposed, I forgot one change
[16:30] <pitti> micahg: sure
[16:30] <pitti> micahg: but why remove? you can just upload a followup and use -v<version_in_updates> to include the previous changelog(s)
[16:30] <cjwatson> elif: please file a bug, I can't take all your bug reports personally :-)
[16:31] <micahg> pitti: it's included in that changelog :(
[16:31] <micahg> pitti: it hasn't been accepted yet
[16:31] <pitti> micahg: aah
[16:31] <pitti> micahg: I thought you meant "the version which is already in proposed"
[16:32] <micahg> sorry, I should have specified the upload queue
[16:32] <cjwatson> elif: (anyway, I think that's already known)
[16:32] <davmor2> apw: added dmesg.txt
[16:32] <apw> davmor2, ta
[16:32] <elif> cjwatson: ok. just thks, I'll check there. and try to file bug if not.
[16:33] <pitti> micahg: done
[16:33] <micahg> pitti: thanks, I'll reupload shortly
[16:34] <cjwatson> elif: bug 690248
[16:36] <elif> cjwatson: that's unfair you're too fast. anyway I have to get used with launchpad yet.
[16:38] <davmor2> apw: anything else you need?
[16:38] <apw> davmor2, not that i can think of right now, thanks
[16:39] <davmor2> apw: if you think of anything feel free to ping
[16:42] <mr_pouit> pitti: your halsectomy page is only for rdepends, right? Because hal is still pulled somehow on the latest xubuntu daily, so I suppose there are still a few spurious (r)recommends ;p
[16:42] <pitti> mr_pouit: the page isn't a complete rdepends list in Ubuntu, just projects which we run into
[16:42] <mr_pouit> ah, okay
[16:43] <pitti> mr_pouit: exaile still pulls it in, for example
[16:43] <mr_pouit> yeah, I just saw that, it's in recommends
[16:44] <pitti> mr_pouit: http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.natty/rdepends/hal/hal
[16:44] <pitti> mr_pouit: so, pretty much just that
[16:45] <pitti> http://people.canonical.com/~ubuntu-archive/germinate-output/xubuntu.natty/rdepends/hal/libhal1
[16:45] <pitti> mr_pouit: libthunar-vfs-1-2
[16:45] <pitti> stil needs libhal1
[16:45] <pitti> or is that library obsolete as well?
[16:45] <mr_pouit> yeah, and I managed to drop it from the default install
[16:48] <hallyn> so if i dont' have the hw to reproduce a bug, and am waiting for someoen to confirm a fix for the bug - what's the proper state?  leave it as 'in progress'?
[16:48] <cjwatson> sounds reasonable to me
[16:48] <hallyn> ok
[16:51] <apw> davmor2, are you in armenia ?
[16:52] <apw> it seems your networking went into country AM configuration
[16:52] <davmor2> apw: no wolverhampton not much difference
[16:52] <mvo> DktrKranz: if the gdebi gio branch looks good to you then feel free to just merge to trunk and upload, should be good from my POV
[16:53] <apw> davmor2, whats channel is your access point on ?
[16:55] <davmor2> apw: 11bgn mixed, http://ubuntuone.com/p/b4y/
[16:57] <apw> davmor2, and the iwconfig output from the linux side would be good
[16:57] <davmor2> apw: for which kernel new or old?
[16:58] <apw> the working one :)
[16:58] <apw> as your routerconfig just says "any i feel like"
[17:00] <davmor2> apw: added to bug
[17:01] <apw> davmor2, ta
[17:09] <slangasek> kirkland: hi there
[17:09] <kirkland> slangasek: howdy
[17:09] <kirkland> slangasek: so, this bug is gaining heat, once again
[17:10] <kirkland> slangasek: my tested/working solution involves the small patch to pam, here: http://launchpadlibrarian.net/39308219/pam.diff
[17:10] <kirkland> slangasek: which i think you've nacked in the past
[17:10] <kirkland> slangasek: i guess i'm wondering if that nack still holds :-)
[17:11] <slangasek> kirkland: yeah, it does.
[17:11] <kirkland> slangasek: okay
[17:12] <kirkland> hallyn: ^
[17:13] <SpamapS> So, does anyone else have the situation where gdm starts, and the screen is black.. then ctrl-alt-f1, login, restart gdm, fixes it?
[17:14] <SpamapS> I changed gdm.conf to start on stopped rc RUNLEVEL=2 .. and that seems to have fixed the problem.. but made login available a few seconds later in boot.
[17:16] <DktrKranz> mvo: ok, I'll give it a go later
[17:20] <DktrKranz> mvo: should we bump to 0.7.0, changes and fixes introduced will be quite important
[17:24] <Riddell> slomo: gst-plugins-base0.10 no longer compiles because /usr/include/linux/videodev.h no longer exists
[17:25] <cjwatson> w
[17:25] <cjwatson> w
[17:25] <cjwatson> (sorry)
[17:35] <slomo> Riddell: that's sad, why? was v4l(1) dropped?
[17:35] <ari-tczew> ogra: ping
[17:36] <Riddell> slomo: there seems to be a /usr/include/linux/videodev2.h now
[17:39] <slomo> Riddell: yes, that's for v4l2... ok, i guess old v4l is finally gone then, that's good news. for ubuntu you only have to drop the v4l plugin then, in debian i'll still keep it until after squeeze release
[17:41] <Riddell> slomo: ok thanks, I'll upload with that change
[17:43] <udienz> did all ftbfs packages must be fixed before natty?
[17:45] <micahg> udienz: would be nice, but there are usually some failures left, the ones in main will usually be addressed before release though'
[17:49] <udienz> micahg: if a fixed package release after natty, the packages will be uploaded to natty or O-release?
[17:51] <Laney> FTBFS can be fixed via SRU
[17:51] <micahg> udienz: well, fixes should land in the devel release first, if there are no binaries, FTBFS fix usually qualifies for SRU, if there are binaries, then usually the fix is saved until another fix goes in unless it's something we know will need to be rebuilt (i.e. lots of security updates in the past)
[17:54] <udienz> ok, thanks
[17:58] <mvo> DktrKranz: yeah, sounds good to me
[18:06] <hyperair> cjwatson: thanks for the upload =)
[18:08] <cjwatson> no problem
[18:08] <cjwatson> thanks for the patch :)
[18:24] <scott-work> cjwatson: do you have a minute to talk about an error in tasksel for ubuntu studio installs from image?
[18:46] <cjwatson> scott-work: it's the end of my day so I'm only intermittently around; it would be best if you described the problem such that I can reply asynchronously
[19:08] <SpamapS> cjwatson: re the openssh-server init.d script being more upstart aware.. I'll take a look and see if I can whip something up. :)
[19:09] <cjwatson> great, thanks :)
[19:10] <bdrung> geser: DMB meeting now!
[19:10] <kees> rickspencer3: re LP: #710796 -- the _kernel_ had hibernate removed. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commitdiff;h=2e5f0ea801534914c6747e953ed277fa16081602
[19:11] <rickspencer3> oh
[19:12] <rickspencer3> kees, ok, so I was a bit out of touch there
[19:12] <rickspencer3> I thought they were just hiding the UI where "they" was the desktop team
[19:13] <rickspencer3> removing it from the kernel is bold, indeed
[19:13] <kees> rickspencer3: right, that's mostly okay -- that's just a configurable. but to be _unable_ is a big deal, IMO.
[19:13] <rickspencer3> kees, well, I dropped a note to @u-devel and @u-desktop
[19:13] <rickspencer3> I think a proper discussion would be good
[19:14] <cjwatson> it seems bad form to remove it from the kernel; I said as much to kernel folks at the rally ...
[19:14] <rickspencer3> kees, would you mind correcting my mistake on that thread?
[19:14] <kees> rickspencer3: cool, thanks.
[19:14] <kees> cjwatson: and that desktop told us that it wouldn't be removed from the kernel. :P
[19:14] <kees> rickspencer3: yup, already added a note.
[19:14] <kees> rickspencer3: or do you mean the u-d thread?
[19:14] <rickspencer3> hmm
[19:15] <rickspencer3> the disconnect was probably due to me not connecting dots sufficiently
[19:15] <rickspencer3> in any case, it seems like a good thing to propose and explore, but warrants some discussion before a final decision is taken
[19:15] <cjwatson> I can see the news articles already :-/
[19:16] <cjwatson> (FWIW I don't care whether the UI is there or not!)
[19:17] <maco> hibernate as in dont-use-power-(if-it-works) ?
[19:18] <rickspencer3> maco, correct
[19:18] <maco> O_o
[19:18] <ScottK> Sigh.  I use that every time I get on an airplane.
[19:18] <rickspencer3> most of the time for me, as in, wait a long to shutdown, then not start up properly
[19:19] <ScottK> rickspencer3: Where is this discussion?
[19:19] <rickspencer3> ScottK @ubuntu-devel and @ubuntu-desktop
[19:19] <rickspencer3> I just started a thread ..  Shall we hide the GUI for Hibernate in Natty?
[19:19] <ScottK> rickspencer3: If it's not in the kernel, that's an easy one to answer.
[19:20] <rickspencer3> well, tbh, I didn't realize it was removed from the kernel
[19:20] <rickspencer3> a bit changes the tone l)
[19:20] <rickspencer3> *;)
[19:20] <ScottK> Right.
[19:20] <rickspencer3> anyway, the discussion needs to take place
[19:20] <broder> it would be nice if we could make some reasonable runtime guesses as to whether or not it would work on a given piece of hardware
[19:20] <rickspencer3> there are pros and cons and options
[19:20] <ScottK> Brings up the "If I have to compile my own kernel anyway, why am I using *buntu" question.
[19:21] <rickspencer3> broder, I was thinking of a white list combined with a checkbox to turn it on if you're not on the white list
[19:21] <ScottK> My only problem with it recently is sometimes I don't have enough swap available (which I can fix), so it's not necessarily a fixed list of what works and what doesn't.
[19:21] <broder> yeah, sure, though maintaining that list is obviously difficult, especially with release-to-release regressions
[19:22] <rickspencer3> but, it's not really my decisions, I'm just trying to make sure that it gets discussed, and doesn't end up happening a bit by default
[19:22] <broder> ScottK: available swap is easy to test for
[19:22] <ScottK> broder: Agreed.  It does that now and then doesn't shut down.
[19:23] <ScottK> rickspencer3: I didn't see anything on ubuntu-devel.  Is it just on -desktop so far?
[19:24] <rickspencer3> ScottK, could be
[19:24] <rickspencer3> I sent it to both lists
[19:27] <kees> rickspencer3: you only sent to u-desktop? not -devel?
[19:27] <broder> no, it was to devel as well. i bet it's stuck in moderation or something
[19:27] <rickspencer3> kees<EMAIL_ADDRESS>[19:28]  * kees waits on https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/date.html
[19:29] <broder> rickspencer3: the e-mail came from your @canonical address. for future reference, my recollection is that anything from an @ubuntu.com address (or maybe from the ubuntu.com smtp server?) is automatically accepted
[19:30] <rickspencer3> broder, thanks for the info
[19:39] <sconklin> pitti, StevenK: is there an actual archive on launchpad (accessible through the API) which corresponds with http://archive.ubuntu.com/ubuntu/pool/main/ ??
[19:40] <broder> actually, what makes hibernate unreliable? because it doesn't seem like it should be hardware dependent - it seems more like it's an issue with not enough swap, or unfavorable disk layouts that the initrd can't dig into correctly, etc
[19:48] <apw> rickspencer3, well we can reinstate it, but its a kernel respin, so if we need to do that for A2 we'll need to cope with the kernel bumping
[19:52] <ScottK> apw: Why did it get disabled?
[19:53] <apw> ScottK, that as i understood it was the decision, it seems a misscommunication if 'get rid of it' doesn't mean that
[19:54] <ScottK> apw: Who's decision?  We certainly support it in Kubuntu.
[19:55] <apw> i don't think i was there fore the discussion, only the final messge it was to go
[19:55] <rickspencer3> i don't think we should worry about turning it back on for A2
[19:56] <rickspencer3> it's not worth a respin and revalidating
[19:56] <rickspencer3> imo
[19:56] <ScottK> rickspencer3: But we are going to turn it back on in the kernel, right?
[19:56] <rickspencer3> I would think so, but I think we should wait and see how the discussion progresses
[19:58] <ScottK> rickspencer3: So far we're only discussing disabling the U/I on one flavor of Ubuntu.  It would seem odd to me that might drive the decision about a kernel change.
[19:59] <rickspencer3> ScottK, you make a good point, I asked someone to add to the thread that it's actually turned off in the kernel right now
[19:59] <ScottK> rickspencer3: That's been done.
[19:59] <rickspencer3> I wasn't aware that that particularly step had been taken
[20:00] <ScottK> But I think the discussion should be on ubuntu-devel.  At this point we aren't just talking Ubuntu Desktop.
[20:00] <rickspencer3> oh?
[20:00] <rickspencer3> I send the email to both
[20:00] <pgraner> rickspencer3, we had discussions at the sprint and the take aways was that is was to get tuned off to see what the impact was
[20:01] <rickspencer3> pgraner, ack
[20:01] <pgraner> rickspencer3, so we turned it off in the kernel
[20:01] <rickspencer3> probably my fault for not connecting all the dots properly
[20:02] <rickspencer3> however, there is plenty of time to discuss and turn it back on, etc...
[20:03] <ScottK> At this point you've ripped it out from under all the other flavors with no discussion.  You need to decide if that as appropriate or not.
[20:04] <ScottK> If it's not, please have it turned back on.
[20:04] <ScottK> Not sure what else there is to discuss.
[20:04] <rickspencer3> let me log a bug to get it turned back on
[20:04] <rickspencer3> I don't think anyone is particularly married to the idea of it being off in the kernel
[20:07] <pgraner> rickspencer3, nope we can turn it back on post A2
[20:07] <rickspencer3> ok
[20:08] <rickspencer3> let me start a new bug for turning it back on the kernel, and sorry for the confusion
[20:10] <smagoun> rickspencer3: thanks for doing that. Would you post the bug # here when you're done?
[20:10] <rickspencer3> yes
[20:17] <rickspencer3> smagoun, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/710877
[20:17] <kees> rickspencer3: the bug was already open (the original report was against the kernel...)
[20:17] <rickspencer3> kees, yeah, but I want to keep that one "should we hide it"
[20:17] <rickspencer3> ?
[20:17] <rickspencer3> versus the discrete task of turning it back
[20:18]  * kees doesn't care. the wording of 710796 was "it's broken in the kernel". *shrug*
[20:19] <rickspencer3> kees, just give me a few minutes to get these fixed up
[20:21] <smagoun> thanks
[20:21] <rickspencer3> kees, the user for bug #710796 is clearly saying "I want hibernate to work"
[20:22] <rickspencer3> or, "I want the feature there"
[20:22] <kees> rickspencer3: they said "option was removed and pm-hibernate doesn't work". the latter is the kernel issue
[20:22] <rickspencer3> which is different than bug #710877 which is to just turn it back on
[20:22] <rickspencer3> kees, right, so there's 2 issues, so should be 2 bug reports, imo
[20:22] <kees> rickspencer3: sounds good!
[20:23] <rickspencer3> in any case, I think the first bug should be moved to polkit
[20:23] <kees> rickspencer3: my point was that 710796 was already open against the kernel, etc.
[20:23] <kees> but yeah, whatever makes sense. as long as it's coming back in the kernel, I'm happy :)
[20:42] <hallyn> bdmurray: /win 10
[20:42] <hallyn> huh
[20:42] <hallyn> bdmurray: what is the 'proper' place to get your greasmonkey lp extensions?
[20:44] <micahg> hallyn: https://launchpad.net/~gm-dev-launchpad/+archive/ppa
[20:44] <bdmurray> hallyn: firefox-lp-improvements ppa is the best
[20:44] <hallyn> thanks
[20:46] <DktrKranz> mvo: gio branch merged!
[21:06] <cjwatson> broder: no, the auto-accept is based on membership of ~ubuntu-dev
[21:08] <broder> oh really? that's actually rather clever. so i assume that means it also incorporates any e-mail address a member of ~ubuntu-dev has registered on their lp account?
[21:09] <cjwatson> (though I don't see Rick's mail in the moderation queue - of course there is an extra whitelist)
[21:09] <cjwatson> broder: it's supposed to
[21:09] <cjwatson> that part is not directly visible to me though, but that's what I'm told
[21:14] <ScottK> lamont: Has fiordland been "improved" or does "stuff" just happen: http://paste.ubuntu.com/560732/
[21:15] <cjwatson> ok, I have no idea where rickspencer3's mail to ubuntu-devel went
[21:15] <cjwatson> it's neither in the queue nor in the archive
[21:15] <rickspencer3> weird
[21:15] <rickspencer3> cjwatson, I'll resend, and yeah, weird
[21:15] <cjwatson> the queue's been suspiciously empty all day (some longer-term things in there but nothing new)
[21:16] <cjwatson> and nijaba was asking me about some problem earlier ...
[21:16] <cjwatson> rickspencer3: I suggest chasing it up with IS, quoting the message-id of the message you sent
[21:16] <cjwatson> I'm not sure resending will help - it will probably just confuse things
[21:16] <rickspencer3> ok
[21:16] <cjwatson> it's almost as if anyone not on the whitelist is getting binned
[21:17] <lamont> ScottK: good question. I'm a bit out-of-loop on that, maybe an RT with the output on it would be in order
[21:17] <ScottK> lamont: OK rt .at. ubuntu.com?
[21:17] <elmo> sigh
[21:17] <elmo> the problem is the tool that hardcoded fiordland
[21:18] <elmo> rather than using the MX
[21:18] <elmo> fiordland is no longer the mx for launchpad.net
[21:18] <ScottK> I see.
[21:18] <ScottK> bdrung: ^^^^
[21:18] <ScottK> elmo: Thanks.  That we can fix.
[21:18] <cjwatson> oh, wow, that's nasty code
[21:18] <ScottK> tumbleweed: ^^^
[21:19] <lamont> ew
[21:21] <ScottK> Yep.  Updating to the current MX works.
[21:21] <ScottK> elmo: Thanks.
[21:21] <elmo> ScottK: np
[21:21] <cjwatson> updating to code that doesn't just hardcode a new MX, I hope :)
[21:23] <lamont> hopefully doing a lookup of mx for launchpad.net and using that???
[21:25] <broder> ugh, smtplib doesn't have a mode where it will do that itself? that's kind of lame
[21:26] <ScottK> broder: It's smtplib, not DNS.
[21:27] <broder> yeah, but "send this message to whoever is the mx for the recipient" seems like a pretty common thing to do
[21:27] <StevenK> Uh, doing a lookup of an MX inside Python is not expensive?
[21:27] <geser> that's also means SRU's are needed
[21:27] <cjwatson> StevenK: how do you do it then?  I was just googling ...
[21:28] <StevenK> Damn it, I knew some one was going to ask that.
[21:28] <cjwatson> so far, only found a stackoverflow comment saying that doing MX lookups in python requires a third-party module
[21:28] <ScottK> It's not that hard.
[21:28] <ScottK> I'm the Debian maintainer for python-dns.
[21:28] <ScottK> One could also use dns-python.  That's a bit overkill for this.
[21:29] <cjwatson> though dnspython is at least in main
[21:29] <cjwatson> (but I agree, it's a big hammer)
[21:29] <StevenK> Bah, seems I'm mis-remembering. Doing DNS lookups in Python can be done with 'socket', but things like MX or NS lookups need a 3rd party module.
[21:30] <broder> yeah, that was what i thought
[21:30] <ScottK> cjwatson: Since I'm maintaining python-dns, I don't think it matters much which is in Main.
[21:30] <cjwatson> ScottK: heh, fair enough
[21:31] <cjwatson> StevenK: right, socket.getaddrinfo is fine for A lookups
[21:32] <scott-work> cjwatson: if i were to fix the seeds and push it back to bzr would you be able to help me get the meta packages rebuilt?
[21:33] <scott-work> cjwatson: i would really like to get the tasksel fixed before alpha2 and my usual contact hasn't responded back yet
[21:33] <geser> ScottK: are you going to file a bug about it for u-d-t? or should I do it?
[21:33] <cjwatson> scott-work: doesn't need metapackage rebuilds, just needs a tasksel rebuild.  yes I can do that.
[21:33] <ScottK> geser: No.  I'm going to fix it.
[21:34] <geser> ok and thanks
[21:34] <scott-work> cjwatson: i will update the seeds in approximately six hours time from now
[21:34] <scott-work> cjwatson: and thank you again!
[21:34] <geser> ScottK: don't we need a bug for the SRU? as maverick and lucid are affected too
[21:34] <ScottK> Good point.
[21:34] <ScottK> Please file it.
[21:35] <cjwatson> scott-work: is it possible to do it before I go to bed?
[21:36] <cjwatson> scott-work: if you do it six hours from now, I won't update tasksel until I get up in the morning, and we'll miss the cron job that should be building the alpha-2 images
[21:36] <scott-work> cjwatson: unfortunately i'm at work and will not leave for another 1.5 hours, plus need to pick kids up on the way home
[21:36] <cjwatson> scott-work: you can just tell me what change to make
[21:36] <cjwatson> what the new Description should be
[21:36] <scott-work> cjwatson: i can do that:
[21:37] <scott-work> cjwatson: in audio-plugins replace "Task-Description: LADSPA, LV2, and DSSI audio plugins" with "Task-Description: LADSPA/LV2/DSSI audio plugins"
[21:38] <cjwatson> scott-work: committed, thanks
[21:38] <scott-work> cjwatson: awesome, thank you very much :)
[21:39] <cjwatson> I'll upload tasksel once the local update finishes here
[21:40] <geser> ScottK: bug 710925
[21:41] <SpamapS> cjwatson: so the most reliable way that I can find to determine whether or not to use upstart is to drop a fake randomly named job in /etc/init and ask upstart what its status is.. if it doesn't know about the job, then I assume we're in a chroot.
[21:41] <StevenK> geser: That's so not the bug.
[21:41] <broder> SpamapS: oww
[21:41] <StevenK> "Talks directly to a machine, assuming it's the MX for launchpad.net"
[21:42] <cjwatson> SpamapS: look at /proc/1/exe?
[21:42] <SpamapS> cjwatson: its a symlink. :-/
[21:42] <SpamapS> as is /proc/root and /proc/cwd
[21:42] <SpamapS> no help at all :P
[21:42] <geser> StevenK: fixed the bug description (taken yours)
[21:42] <cjwatson> I've definitely seen code along those lines that worked
[21:43] <broder> cjwatson: i know you can see if something is in a chroot under you looking at /proc/pid/root
[21:43] <broder> i don't think it works the other way around
[21:43] <cjwatson> initramfs-tools.preinst
[21:44] <cjwatson> tested, works fine
[21:44] <cjwatson> of course on the feature test principle it would be better to test whether upstart knows about the job, so that things work once upstart gains chroot support, but that may be too complex to live
[21:45] <broder> oh right, you have to look at the inode number. i remember seeing that now
[21:45] <SpamapS> The inode number of what exactly?
[21:45] <SpamapS> ?
[21:45] <cjwatson> see initramfs-tools.preinst
[21:45] <broder> your / vs. /proc/1/root
[21:45] <cjwatson> there's a chrooted() function there which works
[21:45] <SpamapS> right, that is reasonaly accurate, but fails if you chroot into a dedicated mount point
[21:46] <cjwatson> "dedicated mount point"?
[21:46] <broder> SpamapS: sorry, combination of the inode and the device number that contains / :)
[21:46] <SpamapS> mkdfs file ; mount -o loop file /mnt/mychroot ; copy stuff to /mnt/mychroot ; chroot /mnt/mychroot /bin/bash
[21:46] <SpamapS> dev number yes that works
[21:46] <cjwatson> please try the code I referred to
[21:47] <SpamapS> yes I was waiting for bzr branch ;)
[21:47] <cjwatson> cat /var/lib/dpkg/info/initramfs-tools.preinst
[21:47] <SpamapS> oh that would have been clever wouldn't it have?
[21:48] <SpamapS>     # borrowed from udev's postinst
[21:48] <cjwatson> it was in Debian udev's postinst, I think, not Ubuntu's
[21:48]  * SpamapS is wary of spreading the evil of copy/paste :-P
[21:48] <cjwatson> yes, still is
[21:48] <cjwatson> meh
[21:48] <cjwatson> I mean I kind of agree but this is code we already know we intend to throw away
[21:49] <SpamapS> That branch of Scott's looked reasonably mature.. did you get any feeling as to how likely it was to make it into natty?
[21:50] <broder> the upstart spec still has it scheduled for natty, right?
[21:50] <cjwatson> fairly, I think, he and James just need to agree on maintenance practices
[21:50] <cjwatson> (not that there's a fundamental disagreement AFAIK, it just needs to get nailed down)
[21:50] <SpamapS> Cool. So this really is just likely to be something for lucid and maverick only.
[21:50] <cjwatson> I'm not going to worry about that until closer to feature freeze
[21:51] <jcastro> ogra: did you get the mail from the banshee upstream guy (gabriel) wrt. ARM?
[21:51] <SpamapS> so.. the question in my mind is how do we know to throw this code in openssh-server away when upstart gets the new capability...
[21:53] <cjwatson> if you come up with something, let me know :)
[21:54] <bdrung> ScottK: feel free to commit a fix to lp:ubuntu-dev-tools
[21:54] <ScottK> bdrung: It's been "improved" in natty, so I'm not sure I'll be able to fix it.
[21:55] <ScottK> bdrung: Where does mailserver_host get set now?
[21:55] <bdrung> ScottK: ask tumbleweed
[21:55] <ScottK> tumbleweed: ^^^
[21:57] <bdrung> ScottK: requestsync line 99: default='fiordland.ubuntu.com'
[21:57] <ScottK> Thanks.
[21:57] <bdrung> ScottK: don't forget to update the man page too
[21:58] <ScottK> bdrung: Found it.
[22:02] <bdrung> poolie: i checked bzr with lintian and found that: http://paste.ubuntu.com/560748/
[22:09] <tumbleweed> bdrung, ScottK: back. shall I commit a fix?
[22:10] <ScottK> tumbleweed: I'll do it for Natty and then you can backport, OK?  I'm already working on it.
[22:10] <bdrung> tumbleweed: yes unless ScottK is working on a fix too
[22:10] <tumbleweed> ScottK: great. I suppose you'll have to pull in an extra dependancy for DNS support :/
[22:10] <ScottK> yes
[22:11] <poolie> bdrung, thanks
[22:34] <SpamapS> slangasek: so I think we can write the -wait job generically
[22:34] <SpamapS> slangasek: meaning one could reasonably do    start wait-for WAIT_FOR=ssh
[22:44] <slangasek> SpamapS: instance $WAITER$WAITSFOR ?
[23:37] <ScottK> bdrung and tumbleweed: Pushed.
[23:38] <bdrung> ScottK: where?
[23:39] <ScottK> bdrung: My bad.  Comitted.  Didn't push.  Just a moment.
[23:39] <ScottK> bdrung: Pushed to trunk.
[23:45] <tumbleweed> ScottK: the second config.get_value doesn't do anything useful
[23:48] <tumbleweed> it will also not abort if it can't do the DNS lookup, but presumably crash later when it tries to connect to ''
[23:48] <geser> ScottK: there is a typo in the ImportError message: "Launchapd" → "Launchpad"
[23:48] <tumbleweed> and you can test it on staging :P
[23:50]  * tumbleweed heads to bed
[23:56] <SpamapS> slangasek: something like that, still monkeying with it
[23:58] <hggdh> slangasek, can you please look at bug 708579? This is either a new issue, or bug 603934 is not completely fixed
[23:59] <SpamapS> slangasek: yes, that works..


[01:55] <rogpeppe> wallyworld: ping
[01:55] <wallyworld> hello
[01:56] <rogpeppe> wallyworld: i've just arrived
[01:56] <rogpeppe> wallyworld: what's up?
[01:56] <wallyworld> i'm tired, been awake for 28 hrs, about to go to bed :-)
[01:56] <wallyworld> couldn't sleep on planes
[01:57] <wallyworld> you fly in from heathrow?
[01:57] <rogpeppe> wallyworld: cool. sleep well. see ya in da mornin'
[01:57] <rogpeppe> wallyworld: no, paris
[01:57] <wallyworld> yeah, sorry, too tired to do much now
[01:57] <rogpeppe> wallyworld: couple of guys from yellow team on the same flight
[01:57] <rogpeppe> wallyworld: have you seen anyone else?
[01:58] <wallyworld> i saw benji on the lobby earlier
[01:58] <wallyworld> he had just finished dinner and was heading up
[01:58] <wallyworld> no one else though
[01:58] <rogpeppe> wallyworld: k, thanks
[01:58] <wallyworld> talk tomorrow
[01:58] <rogpeppe> ttfn
[02:00] <mgz> wallyworld: sleep well!
[02:04] <mgz> rogpeppe: I'm just hanging around in room, not feeling the need to sleep quite yet but no particular plans
[02:04] <rogpeppe> mgz: you eaten?
[02:04] <mgz> did my message get through before dropping? :)
[02:05] <mgz> rogpeppe: not since arriving, haven't worked out if I need another meal not not, but would be happy to go out somewhere and see
[02:06] <mgz> rogpeppe: and you?
[02:06] <rogpeppe> mgz: i'm in the same boat. but... actually, maybe i *should* grab some sleep while i can.
[02:06] <rogpeppe> mgz: only got about 4h last night
[02:07] <mgz> yeah, likewise
[02:07] <mgz> but for less good reasons that you :)
[02:07] <rogpeppe> mgz: how do you know :-)
[02:08] <rogpeppe> mgz: anyway, think i might just crash. see you tomorrow...
[02:08] <mgz> you said you had a gig, I was just doing things last minute :)
[02:08] <rogpeppe> mgz: ah
[02:08] <mgz> see you in the morning!
[02:08] <rogpeppe> mgz: yeah, i did have a gig actually
[02:08] <rogpeppe> mgz: it was cancelled
[02:08] <rogpeppe> mgz: and the un-cancelled at the last moment
[02:09] <rogpeppe> s/the/then/
[02:09] <rogpeppe> mgz: finished playing at 4am
[02:11] <mgz> did it go well?
[02:11] <rogpeppe> mgz: yeah. knackering though. 5 solid hours of playing.
[02:12] <mgz> you're just too hardcore :)
[02:16] <rogpeppe> mgz: less so with every passing year!
[10:09] <rogpeppe> sleep oh sleep, where are thou?
[13:46] <niemeyer> benji: ping
[13:46] <niemeyer> LOL
[13:47] <niemeyer> Anyone else from the Yellow team here?
[13:54] <niemeyer> Hmm
[16:04] <fwereade> TheMue, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1049908
[16:04] <_mup_> Bug #1049908: Upstart control of lxc container instances <lxc (Ubuntu):Fix Released by serge-hallyn> <lxc (Ubuntu Quantal):Won't Fix> <lxc (Ubuntu Raring):Fix Released by serge-hallyn> < https://launchpad.net/bugs/1049908 >
[16:30] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1144704
[16:30] <_mup_> Bug #1144704: environs/openstack: tests fail unless the user running the tests has ~/.ssh keys <juju-core:New> < https://launchpad.net/bugs/1144704 >
[16:55] <jamespage> davecheney, any update on the mongodb packages I pushed to PPA?