[01:37] <cjwatson> archive.ubuntu.com mirroring seems to be busted; I've notified #is on internal IRC, although I'm not expecting anyone to be around right now
[02:36] <cjwatson> apparently pending onsite sysadmin in the UK, so mirrors are probably not going to update until the morning
[04:29] <ogasawara> cjwatson: I just uploaded the kernel
[07:52] <slangasek> doko: lucas has done an archive test rebuild for me to check out the impact of bug #750585 on the archive; it looks like this breaks biarch packages, which I should have thought of.  Do you think it's reasonable for the gcc-multilib metapackage to own a symlink of /usr/include/asm to /usr/include/x86_64-linux-gnu/asm?
[07:52] <ubot4> Launchpad bug 750585 in linux (Ubuntu Oneiric) (and 2 other projects) "[FFe] support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 582)" [Undecided,Fix committed] https://launchpad.net/bugs/750585
[10:04] <cjwatson> ogasawara: great, thanks
[10:05] <pitti> cjwatson: good morning; recovered from the late-night shift?
[10:05] <cjwatson> I think so
[10:05] <cjwatson> coffee cures many things
[10:05] <cjwatson> I need a holiday though
[10:06]  * pitti looks at the clock, looks like freeze time?
[10:06] <pitti> not that we could build CDs right now, due to the mirror breakage, but at least we can switch to controlled mode
[10:07]  * pitti asks IS
[10:08] <chrisccoulson> we're not unfreezing again before release are we? i'm slightly confused with the lack of RC ;)
[10:08] <pitti> chrisccoulson: right
[10:09]  * slangasek waves
[10:09] <pitti> hey slangasek
[10:09] <slangasek> hi there!
[10:10] <slangasek> pitti, cjwatson: eglibc needs an upload at some point before release for bug #750585 to make it buildable again; should I upload this now?
[10:10] <ubot4> Launchpad bug 750585 in newlib (Ubuntu Oneiric) (and 14 other projects) "[FFe] support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/750585
[10:10] <cjwatson> slangasek: does this need to land after linux has finished building on all architectures?
[10:10] <pitti> slangasek: will that even build in time for arm?
[10:10] <slangasek> cjwatson: no, the eglibc patch is written to be safe before and after the multiarch dir switch
[10:11] <slangasek> pitti: it's about a 6hour build for arm
[10:11] <slangasek> and the next six hours are your guys' department not mine ;)
[10:12] <slangasek> sorry, 7 h
[10:13] <slangasek> newlib, klibc also need uploads but there's obviously much less of an impact on image building (klibc: 13min build on armel)
[10:14] <pitti> seems ok to me, the buildds are still quite busy, though
[10:14] <cjwatson> the armel buildds are thoroughly backed up, but I'm guessing that's a mass give-back of some kind?
[10:14] <slangasek> hum, is there?
[10:14] <pitti> cjwatson: it's still the archive rebuild test
[10:15] <cjwatson> oh, it wasn't clear in the UI
[10:15] <slangasek> ah; that shouldn't compete with main archive builds, should it?
[10:15] <cjwatson> at any rate, some of the stuff they're building is in universe, so I think is OK to be preempted if we need it
[10:15] <cjwatson> yeah, our main builds should win
[10:15] <slangasek> so: yes to eglibc upload?
[10:15] <cjwatson> in fact our builds should win in general
[10:15] <cjwatson> yes
[10:15] <slangasek> uploading
[10:15]  * cjwatson wants a maximally-buildable beta-2
[10:18] <pitti> cjwatson: FYI, I got the main NBS sorted out yesterday (just waiting on archive catch-up), working on universe now
[10:18] <pitti> yay libpoppler porting
[10:31] <slangasek> eglibc, newlib, klibc all uploaded
[10:32] <slangasek> and gcc-defaults.  I'll give http://people.debian.org/~lucas/logs/2011/04/11/res.ubuntu.amd64.new-failures a thorough review in the morning, but these seem to be all either biarch packages (fixed already via gcc-multilib) or random noise
[10:41] <slangasek> right, launchpad's not yelling at me, so time for me to grab some shut-eye
[10:42] <slangasek> talk to you in a few hours :)
[11:10] <ev> what group membership is required to target bugs to O?
[11:11] <pitti> I had expected core-dev
[11:11] <micahg_> should be the same as anything else
[11:11] <pitti> at some point this should be fixed to "the same set of people who can upload the package"
[11:11] <micahg_> core-dev or motu depends on main or universe
[11:14] <micahg_> is bug 751038 worth trying to get in?
[11:14] <ubot4> Launchpad bug 751038 in tex-common (Ubuntu) "/usr/sbin/update-language-def: line 779: printf: missing unicode digit for \u (affects: 3) (heat: 20)" [Low,Triaged] https://launchpad.net/bugs/751038
[11:16] <ev> pitti: doesn't appear to be the case. I can only nominate ubiquity bugs for O.
[11:21] <pitti> accepting pidgin, FTBFS fix
[11:31] <pitti> rejecting life, FTBFSes still (sorry, dput'ed the wrong .changes)
[11:44] <didrocks> bamf/nux/unity uploaded. Compiz still need some testing but will come shortly
[11:47] <pitti> thanks didrocks, I'll handhold them
[11:48] <didrocks> thanks pitti :)
[11:48] <pitti> didrocks: do they have proper build-deps?
[11:48] <didrocks> pitti: yeah, should be ok
[11:48] <pitti> i. e. can we accept them in any order, or does it need waiting?
[11:48] <didrocks> no no, I tend to be strict on that :)
[11:48]  * pitti hugs didrocks
[11:48] <didrocks> so unity should build-dep on new nux
[11:48]  * didrocks hugs pitti back
[11:49] <pitti> ^ rejected, packaging bug
[11:49] <pitti> (see #u-devel)
[11:51] <pitti> accepting nux/bamf/unity as discussed on last release meeting
[12:10] <pitti> I'm off for lunch
[12:15] <didrocks> pitti: compiz ready in 5 minutes, just doing some final tests
[12:26] <didrocks> pitti: and compiz uploaded!
[13:03] <pitti> didrocks: ^ :)
[13:03] <didrocks> pitti: thanks :)
[13:11] <pitti> ScottK, cjwatson: I'd like to sync flightgear 2.0.0 from Debian; seems in our autosync we caught simgear 2.0.0, but have flightgear 1.9.1 still (which is now depending on NBS simgear1.9.1)
[13:11] <ScottK> pitti: Sounds reasonable.  I'd go for it.
[13:12] <cjwatson> fine by me
[13:14] <pitti> accepting ubuntu-mono; two beta-2 targetted bugs, and looks safe
[13:15] <pitti> accepting gconf; no-op on i386/amd64, and unbreaks armel build
[13:15] <pitti> s
[13:17] <pitti> ogra_: I see the alsa-lib upload for bug 746023; does it also require a pulseaudio upload? do they depend on each other?
[13:17] <ubot4> Launchpad bug 746023 in pulseaudio (Ubuntu Natty) (and 3 other projects) "No sound on omap4 (affects: 2) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/746023
[13:17] <ogra_> pulse depends on the config to be in place
[13:18] <ogra_> we need the config in any way while the pulse patches are still eing tested
[13:18] <ogra_> *being
[13:18] <pitti> ok, thanks; looked like that, but want to make sure to not break anything at this point
[13:19] <ogra_> you wont, luke is very careful :)
[13:31] <ScottK> pitti: The python2.7 upload in queue fixes Bug #755616 (even though it's not mentioned in the changelog).  It's a 7+ hour build on armel, but it seems like something we want fixed.  I didn't do more than look at the diff, but it seems like a logical change.
[13:31] <ubot4> Launchpad bug 755616 in python2.7 (Ubuntu) "Python curses is not linked to libncursesw (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/755616
[13:32] <pitti> ScottK: I was trying to avoid it right now, until the buildds have caught up, as it doesn't seem critical for the beta-2 images? or is it?
[13:33] <ScottK> I guess it's not critical for beta2.
[13:33] <ScottK> I think we definitely want it before release.
[13:33] <pitti> *nod*
[13:33] <ScottK> Tactically I'm not sure if it's better to go ahead or not.
[13:33] <ScottK> I'm OK with either way.
[13:34] <pitti> I'd like to wait at least 2 hours for i386 to catch up
[13:34] <pitti> otherwise we keep having uninstallability due to langpacks
[13:36] <ScottK> OK.
[13:36]  * ogra_ would like images too on armel ... 7200 packages in the queue, sniff
[13:36] <pitti> ogra_: that's just the test rebuild (mostly)
[13:36] <ogra_> yeah, i know
[13:36] <pitti> they yield to any "real" upload
[13:37] <ogra_> doesnt help much if only big packages are already building though
[13:37] <ogra_> if the buildds are busy queue priority sadly doesnt help a lot
[13:40] <ScottK> That's when you need lamont around to shoot the annoying build in the head.
[13:41] <ScottK> chrisccoulson: The difference this time isn't that we are lacking an RC.  The difference is we aren't pretending to have one.
[13:41] <ogra_> heh, yeah
[13:42] <chrisccoulson> ScottK - thanks ;)
[13:42] <chrisccoulson> i guess that RC should normally be what we intend to ship ;)
[13:42] <ScottK> That's the usual definition.
[13:43] <chrisccoulson> (like with firefox. in fact, i just uploaded a new tarball for that because people kept getting confused that the ~rc2 build we had was actually the final release)
[14:16] <Riddell> kubuntu smoke testing all good with yesterdays images
[14:24] <jibel> ubuntu desktop i386/amd64 smoketest passed
[14:24] <jibel> wubi install and upgrade passed
[14:24] <jibel> ubuntu desktop upgrade passed
[14:24] <pitti> jibel: wubi> yippie
[14:26] <cjwatson> excellent
[14:26] <cjwatson> same partition as Windows, or different?
[14:26] <cjwatson> (mind you I've already had confirmation of both cases)
[14:27] <jibel> cjwatson, same partition, I'm trying different atm.
[14:27]  * cjwatson nods
[14:31] <jibel> on alternate I have a problem with partman. When a partition already exists and the user accepts the defaults, the installer refuses to continue with 'No root filesystem'. There's no 'guided partitioning'  option too.
[14:31] <cjwatson> jibel: you need to explicitly select a partition to mount on /
[14:32] <cjwatson> it is intentional that the defaults do not overwrite your disk
[14:32]  * pitti really isn't happy about the linphone FTBFS fix he just uploaded, but it's the only approach that works and doesn't require major reengineering
[14:44] <jibel> cjwatson, agree but wasn't there 'guided partitioning' and 'resize existing partition' options directly from the main menu, it's gone ?
[14:45] <jibel> on a fresh driver, I have to create all the partitions manually.
[14:46] <jibel> cjwatson, anyway, even with manual partitioning the installation fails with libnotify4 (>= 0.7.0) is not installable
[14:47] <cjwatson> jibel: well, that last is not an installer bug, it's just inconsistent archive syndrome
[14:48] <cjwatson> jibel: resizing is only offered sometimes and depends on the circumstances
[14:49] <cjwatson> jibel: guided partitioning should usually be offered, but there are some constraints; for example, if the only disk also contains the installation medium, it won't be offered.  I'd need to see logs (preferably with DEBCONF_DEBUG=developer) to make sure.
[14:51] <cjwatson> hmm, something does seem to be wrong though
[14:53] <cjwatson> whoa!
[14:53] <cjwatson> who ate partman-auto?
[14:53] <pitti> "ate" == "lost upload"?
[14:54] <cjwatson> I'm not sure, but it's missing from the CD
[14:54] <cjwatson> that would be causing jibel's problem
[14:55] <cjwatson> jibel: thanks for spotting that; I'll sort it out
[14:55] <ScottK> pitti or cjwatson: I just marked Bug #757427 critical is it looks to me like the root of 4 armel FTBFS in Main this morning.
[14:55] <ubot4> Launchpad bug 757427 in gconf (Ubuntu) (and 1 other project) "gconftool-2 segfaults on arm (affects: 1) (heat: 8)" [Critical,Confirmed] https://launchpad.net/bugs/757427
[14:55] <pitti> ScottK: I thought the recent gconf upload was supposed to fix that
[14:56] <ScottK> Maybe it's archive skew then.
[14:56] <ScottK> They all failed today though.
[14:56] <pitti> no, the changelog didn't mention the bug
[14:56] <jibel> cjwatson, on wubi installed from a French Windows 7, I get this bug 742558
[14:56] <pitti> I'll close it manually
[14:56] <ubot4> Launchpad bug 742558 in ubiquity (Ubuntu Natty) (and 3 other projects) ""Keep default keyboard layout ..." dialog is confusing (affects: 2) (dups: 1) (heat: 229)" [High,Fix released] https://launchpad.net/bugs/742558
[14:56] <cjwatson> jibel: in fact, it's just a rather unusual casualty of the mirror system falling over last night - I'll schedule a rebuild
[14:56] <pitti> ScottK: thanks for pointing out
[14:56] <cjwatson> jibel: separate bug, please
[14:56] <ScottK> pitti: So I should retry those builds?
[14:56] <jibel> k
[14:56] <pitti> ScottK: hang on, checking publicatino
[14:57] <ScottK> OK.
[14:57] <ScottK> BTW, no point in retrying compiz on armel until kde4libs finishes and is published.
[14:57] <pitti>     gconf2 | 2.32.2-0ubuntu1 |         natty | armel
[14:57] <pitti>     gconf2 | 2.32.2-0ubuntu2 |         natty | amd64, i386, powerpc
[14:57] <pitti> meh, not yet
[14:57] <ScottK> OK.
[14:57] <cjwatson> jibel: (with logs, so that I can get the same kernel args, since I don't have French Windows)
[14:58] <pitti> ScottK: it's in accepted, so we can retry in one ohur
[14:58] <pitti> hour, too
[14:58] <ScottK> pitti: Great.  The only other new failures were due to slangasek's biarch problem.
[14:59] <ScottK> (alsa-lib and klibc)
[15:00] <ScottK> Unity was archive skew, I already retried it.
[15:21] <pitti> CD cron jobs on manual; with the current churn there's not much point in auto builds
[15:25] <ScottK> Getting close on draining the language packs out of i386.
[15:26] <pitti> yes, and an hour for ppc to catch up
[15:28] <pitti> hm, seems the libx264 transition failed on powerpc, looks we'll need another set of uploads there
[15:40] <cjwatson> sorry for the short notice, but I'd appreciate a MIR team member having a look at bug 757600
[15:40] <ubot4> Launchpad bug 757600 in grub-gfxpayload-lists (Ubuntu) "[MIR] grub-gfxpayload-lists (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/757600
[15:41] <cjwatson> it's my oversight that that wasn't done earlier
[15:52] <pitti> asked in #u-devel
[15:54] <cjwatson> thanks
[15:54] <cjwatson> should be really quick
[15:54] <cjwatson> I think I'll make grub-pc recommend it
[15:54] <cjwatson> or I suppose it could just be a dependency, why muck about
[16:05] <pitti> oh, x264 FTBFSed on powerpc, which explains why it didn't catch the transitional uploads
[16:13] <ScottK> pitti: Any objection to Bug 757540?  It seems to me very much the Ubuntu thing to do to provide the correct font for someone's language.
[16:13] <ubot4> Launchpad bug 757540 in ttf-kacst-one (Ubuntu) "Missing many Glyphs to support Uyghur (Uighur) Language (affects: 1) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/757540
[16:13] <ScottK> AnAnt says he's tested it in Uyghur and it works correctly.
[16:16] <pitti> ScottK: it's installed by default, so my biggest worry is the deb size delta; otherwise no objection
[16:17] <ScottK> OK.  I'll check on that.
[16:32] <ScottK> FYI, I checked Universe/Multiverse armel build failure 4/7 and later for the gconf problem and only found one (mutter) which I retried.
[16:32] <ScottK> Not sure if that was far enough back or not.
[16:35] <jibel> wubi fresh install and upgrade from Maverick on different partition than Windows passed \o/
[16:41] <jdstrand> skaet: I didn't follow up with you, but understand the hardy desktop eol email is going out today
[16:41] <skaet> jdstrand,  yes
[16:42] <jdstrand> skaet: I may not understand all that is going on, but I don't see a reason to stagger eol announcements-- there is nothing to do aiui (IS will do some stuff a few months after the eol, but beyond that, nothing)
[16:42] <jdstrand> skaet: am I missing something?
[16:43] <jdstrand> (nothing to do beyond the email)
[16:43] <skaet> jdstrand, there's some coordination with the OEM teams involved
[16:43] <cjwatson> jibel: cool
[16:44] <jdstrand> skaet: I see. I think this might be a good time to restate my opinion that LTS eol announcements should happen 2-3 months prior to eol, in addition to the 1 month
[16:44] <skaet> jstrand,  yes, I think its a topic we need to talk through a bit at UDS.
[16:45] <skaet> jdstrand, problem wasn't the email, but what had to happen a month from the email.
[16:45]  * jdstrand nods
[16:46] <skaet> jibel,  cjwatson,  re: WUBI again - \o/
[16:48] <jdstrand> skaet: also, I have no idea what oem has to do, but there are not insignificant support costs for the security team with delaying EOL announcements (I think I said this on friday). I realize it is already done at this point, but going forward I think our team should be consulted if the eol will be delayed
[16:55] <skaet> jdstrand, will do.   My assumption was since hardy server is still going to be supported, there was still hardy tracking that had to be done by the security team.
[16:56] <jdstrand> skaet: that is true-- but we will issue security updates for desktop up to the day of eol. those may cause extra work
[16:56] <jdstrand> they may not, it depends on what floats in
[16:57] <skaet> jdstrand, understand.   Agree will consult with you next time if the date looks like its going to need to move.
[16:58] <jdstrand> skaet: thanks
[17:15] <ScottK> pitti: It just occured to me that you might want to use the new "Not Automatic" feature for -proposed too so people can enable proposed and just install the package they are after to test.
[17:16] <pitti> ScottK: that's in natty?
[17:16] <pitti> that's interesting for the "plz test me" emails indeed
[17:16] <ScottK> pitti: Yes.  It's activated for natty-backports.
[17:16] <pitti> for the record, syncing vdr; current version doesn't build and is v4l1 only (which linux 2.6.38 dropped); sid version got ported to v4l2, confirmed to build on natty
[17:16] <ScottK> (not that I can do live fire testing yet)
[17:17] <pitti> (ubuntu changes not required any more)
[17:17] <ScottK> pitti: AFAIK, all you need to do is ask someone like wgrant to enable it for natty-proposed.
[17:18] <pitti> interesting; I had expected this to be configured in apt (default pin priorities)
[17:18] <ScottK> It's in the packages.gz.
[17:18] <ScottK> Apt in Natty knows about this.
[17:18] <pitti> ScottK: btw, gconf/armel is in , so you can give back the failed builds
[17:18] <pitti> bbl, dinner
[17:19] <ScottK> Did.  They seem to be doing well.
[17:20] <ScottK> If I remember wrong about the not-automatic thing, I'm sure wgrant or mvo will correct me.
[17:59] <pitti> cjwatson, ScottK: python2.7 doesn't build arch:all with versioned dependencies to arch: any packages, so I think accepting it now to make use of the (soon to be) idle buildds would work
[17:59] <ScottK> Sounds good to me.
[18:00] <pitti> cjwatson: for coordination,  I accepted the ones from the queue which looked safe and fixed beta-2 RC bugs; I'm planning to start the full set of image builds over night when I'm back from Taekwondo, around 2130 UTC; sounds ok to you?
[18:00] <pitti> skaet ^
[18:00] <cjwatson> um
[18:00] <pitti> provided that the armel kernel has finished by then
[18:00] <cjwatson> there are still a few translation uploads to go (in progress) and a lot of open bugs
[18:00] <cjwatson> the armel kernel won't be close to finished by then, by my calculations
[18:00] <cjwatson> I think I looked it up and it was going to be somewhere in the small hours UTC
[18:01] <ScottK> gnome-games failed for non gconf reasons.  Someone who knows about GIR might want to look https://launchpadlibrarian.net/69045260/buildlog_ubuntu-natty-armel.gnome-games_1%3A2.32.1-0ubuntu5_FAILEDTOBUILD.txt.gz
[18:01] <pitti> I'm not saying that these are necessarily the last ones
[18:01] <skaet> pitti,  cjwatson,  can we get the non armel ones started, so i386/amd64 testing can start?   or are there some dependencies I'm not aware of?
[18:01] <cjwatson> can we just let cron do it tomorrow?
[18:01] <pitti> but I'd at least have desktops with all the updates from today
[18:02] <cjwatson> skaet: certainly can't do it right now, there's grub2 being built, ubiquity on its way, debian-installer and gfxboot-theme-ubuntu to come, and that's just what I know about
[18:02] <pitti> cjwatson: personally I'm not a huge fan of the cron'ed ones right now, as they won't check for the armel kernel, and are also spread out over the day
[18:02] <skaet> cjwatson,  thanks.
[18:03] <cjwatson> pitti: so I suppose overnight makes some sense, but I think it's going to need to be a couple of hours later than that
[18:03] <pitti> I'd at least use the night hours to build the images which have stabilized by then, so that we can do testing tomorrow morning
[18:04] <pitti> cjwatson: I'm planning to stay up late anyway, so that sounds fine
[18:05] <pitti> perhaps best to just check again when I'm back; if you are already asleep, I'll just check the queues/archive, if not we'll sync up?
[18:08] <cjwatson> I don't expect to be around much this evening
[18:11] <slangasek> pitti: is this something you'd like me to track and kick off images when things are ready?
[18:12] <pitti> slangasek: I'm still trying to find that out; I'm reviewing ubiquity, d-i, and gfxboot-theme-ubuntu right now, those are the three that Colin mentioned
[18:12] <slangasek> ok
[18:13]  * cjwatson -> gone
[18:13]  * slangasek waves
[18:13] <pitti> cjwatson: bye, have a nice evening!
[18:14] <pitti> slangasek: so I think we should build desktops and alternates after these three are in, and u/kubuntu/kubuntu-mobile/headless preinstalled once the armel kernel has finished (https://launchpad.net/ubuntu/+source/linux/2.6.38-8.42/+buildjob/2440470)
[18:14] <pitti> so that we have a reasonably current set of images for more detailled smoketesting
[18:40] <pitti> need to go, back in some 3 hours
[19:00] <stgraber> is bug 752393 something that we want fixed for beta2 ? (I don't think it's critical and would like to have someone review the fix as I'm not too familiar with lsb ;))
[19:00] <ubot4> Launchpad bug 752393 in lsb (Ubuntu) "lsb init scripts show line buffering problems on bootup (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/752393
[19:03] <ScottK> stgraber: I think we definitely want it for final and lsb is a quick build, so I'd be inclined to take it for beta2.
[19:04] <stgraber> ScottK: do you feel like reviewing the patch or prefer someone else to look at it ?
[19:05] <ScottK> I'd prefer if cjwatson or slangasek reviewed it.  Please go ahead and upload so that they can review it in the queue.
[19:05] <stgraber> ok, thanks
[19:05] <skaet> stgraber, have gone in and explicitly targetted it to Natty as well.   Will leave it to someone more knowledgable to review.
[19:06] <skaet> ScottK,  cjwatson's off for the night,  so it will probably need to be slangasek if we want to get it into beta2 at this point.
[19:06] <ScottK> OK.
[19:07] <ScottK> pitt could review it too, I know he's coming back later.
[19:09] <stgraber> skaet, ScottK: uploaded
[20:13] <slangasek> stgraber, skaet, ScottK: reviewing
[20:29] <slangasek> stgraber: why is the plymouth buffering code inside the check for log_use_fancy_output && $TPUT xenl?  doesn't the same issue apply when this is not set?
[20:30] <stgraber> slangasek: the non-fancy output didn't seem to use "echo -n" or similar so it shouldn't be affected by the buffering issue
[20:31] <stgraber> I'm not saying the output will be pretty but it's not going to have some upstart output mixed in at least
[20:31] <slangasek> right, ok
[20:40] <slangasek> stgraber: there's a small window between when log_end_msg calls log_daemon_msg again, and when it prints its own output, where other messages could be printed.  I guess we're ignoring this for now?
[20:41] <slangasek> stgraber: the whole thing seems a workaround, vs. cjwatson's suggestion to use the plymouth protocol natively
[20:41] <stgraber> slangasek: unless you have an easy way of avoiding it, I'd just go with the current workaround
[20:41] <slangasek> not an easy one, no :)
[20:42] <stgraber> ideally both lsb and upstart scripts should go through plymouth for that kind of logging, but that'd need a bit more changes to some core components to get done
[20:42] <slangasek> and you've tested booting with this code before upload, right?
[20:42] <stgraber> yep, I tried booting that code with and without the fancy output and SpamapS who reported the issue tested it too
[20:43] <stgraber> for Oneiric we should really try to get some proper logging at boot time, which ideally would catch all lsb and upstart events (that's including the time where upstart doesn't talk over dbus) but it doesn't seem like a trivial thing to do
[20:43] <slangasek> oh, another small buglet... if plymouth has gone away between log_daemon_msg and log_end_msg, you never print $LOG_DAEMON_MSG anywhere... but that's scarcely worse than printing it to a different place
[20:44] <slangasek> so, accepted
[20:45] <stgraber> currently I have a completely random boot.log on my machine, 9 out of 10 times, dbus starts so late that plymouth-upstart-bridge doesn't get any event to log so I end up with only the lsb output being logged :)
[20:45] <stgraber> slangasek: thanks
[21:39] <pitti> re
[21:41] <skaet> slangasek, pitti, - why is evolution being updated after freeze?  anyone know which bug this associated with?
[21:41] <slangasek> haven't looked, let's see
[21:41] <pitti> skaet: doesn't look like it's critical for beta-2
[21:41] <pitti> but I'm just catching up on the last 3 hours
[21:42] <skaet> fair 'nuf.  :)
[21:43] <seb128> hey skaet
[21:43] <pitti> right now, nothing in the queue looks particularly urgent to me
[21:44] <skaet> seb128,  what's up?
[21:44] <pitti> https://launchpad.net/ubuntu/+source/linux/2.6.38-8.42/+buildjob/2440470 is still busy for a couple of more hours (armel)
[21:44] <seb128> skaet, we got quite some people today confused by the schedule, it would be nice to clarify when beta2 should be out and if selected fixes will go in between beta2 and natty
[21:45] <seb128> skaet, there was at least 5 people asking about that today from different teams
[21:45] <pitti> hm, why is euca still uninstallable..
[21:45] <pitti> ah, python-psutil
[21:45] <pitti> fixed
[21:46] <skaet> seb128,  hmm... broadcast to u-d?
[21:46] <seb128> skaet, or clarify on https://wiki.ubuntu.com/NattyReleaseSchedule, like it doesn't have an "beta2 is out" or an "hard freeze"
[21:48] <pitti> slangasek, skaet: I think now would be a good time to build new i386/amd64 images; I can set a trigger for armel when the kernel finishes building; WDYT?
[21:48] <skaet> heh,  NattyReleaseSchedule has beta2 as 4/14...  but I can add redundancy and add hard freeze
[21:48] <pitti> I don't expect these to be the beta2 ones, but we currently have a sane archive AFAICS
[21:48] <skaet> pitti,  +1 from me,  if the packages cjwatson flagged are in.
[21:48] <pitti> python-psutil still needs a publisher run for server, I'll queue that accordingly
[21:48] <pitti> skaet: yes
[21:49] <seb128> skaet, well some updates will go in between beta2 and natty no?
[21:49] <seb128> skaet, so when would be the real hard freeze for natty?
[21:49] <slangasek> pitti: yes, looks good to me
[21:49] <skaet> seb128 bug fixes only.
[21:50] <seb128> skaet, right, well the schedule doesn't make clear what is the slot for those fixes
[21:50] <slangasek> seb128: we're already in the hard freeze for natty; the archive is frozen, nothing goes in between now and release except by the hand of the release team
[21:50] <seb128> skaet, that's what people were mostly asking today
[21:50] <ScottK> Did they read the u-d-a message that explained all this?
[21:51] <seb128> slangasek, well"BetaFreeze" points to https://wiki.ubuntu.com/BetaFreeze which states "Once the BetaRelease is shipped, we roll back to FeatureFreeze and UserInterfaceFreeze status. "
[21:51] <pitti> desktop/DVDs started for all flavours
[21:51] <seb128> slangasek, that got the u1 team confused at least
[21:53] <seb128> ScottK, which one?
[21:53] <pitti> alternates/server triggered on wait-for-package python-psutil_0.1.3-1ubuntu1
[21:53] <ScottK> seb128: I was thinking of this one, but after re-reading it, it's less clear than I remembered: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-February/000823.html
[21:54]  * skaet looking back in the archives and figuring a bit of overcomunicating is now appropriate. 
[21:54] <seb128> ScottK, it was also a while ago
[21:54] <seb128> there was no recent email
[21:54] <pitti> slangasek: do you know if it's safe to start several wait-for-package's in parallel?
[21:55] <slangasek> pitti: they may get a little confused when trying to each trigger their own mirror sync, but I think it's still safe
[21:55] <ScottK> The more detailed discussion that I was thinking of was only on -release.  https://lists.ubuntu.com/archives/ubuntu-release/2011-March/000184.html
[21:55] <pitti> slangasek: well, I think I'll just wait with triggering the armel builds; the server ones will start in an hour, and I'll still be awake by then
[21:55] <pitti> slangasek: but good to know in general
[21:56] <pitti> (bbl)
[21:57] <ScottK> I thought there was a more detailed recent mail, but I can't find it.
[21:57] <skaet> ScottK,  I thought I sent one out as well - but am not spotting it in the archives.
[21:58] <ScottK> pitti, slangasek: Shouldn't we wait for python2.7 on armel or is it safe to assume that finishes before the kernel?
[21:58] <skaet> so,  will do.
[21:59] <skaet> thanks for flagging seb128
[21:59] <slangasek> ScottK: the kernel is a ~24h build that's only 17 hours in, I'm pretty sure we're clear there
[21:59] <ScottK> OK
[21:59] <slangasek> but double-checking
[21:59] <slangasek> ah, python2.7 took 7h12m last time on armel
[21:59] <seb128> skaet, you're welcome
[21:59] <slangasek> pitti: ^^ so python2.7 may be the limiting factor for armel builds
[22:00] <slangasek> (might be - by a hair - so we should wait for both)
[22:01] <ScottK> slangasek: Also kde4libs just finished a few minutes ago on armel, so any Kubuntu images spun before the next publisher will be out of date.
[22:02] <slangasek> we're waiting before building any arm images though, aren't we?
[22:02] <ScottK> Oh, right.
[22:02] <ScottK> Sorry.  Too many moving parts.
[22:02] <slangasek> no worries
[22:04]  * ScottK pushed dhcp3 right through.
[22:20] <pitti> ScottK, slangasek: I don't think the new python2.7 is important to have on the next armel images, but sure, we can wait for it
[22:30] <slangasek> pitti: arm images take long enough to build that I think waiting 1 hour is probably appropriate
[22:30] <slangasek> (since kernel and python probably land less than 1h apart)
[22:30] <pitti> *nod*
[22:34] <mvo> (note about the software-center debdiff, the submit_{review,report,usefulness} is actually a symlink in the tar, still it shows up multiple times in the diff, its the same script called with different personalities)
[23:03] <pitti> http://cdimage.ubuntu.com/daily-live/20110411.1/
[23:03] <pitti> there, hot off the press
[23:07] <pitti> skaet: would you be able to add the images to the iso tracker as they trickle in?
[23:07] <skaet> pitti,  sure.  What order should they be coming in?
[23:08] <pitti> skaet: I just posted ubuntu desktop; k desktop will follow in a few minutes, xubuntu building now, then mythbuntu, kubuntu-mobile, ubuntu dvd, edubuntu dvd, kubuntu dvd
[23:09] <skaet> pitti,  ok,  sounds good.   will check in that sequence.
[23:10] <pitti> skaet: I just started building alternates: ubuntu kubuntu xubuntu ubuntu-server ubuntustudio
[23:10] <pitti> for some reason wait-for-package fooled me, should have triggered 15 minutes ago already
[23:17] <slangasek> doko: bugger, why does g++-multilib not depend on gcc-multilib?  gcc-4.[56] will still FTBFS because this is only fixed for gcc-multilib and they build-depend on g++-multilib
[23:17] <slangasek> doko: so gcc-defaults will need another upload before release - do you want me to add the same compat symlink to g++-multilib, or add a g++->gcc dep?
[23:39] <pitti> slangasek, skaet: starting python/linux triggered pipeline for armel now
[23:39] <pitti> wait-for-package -a armel /python2.7_2.7.1-5ubuntu2 && wait-for-package -a armel linux-image-2.6.38-8-omap_2.6.38-8.42 && buildlive ubuntu-netbook daily-preinstalled && (for-project ubuntu-netbook cron.daily-preinstalled &) && echo kubuntu preinstalled && buildlive kubuntu daily-preinstalled && (for-project kubuntu cron.daily-preinstalled &) && echo kubuntu-mobile preinstalled && buildlive
[23:39] <pitti> kubuntu-mobile daily-preinstalled && (for-project kubuntu-mobile cron.daily-preinstalled &) && echo headless preinstalled && buildlive ubuntu-headless daily-preinstalled && for-project ubuntu-headless cron.daily-preinstalled
[23:40] <skaet> pitti,  ack
[23:40] <pitti> I expect this to trigger in some two hours
[23:40] <slangasek> right, thanks
[23:41] <pitti> if something gets in between just kill the wait-for-package process, and then the next one
[23:41] <pitti> with that, good night!
[23:41] <pitti> skaet: alternates/desktops are trickling in, btw
[23:41] <ogra_> pitti, you rock, sleep well
[23:41] <pitti> but I can add the remaining ones to the tracker in about 8 hours
[23:41] <skaet> pitti, thanks!   sleep well.
[23:41] <pitti> if skaet doesn't beat me to it :)
[23:42]  * skaet will go check it now....
[23:42] <pitti> {k,x,myth}buntu-desktop should be there now
[23:43] <jibel> skaet, it looks like natty-desktop-amd64+mac.iso is there too but not on the tracker
[23:46] <skaet> jibel,  looking into it now
[23:49] <SpamapS> I have a NEW package I'd like to upload to universe.. a tiny wordpress plugin to make wordpress work w/ drizzle. Do I need an ACK from the release team?
[23:55] <doko> slangasek: well, nobody did notice before ...  g++-multilib should depend on gcc-multilib
[23:55] <skaet> jibel, natty-dekstop-amd64+mac.iso now added.
[23:55] <slangasek> doko: ok, uploading now, thanks for confirming
[23:56] <skaet> jibel,  ubuntu desktop,  alternate,  kubuntu desktop, alternate all posted.