[00:01] <hggdh> skaet: ack
[00:04]  * skaet --> dinner
[00:56] <slangasek> all for -proposed, I guess?
[00:58] <infinity> slangasek: They were all for -release, I rejected them all and asked Robert to reupload to -proposed.
[00:58] <slangasek> ah, ok
[00:58] <infinity> I think he missed the "we're staging GNOME 3.4.0 in proposed" memo.
[00:58] <slangasek> ah, well, I missed it too
[00:58] <slangasek> :)
[00:59] <infinity> Yeah, seb was doing gnome 3.4 in proposed so that it would all build and stage and they could just release it on Friday after Beta with no fuss.
[00:59] <infinity> Which seems vaguely sensible.
[00:59]  * slangasek nods
[01:06] <cjwatson> stgraber: I give up for now; I'm not getting anywhere with this bisect / trawl through gnome-keyring/gcr history and I need sleep.  Sorry.
[01:13] <stgraber> cjwatson: thanks for trying for so long, good night!
[01:20] <skaet> heya,  who let all the packages through?
[01:22]  * skaet goes and reads the backscroll
[01:22] <infinity> skaet: Those are all in proposed.
[01:22] <skaet> yup,  just saw that,  adrenaline levels subsiding.
[01:22] <infinity> skaet: :)
[01:23] <infinity> stgraber: queuebot could perhaps announce "$dist-$pocket", both on accept and removal.
[01:23] <infinity> stgraber: Might reduce heart attacks.
[01:23] <infinity> stgraber: Err, on in and out, I guess, don't want to overload "accept" in this context.
[01:24] <infinity> stgraber: It would also be awesome if there was a way to identify how something was removed from the queue (accept or reject), but I'm guessing you don't have that info to work with, just that it's gone?
[01:28] <stgraber> infinity: yeah, I guess I could look in the Done queue if the package is there and announce it as approved then
[01:29] <stgraber> problem is, that "queue" (or status) is kind of long to list ;) so I'd have to check if there's an easier way in the API
[01:29] <infinity> Oh, yeah, scanning done or rejected is a losing battle.  Don't bother.
[01:29] <infinity> I forgot that queubot's just polling.
[01:29] <infinity> But if you could change (component) to (dist-pocket/component), that would be awesome.
[01:29] <stgraber> when we have the audit changes implemented it should be easy to just pull that record and show who accepted/rejected it
[01:30] <infinity> And duplicate that info on Removed.
[01:30] <infinity> (I assume you still have the info when you remove, as you're just pulling a member from a list or something?)
[01:33] <infinity> stgraber: Or put it on a role account on one of your machines, so I can add cute little features when I'm bored. :P
[01:36] <stgraber> let's try that
[01:38] <stgraber> looks like it's working
[01:38] <stgraber> infinity: happy? :)
[01:39] <stgraber> infinity: you can always send merge proposals for lp:~stgraber/+junk/queuebot
[01:41] <infinity> stgraber: You're missing dist.  Though, I guess that only matters if you have it scan non-release dists.
[01:41] <infinity> stgraber: (Which would actually be really handy, as I often don't notice when something's uploaded to, say, lucid-proposed)
[01:41] <infinity> s/non-release/non-devel/
[01:42] <infinity> stgraber: Would be cool if it ran 24/7, and was useful for old dists too.  I'm being picky, aren't I? ;)
[01:42] <stgraber> should be doable but would make it a bit slower as unfortunately we can't call getPackageUploads() on a distribution, it needs to be on a distro_series
[01:43] <stgraber> so the bot would need to call if for every supported release
[01:43] <infinity> Yeah, so you iterate through all supported series.
[01:43] <infinity> Doesn't need to poll as often for non-devel.
[01:45] <infinity> Shouldn't be too much slower, since you could call them all in parallel.
[01:45] <infinity> I've heard pretty neat things about threaded programming.  It's all the rage, I hear.
[01:45] <infinity> Ooo, but pocket on the removal message is already a huge win.
[01:45] <infinity> skaet: Less heart-attack inducing? ---^
[01:45] <stgraber> I'm sure we can get cjwatson to implement the threading ;)
[01:46] <infinity> I'm not a python wizard, but it must have some really dead easy callback conventions, right?
[01:46] <infinity> Seems like the sort of thing a modern high level language should have.
[01:47] <skaet> infiniity,  stgraber - thanks.  :)
[01:48] <infinity> queuebot: What, not going to spam us with the current queue status on connect this time?
[01:48] <stgraber> nope, it usually doesn't do it, I'm just forcing it to do it when I want to make sure it works
[01:49] <infinity> Ahh.
[01:49] <skaet> :)
[01:49] <stgraber> otherwise it doesn't do anything then the first entry it sees I get a backtrace and it dies ;)
[01:49] <infinity> Poor bot.
[01:50] <stgraber> I still need to make it's irc implementation a bit more standard compliant so it doesn't get killed for excess flood
[01:50] <stgraber> though ignoring all the langpacks definitely helped there :)
[01:50] <infinity> Yeah, there shouldn't be much call for rate-limiting most of the time.
[01:50] <infinity> langpacks are a bit special.
[02:36] <stgraber> infinity: implemented (watching all series)
[02:36] <stgraber> just need a restart to make sure it works (and flood the channel some more ;))
[02:37] <infinity> stgraber: Does it already do both NEW and UNAPPROVED?
[02:37] <infinity> stgraber: I've never paid attention.
[02:37] <stgraber> infinity: it can, but it's currently restricted to Unapproved
[02:38] <infinity> stgraber: I'm guessing from the interleaved output there that you went multithreaded?
[02:38] <infinity> stgraber: Looks good.
[02:39] <stgraber> infinity: nope, single thread but once the set is built it's sorted by package name, that's why series are mied
[02:39] <stgraber> *mixed
[02:39] <infinity> Ahh.
[02:40] <stgraber> I guess it'd make sense to change the order to first sort by series, then pocket, then package name, but it's only really useful when I get the bot to print everything at once
[02:40] <infinity> Yeah, printing everything at once shouldn't be a common use-case. :P
[02:41] <infinity> Unless you want to implement /msg ...
[02:41] <infinity> At which point, I think we're missing the point of the bot. ;)
[02:42] <stgraber> right :)
[02:43] <stgraber> I've also started implementing the ISO tracker api in the bot so it can show in #ubuntu-release and #ubuntu-testing when a new build is published during milestone testing
[02:43] <stgraber> as the builds are automatically published from nusakan that should be useful for both the release team and testers
[02:44] <stgraber> but I need to cleanup the code a bit first to properly handle that... ideally keeping the code somewhat readable
[03:03] <stgraber> infinity: I have a version of the bot now monitoring both Unapproved and New for all supported releases
[03:04] <stgraber> infinity: http://paste.ubuntu.com/901523/
[03:06] <stgraber> I think I'll need to add some logic to the bot to figure out if it's source or binary New and change what it shows
[03:06] <infinity> stgraber: You can probably 's/ package//' from that to make the lines a bit shorter, but otherwise awesome.
[03:06] <stgraber> as showing /none and non-existent => <version> is a bit pointless :)
[03:06] <infinity> stgraber: And yeah, could do "New (source)" or "New (amd64)", etc.
[03:07] <infinity> stgraber: And the bits you mentioned too.
[03:20] <stgraber> infinity: http://paste.ubuntu.com/901540/
[03:22] <infinity> stgraber: The anal retentive alignment freak in me wants to point out that if you remove the brackets from binary and source, it'll align perfectly with Unapproved. :P
[03:25] <stgraber> oh, weird I didn't notice... /me fixes ;)
[03:26] <infinity> stgraber: I guess it's also collapsing multiple binNEW entries into one?
[03:26] <infinity> stgraber: (There are 3 for slphone right now, but only one on your list)
[03:27] <stgraber> yeah, launchpad apparently does that for me
[03:27] <stgraber> infinity: http://paste.ubuntu.com/901546/ <-- there, properly aligned now ;)
[03:27] <infinity> Pretty!
[03:27] <infinity> Shame about the collapsing behaviour.  Means we can't watch all 5 arches trickle in, we'll only know about the first.
[03:28] <infinity> But it's still a good enough cue to go watch the queue.
[03:28] <infinity> Which is mostly what I want it for.  I always forget to poll NEW, and end up surprised when there's 5-day-old binNEW stuff in there.
[03:29] <stgraber> hmm, actually I might be able to separate the architectures looking at .display_arches
[03:30] <micahg> ubuntu studio needs their default-settings-package above in and respun with it (can wait if other fixes are needed to be respun with it)
[03:30] <micahg> s/default-settings-package/-default-settings package/
[03:30] <infinity> micahg: Will review shortly.
[03:31] <micahg> infinity: thanks, do you need a pad update?
[03:31] <stgraber> oh, sweet, display_arches actually tells you if it's a source upload or a sync too
[03:31] <infinity> stgraber: Interesting.
[03:32] <infinity> micahg: If studio's already been respun today, I'll just do it again.
[03:32] <micahg> infinity: thanks
[03:32] <skaet> infinity,  ubuntustudio's just emerging now,  so a respin will be necessary
[03:32] <infinity> Hahaha, indeed, it's actually building as we speak.
[03:32] <infinity> TIMING.
[03:33] <infinity> I'll kick off another build before I go to bed. ;)
[03:33]  * skaet nods...
[03:33]  * skaet likes stgrabers changes in the paste.bin too.  :)
[03:33] <micahg> skaet: I won't be able to get to the onboard fix for xubuntu until the morning, the fix isn't needed for ubuntu or edubuntu, but they'd pick it up if they were respun afterwards
[03:35] <skaet> micahg, please update the pad then, and we'll pick it up/respin as necessary.
[03:35] <micahg> skaet: it wasn't on the pad to begin with
[03:36] <skaet> micahg,  s/update/add it to/ :)
[03:36] <micahg> I can add it though :)
[03:37] <stgraber> skaet, infinity: http://paste.ubuntu.com/901559/
[03:37] <stgraber> I simply added "(sync)" at the end if it's a sync, not sure if we want it more visible than that (it doesn't matter so much I guess)
[03:38] <infinity> stgraber: My alignment!
[03:38] <stgraber> or I could make it "Unapproved sync"
[03:38] <stgraber> infinity: you can't have both the architecture and your alignment ;)
[03:39] <infinity> stgraber: s,binary (amd64): wesnoth-1.10,binary: wesnoth-1.10/amd64,'
[03:39] <skaet> stgraber, looking lovely to me.   :)   lots of lovely info without having to go look up.
[03:39] <infinity> stgraber: Keeps source packages aligned with each other. ;)
[03:40] <stgraber> infinity: true but then the format is no longer consistent :)
[03:40] <infinity> stgraber: Well, there only one case that shows arch, it's never consistent.
[03:40] <infinity> there's...
[03:41] <infinity> stgraber: The perhaps more LP-consistent place to show it would be in the dist/comp brackets (maverick-backports/universe/amd64)
[03:42] <infinity> But it's less immediately obvious there than it is tacking it right after the source package.
[03:42]  * infinity shrugs.
[03:42] <infinity> I'm picky about quickly parsable data. ;)
[03:42] <infinity> (And slightly dyslexic)
[03:42] <micahg> infinity: what do you think of me seeding mousetweaks in xubuntu for beta 2 vs this onboard bug fix
[03:43] <stgraber> current format is basically: <queue> [<entry type>]: <pkg_name> (pkg_pocket[/<current_component>]) [current_version => pkg_version] (pkg_pkgsets) [(sync)]
[03:43] <infinity> micahg: I'm completely not caught up on what's up with onboard.
[03:43] <micahg> infinity: without mousetweaks it seems to barf without unicode encoding
[03:43] <stgraber> infinity: but yeah, moving the architecture after the binary package name should be fine :)
[03:43] <micahg> trunk was fixed to use unicode encoding, there's a point release in progress that will include that fix amongst others
[03:44] <infinity> stgraber: Yeah, I'd just make that <pkg_name>[<arch>], and pull arch out of entry type, but again, I'm dyslexic, every bit of alignment helps me track.
[03:45] <infinity> micahg: Not something you can easily backport/cherry-pick?
[03:45] <infinity> micahg: I don't like the idea of seeding packages as a workaround on our last Beta before release.  It's not a particularly good way to represent the final product.
[03:45] <micahg> infinity: there is a fix and it looks innocuous enough, but as there seems to be a less risky fix...
[03:45] <infinity> micahg: (And means anyone installing with Beta keeps mousetweaks FOR EVA)
[03:46]  * micahg wonders if apt-get autoremove would DTRT once it's unseeded
[03:46] <infinity> No.
[03:46] <infinity> Not unless we changed something recently.
[03:47] <micahg> ok, I"ll try try to fix the patch in the morning, it doesn't apply cleanly ATM
[03:47] <infinity> Either way, I'd still prefer to look at the cherry-pick, since that represents what the actual fix will be before final, right?
[03:47] <stgraber> infinity: http://paste.ubuntu.com/901570/
[03:47] <micahg> infinity: http://bazaar.launchpad.net/~onboard/onboard/0.91/revision/764
[03:47] <infinity> stgraber: <3
[03:47] <infinity> stgraber: You just couldn't live with source/arch, could you? ;)
[03:48] <stgraber> infinity: no, wasn't consistent with the other messages ;)
[03:49] <infinity> micahg: Looks remarkably straightforward.
[03:49] <micahg> infinity: right :)
[03:49] <infinity> There really needs to be a way to just tell python "all strings are unicode unless I cast them differently".
[03:50] <infinity> Having to cast it for every string is ridiculous.
[03:50] <micahg> infinity: you could try to PEPify that
[03:50] <infinity> Ew, no.
[03:50] <infinity> I'll just use C, like a sane person.
[03:50] <infinity> And stop worrying about high level laguages only holding my hand sometimes.
[03:51] <infinity> languages, too.
[03:51] <infinity> GIVE ME POINTER ARITHMETIC OR GIVE ME DEATH.
[03:52] <infinity> stgraber: Actually, to be consistent with other messages, I'd say the arch should be in square brackets, like the version is. ;)
[03:52] <infinity> stgraber: (I may just be messing with you now)
[03:52] <infinity> stgraber: It looks like a drastic improvement.
[03:54] <skaet> I'm just looking forward to it rolling out...  and seeng the first message sow up.  :)
[03:54] <stgraber> infinity: square brackets actually sounds like a good idea ;)
[03:54] <infinity> Well here, have some messages.
[03:54] <stgraber> infinity: would match the syntax used for Depends:
[03:54] <infinity> stgraber: That too, yeah.
[03:55] <skaet> *\o/*
[03:56] <stgraber> square brackets upgrade ^
[03:56]  * infinity hugs queuebot.
[03:57] <stgraber> btw, why do we have new source packages in oneiric-proposed and oneiric-release?
[03:57] <jbicha> the gnome:NextVersion thing didn't work right with gnome-shell, it's trying to depend on libmutter0 (>= 3.3), libmutter0 (<< 3.4)
[03:58] <infinity> stgraber: NEW in proposed isn't unheard of.
[03:58] <infinity> stgraber: NEW is release, let me look.
[03:58] <infinity> stgraber: partner.
[03:59] <stgraber> ah, that'd explain it indeed
[03:59] <infinity> stgraber: The bot not showing component for source new would be why we didn't notice. :P
[03:59] <skaet> infinity,  I'm reading the backscroll right in that when ubuntustudio-defaults-settings finishes building, a respin of ubuntustudio is being looked for?
[04:00] <stgraber> I ignored the component for new source uploads as it'll default to universe for everyone, but apparently we're using it for patner, so I probably should show it anyway then
[04:00] <infinity> stgraber: Actually, it shouldn't default to universe for EVERYTHING.
[04:00] <infinity> stgraber: non-free maps to multiverse, and multiverse and restricted are left alone, if I recall.
[04:00] <infinity> stgraber: Just that things that don't declare a component end up in universe.
[04:01] <infinity> skaet: It's already done building, but when it's published in ~20 minutes, yeah.
[04:02] <skaet> infinity, ok,  wubi's just about done, so that should line up nicely.   Sticking it on the pad.
[04:02] <infinity> skaet: Pad away, if you want to drive, I'll wash my hands of it, then. ;)
[04:02] <infinity> I was going to just be a rebel and spin it when you weren't looking. :P
[04:03] <skaet> infinity,  if you're feeling rebelious,  I can go to bed.  ;)
[04:03] <infinity> skaet: Works for me.  I'm up for a while.
[04:04] <skaet> infinity,  coolio.   Will ping you when the wubi's done and you can kick it when it comes out of the publisher.
[04:13] <infinity> stgraber: No new queuebot with source components?  Did bed happen? ;)
[04:16] <stgraber> infinity: it's actually tricky to implement ;)
[04:16] <infinity> stgraber: Oh.  I figured it would be the same as unaproved.  Silly me. ;)
[04:17] <stgraber> nope, for anything that's been published once, getPublishedSources will give me the data
[04:17] <stgraber> but for something that never was published I still haven't found a way to get it
[04:17] <infinity> Ahh.  The queue entry itself has no hint?
[04:17]  * infinity wonders where the web UI is pulling it from.
[04:18] <stgraber> no, the queue entry is pretty limited: https://launchpad.net/+apidoc/devel.html#package_upload
[04:18] <stgraber> I guess I could use archive_link which should work for partner
[04:22] <infinity> I'm guessing source_package.latest_published_component_name is nothing for NEW sources?
[04:23] <stgraber> well, for that you'd need a source_package record
[04:23] <skaet> infinity,  typo on the wubi build,  exec: 111: cron.wub: not found *sigh*
[04:23] <infinity> skaet: *slow clap*
[04:24] <infinity> skaet: I can just do that with ubuntustudio. :P
[04:24] <stgraber> 04:23 -queuebot42:#stgraber-release- New source: swauth (oneiric-proposed/primary) [1.0.2+git20111128-0ubuntu1.1]
[04:24] <skaet> infinity,  do you want me to kick it off again now, or you want to fit it in with  ubuntu-studio.
[04:24] <stgraber> 04:23 -queuebot42:#stgraber-release- New source: jonas-full-5.2 (oneiric-release/partner) [5.2.1-0ubuntu1]
[04:24] <infinity> skaet: It already did the buildlive?
[04:24] <stgraber> infinity: that's what I have currently, basically showing the name of the archive instead of the component for new sources (so primary or partner)
[04:24] <skaet> infinity,  yup
[04:24] <skaet> kapok.buildd starting at Tue Mar 27 03:45:52 UTC 2012
[04:24] <skaet> cardamom.buildd starting at Tue Mar 27 03:45:52 UTC 2012
[04:24] <skaet> kapok.buildd finished at Tue Mar 27 04:17:01 UTC 2012 (success)
[04:24] <skaet> cardamom.buildd finished at Tue Mar 27 04:19:52 UTC 2012 (success)
[04:24] <infinity> stgraber: That'll have to do for now.
[04:25] <infinity> skaet: Kay, I'll finish up.
[04:25] <skaet> infinity,  thanks.
[04:27] <infinity> skaet: Done.
[04:27] <skaet> infinity,  on the arm builder side,  mx5/ac100 are just finishing up,  then its kubuntu's turn,  and that's about it.
[04:27] <infinity> skaet: Check.  I'm got IS working on some parallelisation love for me.
[04:28] <infinity> skaet: Probably won't have it before we're done with B2, but we should right after.
[04:28] <infinity> s/I'm/I've/
[04:29] <infinity> Though, I guess it is only Monday.
[04:29] <infinity> Maybe I can shake up the world before your last Beta spin. ;)
[04:29] <stgraber> skaet: I'll spend a few minutes tomorrow to have the bot also poll the ISO tracker for new milestone (non-daily) builds and announce them here + #ubuntu-testing
[04:29] <skaet> oooh,  stgraber that would be very nice indeed.   :)
[04:29] <infinity> stgraber: New builds in general might be nice, though with milestone versus daily tagging?
[04:30] <infinity> Or maybe that would seem too spammy.
[04:30] <infinity> We do build a lot of image.
[04:30] <infinity> images, too.
[04:30] <skaet> infinity,  fingers crossed for that parallelization.   :)
[04:30] <stgraber> infinity: yeah, turning it on for dailies too will be easy, but I suspect we don't want that kind of spam between milestones :)
[04:30] <infinity> skaet: Oh, it's GOING to happen.  Just not sure it'll be before your last spin on Wednesday/Thursday.
[04:31] <skaet> just hear from pgraner that the workaround seems to be effective,   so on that note of good news,  zzz time.
[04:31] <stgraber> infinity: having the bot read image build failures would be kind of nice though as not everyone receives the e-mails
[04:31] <infinity> Well, we can put the bot in the mail loop.
[04:31] <infinity> So it doesn't need to poll.
[04:32] <pgraner> all seems ok with light testing, QA will did deep in a few hours when europe comes online
[04:32] <infinity> pgraner: Sounds good.
[04:32] <pgraner> infinity, hasta get some rest
[04:33] <infinity> What is this "rest" you speak of? ;)
[04:33]  * skaet --> zzz  (can take a hint)
[04:34] <infinity> micahg: studio respinning now.
[04:56] <infinity> micahg: And done.
[05:08] <pitti> Good morning
[05:09] <pitti> kirkland: that script would also fit into update-manager, for example
[05:09] <knome> morning pitti
[05:10] <pitti> skaet: still there? I'm confused by the pad
[05:11] <infinity> pitti: What's the confusion?  *goes to look*
[05:11] <pitti> rebuild reasons 1, 6, and 13 do not exist in the list any more
[05:12] <pitti> but some images are still marked for rebuild
[05:12] <pitti> I look into the gnome-keyring FTBFS now, to unblock stgraber's fix
[05:12] <infinity> Well, everything was literally just respun.
[05:13] <infinity> So, I imagine she just didn't clear ac100/mx5 because they were in progress.
[05:13] <pitti> ah, ok
[05:13] <pitti> stgraber: ah, that timeout
[05:13] <pitti> stgraber: unfortunately we hit that sometimes, due to builders running very old kernels
[05:17] <infinity> pitti: Oh, I also just did studio.  Removed that trigger from the pad.
[05:18] <infinity> pitti: But yeah, I think the stale ARM ones on the pad are because she went to bed while the build was still running. ;)
[05:18] <infinity> pitti: If they all succeeded, that can be removed.
[05:18] <pitti> infinity: ack, thanks
[05:19] <infinity> Oh, crap, but the studio and wubi builds I did weren't run with the autopost environment.
[05:19]  * infinity sighs.
[05:19] <pitti> infinity: is that even necessary?
[05:19] <infinity> I don't know.  The pad implies such.
[05:19] <pitti> I forgot it as well the other day, and they were posted just fine
[05:19] <infinity> Maybe it lies.
[05:20] <pitti> if you confirm that as well, we can remove that from teh pad
[05:20]  * infinity looks.
[05:20] <infinity> yeah, the builds I just did autoposted.
[05:20] <infinity> That info is stale.
[05:20] <infinity> Delete away.
[05:21]  * infinity wanders off to do $something_else.
[05:22] <pitti> infinity: updated
[05:37] <pitti> gah, gnome-keyring hanging again; we need to find a buildd with a non-hardy kernel, it seems
[05:39] <slangasek> I wasn't aware that any of the distro buildds had hardy kernels?
[05:40] <infinity> Most of them do.
[05:40] <slangasek> hmm
[05:41] <slangasek> why is that?  I thought the distro builds were at lucid, and it was only the virtualized builders that were on hardy
[05:41] <pitti> I asked for cancelling them
[05:41] <pitti> but might get no response
[05:41] <pitti> it might be easier to do a no-change upload and assign thhem to zirconium and allspice manually
[05:41] <infinity> I don't know if any of the x86 ones are !hardy.
[05:41] <infinity> roseapple's one of the newest machines, and it's hardy.
[05:41]  * slangasek scratches his head
[05:41] <pitti> oh, I thought they were; darn
[05:42] <pitti> so we just need to keep retrying until they succeed, or disable the tests on amd64/i386
[05:43] <pitti> so, no response on launchpad-ops
[05:43] <pitti> I guess we are blocking new rebuilds on that, right? so want me to do a no-change upload?
[05:43] <pitti> hang on, got response
[05:45]  * ScottK just did a qwtplot3d upload.  It's unseeded universe.  I'd appreciate it if someone would wave it through when it appears.
[05:45] <ScottK> Thanks.
[05:45]  * ScottK tries to go to sleep (again).
[05:45] <pitti> *nod*, good night ScottK
[05:45] <ScottK> There it is.
[05:45] <ScottK> Thanks pitti.
[05:50] <infinity> pitti: zirconium and allspice are still hardy.  Are you just hoping that a slightly newer SRU rev will do it?
[05:50] <pitti> it's mostly just luck
[05:50] <pitti> it doesn't usually fail twice in a row
[05:50] <pitti> but now it does because we are waiting for it, and looking at it
[05:57] <pitti> both built now, *phew*
[05:57] <infinity> Special.
[05:57] <pitti> so I guess I'll do some respins once that's published
[06:01] <slangasek> so what changed to make g-k ftbfs on hardy kernels?  was it doing that before?
[06:03] <pitti> slangasek: it's a sheer matter of luck
[06:03] <slangasek> so this was a known problem before?
[06:03] <pitti> yes
[06:03] <pitti> it affects quite a few glib based packages, when they run tests
[06:03] <slangasek> alrighty
[06:04] <infinity> But it's definitely not reproducible on recent kernels?
[06:04] <pitti> nope
[06:04] <infinity> Yeah.
[06:04] <pitti> we never experienced it locally
[06:04] <infinity> Chalk up another argument for upgrading buildds.
[06:04] <pitti> and we never got it on arm builds
[06:04] <infinity> I'd rather fix the few packages that break for older releases than the other way around.
[06:05] <infinity> (And lp-buildd is already employing the uname-2.6 hack to minimise the worst damage that 3.0 kernels will bring to old releases)
[06:05] <infinity> Well, it would be employing it if it was running on precise. :P
[06:05] <infinity> But the code is there and tested and rolled out.
[06:06] <infinity> Hrm, I wonder if I should double the header in build logs to show both "real kernel version" and "kernel version reported to sbuild".
[06:35] <pitti> gnome-keyring is published; rebuild galore, I figure
[06:43] <pitti> image builds running, pad updated, time for breakfast
[06:43] <knome> bon appetit
[07:18] <cjwatson> stgraber: nice work on the bot!
[07:19] <cjwatson> infinity: python all strings unicode> that's what python 3's for ...
[07:20] <pitti> good morning cjwatson
[07:20] <cjwatson> pitti: um.  g-k hung reproducibly for me in a local sbuild, albeit in a different test, and also for stgraber.  have you tried it recently?
[07:21] <pitti> not 50 builds in a row or something such, just during normal package updates
[07:21] <cjwatson> I mean, aside from the builds that just succeeded. :)
[07:22] <cjwatson> I did wonder why we were a cycle back on g-k (and don't have the new split gcr), but I guess it's too late for that now
[07:22] <pitti> we did investigate a hang in glib's test suite which also used GIOChannels, and found that it was due to the hardy kernel; I never got the keyring one locally, so so far I could just assume it was a similar problem
[07:22] <pitti> cjwatson: LTS conservativism mostly
[07:22]  * cjwatson nods
[07:22] <pitti> cjwatson: g-keyring 3.4 got quite a dramatic rewrite in 3.4
[07:23] <pitti> and while it's mostly working, we did get some regressions; these should be fixed now, but still..
[07:24] <pitti> cjwatson: so, pad is up to date, respins are running for keyring
[07:25] <pitti> need to run out for 30 mins
[07:28]  * cjwatson hasn't really started yet, just looked in from phone
[07:28] <cjwatson> but baby is asleep \o/
[08:40] <cjwatson> stgraber: ^- "New: removed syslinux-legacy" should've had the arch names maybe?
[08:42] <Laney> haskell-yesod is the last of that stack
[08:42] <Laney> should allow the rest of those packages to be zapped
[08:42] <cjwatson> yeah, I was just looking
[08:42] <Laney> i'll do the partial removal bug later
[08:44] <cjwatson> stgraber: are you relying on http://people.canonical.com/~ubuntu-archive/queue/ in any way?  I guess not since it doesn't have precise.  I was wondering if we should decommission that
[08:44] <cjwatson> not as if it's up to date anyway
[08:45] <cjwatson> (it was always a pre-API hack anyway ...)
[09:03] <cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - wanna reseed a bunch of stuff before this falls out?
[09:31] <Daviey> cjwatson: yep!
[10:50] <bdrung> Laney: i commented bug #965659
[10:50] <ubot2> Launchpad bug 965659 in shunit2 "FFe: Sync shunit2 2.1.6-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/965659
[10:51] <Laney> bdrung: thanks, it was a gentle prod that the FFe was a bit bare :-)
[10:51]  * pitti accepts the GNOME 3.4 -proposed uploads
[10:51] <seb128> pitti, \o/
[10:56] <pitti> oh, it now shows SRUs, too
[10:56] <cjwatson> yep, stgraber had a hacking spree
[11:00] <Laney> what's the analog of http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt for ports?
[11:00] <cjwatson> s/testing/testing-ports/
[11:01] <Laney> ta
[11:01] <bdrung> can i sync eclipse 3.7.2-1 from Debian? according to upstream 3.7.2 is a maintenance release of the 3.7 branch.
[11:01] <Laney> shouldn't armel and armhf be switched there?
[11:02] <cjwatson> probably :)
[11:02] <cjwatson> I thought pitti said something about doing that
[11:02] <pitti> hm, I did switch it for _probs.html
[11:02] <pitti> apparently I missed a spot for outdate
[11:07] <ev> would someone on the release team please weigh in on whether they think bug 964508 is worth having in precise?
[11:07] <ubot2> Launchpad bug 964508 in whoopsie-daisy "whoopsie uploads crash reports, including core dumps, when on a 3G connection" [Medium,Confirmed] https://launchpad.net/bugs/964508
[11:08] <pitti> ah, all my rebuilds are done, updating pad
[11:11] <pitti> ev: responded in the bug
[11:11] <ev> pitti: any thoughts on a better way of handling that at_console bit, or is touch /var/run/console/whoopsie the best way forward?
[11:11] <ev> and cheers!
[11:22] <pitti> ev: oh, I haven't looked at the patch, just at the description
[11:22] <pitti> bbl, lunch
[12:24] <pitti> ev: eww -- can't we just fix NM's dbus policy to also allow root?
[12:59] <ev> pitti: it's not running as root
[12:59] <ev> it's running as the unprivileged whoopsie user
[13:00] <ev> running as root will work just fine, but keeping root around just so we can use nm over dbus is a bit scary.
[13:00] <ev> ah, just saw your comments in the bug
[13:11] <stgraber> good morning
[13:12] <stgraber> cjwatson: the new bot is using the LP API directly
[13:13] <stgraber> indeed showing the architecture on removal of a binary package would make sense, I'll fix that one quickly
[13:13] <cjwatson> OK, I'll nuke the old queue view then
[13:19] <cjwatson> old queue view is gone
[14:09] <skaet> good morning pitti, cjwatson
[14:10] <skaet> thanks for the updates to the TechnicalOverview last night scott-work!   looks good.  :)
[14:10] <stgraber> cjwatson: ^ happy with the new removal message?
[14:14] <cjwatson> stgraber: great, thanks
[14:14] <Laney> can it show seeds too, or would that be too much?
[14:15] <skaet> cjwatson,  any new fixes beyond the server ones looming on the horizon?
[14:15] <cjwatson> it'd have to be germinate output not seeds
[14:16] <Laney> yeah, transitively
[14:16] <Laney> and supported
[14:16] <cjwatson> skaet: I'm not aware of anything just at the moment
[14:17] <Laney> tumbleweed generates that data i think, if it's not in machine-readable form elsewhere
[14:17] <skaet> Laney,  did you see the version in the backscroll (ref's to core, edubuntu, etc.)?
[14:18] <Laney> skaet: yes, I see packagesets in there
[14:18] <skaet> Laney,  okie.  :)
[14:19] <Laney> http://qa.ubuntuwire.org/ubuntu-seeded-packages/seeded.json.gz
[14:24] <jibel> ltsp is broken. Client session doesn't start
[14:25]  * stgraber is looking into it
[14:26] <stgraber> install is running now, should know more in 10-15min
[14:26] <skaet> pitti,  release note https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/963470?
[14:26] <ubot2> Launchpad bug 963470 in compiz "[regression] Unity 5.8+Compiz 0.9.7.2: Pressing Super+Tab or Super+W works, but unity does not respond to when Super is released." [High,Fix committed]
[14:27] <skaet> or should we try for a cherry pick?
[14:28] <stgraber> jibel: FWIW, I'm also doing a quick ltsp-live check to see if it's limited to alternate or also applies to Edubuntu
[14:30] <tumbleweed> skaet, Laney: lp:~stefanor/+junk/ubuntu-seeded-packages
[14:30] <Laney> ty
[14:31] <tumbleweed> reads germinate output for supported seed, and manifests+lists for ISO contents
[14:32] <Laney> how often is it regenerated?
[14:32] <tumbleweed> hourly
[14:35] <cjwatson> bug 963471 makes me suspicious
[14:35] <ubot2> Launchpad bug 963471 in debian-installer "Not all OS shown in grub-install screen at end of installation" [Undecided,Incomplete] https://launchpad.net/bugs/963471
[14:35] <cjwatson> something dodgy going on with FUSE there I think
[14:37] <cjwatson> oh, bah, no, it's much more prosaic than that, os-prober is trying to use which
[14:38] <cjwatson> boo
[14:39] <skaet> ogasawara, apw - is there an ETA on a cherry pick fix to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961482?
[14:39] <ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Confirmed]
[14:39] <ogasawara> skaet: there's one in the works right now, just needs testing
[14:40] <ogasawara> skaet: if it were possible, I would like to get it in for Beta-2, but the window for uploading is slowly closing in on us
[14:41] <skaet> ogasawara, yes, indeed.   how widespread is it?
[14:42] <cjwatson> oh, but I'm going to need a grub2 upload as part of 963471, so that'll have to be post-beta
[14:42] <ogra_> geez, the slideshow is pretty slow on arm
[14:42] <skaet> cjwatson,  ack.
[14:43]  * ogra_ wonders if he will actually see the end before the install is done
[14:43] <ogra_> hmm, no, only three slides
[14:43] <skaet> ogra_ know if there's any progress on: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/963512
[14:43] <ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed]
[14:44] <ogra_> skaet, oh, i didnt know about that one
[14:44]  * ogra_ checks
[14:45]  * ogra_ goes to ask paolo ... 
[14:45] <ogra_> it seems ot not affect everyone
[14:46] <ogra_> skaet, paolo says he has a new kernel ready by tonight
[14:47]  * ogra_ sighs that people dont subscribe ubuntu-arm to bugs anymore and subscribes to the linux-ti-omap4 package 
[14:48] <skaet> thanks ogra_.  tonight in Europe?  ie.  am wondering if we can get the full set of respins with the kernels that fix both of these problems.
[14:48] <ogra_> well, we only need to respin omap4
[14:48] <stgraber> jibel: unable to reproduce on Edubuntu with ltsp-live, alternate install is finishing now
[14:48] <ogra_> thats only two images ... we would have to skip netboot then though
[14:49] <ogra_> but i think we can live with it
[14:49] <ogra_> infinity, ^^^ any opinion ?
[14:51] <skaet> ogra_, kubuntu is also an omap4 one.
[14:51] <ogra_> does anyone test that ?
[14:52] <skaet> Riddell, ^ ?
[14:52] <ogra_> skaet, "<ppisati> ogra_: in a couple of hours"
[14:52] <skaet> ScottK, ^ ?
[14:52] <ogra_> that should suffice to get images ready tomorrow
[14:52] <phillw> I have amd 64 of ubuntu & lubuntu, I can zsync up one for kununtu if you need a tester.
[14:53] <ogra_> phillw, arm
[14:53] <ogra_> do you have arm HW ?
[14:53] <phillw> sorry, no.
[14:53] <Riddell> ogra_: GrueMaster has previous tested kubuntu arm images but I believe won't be doing so any more
[14:53] <ogra_> right
[14:53] <skaet> thanks phillw,  there will be an amd64 kernel showing up a bit later too (me crossing fingers),  so testing of that will be welcome.  :)
[14:54] <ogra_> i belive he wont be doing any testing anymore
[14:54] <Riddell> I can test but I am quite certain it'll fail for me like every other precise image
[14:54] <ogra_> Riddell, see the bug above :)
[14:54] <ogra_> with that fix you should also see output on HDMI
[14:55] <Riddell> ogra_: and that's the comment above from ppisati about in a couple of hours?
[14:56] <ogra_> Riddell, right, he will upload in a few hours, kernel should eb ready by tomorrow so we can have new images with the output fixed
[14:56] <Riddell> tomorrow will be a another sunny day if that works :)
[14:57] <ogra_> :)
[14:59] <pitti> skaet: I agree, it's far from critical
[14:59] <pitti> skaet: will add it, thanks
[15:03] <pitti> skaet: done
[15:10] <skaet> thanks pitti.
[15:15] <stgraber> skaet: tracked down bug 966267 to a race between plymouth and X causing X to explode if the user presses <enter>
[15:15] <ubot2> Launchpad bug 966267 in ltsp "client session doesn't start" [Undecided,New] https://launchpad.net/bugs/966267
[15:16] <stgraber> skaet: it's most likely LTSP's fault for not killing plymouth properly, I'm looking at it now
[15:16] <stgraber> skaet: the bug affects Ubuntu alternate and Edubuntu on both amd64 and i386
[15:19] <ogra> hmpf ... g-s-d just died in my fresh install
[15:20] <stgraber> skaet: I'm hoping to have a tested fix within the next hour
[15:25] <micahg> skaet: I have the onboard fix, but it's untested I was going to upload it and ask xubuntu people to test and let someone know in here if it works, sound ok?
[15:28] <skaet> stgraber,  sounds good.    will keep those in mind for the respins.   Will probably wait to pick up kernel (if possible) before triggering.   If you want just one though to verify out the fix, can do.
[15:28] <skaet> micahg, sounds good.
[15:28] <ogasawara> skaet: we have a fix available (just unconfirmed via testing), but it's been sent to upstream stable already.  I'm inclined to upload as I think 961482 will affect quite a few systems and seeing as they're already rendered unbootable, it can't get much worse.
[15:29] <stgraber> skaet: this fix is in LTSP itself so it's easy to test without reinstalling (for once ...)
[15:29] <skaet> ogasawara, agreed.
[15:29] <ogasawara> skaet: ack, I'll prep an upload with just that fix.
[15:30] <skaet> ogasawara, is there an ETA on ppsati's fix for omap4?
[15:31] <ogasawara> skaet: he was mentioning earlier that he said he'd have a fix by EOD
[15:32] <skaet> ogasawara, Europe EOD or North America ?  ;)
[15:32] <ogasawara> skaet: that he didn't clarify, but I'm assuming Europe
[15:34] <ScottK> http://dissociatedpress.net/2012/03/27/ubuntu-were-not-linux/
[15:34] <skaet> ogasawara, that would be my hope as well. :)
[15:51] <ogasawara> skaet: ppisati has just sent the pull request to the list for omap4, tgardner should upload shortly
[15:54] <skaet> ScottK,  thanks for flagging.   Will put an editorial eye on the wording of this one to avoid feeding that flamefest.
[15:54] <skaet> s/this one/beta 2 TechnicalOverview/
[16:01] <stgraber> skaet: ltsp uploaded, test verified here and by jibel
[16:05] <skaet> stgraber,  :)
[16:05] <skaet> ogasawara, goodness.
[16:14] <ogasawara> skaet: omap4 kernel uploaded, could we get it approved in the queue?
[16:14] <ppisati> ogasawara: you were faster than me :)
[16:15] <skaet> ogasawara, ppisati - just waiting for the diff to generate.  :)  looking at it now.
[16:18] <apw> the diff will likely scare you to death :)
[16:19] <apw> ppisati, that upload is basically a revert to the known good kernel right ?
[16:20] <ppisati> right
[16:26] <skaet> cjwatson,  could you look at the update-manager one in the unapproved queue.   Seems its picked up lots of changes based on the diff,  ok to pull into the respins?
[16:27] <skaet> Daviey,  couold you look at the OpenMPI one - do you want it?
[16:28] <cjwatson> skaet: on the phone, sorry, what are the impending respins?
[16:28] <cjwatson> well s/phone/G+/
[16:29] <skaet> cjwatson,  fair enough.  we'll be waiting for kernel rebuilds so there's time.   its the update-manager am not sure if we should pick up or not.  in unapproved-queue.   (powerpc changes, and some others...)
[16:29] <pitti> skaet: I can also look at u-m
[16:29] <cjwatson> off G+ now
[16:29] <pitti> skaet: but I wasn't aware we'll respin again?
[16:30] <ogra_> omapr4
[16:30] <cjwatson> if we take update-manager we should take python-apt too; not that it's required, but that way it will actually fix a bug
[16:30] <ogra_> *omap4
[16:30] <cjwatson> most of the changes in u-m are a routine mirrors update, and harmless
[16:30] <cjwatson> wait that's python-apt I think, let me check
[16:30] <infinity> skaet: The update-manager PPC changes are just because it includes an embedded copy of base-installer.
[16:30] <cjwatson> right, yeah, that's normal
[16:30] <cjwatson> demoted.cfg is syncing with state of archive
[16:30] <skaet> okie
[16:31] <cjwatson> mirrors.cfg is syncing with data from real world
[16:32] <skaet> pitti, am assuming that was you accepting things into -proposed?   basically ok to accept anything there now,  since only changes we'll be applying to the release will be uploaded to -release?
[16:32] <infinity> skaet: That was me.
[16:32] <cjwatson> the https bit comes with tests
[16:32] <pitti> skaet: I was going to, but someone beat me to it
[16:32] <ogasawara> skaet: ^^ kernel uploaded, contains only the fix for 961482
[16:32] <cjwatson> yeah, u-m looks fine to me if we're respinning for a kernel anyway
[16:33] <skaet> thanks ogasawara
[16:33] <cjwatson> python-apt looks fine too
[16:33] <cjwatson> but we're not respinning all images, correct?
[16:33] <skaet> ogasawara those graphics drivers (nvidia, cedarview) you as well?
[16:33] <ogasawara> skaet: nope, not me
[16:33] <pitti> skaet: it's mostly the gnome 3.4.0 stuff, of which 90% of the chagnes are updated translations, and the rest stuff that made it through the pretty harsh  hard freeze break review
[16:33] <cjwatson> Daviey: what's "Hiding of tasksel when MaaS is selected"?
[16:34] <infinity> skaet: cedarview is Jani, I'm sure.  It'll need some careful review. :)
[16:34] <cjwatson> and are we intending to respin for bug 961482?
[16:34] <ubot2> Launchpad bug 961482 in linux "3.2.0-19 kernel fails to boot (-18 OK)" [Critical,Fix committed] https://launchpad.net/bugs/961482
[16:35] <infinity> cjwatson: I think that's the plan...
[16:35] <cjwatson> accepted update-manager and python-apt, then
[16:35] <infinity> cjwatson: We're respinning for an ARM kernel (including an ABI bump) anyway, so it's a scorched-earth respin, d-i and all.
[16:35] <cjwatson> whee
[16:36] <skaet> yup
[16:36]  * pitti scores them up, so that they go before the -proposed stuff
[16:36] <skaet> cjwatson, yes,  all of the ubuntu ones at least.   Some of the flavors have already requested respins based on other things, so we'll pick them up.
[16:36] <ogasawara> skaet: just got confirmation from an affected user that the patch resolves 961482
[16:36] <skaet> ogasawara, :)  thanks!   thats good news.
[16:37] <infinity> pitti: Shouldn't release have a higher score than proposed by default anyway?
[16:37] <pitti> not usually
[16:37] <pitti> well, devel should be >> devel-proposed
[16:38] <pitti> but stable-proposed >> devel, IMHO
[16:38] <infinity> Oh, I guess the scoring was based on the assumption that pockets are a post-release thing.
[16:38] <infinity> So maybe never took into account the idea that -release could still be open.
[16:39] <stgraber> pitti: btw, how did you get gnome-keyring to build? just hit retry until it worked or did you have to target specific buildds?
[16:39] <infinity> Let me aim these kernels at fast buildds.
[16:39] <pitti> cjwatson, skaet: bumped kernel, p-apt, u-manager
[16:40] <skaet> thanks pitt
[16:40] <pitti> stgraber: mostly, yes; with some help from launchpad-ops to kill hanging builds
[16:40] <skaet> thanks pitti,  even.
[16:40] <pitti> stgraber: they pretty much all run hardy kernels I was told, so the particular builder shouldn't matter; just a matter of luc
[16:40] <pitti> k
[16:40]  * skaet goes to update the pad to double check the builds/not for this afternoon.
[16:41] <stgraber> pitti: fun :)
[16:43] <infinity> There, kernels on roseapple and allspice.
[16:48] <skaet> Riddell,  ScottK,  do you want new images to pick up the new kernel(s) and update-manager fixes for Kubuntu?
[16:49] <skaet> scott-work,  do you want new images as well (kernel and update-manager fixes)?
[16:50] <skaet> astraljava, phillw - how about for lubuntu?
[16:50]  * ScottK hasn't been keeping track (busy with $work)
[16:51]  * skaet notes Edubuntu and Xubuntu already slated for respin, so they'll get them.
[16:51] <phillw> skaet: I've updated to lubuntu 20120327.1 But have been holding fire because of kernel issue.
[16:51] <skaet> phillw,  so am guessing you want the new kernel then... ;)
[16:51] <phillw> skaet: a working kernel is always nice :D
[16:52] <skaet> phillw,  ok,  I've marked it to the list.  :)
[16:53] <infinity> Given everything that was just let through in the name of respinning the world, we probably should just respin the world.  It's only Tuesday.
[16:55] <phillw> no objections from me (not that i count ;) )
[16:55] <skaet> infinity,  probably best at this point to keep it all consistent.
[16:55] <infinity> Ed Zachary.
[16:56]  * skaet was just wondering about how the testing is going. 
[16:56] <infinity> Good practice for final release, where consistent is a requirement, not a suggestion. :P
[16:56]  * skaet goes to google Ed Zachary
[16:57]  * infinity lets in pittit's "make accountservice mirror ubiquitty's new LC_ handling" bit.
[16:58] <pitti> infinity: ah, thanks; note that language-selector fixes the same thing, plus another bug
[16:58] <pitti> I didn't consider either critical for b2, so I didn't poke the channel about those
[16:58] <infinity> pitti: language-selector is just a dpkg-maintscript conffile handling change?
[16:58] <infinity> pitti: Or did you collide with Steve, and aren't aware?
[16:58] <pitti> infinity: oh, that's slangasek's
[16:59] <pitti> infinity: no, he committed to bzr just fine
[16:59] <pitti> so I uploaded a new version on top of his'
[16:59] <infinity> pitti: As in, just now?
[16:59] <pitti> infinity: so if you just want to let slangasek's in to fix conffile handling for upgraders, that also WFM
[16:59] <pitti> infinity: no, this morning, like 10 hours ago
[16:59] <infinity> pitti: Well, not sure where yours went. :P
[16:59] <infinity> pitti: Unless it was proposed.
[17:00] <phillw> I saw mention of bug 959224 earlier, is it due for fix this resin?
[17:00] <ubot2> Launchpad bug 959224 in choose-mirror "Corrupt value for /etc/apt/apt.conf accepted during installation" [Medium,New] https://launchpad.net/bugs/959224
[17:00] <pitti> infinity: oh, nevermind; I didn't upload it yet, just in bzr *blush*
[17:00] <infinity> pitti: *slowclap*
[17:00] <pitti> infinity: as I thought "no rush, can upload after b2 with potentailly more fixes"
[17:00] <infinity> pitti: Upload it, if it matches the LC_ fixes everywhere else, seems worth it.
[17:00] <pitti> infinity: anyway, slangasek's chagnes look fine, so if you are looking for good fixes to wrap into b2, that's ceratinly not the worst
[17:00] <infinity> pitti: We're waiting at least 4 hours or kernels anyway.
[17:00] <pitti> or need a package in main to refresh task headers or so
[17:01] <cjwatson> phillw: no
[17:01] <slangasek> my changes are all low-prio, I'm just picking things off the jenkins report
[17:01] <phillw> cjwatson: okies, thanks
[17:01] <infinity> slangasek: Yeahp, but low-prio on your maintscript changes also adds up to low impact, so I pick them up when I'm bored. :P
[17:01] <cjwatson> phillw: it doesn't have a fix yet, and is in any case not serious enough to merit a respin
[17:02] <slangasek> cjwatson: which reminds me; half the "obsolete conffiles" still listed on the jenkins reports are actually ones that have been taken over by replacing packages, so should fall out of 'obsolete' the next time the packages are upgraded, I think - is there really anything more we should be doing here? ...
[17:02] <slangasek> ... https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-server/ARCH=i386,LTS=lts,PROFILE=server,label=upgrade-test/68/artifact/lts-server/obsolete_conffiles.log
[17:03] <cjwatson> skaet: I suspect infinity means "exactly", rather than the rather unfortunate first google hit for "Ed Zachary" as such :)
[17:03] <slangasek> (console-setup, file, fuse, grub are all in this category)
[17:03] <cjwatson> slangasek: sounds like we should fix the autotester to notice that then?
[17:03]  * pitti off for a bit to prep dinner
[17:03] <cjwatson> I haven't been looking at obsolete conffiles at all, though
[17:03] <pitti> cjwatson: it does?
[17:04] <slangasek> cjwatson: prolly - just wanted confirmation you didn't think there was anything further we should do packaging side
[17:04] <pitti> they become yellow (i. e. tests failed, but upgrade succeeded)
[17:04] <skaet> cjwatson,  thanks.   was scratching my head a bit over that one.
[17:04] <cjwatson> pitti: I mean it should not even list cases where some other package has taken them over
[17:04] <pitti> ah
[17:05] <slangasek> pitti: well, things we don't care about at all should IMHO be green, not yellow :)
[17:05] <slangasek> (for whatever value of "don't care about" applies)
[17:05] <cjwatson> slangasek: I don't *think* so; in my head that's something Replaces should deal with
[17:06] <cjwatson> keyboard-configuration doesn't seem to do anything special to take over console-setup.conf
[17:06] <slangasek> yes
[17:06] <infinity> I thought Replaces did deal with it...
[17:06] <slangasek> and none of these conffiles are listed as "obsolete" on my system
[17:06] <cjwatson> remind me where the autotester moved to?
[17:06] <slangasek> so I *think* it gets flushed when you do a subsequent upgrade of the replaced package
[17:06] <cjwatson> sounds plausible, yes
[17:06] <slangasek> lp:auto-upgrade-testing
[17:07] <astraljava> skaet: I can't speak for lubuntu, but I'll ask around in the #xubuntu-devel. :)
[17:07] <cjwatson> ta
[17:12] <skaet> astraljava, thanks.  (and oops... sorry)
[17:15] <slangasek> cjwatson: confirmed; apt-get install console-setup --> obsolete, apt-get install --reinstall console-setup --> disappeared
[17:15] <slangasek> cjwatson: are you poing the auto-upgrade code?
[17:15] <ScottK> skaet: Did you get an answer from Riddell on respinning?
[17:16] <cjwatson> maybe something like http://paste.ubuntu.com/902501/
[17:16] <skaet> ScottK,  nope,  went ahead and scored them for respinning to keep things consistent.  But if you and he disagree,  please flag here and update the pad.
[17:16] <ScottK> No, I think that's reasonable.
[17:17]  * skaet nods
[17:17] <slangasek> cjwatson: LGTM
[17:18] <cjwatson> minor errors in that, testing/fixing
[17:25] <cjwatson> slangasek: is there a bug about this already?  (if not, don't worry)
[17:26] <slangasek> cjwatson: not AFAIK
[17:28] <cjwatson> slangasek: https://code.launchpad.net/~cjwatson/auto-upgrade-testing/obsolete-conffiles/+merge/99569
[17:35] <stgraber> ^ initial ISO tracker notification support
[17:37] <stgraber> (just a quick test)
[17:37] <stgraber> looks good so far
[17:38] <stgraber> I made it post queue status + iso tracker to #ubuntu-release and only iso tracker to #ubuntu-testing
[17:39] <skaet> stgraber,   excellent.   Looks very good indeed!  :)
[17:47]  * skaet figures it will get a work out this afternoon.
[17:54] <slangasek> cjwatson: merged, thanks
[17:54] <slangasek> cjwatson: oops, except not because I don't have commit access
[17:55] <cjwatson> ... I did wonder
[17:55] <slangasek> :)
[17:55] <slangasek> jibel: could ubuntu-dev or ubuntu-core-dev have commit access to lp:auto-upgrade-testing?
[18:05] <scott-work> skaet: does the new kernel include updating the lowlatency kernel?
[18:07] <scott-work> skaet: if not, then i don't think ubuntu studio needs to have a respin for beta 2
[18:07] <skaet> scott-work, haven't seen any updates to it, but not sure.
[18:13] <infinity> scott-work: It should, but no one's merged and uploaded it yet, no.
[18:15] <scott-work> skaet: infinity:  i guess a repsin will not hurt, so yes please :)
[18:16] <infinity> scott-work: Is the only person handling -lowlatency Luke?
[18:16] <skaet> scott-work,  ok.  will leave it on the list.
[18:16]  * infinity would merge and upload, but doesn't want the package to get out of sync with git.
[18:16] <scott-work> infinity: i believe the only person at this time handling -lowlatency is luke (although that is scheduled to change for q-cycle)
[18:17] <infinity> ogasawara: Would your minions be willing to update -lowlatency to match the base linux (assuming one or more of them has commit access?)
[18:17] <ogasawara> infinity: I don't think we have commit access
[18:17] <infinity> Dang.  We should fix that.
[18:21]  * infinity ponder just applying the tiny diff and letting Luke deal with the fallout later.
[18:23] <apw> can anyone confirm/deny if the backgrounds for OSD messages is meant to have changed colour in the stuff in the archive 'now' ?
[18:24] <infinity> apw: I'll answer your question if you update -lowlatency.
[18:24] <apw> thats a community kernel :)
[18:24] <infinity> apw: (The answer might be "I don't know", though)
[18:25] <apw> they promised they would be responsive ... whats its base ?
[18:26] <infinity> apw: They are responsive, it's only missing your latest -20.33 patch.
[18:26] <infinity> apw: And Luke's probably asleep. ;)
[18:30] <apw> any idea where the source even is?
[18:30] <apw> infinity, its a good job none of the CDs have the image on
[18:31] <infinity> apw: ubuntustudio does.
[18:31] <slangasek> git://kernel.ubuntu.com/abogani/ubuntu-precise-lowlatency.git
[18:31] <slangasek> (per the source package's Vcs-Git field)
[18:32] <infinity> Curious, I would have expected it to be Luke's, not Alessio's, given who does all the uploads.
[18:33] <slangasek> maybe the field's wrong, but that's what the package says
[18:34] <apw> if its that one, its based on -16.25
[18:34] <infinity> Yeah, it's not that one, then. :P
[18:34] <slangasek> right
[18:34] <infinity> Their current upload is -20.32
[18:34] <infinity> (Well, -20.28, but based on -20.32)
[18:35] <apw> hmmm ... fun
[18:36] <infinity> apw: Don't worry too much about it, I'm sure Luke will notice when he wakes up, I've already pinged him.
[18:36] <apw> ack
[18:55] <pitti> skaet: anything you need me to do tonight still? otherwise I'd say good night and be online again in ~ 10 h
[18:55] <skaet> pitti,  one last review of unapproved have what you want in the respin?
[18:56] <skaet> but then,  yes,  after that,  sleep well.  See you on the flip.
[18:57] <pitti> skaet: the only thing which might be worth considering is the new nvidia driver, but I don't have context
[18:57] <pitti> skaet: when in doubt, I'd keep it for post-b2
[18:57] <pitti> skaet: but it's  not on the ubuntu images anyway (only on ubuntustudio and mythbuntu)
[18:58] <skaet> pitti,  I'll dig it it a bit this afternoon, but generally post b2
[18:58] <pitti> the current one isn't terribly broken, so I'd rather have people update post-b2
[18:58]  * skaet nods
[19:00] <pitti> skaet: so in summary, nothing that I deem worthy and safe enough to take into b2 at this point
[19:00] <skaet> THanks pitti.  sleep well.
[19:00] <pitti> ok, see you tomorrow!
[19:01] <skaet> good night.
[19:01] <skaet> :)
[19:03]  * skaet needs to break to go out for lunch,  seems a good time while builds are stil happening.
[19:12] <skaet> yup,  linux still has to get through the arm builders...  :/
[19:13]  * skaet --> lunch
 linux? you mean the ubuntu kernel? </troll>
[19:19] <Daviey> cjwatson: Sorry, just saw your question.. When option 2 from the cd menu is selected, now show tasksel
[19:20] <cjwatson> OK, I assume you'll fix that in maas-enlist-udeb?
[19:20] <Daviey> cjwatson: yep
[19:21] <Daviey> cjwatson: been sorting out rabbitmq first.
[19:26] <cjwatson> 'db_set tasksel/first "standard, server"; db_fset tasksel/first seen true' or some such, I guess
[19:26] <cjwatson> may have the value wrong
[19:30] <Daviey> cjwatson: is it "server" or "Basic Ubuntu Server" ?
[19:33] <scott-work> infinity: skaet : if getting the -lowlatency kernrel updated is putting the ubuntustudio images out of sync (or cadence) with other images then this may be too much trouble at this point for a beta 2
[19:34] <cjwatson> Daviey: definitely not the latter, use the identifier not the display name
[19:34] <scott-work> the current beta 2 images didn't include any critical bugs
[19:34] <infinity> scott-work: Nah, it's no big deal.  The kernel being out of sync won't kill anyone.
[19:34] <infinity> scott-work: Would just have been nice to have it updated to match, that's all.
[19:39] <Daviey> cjwatson: ok
[19:44] <Daviey> cjwatson: looks like, tasksel/first "standard, ubuntu-server"
[19:46] <Daviey> scrub that.
[19:57] <Riddell> skaet: evening, did I hear a respin was doine?
[20:00] <phillw> Riddell: I believe they're waiting for the kernel to get through re-building, then yes - respins are due.
[20:01] <cjwatson> will need a new d-i in between
[20:18] <jibel> slangasek, I added ubuntu-core-dev. The admin of the team should have received an invite.
[20:19] <stgraber> jibel: I'll take care of it
[20:20] <stgraber> jibel: accepted
[20:27] <jdstrand> skaet: hey, what project do I use to file a bug to make sure a release note is added?
[20:29] <stgraber> jdstrand: https://bugs.launchpad.net/ubuntu-release-notes
[20:30] <jdstrand> stgraber: thanks
[20:44] <infinity> stgraber: Hrm, queuebot seems to get confused when binary NEW contains translations, and calls it source.
[20:45] <infinity> (see above with linux-ti-omap4)
[20:48] <stgraber> infinity: LP is confused ;)
[20:49] <stgraber> infinity: let me check how I can detect these reliably
[20:49] <Daviey> Pleae can, cobbler, maas and maas-enlist be accepted please.
[20:50] <Daviey> beta-2 critical
[20:51] <infinity> Daviey: Done.
[20:51] <Daviey> thanks
[20:53] <stgraber> infinity: ^ it "should" now be translation aware
[20:53] <infinity> stgraber: Cool.  We'll find out next time it pops up.
[20:54]  * skaet sees arm still building for linux... :P
[20:55] <infinity> PPC just finished, though.
[20:55] <infinity> Barely winning the race. ;)
[20:55] <infinity> (ARM's nearly done too)
[20:55] <infinity> But we'll need to iterate through some d-i uploads and such.
[20:55] <infinity> And we need a new ti-omap4 meta.
[20:56] <infinity> ogasawara: ^
[20:56] <stgraber> skaet: is anything already building? if not, we have a few interesting fixes in ubiquity, none that are critical though (one is oem critical but I was told it can wait till Friday)
[20:56] <infinity> ogasawara: I get in trouble when I upload meta without committing, so if you could? ;)
[20:56] <ogasawara> infinity: yep, gimme 2min
[20:56] <infinity> stgraber: Nothing should be building right now, we're still waiting on kernels and moving to d-i, etc.
[20:56] <stgraber> infinity, skaet: ok, do we want a new ubiquity then?
[20:57] <infinity> stgraber: If it's 100% regression-free!
[20:57] <stgraber> http://paste.ubuntu.com/902845/
[20:57] <stgraber> bug 963460, bug 964472 and bug 950282
[20:57] <ubot2> Launchpad bug 963460 in language-selector "Ubiquity calls check-language-support with "zh-hans" instead of a locale (zh_CN)" [Medium,Fix committed] https://launchpad.net/bugs/963460
[20:57] <ubot2> Launchpad bug 964472 in ubiquity "'Detect Keyboard Layout' detects the 'group' correctly, but does not update the selectable layout list" [Medium,Fix committed] https://launchpad.net/bugs/964472
[20:57] <ubot2> Launchpad bug 950282 in oem-priority/precise "Installation failing with pop-up "The installer encountered an unrecoverable error and will now reboot."" [Critical,Confirmed] https://launchpad.net/bugs/950282
[20:57] <infinity> Oh, I dunno about skaet, but I'd kinda like those fixes.
[20:58] <skaet> stgraber,  what infinity said...  :) regression free welcome.
[20:58] <ogasawara> infinity: that had an abi bump right?
[20:58] <infinity> Testing all the changed keyboard/language handling stuff we've been messing with more widely would be good.
[20:58] <infinity> ogasawara: Yep.
[20:59] <infinity> stgraber: I say go for it, unless skaet objects strongly.  I really don't want all this lang mangling to bite us on release week if it's subtly wrong.
[20:59] <skaet> infinity, see ^ comments.  ;)
[21:00] <stgraber> infinity: I'm running it through the tests now, will read through the code again and will upload, eta 10min (it needs to build all d-i components for the tests ...)
[21:02]  * infinity goes to mangle seeds and d-i for the omap4 ABI bump.
[21:02] <ogasawara> infinity: uploaded
[21:02] <infinity> ogasawara: \0/
[21:02] <infinity> \o/ too.
[21:02] <infinity> I need new fingers.
[21:03]  * skaet wonders where she can sign up for those new fingers ;)
[21:04] <skaet> s/those/some/ ... too.
[21:12] <infinity> ^-- don't accept this d-i upload until all the kernels are published (I'll keep an eye on that).
[21:12] <stgraber> ubiquity uploaded
[21:12] <infinity> Oh, nice, omap kernels finished building just before the publisher started.
[21:13] <infinity> So, d-i can build in about 20 minutes.
[21:13] <stgraber> the diff should be easy to read except for the usual ubiquity-2.10.4/d-i/source/tzsetup/debian/common.templates changing for no good reason
[21:13] <infinity> Heh.
[21:13] <stgraber> cjwatson: do you have any idea why pretty much everytime I upload after you I get a delta in d-i/source/tzsetup/debian/common.templates ?
[21:14] <infinity> Different versions of intltool/po-*?
[21:14] <stgraber> cjwatson: I always clean the branch entirely (as in, remove any ignored file), then run debian/rules update to get a clean copy of d-i/source
[21:15] <stgraber> infinity: well, it's ubiquity's embedded source copy, so nothing should touch these...
[21:15] <infinity> stgraber: You sure it didn't also change in tzsetup itself?
[21:16]  * infinity grumbles about the appservers getting behind on diff generation.
[21:16] <stgraber> infinity: well, then we'd have a change in d-i/source/tzsetup/debian/changelog too...
[21:17] <infinity> stgraber: Oh, fair point.  Well, maybe something in ubiquity's clean walks d-i/source and mangles all the translations?  Dunno.
[21:17] <infinity> stgraber: Or maybe it just dislikes you specifically.
[21:17] <stgraber> infinity: could be that ;)
[21:21]  * infinity wishes there would be a bunch of gcc-4.7, kernel-team PPA, and golang-tip uploads all at the same time while we're trying to get things built for Beta.
[21:21] <infinity> Oh, wait.  Yay.  I got my wish.
[21:21] <stgraber> ;)
[21:22] <infinity> stgraber: Will review and accept ubiquity in ~5 minutes when LP catches up with me, and then I'll jam it down the buildds' throats as best I can. :P
[21:22] <micahg> infinity: I can upload more random stuff if you like :)
[21:23] <infinity> micahg: Sure.  Chromium, Firefox, Thunderbird, and OpenOffice, please.
[21:23] <infinity> micahg: Ideally security releases that firebomb 5 releases and eat every builder.  Thanks in advance.
[21:23] <Daviey> skaet: Are you spinning all flavours soonly, or should i trigger a server one now?
[21:23] <infinity> Daviey: We're rebuilding d-i.
[21:23] <skaet> Daviey,  wait for it.
[21:23] <infinity> Daviey: So, server will need a respin anyway.
[21:24] <skaet> I'll add server in to the set for the full respin.
[21:24] <Daviey> skaet: thanks.
[21:24] <infinity> skaet: Is anything not in that set?
[21:24] <infinity> skaet: I think we're pretty much at scorched earth "just do it all" land.
[21:24] <skaet> infinity - do we need a set of netboot ones?
[21:24] <Daviey> skaet: I believe everything we want in beta-2 is good to go now.  I'm looking forward to smoking a build.
[21:24] <infinity> skaet: "netboot" = d-i, that's happening shortly.
[21:25] <stgraber> skaet: netboot will be automatically posted on the tracker when my cronjob detects the new d-i
[21:25] <Daviey> skaet: building d-i, builds a netboot.
[21:25] <skaet> infinity,  stgraber,  cool was wondering how that worked.  :)
[21:25] <skaet> Daviey,  thanks.
[21:25] <skaet> Daviey,  are there some bug numbers associated with that maas upload?   changelog isn't mentioning any.
[21:26] <Daviey> skaet: Can you ask the LOSA's to turn the buildd's up to 11, getting impatient :)
[21:26] <Daviey> skaet: no
[21:26] <astraljava> skaet: Apparently there's no interest for a respin of Xubuntu images. (sorry it took a while)
[21:28] <skaet> Daviey,  the one you have to sweet talk on that subject is infinity... he's in discussions with them on improving the situation overall.
[21:30] <skaet> astraljava - there's some rather nasty bugs we're fixing across the rest of the set, so I'm going to go ahead and respin it at this point.  However if team is happy with the images, we can release with what's on the tracker and tested now.
[21:30]  * skaet will manually set it back to the current set if you don't want to do the restesting. 
[21:31] <micahg> astraljava: doesn't xubuntu need the respin for onboard?  (I uploaded the fix specifically for xubuntu)
[21:32]  * skaet nods
[21:33]  * infinity scores a bunch of builds up and notes that it might be a good time for releasy people to take a breather.
[21:33] <infinity> We won't be respinning for a "while".
[21:33] <astraljava> micahg: Oh, sorry I forgot about onboard! I'll go testing immediately.
[21:33] <infinity> Hour or two, at least.
[21:33] <skaet> astraljava,  images won't be out for a couple of hours.  alternates first then desktop a bit after.
[21:34] <infinity> s/couple/few/
[21:34] <infinity> Unless I get a LOSA to firebomb the buildd network and take them all over.
[21:34] <skaet> infinity,  please try.
[21:34] <skaet> :)
[21:35] <astraljava> skaet: Yes, I meant the onboard fix micahg has in a PPA.
[21:35] <micahg> astraljava: use the archive version please :)
[21:35] <infinity> astraljava: It's in.. What he said.
[21:35] <astraljava> micahg: Yep, sorry, was offline for a bit and missed these news. :)
[21:35] <micahg> infinity: it wasn't supposed to be accepted until he tested to made sure it was fixed, but meh :)
[21:35] <infinity> skaet: Do you have a list of triggers other than d-i and ubiquity?
[21:36] <infinity> skaet: I need to make sure everything's scored up if I'm going to go the firebomb route. :P
[21:36] <skaet> astraljava,  if you want that fix,  at this point you'll be having to take the rest.
[21:36] <skaet> infinity, see pad
[21:37] <skaet> (and feel free to add any explicitly I've missed.
[21:37] <astraljava> skaet: Yeah, I suppose that reverses my earlier statement, then. :)
[21:37] <skaet> :)
[21:39] <skaet> stgraber,  looks like there is a stale version of ubiquity (2.10.3) in proposed.   Remove it?
[21:40] <stgraber> skaet: oh, yeah, it's been copied to precise already according to rmadison
[21:43] <skaet> Daviey, there was some discussion on an openMPI fix earlier,  is that still on the list to land for beta 2, or are we release noting?
[21:45] <Daviey> skaet: I spoke to rbasak who has touched openmpi for arm the most, and it's an opportunity, but not critical
[21:45] <skaet> Thanks Daviey
[21:46]  * skaet notices that linux kernel is now all built
[21:48] <infinity> skaet: Yeah, hence why d-i is building. ;)
[21:48] <skaet> :)
[21:48] <skaet> just noticed that too now.
[21:49] <infinity> So, I freed up ross for us to let PPC catch up.
[21:49] <infinity> amd64 will catch up (and pass ARM) soon.
[21:49] <infinity> We should be good.
[21:49] <infinity> Still, it'll be a couple of hours before ubiquity's published everywhere, probably.
[21:49] <skaet> infinity, thanks,  was wondering why amd64 + PPC weren't showing building symbols.   :)
[21:50] <skaet> yes,  ubiquity is lagging on PPC and amd64 as well, as well.
[21:51] <infinity> Well, I only freed up one PPC machine, so it's doing d-i first, then ubiquity.
[21:53] <cjwatson> stgraber: you're running tests/build after debian/rules update, I bet.
[21:53] <micahg> I've got another version of ubuntustudio-default-settings coming to clean up the conf file handling, won't need to respin for this now
[21:53] <micahg> s/now/though/
[21:54] <infinity> micahg: Meh, respins are a bit off on the horizon anyway, may as well let that in too.
[21:54] <skaet> micahg,  we won't block on it, but if its ready, we'll pick it up.
[21:54] <cjwatson> skaet: no need to remove old versions from proposed specifically - they won't cause a problem.  I'm working on an improvement to the pending SRU report to emit commands for that.
[21:55] <skaet> cjwatson,  goodness.  :)
[22:00] <Daviey> skaet: A potential slight regression.. investigating
[22:01]  * skaet likes this stgraber!!!  
[22:01]  * skaet doesn't have to go clickity-click on the project to see if done,  sweet.
[22:01] <skaet> Daviey,  ack.
[22:02] <infinity> stgraber: That seems a bit premature.  Where is it getting that "netboot" info from?
[22:03] <infinity> stgraber: Given that that version of d-i hasn't been published yet...
[22:03] <infinity> stgraber: And, in fact, is still building on amd64 and i386. ;)
[22:05]  * skaet has to do clickty-click after all... :(   lol
[22:05] <infinity> stgraber: If it's polling source, you might instead want to poll archive/ports.u.c/ubuntu{,-ports}/dists/precise/main/installer-$arch/$version
[22:05] <stgraber> infinity: LP API
[22:06] <infinity> stgraber: But just asking LP API if the source is published, I'm guessing?
[22:06] <infinity> stgraber: Since it told me there were new images for all arches, and half of them are still building. ;)
[22:07] <stgraber> infinity: yeah, I had to go read the script :) it's checking for PublishedSource
[22:07] <stgraber> infinity: I'll add to the todo to port it to checking individual architectures and post them only when published for the architecture
[22:07] <infinity> stgraber: I suspect from the POV of testers being able to actually test when the bot tells them, polling the mirrors would be more effective than asking LP.
[22:07] <infinity> stgraber: Since even asking LP about published binaries will still be wrong for about 30 frustrating minutes.
[22:08] <stgraber> infinity: hmm, indeed, hardcoding the path and reading the html may actually be easier than implementing the magic needed to check for the various binaries through the API :)
[22:09] <infinity> Probably. ;)
[22:16] <astraljava> skaet: Xubuntu should be ready for the respin now, thanks!
[22:17] <skaet> astraljava,  :)
[22:18] <cjwatson> well, not until d-i lands
[22:19] <infinity> d-i and ubiquity should both publish for all arches in the next run.
[22:19] <infinity> Except maybe ubiquity/ppc.
[22:19] <infinity> It could be 30 seconds late.
[22:20] <phillw> infinity: drat :(
[22:20] <cjwatson> well, half-hourly runs ftw.
[22:20]  * infinity nods.
[22:21] <infinity> Though, it will literally be about 30 seconds if it's late. ;)
[22:21] <infinity> Timing, yay.
[22:21] <astraljava> cjwatson: Yeah. :) skaet: I'll be sleeping now, so if you have questions/anything for Xubuntu, please ask on #xubuntu-devel, if someone else is awake still. Thanks again for the whole team, see ya tomorrow!
[22:21] <phillw> infinity: cjwatson so, will a ppc be there for 20120328 for the lubuntu ppc testers?
[22:21] <infinity> phillw: You bet, it'll get built.
[22:21] <infinity> phillw: Just commenting on archive publishing being late, the images will happen.
[22:21] <skaet> astraljava,  thanks.  sleep well.
[22:22] <phillw> excellent, that gives them a couple of hours to test before the QA meeting Wed evening and, hopefully, beta 2 on Thursday :)
[22:28] <skaet> Daviey,  if you're still around,  do we have all the pieces accepted from the unapproved queue you want in tonight's images (/me must spotted rabbitmq-server there)
[22:29] <Daviey> skaet: Yep! Rabbit needs to go in.. I thought that was already accepted.. well spotted
[22:29] <skaet> debian/rabbitmq-server.init: emit 'rabbitmq-server-running' signal for  upstart as MAAS needs it.
[22:29] <skaet> ok,  doing now
[22:30] <Daviey> skaet: I have one more issue, working through it now
[22:32] <skaet> Daviey,  put a note of the package affected on the pad,  under invesitgation, so I can remember to keep an eye open for it.
[22:34] <Daviey> k
[22:34]  * skaet is wondering why openmpi sources with the comments in them against arm are listed in edubuntu sets
[22:34] <Daviey> skaet: Happy for me to remove triggers satisfied ?
[22:35] <skaet> Daivey,  I'll do a clean sweep of it to the bottom, once all the pieces are ready and the rebuild startds
[22:35] <skaet> *starts even.
[22:35] <Daviey> skaet: Yep, but things blocking spin which are solved, you still want on there?
[22:36] <skaet> yes,  I'll be doing a double check before kicking and its easiest that way
[22:36]  * skaet not having to look in two places
[22:37] <Daviey> k
[22:37] <Daviey> skaet: you have 2 [23]'s
[22:38] <skaet> Daviey,  good spotting,  fixing.
[22:39]  * skaet sees ubiquity's almost done building.  :)
[22:40] <infinity> skaet: Yeah, ppc missed.  We'll get it in ~45 mins.
[22:41] <infinity> skaet: Could start with preinstalled at the end of this publisher run (~20 mins?) to give ARM a head start.
[22:41] <skaet> infinity, debian installer's done.   should os-prober be accepted from the unapproved queue?
[22:41] <skaet> infinity,  yup,  can do.  re: arm.
[22:42] <skaet> infinity,  we may need to make sure the server bits are all in place for it though.  (rabbitmq-server landed)
[22:43] <cjwatson> os-prober - no point unless you also accept the grub2 upload I haven't prepared yet
[22:43] <cjwatson> that's a two-part fix
[22:45] <cjwatson> it doesn't *hurt* on its own, but it won't gain much of anything
[22:49] <skaet> cjwatson,  thanks.  ok,  we'll leave it in the queue then.
[22:49] <infinity> skaet: Well, if we want to make the rebuild a simple fire-and-forget, then, ubiquity/ppc and rabitmq/all will both publish in the next cycle, so you can just press the big red "build everything" button in ~40ish.
[22:50] <infinity> Assuming the publisher doesn't wrap itself.  Let's see. ;)
[22:50]  * skaet likes simple....
[23:01] <infinity> Okay, the publisher's not going to eat its own tail.  So, the above bits we're waiting on will be on-disk in 30ish.
[23:07] <skaet> infinity,  all bits except rabbitmq-server (ubuntu3_all.deb) seem to have emerged,  will start off the arm ones now, and desktop;   will add alternate/server in as soon as I see that bit.
[23:07] <skaet> can you see anything I've overlooked?
[23:08] <infinity> skaet: Err, yeah.  Wait on desktop images that include PPC.
[23:08] <infinity> skaet: Like I said, ubiquity/ppc is in this same run as rabitmq.
[23:08] <infinity> skaet: (And if you want to just do one big build, hold off for ~20)
[23:09]  * skaet thought ppc was there.... re-checking..
[23:09] <infinity> Nope.
[23:09] <infinity> Don't trust the LP UI.
[23:09] <infinity> It marks things publishes as soon as the publisher starts.
[23:10] <skaet> http://us.archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/?C=M;O=D
[23:12] <infinity> Not sure what I'm meant to be seeing there, as PPC isn't on archive at all...
[23:13] <skaet> infinity,  ah,  thats where I was checking.  educate please.  where should I be checking for it?
[23:14] <infinity> skaet: ports.ubuntu.com/ubuntu-ports would be the mirror that has powerpc/armel/armhf binaries.
[23:15] <skaet> infinity, *doh*  yes.  sorry.
[23:16] <skaet> yeah,  ubiquity/ppc missed the :03 publishing run
[23:21] <infinity> I know. :)
[23:26] <micahg> ^^ fixes conffile migration for ubuntu studio, not needed on image, but needed in archive
[23:27] <infinity> micahg: I'll accept it after we do the images, then.
[23:27] <infinity> skaet: Publisher's done, you can rebuild the world anytime.
[23:29] <skaet> infinity,  hmm,  not showing up on the ports mirror quite yet.   will give it 5 and then kick it all in motion.
[23:29] <doko> infinity, yes I need to restart the rebuild. will do that on Wed
[23:29] <skaet> ah,  its there.
[23:29]  * skaet kicks
[23:29] <infinity> skaet: All the builds operate from ftmaster directly, you're good.
[23:30] <phillw> the clock is sticking guys, No sod the clock.... about what time, in UTC, do you fantastic guys reckon the re-spins will be done? Ah, UTC / Vs BST... it is Wednesday here :)
[23:30]  * skaet goes to reset the iso tracker.
[23:30] <infinity> phillw: Well, they're starting now.  So.  Sometime later than now. ;)
[23:30] <skaet> phillw,  alternate should be done within the hour,   desktop will be a bit longer.
[23:35] <phillw> Hey guys, having sat on this channel for a couple of days, I will admit I understand less than 50% of what you discuss. My question, for lubuntu, is quite simple. Have we enough testing reports in to maintain our current set of Lubuntu variants? i.e. the Mac stuff.
[23:36] <infinity> phillw: For any given flavour/arch combination, one good boot/install smoketest is all we're really looking for.
[23:37] <infinity> phillw: Someone to say "it booted and didn't eat my pets when I clicked on stuff".
[23:37] <infinity> phillw: We hold Ubuntu itself to a higher standard, but for community flavours/ports, we understand that testing bandwidth is limited, and we just need to know we're not building and shipping dud images.
[23:38] <phillw> infinity: it does drive the testers mad, they report that the beta 2 release installs (even with bugs), then the next day - it is all gone? how does that work?
[23:38] <infinity> phillw: It all goes away when there's a new image candidate (as is happening right now).
[23:38] <infinity> phillw: Since it's the image itself we're testing, not the state of the archive, we need to know the image we ship is known-good.
[23:39] <skaet> phillw,  the results are all still there on the tester,  just reported against the prior image.
[23:39] <phillw> infinity: so, no matter what testing has been done - it counts for nothing for when the decision is made to release, in this case, the beta 2?
[23:40] <skaet> phlllw, http://iso.qa.ubuntu.com/qatracker/milestones/210/history
[23:40] <skaet> will show all the prior bugs found
[23:40] <phillw> skaet: so, if it has been shown to be tested, is that enough to drive it forward?
[23:40] <skaet> phillw, the testing does matter.   Several times we've held off on releaseing images if the testing indciated key problems.
[23:40] <infinity> phillw: For betas, you can cheat and nominate an old image, and say "please just ship that", but for final release, yeah, the only one that matters is the last one we build.
[23:41] <cjwatson> "Counts for nothing" is a bit strong, but the weirdest things can cause images to fail.
[23:41] <infinity> phillw: That said, any testing leading up to the final image is, obviously, good.
[23:41] <cjwatson> We tend to be paranoid.
[23:41] <phillw> cjwatson: my aopolgies,
[23:41] <skaet> phillw,  if it has been fully tested on one instance, and then spot tested,  it's likely to go through.  its the entire history that matters.
[23:42] <cjwatson> phillw: no need :)
[23:42] <skaet> phillw, for each of the flavors I try to make sure that the leads and QA reps are comfortable with the images before we make the ship/not decision.
[23:42] <phillw> what I meant was, there are guys testing the ppc / Mac stuff. And I really find it hard to ask them to run every test at every stage of a respin
[23:43] <skaet> phillw,   just ask them to spot check at this point if they've done the full set already.
[23:43] <phillw> As long as it noted that testing has been done, that will be excellent news to them
[23:44] <skaet> as infinity says, for the final release its different - we do need to know all is well, but for the beta's if all the tests have been done, and no irregularities show up with last image from spot testing,  all should be reasonable risk.
[23:45] <phillw> skaet: I am aware that this is a major re-spin, but if they cannot get them all done by about midnight Thursday, which is Beta 2 release day, will their previous tests count?
[23:45] <cjwatson> Even knowing that the image still boots is somewhat reassuring, though installability in at least one mode is nice.
[23:45]  * cjwatson is still slightly scarred by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368969
[23:45] <ubot2> Debian bug 368969 in squashfs-tools "rounding error causes generation of invalid filesystems" [Critical,Fixed]
[23:46] <skaet> phillw,  as cjwatson says,  if they've all been done at some point,  and the spot testing looks good.  we're fine for beta.
[23:46] <infinity> cjwatson: Good times.
[23:46]  * skaet goes to look at that bit of history... 
[23:46] <cjwatson> that's also https://launchpad.net/ubuntu/+source/squashfs/1:2.2r2-2ubuntu2
[23:47] <phillw> thank you. the last thing I wanted to do was to give false hope to the new band of ppc / Mac 64 testers.
[23:47] <cjwatson> And in some ways was the genesis of our current practices ...
[23:48] <infinity> phillw: Like i said, a quick boot/install smoketest is all we really require of most flavours/ports anyway.  So, hopefully that's not too onerous for them.
[23:48] <phillw> infinity: it will be done.
[23:48] <cjwatson> (Background: we changed something completely inconsequential.  Suddenly the Ubuntu desktop image kernel-panicked.  We had no idea why until Scott stared at it for a few solid hours.)
[23:48] <infinity> phillw: I think people get the wrong idea about how much testing they MUST do.  As always, more is better, and we love bug reports (and patches), but to be able to ship and image, we just need to know it's not completely DOA/broken.
[23:49] <infinity> s/and image/an image/
[23:52] <cjwatson> Of course, it's silly to fight the last war, and we probably won't see that kind of image misgeneration again.  But everyone still likes to know that *somebody* has tried any image we release.
[23:53] <phillw> infinity: would a PM be allowed?
[23:54] <infinity> phillw: Depends on which PM it is.  If it's not Stephen Harper, sure.
[23:54] <slangasek> infinity: the threshold for betas is considerably higher than "not completely DOA/broken"
[23:54] <phillw> infinity: im on my name in here
[23:55]  * micahg thought that was alpha criteria
[23:55] <slangasek> hmm, now why did the daily upgrade test not spit out any results for lucid-server today
[23:55] <infinity> slangasek: I said what we need to know, not what we like to know.  I'd like to think that the flavour folks won't ship an image that doesn't look/do as they think it should.
[23:57] <infinity> phillw: I think you missed my sarcasm.  PMs are fine. :P