[00:00] <infinity> I suspect it related to upstart-job being a virtual package somehow breaking the world here, but... Meh.
[00:01] <infinity> relates*
[00:01] <infinity> I'll give it some more brain time to sink in
[00:12] <RAOF> Oh, *urgh*. cups 1.5.3-0ubuntu2 was broken.
[00:12] <RAOF> infinity: Can I get a second opinion on this: http://launchpadlibrarian.net/109781750/cups_1.5.3-0ubuntu1_1.5.3-0ubuntu2.diff.gz - you're looking at the postinst, “if dpkg --compare-versions "$2" lt-nl "1.5.3-3"; then”...
[00:14] <RAOF> infinity: That looks like it'll break on any upgrade to cups, such as the 1.5.3-0ubuntu3 update that's
[00:14] <RAOF> recently been published.
[00:24] <infinity> RAOF: It certainly could, depending on the contents of said file, yeah...
[00:25] <infinity> RAOF: Same broken comparison later in the postinst too.
[00:34] <RAOF> I don't know how widespread the problem is, so I'm not sure quite what to do next
[00:34] <RAOF> Also, baby impedes my typing speed
[00:37] <skaet> RAOF,  any other evidence that folks are seeing this,   or isolated incident?
[00:37] <skaet> (possible user error)
[00:38] <RAOF> Still possible user error
[00:38] <RAOF> The packaging *is* wrong, though
[00:44] <skaet> RAOF, can you start off a new bug to track the packaging error?
[00:51] <RAOF> skaet: bug #1037845 is your winner.
[00:51] <ubot2`> Launchpad bug 1037845 in cups "[precise-updates] Cups 1.5.0-0ubuntu2 has incorrect postinst" [Undecided,New] https://launchpad.net/bugs/1037845
[00:52] <skaet> Thanks RAOF.
[01:29] <skaet> infinity,  stgraber,  any updates on when we'll be getting cardamom and kapok back on line?
[01:42] <skaet> stgraber, infinity - chinese images appear to have built on the buildds now.    Am kicking off the rest of the rebuilds for precise on nusakan.
[01:45] <stgraber> skaet: I'm back, looking at all the highlights. Will trigger whatever's left
[01:46] <skaet> stgraber,  I've kicked off the desktop ones (executed set from pad),  if you want to do the alternates and core,  that will complete the set.
[01:46] <stgraber> right, done catching up, starting a rebuild of everything (might as well)
[01:47] <skaet> full desktop is already building
[01:48] <skaet> all of them...
[02:02] <RAOF> skaet: Ok, the poster followed up on that bug; it's still not entirely clear what's happening, but user-error is increasing in probability.
[02:03] <skaet> RAOF,  thanks for following up.
[02:03]  * skaet keeping fingers crossed its user error.  ;)
[02:14] <skaet> just an update for anyone reading the backscroll and intersted in the state of the builds...
[02:14] <skaet> full set of precise daily images is being produced and published to iso tracker right now.
[02:15] <skaet> crontab has been turned back on for quantal,  so those images should be emerging as well in their regularily scheduled times.
[02:15]  * skaet --> EOD
[02:15] <jocarter> night skaet
[02:16] <skaet> thanks.
[03:16] <cjwatson> Subject: LiveFS (built by kate) ubuntu-studio-dvd/precise/amd64 failed to build on 20120817
[03:16] <cjwatson> skaet: looks like a typo in the pipeline, ubuntu-studio -> ubuntustudio
[06:13] <ScottK> Did the -updates regression get passed off to anyone?
[06:15] <infinity> ScottK: The cups one?
[06:16] <infinity> ScottK: RAOF was looking into it further to see if it might actually have just been user error.
[06:16] <ScottK> Yes.
[06:17] <RAOF> There's a definite chance of user-error; the user has replied on the bug that the bug they replied on is not actually the bug they were seeing. I've asked to verify that they're seeing an actual regression.
[06:17] <RAOF> On the other hand, the cups postinst is *definitely* wrong.
[06:18] <ScottK> Was it wrong in the previous release or is this new wrongness?
[06:18] <RAOF> There was some wrongness introduced in 1.5.0-0ubuntu2
[06:19] <RAOF> There was also some wrongness introduced in 1.5.0-0ubuntu1. I don't think 1.5.0-0ubuntu3 introduced any further wrongness.
[06:20] <ScottK> That's all regression-update though.
[06:20] <RAOF> Right.
[06:21] <ScottK> My vote is fix it ASAP then.
[06:21] <RAOF> I need to ask til what the practical upshot of that wrongness is; it looks like it might be as benign as needlessly deleting a cache.
[06:22] <ScottK> If that's it, I guess it can wait until after 12.04.1, but since we've got a zero tolerance policy on regressions in updates it needs to be addressed.
[06:23] <RAOF> Yes.
[06:24] <ScottK> I updated your bug.
[06:24] <ScottK> I pointed it at 12.04.1 for the moment.
[08:27] <babyface> are the quantal desktop isos under building now?   still can not find them on the cdimage server
[08:28] <cjwatson> You probably should expect continuing disruption there until the datacentre move is complete.
[08:28] <cjwatson> i.e. check back next week.
[08:28] <babyface> cjwatson,  ack. thanks for the info
[08:29] <cjwatson> If you get anything today, it's a bonus. :-)
[08:30] <babyface> cjwatson, hehe
[09:20] <Laney> Well, looks like we have i386/amd64 buildds for the images at least.
[09:32] <Laney> ah, someone recronned it
[09:36] <Daviey> cjwatson: hey, would you be able to NEW review ubuntu-cloud-keyring please?
[09:37] <cjwatson> Daviey: It occurred to me while I was offline: any reason this shouldn't just go into cloud-utils, which already includes a keyring?
[09:37] <Daviey> cjwatson: well they serve different purposes TBH
[09:38] <cjwatson> Yes, they would need to be different actual keyring files.  But is cloud-utils perhaps already installed everywhere that might want this keyring?
[09:38] <Daviey> cloud-utils means installing software people potentially don't need
[09:38] <cjwatson> So it isn't already installed everywhere relevant?
[09:38] <Daviey> hmm
[09:39] <Daviey> i didn't think it was in the server seed, but i'll double check
[09:39] <cjwatson> Only cloud-image apparently.
[09:39] <cjwatson> OK, so perhaps that wouldn't make a great deal of sense.
[09:40] <Daviey> cjwatson: The funny thing is.. this package only really makes sense on Precise. :)
[09:41] <Daviey> ie, there won't be an archive series for Quantal
[09:43] <cjwatson> well, accepted anyway and you can figure out what to do with it in post-precise series later
[09:44] <Daviey> cjwatson: thanks.
[12:12] <mdeslaur> uhm, nspr on precise is trying to uninstall my language packs
[12:14] <mdeslaur> infinity: ^
[12:16] <mdeslaur> oh, hrm, I see they are obsolete packages
[12:17] <mdeslaur> trouble is, update-manager refuses to uninstall packages, so some precise users will be unable to update now
[12:19] <mdeslaur> slangasek: ^
[12:21] <Laney> mdeslaur: I thought that was debugged in ubuntu2.2
[12:22] <Laney> https://launchpad.net/ubuntu/+source/nspr/4.8.9-1ubuntu2.2
[12:22] <mdeslaur> 2.2 is what's causing it
[12:22] <mdeslaur> actually, update-manager seems to now handle uninstalling properly if you go through the "partial upgrade" dialogs
[12:24] <mdeslaur> ok, the partial upgrade worked...so, it's not critical...just probably confusing for users
[12:24] <mdeslaur> no biggie
[12:25] <mvo> mdeslaur: uh, unattended-upgrades will probably hold it back too, what package is causing this? could we do something to woraround it?
[12:25] <mdeslaur> mvo: it's nspr ubuntu2.2, see #1036794
[12:26] <mdeslaur> oh right, unattended-upgrades...hrm, yeah, we probably need to fix it then
[12:27] <mvo> mdeslaur: its ok(ish) as update-manager will at least popup on the next session
[12:29] <mdeslaur> mvo: assuming the usual user of the machine who has unattended upgrades turned on actually has admin rights
[12:29] <mvo> mdeslaur: yep
[13:13] <stgraber> 17:04 < stgraber> hmm, I'm actually wondering what update-manager will do as the upgrader will require removing packages on these weird precise systems
[13:13] <stgraber> 17:04 < stgraber> though at least it'll do the right thing when upgrading from oneiric, so that's already a big win
[13:13] <stgraber> 17:04 < stgraber> infinity: thanks!
[13:13] <stgraber> mvo, mdeslaur: ^
[13:13] <stgraber> 17:05 < infinity> stgraber: update-manager pretty much flat out refuses to remove packages (same as "apt-get upgrade"), but there's not much we can do about that situation. :/
[13:13] <stgraber> 17:06 < infinity> stgraber: Thanfully, we didn't really have nearly as many "normal users" back in jaunty times, and even fewer "normal users" who've probably upgraded through
[13:13] <stgraber>                   all the releases since, so there's a fair chance that anyone in said predicament can hit a console and type "apt-get dist-upgrade", which should work.
[13:15] <mdeslaur> stgraber: why jaunty? this will hit anyone who's upgraded from lucid
[13:15] <mdeslaur> or natty
[13:16] <mdeslaur> stgraber: I don't see how installing natty and upgrading to oneiric and precise is considered to be a "weird precise system"
[13:18] <skaet> cjwatson,  thanks for sorting the typo and respinning up the images for ubuntu studio.  Have fixed it in the ubuntu-release pad now.
[13:19] <cjwatson> skaet: I didn't respin
[13:21] <xnox> "* lamont fires off the  buildlive command and watches|
[13:22] <xnox> at like 1am today, not sure if it is related.
[13:22] <stgraber> xnox: unrelated
[13:22] <xnox> stgraber: oh well... =)
[13:23] <stgraber> skaet: rebuilding
[13:23] <Laney> was me, sory forgot to mention
[13:23] <stgraber> Laney: oh well, they'll have two rebuilds then ;)
[13:23] <Laney> makes them twice as good
[13:23] <Laney> it was 10ish UK
[13:23] <skaet> thanks Laney.
[13:24] <lamont> mdeslaur: if "installing an old release and upgrading to each new release as it comes out, with the upgrader" is considered a "weird and unsupported system", then we hate our installed base and should all be shot in the head
[13:24] <lamont> stgraber: ^^
[13:25] <mdeslaur> the original problem only occurred to systems that were upgraded from jaunty, but the fix that went in now triggers an issue for people coming from lucid or natty
[13:25] <stgraber> mdeslaur: hmm, I think we somehow missed that language-support-en was only removed in oneiric... the initial problem was with language-support-translations-en which was indeed deprecated after jaunty
[13:26] <mdeslaur> stgraber: yeah, that makes sense
[13:26] <stgraber> slangasek: what was the reason for also breaking against language-support-en? I vaguely remember language-support-translations-en being the real problem here
[13:26] <mdeslaur> stgraber: so this is going to hit a _lot_ more users than you had planned
[13:27] <stgraber> mdeslaur: yeah, will check with slangasek for the reason of the breaks against language-support-en, we might get away with re-SRUing another update breaking only language-support-translations
[13:27] <stgraber> but slangasek rarely does something without a very good reason, so we'll see...
[13:28] <mdeslaur> stgraber: yeah, isn't that annoying? it makes the rest of us look bad :)
[13:30] <stgraber> mdeslaur: so, from a UI point of view, what's happening to the user at the moment? do they have to go to a terminal to force a dist-upgrade or can they somehow do it from update-manager?
[13:31] <mdeslaur> stgraber: update manager will give a scary dialog that says updates can't be installed, and suggests trying a partial upgrade
[13:31] <mdeslaur> you then go through a few dialogs that asks to remove packages, etc.
[13:32] <mdeslaur> stgraber: if you use unattended-upgrades, it stops working
[13:32] <mdeslaur> stgraber: ie: if someone changed their preferences to automatically install updates, or in a corporate environment
[13:32] <stgraber> right, though in my experience unattended-upgrades stops working every month or so (whenever there's a potential conffile prompt), so users should be used to doing a standard upgrade from time to time
[13:33] <mdeslaur> stgraber: there shouldn't be any conf file prompt on normal desktop systems
[13:33] <mdeslaur> stgraber: or rather, no conf file changes in security updates and srus
[13:36] <mdeslaur> mvo: what happens to unattended-upgrades if there are conf file changes? so it keep those packages back, or does it default to something?
[13:36] <stgraber> keeps them back
[13:36] <mdeslaur> stgraber: so the other updates still get installed?
[13:36] <stgraber> I mostly see that on my servers/containers with updates like apache
[13:36] <stgraber> yeah, it usually updates as many as possible
[13:37] <mdeslaur> stgraber: I believe the partial upgrade situation grinds unattended upgrades to a half
[13:37] <mdeslaur> halt
[13:38] <mvo> mdeslaur: by default keeps it back and notifies about it
[13:38] <mvo> mdeslaur: all the ones that can be installed wil lbe installed
[13:39] <mdeslaur> mvo: ok, and in the partial upgrade scenario, it just aborts?
[13:43] <mvo> mdeslaur: it will skip the package that requires the removal but upgrade everything else
[13:43] <mdeslaur> mvo: oh, good, that's not as bad as I thought
[13:43] <mdeslaur> thanks mvo
[13:43] <mvo> yw
[13:47] <mpt> stgraber, mvo, if you can figure out a safe way to verify that yes, this upgrade really should remove a package, please do so ... I hate that partial upgrade dialog with a passion
[13:49] <mpt> (bug 955022)
[13:49] <ubot2`> Launchpad bug 955022 in update-manager ""Not all updates can be installed" requires a decision most people can't make" [Medium,Confirmed] https://launchpad.net/bugs/955022
[13:50] <mvo> I wonder if we could add some metadata, something like "XB-Removal-Ok: old-package-that-really-really-can-go-away"
[13:50] <mvo> i totally agree with the bugreport fwiw
[13:50] <stgraber> slangasek, mdeslaur: I uploaded a new nspr to -proposed removing the language-support-LANG Breaks, only keeping the language-support-translations-LANG ones. I'm not sure that'll work, but at least we'll have it in the queue if it does.
[13:51] <stgraber> mvo: I think extra metadata on the binary package would be reasonable. That way when we add a Breaks in a SRU we can just add it there too and give a good upgrade experience to the users.
[13:51] <mpt> mvo, and in <https://wiki.ubuntu.com/ReleaseUpgrades> I included a "These applications conflict and must be removed:" list that could take care of the rest.
[13:53] <mdeslaur> stgraber: that would help with security updates too, we've been doing some crazy things to prevent package removals in security updates
[13:53] <mvo> in preparation for a sru it would be great if the build score for https://launchpad.net/~mvo/+archive/freeglut-multiarch could be raised
[13:54] <stgraber> mvo: rescored the individual builds
[13:54] <mvo> mdeslaur, stgraber: that actually makes me wonder if security updates simply should always trump and allow removal, but I guess its safer if we have a allowed-removal list - do you have a good example case where htis is used/needed?
[13:54] <mvo> stgraber: \o/
[13:55] <stgraber> mvo: hmm, I'm wondering, could we get away with a breaks/provides/replaces kind of thing or would that still lead to partial upgrade?
[13:55] <mvo> stgraber: currently I think any removal will cause it to be defensive :/
[13:57] <mdeslaur> mvo: this was an example I can think of: http://launchpadlibrarian.net/36531850/bind9_1%3A9.4.2.dfsg.P2-2ubuntu0.3_1%3A9.4.2.dfsg.P2-2ubuntu0.4.diff.gz
[13:58] <mdeslaur> wow, 2009, back when I was young and fresh-faced
[13:58] <jocarter> ah those were the days
[14:02] <mvo> mdeslaur, stgraber: but I think you have a point about using conflicts/provides/replaces, it could similar honor that and we don't need a extra field or am I missing something?
[14:03] <mvo> mpt: thanks for the spec link
[14:04] <stgraber> mvo: both seem equally ugly, so I guess we might as well support conflicts/provides/replaces as it's already part of the standard :)
[14:06] <slangasek> stgraber, mdeslaur: were lucid and natty actually installing language-support-en?  It hadn't been revved since karmic, and AIUI was supposed to have been obsolete as well.  I didn't miss that it was still present in natty, but didn't anticipate that forcing its removal on upgrade would cause problems.  Is this actually a problem when dist-upgrading?  Or only when trying to install the SRU?
[14:07] <mdeslaur> slangasek: my laptop was installed with natty, and I had it installed
[14:07] <slangasek> hmm.
[14:07] <stgraber> slangasek: dist-upgrade isn't a problem, it's just causing the problem for people on precise with language-support-LANG
[14:07] <slangasek> ok, then it was less obsolete than I believed, sorry
[14:08] <stgraber> slangasek: do you expect any problem by removing these from the Breaks?
[14:08] <slangasek> stgraber: so we need to test whether the Breaks: on language-support-$thingy-en is enough to get the right lucid->precise upgrade path
[14:08] <slangasek> there's a *possibility* of problems if we leave those out
[14:09] <slangasek> because apt may go "oh, language-support-en is broken, let's try readding language-support$thingy-en" and it'll cascade from there
[14:09] <stgraber> slangasek: right. If you can review my upload to -proposed and accept it, I have a VM I can use to test the new package
[14:10] <mvo> fwiw https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1038113
[14:10] <ubot2`> Ubuntu bug 1038113 in update-manager "support conflicts/provides/replaces and allow removal in this case" [Undecided,New]
[14:10] <slangasek> mdeslaur: fyi, my system was installed as lucid and I don't have language-support-en installed
[14:11] <slangasek> so I don't think "anyone who has upgraded" is accurate
[14:11] <mdeslaur> slangasek: hrm...isn't that the metapackage that gets installed by the language support tool? I usually install in english, and install french using the language tool for testing
[14:12] <stgraber> slangasek: I guess we should SRU a new update-manager (can be post-12.04.1) adding these to the obsolete list so the dist-upgrader takes care of removing them
[14:12] <mdeslaur> I'm not quite sure why I had it installed
[14:12]  * mdeslaur fires up lucid vm
[14:14] <stgraber> mdeslaur: can you kill one of the security builds on PPC? they just came back to life and we need to have two SRUs built in the next hour or so (if we want them to make it by the time we freeze)
[14:15] <mdeslaur> slangasek: my pristine lucid vm that's installed using preseeding has language-support-en installed
[14:15] <slangasek> mdeslaur: ok, my mistake
[14:15] <stgraber> I scored them at 9000 in the past but apparently that wasn't enough to get in front of your security builds... I now bumped to 50000 which should ensure I get the buildd as soon as one of the two security builds disappear
[14:15] <jdstrand> stgraber: those will be done within that time frame
[14:16] <stgraber> jdstrand: good, was affraid it was libreoffice, kernel or some other fun things like that
[14:16] <jdstrand> no
[14:16] <jdstrand> there are a lot of things queued, but they shouldn't take long
[14:16] <stgraber> well, with my last rescore, I should get ahead of these anyway
[14:17] <stgraber> (IIRC private PPAs get 15000 and I rescored at 50000)
[14:18] <stgraber> mdeslaur, slangasek: confirmed that a clean 10.04.4 + updates comes with language-support-en and language-support-writing-en
[14:19] <slangasek> well, then I guess the alternate CD doesn't do this correctly and it's yet another reason to get rid of the alternates :)
[14:38] <ScottK> Is anyone on the cups regression in -updates?
[14:42] <stgraber> slangasek: running a test upgrader with a locally built nspr
[14:49]  * cjwatson tries to think of a way to do an HFS+ mount as root during image building
[14:49] <cjwatson> the hfsplus tools are just complete no-hopers :-(
[14:49] <cjwatson> I wonder if I could abuse the fact that bits of livecd-rootfs run as root
[14:50] <cjwatson> lamont: do the livefs builds have specially trimmed-down kernels, or is it possible that I might be able to do mount -t hfsplus?
[14:50] <lamont> Linux kapok 2.6.32-42-server #95-Ubuntu SMP Wed Jul 25 16:10:49 UTC 2012 x86_64 GNU/Linux
[14:51] <lamont> cjwatson: does that clarify things?
[14:51] <lamont> it's not particularly cut back other than being lucid
[14:51] <cjwatson> So basically a normal Ubuntu kernel image
[14:52] <cjwatson> I might just about be able to wedge something useful out of that
[15:09] <stgraber> slangasek: upgrade succeeded
[15:09] <stgraber> slangasek: I'll grep through the logs to ensure it used the new nspr though :)
[15:11] <stgraber> slangasek: no mention of -1ubuntu2.2 in the logs, only of -1ubuntu2.3 so that looks like a success
[15:11] <stgraber> will mark the bug verification done
[15:22] <stgraber> jibel: can you re-trigger the jenkins upgrade for 12.04.1 (these with -proposed enabled)?
[15:22] <stgraber> want to check we don't get any regression with the nspr in proposed
[15:25] <jibel> stgraber, started profiles desktop, server, server-tasks for lucid and oneiric. main and universe are scheduled to start in 90min
[15:25] <stgraber> thanks
[15:25] <slangasek> stgraber: great, thanks!
[15:26] <stgraber> slangasek: I think we should copy directly to -updates once we have the result from Jenkins. I know it's Friday but I don't see how that change can make it any worse ;)
[15:26] <slangasek> stgraber: agreed, this is effectively an SRU regression
[15:26] <slangasek> speaking of which, let me catch up on this cups thing
[15:29] <stgraber> knome: so, xfwm4 is finally built on all architecture. Do you guys want it pushed to -updates today so it makes it by freeze time (in 30 minutes) or do you prefer to wait until Monday, meaning the Xubuntu images built today won't be true candidates.
[15:29] <stgraber> oops, forgot to rescore nspr on powerpc... done now, should be built soonish
[15:32] <slangasek> ScottK: I'm confused by bug #1037845; we're never going to have 1.5.0-3 in precise-updates, true, because the version in precise is already greater than this
[15:32] <ubot2`> Launchpad bug 1037845 in cups "[precise-updates] Cups 1.5.0-0ubuntu2 has incorrect postinst" [High,Confirmed] https://launchpad.net/bugs/1037845
[15:34] <ScottK> slangasek: Isn't 1.5.0-0ubuntu2 < 1.5.0-3
[15:36] <slangasek> ScottK: certainly, but that's not the version we have in precise
[15:36] <slangasek>       cups | 1.5.2-9ubuntu1 |       precise | source, amd64, armel, armhf, i386, powerpc
[15:36] <slangasek>       cups | 1.5.3-0ubuntu3 | precise-updates | source, amd64, armel, armhf, i386, powerpc
[15:36] <ScottK> Both of which are < 1.5.3-3
[15:37] <ScottK> So I'm now confused about your confusion.
[15:37] <stgraber> ScottK: you just said < 1.5.0-3 (15:34 UTC)
[15:37] <ScottK> Can't type
[15:37] <ScottK> Meant that.
[15:37] <ScottK> Oh.
[15:38] <ScottK> Can't read either.
[15:38] <cjwatson> You're sorted, then.
[15:38] <ScottK> Yeah.
[15:38] <ScottK> RAOF: ^^^ so that's not the problem.
[15:38] <stgraber> right, the condition will never match, so not a problem
[15:38] <ScottK> Yeah.
[15:38] <ScottK> There's still apparently some undiagnosed issue with Bug 973270
[15:38] <ubot2`> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released] https://launchpad.net/bugs/973270
[15:42] <cjwatson> balloons: do we have any non-zero number of currently-engaged community Mac testers?
[15:42] <slangasek> in which the commenter says his bug is probably actually bug #995111
[15:43] <ubot2`> Launchpad bug 995111 in cups "Print failure since upgrade to 12.04" [High,Fix released] https://launchpad.net/bugs/995111
[15:43] <cjwatson> balloons: I am in the middle of an evil plan, but it only works if I can get it validated on some Macs
[15:43] <balloons> cjwatson, by mac do you mean ppc or amd64mac?
[15:43] <ScottK> We have one, sometimes two for Kubuntu.
[15:43] <cjwatson> balloons: the latter
[15:43] <ScottK> shadeslayer: ^^^
[15:44] <balloons> k.. then yes, we have some
[15:44] <cjwatson> ideally a range of models
[15:44] <shadeslayer> sec, need to read the backlog
[15:44] <balloons> I know at least one persn with a imac and a couple with macbook pros
[15:44] <shadeslayer> cjwatson: hey hey, I have a mac :)
[15:45] <shadeslayer> I was told that the amd64+mac iso was there because the standard ISO can't boot on some machines
[15:45] <stgraber> cjwatson: if you just need to boot a media to check the xoriso change, I can probably borrow jocarter's mac ;)
[15:45] <cjwatson> stgraber: well, I did commit a preliminary change earlier today yes, but that's not the whole thing
[15:45] <shadeslayer> I also have a technique that allows you to EFI boot the ISO using GRUB's loopback mechanism, though I haven't documented it anywhere
[15:46] <cjwatson> so I'm working on incorporating something that's roughly equivalent to the technique used in Fedora
[15:46] <shadeslayer> \o/
[15:46] <cjwatson> I'm having to be a bit creative, because the Fedora approach relies on being able to loop-mount a filesystem as root
[15:47] <stgraber> oh, that explains the hfsplus question ;)
[15:47] <cjwatson> I *think* that if I rely on all the features of xorriso 1.2.4 that I can lay my hands on and run it twice, I can work around that
[15:48] <cjwatson> (because it has code to generate ISO9660/HFS+ hybrid filesystems, and I can by definition presumably rely on that being readable as HFS+)
[15:49] <shadeslayer> cjwatson: any plans for the install stage ?
[15:49] <cjwatson> what I'll want to do is generate a test ISO and get people to boot it on as many Macs as possible, and find out (a) whether it boots at all (b) what the boot screen looks like (c) whether it boots as BIOS or UEFI (d) what ubiquity does as a result
[15:49] <slangasek> ev: errors still gives timeouts for all the lists... what's the status of breaking out the launchpad bits?
[15:49] <shadeslayer> I'm particularly interested in d)
[15:49] <ev> slangasek: RT 55342
[15:49] <cjwatson> I will probably need somebody with hardware to work on that
[15:50] <cjwatson> but hopefully the answer can be that it just does an EFI install
[15:50] <ev> slangasek: webops is in the middle of a datacenter move this weekend, so getting deployments out is unlikely to occur before monday
[15:50] <shadeslayer> cjwatson: oh and fwiw, there's a bug in X where it tries to address out of bound memory under EFI boot
[15:50] <shadeslayer> ( macbook pro 8,2 )
[15:50] <cjwatson> well that's unfortunate, perhaps you could harass the X people?
[15:50] <balloons> cjwatson, ohh. awesome.. so this would let us drop the amd64+mac iso?
[15:50] <slangasek> ev: phooey, escalating
[15:50] <balloons> if so.. you better believe I'm all for helping make it happen :-)
[15:50] <slangasek> ev: why are we not being all devops on this? :)
[15:50] <cjwatson> balloons: that's the intention, but it relies on quite a lot of bits
[15:50] <ev> slangasek: :)
[15:51] <shadeslayer> cjwatson: one just needs to put this into xorg.conf : http://paste.kde.org/536090
[15:51] <shadeslayer> but yeah, the X people would know
[15:51] <cjwatson> shadeslayer: X needs to auto-figure-that-out by default, then
[15:51] <ev> slangasek: charms of the infrastructure are in progress, but so are lots of things
[15:51] <shadeslayer> *nod*
[15:51] <cjwatson> we aren't going back to the bad old days of writing xorg.conf
[15:51] <cjwatson> especially not during live CD boot :)
[15:51] <shadeslayer> hehe :)
[15:52] <balloons> cjwatson, yes.. let's put up an image, and I'll put together a mini call for testing specific for mac users
[15:52] <ev> I do miss hand rolled mode lines
[15:52] <cjwatson> slangasek: ^- FWIW the other purpose of this plan is making EFI USB hybridisation work
[15:52] <shadeslayer> just saying that just getting EFI boot is not enough ;)
[15:52] <cjwatson> slangasek: I think the change I committed to debian-cd earlier today should take care of that
[15:52] <cjwatson> shadeslayer: yeah, I know, but I suspect it's a more viable forward path
[15:53] <cjwatson> balloons: before doing that, I think I'd like to work with one or two people like shadeslayer directly - since otherwise if it's completely broken I'll be swamped
[15:53] <slangasek> cjwatson: yes, I'm sitting here cackling gleefully at the discussion :)
[15:53] <shadeslayer> :)
[15:54] <shadeslayer> feel free to ping when you have a ISO, it'll take a bit of time since my connection is a bit slow, but I can surely help
[15:55] <cjwatson> it'll take even longer to squeeze up my connection, I expect
[15:56] <shadeslayer> ^_^
[15:56] <cjwatson> shadeslayer: do I recall correctly that your Mac(s) boot the amd64 images natively?
[15:56] <cjwatson> as EFI?
[15:56] <shadeslayer> cjwatson: yes
[15:57] <cjwatson> I mean, leaving aside X and installer troubles
[15:57] <shadeslayer> I can even install it, just need to pre partition the disks
[15:57] <cjwatson> OK; ideally I'd also like coverage from systems that don't, but perhaps that can be the second stage
[15:57] <shadeslayer> cjwatson: however, if I write the image to a usb, the system doesn't boot the USB
[15:58] <shadeslayer> I have to take special measures to partition the USB, write grub efi to the USB, etc
[15:59]  * xnox managed to boot EFI usb sticks, if in Mac OS X I wrote into nvram that the usb stick is blessed for next boot only
[16:01] <balloons> cjwatson, yes,. I wouldn't push it out to tons of people
[16:01] <balloons> I have a couple in mind I would ask directly
[16:02] <cjwatson> shadeslayer: Most of that may just be hacks in the installer to try to avoid doing things on Macs that previously didn't work
[16:02] <shadeslayer> ah :)
[16:03] <shadeslayer> cjwatson: any progress on the lb merge?
[16:03] <seb128> infinity, hey, did you break nvidia users on purpose by moving the xorg stack from quantal-proposed to quantal? ;-)
[16:04] <seb128> infinity, e.g did you know there was issues with nvidia?
[16:04] <shadeslayer> seb128: not to mention ATi users  :P
[16:04] <seb128> ATI users can use the ati driver
[16:04] <seb128> it's harder to use nouveau
[16:04] <cjwatson> shadeslayer: not as yet sorry
[16:04] <shadeslayer> card too new
[16:05] <shadeslayer> cjwatson: ah ok ... because my merge is a bit screwed up, the iso it builds doesn't boot, doesn't have a boot/preseed/other files and folders
[16:05] <shadeslayer> just isolinux and casper :P
[16:06] <balloons> cjwatson, ping and send me the link as well
[16:06] <balloons> I'll onboard a couple folks to test
[16:07] <cjwatson> balloons: I'll let you know when I'm ready; I'd prefer to work with a single person initially
[16:07] <balloons> cjwatson, yes.. don't want to overload
[16:07] <slangasek> ok, why in the world am I looking at bug #837054
[16:07] <ubot2`> Launchpad bug 837054 in ubuntu-geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Confirmed] https://launchpad.net/bugs/837054
[16:10] <xnox> slangasek: because it takes time to scroll past New York, before you get to 17 Portlands?
[16:11] <ogra_> slangasek, because plan moving to new york and want to know about the dangers in advance ?
[16:11] <slangasek> xnox: no... someone must have mentioned this bug somewhere, but I've now lost track of the reference
[16:21] <skaet> dobey, we're contemplating  letting ubuntuone-installer, ubuntuone-sso-client in to 12.04.1 without 7 day period in proposed?   what is the testing confidence like,  how great is the regression risk?
[16:21] <skaet> slangasek, stgraber, Daviey, ^
[16:22] <infinity> seb128: Blame tjaalton, he's the one who told me it was good to go.
[16:22] <slangasek> Riddell: can you please do qt4-x11 uploads to quantal-proposed, not to quantal?  As a core library, architecture skew has an impact on multiarch installability of the dev release
[16:22] <seb128> infinity, I though it was clearly flagged last week that nvidia was broken :-(
[16:22] <dobey> the risk is minimal i think. there's basically no risk for  ubuntu-sso-client. there's a little more risk with  ubuntuone-installer as the main fixes are basically an invasive  behavioral change (not ignoring errors where we once were  before), but i don't think there should be any new crashes in  installer as it should just show the errors in the UI now and let  the user retry or cancel
[16:23] <Riddell> slangasek: mm right, yes
[16:23] <slangasek> skaet: is that informational only, or is there a question for me?
[16:23] <slangasek> Riddell: ok, thanks :)
[16:23] <skaet> slangasek, for information only,  and a chance to raise concerns ;)
[16:23] <ScottK> When did it become a policy that only X updates with binary only support were allowed in the development release?
[16:23] <Riddell> slangasek: when uploading to -proposed is there a convenient way to remind yourself when it's ready to be copied over or do you just have to check back lots?
[16:24] <ScottK> infinity: As far as I can tell it was 'ready'.
[16:24] <slangasek> Riddell: I think infinity has made the copies his problem :)
[16:24] <skaet> thanks dobey,  stgraber,  you ok with including it too?
[16:25] <stgraber> I still want to look at errors.ubuntu.com first, but if nothing bad showed up there (when it eventually loads ...), we should be good
[16:26] <slangasek> stgraber: per-package reports should still load I think
[16:27] <infinity> Riddell: Yeah, until the automation is all sorted, I just look at the list occasionally, it's not rocket surgery (except when people decide to stage a large transition there).
[16:27] <skaet> stgraber,  how much time with errors.ubuntu.com before it makes sense to spin the first set of images?
[16:27] <stgraber> skaet: I'm looking at it now. Other issue is cedarview... at this point if we want candidates, that means they'll miss .1
[16:28] <stgraber> skaet: as they haven't been tested
[16:29] <infinity> stgraber: All it takes is verifying jockey DTRT by one person.  Surely, someone with hardware in, say, PES, can make that happen. :P
[16:29]  * infinity pokes jmleddy again.
[16:30] <infinity> Or, rather, I would poke him, were he online.
[16:30] <infinity> I'm going to think really hard about poking him and see what happens.
[16:30] <stgraber> skaet: ubuntu-sso-client looks good, no spike on the release in -proposed
[16:32] <stgraber> skaet: nothing scary for ubuntuone-installer either
[16:32] <stgraber> skaet: so these two are good to go I think
[16:32] <stgraber> still waiting on knome for xfwm4
[16:36] <dobey> awesome
[16:43] <stgraber> slangasek, infinity: can one of you please release ubuntu-sso-client and ubuntuone-installer?
[16:43] <stgraber> I'll keep monitoring errors.ubuntu.com for the next 5 hours in case we missed something
[16:44] <infinity> stgraber: Sure.
[16:45] <slangasek> stgraber: what's our rollback plan if there are problems?
[16:45] <slangasek> because we can't assume there will be time to fix any regressions before 12.04.1
[16:46] <stgraber> slangasek: re-upload of former version with an ugly version number
[16:46] <slangasek> dobey: ^^ you're ok with that rollback plan in the event of a regression?
[16:47] <dobey> i guess so
[16:47] <slangasek> ok
[16:47] <slangasek> infinity: pull the trigger (if you haven't already) :)
[16:50] <infinity> slangasek: I can pull it again, if you like echoes.
[16:50] <slangasek> nah
[16:50] <knome> stgraber, for what?
[16:51] <knome> stgraber, ah, today works if you can do it. :)
[16:52] <stgraber> knome: are you happy with the same plan as dobey? that's if anything breaks in the new xfwm4 we simply revert to the previous version for 12.04.1?
[16:53] <knome> stgraber, sure. i don't expect anything to break though :)
[16:53] <slangasek> stgraber: https://errors.ubuntu.com/?launchpad=false for more reliable loading
[16:54] <stgraber> slangasek: yay!
[16:55] <stgraber> infinity: based on the above, can you also release xfwm4 please?
[16:56] <knome> stgraber, infinity: thanks
[17:02] <skaet> stgraber, sounds good.
[17:05] <infinity> stgraber: Copied, BTW.
[17:05] <stgraber> thanks
[17:09]  * slangasek reopens bug #734376 for seb128_ 
[17:09] <ubot2`> Launchpad bug 734376 in jockey "jockey-gtk crashed with DBusException in call_blocking(): org.freedesktop.DBus.Error.NoReply in shutdown()" [High,Triaged] https://launchpad.net/bugs/734376
[17:09] <seb128_> slangasek, thanks, I wish we had a maintainer for jockey :-(
[17:09] <slangasek> seb128_: no one on desktop team is maintaining it?
[17:09] <seb128_> slangasek, same as that half a dozen list of unmaintained component that get most of the top issues atm that I listed on one of my -release emails
[17:10] <seb128_> slangasek, no, in fact it's deprecated in quantal, the only one who ever really worked is pitti and I think he lost interest for it, especially since he move to Qa
[17:11] <stgraber> jibel: how are the Jenkins tests going?
[17:11] <seb128_> slangasek, same as update-manager, update-notifier, sessioninstaller, etc
[17:11] <infinity> "Deprecated in Quantal" is no reason to not maintain it in previous LTSes...
[17:11] <slangasek> seb128: incorrect; update-manager and update-notifier are maintained by the foundations team
[17:12] <seb128> slangasek, ok, so jockey is "maintained" as well ;-)
[17:12] <seb128> it's as maintained as update-manager and update-notifier are
[17:12] <slangasek> seb128: I'm not handwaving definitions here.  Foundations ported update-manager and update-notifier to python3, and we've fixed the top crashers for them in 12.04.1.
[17:13] <slangasek> they're on the list of packages owned by foundations, and we're responsible for keeping them in working order
[17:13] <slangasek> I would expect the same to be true for desktop and jockey
[17:15] <stgraber> slangasek: did you have a chance to look at the logs I posted at http://www.stgraber.org/download/bug1017001/ ?
[17:16] <stgraber> slangasek: based on the discussion with infinity yesterday it seems to be linked to upstart-job being virtual (provided by upstart) and that somehow messing with the resolver
[17:16] <slangasek> stgraber: I've looked at them but they don't really give me any more insight on how to resolve this
[17:16] <slangasek> stgraber: what does apt-get with the -o debug::pkgResolverThingie option show?
[17:17] <seb128> slangasek, desktop maintains it, I don't think we have suffisant resources to do a good job about it
[17:17] <stgraber> slangasek: well, that's the problem, I have no idea how to get apt-get to run manually... as it requires the backported stack
[17:19]  * skaet --> lunch,  biab
[17:22] <slangasek> stgraber: oh, indeed :/
[17:32] <ScottK> Need help on a licensing question in New.  print-manager is GPL-2+, but there is one file that has a code snipped copied from cups 1.4.2 which is LGPL-2 only with openssl exception.  I believe that's distributable under GPL-2 only, but I'm not sure (needs some Debian copyright fixes in any case, but I want to give proper feedback).
[17:33] <slangasek> ScottK: yes, the intersection of those licenses would be GPL-2 only
[17:33] <ScottK> Thanks.
[17:50] <stgraber> slangasek: precise-upgrade-oneiric-desktop looks good, will wait some more to get testing results for lucid too
[17:51] <slangasek> stgraber: that's for the nspr regression test?
[17:52] <stgraber> yeah
[17:52]  * slangasek nods
[17:57] <jibel> stgraber, oneiric desktop passed but there is no language-support-* and lucid desktop with -proposed enabled picked nspr 4.8.9-1ubuntu2.2. I'll restart it
[17:57] <jibel> stgraber, I'll do a manual verification after diner with the packages that caused problem
[17:57] <stgraber> jibel: thanks
[17:59] <jibel> I could reproduce the unmet dep issue when upgrading from oneiric, I'd like to verify that the fix is still valid.
[18:30] <slangasek> hmm, strange profile on this crash. https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Findicator-weather%3A11%3Ax86_64%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B1cf08%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Baca2%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibdbusmenu-glib.so.4.0.13%2Bcafa%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B47d53%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0
[18:30] <slangasek> ... a0%3A%2Flib%2Fx86_64-linux-gnu%2Flibglib-2.0.so.0.3200.3%2B4849a%3A%2Fusr%2Flib%2Fx86_64-linux-gnu%2Flibgtk-x11-2.0.so.0.2400.10%2B1342f7%3A%2Fusr%2Flib%2Fpython2.7%2Fdist-packages%2Fgtk-2.0%2Fgtk%2F_gtk.so%2B1ac046%3A%2Fusr%2Fbin%2Fpython2.7%2B9890a%3A%2Fusr%2Fbin%2Fpython2.7%2B98602%3A%2Fusr%2Fbin%2Fpython2.7%2B9f1c0%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9081%3A%2Fusr%2Fbin%2Fpython2.7%2Ba9311%3A%2Fusr%2Fbin%2Fpython2.7%2Baa8bd%3A%2Flib%
[18:30] <slangasek> ... x-gnu%2Flibc-2.15.so%2B2176d
[18:30] <slangasek> also, a lovely url
[18:31] <slangasek> indicator-weather had a recent SRU... but the crashes don't seem to be tied to the SRUed version
[18:31] <slangasek> yet they appear to have only started happening recently
[18:41] <infinity> slangasek: Recently?  That crash has been happening in pretty much every version, no?
[18:41] <infinity> slangasek: If the frequency has gone up recently, I would contend that it's a direct result of the SRU being successful.
[18:41] <infinity> slangasek: (ie: now that indicator-weather isn't crashing in the other fashion, it runs long enough to break in this old and familiar way)
[18:55]  * skaet ->back
[19:21] <slangasek> infinity: the graph shows it's only been happening since July 31
[19:21] <slangasek> I don't know why that should be
[19:22] <slangasek> infinity: ah... possibly because there was a previous SRU on July 30
[19:23] <slangasek> so in fact, this is a new crash only since the first SRU, which was not published to -updates
[19:24] <infinity> I don't see an SRU on Jul 30... I see an upload to quantal, though.
[19:24] <slangasek> 11.11.28-0ubuntu1.1 has a 30 Jul 2012 changelog entry
[19:24] <infinity> Yeah, but it wasn't accepted until 08-04
[19:24] <slangasek> didn't get published until the 3rd though
[19:25]  * slangasek nods
[19:25] <slangasek> also, the *versions* it's reported in include the one from precise release
[19:26]  * slangasek thinks it's time for us to get better tooling for auto-analyzing regressions
[19:33] <infinity> Hrm.  So, if the graph curve is useful here, I assume we're looking for something that entered proposed around 07-30, and hit updates around 08-08...
[19:33] <slangasek> and is related to unity and/or indicators, most likely
[19:33] <infinity> Maybe.
[19:34] <infinity> Or hit quantal at similar times, messing with the graph.
[19:34] <slangasek> the version breakdown shows nearly all of it is with precise versions of the indicator-weather package
[19:35] <slangasek> (in fact, indicator-weather first revved in quantal on Jul 30)
[19:35] <infinity> Indeed.  In fact, the i386 version of the same trace doesn't have any quantal versions.
[19:35] <infinity> And has pretty much the same curve.
[19:58] <infinity> That was an awfully quick NEW review...
[19:59] <seb128> yeah, we do pre-upload reviews
[19:59] <seb128> so it's just checking that the upload matches the preupload version :p
[20:04] <skaet> slangasek,  the bugs associated with the cedarview drivers are not inspiring confidence that anyone's actually verified them.  Who is supposed to be doing the checking?
[20:04] <slangasek> skaet: jmleddy, and no, no one has actually verified them yet
[20:04] <slangasek> infinity and I have both sent nagmails today
[20:05] <slangasek> skaet: we appear to have cc:ed you, for that matter ;)
[20:05] <skaet> slangasek, yes, but was hoping it had progressed since that email ;)
[20:05] <slangasek> nope
[20:06] <skaet> :(
[20:08] <skaet> slangasek, stgraber, what's the risk like on npsr?  looks like its verified now.
[20:09] <stgraber> skaet: waiting for Jenkins
[20:09] <skaet> and is there anything else we want to consider for 12.04.1 candidate images?
[20:09] <stgraber> though the test runs might be done now, in the middle of a pretty tricky lxc merge, will check after that
[20:09] <stgraber> skaet: cedarview...
[20:09] <slangasek> I think those are the only two to consider
[20:10] <slangasek> and I think that if nobody is testing the cedarview today, it should be off the table
[20:10] <skaet> stgraber,  cedarview hasn't been tested yet,  so if they don't get to by the time everything else is ready, I see no point in holding up on them now.
[20:10] <skaet> slanagasek,  agreed.
[20:11] <slangasek> let me see if I can raise vanhoof
[20:11] <skaet> thanks slangasek,  I've put a ping into jmleddy
[20:12] <skaet> other thing I'm worried about with them, at this point, is that with the rest of the data center shifting tomorrow,  if theres something serious we may not hear about it.
[20:12] <skaet> ScottK,  did you start off an incident report earlier about the cups?
[20:13]  * skaet just cross checked and looks like its not user error. :/
[20:13] <ScottK> skaet: I did not because RAOF was the first man on the scene.
[20:14] <slangasek> skaet: oh, where did you find jmleddy that he was pingable?  He doesn't seem to have been on IRC
[20:14] <skaet> ScottK,  yes, but it was ambiguous as to whether it was user error or not and we didn't hear back until this morning when he's zzzing
[20:15] <ScottK> Agreed.
[20:15] <ScottK> I went to sleep not knowing.
[20:15] <ScottK> Someone should grab Til and shake him until we have an answer.
[20:17] <ScottK> BTW, just did a successful 10.04 -> 12.04 server upgrade.
[20:17] <jibel> stgraber, skaet manual verification from oneiric to precise and lucid to precise with nspr 4.8.9-1ubuntu2.3 is ok.
[20:17] <jibel> calculation of the upgrade is successful, language-support-translations-en is removed during upgrade.
[20:18] <jibel> for oneiric if evolution-plugins/natty and evolution-common/natty are installed, evolution is installed during the upgrade instead of blocking it.
[20:18] <skaet> :)  glad to hear upgrade smooth, ScottK
[20:18] <jibel> I'm currently testing a dist-upgrade on precise with language-support-*-en installed
[20:18] <skaet> Thanks jibel.  :)
[20:18] <jibel> automated test ran for desktop, server and server-tasks for lucid and oneiric to precise and nothing found.
[20:18] <skaet> even better news.  :)
[20:19] <slangasek> skaet, ScottK: the only end user reporting a regression in cups in precise-updates clarified later that his symptom matches an existing bug report related to USB-connected printers that has been present all along - possibly intermittently so
[20:19] <skaet> slangasek,  ping'd in a stale PM session it appears.  :P
[20:19] <slangasek> skaet: right ;)
[20:20] <ScottK> OK.  That's good to know.
[20:21] <skaet> slangasek,  not sure if incident report makes sense or not given the limited scope.   If its matching a known bug, am tempted to just let it follow regular flow rather than incident report it.    But agree with ScottK need to get Til on it.
[20:22] <slangasek> skaet: given that there's no evidence of an actual incident, I don't think we should spend time on an incident report
[20:23] <skaet> slangasek,  I can live with that.
[20:23]  * skaet considers it off her worry about list.
[20:24] <seb128> skaet, slangasek: +1 on no-incident-report, Till was off this end of week but I will ask him to have a look monday morning when he's back
[20:25] <slangasek> so https://bugs.launchpad.net/ubuntu/+source/cups/+bug/973270/comments/86 redirects to bug #995111; the latter seems to be the known outstanding, intermittent issue
[20:25] <ubot2`> Launchpad bug 995111 in cups "Print failure since upgrade to 12.04" [High,Fix released] https://launchpad.net/bugs/995111
[20:25] <ubot2`> Ubuntu bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released]
[20:36] <jibel> window manager crashed during a desktop upgrade from lucid to precise. desktop becomes unusable (no keyboard only mouse). Reproduced twice.
[20:50] <stgraber> slangasek: based on feedback from jibel, I think we should copy nspr now.
[20:55] <slangasek> stgraber: ack
[20:55] <slangasek> I've also just gotten feedback from jmleddy, he says he's tested the packages but didn't get a chance to update the bugs before he had to leave the office
[20:56] <skaet> stgraber,   looks like we've got our set then.
[20:57] <stgraber> yep, so we can copy cedarview-*, jockey and nspr
[20:57] <stgraber> then wait for all that to publish and start building candidates
[20:57] <infinity> Well, assuming jmleddy's feedback was going to be positive...
[20:57] <infinity> slangasek: Is that what we should assume from the above? :P
[20:58] <slangasek> it is ;)
[20:58] <infinity> Alright, then I can get to copying.
[20:59] <jibel> slangasek, what's the status of bug 1034668 ? it's target for .1
[20:59] <ubot2`> Launchpad bug 1034668 in indicator-appmenu "Upgrade from Lucid to Precise does not install packages for Global Menu: indicator-appmenu" [High,Triaged] https://launchpad.net/bugs/1034668
[21:00] <infinity> stgraber: Released nspr jockey cedarview-vaapi-driver cedarview-graphics-drivers cedarview-drm-drivers
[21:00] <infinity> stgraber: The whole mess should hit disk in ~30m.
[21:00] <tjaalton> hmm, no seb128
[21:01] <ScottK> He's not usually around on the weekend.
[21:01] <infinity> Smart man.
[21:03] <tjaalton> infinity: nvidia was already in quantal, and it occured to me today that the workaround to block the upgrade for it's users was  trivial
[21:03] <tjaalton> too late anyway
[21:04] <tjaalton> hope tseliot uploaded it, after checking the new version was just as broken
[21:07] <jibel> stgraber, did you try a cdromupgrade from lucid to precise with alternate i386 20120817 ?
[21:07] <stgraber> jibel: didn't try i386, but I believe that's the version of the amd64 one I used
[21:08] <jibel> stgraber, ok, it fails with unmet deps. I'll upload the logs.
[21:10] <stgraber> slangasek, jibel: uploaded indicator-appmenu to -proposed
[21:19]  * skaet --> appt.   back on line later.
[21:22] <slangasek> tjaalton: the workaround to make the nvidia package not claim to support an X ABI before it's ever seen it? :)
[21:22] <slangasek> stgraber: are we looking to get indicator-appmenu into .1 still?
[21:23] <stgraber> slangasek: not sure, I don't have a clear understanding of the bug, just blindly applied your suggested fix
[21:23] <slangasek> heh
[21:23] <stgraber> AFAICT they seem to be internet enabled upgrade problems, so in theory we don't need it on the media
[21:23] <slangasek> ok
[21:24] <stgraber> but maybe we do as jibel said he still had upgrade issues using media only on i386...
[21:24] <stgraber> I guess it'll depend on jibel's log
[21:24] <tjaalton> slangasek: yep, now that they are hardcoded and not generated during package build..
[21:24] <tjaalton> which was always wrong for the blobs
[21:26] <slangasek> yep
[21:26] <jibel> bug 1038272
[21:26] <ubot2`> Launchpad bug 1038272 in update-manager "lucid to precise i386 - cdromupgrade without network failed" [Undecided,New] https://launchpad.net/bugs/1038272
[21:26] <stgraber> jibel: looking
[21:27] <jibel> stgraber, I did a ./cdromupgrade and answered 'no' when it asked to use a network connection
[21:28] <stgraber> right, that's how I tested amd64
[21:31] <stgraber> slangasek: any idea on jibel's log?
[21:38] <slangasek> idea: is it too late to drop alternate CDs for 12.04? ;)
[21:38] <slangasek> ok, let's see here
[21:39] <stgraber> ;)
[21:39] <slangasek> gah, nspr
[21:39] <slangasek> is libnspr4-0d on the CD?
[21:40] <stgraber> I think so
[21:40]  * stgraber checks
[21:40] <slangasek> the error suggests it isn't
[21:40] <stgraber> stgraber@castiana:~/data/code/seeds/ubuntu.precise$ grep -r nspr .
[21:40] <stgraber> ./ship: * libnspr4-0d
[21:40] <stgraber> though the media doesn't agree
[21:41] <slangasek> $ grep nspr-0d precise/daily/20120817/*.list
[21:41] <slangasek> $
[21:41] <slangasek> yep, so that's the problem
[21:41] <infinity> slangasek: That regex could be wrong, of course. :P
[21:41] <slangasek> it could, but that's not actually the issue ;)
[21:41] <stgraber> No new revisions or tags to push.
[21:41] <infinity> Yeah, I'm going to ask the logs.
[21:41] <stgraber> so the seed is up to date...
[21:42] <infinity> ? Unknown ship package: libnspr4-0d
[21:42] <infinity> Did we promote it?
[21:42] <slangasek> checking
[21:43] <infinity> Nope.
[21:43] <slangasek> no
[21:43] <infinity> Let me fix that.
[21:43] <stgraber> oh, that'd explain it
[21:43] <infinity> Fixed in the nextr publisher.
[21:44] <stgraber> 16:47 < infinity> stgraber: libnspr4-0d will be in main (in proposed) after the next publisher.
[21:44] <stgraber> that was from a few days ago FWIW :)
[21:44] <stgraber> so did something move it back to universe while we weren't watching
[21:44] <infinity> stgraber: And it was probably true until a new version came in.
[21:44] <stgraber> that'd explain it indeed
[21:45] <infinity> overrides in pockets are a bit sketchy at times, as far as weird inheritance bugs go.
[21:45] <infinity> Though, I'm kinda curious now...
[21:45]  * infinity goes to look.
[21:47] <infinity> Yeah, 2.1 was in main, and then 2.2 and 2.3 landed in universe, due to the fact that pockets only inherit from -release.
[21:47] <infinity> We even had this conversation back then, if I recall.
[21:47] <infinity> Every time that source package gets updated, we'll need to re-promote. :/
[21:47] <infinity> Or fix the LP bug. :P
[21:47] <slangasek> sweet
[21:48] <stgraber> slangasek: right, so indicator-appmenu should go to -proposed and ideally be moved to -updates before 12.04.1 release
[21:48] <stgraber> the rest should be good to go after the next publisher run
[21:50] <infinity> I wonder if seeds have a keyword/char that can cause germinate to hard fail on a missing package.
[21:50] <infinity> That would at least catch this if it slips out of main again later.
[21:51] <infinity> Hrm, not according to the manpage.  Drat.
[21:52] <infinity> stgraber: Pending fixing the actual LP bug, maybe some hackery on cdimage to verbosely fail ubuntu-daily/precise builds that don't have libnspr4-0d in the .list or something?
[21:53] <infinity> Cause Murphy is so going to update that package between now and 12.04.2
[21:59] <slangasek> stgraber: indicator-appmenu accepted; do we have a way to test this without another CD build from -proposed?
[22:01] <slangasek> infinity: I don't understand why we haven't pulled that guy's upload privileges by now...
[22:01] <stgraber> slangasek: using the same system with a patched dist upgrader that allows for local packages
[22:02] <infinity> slangasek: Because Murphy is good for our job security.
[22:02] <slangasek> ok
[22:03] <stgraber> ok, so I'll start building everything but the alternates now
[22:07] <stgraber> all started now, didn't bother trying to get them in any particular order
[22:15] <stgraber> EOD, will be back in a little bit to start the live images, then disappear for the rest of the evening
[22:17] <slangasek> stgraber: thanks!
[22:35] <slangasek> infinity: hmm, what did we say the cutoff point should be after which we kick unverified SRUs out of -proposed?
[22:38] <infinity> slangasek: I don't recall, I suspect it might have been in the google doc of meeting note doom.
[22:39] <slangasek> hmm
[22:39] <stgraber> ok, that's everything started on nusakan, will check in a few hours that everything built properly
[22:39] <slangasek> well, I'm guessing at least that "528 days" exceeds the limit
[22:39] <infinity> slangasek: Seems plausible, yes. ;)
[22:46] <slangasek> infinity: fwiw I've looked over https://lists.ubuntu.com/archives/precise-changes/2012-August/ and can't find any SRUs matching those dates that would be a plausible culprit for the indicator-weather problem
[22:47] <slangasek> I conclude that indicator-weather just doesn't like August
[22:48] <cjwatson> just so people know, the publisher run currently in progress is cocoplum's last
[22:48] <cjwatson> or so I'm given to understand
[22:48] <wgrant> Right
[22:48] <slangasek> hmm
[22:49] <slangasek> I guess that means we don't get indicator-appmenu into precise-updates before the cut
[22:49] <cjwatson> we're in the advertised outage window now
[22:49]  * slangasek nods
[22:49] <slangasek> stgraber: ^^
[22:49] <cjwatson> when was the override change made?
[22:49] <slangasek> this is a package that's still pending publishing to -updates
[22:50] <slangasek> the override for libnspr4-0d is all settled, no problems there
[22:50] <cjwatson> depends how quickly pepo comes up then, I guess
[22:51] <slangasek> pepo?  are we reduced to using genus of garden vegetables now? :)
[22:52] <slangasek> ah, I guess that's the species rather than the genus
[22:52] <slangasek> still
[22:56] <cjwatson> I didn't even look it up; I'm just assuming hostnames are pwgenned now
[22:56] <infinity> I heartily approve of pepo, I can both remember and type that.
[22:58]  * infinity might go shower and get an early start on his weekend, since the rest of the world is going asplodey.
[22:58] <infinity> I'll check in later/tomorrow.
[22:58]  * slangasek waves
[23:23] <cjwatson> shadeslayer: http://people.canonical.com/~cjwatson/tmp/quantal-desktop-amd64-hacked.iso - would be interested to see what that does, per previous conversation
[23:23]  * shadeslayer downloads
[23:24] <shadeslayer> cjwatson: can I get the md5sum as well?
[23:25] <cjwatson> yeah, was just doing that :)
[23:25] <shadeslayer> it's going to take a couple of hours to download
[23:25] <cjwatson> quantal-desktop-amd64-hacked.sha256sum and quantal-desktop-amd64-hacked.sha256sum.gpg alongside now
[23:25] <shadeslayer> awesome
[23:25] <shadeslayer> I'll download it to my VPS and then make a torrent out of it :P
[23:26] <cjwatson> please don't :
[23:26] <cjwatson> :P
[23:26] <shadeslayer> ah ok
[23:26] <shadeslayer> downloading to vps and rsync'ing
[23:27] <shadeslayer> no point in using wget over this connection
[23:27] <cjwatson> totally unstable URL and moreover it's based off some random image which is whatever I had to hand
[23:27] <shadeslayer> right
[23:27] <cjwatson> the image from 2012-08-01 by the looks of things
[23:28] <shadeslayer> cjwatson: so basically, I use usb creator to burn it to a usb stick, and efi should pick it up and do a native boot
[23:28] <cjwatson> don't use usb-creator
[23:28] <shadeslayer> dd?
[23:28] <cjwatson> either write it to a DVD or whatever, or dd it straight to a USB stick
[23:28] <cjwatson> I'd actually like both tests if possible
[23:28] <cjwatson> usb-creator will introduce variables I don't want, and is unlikely to work
[23:29] <shadeslayer> alright, will have to go out and buy a DVD
[23:29] <cjwatson> basically I unpacked the old image, fiddled with xorriso arguments per advice from xorriso upstream on getting more reliable EFI hybridisation in general (now works for me from a USB stick), and added an HFS+ EFI image
[23:29] <cjwatson> generated by a subsidiary pass of xorriso
[23:29] <shadeslayer> hmm
[23:30] <cjwatson> and roughly based on what Fedora are doing in their images
[23:30] <shadeslayer> assuming there's a EFI/ folder on the top leve dir, it /should/ boot
[23:30] <cjwatson> waaaaaaay not that simple on macs
[23:30] <shadeslayer> *level
[23:30] <cjwatson> there's all sorts of fiddly stuff to get the boot chooser working
[23:30] <cjwatson> theoretically
[23:31] <shadeslayer> yeah, blame APPL and MSFT
[23:31] <shadeslayer> :P
[23:31] <cjwatson> if I got this right, the boot chooser (is it still "hold down Option at boot"?) should show an Ubuntu icon with "Ubuntu" underneath
[23:31] <shadeslayer> yay
[23:31] <shadeslayer> I was trying to get that, but never could figure it out
[23:31] <cjwatson> I'd be pretty surprised if it worked first time though
[23:31] <shadeslayer> hah :D
[23:32] <cjwatson> now doing that on the installed system as well is a whole other kettle of fish I don't care about right now
[23:32] <shadeslayer> *nod*
[23:32] <shadeslayer> Lets just get it to boot the Desktop atm
[23:32] <shadeslayer> one step at a time ;)
[23:33] <cjwatson> quite
[23:33] <shadeslayer> cjwatson: btw, the custom ISO that I built only has 2 folders, casper and isolinux
[23:33] <shadeslayer> is that what's expected?
[23:33] <cjwatson> not sure I can think about that tonight :)
[23:34] <shadeslayer> alright :)
[23:34] <cjwatson> I'm mostly up in case any help is needed with the ftpmaster bits of the DC move
[23:34] <cjwatson> hopefully won't be but you never know
[23:35] <shadeslayer> cjwatson: will you be available tomorrow
[23:35] <cjwatson> unlikely
[23:35] <cjwatson> sleep catchup, family stuff, housework, friend's stag do
[23:35] <shadeslayer> ok, will poke you on Monday then ;_
[23:36] <shadeslayer> :)
[23:36] <shadeslayer> though I managed to get the ISO building to work with live build from the archive
[23:37] <shadeslayer> as expected, md5sums don't match >.>
[23:37] <cjwatson> you're still trying to build quantal images with precise's live-build, which is ambitious at the very least and basically unwise
[23:37] <cjwatson> you need to use quantal's tools
[23:38] <cjwatson> even if you get it working now with precise there's absolutely no guarantee of it staying working
[23:38] <shadeslayer> mmmmm .... guess I could upgrade the server to quantal
[23:38] <cjwatson> use a quantal chroot
[23:38] <cjwatson> that's how all our builds work
[23:38] <shadeslayer> hm ... will do
[23:38] <shadeslayer> ah
[23:39] <cjwatson> livefs builds for $release are always in a $release chroot
[23:40] <shadeslayer> understood
[23:40] <shadeslayer> plus, qemu is all weird
[23:40] <cjwatson> qemu would be massively overkill for this
[23:41] <cjwatson> Unless you have some kind of complicated arrangement where you're doing arm livefs builds on a really fast x86 box or something
[23:41] <cjwatson> (Even then the tradeoffs aren't necessarily obvious due to things like memory limitations in the emulated machines)
[23:41] <shadeslayer> cjwatson: no, I meant, testing a iso on qemu
[23:41] <shadeslayer> over VNC
[23:41] <shadeslayer> because for some reason, -hda and -vnc don't work together
[23:42] <cjwatson> Ah, uh, I've never been that ambitious
[23:42] <shadeslayer> :D
[23:47] <shadeslayer> 0.o
[23:47] <shadeslayer> md5sum mismatch again
[23:56] <shadeslayer> cjwatson: are you sure the md5sum is right?
[23:56] <shadeslayer> because I'm getting 78be4c9b4b8bb81fd384ebc616485d81
[23:56] <shadeslayer> ( for the past 2 downloads )
[23:56] <cjwatson> I gave you a sha256sum, not an md5sum
[23:56] <shadeslayer> ergh
[23:56] <cjwatson> clue's in the filename :)
[23:57] <cjwatson> that said, the md5sum should be 2d3f192d06054546950e8acedf307402
[23:57] <shadeslayer> mm ... still doesn't match
[23:57] <shadeslayer> I clearly need more coffee
[23:58] <cjwatson> wait, what
[23:58] <cjwatson> oh damnit
[23:58] <cjwatson> rsync -avP quantal-desktop-amd64-hacked.iso lillypilly:public_html/quantal-desktop-amd64-hacked.iso
[23:58] <cjwatson> is not equal to public_html/tmp/...
[23:58] <shadeslayer> ...
[23:58] <cjwatson> sorry about that
[23:58] <shadeslayer> not a issue
[23:58] <cjwatson> I've moved the file to the right place now
[23:59] <shadeslayer> http://people.canonical.com/~cjwatson/tmp/quantal-desktop-amd64-hacked.iso right?
[23:59] <cjwatson> Yeah
[23:59] <shadeslayer> ok, just confirming :P
[23:59] <cjwatson> rsync should get you about half of it
[23:59] <cjwatson> assuming you can rsync from that
[23:59] <cjwatson> otherwise let me know and I can set up zsync
[23:59] <shadeslayer> nope
[23:59] <shadeslayer> can't