[00:01] <slangasek> cjwatson: this grub2-signed downloads the gcdx64.efi.signed, but doesn't appear to install it (Makefile is unchanged)
[00:06] <slangasek> cjwatson: reuploaded with this fix, and accepting
[00:08] <cjwatson> slangasek: Whoops, thanks
[00:08] <cjwatson> Quite right
[00:27] <slangasek> grub-installer looks good
[00:28] <slangasek> adding grub-efi-amd64-signed to the installer seed now
[00:28] <slangasek> (supported-installer-common, to be precise)
[00:29] <doko_> quantal, not precise?
[00:29] <slangasek> I don't want to be quantal
[00:29] <slangasek> I want to be precise
[00:29] <doko_> ;)
[00:30] <slangasek> I'm also assuming grub2-signed doesn't require an MIR since there's no new binary package code
[00:30] <slangasek> so, promoted'n'such
[00:31] <cjwatson> supported-installer-common isn't really right
[00:31] <cjwatson> I think it should go in platform.quantal/d-i-requirements plus ubuntu.quantal/ship-live
[00:31] <cjwatson> (And probably in general all seeds that currently contain grub-efi)
[00:32] <doko_> afk now
[00:32] <cjwatson> s/right/sufficient/
[00:33] <slangasek> ok
[00:59]  * xnox ponders how much stuff I have missed over the weekend...
[01:09] <cjwatson> Well, some of the changes in tcl8.4 we kind of want, but I think it's too involved for 12.10 and I'm not certain whether it would break any dependent packages
[01:09] <cjwatson> So I'm justs uploading a no-change rebuild for that
[01:09] <cjwatson> *just
[01:18] <cjwatson> vte has a fix to an Ubuntu bug that has been getting "so when are you going to apply my clearly sensible patch?" (and it is clearly sensible) for months, and two security fixes
[01:19] <cjwatson> So I think I'll merge that
[02:00] <cjwatson> vte merge uploading, and that's the last of the armel rebuilds, so *zonk*
[02:00] <cjwatson> ARM builds starting to generally emerge from gecko, though it'll be ten more hours or so until those are entirely finished
[02:08] <cjwatson> cyphermox: I've accepted usb-modeswitch as the only remaining problem I can see is a very unlikely scenario; but I think you should check getenv's return for non-NULL before passing to strdup, as right now I think this will segfault if you run it with PATH missing from the environment
[02:08] <cjwatson> (not that it would probably work very well in that case anyway, but)
[02:08] <cjwatson> thanks
[06:06] <slangasek> ok, why was nvidia-graphics-drivers 304.51-0ubuntu1 let in during the freeze?
[06:06] <slangasek> bug #1063969
[06:06] <ubot2> Launchpad bug 1063969 in plymouth "No Plymouth Splash on Latitude E6420" [Undecided,New] https://launchpad.net/bugs/1063969
[06:10] <slangasek> I'm getting rather sick of having to chase down last-minute regressions in plymouth support with nvidia drivers due to last minute changes to the packaging
[06:13] <slangasek> cjwatson: ^^ from scrollback, it looks like you were probably the one who reviewed/accepted the nvidia packages; just a heads-up that there's a pattern of ill-tested last-minute packaging changes...
[06:53] <Daviey> cjwatson: I wasn't able to touch it yesterday at all.  It will be done today.
[07:16] <infinity> ^-- Who accepted those ppl binaries?
[07:16] <infinity> You just skewed it on armel and armhf...
[07:17] <infinity> Oh, nevermind, the only arch:all package is a -doc package anyway.
[07:18] <infinity> Although, ppl-dev should have probably been NEWed to main.  So, I'm back to "who did that?"
[08:11] <cjwatson> ^- should fix wrapitk-python/amd64 build failure
[08:14] <cjwatson> slangasek: Yeah, that was me, sorry - was it the gfxpayload blacklist change?  I assumed that was fixing a disease that was worse than the cure, sorry ...
[08:16] <slangasek> cjwatson: the "disease" it was fixing is entirely unsubstantiated in the referenced bug report :/
[08:16] <infinity> cjwatson: Accepted.
[08:16] <cjwatson> slangasek: *sigh*
[08:16] <cjwatson> infinity: thanks
[08:16] <infinity> slangasek: About the only validity the report appears to have is that it came from @nvidia.com, but yeah, it doesn't actually say what the problem *is*, just that there might be one.
[08:17] <infinity> Always irksome, that sort of "bug".
[08:17] <infinity> "This package might misbehave sometimes."
[08:17] <slangasek> ah, I didn't catch the submitter's domain
[08:17] <slangasek> but even so, bleh
[08:17] <cjwatson> Yeah, I think I took that as authoritative
[08:27] <slangasek> grr, grub2-signed override to main didn't take for the binary; promoting now
[08:28] <slangasek> (so today's images missed including it; probably not worth a rebuild for just that, we might as well get the d-i piece done first too)
[08:28] <cjwatson> slangasek: I already promoted
[08:28] <cjwatson> Yeah, not worth a rebuild, not like we worked on SB yet anyway ...
[08:32]  * slangasek nods
[09:44]  * ogra_ wonders why its always cjwatson's uploads that remind me of the sins of my youth ... and files bug 1064271
[09:44] <ubot2> Launchpad bug 1064271 in redboot-tools "please demote redboot-tools to universe" [Medium,Triaged] https://launchpad.net/bugs/1064271
[10:02] <seb128> gtk reverts http://git.gnome.org/browse/gtk+/patch/?id=5debed5ae247c1dd440cb71d0a6d328df74b0844 ("Shut down a11y when an app shuts down") to workaround https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1056300
[10:02] <ubot2> Ubuntu bug 1056300 in gtk+3.0 "If a GTK application quits the main loop and restarts it again, accessibility is lost." [High,In progress]
[10:03] <seb128> e.g "ubiquity looses a11y midway"
[10:03] <seb128> it's not a fix but it seems to safest option for release
[10:04] <xnox> seb128: yes, please. I am also confused how they managed to slip such a big feature so late in the 3.6 cycle.
[10:04] <seb128> it's not so much of a "feature" than an optimization...
[10:05] <seb128> but GNOME is not very good nowadays to be conservative about their changes (well, the same way we have issues pushing back on #ps changes to be fair)
[10:08] <xnox> seb128: well the point of that gtk commit, as far as I can see, is a workaround the apps that are not using GApplication(-shutdown) and hence don't clean up a11y resources at the end.
[10:09] <xnox> I am not sure if ubiquity should be using GApplication or not.
[10:09] <seb128> it's a good discussion to have with desrt at UDS ;-)
[10:10] <seb128> I'm not sure but, ubiquity is not really a standard "application", well not in sense of desktop application
[11:15]  * cjwatson tries to work out why wrapitk-python was deleted from quantal for other architectures
[11:15] <Laney> rejecting gdm - confused, asking a question
[11:17]  * Laney gets irritated at Launchpad wiggling in the launcher so often
[11:17] <cjwatson> "NBS libgdcm2.0, and no rdepends for python-insighttoolkit3"
[11:18]  * cjwatson suggests that removing non-NBS binaries of a source package still in the archive is not the best idea
[11:18] <doko> asked the schooltool maintainers about a FFe
[11:19] <Laney> you might want to reject so nobody accidently accepts then
[11:19] <doko> I'm not -release
[11:19] <Laney> or duplicates time reviewing
[11:19] <Laney> oh woe
[11:19] <cjwatson> ah, a simple rebuild would have fixed wrapitk-python, rather than removal, it seems
[11:19]  * cjwatson does that
[11:23] <jbicha> Laney: what was the gdm question?
[11:23] <Laney> about the prerm change
[11:23] <Laney> doko: I'm doing so. Please could you let them know what's happened?
[11:24] <jbicha> I've uninstalled gdm a few times and it's killed my X session which is not nice, I'm not sure there's any need for uninstallation to kill gdm
[11:24] <Laney> yeah possibly not
[11:24] <doko> Laney, done
[11:25] <Laney> ta
[11:25] <doko> Laney, please accept zope.interface, synced by cjwatson yesterday
[11:25] <Laney> looking at the rest now
[11:27] <Laney> the base revision chosen by LP for the e-d-s diff is curious
[11:27] <cjwatson> Probably the last one in -proposed
[11:27] <seb128> Laney, it's the previous upload to that pocket? like if that goes through proposed
[11:28] <cjwatson> The ancestry code is basically wrong
[11:28] <cjwatson> Needs a complete overhaul AFAICT
[11:28] <Laney> does indeed seem to be the previous -proposed upload
[11:54] <Daviey> cjwatson: freeipmi uploaded (i missed the convention local function on the last upload, now used.)
[11:55] <Daviey> kind to review sir?
[11:55] <cjwatson> Sure
[11:55] <cjwatson> When the diff arrives
[11:56] <Daviey> http://pb.daviey.com/0Dxi/
[12:00] <cjwatson> I needed code context anyway :)
[12:01] <cjwatson> That looks better now, thanks - accepted
[12:03] <cjwatson> Daviey: Per jdstrand, the MIR still needs these patches forwarded to Debian, and ubuntu-server added to bug subscribers
[12:10] <Daviey> cjwatson: Yep
[12:10] <cyphermox> cjwatson: no, it won't segfault. I tested this by itself in a quick little program by itself
[12:10] <cjwatson> strdup(NULL) is not defined
[12:11] <cyphermox> why am I duplicating words ;)
[12:11] <cyphermox> cjwatson: oh wait, you mean if PATH is undef
[12:11] <cjwatson> Unset, not empty
[12:11] <cyphermox> right
[12:11] <cyphermox> in the case where usb-modeswitch-dispatcher gets run (by udev), very unlikely to happen
[12:12] <cjwatson> As I say, corner case and will probably fail somewhere else anyway - I just don't like leaving segfault cases around unhandled
[12:12] <cjwatson> (Which is why I accepted with a comment rather than rejecting)
[12:12] <cyphermox> sure. I'll fix it first thing in R; I'll start a list now
[12:14] <cjwatson> ta
[12:14] <doko> cjwatson, is it ok to update base-files for the rc?
[12:14] <cjwatson> doko: We're not doing an RC as such
[12:15] <cjwatson> Just incrementally better until release :)
[12:15] <cjwatson> doko: But yeah, probably might as well
[12:15] <doko> ok
[12:59] <doko> python3-stdlib-extensions: needed to build the _gdbm and _tk extensions for 3.3. talked with jdstrand that it's ok to have it main for q
[13:00] <cjwatson> seeding and promoting linux-signed - same rationale as slangasek gave earlier for grub2-signed
[13:07] <smartboyhw> Jesus
[13:07] <smartboyhw> There are 7 days left in the current cycle. That means that in order to complete all the work 90.29 workitems must be completed per day.
[13:08] <smartboyhw> OMG
[13:09] <chrisccoulson> hey, is someone able to approve flash, please? :-)
[13:10]  * GridCube gives smartboyhw a chamomile tea
[13:10] <smartboyhw> GridCube, thx:D
[13:20] <ara> morning release team!
[13:20] <ara> currently, many udev related tests in checkbox are broken, as they are not using udisk2
[13:20] <ara> would this fix require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035
[13:20] <ubot2> Ubuntu bug 1016035 in checkbox "Add udisks2 support to scripts/removable_storage_* scripts" [High,In progress]
[13:30] <cjwatson> Reviews of base-installer and grub-installer would help unblock me a little - more secure boot madness
[13:31] <didrocks> Laney: I think you may consider that upload for quantal finale. I tried to be as descriptive as possible in the changelog, but do not hesitate to ask me anything else :) ^
[13:32] <stgraber> cjwatson: I'll take a look in a minute
[13:33] <Laney> didrocks: oui mon ami
[13:33] <didrocks> Laney: merci! :-)
[13:34] <jdstrand> cjwatson: did you get an answer on linux-signed (sorry for the delay-- holiday)
[13:35] <cjwatson> jdstrand: on which aspect?
[13:35] <Daviey> Anyone object to me doing a server spin?
[13:35] <jdstrand> cjwatson: you asked me about promoting it with a mir
[13:35] <jdstrand> without a mir
[13:35] <cjwatson> Daviey: component-mismatches looks pretty unresolved
[13:35] <cjwatson> jdstrand: oh, I JFDIed that a little earlier today
[13:35] <cjwatson> and figured I'd apologise if somebody objected
[13:36] <jdstrand> cjwatson: ok, based on what you said a few days ago, I would have said as much\
[13:36] <cjwatson> ok, good
[13:36] <Daviey> cjwatson: I think c-m just needs a refresh
[13:37]  * cjwatson looks at rmadison output
[13:38] <cjwatson> mm, out of sync across architectures.  I'll fix
[13:38] <Daviey> cjwatson: I have just fixed
[13:38] <cjwatson> server spin is fine then as long as it's just amd64/i386
[13:38] <Daviey> That is all i want for this spin
[13:39] <cjwatson> Actually, freeipmi-common was in universe
[13:39] <cjwatson> Oh, but that's NBS
[13:39] <cjwatson> This is confusing :)
[13:39] <cjwatson> I guess this will settle down in a bit.  At the moment I can't say whether a server spin is likely to work
[13:40]  * Daviey leaves it another hour, for giggles
[13:40] <cjwatson> Yeah, if I were you I'd let the automatic reports have a chance to catch up before spending any manual time on it
[13:40] <Daviey> yeah, ok. Thanks
[13:45] <stgraber> cjwatson: accepted
[13:46] <cjwatson> stgraber: thanks
[13:46] <cjwatson> ooh, webkit/armhf succeeded
[13:46] <Laney> nice
[13:47] <Laney> armel is nearly there too
[13:47] <cjwatson> Yeah
[13:47] <Laney> glorious
[13:48] <Laney> I got some new puncture proof tyres for my bike over lunch too — truly a day for vanquishing broken old crap
[13:50] <apw> the recent linux-meta upload fixes an issue where installing linux-crashdump on an efi system uninstalls your bootloader
[13:50] <cjwatson> apw: haha
[13:50] <cjwatson> We rule
[13:50] <apw> cjwatson, i thought so :)
[13:50] <cjwatson> Eh, that's not really right - grub-efi is a transitional package
[13:51] <cjwatson> Should be grub-efi-ia32 | grub-efi-amd64
[13:51] <ara> cjwatson, do you think this would require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035
[13:51] <apw> cjwatson, if you reject it can we re-use the version number ?
[13:51] <ubot2> Ubuntu bug 1016035 in checkbox "Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
[13:51] <cjwatson> apw: yes
[13:51] <apw> ok do that, lets git it right
[13:52] <cjwatson> apw: ok, done, please pass on to smb
[13:52] <cjwatson> ara: sorry, eyebrow-deep in secure boot right now, no spare brain
[13:52] <cjwatson> if in doubt, upload, it'll be queued and reviewed anyway
[13:52] <ara> cjwatson, OK, now worries
[13:52] <ara> cjwatson, OK, thanks
[13:53] <stgraber> zul: ping
[13:53] <zul> stgraber:  whats up?
[13:54] <stgraber> zul: cinder in the queue does a dh_fixperms -X on nova_tgt.conf but the rest of the diff refers to cinder_tgt.conf
[13:54] <zul> stgraber: crap can you reject it please ill upload a fix
[13:54] <stgraber> zul: ok
[14:06]  * stgraber assumes we want to keep base-files in the queue until FinalFreeze and leaves it there
[14:11] <skaet> ev, are there any more fixes expected for WUBI?   ( its time to ask IS to prepare the signed copy)
[14:11] <ev> skaet: credit where credit is due, cjwatson has been doing all the fixes. I've just been building the binaries
[14:11] <ev> I am unaware of any further changes that need to be made
[14:12] <cjwatson> likewise, for the moment
[14:12] <skaet> fair 'nuf ;)
[14:12] <ev> so we can most certainly put in an RT for the signed copy
[14:12] <cjwatson> not much changed this cycle
[14:12] <ev> shall I sort that out then?
[14:12] <skaet> thanks cjwatson, ev - doing.
[14:12] <ev> ah
[14:12] <ev> excellent
[14:12] <ev> :)
[14:12] <cjwatson> haven't had my recent fix for Tibetan verified, but well
[14:12] <cjwatson> best-effort at this point given everything else :-/
[14:14] <ogasawara> skaet: the kernel team would like to get a freeze exception for a kernel upload.  It would be to resolve the following: bug 1063061, bug 1061599, bug 1021471, bug 1030233, bug 717970
[14:14] <ubot2> Launchpad bug 1063061 in linux "please backport support for EFI vars > 1KB" [Medium,In progress] https://launchpad.net/bugs/1063061
[14:14] <ubot2> Launchpad bug 1061599 in linux "beagle: omap3: usb is dead" [Undecided,Fix committed] https://launchpad.net/bugs/1061599
[14:14] <ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
[14:14] <ubot2> Launchpad bug 1030233 in linux "not have bluetooth usb 0489:e046 Foxconn / Hon Hai" [Medium,Fix committed] https://launchpad.net/bugs/1030233
[14:14] <ubot2> Launchpad bug 717970 in linux "After sleep, key presses get lost and trackpad is jittery" [High,Fix committed] https://launchpad.net/bugs/717970
[14:16] <skaet> ogasawara,  will we need a d-i as well?
[14:16] <ogasawara> skaet: I don't believe it is an ABI bump, so no
[14:17] <skaet> ogasawara, ok,   have all the fixes been independently verified?  ( like we would for SRU?)
[14:17] <ogasawara> skaet: yep, all thoroughly tested
[14:17] <skaet> ogasawara, coolio.  If the kernel is ready to upload, rather get it in sooner than later.
[14:18] <rtg> ogasawara, we don't have a patch set yet for 1063061
[14:18] <ogasawara> skaet: ack I still need to get the final patch revisions for 1063061 from apw but am told it will be ready shortly
[14:18] <ogasawara> rtg: ^^
[14:19] <skaet> ogasawara,  understood.   just to confirm - plan is to revert if any issues found with this latest kernel?
[14:19] <rtg> ogasawara, hmm, it had a lot of issues and I'm not sure we'll be able to test it sufficiently.
[14:19] <ogasawara> skaet: indeed, that would be the plan if any regressions appear
[14:19] <ogasawara> rtg: hrm, maybe we should make sure we're both on the same page with apw
[14:19] <rtg> yeah
[14:20] <cjwatson> ironically 1063061 is the only one of those I care about ;-)
[14:22]  * stgraber cares about bug 1021471 (makes LXC almost unusable on 12.10)
[14:22] <ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
[14:22] <Laney> yes :-)
[14:22]  * Laney is trying to do a stgraber on this new install and have no dev packages installed on the bare metal
[14:22] <Laney> using lxc for dev
[14:23] <cjwatson> skaet: there'll necessarily be at least one more d-i anyway
[14:24] <cjwatson> so I don't think we should worry about that either way
[14:25] <skaet> cjwatson,  ok.
[14:26] <cjwatson> (general catchup; SB work)
[14:28] <cjwatson> yay, webkit/armel finished
[14:28] <doko> cjwatson, stgraber: webkit now built in -proposed for armel and armhf. please promote to quantal so that ephiphany can start building
[14:28] <doko> heh
[14:29] <cjwatson> doko: I'm going to wait for a publisher run
[14:29] <cjwatson> I am taking absolutely no risks here
[14:29] <cjwatson> At least process-accepted, anyway; actually getting it onto disk doesn't matter
[14:49] <cjwatson> doko: copied
[14:49] <cjwatson> ^- that grub2 upload is critical path for secure boot images
[14:49] <stgraber> cjwatson: will review
[14:50] <doko> cjwatson, could you have a look at the python3-stdlib-extensions upload?
[14:50] <stgraber> cjwatson: can you review isc-dhcp and ifenslave-2.6 in exchange? :)
[14:51] <cjwatson> one at a time :)
[14:54] <stgraber> cjwatson: accepted
[14:54] <cjwatson> doko: Have you already convinced somebody else on the MIR team that it's OK to promote python3.3?
[14:55] <cjwatson> stgraber: shorter form: BOND_SLAVES="${BOND_SLAVES:+$BOND_SLAVES }$name"
[14:55] <doko> cjwatson, from my point of view not needed, only a new upstream version. got approval from jdstrand from a security point of view, and from barry from a technical point of view
[14:55] <cjwatson> But accepted the increasingly inaccurately named ifenslave-2.6
[14:56] <cjwatson> doko: In that case it's fine - I assume you're ready to promote python3.3 so that this can build?
[14:56] <doko> right
[14:56] <cjwatson> OK, accepted
[14:58] <cjwatson> stgraber: and isc-dhcp is fine too, accepted
[14:59] <stgraber> cjwatson: thanks
[15:20] <skaet> cjwatson, stgraber, infinity, Laney, and other members of the release team ;) - pitti is uploading apport shortly for the switch over to only have it reporting to errors.ubuntu.com.   Please don't accept it in until we're ready to try for the release candidates.
[15:21] <Laney> do the standard reject/accept trick on it then?
[15:21] <skaet> Laney, yeah, I think that best
[15:22] <skaet> will you do the honors, or do you want me to?
[15:22] <Laney> feel free
[15:23] <stgraber> btw, shouldn't we have done the same with base-files? I just noticed it was accepted (removing the "dev release" tag from lsb_release and similar tools)
[15:24] <skaet> stgraber,  yes.  anything with timing issues around it should go to reject,  so accidents don't happen.
[15:24] <Laney> not really the end of the world though
[15:25]  * skaet nods
[15:45] <cjwatson> Sigh, could really use ARM catching up a bit - this is hard to manage
[15:48] <stgraber> cjwatson: if you have a minute, can you look at ifupdown?
[15:48] <bdmurray> I've an upload of update-manager to precise-proposed that may help with diagnosing upgrade errors so it would be good to get it in precise.
[15:49] <cjwatson> stgraber,jodh: oh, nice catch (ifupdown)
[15:49] <jodh> cjwatson: thanks :)
[16:05] <zul> can you reject the horizon please?
[16:06] <ScottK> zul: Done.
[16:07] <zul> thanks
[16:16] <balloons> slangasek, can you add back the amd64, i386 isos for ubuntu and ubuntu server for beta1?
[16:19] <balloons> slangasek, http://cdimage.ubuntu.com/releases/quantal/beta-1/ s missing these images and they are needed for upgrade testing from beta1 to rc
[16:20] <cjwatson> You can't expect old images to hang around after the next milestone is released
[16:20] <cjwatson> If your process assumes that then your process needs to be fixed
[16:20] <balloons> cjwatson, I know.. but I'm looking and seeing that beta2 has been gutted also
[16:20] <cjwatson> Err, no
[16:20] <Laney> No. You need to look on releases.u.c
[16:20] <cjwatson> desktop and server images live on releases.u.c
[16:21] <balloons> http://releases.ubuntu.com/quantal/
[16:21] <cjwatson> Yes
[16:21] <balloons> this was a request by skaet to test an install of beta1 and upgrade to current
[16:22] <cjwatson> You'll have to get it from somewhere else
[16:23] <cjwatson> In any case, you'd only be able to do a beta-1 install now if it were networkless ...
[16:23] <cjwatson> Otherwise it'd be a hybrid
[16:23] <Laney> Yeah, not massively sure any such test results will be useful
[16:24] <balloons> fair enough. ty cjwatson and Laney
[16:24] <cjwatson> skaet: what are you trying to learn from this that you wouldn't learn from an upgrade from precise?
[16:25] <xnox> balloons: if he had snapshots archive, it would be interesting to install from beta1 archive snapshot & dist-upgrade to -rc archive snapshot or final.
[16:25] <xnox> balloons: but we don't have archive snapshots.
[16:25] <cjwatson> If we want to do this kind of thing, we would need to plan ahead - e.g. archive test installs done at beta-1 time
[16:26] <cjwatson> I plan to clean beta-1 entirely off cdimage fairly soon - it should have been done at beta-2, really
[16:34] <slangasek> balloons: hrm, why is upgrade testing from beta1 to rc anything that you are focusing on?
[16:35] <slangasek> ah, see that's answered in scrollback
[16:35] <balloons> slangasek, we'll have to await skaet for that answer. I believe she wanted to check unity regressions
[16:35] <jdstrand> infinity: iirc, you asked over the weekend about firefox 16 going to quantal-- I think it needs to go, but we need to test a bit more
[16:35] <infinity> jdstrand: Check.
[16:36] <infinity> jdstrand: At least it's all built now. ;)
[16:36] <jdstrand> infinity: indeed-- was that the main bit you cared about? ie, can I just pocket copy to quantal after testing?
[16:36] <cjwatson> infinity: firefox/quantal-proposed is still needs-build, actually
[16:36] <infinity> cjwatson: 16, not 15.
[16:36] <cjwatson> If that's what you mean ...
[16:37] <jdstrand> these are in https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages
[16:37] <cjwatson> Oh
[16:37] <cjwatson> Does that include the changes in quantal-proposed?
[16:37] <jdstrand> chrisccoulson: ^
[16:38] <chrisccoulson> jdstrand, cjwatson, yeah, it's got all of the changes from quantal-proposed
[16:38] <infinity> And more, apparently.
[16:38] <infinity> Newer version of globalmenu again.
[16:38] <cjwatson> Then it would be ideal to copy it sooner rather than later and supersede -proposed
[16:38] <cjwatson> Since we're short of build time and there's no point in duplicate ten-hour builds
[16:39] <jdstrand> I'm happy to do that. we need to test i386 a bit more though
[16:39] <skaet> cjwatson, balloons,  sorry, was otp.   Want to make sure that those end users who have installed beta 1 don't have any big surprises esp. on i386/amd64.    We can release note if the only issues are on arm - but it would be good to know what they'll be seeing.
[16:39] <infinity> I can just delete 15 from proposed if we definitely plan to copy 16.
[16:39] <jdstrand> the security issues warrant it
[16:39] <infinity> Yeah, that's why I was pushing for it.
[16:39] <cjwatson> skaet: it just seems like an oddly specific thing to focus on - one would expect that for the most part any issues seen upgrading from 12.04 would be a superset
[16:39] <infinity> Doesn't seem to make sense to wait and do a 0-day security release.
[16:40] <jdstrand> no
[16:40] <cjwatson> skaet: and I really don't want to go resurrecting beta-1 images when QA apparently doesn't already have copies
[16:40] <jdstrand> this one is pretty important based on the upstream advisories
[16:41] <infinity> jdstrand: What about thunderbird 16, has it been tested?
[16:41] <jdstrand> not yet, I'll be testing that next
[16:41] <infinity> jdstrand: (Copying that one would also get us out of doing two long builds)
[16:41] <jdstrand> that one hasn't been tested at all btw. firefox/amd64 has been
[16:42]  * jdstrand is working on these as we speak-- tbird will be a little while though
[16:42] <infinity> jdstrand: Alrighty.
[16:44] <skaet> cjwatson, ??  Why were the copies of the beta 1 images removed for desktop and server?   They are still there for cloud...http://cloud-images.ubuntu.com/releases/quantal/beta-1/
[16:44] <skaet> infinity, ^ ?
[16:44] <cjwatson> skaet: We always remove the previous milestone when publishing the next one.  We have done ever since long before you joined
[16:45] <cjwatson> skaet: Cloud has an entirely separate publishing process that is nothing to do with me
[16:45] <slangasek> cjwatson: so we're not expecting gcdx64.efi to work for netboot at this stage, right?  Given that /.disk/info will not exist
[16:45] <cjwatson> There isn't even a defined location where previous versions of the ones that go on releases.ubuntu.com mightgo
[16:45] <cjwatson> slangasek: No, that would need the Fedora fw_path patch I think
[16:45] <slangasek> ok
[16:45] <skaet> balloons, can you please test for beta2 forward then.
[16:46] <utlemming> skaet: the policy for the cloud images is to provide all milestones indefinately. There was a revolt a bit back on about removing previous milestones.
[16:46] <cjwatson> Right, that is definitely not the policy for cdimage and never has been
[16:46] <balloons> skaet, lol. I originally announced it as beta2, re-sent the clarification 30 mins ago that we wanted beta1
[16:47] <infinity> utlemming: That's a strange policy.
[16:48] <infinity> utlemming: Interesting for QA bisection, somewhat confusing to present users with an option to use images that aren't based on release versions (and probably lack an obvious route to the matching source, too)
[16:48] <cjwatson> I don't want to reinforce any notion that it's just as OK for people to install beta-1 as beta-2 and that we'll support them both.  errors.ubuntu.com indicates that we have a hard enough time getting users to upgrade as it is.
[16:49] <utlemming> infinity: the bisection is part of why they are there. But if you look http://cloud-images.ubuntu.com/releases you'll see that we have a whole library of all the images that have been declared "release" or "milestone"
[16:49] <skaet> utlemming, cjwatson - something to discuss at UDS.   cjwatson, understand your point, keeping them accessible without heroics, so we can set expectations of the experience a bit better seems prudent if we have the space.
[16:49] <skaet> but they shouldn't be an easy default.
[16:49] <cjwatson> We don't have the space to do it for any more than a short period of time.
[16:50] <utlemming> for the cloud-images, space is easy -- we use the cloud
[16:51] <skaet> cjwatson,  maybe doing what utlemming is doing might make some sense?
[16:51] <infinity> utlemming: There's probably some GPL violation going on there.
[16:51] <cjwatson> skaet: I'd rather not.
[16:51] <cjwatson> I'm honestly quite happy with the way it is ...
[16:52] <infinity> skaet: People installing from old media has always been a problem, any publishing of old media just encourages it.
[16:52] <cjwatson> I don't want us to have to maintain a full library of all milestones.  We build a much larger family of images than cloud-images does.
[16:53] <cjwatson> And for bisection, it's usually enough to bisect between packages, and they're in the librarian.
[16:53] <skaet> cjwatson,  am not advocating all milestones,  only the betas
[16:53] <cjwatson> I don't think they're particularly special for this.
[16:54] <cjwatson> It took errors.ubuntu.com much longer to stop showing errors from beta-1 than it should have done
[16:54] <skaet> yeah,  I noticed that too.
[16:54] <cjwatson> A ubiquity crasher fixed in beta-2 was the top crasher there for well after beta-2 was released
[16:54] <cjwatson> That says to me that *any* increase in visibility of beta-1 would be a mistake
[16:55]  * ScottK agrees with cjwatson
[16:56] <skaet> Understood.   It leaves us without a good way of understanding what will happen to the beta1 users when they try to update to the release candidate, but that is the tradeoff then.
[16:56] <Daviey> cjwatson: surely it's only a violation if a user requests the source, and it isn't provided?  Isn't this just a case of having binaries hanging around?
[16:56] <Daviey> (with the source available)
[16:56] <cjwatson> Daviey: I didn't mention violations.
[16:57] <Daviey> Ah, my eyes are too slow.. it was infinity.
[16:57] <cjwatson> But we are equally without a good way of understanding what will happen to the beta-1 users who'd last updated a week after beta-1, or two weeks after beta-1, and then upgraded to rc
[16:58] <cjwatson> We do not in general encourage users to upgrade only at milestones; we strongly encourage them to upgrade continuously over the network
[16:58] <cjwatson> (e.g. by popping dialogs up in their faces)
[16:58] <ScottK> If you run the development release and don't update for weeks at a time, I think you own whatever happens
[16:59] <skaet> closer to rc,  less update churn,  less concern.   Its the earlier ones that were lingering I was concerned about.
[16:59] <infinity> Daviey: As long as launchpad keeps every source package ever (a promise we've not made for !release versions, though it may currently be true), then yes, it's only a violation in spirit to not provide a source CD, not in letter.
[17:00] <skaet> However,  its moot for now.    A possible UDS discussion.   I agree its not worth resurrecting the beta 1 images.
[17:02] <infinity> I, like Colin, see no real reason to discuss this at UDS.
[17:04] <cjwatson> Dear gtk+3.0/armel: please finish building so that the world's installable again there
[17:04] <cjwatson> (OK, in -proposed)
[17:04] <cjwatson> infinity: You don't happen to know how to clear the stuck pyorbit build on chort, do you?  See #launchpad-ops backlog
[17:06] <cjwatson> (FWIW, we keep the *logs* of old image builds available essentially forever, so that developers can do archaeology)
[17:06] <infinity> cjwatson: Oh, weird.
[17:27] <stgraber> Laney: I noticed you reviewed bug 1064232, can you also review bug 1051162?
[17:27] <ubot2> Launchpad bug 1064232 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for installer slideshow in Ubuntu 12.10" [High,Triaged] https://launchpad.net/bugs/1064232
[17:27] <ubot2> Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162
[17:28] <stgraber> I'd prefer to do a single upload before we freeze for good (with updated translations and all the FF that were approved)
[17:28]  * ogra_ has an ubuntu-meta upload pending ... anyone else wanting any seed changes before i generate the package ?
[17:28] <stgraber> I know I could review bug 1051162 myself, but I really don't have an opinion on it.
[17:28] <ubot2> Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162
[17:31] <infinity> stgraber: Seems reasonable to me.
[17:37] <infinity> cjwatson: armel-rebuild is done, I'm guessing, from your text file?  (linux-linaro-* don't need rebuilding, obviously, and I assume there's a reason you skipped zope.interface?)
[17:37] <Laney> stgraber: yeah, sure, if gnome remix guys are happy with it
[17:38] <cjwatson> infinity: zope.interface is building/recently-built
[17:38] <infinity> Ah-ha.  So, done.  Yay.
[17:38] <cjwatson> infinity: So yeah, it's done modulo publisher
[17:38] <Laney> Doesn't seem to have reviews though, so you might want to check
[17:38] <cjwatson> Let queue reviewers rejoice
[17:38] <jdstrand> infinity: so, as it turns out, tbird won't be released by upstream until tomorrow
[17:39] <jdstrand> infinity: when is the latest we could push it into quantal?
[17:39] <cjwatson> infinity: still building, actually, on heka
[17:39] <ogra_> slackers
[17:39] <doko> cjwatson, looking at http://www.freedesktop.org/software/systemd/man/os-release.html /etc/os-release for precise. VERSION_ID may not contain white space, so either set it to 12.04, or 12.04-LTS?
[17:39] <skaet> jdstrand,  so 0 day SRU.
[17:39] <infinity> jdstrand: Tomorrow's fine with me.
[17:39]  * jdstrand got conflicting responses
[17:39] <cjwatson> doko: you're the os-release guru :)
[17:39] <skaet> infinity,  how will that interact with the translations landing?
[17:39] <skaet> we need to have the release candidates on Thursday.
[17:40] <jdstrand> tbird has its own locales...
[17:40] <cjwatson> doko: personally I'd be inclined to suggest just 12.04 there, from the description, but I suppose it could go either way
[17:40] <jdstrand> eg thunderbird-locale-zh-tw
[17:40] <doko> cjwatson, well, I would keep it as 12.04 for consistency. the pretty names include  the LTS anyway
[17:40] <doko> ok
[17:40] <cjwatson> "mostly numeric"
[17:40] <infinity> skaet: What jdstrand said.
[17:41] <infinity> skaet: thunderbird and firefox translations are completely decoupled from langpacks.  If they weren't, our policy of new upstream releases in security would be a nightmare.
[17:41] <skaet> infinity,  its the build time I'm worrying about.
[17:41] <infinity> skaet: It's already built.
[17:41] <jdstrand> infinity: so, I guess we can't kill the tbird builds... if upstream delays past tomorrow, then we'd need 15 for the images
[17:42] <slangasek> bweh, why is os-release needing backported to 12.04?
[17:42] <jdstrand> skaet: these are staged in the ubuntu-mozilla-security ppa, all built and ready
[17:42] <skaet> jdstrand,  if the are already build, then we have more flexibility.
[17:42] <infinity> jdstrand: Honestly, if you guys have it well-tested, I'm happy squeezing it in just about any time, as long as there are other image builds going too.  Waiting a week for a 0-day security release seems silly.
[17:43]  * skaet would like to understand what has been tested though
[17:43] <ogra_> slangasek, to make myunity not source /etc/lsb-release ?
[17:43] <ogra_> :)
[17:43] <infinity> jdstrand: (But we may end up building 15 anyway, it's just not high on the queue right now)
[17:43] <jdstrand> infinity: ok-- my amd64 testing looks good overall-- we need a newer enigmail and I've yet to test lightning yet, but it is solid overall
[17:44] <jdstrand> infinity: I'll let you decide on 15 then
[17:44] <jdstrand> (to build or not to build)
[17:44] <doko> slangasek, was a request in the report. I think it's harmless, and only useful for third party vendors
[17:44] <jdstrand> infinity: we also have reports that i386 is good too, so 16 seems pretty solid
[17:44] <jdstrand> I'll report back if I have an issues
[17:45] <skaet> jdstrand, how is arm looking
[17:45] <infinity> jdstrand: Alright, cool.  Push enigmail (and lightning, if required) to the PPA ASAP too, so we can just do a batch copy if/when we want to.
[17:45] <jdstrand> it is built. I don't have arm machines
[17:45] <infinity> skaet: It can't be any worse than 15 on ARM, which hasn't built yet, so hasn't been tested. :P
[17:46] <jdstrand> that may change in the future, but we currently only test i386 and amd64
[17:46] <slangasek> doko: are there specific third-party vendors that need this?  Otherwise, it doesn't seem to me to be a good use of time to SRU for - especially since it would need to be SRUed into all supported releases to have the intended effect
[17:46] <doko> stgraber, did you leave DISTRIB_RELEASE untouched by intent for the .1 release?
[17:46] <jdstrand> infinity: re pushing-- lightning is there, it needs testing. enigmail also happens to be there, but we need a newer. ack
[17:46] <stgraber> doko: yes, IIRC the documentation says not to touch DISTRIB_RELEASE
[17:47]  * jdstrand resumes testing
[17:47] <stgraber> doko: "Upload a new base-files package to -proposed to bump the lsb_release description (example for 8.04.4). Do not change the DISTRIB_RELEASE value, which is used programmatically by third-party software." <- https://wiki.ubuntu.com/PointReleaseProcess
[17:48] <cjwatson> OK.  component-mismatches clear (next publisher), priority-mismatches clear, architecture-mismatches clear (once my fso-frameworkd upload is reviewed, built, and published), NBS will be clear once epiphany-browser finishes on ARM, quantal_probs not clear but I think it's just lagging builds, quantal_outdate_all probably the next hitlist
[17:48] <cjwatson> Getting there
[17:48] <skaet> Thanks cjwatson
[17:49] <cjwatson> doko: Yeah, we've had trouble in the past from changing DISTRIB_RELEASE so we don't
[17:49] <doko> slangasek, no specific. I'll add patches for python and openjdk to use it. and at least the openjdk updates tend to go to older releases too
[17:49] <infinity> cjwatson: _probs all looks like armhf lag to me, yeah.  I was about to work on outdate_all as well.
[17:49] <cjwatson> Be my guest.  EOD is somewhere in the near future for me.
[17:49] <doko> stgraber, cjwatson: ok, doing the same with VERSION_ID
[17:49] <slangasek> doko: that doesn't sound like third-party to me if you're talking about doing it in Ubuntu
[17:49] <slangasek> nothing in Ubuntu should rely on /etc/os-release
[17:49] <cjwatson> Wouldn't mind clearing some of those ruby build failures for real.
[17:51] <infinity> cjwatson: Couldn't we just use copy tricks to fix fso-frameworkd?
[17:52] <cjwatson> Not sure.  I preferred to keep it simple, really.
[17:53] <infinity> cjwatson: Actually, is fixing it even necessary?
[17:53] <cjwatson> It's only a five-minute build on one architecture.
[17:53] <cjwatson> infinity: It shows up on architecture-mismatches, so I wanted to clear it properly.
[17:53] <infinity> cjwatson: arch-mismatches is whining because the arch:all binary only exists on armel, but the arch:any binary only exists on armel...
[17:53] <cjwatson> And it has some rdepends.
[17:53] <doko> slangasek, not relying, just using it. platform.linux_distribution() is part of the standard library
[17:53] <cjwatson> The arch:all binary should exist on armel, though, shouldn't it?
[17:54] <infinity> cjwatson: It does.
[17:54] <cjwatson> Right now it doesn't (well, not at the right version)
[17:54] <doko> for openjdk, it's just used to identify the OS in core dumps
[17:54] <infinity> cjwatson: At least, that's how I read it?
[17:54] <cjwatson> It's an old version, according to rmadison
[17:54] <cjwatson> I was trying to clear it out of outdate_all last week and I think I made a mistake
[17:54] <cjwatson> (Nothing really reports on partial NBS so it has to be cleared by hand)
[17:54] <infinity> Hrm.
[17:55] <pitti> hello all
[17:55] <infinity> Will rmadison actually show if :all exists in more than one version on different arches, or just pick one to report on?
[17:55] <pitti> I just noticed that I forgot to sync udisks2 yesterday (I uploaded it to experimental on Friday, but it didn't get imported into LP in time)
[17:56] <cjwatson> I think it collects them.
[17:56] <pitti> it updates from our git snapshot to the official 2.0.0 release; it's got some nontrivial changes, but I'm happy to answer any question about it
[17:56] <cjwatson> Hmm
[17:56] <cjwatson> It's an architecture: all from a source not built on i386
[17:56] <pitti> I've been running it on my machine since Thursday, and it has quite an exhaustive test coverage
[17:56] <cjwatson> So actually there's no way to build it in our build system
[17:57] <cjwatson> The Debian maintainer presumably does a -b build on armel ...
[17:57] <infinity> Right, there isn't.
[17:57] <cjwatson> So yeah, reject that then.  I'll just have to remove the arch all binary, and think about its rdepends
[17:59] <doko> anyway, afk now
[18:00] <infinity> cjwatson: Or drop fso-frameworkd-gta* from the packaging, so it's pure arch:all.
[18:00] <cjwatson> That sounds like it requires thought.
[18:00] <zyga> hi
[18:01] <cjwatson> infinity: If you understand it can I convince you to do something about it? ;-)
[18:01] <infinity> cjwatson: Yeah, sure.
[18:01] <cjwatson> Awesome.
[18:01] <infinity> cjwatson: It just means dropping some armel-only other bits too, which doesn't seem like a huge loss.
[18:01]  * cjwatson rejects his upload
[18:01]  * zyga is here for https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
[18:02] <zyga> if anyone has questions -please ping me about it-
[18:02] <infinity> (making "!x86 all" builds work might be a nice goal, though)
[18:06] <cjwatson> Ooh, yay, NBS cleared.
[18:06]  * infinity cheers.
[18:07] <infinity> And it only took two weeks to build epiphany and do it.
[18:07] <infinity> Oh, hey, only one week.  I guess I'm having temporal issues.
[18:09] <infinity> Copied gtk+3.0 to release.
[18:26] <skaet> :)
[18:37] <jdstrand> skaet, infinity: fyi, enigmail is fixed, lightning works, and tbird testing shows it works fine. we are only waiting on upstream now
[18:37] <jdstrand> (well, and enigmail to build in the ppa, but that won't take long)
[18:37] <jdstrand> chrisccoulson: thanks ^
[18:40] <skaet> jdstrand.  ok.
[18:43] <infinity> jdstrand: In that case, are you okay with us killing all the tbird/ffox quantal 15 quantal builds and assuming we'll get 16 for sure in the next day or three?
[18:44] <jdstrand> infinity: I think so, yes
[18:45] <infinity> Right, then.  Removing ffox from proposed, and setting about killing some things to free up buildd time.
[19:02] <ogasawara> skaet, infinity: I've uploaded the kernel (no ABI bump).  It just needs approval in the queue.  After discussion, we decided to wait to include the patches for bug 1063061 and handle it as an SRU instead.  So this upload is intended to fix the bugs I mentioned earlier, ie bug 1061599, bug 1021471, bug 1030233, and bug 717970
[19:02] <ubot2> Launchpad bug 1063061 in linux "please backport support for EFI vars > 1KB" [Medium,In progress] https://launchpad.net/bugs/1063061
[19:02] <ubot2> Launchpad bug 1061599 in linux "beagle: omap3: usb is dead" [Undecided,Fix committed] https://launchpad.net/bugs/1061599
[19:02] <ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471
[19:02] <ubot2> Launchpad bug 1030233 in linux "not have bluetooth usb 0489:e046 Foxconn / Hon Hai" [Medium,Fix committed] https://launchpad.net/bugs/1030233
[19:02] <ubot2> Launchpad bug 717970 in linux "After sleep, key presses get lost and trackpad is jittery" [High,Fix committed] https://launchpad.net/bugs/717970
[19:02] <skaet> ogasawara, ack
[19:03] <skaet> infinity,  you able to review it through?
[19:04] <infinity> skaet: Aye.
[19:05] <skaet> infinity, thanks.
[19:05] <infinity> ogasawara: Any idea if ti-omap4 and armadaxp will get a final rebase to this version as well?
[19:06] <ogasawara> infinity: we can likely get ti-omap4 rebased and uploaded.  I'll need to nudge ike about armadaxp.
[19:07] <infinity> ogasawara: Both would be lovely, so they land in the release d-i.
[19:07] <ogasawara> infinity: ack
[19:07] <infinity> apw: lowlatency rebase, if you please, and a reminder about getting me access to that tree. ;)
[19:08] <apw> infinity, waiting on your acceptance :)
[19:08]  * infinity peers at the queue.
[19:08] <infinity> Lies and subterfuge.
[19:08] <infinity> Or you mean waiting on me reviewing and accepting linux?
[19:09] <infinity> I suppose that's fair. :P
[19:09] <infinity> I'm waiting on LP to provide me a useful diff, cause I'm tethering on 3G and have no urge to download the whole source package.
[19:12] <ogra_> infinity, hmm. you added the touch for the oem-config enabling to live-build ... somehow that touched file isnt in the tarball (nothing that needs to be solved now ... just noticed it)
[19:13] <infinity> ogra_: I suspect you're quoting distant past.  This relates to ac100 tarballs?
[19:13] <ogra_> yeah
[19:14] <ogra_> i'm abusing tehm for another project atm
[19:14] <ogra_> and noticed the file isnt there
[19:14] <ogra_> doesnt affect ac100 since that checks for it and touched it if its no available
[19:14] <ogra_> *touches
[19:14] <infinity> ...
[19:14] <infinity> Then I'm not sure why live-build would have done it at all?
[19:14] <infinity> Cause jasper did it too, didn't it?
[19:15] <ogra_> yep
[19:15] <roadmr> Hello! Is it still OK to upload a last-minute version of checkbox? (has udisks2 support which is rather important). https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
[19:15] <infinity> ogra_: I see no mention of oem-config in live-build at all, I think you may be mistaken. :)
[19:15] <ogra_> but we discussed it in the past and both aggreed it should be done in live-build instead
[19:15] <ogra_> err, livecd-rootfs indeed
[19:15] <infinity> ogra_: We may have discussed it, it clearly never happened.
[19:15] <infinity> Oh, indeed.
[19:16] <roadmr> our beloved sponsor is reviewing it but wanted to know if it's Ok to do the upload
[19:16] <ogra_> sorry, mixing package names here
[19:16] <infinity> ogra_: Although, I don't see it there either.
[19:16] <infinity> ogra_: Unless you mean the config/oem-config-preinstalled bits?
[19:16] <ogra_> infinity, exactly that
[19:16] <infinity> ogra_: Which isn't about the tarball at all.
[19:16] <zyga> hey, can we please get an exception for a pending merge request for checkbox
[19:17] <infinity> ogra_: That's touching a file in the build directory, so we can know what mode we're in across invocations, that's all.
[19:17] <infinity> ogra_: Which then allowed me to do things like set up a sane sources.list.
[19:18] <ogra_> hmm
[19:18] <infinity> ogra_: In fact, that's all that was used for, it looks like.
[19:18] <ogra_> k, i thought i saw it touching the file in the tarball somewhere
[19:18]  * ogra_ makes a note to fix that for R
[19:19] <infinity> ogra_: In that same 'if [ -f config/oem-config-preinstalled ]; then' block, you could certainly also do the /var enabling magic, to get it out of initrd hack land.
[19:19] <ogra_> yeah
[19:20] <ogra_> nothing for quantal though
[19:20] <ogra_> and for my other project i repack the tarball anyway
[19:21] <cjwatson> Laney: I'm rather tempted to start removing FTBFS out-of-date haskell binaries on armhf.  What do you think?
[19:21] <Laney> yes
[19:21] <infinity> cjwatson: If we had the CPU time right now, I'd suggest one more give-back.
[19:22] <cjwatson> Is there reason to believe it'd help?
[19:22] <infinity> Nope!
[19:22] <cjwatson> (Of course, we can always give-back after removal too)
[19:22] <Laney> I believe it to be a genuine ghc bug
[19:22] <infinity> Except that if they worked before, it's odd that they're broken now.
[19:22] <infinity> Oh, if GHC is genuinely FUBAR, then screw it.  Remove away.
[19:22] <infinity> That's not getting fixed this week.
[19:23] <cjwatson> Laney: Do you have a reference or anything?  It'd be nice to be able to quote something in removal comments, even if it's speculative
[19:23] <Laney> no :/
[19:23] <Laney> I'll file a bug with "HEY IT'S BROKEN LOL"
[19:23] <Laney> that we can use as a placeholder
[19:23] <ogra_> Laney, cant you follow standards ?
[19:23] <infinity> ogasawara: You reintroduced all the .gitignore files...
[19:24] <ogra_> the proper wording is "doesn't work!!!11!"
[19:24] <Laney> THAT'S IT, I'M MOVING TO SCHEME
[19:24] <infinity> ogasawara: Or were those in your orig? :P
[19:24] <ogasawara> infinity: they're in the orig
[19:24] <ogra_> lol
[19:24] <infinity> D'oh.  Kay.
[19:25] <ogra_> git is so ignorant
[19:25] <ogasawara> infinity: apw and I intend to sit down at UDS and sort out the file deletion issue we're seeing when packaging
[19:25] <cjwatson> I'm seriously tempted to consolidate testing{,-ports}/quantal_outdate_all.txt
[19:25] <cjwatson> Due to Architecture: all handling it's a lot clearer if you can see both at once
[19:25] <infinity> cjwatson: Consolidating testing in general probably needs to happen anyway.
[19:26] <Laney> cjwatson: do you see any similar problems on armel?
[19:26] <cjwatson> Laney: haskell-chell (my current example) built on armel but not armhf, although I haven't compared ghc versions
[19:27] <Laney> should be the same, I'm just wondering if all of the segfaults are armhf
[19:27] <cjwatson> infinity: the whole thing is a bit less clear because quantal_probs.html is used as a green light in things like jenkins tests, Rick's morning web browsing, etc.
[19:27] <cjwatson> infinity: but nobody except archive nerds looks at quantal_outdate_all.txt
[19:28] <infinity> cjwatson: Maybe, yeah.  I dunno.  I think a goal of having _probs be unprobby on all arches isn't so awful anyway.
[19:28] <cjwatson> Post-CI/britney/whatever I think that'd be good.
[19:28] <infinity> Right.
[19:29] <cjwatson> At the moment it's likely to be a lot of noise and increased stress due to perceived breakage in ports
[19:29] <infinity> Auto-britney was kinda where I was going with "it needs to not have a ports split anymore soon".
[19:29] <cjwatson> Yeah, that's like a couple of lines at the top anyway.
[19:29] <cjwatson> I expect you'd be using a different instance.
[19:29] <infinity> ogasawara: Accepting, after manual noise filtering.
[19:29] <ogasawara> infinity: thanks
[19:29] <ogasawara> apw: ^^
[19:30] <apw> ack
[19:33] <cjwatson> Laney: haskell-chart failed on armel with a segfault
[19:33] <cjwatson> haskell-file-embed/armel with SIGILL (like haskell-chell/armhf)
[19:33] <infinity> SIGILL?
[19:33] <cjwatson> haskell-yesod-form/armel with SIGSEGV
[19:33] <infinity> That's specially.
[19:34] <infinity> special, too.
[19:34] <cjwatson> Seems a bit of a mix, really.
[19:34] <cjwatson> And oddly random.
[19:34]  * Laney eyes trac
[19:34] <Laney> "preview" appears to have submitted
[19:36] <Laney> http://hackage.haskell.org/trac/ghc/ticket/7316
[19:36] <Laney> cjwatson: ^ (mostly a placeholder)
[19:36] <cjwatson> OK, http://people.canonical.com/~ubuntu-archive/testing/quantal_outdate_all.txt is all-arches now, and .../testing-ports/quantal_outdate_all.txt redirects to it
[19:37] <cjwatson> Laney: thanks
[19:37] <roadmr> hi, sorry to pester again, I know everybody is busy :/ is it ok to upload checkbox 0.14.9? merge here https://code.launchpad.net/~roadmr/ubuntu/quantal/checkbox/0.14.9/+merge/128777
[19:38] <cjwatson> roadmr: You should upload so that it can be reviewed in the queue
[19:38] <roadmr> cjwatson: ok, will upload then. Thanks!
[19:38] <cjwatson> This isn't me granting an FFe, just saying that's how we do reviews
[19:38] <cyphermox> cjwatson: ah, there was a misunderstanding
[19:39] <cyphermox> I was curious as to whether this kind of change warranted a FFe, I'm on the line for this one
[19:39] <cyphermox> (I'm working on the merge and preparing the package)
[19:39] <skaet> roadmr, it does require an FFE.   There's a new feature in it.    Can you please make sure you're following the FFE process, and especially document the testing done on it so far.
[19:40] <roadmr> skaet: sure, I'll do that in the linked bug
[19:41] <cyphermox> skaet: thanks;
[19:41] <skaet> roadmr, ok.  please paste the link of the bug here, and make sure its targetted to quantal, and release team subscribed so it can be commented as the review happens.
[19:42] <cjwatson> Heh, I just finished reviewing the udisks2 sync
[19:42] <cjwatson> (And would have accepted it too)
[19:42] <infinity> cjwatson: This is what you get for working past your EOD.
[19:43] <infinity> cjwatson: Hands off my queue and go have a pint? :P
[19:43] <skaet> jdstrand,  Daviey - what is the current status of openstack-resource-agents that's still in New?
[19:43]  * jdstrand has done nothing with it
[19:43] <cjwatson> Trying to get a baby to sleep - reviewing actually isn't a bad activity
[19:44] <zyga> cjwatson:
[19:44] <zyga> cjwatson: \o/
[19:44] <infinity> cjwatson: Especially if you read the diff out loud?
[19:44] <zyga> haha
[19:44] <cjwatson> Speech synthesis, man.  Have you no love of gadgetry?
[19:45] <infinity> cjwatson: Like those creepy voices could ever soothe a child.
[19:45] <infinity> cjwatson: You need to make the diff into a story.
[19:45] <skaet> :)
[19:46] <cjwatson> "Once upon a time, there was a datadir that was equal to dot"
[19:46] <cjwatson> I think it lacks a compelling sense of characterisation
[19:46] <jdstrand> heh
[19:46] <infinity> cjwatson: "And then the header was included, allowing the prototype to be defined correctly, and the compiler no longer complained about implicit declaration.  Can you say implicit?  ihm plih sit."
[19:46]  * skaet giggles
[19:47] <roadmr> skaet: https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/1016035 I just updated the description and the build/install/upgrade logs are there too
[19:48] <ubot2> Ubuntu bug 1016035 in checkbox "Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
[19:48] <infinity> If I ever reproduce and my child's first words are "implicit declaration" or "buffer overflow" or something, I suspect I would have failed as a parent.
[19:48] <infinity> And yet, also succeeded somehow.
[19:49] <cjwatson> my mother once told some students in her charge - this was while as a teacher in um 1970s or so Northern Ireland - that they could say the Sinn Féin slogan if and only if they could spell it
[19:50] <cjwatson> sorry, not sure that was totally apposite, you just reminded me of it somehow :)
[19:51] <apw> infinity, low-latency in the queue for you
[19:51] <zyga> infinity: you can avoid the 'failed as a partent' part if your children can fix the buffer overflows ;-)
[19:52]  * skaet a bit confused about what is so hard to spell about the slogan after looking it up on wikipedia, but *shrug*
[19:52] <cjwatson> my stepson, whose father's a train geek, had his first word as "engine"
[19:53] <cjwatson> skaet: oh, there are a couple.  I'm referring to https://en.wikipedia.org/wiki/Tiocfaidh_ár_lá
[19:53] <ScottK> When I lived in Ireland (Dublin) I learned a few words of Irish.  The only way I ever learned to spell any word was to fully memorize it.  I was never able to divine any rules.
[19:53] <cjwatson> It's actually more regular than English, just totally different.
[19:53] <infinity> "Oh the English came, and they jumbled up the letters, but those brave Irish boys turned them into a word..."
[19:54] <ScottK> Right.  I didn't say there weren't any, just none I could figure out.
[19:54] <skaet> cjwatson,  yeah, that one makes the story make more sense.
[19:54] <skaet> :)
[19:54] <cjwatson> (BTW not endorsing the political sentiments of the above wikipedia page ...)
[19:54] <infinity> apw: Reviewificating.
[19:54] <skaet> fair 'nuf
[19:55]  * cjwatson starts in on nuking OOD haskell builds then
[19:56] <apw> infinity, linux-signed for linux in the queue
[20:07] <Daviey> zul: Am i being daft.. is bug 1050359 also covered in the nova upload?
[20:07] <ubot2> Launchpad bug 1050359 in nova "Tests fail on 32bit machines (_get_hash_str is platform dependent)" [Medium,Fix committed] https://launchpad.net/bugs/1050359
[20:08] <zul> Daviey: fixed in a previous upload
[20:08] <Daviey> -ubuntu-fix-32-64-bit-iss.patch
[20:08] <Daviey> +ubuntu/ubuntu-fix-32-64-bit-iss.patch
[20:08] <zul> Daviey:  i just moved the patch to the ubuntu directory so when we do SRUs we can just drop the patch
[20:11] <knome> ugh, we need to get bug 1063453 through
[20:11] <ubot2> Launchpad bug 1063453 in xubuntu-docs "references to 3rd-party intellectual property need to be displayed with trademark" [Low,Fix committed] https://launchpad.net/bugs/1063453
[20:21] <skaet> Daviey, ^ what's the story on openstack-resource-agents - what's left, or should I just reject it from quantal?
[20:22]  * skaet notes its been in NEW for over a week at this point.
[20:22] <knome> skaet, can you give some opinion about that ^ so i can mentally prepare myself for things i need to do?
[20:22] <Daviey> skaet: Good question, i've been tentatively thinking of reviewing it.  I'd quite like it in Quantal.. but it's not required.
[20:22] <skaet> Daviey,  your call then.   either in or reject today please then.
[20:22] <Daviey> (Good chance it will be main next cycle, and it's nice to expose stuff for a cycle first... right?)
[20:23] <skaet> knome,  looking
[20:23] <knome> skaet, thanks
[20:24] <stgraber> rsalveti, ogra_, infinity: is the xf86-video-omap in the queue a request of one of you? (it's a sync so I can't know how to poke about it)
[20:27] <rsalveti> stgraber: tjaalton pushed it, it's a minor upstream bug-fix only release, which I tested already
[20:29] <ara> skaet, any chances to get the ffe for checkbox? or we should just give up
[20:30] <tjaalton> stgraber: yeah, I uploaded it
[20:33] <stgraber> tjaalton, rsalveti: ok. The delta at http://launchpadlibrarian.net/119246857/xf86-video-omap_0.4.0-0ubuntu2_0.4.1-1.diff.gz isn't terribily readable, but based on the changelog only, it's showing new features (xrandr rotation) that'd require a FFe
[20:33] <skaet> ara,  if its not absolutely critical,  prefer not to introduce more churn.   If it is critical,  please give detailed summary of testing done so far, and why it is not introducing risk by including it.
[20:33]  * skaet --> appt.   bbl
[20:35] <stgraber> rejected xf86-video-omap for now, we can always get it back from rejected if needed
[20:35] <ara> skaet, it is kind of critical, as checkbox is on the cd, and currently, all storage tests are broken
[20:36] <ara> skaet, we will include the information
[20:36] <rsalveti> stgraber: indeed, the rotation is a new feature there
[20:36] <Daviey> xpra: accepting, dig into the debian RC bug.. Looks reasonable, and fixes buggy version.
[20:37] <rsalveti> tjaalton: which is also not critical for us, so don't think it's worthy having the FFe for it
[20:38] <rsalveti> tjaalton: the other fixes are useful though
[20:40] <Daviey> barry: woooaaahhh.. mediathekview looks pretty extensive change.. bug 889117 doesn't seem very extensive.. what is the stauts?
[20:40] <ubot2> Launchpad bug 889117 in mediathekview "new version of mediathekview -needs packaging" [Undecided,Confirmed] https://launchpad.net/bugs/889117
[20:41] <barry> Daviey: i was looking at bug 1064451.  there are no rev-deps and it's universe so it seemed harmless, but i could be convinced otherwise
[20:41] <ubot2> Launchpad bug 1064451 in mediathekview "Sync mediathekview 3.0.0-1 (universe) from Debian unstable (main)" [Undecided,Fix released] https://launchpad.net/bugs/1064451
[21:02] <ara> stgraber, hey, could you have a look to FFe of https://bugs.launchpad.net/checkbox/+bug/1016035, please?
[21:02] <ubot2> Ubuntu bug 1016035 in checkbox "[FFE] Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
[21:02] <ara> we are losing our sponsor :)
[21:02] <ara> or anybody else in the release team
[21:04] <ara> Daviey, ?
[21:05] <zyga> cjwatson: still up?
[21:05] <zyga> stgraber: or you maybe?
[21:05] <zyga> pitti: ^^ ?
[21:05] <zyga> anyone that saw me during the last few years ;)
[21:05] <zyga> please help
[21:06] <Daviey> ara: heya
[21:07] <ara> Daviey, trying to get a FFe from the release team for https://bugs.launchpad.net/checkbox/+bug/1016035,
[21:07] <ubot2> Ubuntu bug 1016035 in checkbox "[FFE] Every script that uses udisk in currently broken in Quantal" [High,Fix committed]
[21:08] <ara> Daviey, it'd be great if you could have a look
[21:09] <Daviey> ara: Can you get it into the queue for review there please?
[21:10] <ara> Daviey, trying that, but the sponsor wouldn't want, let's try gain
[21:10] <ara> again
[21:11] <zyga> Daviey, ara: what does that mean, we need to dput the package to the review queue?
[21:12] <ara> zyga, it means that even if cyphermox upload it (yes, with dput), it'll go to a queue
[21:13] <zyga> ara: right, and isn't that the current goal?
[21:13] <Daviey> zyga: yes, the archive is in frozen state meaning each upload is wedged pending review.  Where it will be accepted or rejected
[21:13] <zyga> ok
[21:14] <Daviey> ara: I'm trying to grok the changes, and it's too much for me to work out.  You are quite confident this is well tested and regression free?
[21:14] <Daviey> ara: This wouldn't impact any other flavours would it?
[21:14] <ara> Daviey, no, just Ubuntu
[21:14] <Daviey> And I can't imagine this is covered in documentation, right?
[21:15] <ara> Daviey, it is not part of Ubuntu Docs
[21:15] <stgraber> ara: wrong, edubuntu ships it too
[21:15] <jdstrand> infinity: firefox 16 is good. shall I copy now?
[21:15] <stgraber> (as edubuntu ships all of ubuntu)
[21:15] <Daviey> stgraber: Do you want to take this review? :)
[21:15] <stgraber> Daviey: no
[21:16] <Daviey> bah
[21:16] <zyga> Daviey: note, there's a non-squashed version
[21:16] <zyga> Daviey: if you want to read that instead
[21:16] <infinity> jdstrand: Please do.
[21:16] <stgraber> Daviey: I had a look at the change quickly and it's too big for me to review and not something I know much about (udisk2), so as it's, I'd just reject on the basis that it's way too late and that I prefer to stick with known limitations rather than get new problems.
[21:17] <zyga> stgraber: known broken better than fixed by upstream but large delta?
[21:17] <Daviey> ara: Impact on checkbox-cli ?
[21:17] <stgraber> zyga: yep, because we know what's broken vs potentially getting something even more broken that we just don't know about yet
[21:18] <ScottK> Since none of the udisk tests work, the downside risk seems likely low.
[21:18] <zyga> stgraber: how can it be more broken if previous version just did not function anymore
[21:18] <ara> Daviey, it impacts the scripts and tests, not the different interfaces, so, yes it impacts checkbox-cli as well
[21:18] <zyga> stgraber: (anymore == since udisks2 became used)
[21:19] <stgraber> zyga: yeah, that's why I didn't reject it myself. I'm still fine if someone from the release team actually goes through the code and confirms that it's perfectly contained to the tests that aren't currently working
[21:20]  * zyga is sorry about being emotional, I'm sure that every developer wants their package in the repo at this late hour and it's a very difficult job to review all that code and be the one to make the call to reject or include it
[21:20] <Daviey> zyga: passion is good :)
[21:20] <knome> Daviey, the fruit?
[21:21] <Daviey> yah
[21:21] <knome> don't like that
[21:23] <Daviey> cyphermox: Can you get it in the queue real soon?
[21:24] <jdstrand> infinity: copied
[21:48] <cyphermox> Daviey: yes, I'll get it now
[21:50] <zyga> Daviey: the package is uploaded into the queue
[21:50] <zyga> cyphermox: thanks a lot!
[21:50] <cyphermox> Daviey: queuebot will notice it any second
[21:52] <slangasek> hrm, is python2.7 broken?
[21:52] <slangasek> https://launchpadlibrarian.net/119288447/buildlog_ubuntu-quantal-amd64.update-notifier_0.125_FAILEDTOBUILD.txt.gz
[21:52] <slangasek> that didn't happen when I build-tested locally
[21:53] <ScottK> That does look concerning.
[21:58] <slangasek> probably on my side, since python2.7 hasn't revved lately
[22:03] <cjwatson> slangasek: missing build-dep on python, so you only have python-minimal, I suspect
[22:03] <slangasek> ah, doh
[22:03] <slangasek> thanks
[22:03] <cjwatson> you might be using slightly fatter chroots
[22:03] <slangasek> yeah :/
[22:07] <Daviey> slangasek: Are you using pbuilder or sbuild?  if sbuild, are they just mk-sbuild generated, or something fancier ?
[22:07] <slangasek> Daviey: I have a comparatively-rich chroot that I use for development
[22:08] <slangasek> it has things like 'bzr-builddeb' installed :P
[22:08] <Daviey> ahh, ok :)
[22:09] <Daviey> (last cycle i hit an issue i couldn't reproduce outside the archive.. it did turn out to be a differing chroot)
[22:12] <slangasek> funny how turning on the test suite at build time turns up a bunch of modules that are missing from the package runtime deps
[22:12] <stgraber> ScottK: updated the madwimax bug, not sure how I missed that one last time I pushed a bunch of network SRUs...
[22:13] <cjwatson> grr, pycuda, you weren't supposed to fail again
[22:29] <cjwatson> apw: linux-signed still trying to download from quantal rather than -proposed, apparently
[22:29] <cjwatson> of course we could always source-copy and not care, but ...
[22:30] <apw> cjwatson, that doesn't make any sense, it searches all of the connected pockets
[22:30] <cjwatson> (or indeed copy linux once it builds everywhere, build linux-signed, copy that)
[22:31] <cjwatson> I'll look at the source later and see if I spot anything obvious
[22:31] <cjwatson> I think sleep may call for now
[22:32] <Daviey> stgraber: So, this checkbox upload.. It's been explained to me such that it is required to give the same testing coverage as 12.04..  The team are confident it is regression free, and if it did - they are committed to super fast resolution.  They are also on the hook for resolving issues it introduces to other flavours (ubuntu server ships the cli variant)
[22:32] <Daviey> Based on this, I am going to accept it, unless you scream otherwise.
[22:32] <apw> cjwatson, yeah too tired to make any sense now, will have to look at it in the mornign
[22:34] <apw> cjwatson, isn't the pool the same place regardless of the pocket the version is from ?
[22:35] <stgraber> Daviey: I'm fine with that. I just wanted someone to actually confirm that the change only affects the code that wasn't working as it wasn't obvious from the attachments to the FFe bug.
[22:35] <ogra_> apw, the pool is, the Packages file with the meta info isnt
[22:36] <apw> ogra_, right and so for the signed files there is no difference in location regardless of which pcoket it is in then
[22:36] <apw> cjwatson, those files are not in the pool at all
[22:38] <infinity> apw:
[22:38] <infinity> Downloading http://ftpmaster.internal/ubuntu/dists/quantal/main/uefi/linux-amd64/3.5.0-17.28/flavours ...
[22:38] <infinity> apw: ^--- That's not the pool.
[22:38] <apw> right
[22:38] <infinity> apw: And that needs to look for quantal-proposed.
[22:38] <apw> oh hmmm
[22:39] <apw> then i just have to guess
[22:39] <apw> ok
[22:39] <apw> we can do that
[22:39] <infinity> apw: Since it's looking for an exact version, that's fine.
[22:39] <apw> cjwatson, ok i know what is wrong here, will get it sorted and uploaded
[22:39] <apw> infinity, thanks ...
[22:39] <apw> infinity, yeah indeed.  i don't think i can tell if i shoud check proposed or not
[22:40] <infinity> apw: You can just test $series, $series-updates, $series-proposed in that order, and should be good to go.
[22:40] <apw> infinity, ack thanks
[22:40] <infinity> apw: Oh, and $series-security, on the off chance it's a security update before getting copied to updates.
[22:40] <infinity> apw: But yeah, since you're doing exact version checks, and no version can ever exist in the archive twice (even in history, including removals), checking all the pockets is fine.
[22:41] <infinity> apw: Heck, you could even make it backport-friendly by checking them last. :P
[22:42] <infinity> apw: I think we'll leave that kernel in proposed intentionally until you're sure you've sorted pocket handling, since it'll become critical post-release.
[22:44] <apw> infinity, yes please do, i'll do all of that :)
[22:51] <RAOF> bg
[22:54] <slangasek> cjwatson: initial shim-signed package (re)uploaded; can you review when it hits the queue?
[22:56]  * skaet --> back
[22:56] <skaet> Thanks Daviey for handling the checkbox
[22:58] <Daviey> sbeattie: Hey, can you check that the best fix for bug 1061879 really is shifting from Depends to Recommends?  I suspect that isn't enough.. But it's certainly no worse than the current situation... So happy to accept it.
[22:58] <ubot2> Launchpad bug 1061879 in apparmor "please have apparmor-notify Recommends libnotify-bin instead of Depends" [Medium,Triaged] https://launchpad.net/bugs/1061879
[22:58] <apw> infinity, whats the backport pocket called, -backport or -backports
[22:59]  * skaet sees unapproved as empty,   new with only the shim.   nice.  :)
[23:00] <Daviey> On that note, i'm going to bed before it fills up again.
[23:00] <Daviey> o/
[23:00]  * Laney looks forward to the final freeze mail
[23:00] <skaet> good night Daviey,   thanks.
[23:00]  * skaet goes to send it out.
[23:03] <sbeattie> Daviey: yeah, will do. Also, g'night!
[23:04] <infinity> apw: -backports.
[23:09] <skaet> Laney,  its sent now.   Should be making its way through the mail servers.
[23:10] <Laney> groovy
[23:14] <phillw> skaet: I've only just checked my email and see the one from Julian...  He would not ask for such a thing so late on. Your views on the FFe?
[23:16] <skaet> phillw,  bug number again please?    lots going through.
[23:16] <phillw> *Julien*
[23:16] <phillw> skaet: https://bugs.launchpad.net/ubuntu/+source/lubuntu-artwork/+bug/1043129
[23:16] <ubot2> Ubuntu bug 1043129 in lubuntu-artwork "[UIFe] Black borders on some active controls" [Undecided,Fix committed]
[23:17] <phillw> Yes, i know I'm a PITA :D
[23:20] <skaet> phillw,  Julien writes:  I currently can't include the fixed theme in 12.10 because there is too much changes, with too much potential regression or change in the UI.  I'm not seeing anything else contrary in the bug,  that gives confidence.
[23:21] <skaet> that its been tested, and won't likely introduce more regressions than issues it sorts.
[23:21] <skaet> Feel free to put more data in the bug if it exists.   This sort of change is probably best for 13.04 when it can get a lot more testing.
[23:22] <phillw> skaet: http://pastebin.com/emtpgLDF
[23:23] <phillw> you were emailed it (I saw you on the list of recpients, of which I was the other).
[23:24] <skaet> phillw,  ok,  have to catch up with the email queue yet - mostly focusing on IRC today.
[23:26] <phillw> skaet: It is, from my memory, very, very rare for Julien to make a plea. Basically, he and the artwork are stuck, (I see lots of little bugs flying about). Please help him & lubuntu on this one.
[23:27] <skaet> phillw,  ok,  if Julien is will to revert and take the risk, we'll let it in.
[23:27] <skaet> s/will/willing/
[23:28] <phillw> skaet: It seems that he has no choice. It's not ideal, it's not perfect but it's the best that can be done :(
[23:29] <phillw> him coming back from his 2 weeks away to recharge his batteries ill, and quite ill has really messed things up. :(
[23:30] <phillw> skaet: thanks for that, I now owe you another favour! :D
[23:33] <skaet> phillw,  please work to get it uploaded now in next couple of hours, and we'll call it even.
[23:35] <phillw> skaet: anyone here know how to explain what I need to do?
[23:36] <skaet> infinity,  can you help phillw?
[23:37] <phillw> oh, heck, I'm so sorry infinity, you must really hate me for the stuff I ask for help on,
[23:39] <infinity> phillw: All you need to do is work with your packager to get it uploaded.  I have nothing to review unless someone uploads a package.
[23:40] <phillw> infinity:  lubuntu-artwork0.34~ppa1Julien Lavergne (5 hours ago)
[23:40] <phillw> what is the next step?
[23:41] <phillw> He is an MOYU, I'm a mere mortal :)
[23:41] <phillw> *MOTU*
[23:41] <doko> better become immortal if you want to survive
[23:42] <phillw> doko: I'm a QA person... we are the people who 'bug' you:)
[23:43] <phillw> infinity: do you want to take this to -testing so as not to 'flame' the room?
[23:52] <apw> infinity, ok i hope i have fixed linux-signed, if the diff looks sane (and it is tested locally) then if you could poke it through, if not reject it and i'll try again in the AM