[02:45] <stgraber> oh, typo in the changelog, as it's still in the queue might as well fix that :)
[02:45] <stgraber> please reject ^
[02:47] <stgraber> and re-uploaded
[03:01] <ScottK> stgraber: Rejected the older one.
[03:06] <stgraber> ScottK: thanks
[03:06] <ScottK> No problem.
[03:07] <ScottK> slangasek: ^^^ Yon kde-workspace upload has the upstart init change you're waiting for if you'd care to review (all the patches are cherrypicks from upstream).
[05:26] <slangasek> ScottK: accepted
[05:27] <ScottK> slangasek: Thanks.
[05:28] <slangasek> and that lightdm is the last one that blocks fixing this on the plymouth side
[05:35] <pitti> ev: will have a look at the custom widgets thing this morning
[05:49] <pitti> slangasek: accepted
[05:49] <pitti> thanks!
[05:50] <slangasek> pitti: huzzah, thanks to you
[06:37] <micahg> pitti: could you review firefox ^^
[06:37] <pitti> oh, another one? :-)
[06:37]  * pitti already accepted two yesterday
[06:37] <pitti> micahg: sure, doing
[06:38] <micahg> pitti: you weren't supposed to accept the first one ;)
[06:38] <micahg> or whichever one ubuntu2 was
[06:42] <micahg> pitti: thanks!
[06:42] <pitti> np; sorry for prematurely accepting ubuntu2 then, didn't spot that error
[06:43] <micahg> pitti: yeah, I didn't spot the issue either, cjwatson caught it, but we should've listened to infinity and rejected it :)
=== jpds_ is now known as jpds
[08:18] <pitti> ^ review of that appreciated (I uploaded), breaking ubiquity
[08:18] <micahg> pitti: why the funny version?
[08:19] <pitti> micahg: it was -0svn1 before, and it's a bit impractical right now to commit that to debian's svn
[08:19] <pitti> I can also name it -0ubuntu1 if people prefer taht
[08:19] <micahg> pitti: right, so it should be -0ubuntu1, no?
[08:20] <pitti> fine for me; rejecting, reuploading
[08:21]  * micahg isn't sure what his obsession with version numbers is about...
[08:26] <ev> pitti: thanks
[08:27] <pitti> ev: sorry about that; I was going to test the new pygobject with ubiquity with the first live CD after b2, but we didn't get one yet; seems you beat me to it
[08:27] <pitti> anyway, the just uploaded version works fine
[08:28] <ev> no worries
[08:28] <ev> we should discuss doing this sort of thing in a more automated fashion at UDS
[08:28] <ev> integration tests and all that jazz
[08:29] <pitti> ev: I thought QA used to have daily automatic tests of our CDs; they should catch this sort of regression, too
[08:30] <ev> well I was thinking of something less reactionary.  Have the buildd run through the unit tests of any package that depends on the package being built
[08:30] <ev> that way we catch it straight away
[08:30] <pitti> ah
[08:32] <pitti> ev: with jhbuild that already works pretty nicely, but that's of course not easy to move to our per-package source builds
[08:33] <ev> hm
[08:34] <ev> admittedly I haven't dug through the source here much
[08:34] <pitti> next time I upload pygobject I could just run the ubiquity tests
[08:34] <pitti> that's low-tech and rather easy to do
[08:38] <ev> Oh, my intention wasn't to just fix ubiquity with this approach, but make it hard to get any software into the archive that breaks existing software.
[08:38] <ev> but that works for now :)
=== doko_ is now known as doko
[10:51] <ev> is it too late to switch wubi to building ext4 disk images? It's roughly a two line change.
[13:15] <ogasawara> could I get the linux-meta-3.0.0.12.13 package approved in the queue please?
[13:27] <ScottK> pitti: I just uploaded KDE 4.6.5 for natty-proposed.  I'd appreciate it if you could accept it today.
[13:33] <pitti> ScottK: will see to squeeze it in, and/or delegate to SpamapS :)
[13:34] <ScottK> pitti: Thanks.
[14:19] <seb128> ^ I did reject my gtk upload, it had a small issue
[15:33] <ScottK> pitti: You rejected my oxygen-icons upload?
[15:34] <pitti> ScottK: yes, see bug; it's a no-change upload, so I guess not worth an SRU?
[15:34] <ScottK> OK.  Thanks.
[15:34] <ScottK> Agreed.
[15:34] <ScottK> People who had the bad PPA version already got the fixed one I guess.
[15:35] <pitti> yes, the reversion to .2 also seems to be in the PPA, according to changelog
[15:36] <ScottK> It is.
[15:37] <ScottK> I forgot to go back and diff against what was in the archive.
[15:40] <pitti> ScottK: ok, all done; that should keep the buildds busy for a while
[15:40] <ScottK> Yep.  Thanks.
[15:41] <cjwatson> pitti,SpamapS: I don't suppose one of you could look at my grub/grub-installer/hw-detect SRUs?  I have a tester ready and waiting eagerly. :-)
[15:41] <ScottK> There will be a bunch of non-i386 failures due to transient build-dep uninstallability.  I'll keep an eye and retry, but don't be suprised.
[15:41] <cjwatson> (In fact, he first mailed me about this set of bugs in February ...)
[15:42] <pitti> cjwatson: already at it :) (while I'm at it)
[15:43] <cjwatson> cool
[15:43] <cjwatson> grub <= natty shouldn't suffer from the problem I uploaded for today; I'm pretty sure that I've isolated that to GCC >= 4.6
[15:44] <pitti> cjwatson: for hw-detect, will that get an accompanying d-i upload?
[15:44] <cjwatson> yes, although only after it's built
[15:50] <SpamapS> cjwatson: hah, I read that as "I have a zester ready and waiting" .. and I wondered.. what does citrus flavoring have to do with grub?
[15:51] <cjwatson> boots better if you add some lemon juice
[15:54] <pitti> good night!
[15:54] <Daviey> squashfs until the pips squeak.
[16:02]  * ScottK prepares to get sabdfl'ed.
[16:21] <lamont> deploying the correct fix for the archive mirror. this could produce a short period where the archive is not completely in sync
[16:22] <infinity> "The correct fix"?
[16:22] <lamont> the one where we fix dangling symlinks by also syncing the target, instead of stomping on it
[16:23] <lamont> it would be interesting to know how debmirror deals with symlinks between components
[16:25] <lamont> I suspect that the answer is "not"
[16:26] <lamont> fwiw, the not-in-sync shows up mostly as 403/404 errors. :(
[16:30] <infinity> There are worse things than a few missing files for an hour or two.
[16:36] <Daviey> lamont: Hmm, you have concerns that debmirror (and others?) will be broken going forward?
[16:37] <lamont> Daviey: no
[16:37] <Daviey> lamont: super, thanks
[17:14] <skaet> Daviey,  there are 2 cobbler-enlist_0.1 packages in the new queue,  separated by 10 days.    Should the older be rejected.   Note:  the sizes are different between the two.
[17:15] <skaet> ?
[17:16] <Daviey> skaet: One is called cobbler-enlist, the other cobbler-enrol :)
[17:16] <Daviey> cobbler-enrol can be rejected.
[17:17] <skaet> Daviey,  yup,  misread that, my bad.    cobbler-enrol rejected now.
[17:18] <bjf> skaet, is today's daily iso busted ? i get an "installation failed" "The installer encountered an unrecoverable error." dialog trying it
[17:18] <Daviey> ta
[17:19] <skaet> bjf,  I've just been doing updates myself today.   jibel,  are you seeing anything from the automated tests?
[17:19] <Daviey> oo-er
[17:19] <skaet> ....
[17:19] <bjf> skaet, np, will keep looking
[17:19] <SpamapS> Release team, need your thoughts on the situation with ensemble/juju ..
[17:19] <SpamapS> Its a leaf package, no dependencies..
[17:20] <skaet> Daviey, oo-er?
[17:20] <SpamapS> We have a pending upload which renames ensemble's binary packages to juju, as the project has been renamed..
[17:20] <Daviey> bjf: What ISO image?
[17:20] <slangasek> The Situation is using Juju?  By all means, let's capitalize on this in all our marketing
[17:20] <slangasek> oh, not that situation
[17:20] <SpamapS> And there are two big features which upstream would like to see land in 11.10...
[17:20] <Daviey> SpamapS: I assume you have a transional package in place?
[17:20] <SpamapS> Since its a leaf, unseeded, universe package, can we upload after Thursday?
[17:20] <bjf> davidm, should have been the daily from today, i'm pulling a new one down, and will retest
[17:20] <SpamapS> Daviey: yes, thats part of it.
[17:21] <SpamapS> slangasek: Maybe we can get snookie too :)
[17:21] <Daviey> SpamapS: ISTM that there are two issues, the name and the features.  Can they be handled in seperate uploads please?
[17:21] <slangasek> SpamapS: it can be uploaded after Thursday, but "new features" still means "FFe", which requires some lead time... I don't think you want to risk the name change not going through because it's caught in review
[17:21] <Daviey> Thereofr eseperate FFe's
[17:22] <slangasek> so I would suggest uploading the package name change ASAP
[17:22] <SpamapS> Ok I can upload the name change now for sure. Should I open a FFe bug to track the rename too then?
[17:22] <cjwatson> bjf: do you have a bug# and/or installation logs?
[17:23] <Daviey> SpamapS: Is a deprecation warning being issued under older commands?  Or just shooting for gold?
[17:23] <cjwatson> bjf: and which daily, we build quite a few
[17:23] <Daviey> SpamapS: Bugs are always handy :)
[17:23] <SpamapS> Daviey: I was thinking that at least /usr/bin/ensemble should throw up a warning.
[17:23] <bjf> cjwatson, not yet, just tried, failed, just pulled down one right now, am going to try that
[17:23] <Daviey> ... and rewarding! :)
[17:23] <bjf> cjwatson, how to i tell one daily from the next ?
[17:23] <cjwatson> bjf: it would really help if you could tell me the URL
[17:24] <cjwatson> we build dailies of Ubuntu desktop, Ubuntu alternate, Ubuntu server, Kubuntu desktop, Kubuntu alternate, Xubuntu desktop, Xubuntu alternate, need I go on
[17:24] <cjwatson> several of which are Canonical-supported
[17:24] <cjwatson> and we build each of those for multiple architectures
[17:24] <Daviey> bjf: It's not clear to me even what flavour you have encountered this with... server, desktop, kubuntu etc?
[17:24] <bjf> cjwatson, sorry, ubuntu desktop amd64
[17:24] <cjwatson> thank you
[17:24] <bjf> Daviey, ^
[17:25] <slangasek> SpamapS: if you want to just say in the changelog that I've pre-approved the name change, that's fine
[17:25] <cjwatson> if you had the daily from today, what new one are you pulling down?
[17:25] <Daviey> He's right ya know
[17:25] <Daviey> https://jenkins.qa.ubuntu.com/job/oneiric-desktop-amd64_default/98/
[17:25] <skaet> Daviey, re: cobbler-enlist:  debian/copyright is different from what is in the cobbler-enlist.c file.   Note: cobbler-enlist.c, references cobbler-enrol in the title of the comments also.
[17:25] <cjwatson> wasn't saying he wasn't, just needed something to look for ...
[17:26] <Daviey> crap, thought i caught them all
[17:26] <SpamapS> slangasek: alright that sounds good. I'm finishing some testing and will upload after that.
[17:26] <bjf> cjwatson, i have a script that pulls down the ubuntu desktop amd64/i386 every day, i tried it and it failed, i just ran the script again incase new ones had been built
[17:26] <skaet> Daviey,  np.  want me to reject it so you can re-upload?
[17:27] <cjwatson> Daviey: do you know how I can extract installer logs from jenkins?
[17:27] <Daviey> cjwatson: I think jibel or jamespage are the key to that.
[17:27] <SpamapS> And per the other features.. which should land late this week, is there anything I need to do to ensure that the upload early next week is approved?
[17:28] <Daviey> skaet: please
[17:28] <skaet> Daviey, done.
[17:28] <cjwatson> it's chocolate-teapot levels of usefulness without logs, sadly
[17:28] <cjwatson> well, I guess we get one bit of information out, success or failure :)
[17:29] <cjwatson> but surely we can do better, I complained about this months ago
[17:29] <bjf> cjwatson, i'll see what i can get you
[17:29] <cjwatson> thanks; I'm syncing now but it will take a while
[17:31] <bjf> cjwatson, i'm building a new usb key right now, when it fails, which logs would you like? (is there a wiki page for debugging installer issues?)
[17:32] <cjwatson> the logs from the previous usb key would've been fine, but ...
[17:32] <cjwatson> https://wiki.ubuntu.com/DebuggingUbiquity
[17:33] <cjwatson> tl;dr: /var/log/{syslog,partman}
[17:33] <cjwatson> oh and /var/log/installer/debug
[17:33] <bjf> cjwatson, ack
[17:33] <cjwatson> should probably edit that page to not talk about EOL distributions but life's too short
[17:44] <bjf> cjwatson, bug #859849
[17:44] <ubot4> Launchpad bug 859849 in ubiquity (Ubuntu) "ubiquity crashed with AttributeError in do_set_property(): 'StateBox' object has no attribute 'label' (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/859849
[17:46] <cjwatson> fixed by new pygobject
[17:46] <cjwatson> I'll find the dup target in a moment
[17:46] <cjwatson> so will be fixed in tomorrow's daily
[17:46] <cjwatson> *dailies
[17:46] <bjf> cjwatson, ok, thanks
[17:47] <cjwatson> bug 856669
[17:47] <ubot4> Launchpad bug 856669 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "pygobject 3.0.0-0svn1 does not work with custom python GTK widgets (affects: 24) (dups: 20) (heat: 194)" [Undecided,Invalid] https://launchpad.net/bugs/856669
[17:47] <cjwatson> (stupid bugbot, true status is fix released on pygobject)
[17:56] <jamespage> cjwatson, Daviey: it looks like that test run did not actually start installing - hence no installer log
[18:13] <cjwatson> jamespage: ok, but it would do if it got past a certain point?  that's good
[18:14] <jamespage> cjwatson: yes it would - the preseed kicks off httpd in early_command and the framework then grabs the installer log every X seconds
[18:16] <jamespage> looking at todays tests - https://jenkins.qa.ubuntu.com/
[18:16] <jamespage> it would appear that all oneiric-desktop-* tests failed
[18:16] <jamespage> alternate was OK
[18:17] <jamespage> they all appear to have failed in the same way i.e failed to start installation
[18:22] <cjwatson> anything gtkish would have done
[18:22] <cjwatson> dunno if you test kubuntu
[19:23] <Daviey> woah, 2.6.38-1.3 → 2.6.38-1000.1 .. is that right?
[19:28] <infinity> Daviey: I'm on it.
[19:28] <infinity> (Feel free to ignore all the ARM kernels in the queue, I'm reviewing them all)
[19:29] <Daviey> infinity: ah ok, i started chatting in -arm, if you want to take over.
[19:48] <cjwatson> pitti: bug 720558 - do you want non-Xen tests as well, or do you think Xen tests are enough?
[19:48] <ubot4> Launchpad bug 720558 in grub-installer (Ubuntu Natty) (and 7 other projects) "Ubuntu 10.04 currently requires groot= workaround with pvgrub (affects: 1) (heat: 12)" [Undecided,Invalid] https://launchpad.net/bugs/720558
[19:50] <cjwatson> (obv. I need to test maverick and natty too)
[19:57] <doko> please could somebody approve openjdk-6? JamVM fixes, one CACAO fix and three OpenJDK fixes
[19:58] <infinity> doko: Let me look.
[20:09] <infinity> La la la, gnome3.20 flood...
[20:51] <cyphermox> could someone please ack network-manager-applet?
[20:55] <infinity> cyphermox: I don't see how it's at all improved over pitti's previous complaints.
[20:55] <infinity> Oh, unless I'm reading the diff wrong.  Need more context.
[20:55] <cyphermox> ah? I moved the files over into a -common package as suggested
[20:55]  * infinity downloads the full source.
[20:55] <infinity> Yeah, but what depends on the -common?
[20:55] <cyphermox> libnm-gtk0. did I screw this up again?
[20:56] <infinity> Yeah.
[20:56] <cyphermox> dah!
[20:56] <infinity> You depend on a -common (= ${binary:Version}) ...
[20:56] <infinity> In essence, you've moved nothing, just created a new package. :P
[20:56] <infinity> Because libnm-gtk0 and libnm-gtk1 will still not be co-installable.
[20:56] <infinity> Which was the complaint.
[20:58] <infinity> Does the library actually require those two unversioned files to run?
[20:58] <infinity> Or to be loaded usefully.
[20:58] <infinity> Or is it just the applet that needs them?
[20:59] <cyphermox> the library does
[20:59] <infinity> Seriously? :/
[20:59] <cyphermox> at least wifi.ui; since it's used to display the dialogs the library is meant to display
[21:00] <infinity> In that case, you're going to have to give them versioned paths.
[21:00] <infinity> And then you can safely put them in the library package.
[21:00] <cyphermox> but why not just keep them in this -common package? afaik it does follow policy (section 8.2 iirc)
[21:00] <cyphermox> I was looking this up again this morning
[21:01] <cyphermox> I thought I only screwed up the dependency
[21:04] <infinity> Well, the common package only works if (A) you fix the dependency, but more importantly (B) those files will work with newer versions of the library.
[21:05] <infinity> (Or, more to the point, newer versions of those files will work with older libraries)
[21:05] <infinity> If that backward compat isn't guaranteed, just versioning the files and stuffing them in the library package is reasonable.
[21:05] <infinity> If upgrading to libnm-gtk1 makes libnm-gtk0 fail to function, then we've won nothing with the split.
[21:06] <cyphermox> From what I know these files should work with older versions, that part doesn't worry me
[21:07] <infinity> If you're fairly sure of that, then yeah, your only bug here is the dependency.
[21:07] <cyphermox> please reject it, I'll fix this
[21:08] <infinity> Rejected.
[21:08] <cyphermox> fwiw, I do see the issue with the dependency, sorry about that
[21:14] <cjwatson> pitti,SpamapS: it turned out I already had a debian-installer/natty-proposed upload staged (for some time), so I uploaded that
[22:02] <cyphermox> infinity:  ^ I think this covers it all now.
[22:05] <doko> slangasek, why not qemu-linaro 2011.09?
[22:06] <slangasek> doko: because I haven't tested 2011.09 at all yet and time is short
[22:06] <slangasek> I really don't want to go through another round of ppa tests, etc. to get this done