[03:56] <stgraber> ScottK, Riddell: someone reported bug 1039828 for kubuntu upgrades, I noticed something similar while working on another bug for mythbuntu, so if you want to fix it for 12.04.1, I'd be happy to grant an exception for that one
[03:56] <ubot2`> Launchpad bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1039828
[03:56] <stgraber> I believe just uploading a fix to -proposed and getting it copied to -updates before we set the upgrade flag on Thursday should be enough
[03:56] <stgraber> we probably don't want or even need to respin anything for it
[03:57] <stgraber> it looks like it may be linked to slangasek's change to get rid of defoma that's only calling rmdir while the directory may still contain something
[03:58] <stgraber> the rmdir can either be passed to || true or the call changed to an rm -Rf, I haven't spent enough time to figure out which of these two options would be the "right" one for this case
[03:58] <slangasek> is that code mine?
[03:58] <stgraber> let me check the diff
[03:59] <slangasek> if so, please take away my license
[03:59] <slangasek> as I've clearly been committing under the influence
[03:59] <stgraber> slangasek: yes, it's in https://launchpadlibrarian.net/102433012/fontconfig_2.8.0-3ubuntu8_2.8.0-3ubuntu9.diff.gz
[03:59] <stgraber> slangasek: 'rmdir $DEFOMA' where $DEFOMA in kubuntu and mythubuntu's case is non-empty
[04:00] <stgraber> though according to the changelog, it's a cherry-pick from Debian
[04:00] <slangasek>   Cherry pick from Debian experimental: Remove defoma support.
[04:00] <slangasek> right, not my code ;)
[04:00] <slangasek> stgraber: please use rmdir --ignore-fail-on-non-empty
[04:00] <stgraber> ok
[04:01]  * slangasek blahs at the importer failure
[04:03] <stgraber> I'll push it quickly then, I know I identified this one as being the next problem once we sort out bug 1017001 and it was on my try-to-fix-for-12.04.1-updates list (though it suddenly got a lot more important as kubuntu shows the same problem)
[04:03] <ubot2`> Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
[04:03]  * slangasek nods
[04:04] <slangasek> as far as 1017001 is concerned, maybe it would help to manually build apt from the release-upgrader-apt source package, to get the debugging info?
[04:05] <stgraber> yeah, that or patch the upgrader to call apt the way we want... I'll spend some more time on that one tomorrow. I'm almost done with the testing I needed to do for 12.04.1
[04:08] <stgraber> uploaded fontconfig to precise-proposed. Will check if quantal is also affected
[04:10] <slangasek> quantal will also be affected, yes
[04:10] <slangasek> (though with reduced frequency, I expect)
[04:16] <stgraber> slangasek: uploaded to quantal and updated bug description for SRU. Can you review and let it into -proposed?
[04:17] <slangasek> stgraber: yes.  Are you planning to have this in on CDs, or just as an immediately-available upgrade?
[04:19] <stgraber> so far I've seen no evidence of this bug on Ubuntu when using the 12.04.1 media as an upgrade source, so Kubuntu and Mythbuntu may want to respin as it's definitely the case for these but I don't think we'll want to respin Ubuntu alternate for it
[04:20] <slangasek> stgraber: OOI, when you hit the bug, what was left in the directory?
[04:20] <stgraber> I can't recall the name of the file, but I remember it wasn't owned by a package
[04:20] <slangasek> ok
[04:22] <stgraber> slangasek: id-cache
[04:22] <slangasek> lovely
[04:24] <stgraber> it seems to be a pretty long plain text file containing font names, paths and some font related details
[04:24] <stgraber> and not in an xml-like kind of syntax like fonts.conf
[04:24] <stgraber> proper xml actually (for fonts.conf), missed the two first lines for some reason
[04:33] <stgraber> skaet: ^ added to opportunity targets, if we think people with that package (quite a few lucid users apparently) doing LTS-to-LTS upgrades without internet connectivity is an important enough user base to warrant a respin to include the fix, the affected images would be ubuntu alternate, xubuntu alternate and kubuntu alternate
[04:33] <stgraber> although most of the other images do include that package, they can't be used as update source so won't show the problem
[05:33] <slangasek> stgraber: oh.  Looking at the error in the bug report description... are we sure this isn't caused by defoma-app failing to compile, and as a result the 'purge' command not running?  Maybe we should be worried about fixing that instead
[05:39] <slangasek> stgraber: ah, nevermind; bug #990555 shows a case where defoma-app succeeds and the directory is still non-empty.
[05:39] <ubot2`> Launchpad bug 990555 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/990555
[09:16] <babyface> anybody know why still no new desktop isos for today?
[09:17] <cjwatson> Have you checked the logs?
[09:17] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120822/livecd-20120822-i386.out
[09:18] <cjwatson> Same bug as you just brought up in -installer.  xserver-xorg-video-modesettings needs to be moved to main, which may or may not be blocked on an MIR (I haven't been keeping track).
[09:18] <cjwatson> tjaalton: ^-
[09:19] <cjwatson> Ah, I see conversation about that at ~18:11 UTC yesterday
[09:21] <tjaalton> yeah no MIR, don't think it would need one?
[09:22] <tjaalton> it's the defacto fallback driver if there is a kms driver already initialized
[09:22] <cjwatson> doko: Hello European MIR person who isn't on holiday.  ^- Do you think I'm OK to promote xserver-xorg-video-modesetting without an MIR?
[09:22] <cjwatson> The lack of it in main breaks the world :-(
[09:22] <doko> looking
[09:23] <babyface> cjwatson, so the build will be kicked out after the bug is fixed?
[09:23] <tjaalton> a rare beast that it's actually maintained upstream :)
[09:23] <cjwatson> babyface: Not automatically
[09:23] <cjwatson> I mean it would automatically happen tomorrow.  We'd probably run a manual build in this case
[09:23] <tjaalton> meant for hw that have a simple kms driver in the kernel, and don't need any fancy stuff from the ddx
[09:23] <babyface> cjwatson, ok, I see.  thanks.
[09:23] <doko> cjwatson, yes, looks ok
[09:23] <tjaalton> doko: thanks
[09:24] <cjwatson> doko: OK, thanks - moved to main
[09:24] <tjaalton> \o/
[10:03] <ogra_> erm
[10:04]  * ogra_ just looks at the nusakan crontab ... when were all the preinstalled daily arm builds re-enabled ?
[10:04] <ogra_> they should be gone
[10:04]  * ogra_ checks if the bzr crontab matches the actual one
[10:05] <cjwatson> If they were meant to be gone, nobody ever committed that to bzr
[10:05] <ogra_> months ago !
[10:05] <cjwatson> revision number?
[10:06] <ogra_> ah, 1459 re-enabled it
[10:06] <ogra_> and 1439
[10:06] <ogra_> " generally stop building preinstalled images from quantal on (only ac100 ones will stay that way) and switch kubuntu to live arm images as well"
[10:06] <cjwatson> it would have been less confusing if that had removed the lines from the crontab as well
[10:07] <cjwatson> (and 1459 would presumably have had to put them back, but still)
[10:07] <ogra_> hmm, i'm sure i removed them
[10:07] <ogra_> might have been during a milestone while the crontab was manually edited and i didnt commit it
[10:08] <ogra_> or some such
[10:08] <ogra_> in any case unless we want to roll daily precise arm iamges they should be dropped
[10:08] <cjwatson> that shouldn't be a problem unless you're editing in place on nusakan, which you mustn't :)
[10:09] <ogra_> (to free up livefs builder time)
[10:09] <cjwatson> feel free to amend, anyhoe
[10:09] <cjwatson> *anyhow
[10:09] <ogra_> yep
[11:34] <xnox> During a package built buildd got "Segmentation fault"
[11:34] <xnox> Can it be investigated or retried?
[11:35] <xnox> https://launchpad.net/ubuntu/+source/sphinx/1.1.3+dfsg-4ubuntu3
[11:35] <seb128> xnox, retried, sure
[11:35] <xnox> not reproducible locally in up-to-date sbuilds (i386,amd64) on amd64 host
[11:35] <seb128> done
[11:35] <xnox> seb128: ok thanks. Hope it's not gonna seg fault again =)
[11:35] <seb128> xnox, I don't think you can get debug infos, out of getting lamont or a buildd admin to manual run the build with a gdb for you
[11:36] <xnox> seb128: ok.
[11:40] <mitya57> xnox: successfully built on roseapple :)
[11:40] <mitya57> seb128: thanks
[11:44] <cjwatson> slangasek: ^- if you'd care to look that over, that'll make it easier to prepare an efilinux-signed package
[11:44] <lamont> seb128: I can pull syslog data, which sometimes has tombstones, but otherwise it's just a pain.  I see that the build in question succeeded
[11:44] <seb128> lamont, it did
[11:45] <seb128> lamont, but anyway it was xnox's asking, not me, I'm fine with the retry working ;-)
[11:48] <lamont> yeah
[12:30] <cjwatson> Come back livecd-rootfs, all is forgiven
[12:31] <cjwatson> I've just uploaded a giant live-build merge with a huge stack of consequential changes to livecd-rootfs and ubuntu-defaults-builder, because live-build is allergic to providing stable interfaces
[12:31] <cjwatson> I hope I got it all right, but if you notice any live image building weirdness, please let me know
[13:25] <stgraber> slangasek: right, in my case I didn't get the compile errors, just the defoma crash
[13:25] <stgraber> (rmdir failure in the defoma cleanup code of fontconfig-config)
[14:18] <skaet> stgraber, re: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1039828,   if we can get someone to validate it (and the teams affected can retest), would like to get it included in the alternates, since LTS to LTS will be common case.
[14:18] <ubot2`> Ubuntu bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix committed]
[14:20] <skaet> stgraber,  can we get the reporter to retest or find someone else to validate?
[14:23] <jibel> skaet, I've a very poor connection to the world today and missed the context. What do you need to validate ?
[14:24] <skaet> jibel,  if you could validate https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1039828,  it would be appreciated.  its in -proposed
[14:24] <ubot2`> Ubuntu bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix committed]
[14:24] <jibel> skaet, ok I can do it
[14:24] <skaet> Thanks jibel.  :)
[14:24] <jibel> yw :)
[14:24] <stgraber> skaet: I'll do it
[14:25] <stgraber> or rather, already in the middle of testing it ;)
[14:28] <skaet> stgraber,  thanks!  :)   I'd like to respin the alternates for ubuntu,  and any flavor that wants their alternates respun, as soon as we know its safe, so we can get the testing done.
[14:30] <jibel_> skaet, upgrade running
[14:30] <skaet> thanks jibel_
[14:31] <skaet> Riddell, ScottK - do you want Kubuntu's alternate's respun to pick up this fix ^
[14:32] <Riddell> hmm
[14:32] <stgraber> skaet,Riddell: to be clear, that bug will only show up on machines that have fontconfig-config + have an extra file in /var/lib/defoma/fontconfig.d/ and run an lts-to-lts upgrade WITHOUT internet connectivity
[14:32] <Riddell> yeah was about to ask that
[14:33] <stgraber> though, apparently at least mythbuntu and kubuntu 10.04 have an extra file in /var/lib/defoma/fontconfig.d/, so anyone using the media to upgrade without internet connectivity will hit that bug
[14:33] <Riddell> my feeling is that's not many people
[14:33] <Riddell> on the other hand I don't mind doing a bit more testing
[14:33] <stgraber> skaet: fix confirmed
[14:33] <Riddell> skaet: yes go for it, wouldn't want us to have a bug that others don't :)
[14:34] <skaet> stgraber,  ok,  will wait for jibel_'s results and then get it copied over, and trigger the respin.
[14:35]  * skaet notes that mythbuntu hasn't had any testing yet, so adding it to the respin target too.
[14:38] <stgraber> skaet: there's nothing to respin for mythbuntu, they don't have an alternate image
[14:38] <skaet> stgraber,  yes, but thought they were affected by this bug.
[14:38] <skaet> ?
[14:39] <stgraber> skaet: yeah, they're affected by the bug but they won't need a respin
[14:39] <stgraber> skaet: once the fix lands in -updates they'll be good
[14:39] <skaet> stgraber, ok.  thanks.
[14:59] <slangasek> cjwatson: accepted
[15:08] <jibel> skaet, stgraber upgrade is ok with fontconfig 2.8.0-3ubuntu9.1
[15:08] <skaet> thanks jibel
[15:08] <skaet> :)
[15:09] <stgraber> ok, so we need it copied to updates
[15:10] <stgraber> can someone from the SRU team copy fontconfig from -proposed to -updates please?
[15:11] <cjwatson> Uh, can we get it built on powerpc first please
[15:11] <cjwatson> Otherwise it'll be hard to fix later
[15:11] <stgraber> oops, I missed that...
[15:12] <stgraber> should have rescored yesterday after it got accepted...
[15:12] <stgraber> rescored now
[15:12] <stgraber> not that it really made any difference...
[15:13] <cjwatson> I think it's next in the queue
[15:14] <stgraber> yeah, once libreoffice and gtk are done building ;)
[15:14] <skaet> gtk just started, libreoffice has been at it for 11 hours
[15:14] <skaet> so,  maybe see if we can kill gtk, and get this built?
[15:14] <stgraber> based on history, libreoffice should be done in 9 hours
[15:15] <skaet> ie.  gtk's on ross
[15:15] <stgraber> gtk typically takes a bit over an hour to build
[15:15] <cjwatson> gtk+3.0 just failed to build
[15:15] <cjwatson> So it's moot
[15:15] <cjwatson> fontconfig is building now
[15:16] <stgraber> yay for that FTBFS!
[15:16] <skaet> :)
[15:16] <skaet> yup seeing it on ross now too.
[15:16] <cjwatson> lamont: powerpc chroots could do with a refresh
[15:16] <cjwatson> lamont: https://launchpadlibrarian.net/113221890/buildlog_ubuntu-quantal-powerpc.gtk%2B3.0_3.5.12-0ubuntu3_FAILEDTOBUILD.txt.gz is a decent enough chunk of upgrades, and powerpc is backlogged
[15:23] <seb128> do we need all archs to be built to do a quantal-proposed to quantal copy?
[15:23] <seb128> speaking of gtk, the proposed version fixes an annoying segfault and I would like to see the fix reaching quantal without being blocked on powerpc to catch up
[15:25] <Laney> yes
[15:26] <Laney> oh, it failed to build already
[15:26] <Laney> so it could be retried in the release pocket?
[15:26] <Laney> once the world has caught up
[15:28] <infinity> cjwatson: I'll refresh the chroots in a bit, I was waiting for gcc-4.7 to be in sync across arches, but with the DC move, that's been a lost cause.
[15:28] <infinity> lamont: ^-- Don't worry about the chroots, I've got it.
[15:28] <cjwatson> Laney: are you certain (e.g. from experience) that that's possible?
[15:29] <cjwatson> I haven't got my head around the relevant bits of the copy code enough to be certain of that
[15:29] <seb128> can I try? ;-)
[15:29] <Laney> no, I'm guessing
[15:29] <cjwatson> seb128: If you get it wrong then you need to reupload to get the world back in sync again
[15:29] <cjwatson> I really can't say I recommend it
[15:29] <seb128> I'm fine with that but I don't know if others are
[15:30] <infinity> seb128: I'd rather we just unsnagged PPC and got GTK built in proposed.
[15:30] <seb128> I don't want to random segfault GTK users in quantal for another day because ppc is not able to keep up
[15:30] <cjwatson> powerpc's trouble has mostly been because it kept having very long builds aborted due to a Launchpad bug
[15:30] <infinity> seb128: Yada yada, when it's automated, blah blah, won't let you do things with outdates/ftbfs, etc.
[15:30] <cjwatson> It'd be more or less caught up if not for that
[15:31] <infinity> It would have caught up on Saturday if it weren't for that.
[15:31] <seb128> cjwatson, does gtk qualify for running in that launchpad bug? and is the bug fixed?
[15:31] <seb128> like is gtk likely going to make it today?
[15:31] <seb128> infinity, yeah, that day I might just reupload gtk with ppc dropped from the supported archs in the control :p
[15:31] <infinity> seb128: I'll try to babysit gtk to completion today.
[15:32] <infinity> seb128: Also, uhm.  No?
[15:32] <cjwatson> seb128: The bug in question has been worked around procedurally
[15:32] <seb128> it's ridiculous to keep a buggy gtk for i386 amd64 and armel users blocked on ppc
[15:32] <cjwatson> As in we've told IS not to reload the firewall without stopping buildd-manager
[15:32] <seb128> ok
[15:32] <infinity> cjwatson: Which may or may not end up well-communicated, but I'm hoping.
[15:33] <seb128> infinity, but I guess at this point I should join others to advocate we stop supporting ppc
[15:33] <cjwatson> So I would be fairly surprised if gtk didn't make it today
[15:33] <seb128> that's a discussion for another time though
[15:33] <seb128> cjwatson, infinity: thanks
[15:33] <cjwatson> Gosh, it's not as if we have a partner actively trying to support ppc ...
[15:33] <Laney> https://launchpad.net/ubuntu/+source/fontconfig/2.10.1-0ubuntu3/+build/3735651 score this bad boy up
[15:33] <cjwatson> But I guess Canonical hates its partners or something
[15:34] <cjwatson> Laney: done
[15:34] <Laney> should be it from what I can see
[15:34] <infinity> seb128: We're buying more PPC hardware (plus, this entire backlog was DC move and LP bug, not the arch itself), so if we could keep the sky is falling hyperbole to a minimum.
[15:34] <seb128> cjwatson, well, it's a tradeoff and it depends of who we target I think, but if having to support ppc reduces our velocity to get desktop fixes out on main desktop arches it has a cost
[15:34] <cjwatson> seb128: if this kind of thing annoys you, I recommend you help out with ensuring that Launchpad can handle arch desync
[15:35] <cjwatson> Rather than just complaining about it
[15:35] <infinity> seb128: You could have made the same arguments about armel/armhf a few hours ago before they mostly caught up.
[15:35] <cjwatson> That's much better than hating on $slow_arch_du_jour
[15:36] <seb128> powerpc is a recurrent problem and it's desktop's userbase is really limited, but yeah there is not only desktop in life I know ;-)
[15:36] <cjwatson> Laney: agreed
[15:36] <cjwatson> arm is a recurrent problem in this way too
[15:36] <seb128> infinity, well, I see the point of support arm desktops and that's something we have active interest in
[15:36] <cjwatson> we just pretend it isn't
[15:36] <seb128> it is a problem, but I can see the interest in it
[15:36] <cjwatson> so the right fix is to make the toolset handle it better
[15:36] <cjwatson> in an architecture-generic way
[15:36] <seb128> that's even better yes
[15:37] <infinity> seb128: Anyhow, if speed is the biggest concern, it's being handled.
[15:37] <infinity> seb128: PPC should be the fastest arch in the buildd pool again soon (like it was when we first started, so long ago).
[15:37] <seb128> infinity, blocking important fixes to reach users in a timelined fashion is the issue there
[15:37] <cjwatson> Let's drop amd64 once it's blocking powerpc fixes
[15:38] <seb128> so if it's solved, whatever way it's solved I'm happy
[15:38] <infinity> cjwatson: Sold.
[15:38] <seb128> lol
[15:39] <seb128> point taken, sorry for the perceived-non-contructive discussion ... and no, the issue is not only lag, it's the number-of-users-pondered-with-cost which is
[15:39] <infinity> seb128: Anyhow, I'll poke at scoring and unsnagging the gtk build-dep failure so it builds soonish.
[15:39] <seb128> but anyway, let's move on
[15:39] <seb128> infinity, thanks
[15:45] <Laney> fontconfig is built
[15:48] <skaet> SpamapS,  would you help with the copy over?
[15:49] <skaet> (of fontconfig-config from -proposed to -updates)
[15:52] <stgraber> it's not published in -proposed yet
[15:53] <infinity> I beg to differ.
[15:53] <infinity> Did you need it released?
[15:53] <cjwatson> rmadison agrees with stgraber ...
[15:53] <lamont> infinity: ta
[15:54]  * cjwatson checks LP
[15:54] <stgraber> IIRC copyPackages doesn't like copying non-published binaries
[15:54] <stgraber> libfontconfig1 | 2.8.0-3ubuntu9.1 | precise-proposed | amd64, armel, armhf, i386
[15:54] <infinity> rmadison lies. :P
[15:54] <stgraber> ^ no powerpc there
[15:54] <cjwatson> Ah, yes, published in LP
[15:54] <cjwatson> It's fine to copy
[15:54] <cjwatson> We don't need it on the mirrors to make copying sane
[15:54] <stgraber> ah right, that's a case where the published state on LP is actually what we want ;)
[15:54] <infinity> (copied)
[15:55] <stgraber> skaet: I'll start the respin once it's published in -updates
[15:56] <skaet> thanks stgraber
[15:56] <stgraber> skaet: so we have kubuntu and ubuntu that want it, do you know if xubuntu wants it too?
[15:57] <skaet> stgraber,  no haven't heard back on that one.
[15:57] <stgraber> knome: ^
[15:58] <skaet> astraljava, ^ ?  do you awnt a respin of the alternates?
[15:58] <skaet> want even
[16:06] <skaet> stgraber,  looks like bug 1036994 still isn't quite resolved.  probably needs to be reopened?
[16:06] <ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
[16:08] <stgraber> skaet: I'll do another test run here, for some reason (past experience?) I don't really trust the test results for the chinese builds
[16:08] <slangasek> cjwatson: efilinux accepted btw, if you hadn't already seen
[16:08] <skaet> stgraber, ok.   will forward you the rest of the results I've gotten.
[16:26] <balloons> skaet, I don't see the respin for fontconfgig in the pad?
[16:28] <skaet> balloons,  updated it now to move to right column header on the pad.   its bug 1039828
[16:28] <ubot2`> Launchpad bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix released] https://launchpad.net/bugs/1039828
[16:30] <balloons> skaet, ty :-)
[16:30] <balloons> you plan to pull the opportunity targets?
[16:43] <stgraber> skaet: for bug 1036994, I can indeed confirm that these now show up though they definitely didn't when I last tried (only thunderbird-locale-zh-cn did back then)
[16:43] <ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
[16:43] <stgraber> skaet: adding these would require an extra 40MB or so of CD space which we don't have
[16:43] <stgraber> so the best hope is to figure out why they're suddenly being needed
[16:45] <skaet> stgraber,  ok,  will start the thread off by email with the testers and folks pushing for it, and see if we can figure a path forward.
[16:55] <stgraber> skaet: that's the 12.04 => 12.04.1 delta for the chinese image: http://paste.ubuntu.com/1161119/
[16:55] <stgraber> reverting the package additions still gives me the same missing package list, so I'm starting to doubt that the 12.04 image was really any better than what we have currently
[16:57] <SpamapS> skaet: can I assume from the backscroll that fontconfig was taken care of?
[16:57] <stgraber> going for lunch now, will try a local respin of the image with the needed packages to see if squashfs does magic and makes 40MB worth of compressed debs fit into the 20MB or so of free space we have
[16:57] <stgraber> SpamapS: yep
[16:58] <skaet> SpamapS,  what stgraber said.  :)
[16:58] <skaet> enjoy lunch stgraber
[17:16] <jibel> skaet, stgraber what's ETA for new alternates ?
[17:16] <stgraber> jibel: 30min
[17:16] <jibel> stgraber, ok, back in 90min
[17:18] <stgraber> skaet: adding the packages would make the squashfs grow by 41.3MB
[17:30] <slangasek> stgraber: bug #1036994> perhaps language-selector is returning partial results for different kinds of missing packages, and only after we got thunderbird-locale-zh-cn added does the next batch show up?
[17:30] <ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
[17:30] <slangasek> stgraber: as for not having room, I'm not sure - are we committed to fitting the zh_CN image on a CD?
[17:30] <slangasek> (that's a question we should ask the folks who own the image)
[17:33] <stgraber> slangasek: could be... I can't reproduce that behaviour with check-language-support but maybe the UI behaves differently
[17:34] <slangasek> right
[17:34] <stgraber> slangasek: Kate started a discussion on whether to move past the 703MB limit as I don't see any other way to get these packages in and still get it fit on the media
[17:36] <slangasek> in any case, I see those packages listed in the language-selector data, and l-s hasn't changed, so it seems the bug is that they weren't shown before when they should have been
[17:36] <slangasek> stgraber: ah, perfect
[17:37] <slangasek> pff, 12.04.1 images need to happen so bug #853060 can get knocked off the top crashers report
[17:37] <ubot2`> Launchpad bug 853060 in ubuntuone-installer/trunk "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [Critical,Fix released] https://launchpad.net/bugs/853060
[17:38]  * slangasek hmms at lillypilly.  Busy machine.
[17:41] <infinity> slangasek: Yeah, we kinda hammer it.  It might be high time to ask for an ubuntu-archive.canonical.com (or something) that we can redirect people/~ubuntu-archive to and run our scripts in peace.
[17:41] <slangasek> infinity: not sure it's our hammering that's at issue here; there's a lot of other stuff running too
[17:42] <ogra_> it isnt by chance also cating as central IRC node ? :)
[17:42] <ogra_> *acting
[17:42] <slangasek> zul: hi, what's 'accepted-nominations.py'?  Seems to be wedging a bit on lillypilly
[17:42] <bjf> ogra_: *many* teams run cron jobs on it that beat on LP
[17:42] <infinity> slangasek: No, our hammering isn't the only hammering, but moving ours off would give others breathing room, and would make some sense, since the archive-related stuff probably shouldn't be on people anyway.
[17:43] <zul> is the server team sru tracking stuff
[17:43] <bjf> infinity: last i asked i was told there was a plan to improve that situation, that was a while ago
[17:43] <slangasek> zul: you have instances of it running since Aug 19 without completion
[17:43] <slangasek> zul: and using quite a lot of CPU time
[17:43] <zul> *sigh* no i wasnt...ill kill il
[17:43] <skaet> stgraber, based on the discussion with smagoun in email, he'd prefer it to go out oversized, and just document it as USB/DVD image.   thoughts?
[17:44] <ogra_> bjf, sorry i was trying to be funny and referring to that massive netsplit that occured when slangasek asked first :)
[17:45] <zul> slangasek: done...cron jobs have been disabled as well
[17:45] <slangasek> zul: ok, cheers :)
[17:45] <jibel> latest alternate seems to be broken. kernel version mismatch
[17:46] <slangasek> zul: I guess http://reports.qa.ubuntu.com/reports/ubuntu-server/sru-report.html is the authoritative location for this now, anyway?
[17:46] <zul> slangasek: i think so
[17:46] <jibel> and upgrade from CD failed
[17:46] <slangasek> zul: ok, cool
[17:46] <jibel> skaet, stgraber ^
[17:46] <zul> slangasek: you'll have to check with jamespage though since he is using that report
[17:47] <slangasek> jamespage: hi, can you confirm that you use http://reports.qa.ubuntu.com/reports/ubuntu-server/sru-report.html these days and not http://people.canonical.com/~chucks/SRUTracker/ ?  the latter was running amok on lillypilly, so has now been disabled
[17:47] <zul> but i didnt mention hes on vacation this week
[17:48] <slangasek> zul: ok, then he'll have scrollback :)
[17:49] <stgraber> skaet: hmm, ok... I don't really care about that image, so if they want it to become a DVD/USB image, I'm fine with it, I can push a new ubuntu-defaults-zh-cn to include the missing packages
[17:50] <stgraber> jibel: hmm, weird... let me do a few diffs quickly
[17:51] <stgraber> skaet, jibel: hmm, looks like we lost the previous alternate build...
[17:53] <skaet> urk... why?
[17:54] <slangasek> cleanup limit not removed for mastering?
[17:54] <stgraber> my guess is the cleanup script
[17:55] <jibel> stgraber, what do you need, I have 20120817.2 but not .3
[17:55] <slangasek> etc/purge-days doesn't look like it's been changed
[17:55] <stgraber> jibel: I have them locally, it's just that we don't have a fallback now... so we need it fixed for sure
[17:56] <balloons> ok, the alt images look to be up again.. i'm zsync'd
[17:56] <stgraber> infinity, slangasek: so, a diff shows that we're missing linux-image on the media, any idea what happened? (going to go grab the logs now)
[17:56] <slangasek> stgraber: which media, exactly?
[17:56] <infinity> stgraber: What he said.
[17:57] <slangasek> oh, n/m
[17:57] <slangasek> looking at precise/daily/20120822.2/precise-alternate-i386.list now
[17:57] <slangasek> sure enough, metapackages are there but not the kernel images
[17:57] <slangasek> infinity: ^^
[17:57] <infinity> It's not building from -proposed, is it?
[17:58] <knome> skaet, ok for me to respin alt
[17:58] <slangasek> that's supposed to have been disabled (rev 1484)
[17:58] <skaet> knome,  ok.
[17:58] <slangasek> ah, that's only the cronjob anyway
[17:58] <njin> kirkland, are you a devel of testdrive ?
[17:59] <slangasek> stgraber: it does look like precise-proposed is mentioned in the build log.  How was this kicked off?
[17:59] <jibel> balloons, skaet I disabled alternate for Ubuntu and Kubuntu on the tracker
[17:59] <stgraber> knome: ok, adding you to the list once we've figured out what's going on
[17:59] <balloons> ty jibel
[18:00] <skaet> thanks jibel
[18:00] <stgraber> slangasek: DIST=precise for-project ubuntu cron.daily
[18:00] <infinity> stgraber: Something's definitely using proposed, cause it's picking up a kernel that's only in proposed...
[18:00] <infinity> stgraber: Then, of course, that goes splat when it doesn't match either d-i or the seeds.
[18:00] <knome> stgraber, ta
[18:01] <balloons> skaet, jibel did we pull/we will pull all the opportunity target's on the pad?
[18:02] <skaet> balloons,  no not necessarily in the images
[18:02] <balloons> k
[18:02] <skaet> they will all be available in the 0 day SRU updates though.
[18:02] <balloons> so my update to the noticeboard should be correct :-)\
[18:03] <infinity> stgraber: You don't have PROPOSED=1 in your environment or something?
[18:03] <infinity> (Or whoever did the build...)
[18:03] <stgraber> infinity: hmm, proposed is definitely disabled in CONF.sh... and I can't spot anything that changed since Monday...
[18:03] <stgraber> infinity: nope, already checked ;)
[18:05] <slangasek> stgraber: are you sure this was your build? :)
[18:05] <slangasek> maybe check whether it's reproducible?
[18:05] <stgraber> kicking a new one to check...
[18:06] <stgraber> running (from a clean shell, just in case...)
[18:08] <slangasek> stgraber: see bin/run-germinate (and history thereof)
[18:09] <slangasek> it's not that you weren't pulling from proposed before and are now; it's that we've been consistently pulling from proposed for germinate, and this is the first time since we stopped /building/ from proposed that this gives a different result vs. -updates
[18:09] <infinity> Oh, d'oh.
[18:09] <infinity> That needs a PROPOSED guard instead of a DIST= guard, and you should be set.
[18:10] <stgraber> fixing...
[18:11] <infinity> Well, assuming PROPOSED actually gets exported higher up.
[18:11] <infinity> If not, that would end up being a no-op and fail with 12.04.2
[18:12] <stgraber> code updated, waiting for the current build to finish (and produce an equally buggy image), then will respin ubuntu, kubuntu and xubuntu with the fix
[18:14] <infinity> Yeah, that probably won't work for 12.04.2, I bet.  I suspect PROPOSED doesn't exist in that part of the twisty shell stack at all.
[18:14] <infinity> But that could be fixed.
[18:14] <infinity> In fact, if it was fixed, we could ditch the need to edit CONF.sh too.
[18:15] <infinity> But, I'd rather not experiment right now, just get your fixed images out, and we can play after 12.04.1 ships. :P
[18:16]  * skaet nods
[18:16] <stgraber> yeah, I think it'd make sense to always use PROPOSED=1 and skip CONF.sh completely but that can be done for .2, and once that's done, my change to run-germinate should magically work
[18:17] <infinity> stgraber: Well, it'll magically work if higher-level scripts (build-image-set, or similar) export PROPOSED.
[18:17] <infinity> stgraber: Which would fix your run-germinate fix, and would also allow CONF.sh to not have to do the same.
[18:18] <infinity> Anyhow, as much as it all makes sense in my head, I won't touch it while you're trying to release something. :P
[18:18] <stgraber> skaet: I'll upload a new ubuntu-defaults-zh-cn now with the missing packages, that'll need to get into -proposed, be tested, then moved to -updates before we can respin the chinese images
[18:18] <skaet> stgraber,  thanks.
[18:20] <stgraber>   * depends.txt: Dropping ttf-wqy-zenhei was just a tad too little to fix
[18:20] <stgraber>     oversizedness. Put it back and drop ibus-sunpinyin instead, so that ibus
[18:20] <stgraber>     will use ibus-pinyin with db-android, as in a normal install. Zhengpeng
[18:20] <stgraber>     Hou says most people use the googlepinyin module anyway.
[18:20] <stgraber> skaet: ^ that's from the ubuntu-defaults-zh-cn changelog, so apparently dropping ibus-sunpinyin was done on purpose by Martin to fight oversizedness
[18:20] <infinity> stgraber: If the PROPOSED checks are actually that convoluted [ "${PROPOSED:-0}" != "0" ] construct everywhere too (which we can check with a fine-toothed grep), then we can stop with the somewhat error-prone adding and removing of PROPOSED in cronjobs, and just have stable releases have PROPOSED=0 in crontab, and flip to 1 when needed.  Much less change for human oopsification, I suspect.
[18:21] <infinity> s/change/chance/
[18:22] <stgraber> infinity: only place that's not using that kind of check (using [ "$PROPOSED" = "1" ] instead) is debian-cd/Makefile, the rest looks pretty consistent
[18:23] <infinity> stgraber: Well, PROPOSED=1 would also match my plan above.
[18:23] <infinity> stgraber: It's only things that check for it being set/empty that would break.
[18:24] <stgraber> infinity: my grep against the cdimage, cdimage-deployment and debian-cd branches suggest that we never do [ -n "$PROPOSED" ], so your plan should be fine
[18:25] <stgraber> skaet: uploaded ubuntu-defaults-zh-cn to -proposed
[18:26] <stgraber> ok, rebuilding all alternates now
[18:31]  * stgraber -> upgrading memory in laptop, be back in 10min (hopefully)
[18:31]  * skaet hopes so too...
[18:36]  * stgraber is back with 16GB of RAM!
[18:37] <stgraber> slangasek: so in case you were wondering, contrary to what Lenovo and the DMI pretends, an x201 (x201s in my case) seems perfectly happy with 16GB of RAM (instead of the documented maximum of 8GB)
[18:38] <skaet> :)
[18:41] <stgraber> jibel: can you test that new batch?
[18:41] <stgraber> we seem to have a kernel this time around
[18:47] <slangasek> stgraber: noted ;)
[18:48] <skaet> :)
[18:48] <slangasek> I have my hands full at the moment upgrading my work area to use digital video only
[18:48] <slangasek> just bought an x200 ultrabase, to discover that it's DP instead of the HDMI I expected... now I have an adapter on order :P
[18:50] <stgraber> haha, yeah, I have the ultrabase and the DP => DVI adapter, though I'll be ordering a new laptop (x230) this week and so I'll need yet another adapter as that one is coming with mini-DP (though directly on the laptop instead of requiring the docking station which is a nice improvement)...
[18:50] <stgraber> SpamapS, slangasek, infinity: can one of you review ubuntu-defaults-zh-cn in Unapproved?
[18:51] <infinity> stgraber: I'll poke it.
[18:51]  * SpamapS was too slow
[18:52] <infinity> stgraber: And we're sure everyone's cool with it being oversized?
[18:54]  * infinity assumes so from scrollback.
[18:55] <infinity> stgraber: Did you want to do any testing on that once its built, or just want to wing it straight to updates?
[18:56] <infinity> stgraber: (If I time it just right, I can skip a publisher cycle... Sometimes)
[18:56] <skaet> infinity,  yes, we're ok with the chinese image being oversized.   Prefered option from OEM.
[18:57] <stgraber> infinity: only check that should be done is ensuring the extra 4 binaries found their way into the Depends field
[18:58] <infinity> stgraber: https://launchpad.net/ubuntu/+source/ubuntu-defaults-zh-cn/0.8.4/+build/3737400/+files/ubuntu-defaults-zh-cn_0.8.4_all.deb
[18:58] <infinity> stgraber: Go forth and dpkg-deb -I
[18:59] <stgraber> infinity: looks good
[19:05] <infinity> stgraber: Oh, nevermind, can't cheat the publisher, that trick only works if the source was already published.
[19:05] <infinity> stgraber: (since, for curious reasons, binaries get published during the short "security-only" run, so there's a window where one can then pocket-copy the whole mess before the full run happens)
[19:07] <infinity> stgraber: Anyhow, copied now, will make it in the next run. :/
[19:08] <balloons> ok -- we feeling good on these now :-)
[19:09] <slangasek> stgraber: if ibus-sunpinyin was removed deliberately, why are you re-adding it, rather than fixing language-support?
[19:14] <stgraber> slangasek: well, it was removed deliberately to save space but it's apparently still something most users want and that's what all 12.04 users with connectivity have, so just adding it back to the media (after checking that they're fine with it being oversized) seemed like the less risky change at this point
[19:16] <slangasek> stgraber: where do you see that it's something most users want?
[19:16] <slangasek> pitti's changelog said the opposite
[19:19] <stgraber> slangasek: my understanding of that comment is that in an ideal world we'd use ibus-googlepinyin, which we can't as it's not in main. That's also why language-selector still installs ibus-sunpinyin in 12.04 instead of googlepinyin (on quantal)
[19:22]  * slangasek rereads
[19:23] <slangasek> stgraber: well, "we can't use it because it's not in main" doesn't make sense; if it's the right one to use, it can be moved to main (I see it's still in universe in quantal)
[19:23] <slangasek> "ibus-pinyin with db-android, as in a normal install" - what's a "normal install" in this case?
[19:24] <stgraber> slangasek: oh, I assumed that change in quantal based on the "# replace with ibus-googlepinyin in 12.10" next to it in depends.txt... guess nobody did that change yet
[19:24] <balloons> any status on this bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1040002
[19:24] <ubot2`> Ubuntu bug 1040002 in linux "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete]
[19:24] <slangasek> ah, "a normal install" == that's the method ubuntu-desktop depends on
[19:25] <slangasek> seems like we ought to list alternatives there, so that the Qin CDs don't have to have *both* included
[19:25] <stgraber> slangasek: I only have a very limited understanding of the chinese input methods, so we really should talk to someone who has a clue what kind of change we're talking about. I really doubt we should be changing input method in a point release.
[19:25] <njin> hallo, I've installed Lucid to test the upgrade to precise, but U M won't propose the upgrade, is this expected ?
[19:26] <njin> iis the upgrade locked ?
[19:27] <slangasek> stgraber: I agree we shouldn't change it, I just didn't understand that's what pitti's changelog meant the first time around
[19:27] <slangasek> njin: this is expected, until after 12.04.1 releases and we turn on upgrades for LTS users
[19:28] <njin> ok slangasek, usefull
[19:28] <stgraber> slangasek: I'm really wondering how many users will be getting a well working upgrade path to 10.04.4, looking at bug 1040002 ...
[19:28] <ubot2`> Launchpad bug 1040002 in update-manager "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete] https://launchpad.net/bugs/1040002
[19:29] <slangasek> balloons: bug #1040002> nothing should have changed in precise-updates in the past 24 hours to cause this.  Are you sure this isn't some jenkins breakage?
[19:29] <stgraber> that one seems to have quite a lot of extra packages installed (wine, opencv, ... looking just at the end of apt.log)
[19:29] <slangasek> stgraber: it's the lucid universe upgrade test, so of course it has extra packages installed?
[19:30] <stgraber> isn't it the universe upgrade test that uses a random subset of universe?
[19:30] <slangasek> not random
[19:34] <jibel> universe includes the maximum number of packages from all the repositories with a desktop file until dpkg explodes
[19:34] <stgraber> right, I just refreshed my memory by reading install_universe again :)
[19:35] <stgraber> jibel: do you have a way of checking whether the list changed between the last succesful upgrade and the first failed one?
[19:36] <jibel> stgraber, the list of packages installed ?
[19:37] <stgraber> jibel: yep
[19:37] <jibel> stgraber, the source list doesn't change
[19:37] <slangasek> the apt-clone_system_state?
[19:37] <stgraber> ah, indeed, apt-clone_system_state should contain that
[19:37] <slangasek> however, AFAICS there've been no publications of anything to precise-updates in the past 36h that would have introduced new breaks
[19:39] <slangasek> stgraber: the working one shows the release-upgrader apt, the broken one does not
[19:39] <slangasek> (in dpkg-status - first diff I see)
[19:41] <slangasek> though maybe that's because the failure happened so early it couldn't be pulled in
[19:41] <slangasek> jibel: is the lucid-universe upgrade job for today in progress?
[19:44] <jibel> slangasek, it is in the queue and will start after main in approximately 4h45min
[19:47] <stgraber> skaet: I'm going to turn off purge-old-images completely (to make sure we don't loose any more build), then rebuild the chinese image
[19:47] <skaet> thanks stgraber - wise
[19:49] <skaet> stgraber,   new image will go to : http://china-images.ubuntu.com/precise/daily-live/current - right?
[19:49] <stgraber> yep
[19:53] <slangasek> micahg: hi, can I ask why you marked bug #997359 as rls-q-incoming?  AFAICS this is an annoyance, but hard to fix and low-impact for users
[19:53] <ubot2`> Launchpad bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [High,Confirmed] https://launchpad.net/bugs/997359
[20:23] <jibel> stgraber, where are the logs for ltsp-client-builder ?
[20:27] <stgraber> jibel: I believe one is directly in /var/log and the rest should be in installer/syslog
[20:29] <jibel> stgraber, this is the end of syslog http://paste.ubuntu.com/1161542/
[20:29] <jibel> there is a file /tmp/ltsperror.txt which is 0byte
[20:30] <stgraber> jibel: oh, good, that's just quantal, was scared for a minute ;)
[20:30] <stgraber> I was sort of expecting it to blow up on quantal after the big merge from Debian. I have an upload scheduled for tomorrow, will fix that in it.
[20:31] <jibel> stgraber, oh phew! I scared myself
[20:31] <jibel> stgraber, retrying with precise :)
[20:34] <slangasek> micahg: same question on bug #769601... not sure what the impact is here
[20:34] <ubot2`> Launchpad bug 769601 in gcc "libstdc++, debug mode: resizing a vector doesn't update capacity" [Medium,Fix released] https://launchpad.net/bugs/769601
[20:34] <slangasek> (marked 'low', and nobody's said it's breaking any of the handful of packages that depend on g++-4.4)
[20:36] <skaet> stgraber, have the chinese image rebuilds been triggered yet?
[20:37] <stgraber> skaet: no
[20:37] <stgraber> skaet: but they will in a minute
[20:37] <skaet> :)
[20:37]  * skaet was just about to ask if you wanted me to.
[20:38] <stgraber> running
[20:38] <skaet> thanks
[20:56] <stgraber> skaet: chinese images built
[20:56] <skaet> thanks stgraber
[21:14] <skaet> balloons, stgraber - I updated the notice board, since alternates have built,  and have updated pad
[21:14] <balloons> thanks skaet .. chasing a rescue mode bug
[21:18] <skaet> utlemming,  how are the cloud images looking for testing results?
[21:18] <skaet> can they get added to the tracker?
[21:18] <utlemming> beautiful
[21:18]  * skaet likes hearing testing is beautiful.... ;)
[21:18] <skaet> or rather the tested images are beautiful.
[21:19] <utlemming> all tests passed, except for two, which were caused by bzr failures
[21:19] <utlemming> stgraber: can you add these to the tracker? http://cloud-images.ubuntu.com/precise/20120821/
[21:21] <catbus1> skaet: I can still see the incomplete language support with the latest chinese image. I will get the list of missing packages and comment on the bug
[21:28] <stgraber> utlemming: sure
[21:33] <skaet> thanks catbus1,  stgraber, looks like still some ones to add.
[21:34] <catbus1> skaet: stgraber: check-language-support returns nothing though, which means nothing is missing.
[21:37] <skaet> catbus1 - could it be that the translations aren't complete for all the strings?  and that's what's being seen?
[21:39] <cjwatson> no, missing translations won't trigger that
[21:39] <cjwatson> that's a package-level check
[21:42] <catbus1> skaet: ^^^
[21:44] <catbus1> Assuming check-language-support does it right, it seems to me it's a false alarm, there is nothing missing. The missing language support window shouldn't appear.
[21:45] <skaet> catbus1, cjwatson - ok, thanks.
[21:46] <cjwatson> The odds are that it's complaining about something like missing translated help files for some application, or missing thesaurus files, or something relatively tangential like that.
[21:47] <cjwatson> But I can't easily check right now.
[21:47] <skaet> ok,  something wrong but not that serious.  gotcha.
[21:47] <stgraber> skaet: will grab the new image to figure out what's going on
[21:48] <skaet> thanks stgraber
[21:50] <cjwatson> Basically check-language-support has various packages entered in a matrix of locales / categories (fonts, input methods, etc.) / (for some categories) installed applications, and will complain about packages missing from that.
[21:52] <cjwatson> This was an improvement over the prior system where we had a pile of language-support-* metapackages, which never really worked right because different flavours had different applications which might need to be enhanced with support packages.
[21:53] <cjwatson> So we ended up with c-l-s instead, in, er, whichever release followed the UDS in Barcelona I think
[21:54] <cjwatson> (Does anyone else find that?  I think of a feature and remember what the hotel looked like where we designed it ...)
[21:54] <stgraber> karmic I believe
[21:56] <stgraber> yeah, I get that sometimes, then have to spend a few minutes figuring out the release based on the continent and LTS/non-LTS (won't work once we have a LTS release UDS in Europe...) ;)
[21:57] <ajmitch> or breaking the cycle & having it in Australia again? :)
[21:58] <cjwatson> Barcelona was memorably visually distinctive with that crazy giant 20-storey atrium or whatever it was in the sleeping accommodation
[22:18] <stgraber> skaet, cjwatson, catbus1: based on check-language-support, it's prompting because of lack of english support packages
[22:19] <skaet> lol
[22:20] <stgraber> specifically: hunspell-en-ca hyphen-en-us libreoffice-help-en-gb libreoffice-help-en-us libreoffice-l10n-en-gb libreoffice-l10n-en-za myspell-en-au myspell-en-gb myspell-en-za mythes-en-au mythes-en-us openoffice.org-hyphenation thunderbird-locale-en thunerbird-locale-en-gn thunderbird-locale-en-us and wbritish
[22:20] <skaet> sorry,  that seems quite ironic.
[22:20] <skaet> given we're oversize already - does it make more sense to add,  or just to release note it?
[22:21] <cjwatson> I certainly don't think it makes sense to add all those.
[22:21] <stgraber> well, I certainly won't ba adding these to ubuntu-defaults-zh-cn, that just wouldn't make sense ;)
[22:21] <skaet> :)
[22:21] <skaet> fair 'nuf
[22:21] <stgraber> cjwatson: what's the reason why we always have language-pack-en installed on all systems even non-english ones?
[22:22] <stgraber> (besides making me happy as I can just LANG=en_US.UTF-8 and get the system into a locale I understand)
[22:22] <stgraber> oh, actually, we now have C.UTF-8 don't we? so I don't even need them for that anymore :)
[22:23] <cjwatson> It was an agreement dating back to 2004
[22:23] <cjwatson> I think mdz ruled on it
[22:23] <stgraber> skaet: confirmed that flushing the English langpacks from the system makes check-language-support happy again
[22:23] <cjwatson> I'd have to do some archaeology to remember the reasoning
[22:24] <cjwatson> en_US.UTF-8 might have been a part of it, although I'm not sure it was all
[22:24] <stgraber> cjwatson: ok, might be worth re-checking, especially now that we have C.UTF-8, stuff hardcoding en_XX.UTF-8 should just be fixed
[22:25] <stgraber> skaet: so I suppose they can just release note that the DVD image comes with full chinese support and partial english support and that users will be prompted to install the remaining set of english packages post-install. They can choose not to install them or even remove the base english packages if they want.
[22:28] <skaet> stgraber,  I can live with that.
[22:29] <Daviey> skaet: I assume arm images are all in order?
[22:30] <skaet> Daviey,  haven't seen results from netboot armhf omap and omap4 yet.
[22:31] <skaet> slangasek, infinity - either of you able to help with those?
[22:34] <catbus1> stgraber: can you comment on the bug so it's clear on the root cause? 1036994
[22:34] <slangasek> infinity: my panda is busy testing llvmpipe.  can you look at netboot?
[22:59] <stgraber> catbus1: done
[23:00] <stgraber> skaet: marked Edubuntu as good to go
[23:00] <stgraber> even the unsupported 10.04-to-12.04 upgrade worked for it ;)
[23:10] <skaet> Thanks stgraber.  :)
[23:18] <skaet> slangasek,  we're also still missing some of the netboot i386 results.
[23:21] <phillw> skaet: I'm running low on testing.. what do you need for netboot i386 results.?
[23:22] <phillw> skaet: is a VM okay?
[23:22] <skaet> phillw,  installing Xubuntu and Kubuntu needed.  http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21346/testcases
[23:23] <skaet> slangasek, ^  I think it should be,  but want to cross check.
[23:23] <skaet> (installing on VM)
[23:24] <phillw> skaet: I've had a nightmare with 10.04.4 -- 12.04. If there is an up to date set of instructions I can run it via an VM if that is acceptable?
[23:26] <skaet> phillw, good question.    jibel's offline now, and he did the other netboot test cases.
[23:27] <skaet> balloons,  you still around?    any  insight?
[23:27] <phillw> skaet: sorry, cancel me out... it is expected 3 hours for me to recover mt music files from the 1st area of my back up area.
[23:28] <skaet> phillw,  ok.   Thanks.
[23:29] <phillw> skaet: the VM on the SII server was made available, I can do more than that :(
[23:29] <psivaa> skaet, i was able to do the upgrade using you still around?    any  insight?
 skaet: sorry, cancel me out... it is ex
[23:29] <phillw> *I cannot*
[23:29] <psivaa> sorry https://help.ubuntu.com/community/PreciseUpgrades
[23:30] <skaet> psivaa,  not parsing what you've typed I'm afraid.
[23:30] <phillw> skaet: too many tasks asked for, we simply do not have enough people to carry them all out.
[23:30] <skaet> were you able to do the netboot install.
[23:31] <skaet> psivaa, ^
[23:31] <psivaa> skaet, sorry it was a bad copy paste. i thought phillw was asking for links with the instruction for lucid- prcise upgrade
[23:32] <skaet> psivaa,  he was asking if it was ok to do the netboot tests under a VM, and if there were good instructions for doing so.
[23:33] <phillw> psivaa: no, I tried the the kubuntu 10.04.04 --> 12.04 in VM just to tick the box... it was an epic fail.
[23:33] <psivaa> skaet, phillw ohh sorry the instructions on the link above for hw i suppose
[23:34] <phillw> psivaa: do not feel dis-heartened, the instructions were also out dated.
[23:37] <phillw> psivaa: on QA, we have, IMHO, gone a bridge too far.  The lessons learned are important. I do ask that you be patient as we sort things out.
[23:37] <psivaa> phillw, ok thanks :)
[23:38] <psivaa> phillw, the upgrade from 10.04 --> 12.04.01 was ok on hw for me though
[23:39] <phillw> psivaa: great news,
[23:40] <psivaa> phillw, going to go off now, enjoy the rest :)
[23:40] <skaet> good night psivaa,  and thanks. :)
[23:40]  * skaet --> dinner


[01:37] <ScottL> i added a patch to the ardour mute bug # 581786
[02:36] <ScottL> persia: i received an email from luis today with a +1
[02:37] <persia> Cool.  Sounds like you've collected the whole set, and win the prize :)
[02:37] <ScottL> lol, yeah, a whole set of responsibilities ;)
[02:40] <ScottL> however, i was also thinking of talking to #ubuntu-desktop tonight about the network-admin bug
[02:40] <ScottL> if there anything in particular i should point out to them persia?
[04:43] <ScottL> persia, TheMuso, jussi, i've almost finished my ubuntu membership application and I was wondering if you would be kind enough to write a testimonial for me
[04:43] <ScottL> i should be done with it either tomorrow or the following night :)
[04:44] <ScottL> lol, i see TheMuso is popular, he just got asked for an endorsement in -desktop as well
[06:19] <jussi> ScottL: well itd actually help if you linked us to your wiki page....
[09:48] <abogani> kernels don't built in PPA! Sgrunt!
[10:14] <abogani> persia: ^ :-(((((
[10:32] <abogani> persia, ScottL : https://lists.ubuntu.com/archives/kernel-team/2010-May/010707.html
[11:36] <persia> What!  Why don't kernels build in a PPA?  I thought apw did this regularly.
[11:54] <abogani> persia: I received this error:
[11:55] <abogani> http://paste.ubuntu.com/439296/
[11:58] <abogani> persia: Moreover I don't think than apw really do it.
[11:58] <abogani> They release packages at http://kernel.ubuntu.com/~kernel-ppa/mainline/ (which it isn't launchpad).
[11:58] <abogani> I suppose that "ppa" should be removed for avoid confusion...
[11:59] <abogani> Perhaps kernel-ppa is the user who used for build kernels on Zinc (that is kernel.ubuntu.com)...
[12:04] <persia> abogani: He really does it: https://launchpad.net/~apw
[12:04] <persia> Hrm.    Try uploading the regular kernel, and see if that makes a difference.
[12:04] <abogani> persia: Ok. Evidently their are some type of super powers.
[12:04] <persia> I have a feeling that either there's a special hack in launchpad, or something else is wonky.
[12:05] <persia> These are extendable :)
[12:05] <persia> Just need to track down the cause, and then the folks in #launchpad can sort it.
[12:05] <abogani> persia: I have already done it: If I remove -pae images it build.
[12:06] <persia> Interesting.
[12:06] <persia> So it just takes too long?
[12:06] <abogani> persia: More than 10 hours.
[12:06] <abogani> On LP.
[12:07] <abogani> Obviously it build perfectly in two hours on my machine with pbuilder (variant=buildd)
[12:07] <persia> Yeah, and it gets killed after 150 minutes.
[12:07] <persia> Ask in #launchpad if there's something special for kernel builds that allows them to take longer.
[12:07] <persia> if not, we can add a script that just prints something every 30 minutes or so to prevent the timeout.
[12:10] <abogani> persia: Asked.
[12:11] <abogani> persia: You mean an infinite loop with a sleep and an echo  inside?
[12:12] <persia> I'd probably not use an infinite loop.  Make it exit after say 36 iterations (gives you 18 hours).
[12:15] <abogani> Sound really nasty trick
[12:18] <persia> It's definitely in the deep workaround category :)  Usually better to figure out why the build didn't print anything for 18 hours.
[12:18] <persia> Most of the time there's some buildsystem flag that makes it more verbose, etc.
[12:21] <abogani> DH_VERBOSE?
[12:21] <abogani> persia: Full log at http://launchpadlibrarian.net/49048008/buildlog_ubuntu-lucid-i386.linux-lowlatency_2.6.32-22.38_FAILEDTOBUILD.txt.gz
[12:22] <persia> DH_VERBOSE only helps for the debhelper bits.
[12:23] <persia> You'd need something that made kernel-wedge copy-modules more verbose at the point where it appaers to hang for 150 minutes.
[12:26] <abogani> It could be very easy: place an "set -x" at top of the copy-modules should be work (and also add that file to the package changing also rules to point on this).
[12:27] <persia> that's a lot cleaner than the while/sleep hack.
[12:27] <persia> And probably more informative as to the cause of the underlying error.
[12:27] <persia> But I'd recommend checking to see if wgrant has any other ideas before just uploading that :)
[12:29] <abogani> If he continue to consider me...
[12:30] <persia> He knows more about the build system than the both of us combined.  You might suggest the -x trick and see what he thinks.
[12:30] <abogani> Ok
[12:30] <persia> he might have a different recomemndation, or want more time to think, or say "Go ahea and try".
[12:37] <ScottL> jussi, here:  https://wiki.ubuntu.com/ScottLavender
[12:37] <ScottL> i originally was waiting to give the link until i completely finished it, but i cleaned up the bottom of it enough this morning though
[12:37] <ScottL> thank you
[12:38] <abogani> Wow!
[12:38] <abogani> It seems very completed.
[12:42]  * abogani would want give thanks to all who correct his horrible English! Thanks!
[12:50] <persia> ScottL: contributions to Ubuntu Studio *are* contributions to Ubuntu.
[12:50] <persia> There's a reason we're part of a larger project :)
[12:56] <persia> ScottL: I don't sit on the board that will review your application (wrong continent), but excepting the false distinction between contributions to Ubuntu Studio and contributions to Ubuntu, your application is one of the most complete and compelling I've ever seen.
[12:57]  * abogani agrees
[13:00] <abogani> but my opinion don't worth much
[13:01] <persia> abogani: On the contrary.  You're an Ubuntu Member, so your testimonial carries considerable weight with the approval boards.  If you feel that way, please add a testimonial to ScottL's wiki page.
[13:18] <abogani> persia: For sure If someone review my English. :-)
[13:24] <quadrispro> ScottL, why don't you apply for MOTUship?
[13:25] <abogani> MOTUship?
[13:28] <quadrispro> abogani, to become ubuntu-developer
[13:30] <jussi> !motu
[13:30] <abogani> quadrispro: So perhaps it is a mentoring program?
[13:31] <quadrispro> abogani, there was a mentoring program, I think persia knows much more about it than me
[13:35] <abogani> persia: (re -preempt) I suppose than they meant "remove for main git tree".
[13:39] <persia> abogani: I know, and you know, but I want them to know that :)
[13:39] <abogani> persia: :-)
[13:39] <abogani> lol
[13:39] <persia> My fear is that they will decide they get to ignore it just because it's a different source package.
[13:39] <persia> And then leave known bugs in it.
[13:40] <quadrispro> bye guys
[13:40] <persia> I'm kinda against the mentoring program.
[13:40] <persia> I used to be a mentor (one of my mentees is in the channel), but I think folks who want to be MOTU do better just qworking with other MOTU.
[13:40] <abogani> It is exactly what I expect from them.
[13:41] <abogani> persia: ^
[13:41] <persia> That said, MOTU is *not* the only way to become a developer these days.
[13:41] <abogani> quadrispro: Ciao!
[13:41] <persia> abogani: That would be sad, really, but yes.
[13:43] <abogani> persia: I would want let you notice than I totally ignored in #launchpad (for build kernel in PPA) and in #ubuntu-kernel (for new kernel). What you would do in my shoes?
[13:43] <persia> I don't think you were ignored in #launchpad.
[13:43] <persia> I saw some traffic.
[13:43] <persia> That nobody who was around had a good answer is a different matter.
[13:44] <persia> At least two active Soyuz developers did talk to you about the issue.
[13:45] <persia> I've also seen a fair bit of commentary about the new kernel in #ubuntu-kernel.  If they folks there don't sponsor your upload, try pointing imbrandon at it (he said he was interested in that class of kernels)
[13:48] <abogani> persia: I _really_ more and more appreciate imbrandon help but ....
[13:48] <abogani> persia: Did you notice than kernel people have got a very big ego? If I bypass them I can incur in some problems in future...
[13:49] <persia> Most of them can't upload anything at all.
[13:49] <persia> Do you feel that the earlier discussion was sufficient that they expect a new kernel to be uploaded?
[13:49] <persia> Do you really think they care how it gets uploaded, as long as you work with them on it otherwise?
[13:53] <abogani> :-(
[13:53] <persia> What?
[13:53] <persia> It may be because I'm a bit distracted, but I'm not understanding the issue.
[13:58] <abogani> The issue is than I don't know what is the right way to do this things.  So I can't know how answer to your questions.
[13:58] <abogani> Simply I'm trying to do things in most reasonable way.
[14:03] <abogani> By the way, Anyone could review my English for Scott's application?
[14:08] <persia> In my opinion, the right way is to do what it takes to get stuff done, trying to involve as many folks as possible for comment in the process.
[14:08] <persia> And if anyone objects to anything, discuss it reasonably and get it fixed.
[14:08] <persia> Especially at the beginning of a cycle, it's usually better to just do stuff and then fix it.
[14:09] <persia> Things can be undone later, but once freezes begin to arrive, it's hard to do new stuff.
[14:16] <abogani> I agree with you but We should in two for "discuss". For example the last wgrant's suggestion was "abogani: You should prevent it from taking that long." It isn't seems a discussion to me.
[14:17] <abogani> scott-work: Dow you have a minute for me?
[14:18] <scott-work> abogani: certainly :)
[14:19] <abogani> scott-work: Could you review English on my comment about your application? :-)
[14:20] <scott-work> abogani: i am always happy to review your English on anything :)
[14:22] <abogani> scott-work: ;)
[15:50] <scott-work> *sigh*
[15:50] <scott-work> persia, i've attempted to talk to the #ubuntu-desktop people a few times about the network-admin bug and i'm not receiving much response
[15:50] <scott-work> i'm going to look for someone to contact directly unless you have a better suggestion
[17:09] <persia> scott-work: I'd recommend checking with the changelog owner for the changelog entry dropping the patch.
[17:09] <persia> If they don't respond, just do it (as it indicates a lack of interest on their part)
[17:09] <scott-work> i shall
[17:10] <persia> If they object to just doing it, the discussion has started.  As long as you're respectful from that point, the result should remain good.
[18:29] <abogani> persia: smb is volunteer to update linux-rt (in Lucid), apw is volunteer for review and find someone with upload rights for -lowlatency.
[18:30] <abogani> persia: At the moment miss only the right man for upload upgrades in Maverick.
[18:30] <abogani> persia: About -rt I meant.
[18:32] <abogani> persia: Tomorrow I'll try to request that to imbrandon.
[18:32] <persia> The only other kernel uploaders are tgraner and ogarasawa
[18:33] <persia> ogarasawa is busy in the role of primary uploader: I'm not sure she'll have time.
[18:33] <persia> And tgraner is always too busy.
[18:33] <abogani> persia: I don't think to have chance with them.
[18:33] <persia> I'd go with imbrandon, unless you expect someone will complain.
[18:33] <abogani> persia: I am too slow in typing...
[18:33] <abogani> :-)
[18:34] <persia> Given that you're actively working with the security team, I doubt they will have any issues if someone else uploads, as long as it's a good upload.
[18:34] <persia> And I'm fairly certain that by working with these folks, you can improve your developer application, and be able to upload directly in a couple months.
[18:35] <abogani> persia: At the moment I would want only let our users in a better situation (my application could wait).
[18:37] <persia> I know.  It's just awkward hunting sponsors in a narrow domain, because so many folks are afraid to upload kernels.
[18:37] <persia> So things will be easier once that's also sorted.
[18:41] <abogani> I hope.
[18:46] <persia> Indeed.  We'll see.