[00:02] <cjwatson> Link from /srv/cdimage.ubuntu.com/ftp-universe/pool/universe/w/wv/libwv-1.2-3_1.2.4-2ubuntu3_i386.deb to /srv/cdimage.ubuntu.com/scratch/xubuntu/daily/tmp/oneiric-i386/CD1/pool/universe/w/wv/libwv-1.2-3_1.2.4-2ubuntu3_i386.deb failed: No such file or directory
[00:02] <cjwatson> hmm
[00:04] <cjwatson> that source file exists on disk with a newer change time; I don't understand this but I suppose it's possible that a respin will in fact fix it
[00:06] <cjwatson> true of all the missing files (there are three; libwv-1.2-3, screensaver-default-images, tango-icon-theme-common)
[00:06] <cjwatson> maybe more fallout from the new syncproxy or something
[00:07] <cjwatson> ubuntu-server preinstalled is currently building so I'm hesitant to respin; at this point I think it might be best left to tomorrow morning's cron job
[01:53] <stgraber> would be great if someone could review bug 850550 (ideally I'd like to do the changes tomorrow morning), thanks!
[01:53] <ubot4> Launchpad bug 850550 in ubiquity-slideshow-ubuntu (Ubuntu) (and 1 other project) "[UIFe] [FFe] Removal of sabayon, pessulus and nanny from the Edubuntu 11.10 seed (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/850550
[05:16] <gador> I have a question. I fixed a bug (https://bugs.launchpad.net/ubuntu/oneiric/+source/ihu/+bug/770906) but got the BetaFreeze email now.
[05:16] <ubot4> Launchpad bug 770906 in ihu (Ubuntu Oneiric) (and 1 other project) "ihu version 0.6.0-2ubuntu2 failed to build on amd64 with GCC-4.6/oneiric (affects: 1) (heat: 8)" [High,Confirmed]
[05:17] <gador> Since I used the next debian version as a basis, should the fix still be merged in the main branch?
[05:27] <gador> didrocks, you seemed to be awake: I just a question concerning Beta Freeze. Maybe you could help me?
[05:27] <didrocks> gador: sure
[05:27] <gador> I fixed a bug (https://bugs.launchpad.net/ubuntu/oneiric/+source/ihu/+bug/770906) but got the BetaFreeze email now
[05:27] <ubot4> Launchpad bug 770906 in ihu (Ubuntu Oneiric) (and 1 other project) "ihu version 0.6.0-2ubuntu2 failed to build on amd64 with GCC-4.6/oneiric (affects: 1) (heat: 8)" [High,Confirmed]
[05:27] <gador> Since I used the next debian version as a basis, should the fix still be merged in the main branch?
[05:29] <didrocks> gador: the beta freeze is this evening, 21 UTC, so you still have time today  :)
[05:29] <didrocks> gador: do you know if the new version is introducing features?
[05:30] <didrocks> or bug fixes only
[05:31]  * micahg was hoping a release team member would answer, but there are major changes to the debian/rules files which from recent requests by the release team would require an FFe w/build logs just to verify the sanity of the changes
[05:31] <gador> didrocks, I don't think so. At lease nothing is stated in the changelog
[05:31] <gador> No new features, I mean
[05:32] <gador> But I can only propose a merge (Which I did). So if you think what I did is ok, could you merge the branch?
[05:33] <didrocks> micahg: the rules change are pretty easy
[05:33] <didrocks> yeah, it's only a new bug fix in debian
[05:33] <didrocks> gador: I guess if you can get it sponsored by the patch pilot today, it should be fine :)
[05:34] <gador> didrocks, patch pilot?
[05:34] <didrocks> gador: a sponsor to push it to ubuntu (not sure to have the time to do a lenghty review)
[05:35] <ScottK> If you redid the build system, please ask for an FFe.
[05:36] <didrocks> ScottK: it would be a sync from debian which did the change from debhelper5 to debhelper 7 (the new one is mostly the debhelper 7 boiler plate)
[05:36] <gador> didrocks, and how would I get a sponsor to look at it today? The only thing I did until now with other bug fixes was to propose the merge and someone looked at it at some point in time.
[05:36] <ScottK> didrocks: Still want an FFe and a debdiff.
[05:39] <didrocks> gador: so you have to file the FFe for ScottK (if it isn't acked, it will stay in the FTBFS state) and try to ping the patch pilot on #ubuntu-devel or wait for him to have a look (the patch pilot is a sponsoring programm where everyone try to take some time for doing those kinds of review)
[05:40]  * micahg will try to pilot before the freeze
[05:40] <ScottK> This isn't really a "will it get in" FFe, but a "we want an extra level of review" FFe.
[05:40] <gador> micahg, thanks :-)
[05:41] <micahg> gador: you still need to get the FFe though
[05:42]  * micahg still has his own FFes to file
[05:43] <gador> micahg, so I only need to file a new "bug" in launchpad with the necessary information?
[05:43] <micahg> gador: and subscribe ubuntu-release
[05:43] <micahg> gador: also update the merge proposal to close that bug
[05:44] <gador> micahg, what exactly do you mean?
[05:45] <micahg> gador: let
[05:45] <gador> micahg, I added the LP : bug# in the changelog, so it should close the bug when the branch get merged
[05:45] <micahg> gador: yep
[05:46] <gador> micahg, ok, I will file the bug from work (I need to get going now) Thanks for the help!
[05:47] <micahg> gador: thanks for the fix
[05:47] <gador> didrocks and ScottK , thanks to you, too ;-)
[05:47] <gador> sure
[05:47] <didrocks> yw :)
[07:17] <mvo> could somene from the releae team have a look at the ui freeze exception #850217 please? design updated the default banner of software-center, got a ok from the docs team already
[07:38]  * cjwatson will be flicking the switch to move package descriptions from Packages to Translations-en (bandwidth saving for multiarch) later today
[08:58] <mvo> could somene from the releae team have a look at the ui freeze exception #850217 please? design updated the default banner of software-center, got a ok from the docs team already - its the only missing blocker for doing a new upload with a bunch of fixes
[09:28] <ogra_> hmm, did the cron jobs not run ? i got no images but also got no failure mails
[09:32] <ogra_> no build logs either :(
[09:36]  * ogra_ doesnt get it ... seems the livefs build works for ac100 and mx5 but isnt attempted for any of the omap/omap4 images ... and cron.daily-preistalled doesnt seem to run at all
[09:42]  * ogra_ looks at bin/default-arches
[09:51] <ogra_> cjwatson, ogra@antimony:~/branches/cdimage-private$ ALL_DISTS=oneiric CDIMAGE_ROOT=/srv/cdimage.ubuntu.com bin/default-arches ubuntu dail-preinstalled oneiric
[09:51] <ogra_> amd64 amd64+mac i386 powerpc
[09:51] <ogra_> hmm
[09:52] <ogra_> that should definitely spit out something different i think
[09:53] <ogra_> (unless we started building preinstalled for x86 and ppc systems at least :) )
[10:00] <cjwatson> ogra_: you apparently can't type "daily". :-)
[10:00] <cjwatson> $ ALL_DISTS=oneiric CDIMAGE_ROOT=/srv/cdimage.ubuntu.com bin/default-arches ubuntu daily-preinstalled oneiric
[10:00] <cjwatson> armel+ac100 armel+mx5
[10:01] <cjwatson> ubuntu                  daily-preinstalled      oneiric-                armel+ac100 armel+mx5
[10:01] <cjwatson> so it's doing what you told it to do
[10:02] <ogra_> not really, it should also spit out omap
[10:02] <ogra_> and omap4, but yes, i seemingly cant type
[10:03] <ogra_> ubuntu                  daily-preinstalled      oneiric-                armel+ac100 armel+mx5
[10:03] <ogra_> *                       daily-preinstalled      maverick-               armel+omap armel+omap4
[10:03] <ogra_> thats what is in /etc/default_arches
[10:03] <ogra_> err s/_/-/
[10:03] <cjwatson> No, they don't add that way.
[10:04] <ogra_> do i need to drop the dash from oneiric in the first line ?
[10:04] <ogra_> hmm, at the top the file says i should put more specific matches first, i thougth thats what it means
[10:04] <cjwatson> It picks *one* line and uses the entries from that.
[10:04] <ogra_> hmm, tricky
[10:04] <cjwatson> If they added the way you suggest then it would be hard to drop architectures.
[10:05] <ogra_> so i need separae lines for sever core and desktop then
[10:05] <ogra_> *separate
[10:05] <cjwatson> Be specific
[10:05] <ogra_> yes
[10:05] <cjwatson> No, be specific about what you mean by what you just said
[10:06] <ogra_> oh, well, we used to have just the second line and i usually just add to it, but that will build all possible preinstalled flavours
[10:06] <ogra_> for ac100 and mx5 i only want desktop
[10:06] <ogra_> and indeed only for oneiric
[10:06] <ogra_> that made me create the top line
[10:06] <cjwatson> Then you don't need separate lines.  'ubuntu daily-preinstalled oneiric- armel+ac100 armel+mx5 armel+omap armel+omap4' will do it.
[10:07] <cjwatson> Other flavours will fall back to the less specific match '* daily-preinstalled maverick- armel+omap armel+omap4'
[10:07] <ogra_> but then the cronjob builds server too
[10:07] <ogra_> which i'l like to avoid on ac100 and mx5
[10:07] <cjwatson> default-arches does not govern which cron jobs are run
[10:08] <cjwatson> How about you enumerate every single image you want built and I will do the right thing
[10:08] <ogra_> no, but it will return ac100 and mx5 as allowed arches for it
[10:08] <cjwatson> No it won't
[10:08] <cjwatson> ubuntu-server != ubuntu
[10:08] <cjwatson> the 'ubuntu' project in cdimage is just desktop/alternate
[10:08]  * ogra_ is referring to the original line that has just a * in the beginning
[10:09] <cjwatson> Which doesn't list ac100 and mx5
[10:09] <ogra_> that got me all flavours for all possible preinstalled arches in the past
[10:09] <ogra_> (when i added the two new arches)
[10:09] <cjwatson> Please just list every flavour you want and let me encode it
[10:09] <cjwatson> every image, I mean
[10:09] <ogra_> k
[10:10] <mvo> cjwatson: could you comment on bug #850217 (ui-freeze-exception) please? or should I wait for kate ?  its hopefully just a formatlity
[10:10] <ubot4> Launchpad bug 850217 in software-center (Ubuntu) "ui freeze exception for default banner (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/850217
[10:10] <cjwatson> mvo: yes, will do
[10:11] <mvo> great, thanks a lot!
[10:12] <ogra_> omap3/4, ac100 and mx5 - preinstalled desktop
[10:12] <ogra_> omap3/4 - preinstalled server
[10:12] <ogra_> omap3/4 - netinst (shouldnt matter here)
[10:12] <ogra_> cjwatson, ^^^
[10:12] <mvo> I have some pending fixes in apt too, http://paste.ubuntu.com/689860/ that should be fine, right? just fixes, no need for a FFe?
[10:15] <infinity> mvo: \o/ to the removal of binary caches on clean and update.
[10:15] <cjwatson> ogra_: then it's as I said, and I've committed and deployed the appropriate change
[10:15]  * ogra_ checks to understand 
[10:16] <ogra_> aha, why dont you specify server explicitly on the second line ?
[10:16] <ogra_> guessing that would work too, right ?
[10:16] <infinity> ogra_: Because there's no point in having a specific match.
[10:16] <ogra_> k
[10:16] <ogra_> well, at least i understand my mistake now
[10:16] <ogra_> cjwatson, thanks so much
[10:17] <cjwatson> ogra_: There's no need; desktop is the one that's out of the ordinary, and everything else can use a default
[10:17] <cjwatson> I try not to be excessively specific
[10:17] <ogra_> yeah
[10:17] <cjwatson> oh yes, infinity said that too
[10:17]  * ogra_ somewhat misinterpreted "specific" here :)
[10:19] <cjwatson> mvo: software-center> +1
[10:19] <mvo> woooh, thanks
[10:19] <cjwatson> Long descriptions should move to Translations-en after the next publisher run
[10:20] <cjwatson> With any luck
[10:20] <mvo> nice, thats going to be interessting :)
[10:21] <cjwatson> 'apt-get clean' - what does that do to startup times?  doesn't that mean that every time you ask it to remove cruft from /var/cache/apt/archives/, it then has to build its package list caches from scratch?
[10:21] <cjwatson> and for 'apt-get update', I thought it rebuilt the caches anyway?
[10:21] <cjwatson> I assume we're talking about /var/cache/apt/{pkgcache,srcpkgcache}.bin here?
[10:23] <cjwatson> I'm OK with the rest of it, although slightly nervous about the resolver change and curious what testing's been done on that
[10:24] <mvo> it sill slightly increase the startuptime on the first run after apt-get clean, but the cache is rebuild automatically so that should not be a huge issue
[10:24] <mvo> but yeah, the apt-get update one I'm not sure about, given that apt will rebuild the cache anyway automatically after the update
[10:25] <infinity> It really won't.
[10:25] <infinity> Not until this change.
[10:25] <infinity> Trust me, I banged my head on that wall for two days a month or two ago.
[10:25] <mvo> the resolver one is currently doing a test run in a VM for natty -> oneiric
[10:26] <mvo> infinity: hm, it should unless there are i-m-s only hits
[10:26] <infinity> If the update gave you a new Packages file, it will rebuild, but if you did something like, say, change the order of sources.list, the binary cache stays intact, and is now "backwards".
[10:26] <infinity> At which point, I bug you about bugs that don't exist.
[10:26] <infinity> Remember? :P
[10:27] <mvo> infinity: iirc I fixed this one (sources.list timestamp check)
[10:27] <infinity> Oh, true.  You did fix that one case.
[10:27] <infinity> Did you also check preferences?  And .d?  And..? :)
[10:27] <mvo> but I agree, there may be more cases and rebuilding is not that expensive (comapred to the download work it needs to do)
[10:28] <infinity> I dunno.  Making update take more time sucks a bit on slow machines, but...
[10:28] <mvo> it does check .d, not sure about preferences …
[10:29] <infinity> I'm less convinced about deleting the caches on clean, TBH.
[10:29] <infinity> I expect "update" to do work.
[10:29] <infinity> I expect clean to just wipe out archives.
[10:29] <infinity> But meh.
[10:30] <mvo> ok, this all sounds controversial enough to just leave it out for oneiric
[10:30] <mvo> thanks for the feedback!
[10:31] <infinity> I dunno.  The resolver change, if it does what I think it does, sounds worth it, if it passes some solid testing.
[10:31] <infinity> (Though any resolver change is scary)
[10:31] <mvo> true, but the auto-upgrade-tester makes it at least easier to test common scenarios
[10:32] <mvo> I will just cherry pick instead of taking the full merge
[10:32] <infinity> Upgrades are getting more and more painful, and multiarch just made that a ton worse.  I suspect that resolver change (again, if I'm reading the intent correctly there) will actually help a lot.
[10:48] <ev> I'm going to respin the Ubuntu desktop CD once ubiquity is published, so long as there are no prior complaints
[11:44] <smspillaz> hi - can I get the release team to look at an FFE/UIFe that's been pending for a few days now ?
[11:44] <smspillaz> https://bugs.launchpad.net/ayatana-design/+bug/837545
[11:44] <ubot4> Launchpad bug 837545 in compiz (Ubuntu) (and 2 other projects) "Spread - center the workspace switcher to account for the launcher and pane (affects: 1) (heat: 10)" [Undecided,New]
[11:45] <smspillaz> the explanation of what's changed and everything is on the bug
[11:51] <smspillaz> skaet: ^ (sorry for bugging you! :))
[11:57] <ogra_> lamont, hmm, i see a lot  annonaceae live builds in antimonys process list, but looking at annonaceae there doesnt seem to be anything building ...
[11:59]  * ogra_ wonders if the ssh key changed with yesterdays changes
[11:59] <ogra_> or something like that
[13:36] <smspillaz> skaet: pitti ?
[13:54] <skaet> smspillaz, hiya.
[13:54] <smspillaz> skaet: hi!
[13:54] <smspillaz> skaet: I need the release team to have a look at some stuff I've been doing in the workspace switcher
[13:55] <smspillaz> desktop can't sign it off as the diff is quite large
[13:55] <smspillaz> (it's a uife)
[14:02] <skaet> smspillaz, is there a bug and pointer to details?
[14:03] <smspillaz> sure
[14:03] <smspillaz> https://bugs.launchpad.net/ayatana-design/+bug/837545
[14:03] <ubot4> Launchpad bug 837545 in compiz (Ubuntu) (and 2 other projects) "Spread - center the workspace switcher to account for the launcher and pane (affects: 1) (heat: 10)" [Undecided,New]
[14:06] <skaet> hmm,  looks like docs has ok'd it so that's one question answered ;)
[14:07] <njpatel> Anyone from the doc team who can grant a poor soul a UIFe?
[14:07] <skaet> smspillaz,  are all the pieces tested and ready to go in?  or is there still waiting on compiz part?   can't tell from the description.
[14:08] <smspillaz> skaet: tested - we've have 3 dx people test them
[14:08] <smspillaz> skaet: and it works fine
[14:08] <smspillaz> skaet: and it doesn't depend on anything else in compiz
[14:14] <skaet> smspillaz, want to cross check a few more things.  will get back to you in 30 mins or so.
[14:16] <smspillaz> skaet: np
[14:33] <cyphermox> hi, could someone please ack https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/849994 ?
[14:33] <ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New]
[14:40] <skaet> smspillaz, ok,  have gone in and acked it.   If you can't make the upload deadline of beta freeze 2100,  we probably should hold off though.
[14:40] <smspillaz> skaet: how long have I got
[14:40] <stgraber> smspillaz: 21:00 UTC
[14:40] <smspillaz> ok :)
[14:51] <skaet> smspillaz, please coordinate with didrocks to make sure any of his changes necessary to enable this, as well as yours, land before 2100.   Don't want this to cause breakage right now.
[14:52] <smspillaz> sure thing
[14:52] <skaet> :)
[16:41] <charlie-tca> cjwatson: anything happening to bug 850172 ?
[16:41] <ubot4> Launchpad bug 850172 in debian-installer (Ubuntu) "Xubuntu Oneiric Alternate images fail to find abiword dependencies when building images (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/850172
[16:51] <cjwatson> depends, does total confusion count?
[16:52] <charlie-tca> sure, it is a state I am in most of the time :)
[16:52] <cjwatson> I tried again and it's still returning link errors on the same a handful of files saying "no such file or directory", except that I've checked and the files exist
[16:52] <charlie-tca> so, it just doesn't like us no more, huh?
[17:05] <cjwatson> charlie-tca: I'm going to have to trace it, but have run out of time for now - it's still on my plate though
[17:36] <micahg> do we need an FFe for adding hardening to packages?
[17:38] <cjwatson> I personally don't think so
[17:45] <cyphermox> could someone please ack bug 849994; for DHCPv6 DUID support in NM
[17:45] <ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/849994
[17:46] <micahg> cjwatson: are you planning a sync run before beta 2 freeze or should I use the API for stuff that needs to go in?
[17:48] <cjwatson> micahg: I probably can, but you should use the API anyway
[17:48] <cjwatson> unless you've already requested it
[17:48] <micahg> cjwatson: ok, didn't want to add more work for you, will use API for stuff that needs to go in before beta 2
[17:49] <micahg> thanks
[17:49] <cjwatson> although my link to LP is really really slow today so maybe some other archive admin could run the sync queue?
[17:50] <micahg> I'm still waiting on the sync credit bug to be fixed (don't need the credit, but it's how I watch for regressions), these are all xubuntu packages, so I have others to poke me if they break
[18:57] <stgraber> slangasek, skaet: for bug 575469, the change in the upstart job to make it work without changing initramfs-tools doesn't seem to work. If it's something we want by freeze time, I'd have to revert to changing initramfs-tools (that's assuming the FFe is accepted)
[18:57] <ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/575469
[18:58] <stgraber> I spent a bit of time with jhunt earlier discussing it, for some reason cjwatson's suggested upstart job works on his setup but it reliably fails for me in an Oneiric VM installed from yesterday's daily...
[18:59] <stgraber> so I don't know what you prefer, either revert to changing initramfs-tools or wait till we figure out why upstart doesn't work for me (and for sure missing the freeze time)
[19:02] <skaet> stgraber,  lets let slangasek weigh in on this one.
[19:03] <skaet> my preference is to revert at this point, but he may be more comfortable going for the fix.   Not sure.
[19:09] <stgraber> also, with my ipv6 hat on now ;) would be great if someone from the release team could go and review bug 849994 so cyphermox can get it uploaded before the freeze
[19:09] <ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/849994
[19:10] <stgraber> that missing "feature" in network-manager was really a bug (as it wouldn't be rfc compliant without it) but still, there's the FFe :)
[19:12] <cyphermox> thanks stgraber
[19:21] <skaet> Daviey, ^^ can you review 849994?
[19:29] <Daviey> skaet: That simple patch is huge, i'd be happier if someone closer to network manager reviewed it tbh.
[19:31] <cyphermox> hmm.
[19:34] <Daviey> cyphermox: did pitti look at that, do you know?
[19:34] <cyphermox> not that I know
[19:34] <cyphermox> hold on, trying to get upstream to review it nao
[19:35] <Daviey> cyphermox: oh cool, if it's in upstream - makes it less daunting.
[19:35] <stgraber> if that counts at all, I did look at it :) cyphermox did the implementation based on discussions we had with upstream
[19:35] <cyphermox> well, it's not in upstream now, but the lead dev can chime in :)
[19:35] <stgraber> the actual implementation is what we agreed with Dan (upstream for NM) on the mailing-list
[19:36] <stgraber> most of the code is to generate the DUID itself and escape it, the changes in the existing code are relatively limited (update existing broken lease files and call the generation code).
[19:37] <stgraber> the change only applies to dhcpv6 which isn't too common yet and I can confirm that the DUID is indeed valid (as in, my home dhcpv6 server is happy with it) and constant (was the goal of the change)
[19:41] <cyphermox> waiting for the email back from dcbw or a message in #nm
[19:41] <cyphermox> Daviey: http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00146.html btw
[19:51] <slangasek> stgraber: for bug #575469, is there an implementation of the initramfs-tools approach ready for review?
[19:51] <ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/575469
[19:52] <stgraber> slangasek: yeah, that was my initial implementation. I'd use it with Colin's suggested changes
[19:54] <slangasek> stgraber: so this would use all the same boot arguments for grub, but implement it by interposing recovery-menu before upstart?  and could still reasonably support running mountall by hand with --no-events?
[19:55] <stgraber> I'd have the grub debdiff updated to set "startup-event=recovery" instead of "recovery". the initramfs-tools change will send that as --startup-event=recovery to upstart
[19:55] <stgraber> upstart will then emit "recovery" instead of "startup"
[19:55] <stgraber> friendly-recovery will be "start on recovery"
[19:56] <stgraber> the mountall call in friendly-recovery will run with --no-events to avoid starting everything
[19:56] <stgraber> and the post-start script of friendly-recovery will do a "initctl emit startup" to trigger the usual boot sequence on resume
[19:57] <slangasek> I'd rather we still had 'recovery' as the boot argument
[19:57] <slangasek> startup-event=recovery is excessively verbose for something users may be trying to edit / input at boot time
[19:58] <stgraber> ok, I can make the initramfs-tools change look for "recovery" and set --startup-event=recovery on the init command line then
[19:58] <slangasek> and that way the naming isn't tied to the specific implementation
[19:58] <slangasek> yep, I think that would be best
[19:58] <slangasek> now, if friendly-recovery isn't installed at all, this means the boot will hang?
[19:58] <slangasek> since upstart will only emit an event nothing is listening for, so no jobs ever start
[19:59] <stgraber> no, because the change to grub sets "single" instead of "recovery" when friendly-recovery isn't installed
[19:59] <stgraber> so you'll boot in single boot and get dropped into a root shell
[19:59] <slangasek> and the grub config is forcibly regenerated when friendly-recovery is installed/removed?
[19:59] <stgraber> no, boot it definitely should, adding that to my list
[19:59] <slangasek> ok
[20:00] <stgraber> calling update-grub on postinst and postrm should do the trick
[20:00] <slangasek> I haven't reviewed the initramfs-tools patch yet (please give a direct pointer when you have that done), but with those two concerns taken care of and provided you've tested this both with and without friendly-recovery installed, for normal, recovery, and single-user modes, I'm satisfied that we should proceed
[20:01] <slangasek> IFF it can all land today
[20:01] <stgraber> slangasek: https://launchpadlibrarian.net/79349232/initramfs-tools.debdiff
[20:02] <stgraber> Coling recommended exec run-init ${rootmnt} ${init} "$@" ${STARTUP_EVENT:+--startup-event=$STARTUP_EVENT}
[20:02] <stgraber> instead of the two lines at the end
[20:03] <slangasek> looks good to me
[20:03] <stgraber> ok, working on updated patches now
[20:14] <ScottK> slangasek: Would you please demote digikam to Universe.  I've already removed it from the Kubuntu dvd and kubuntu-full.
[20:21] <skaet> Daviey, 831496 - anything more about to land?
[20:22] <astraljava> Hello all, on behalf of ubuntustudio-devel, may I ask someone privileged to upload ubuntustudio-meta, please? We made some modifications on the seeds. Thanks!
[20:23] <Daviey> skaet: If i could work out how to add an empty task, yes :)
[20:25] <slangasek> ScottK: the 'showfoto' binary is also unseeded from kubuntu-full?
[20:25] <slangasek> (or maybe that's the one you mean anyway - but just to clarify)
[20:26] <ScottK> slangasek: No.  Missed that one.  I'll fix it.  In the meantime, I'd  appreciate it if you'd go ahead and demote it.
[20:26] <slangasek> ScottK: ok, will do
[20:26] <stgraber> slangasek: updated patches attached to the bug
[20:27] <stgraber> will start a ppa build now, not sure if I'll have the result before freeze time though
[20:27] <ScottK> Seed fixed.  Meta in a moment.
[20:27] <slangasek> what time is freeze o'clock today?
[20:27] <stgraber> 21:00 UTC
[20:28] <slangasek> tight indeed
[20:29] <slangasek> stgraber: Breaks: upistart (<< 1.3-0ubuntu9) <-- opa
[20:29] <stgraber> oops
[20:30] <slangasek> stgraber: friendly-recovery also needs an update-grub call in the postrm
[20:30] <stgraber> doh, forgot a bzr add... Let me get you a new debdiff for friendly-recovery
[20:30] <slangasek> ok
[20:31] <slangasek> if ! grep -q "recovery" /proc/cmdline; then
[20:31] <slangasek> possibly redundant now, but also safe to leave it
[20:31] <slangasek> and it better future-proofs the job
[20:32] <stgraber> slangasek: https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/575469/+attachment/2409475/+files/friendly-recovery.debdiff
[20:32] <ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid]
[20:32] <stgraber> yeah, and also avoids cases where someone would do: "start friendly-recovery" or "initctl emit recovery" on a booted system
[20:32]  * slangasek nods
[20:34] <slangasek> debian/friendly-recovery.symlinks> not idiomatic, is this for use with dh_link?
[20:34] <slangasek> (filename should be debian/friendly-recovery.links, if so)
[20:35] <stgraber> oops, /me fixes
[20:35] <stgraber> yeah, that's for dh_link
[20:36] <slangasek> and the upstart job even handles the case when the package is in conffiles state, nice
[20:40] <slangasek> stgraber: aside from the last round of touch-ups, have you had a chance to test these changes out together?
[20:41] <ScottK> FYI there will be a large number of no change KDE uploads to fix a problem with .desktop file translations.  Sorry.
[20:41] <stgraber> slangasek: there are all done building on amd64 in my PPA, will test them now in a VM
[20:42] <ScottK> slangasek: kubuntu-meta updated too.
[20:42] <slangasek> ok
[20:42] <slangasek> ScottK: spiff
[20:45] <cyphermox> Daviey: I got good review from upstream despite there will be cleanup needed
[20:46] <micahg> any opinion about bug 846483 and needing any exceptions? icons seem to be broke w/out them
[20:46] <ubot4> Launchpad bug 846483 in ubuntustudio-icon-theme (Ubuntu) "icons do not play nice with XFCE (affects: 3) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/846483
[20:46] <Daviey> cyphermox: Being kinda desktop centric, i'd be happier if pitti looked at it.  Does it need to be on the iso tommorrow?
[20:47] <cyphermox> Daviey: I guess not.
[20:47] <cyphermox> stgraber: ^^ ?
[20:47] <cyphermox> you're the one who wanted this to be in yesterday ;)
[20:47] <ScottK> micahg: From the title it sounds like a bug.
[20:48] <Daviey> micahg: screenshot before and after would certainly help.
[20:48] <doko> skaet, slangasek: there is a buffer overflow in the gcc multiarch patch. please expect uploads for g{cc,cj,dc,nat}-4-.{4-6}-*
[20:48] <micahg> Daviey: let me grab the updater to answer questions
[20:49] <skaet> doko, what triggers the buffer overflow
[20:49] <skaet> ?
[20:49] <skaet> doko,  also, what is the bug number?
[20:50] <micahg> falktx: Daviey was wondering if we can get screenshots of before and after for the icon theme change, is that possible?
[20:50] <falktx> let me check
[20:50] <doko> no bug number
[20:50] <doko> gcc/gcc.c
[20:51] <doko>        if (path == NULL)
[20:51] <doko>         {
[20:51] <doko>           len = paths->max_len + extra_space + 1;
[20:51] <doko> -         if (suffix_len > multi_os_dir_len)
[20:51] <doko> -           len += suffix_len;
[20:51] <doko> -         else
[20:51] <doko> -           len += multi_os_dir_len;
[20:51] <doko> +         len += MAX (MAX (suffix_len, multi_os_dir_len), multiarch_len);
[20:51] <doko>           path = XNEWVEC (char, len);
[20:51] <doko>         }
[20:51] <doko>  
[20:52] <falktx> micahg: basically, because of the xfce change, lots of icons were not covered (xfce uses different names than gnome)
[20:53] <micahg> Daviey: ^^
[20:53] <falktx> micahg: this new version deletes the old icons and now depends on elementary ones
[20:53] <slangasek> doko: what's the actual impact of this bug?  It does seem to have taken a while to notice; are we getting broken packages output as a result, or is there just a random risk of the compiler segfaulting (on select archs / with select options)?
[20:53] <Daviey> falktx: So this provides the same experience of Alpha 2?  A change in XFCE broke it recently?
[20:54] <falktx> micahg: Daviey: the old ones were just bad, and arrange them for xfce would be just too much work
[20:54] <slangasek> doko: or to put it another way: what's the damage if we hold the update until after beta2 is out, given that we are about to enter freeze?
[20:54] <falktx> Daviey: ubuntustudio used gnome, now it uses xfce
[20:54] <Daviey> Ah.
[20:54] <falktx> Daviey: ^this change broke the icons, as xfce needs different ones
[20:54] <stgraber> slangasek: test in a VM looks good. recovery menu showed up with read-only filesystem, remount in read/write worked without starting any service, the various entries work and resuming does too
[20:55] <falktx> Daviey: the updated branch will remove all old icons except the branding, and make it dependant on elementary
[20:55] <falktx> Daviey: I hope it's clear enough...
[20:56] <doko> slangasek, I don't know. it was noticed on mipsel-linux and kfreebsd-i386, but I don't see any reason why it should trigger on other archs
[20:56] <Daviey> falktx: Out of interest, when did UbuntuStudio switch from gnome to xfce?
[20:56] <falktx> Daviey: earlier this cycle, just about alpha-2/3
[20:58] <doko> or should not
[20:58] <slangasek> doko: what string is multiarch_len measuring?
[20:58] <falktx> Daviey: micahg: is it possible to update the package now?
[20:58] <falktx> or is it too late for beta-2?
[20:59] <doko> slangasek, the multiarch_dir
[20:59] <stgraber> slangasek: just saw your comment in the bug, will start uploading now. 20:59 UTC :)
[20:59] <Daviey> falktx: do you need a sponsor?
[21:00] <micahg> Daviey: I can sponsor, just need to know if I need a release ack or not
[21:00] <Daviey> micahg: Just commented, seems fair.
[21:00] <SpamapS> I have a fix for bug 791607 .. euca is demoted tho, so is it even subject to beta freeze?
[21:00] <ubot4> Launchpad bug 791607 in eucalyptus (Ubuntu Oneiric) (and 1 other project) "Oneiric Eucalyptus fails to start up (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/791607
[21:00] <slangasek> doko: what surprises me about this is that I would also expect it to affect all architectures, and result in an immediate segfault... if we're not seeing massive compiler segfaults yet then the impact seems to be very specific to the memory layout of the build.  We should fix the overflow, but it doesn't seem urgent to fix before beta for the default compiler.  Do you disagree?
[21:01] <Daviey> SpamapS: everyfink is subject to b2 freeze.
[21:01] <Daviey> SpamapS: With this, i'd be happy with a fix 5 mins before B2 is announced. :)
[21:01] <ScottK> Daviey: Sort of.  Unseeded packages can still be uploaded, they just need a manual push from the release team.
[21:01] <doko> slangasek, I do disagree. it's just luck that we are not hit
[21:02] <SpamapS> Daviey: graziano's patch appears to work
[21:02] <Daviey> SpamapS: rocking!
[21:06] <stgraber> ok, I guess I'm done with uploads for today, now to make sure nothing breaks and start poking at ubiquity bugs again ;)
[21:12] <doko> skaet, didn't see any feedback, so I assume you are ok
[21:13] <skaet> doko,  I'm reluctant to go forward with this since this is the first we're seeing it, and we're now in beta freeze.
[21:13] <Daviey> doko: On another note, Do you have another archive rebuild scheduled?
[21:14] <doko> skaet, fine with this as well. just want to trade my arse for yours ;=P
[21:15] <ScottK> Daviey: First one isn't done yet (still going on armel)
[21:15] <Daviey> still 10 days?
[21:16] <Daviey> 4 days \o/
[21:16] <doko> Daviey, no, unless you can convince management to have any productive outcome on this
[21:16] <doko> skaet, slangasek: any opinions? ^^^
[21:16] <slangasek> doko: what do you mean by productive outcome?
[21:18] <doko> slangasek, we had about ~800 uploads ater the test rebuild. Im fine if you do acknowledge that these uploads don't have any effect on the test rebuild
[21:19] <SpamapS> Daviey: ok with graziano's patch I get a normal Euca system.. should I upload it?
[21:20] <slangasek> doko: sorry, I don't get it.  I'm sure that the 800 uploads will have had an effect - *hopefully* all positive, but maybe some negative, which would be the point of doing another test, I think?
[21:21] <astraljava> Hey guys, I created a new branch for our team (~ubuntustudio-dev), on which we depend on in the desktop seed. Do I need to file an FFe because of the new package?
[21:21] <Daviey> SpamapS: Hell.. Yes..
[21:21] <Daviey> SpamapS: I am overjoyed!
[21:21] <SpamapS> Daviey: as am I
[21:22] <doko> slangasek, Daviey I'm fine to start another rebuild. including the rescoring for the last rebuild
[21:22] <SpamapS> Daviey: now we just need to strip out the "Ubuntu Enterprise Cloud" bits ;)
[21:22] <doko> slangasek, if it's not needed, please just tell me
[21:23] <Daviey> SpamapS: Ah, good point.  Being that it was in such a mess, that kinda got lost.  We should probably remove the UEC branding patch and images..
[21:24] <Daviey> doko: Server certainly cares about FTBFS's, it's a good entry point for our massive community. :)
[21:24] <SpamapS> Daviey: will open a bug for that, should be fine to upload that during beta.
[21:26] <Daviey> SpamapS: Yeah, i don't think we need to still support the image-store, so should be quite easy to cut 'n shut.
[21:26] <SpamapS> bug 851351 opened
[21:26] <ubot4> Launchpad bug 851351 in eucalyptus (Ubuntu) "Remove "Ubuntu Enterprise Cloud" branding from Eucalyptus packages. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/851351
[21:26] <SpamapS> should e target that to 11.10?
[21:28] <Daviey> SpamapS: makes little difference really.. If it's not done by b2, the milestone will be ported across anyway. :)
[21:28] <Daviey> SpamapS: Are you looking to do that?  Now you are a euca expert?
[21:29]  * SpamapS swears an oath to squirt Visine into Daviey's coffee
[21:30] <SpamapS> Daviey: I'd be perfectly fine with handling that, as much of a Eucalyptus *NOVICE* as I am. :)
[21:31] <Daviey> SpamapS: The rest of the team have forgotten everything about it now, which makes you the most experienced with it. :)
[21:31] <Daviey> And now touched-it-last.. wow, you just signed up for so much pain.
[21:34] <stgraber> oops, that last fix didn't make it in time apparently (.links file being the wrong way around)
[21:35]  * SpamapS goes to find food for lunch and some dried worms to garnish Daviey's lunches
[21:36] <NCommander> doko: building GCC is a 1.25 day event. so far our luck being holding pretty well, and I think I'd be much more confortable if the upload happened after we came out of B2 as that gives up a few weeks to fix anything that might break
[21:36] <NCommander> on armel
[21:36] <Daviey> \o/
[21:36] <doko> NCommander, that's fine. I could stage these in a PPA if demanded
[21:37] <NCommander> doko: that would be preferable, then we can simply binary copy them into archive if everything looks sane
[21:37] <doko> but unortunately I don''t get any response :-/
[21:37] <NCommander> ^- skaet, your opinion
[21:37] <NCommander> doko: ?
[21:38] <Daviey> wait, we can now binary copy from PPA to archive?
[21:38] <NCommander> Daviey: we've been able to do that for years from unvirtualized PPAs
[21:38] <NCommander> that's how the security team does their releases
[21:38] <Daviey> interesting, i thought that was still wishlist.
[21:39] <doko> the point is that you have to be trusted.
[21:39]  * NCommander does believe there are SOME limitations on copying from virtualized PPAs :-/
[21:41] <NCommander> anyway, I need to get something to eat, so I'll be back later
[21:42] <skaet> doko, NCommander,  I'd like to explore the PPA approach a bit more.   What are the downsides?
[21:43] <doko> skaet, what do you expect for a go or no-go?
[21:46] <Daviey> Interesting concept, The PPA could be called 'Ubuntu experimental' where developers stage uploads which are still alpha.
[21:46] <skaet> doko,  I don't understand why we don't use the PPA option more often, so figure there must be some downsides.
[21:47] <doko> skaet, why should we?
[21:48] <skaet> doko, risk management for pervasive changes
[21:49] <doko> skaet, so why don't we use for the kernel across architectures?
[21:49] <doko> s/use/use it/
[21:49] <ScottK> Non-canonical people aren't allow access to unvirtualized PPAs AIUI, so it'd be a Canonical only PPA.
[21:50] <doko> to upload yes, to access no
[21:50] <slangasek> also, it's more manual work to copy from a ppa instead of pushing straight to the archive
[21:51] <slangasek> so in most cases the extra effort probably outweighs any risk we're mitigating?
[21:52] <skaet> doko, for the stable kernels are copied -proposed, and tested for 2 weeks before they go to -updates,  which is the same concept.
[21:52] <doko> skaet, fine, but we are not talking aboout -updates
[21:53] <slangasek> NCommander: "fix up anything that might break" - this is literally a change to the size of a buffer being malloc()ed to contain the name of a path; there is no impact on code generation
[21:54] <slangasek> while I can see not wanting to risk having the build started during beta freeze and finish after milestone candidates are rolled with the result that libgcc and friends are out-of-date on the beta CD before we even get started, there's no reason for there to be anything than breaks and needs fixing
[21:57] <ScottK> And exactly right now would be the time to do it so that if there is a problem there's actually time to react.
[21:58]  * skaet pondering hard
[21:58] <skaet> doko,  how long will the builds take across all the architectures?
[22:00] <doko> skaet, if I use my buildd admin powers on armel, about 36h
[22:00] <doko> s/use/misuse/
[22:01] <slangasek> that implies building all of the different packages in parallel, yes?
[22:02] <doko> this is for the default only.
[22:02] <doko> I don't care when the non-defaults reach the archive
[22:03] <skaet> doko, if we're going to do it, it all needs to be build and settled down before Sunday night, otherwise we run into the libgcc issue that slangasek points out.
[22:04] <doko> skaet, please could you elaborate on the libgcc issue?
[22:04] <slangasek> doko: libgcc out of date on the CD before we've even released the milestone
[22:05] <slangasek> it breaks jigdo, means everyone sees "updates available" at all points during the milestone testing
[22:05] <slangasek> we ideally want to avoid that
[22:05] <doko> slangasek, how will be a driver change affect libgcc?
[22:06] <slangasek> doko: it's not that it breaks anything, it's just that we want milestone CDs to contain up-to-date packages
[22:07] <slangasek> doko, skaet: but it sounds like the conclusion is that we want gcc-4.6 uploaded to the freeze queue ASAP; and as long as "ASAP" is before end of day tomorrow, and the armel buildds are in good shape with no backlog, we can accept this and get it built easily by that deadline
[22:08] <skaet> slangasek,  yes,  I think that's where we're ending up.
[22:08] <slangasek> and if the upload and accept happen today, that even buys us enough time for a *second* armel build if the buildd gets 95% done and then falls over ;P
[22:09] <skaet> Should I assume we're also also doing the gcj, gnat, gdk at the same time? Or do we want to start them now.
[22:09] <doko> finally, thanks! I'll do this the first thing tomorrow morning
[22:10] <doko> skaet, I'd like to delay these over the weekend, when the buildd loads are ower
[22:10] <doko> s/ower/lower/
[22:10] <skaet> doko,  ok.
[22:11] <skaet> doko,  for the 4.4 we wait until after beta2 is out.
[22:11] <skaet> ?
[22:11] <slangasek> maybe do 4.4 opportunistically if it's clear that there are spare buildds and it won't impact the milestone?
[22:11] <doko> skaet, thanks, so to summarize: I'l upload gcc-4.6 tomorrow morning, and anything else when I think the load doesn't effect any other builds?
[22:12] <slangasek> and it doesn't impact the CDs anyway, so if we have to kill a 4.4 build to free up a buildd it's not the end of the world
[22:12] <slangasek> doko: hard freeze, so you can certainly *upload* the others whenever you like
[22:12] <doko> I'm fine to have any other build killed besides gcc-4.6
[22:12] <skaet> doko,  do a cross check before uploading the other pieces, as we may have something in planning about to hit, but yes.
[22:13] <slangasek> skaet: uploading doesn't hurt us, release team still has to accept the upload by hand... :)
[22:13] <skaet> slangasek, yeah just realized that after I typed it. :)
[22:13] <doko> skaet, sorry, didn't understand the cross remark
[22:14] <skaet> doko,  no matter,  slangasek correctly points out, release team will need to let them in to start building.  We're hard frozen.
[22:16] <skaet> and based on what you're saying, as long as gcc 4.6 is built, others can be killed off at need.
[22:17] <doko> thanks for confirming.
[22:17] <doko> just want to use the idle time on weekends
[22:17]  * skaet nods
[22:18]  * skaet is worried about the arm builds though, and not sure how much idle time there will be. 
[22:24] <doko> skaet, slangasek , we do have 17 armel buildds. so he buildds will pick up main builds with the first priority. it's the abolute build time which matters. and even then,  a fix in the driver doesn't change anything in code generation.
[22:26] <skaet> doko,  thanks for explanation.  Problem is that the arm buildds are broken right now, and we still don't have all the pieces for some of the images built.  Ncommander's trying to get it sorted.
[22:27] <doko> skaet, sorry, didn't know. care to send a pointer?
[22:30] <skaet> doko, pointer in pm.
[23:01] <infinity> doko / skaet : The ARM buildd issue is with image builders, not package buildds.  Using build time on the package buildds shouldn't be a big deal, as long as it's done sanely.
[23:02] <skaet> inifinity,  thanks for explanation.
[23:41] <SpamapS> eucalyptus FTBFS on armel..