[00:03]  * infinity is finally home.
[00:08] <stgraber> infinity: that was a long trip back home
[00:09] <infinity> ogra_: That -lGL bit will fail on powerpc.
[00:09] <infinity> stgraber: The bit where I was in hospital for a day slowed me down.
[00:09] <stgraber> infinity: ouch, what happened to you?
[00:10] <infinity> stgraber: Kidney stones.  Fun times.
[00:13] <mdeslaur> infinity: ouch :(
[00:15] <ogra_> infinity, why ?
[00:15] <ogra_> no meas on ppc ?
[00:15] <ogra_> *mesa
[00:15] <infinity> ogra_: Err, no, you're only setting -lGL on x86_64 and i686
[00:16] <infinity> ogra_: Whereas, previously, it was on all arches.
[00:16] <ogra_> oh, right, whats the machine string for ppc again ?
[00:16] <infinity> ogra_: You probably want NOT STREQUAL "armv7l" or something.
[00:16] <infinity> ogra_: Since that's what you mean.  Listing every GL arch is silly.
[00:16] <ogra_> what i want is "else"
[00:17] <ogra_> but silly cmake doesnt have that
[00:17] <infinity> ogra_: Better yet, not making it arch qualified at all, don't we already have a magic "using gles" flag we can test?
[00:17] <ogra_> or the guarantee that one set overrides a former one
[00:18] <ogra_> infinity, looking at the build it actually sets everything properly already i think its not needed at all
[00:18] <infinity> They do override the former, except that it's being done in an additive fashion.
[00:18] <infinity> And dropping -lGL and -lGLU entirely, if the flags are added elsewhere, is an even better option, yeah.
[00:19] <ogra_> right, i was waiting for rsalveti's feedback for that one
[00:19] <ogra_> my cmake hack is rather thought as a last resort
[00:19] <infinity> if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l")
[00:19] <infinity>     set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm")
[00:19] <infinity> else ()
[00:19] <infinity>     set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU")
[00:19] <infinity> endif ()
[00:19] <infinity> ^-- From /CMakeLists.txt
[00:19] <ogra_> fun
[00:20] <infinity> Assuming UNITY_STANDALONE_LADD is used for the subproject, you can probably just ditch that bit from dash/previews/CMakeLists.txt
[00:20] <ogra_> yeah, i wonder why they define it at all
[00:20] <infinity> Though, it doesn't appear to be..
[00:21] <infinity> Still this is all silly and fragile to be doing it based on uname and not a config flag. :/
[00:21] <infinity> It should be based on BUILD_GLES
[00:21] <ogra_> yep, but at least its consistently odd :)
[00:22] <infinity> Which is defined.
[00:22] <ogra_> yup ... like -fPIC that should be set based on defaults :)
[00:22] <infinity> I'd just move that armv7l bit into the BUILD_GLES stanza that follows.
[00:23] <ogra_> but i surely wont rewrite the unity build system tonight
[00:23] <infinity> fPIC should just be the default, period.
[00:24] <infinity> I'm sure the only reason it isn't is because they added it to fix a build failure on amd64, not realising that they really want it on all arches.
[00:24] <ogra_> heh, take a look at any of the CMakeList.txt files in the unity tree
[00:24] <infinity> Yeah, I'm looking right now.
[00:24] <infinity> Silly.
[00:29] <infinity> ogra_: http://paste.ubuntu.com/1182617/
[00:29] <infinity> ogra_: Something like that should do.
[00:29] <infinity> ogra_: (Not fixing the fPIC mess with that, just cargo-culting as you did)
[00:30] <infinity> ogra_: But that should fix the linking issue.
[00:32] <infinity> ogra_: Want me to test and push something along those lines?
[00:32] <infinity> ogra_: It's pretty late for you. :P
[00:34]  * infinity reapplies against the current version and tests.
[00:39] <infinity> http://paste.ubuntu.com/1182627/
[00:39] <infinity> ogra_: ^-- Testing that patch right now.
[00:51] <ogra_> infinity, my testbuild with the first patch just finished
[00:51] <ogra_> so at least there are no subsequent build issues
[00:51] <infinity> ogra_: Alright.  well, I'm testing mine on all 5 arches.
[00:51] <infinity> ogra_: If it seems happy, I think I'll upload it.
[00:51] <ogra_> great
[00:52] <ogra_> thanks so much ... i'll make Łukasz pay us a lot beers at UDS :)
[00:55] <ogra_> though probably seb should pay half of it ... he was the actual uploader and signer
[00:56] <infinity> Applying patch disable_standalone-clients.patch
[00:56] <infinity> patching file CMakeLists.txt
[00:56] <infinity> Hunk #1 FAILED at 156.
[00:56] <infinity> 1 out of 1 hunk FAILED -- rejects in file CMakeLists.txt
[00:56] <infinity> Patch disable_standalone-clients.patch does not apply (enforce with -f)
[00:56] <infinity> ^-- Why the heck is that non-fatal?!
[00:57] <ogra_> heh
[00:57] <slangasek> infinity: because of the hand-hacked rules for coping with arch-specific series files, which should be taken out and shot?
[00:58] <slangasek> (but most importantly, taken out)
[00:58] <ogra_> on my TODO
[00:58] <slangasek> I would suggest it be done now
[00:58] <infinity> Yeah.  I suspect that patch isn't even necessary now.
[00:58] <infinity> If this stuff all builds, then it clearly isn't necessary.
[00:58] <infinity> Given that it DIDN'T APPLY ANYWAY.
[00:58] <ogra_> yeah
[00:59] <infinity> So, if this pass works everywhere, I'll drop that hunk of sad.
[00:59] <ogra_> though it didnt apply because you edited CMakeLists.txt, no ?
[00:59] <infinity> ogra_: No, it had nothing to do with my edits, unless this is the pickiest quilt ever.
[00:59] <slangasek> well, either way, the directory referenced by that patch doesn't exist
[00:59] <slangasek> so it should be dropped
[01:00] <slangasek> and debian/rules sanitized
[01:00] <infinity> Yeah, doing.
[01:00]  * ogra_ isnt sure we should put that much cleanup worn in 
[01:00] <ogra_> *work
[01:00] <infinity> It's 5 seconds.
[01:00] <infinity> And I've already done it. :P
[01:01] <infinity> Plus, I'm on drugs.  CMake projects make sense right now.
[01:01] <ogra_> i mean, the whole thing needs to be repacked from scratch anyway
[01:01] <ogra_> non-native ... cleaned up etc
[01:01] <slangasek> the non-native issue is orthogonal
[01:01] <ogra_> well, if its done already ... *shrug*
[01:02] <slangasek> and as infinity has just shown, the existing rules are so broken that they would prevent the package from FTBFS reliably if something comes un-stuck with this current fix.  Ripping out the bad code is definitely the right thing to do
[01:03] <ogra_> true
[01:03] <ogra_> anyway, 3am ... i'll crawl towards my bed ...
[01:04] <ogra_> what a weekend ...
[01:04] <slangasek> ogra_: 'night... :)
[04:32] <shadeslayer> infinity: thanks for fixing telepathy qt
[04:36] <infinity> slangasek: I had a bit of an accidental nap while testbuilding, unity's uploaded now. :P
[04:36] <rsalveti> infinity: I'm testing the same patch now
[04:36] <rsalveti> infinity: the older one that is part of the specific rules can also be gone
[04:36] <rsalveti> which helps if you want to remove the hack at rules
[04:37] <rsalveti> another thing that I just changed as well is removing the dependency on gcc-4.6
[04:37] <rsalveti> as it's not needed anymore
[04:37] <infinity> rsalveti: I removed the patch and the arch-specific patch hack completely.
[04:37] <rsalveti> cool
[04:37] <infinity> rsalveti: I didn't drop the gcc build-dep, I'll let that wait until post-beta.
[04:38] <infinity> rsalveti: My diff: http://launchpadlibrarian.net/114595044/unity_6.4.0-0ubuntu3_6.4.0-0ubuntu4.diff.gz
[04:38] <rsalveti> infinity: why is this a native package
[04:38] <rsalveti> ?
[04:39] <infinity> rsalveti: I'm sure more cleanup could be done (like -fPIC for all arches, for instance), but this was a minimal "make it work" thing.
[04:39] <rsalveti> sure
[04:39] <infinity> rsalveti: No idea why it's native, not going to switch/fix that for them today. :P
[04:39] <rsalveti> I just dropped the gcc because I was using icecc to build
[04:39] <rsalveti> and it was forcing gcc-4.6, which was then skipping icecc
[04:40] <infinity> shadeslayer: NP.
[04:41] <rsalveti> infinity: yup, just installed and it worked fine
[04:41] <rsalveti> infinity: so this patch is good to get it all working
[04:41] <rsalveti> and it's quite fast I must say, just missing the kernel fix to avoid the flickering, which we'll try to fix after b1
[04:42] <rsalveti> and, built fine with gcc-4.7 for amd64 and armhf
[04:42] <rsalveti> so we can drop it later on
[04:45]  * infinity drugs himself up and goes back to bed.
[04:58] <ScottK> infinity: Thanks for taking care of telepathy-qt.
[05:00] <infinity> ScottK: Want to review and accept that unity in the queue as compensation? :)
[05:00] <infinity> ScottK: (Test-built it on all 5 arches here, seems good)
[05:01] <ScottK> Depends on how long I last before I time out.  I've been offline all of today and most of yesterday, so I have a pile of stuff in the queue.
[05:07] <stgraber> infinity: accepted
[05:08] <stgraber> debdiff looks reasonable and matches what I've read on IRC today. Hoping that one will finally work for everyone...
[06:01] <pitti> hello
[06:02] <pitti> does anyone from the release team happen to be awake?
[06:02] <pitti> I'd like to discuss postgresql-9.1
[06:38] <Mirv> infinity: can you do a merge request of your CMakeLists.txt changes against lp:unity at some point so that the changes don't get forgotten?
[07:19] <slangasek> ogra_: unity runs for me now \o/ but it seems to flicker a lot; have you seen this?
[08:01] <pitti> slangasek: got a minute for discussing postgresql-9.1?
[08:01] <slangasek> pitti: hmm, I can try :)
[08:02] <pitti> so, I uploaded 9.1.5-2 to unapproved last Friday with two bug fixes that are milestoned for b1
[08:02] <pitti> I didn't get an IRC response or review, so I re-synced the same thing into quantal-proposed where it built
[08:03] <pitti> slangasek: -2 is still in the unapproved queue and shoudl be rejected, but I kept it to provide the queue diff for the -release review
[08:03] <pitti> slangasek: I'd recommend getting this in, as it fixes upgrades from precise which we hope to get testers for
[08:04] <pitti> so if I get a +1, I can reject the unapproved upload and copy -proposed to quantal
[08:06] <Laney> yay, unity
[08:07] <iulian> Can I accept those syncs from unapproved if I'm happy with them?
[08:07] <slangasek> pitti: ah, I reviewed it and accepted before seeing the last comment
[08:08] <Laney> iulian: yeah
[08:08] <iulian> OK.
[08:08] <Laney> using 'queue' is preferred to the web UI, although I forget exactly what the UI does wrong
[08:08] <pitti> slangasek: oh, does that even work? the same versino is already in -proposed, after all?
[08:08] <slangasek> pitti: sorry, I meant I copied from -proposed
[08:09] <pitti> slangasek: ah, c'est parfait
[08:09] <pitti> slangasek: merci
[08:11] <iulian> Laney: Yup, I've been teaching myself how to use those tools. Well, just queue and queuediff.
[08:13] <cjwatson> The only thing the web UI does desperately wrong is that it doesn't present binary overrides sensibly
[08:13] <cjwatson> It's fine to use it for accepts and such
[08:13] <Laney> one thing I did have to use it for is to reject one copy of the same (source, version)
[08:13] <Laney> how do I do that with queue?
[08:13] <cjwatson> reject by ID
[08:14] <cjwatson> queue reject <seven-digit-number>
[08:14] <cjwatson> which you can get from queue info
[08:14] <Laney> ah, that works, cool
[08:14] <cjwatson> For the experimental freeze a while back I asked people to use the API client because we were specifically testing that
[08:14] <cjwatson> But that wasn't a long-term prescription or anything
[08:15] <cjwatson> That said I personally prefer using the client
[08:18]  * Laney switches default_milestone
[08:22] <Laney> pitti: will you copy postgres over?
[08:22] <pitti> Laney: slangasek already did
[08:22] <Laney> hm, I don't see it
[08:22] <pitti> https://launchpad.net/ubuntu/+source/postgresql-9.1/+publishinghistory
[08:23] <Laney> oh, +pu
[08:23] <Laney> yeah
[08:23] <pitti> not published yet
[08:23] <Laney> the version page doesn't
[08:23] <Laney> cheers
[08:27]  * Laney disables cronned builds
[08:34] <iulian> Hmm, no queuebot?
[08:39] <iulian> Is there a log somewhere I can look at to see who did what?
[08:39] <Laney> not sure how far along queue audit is
[08:39] <Laney> there's certainly been some work on it
[08:40] <Daviey> I don't believe there is anything of use right now.
[08:40]  * iulian nods.
[08:41] <Laney> https://bugs.launchpad.net/launchpad/+bug/885739
[08:41] <ubot2`> Ubuntu bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,In progress]
[08:41]  * iulian looks.
[08:42] <cjwatson> StevenK has been working on an auditor interface, much of which has landed, but I have no idea how to get at the audit logs
[08:44] <cjwatson> cyphermox: would it be possible to resolve the evolution-related items on http://people.canonical.com/~ubuntu-archive/nbs.html before beta, at least those in main, preferably without taking a whole new upstream of the evolution stack?  I tried rebuilding evolution-exchange but it FTBFS ...
[08:44] <iulian> Nice.
[08:56] <cjwatson> cyphermox: everything I've tried there so far dies with direct-inclusion errors
[08:57] <Laney> someone was porting -exchange
[08:58] <Laney> perhaps it was cyphermox, but something in my head is telling me chrisccoulson
[09:02] <chrisccoulson> it wasn't me :)
[09:14] <Laney> Riddell: ScottK: Should we be building kubuntu active for B1?
[09:17] <seb128> cjwatson, re evo, those are non trivial, the upstream apis had quite some changes
[09:17] <seb128> cjwatson, we should probably drop some of those sources like contacts or dates, stuff that are unmaintained upstream for years
[09:21] <cjwatson> I don't especially care but I'm not removing anything without audit-trail bugs :-)
[09:22] <Laney> ok, building a set of images
[09:22] <seb128> cjwatson, when do you want that sorted? is end of day today or tomorrow ok?
[09:22] <seb128> cjwatson, I want to talk to cyphermox first before dropping stuff, but he's not up before a few hours
[09:23] <Riddell> Laney: yes please, although it needs a bugfix first
[09:23] <Laney> ok, well it'll build but we can spin it again later
[09:26] <cjwatson> seb128: sure, that's fine, just post-holiday "what's the archive looking like" checks
[09:27] <seb128> cjwatson, sorry about that, part my fault, with Didier on holidays I had to step up to help getting the stuff from #ps landing for ff and I didn't manage to do lot of +1 due to that :-(
[09:45] <xnox> Please accept ubiquity 2.11.27 it fixes bug 1044545 which prevents opening manual partitioning in ubiquity.
[09:45] <ubot2`> Launchpad bug 1044545 in ubiquity "ubiquity crashed with AttributeError in on_partition_use_combo_changed(): 'PageGtk' object has no attribute 'partition_format_checkbutton'" [Critical,In progress] https://launchpad.net/bugs/1044545
[09:45] <xnox> Laney: ^^^^
[09:46] <Laney> xnox: when the diff appears
[09:46] <xnox> Laney: ok thanks. And I guess I owe 14 birdseeds to the release team by now....
[09:47] <Laney> did you mean to not sponsor it properly for Omer?
[09:48] <seb128> Laney, did you guys consider the stuff I mailed the list about on saturday?
[09:49] <seb128> like indicator-session
[09:49] <Laney> seb128: not yet
[09:49] <seb128> :-(
[09:49] <Laney> I'll look at it in a minute
[09:50] <Laney> you want indicator-session s-c-p indicator-messages considered?
[09:54] <xnox> Laney: no, I did not mean to sponsor it properly for Omer. I did mean to have multi-maintainer changelog.
[09:55] <Laney> ok, well, looks "DOH" enough
[09:55]  * Laney accepts
[09:55] <xnox> Laney: thanks.... and respin later?! =)
[09:55] <Laney> yes. later.
[09:55] <Laney> after considering these desktop updates
[09:56] <ogra_> slangasek, yay, awesome, thanks for testing :)
[09:56] <xnox> also is the release bot asleep? =)
[09:56]  * Laney wonders how long these guys upstairs need to assemble a desk
[09:57] <seb128> Laney, yes
[10:04] <ogra_> slangasek, oh, and yes, i have seen the flickering too, but i think thats post-beta stuff, having a desktop at all was my beta target :)
[10:06] <cjwatson> xnox: needs stgraber to fix
[10:08] <xnox> ok
[10:12] <xnox> So am I allowed to upload to quantal-proposed for stuff which is not critical for beta1
[10:12] <xnox> e.g. fix for bug 523896
[10:12] <ubot2`> Launchpad bug 523896 in shadow "useradd: cannot lock /etc/passwd; try again later." [High,In progress] https://launchpad.net/bugs/523896
[10:12] <xnox> ?
[10:12] <cjwatson> Yeah
[10:13] <cjwatson> Or you can dump it in the unapproved queue and we can ignore it until later :-)
[10:13] <cjwatson> (i.e. upload to quantal, if it's relatively unlikely anyone else will need to for that package)
[10:14] <xnox> ok.
[10:17] <cjwatson> slangasek: Could you review efilinux-signed in NEW?
[10:36] <Laney> seb128: accepted
[10:36] <seb128> Laney, thanks!
[10:36] <Laney> np, will respin later
[10:36] <cjwatson> seb128: is bug 1028363 OK?  compizconfig-settings-manager and compizconfig-python are obvious, I just wanted to check on whether you're fine with dropping the binary package compiz-fusion-plugins-extra from compiz-plugins-extra
[10:36] <ubot2`> Launchpad bug 1028363 in compizconfig-settings-manager "Please remove old compiz sources from quantal archive" [Undecided,New] https://launchpad.net/bugs/1028363
[10:39] <cjwatson> jdstrand: could you confirm bug 1033107?
[10:39] <ubot2`> Launchpad bug 1033107 in ubuntu "Please remove python-pyftpdlib from the blacklist and sync from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1033107
[10:39] <seb128> cjwatson, yes, they are all fine, we just support "compiz" in quantal, those 3 sources can be dropped
[10:39] <seb128> cjwatson, I commented on the bug saying so
[10:39] <cjwatson> thanks
[10:40] <cjwatson> Ah, yes, compiz-plugins-extra exists since natty
[10:46] <Laney> psivaa: hey, do you think you guys could put your nicks on the ReleaseTaskSignup page? I'm not yet familiar with your first names ;-)
[10:46]  * Laney will edit for the names of the RT
[10:47] <psivaa> Laney, could i have the link for the page?
[10:47] <Laney> psivaa: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseTaskSignup
[10:47] <Laney> I'm trying to figure out who to ping when respinning :-)
[10:48] <psivaa> Laney, sure ill add my nick
[10:48] <Laney> the others too if you know them
[10:48] <Laney> sorry for being clueless
[10:53] <psivaa> Laney, ok no worries, done for the 3 qa contacts
[10:53] <Laney> thank you
[10:53] <Laney> so FYI we're currently looking at some respins as listed on the pad http://pad.ubuntu.com/ubuntu-release
[10:53] <Laney> but the first cut images aren't all done yet, so will be kicked off in a few hours
[10:56] <cjwatson> Laney: so I'm still kind of coping with piles of post-holiday stuff; for today, maybe best if you lob things in my direction as needed?
[10:56] <Laney> cjwatson: sure, no probs, handling it for now
[10:57] <Laney> the kind gentle folk from across the Atlantic should be along soon too
[10:57] <cjwatson> mostly trying to clean up archive bugs
[10:57] <cjwatson> which seem to have got rather behind
[10:58] <seb128> Laney, not sure what people you are talking about but it's labor day in the U.S so those people will not be here today
[10:58] <seb128> ;-)
[10:58] <Laney> oh, really?
[10:58]  * Laney panics
[10:58] <seb128> yes...
[10:58] <Laney> not really :P
[10:58] <seb128> bit of an unfortunate timing, release people being at plumber on friday and U.S being off on monday
[11:02]  * cjwatson eyes bug 1011053
[11:02] <ubot2`> Launchpad bug 1011053 in glew1.5 "Please remove libglew1.5-dev and libglewmx1.5-dev and the glew1.5 source from quantal" [Wishlist,Confirmed] https://launchpad.net/bugs/1011053
[11:04] <cjwatson> I think the simplest fix for this is: remove libglew1.5-dev and libglewmx1.5-dev binaries, *then* rebuild all the reverse-deps (because libglew-dev Provides: libglew1.5-dev), then remove glew1.5 source
[11:04] <cjwatson> Anyone object to that?
[11:07] <Laney> poor celbalrai
[11:07] <cjwatson> There are no runtime deps on libglew1.5
[11:08] <cjwatson> Sorry, libglew1.5-dev
[11:08] <cjwatson> Or libglewmx1.5-dev for that matter
[11:11] <cjwatson> There are three seeded packages involved that I can see: enblend, hugin, and hugin-tools (all Kubuntu daily-preinstalled)
[11:18] <xnox> cjwatson: well. libglew is at 1.8 now. And did a transition tracker and it shows 43 bad packages.
[11:19] <xnox> so my guess is, no rush?!
[11:19] <cjwatson> Yes
[11:19] <cjwatson> Well
[11:19] <cjwatson> I want to clear the archive bug queue
[11:19] <cjwatson> It's non-urgent +1 work I suppose but it does have to be unstuck at some point
[11:43] <Riddell> no bot for the queue this time?
[11:43] <Laney> it's down
[11:45] <cjwatson> Riddell: 11:06 <cjwatson> xnox: needs stgraber to fix
[11:46] <Laney> perhaps we can run it on some shared machine
[11:50] <Daviey> Laney: write a juju charm for it. :)
[11:50] <cjwatson> Say his name and he shall appear
[11:51] <cjwatson> Riddell: Is startactive for beta-1?
[11:54] <Riddell> cjwatson: yep
[11:54] <cjwatson> OK, accepted
[12:04] <cjwatson> Daviey: can you write a juju charm to keep server team MIRs up to date?
[12:05] <Daviey> cjwatson: Unlikely.
[12:05] <cjwatson> I guess that needs more resources than are readily available in the cloud
[12:06] <Daviey> Yeah.  It might be easier to write a charm to distill flippant people :)
[12:07] <cjwatson> touché
[12:09] <cjwatson> though seriously, having horizon uninstallable due to unfiled MIRs three days before beta seems kind of suboptimal
[12:10] <cjwatson> (well, uninstallable when using only main)
[12:10] <cjwatson> and something in that stack is trying to pull python-support back in
[12:12] <Daviey> cjwatson: it doesn't require a MIR.. It requires work to remove the the C-M
[12:12] <cjwatson> OK ... is that work in progress?
[12:13] <Daviey> cjwatson: we don't want to pull node into Main.  It's only needed to compress some CSS.. which should be done at source package creation time IMO.
[12:13] <Daviey> cjwatson: yeah, it is.
[12:13] <cjwatson> OK, good
[12:14] <Daviey> cjwatson: well, two approaches are being investigated atm.. Compressing at source package creation time or making less,node/universe a suggests and doing a posh [ -f /usr/bin/node ] compress() at runtime.
[12:28] <psivaa> Laney, just a smal Q :)..
[12:29] <psivaa> Laney, I have just seen a few rebuilding but the pad does not say that in the history, will that be updated later?
[12:30] <cjwatson> psivaa: it's probably not realistic to rely on the pad having a full history, since it's pretty cumbersome to update
[12:31] <psivaa> cjwatson, ahh ok, thanks
[12:31] <cjwatson> Personally I think adding that to the pad was a bad idea - if history's important, can't we track this some other way that would be more reliable?
[12:31] <cjwatson> I guess reasons are hard to capture automatically though
[12:33] <psivaa> cjwatson, yea thats true, i was just wondering cuz i missed that there is a respin at the moment, but the iso tracker shows it though so that's fine by me
[12:33] <Daviey> cjwatson: I agree that pad's suck for this.  bzr would be far superior IMO, but at the very least wiki.
[12:34] <cjwatson> Well
[12:34] <cjwatson> What I'd actually like to do is complete and land my python rewrite of the cdimage tools, then write something on top which respins an image or set of images and reports the reason to some service
[12:35] <cjwatson> Any system where we have separate action and tracking-of-action is bound to fail
[12:35] <Daviey> oooo, that sounds ideal.
[12:55] <cjwatson> Laney,QA: So, respin status - how would that be affected by accepting c2esp?
[12:56] <cjwatson> Will let us fix a problem showing up on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[12:56] <cjwatson> (Which IMO should be clear before anything is even considered as a candidate, but what do I know ...)
[12:56] <cjwatson> Binaries from that source package are in nearly all non-core images, though
[12:57] <Daviey> cjwatson: horizon isn't shipped.. so no a candidate blocker IMO.
[12:57] <cjwatson> Right, that's supported-misc-servers so we can get away with that, but it would still help clear noise if it were fixed
[12:58] <cjwatson> The problem with ignoring noise manually is that we can't just say "it's green, next check"
[13:02] <xnox> Laney or others: above ubiquity fixes the warning label in ubiquity / arm images
[13:02] <cjwatson> And if we accept that, we'll need to respin most of everything anyway, so I think we should take c2esp too
[13:04] <cjwatson> psivaa: ^- above ten lines or so, assuming you're current QA contact on duty
[13:04] <psivaa> cjwatson, just reading it :)
[13:05] <cjwatson> I only see five test results posted so far, and those are on netboot
[13:10] <psivaa> cjwatson, i do not have any objections in including that on a respin if thats the question is..
[13:11] <cjwatson> It is, thanks
[13:15] <seb128> is there any chance we could get libreoffice considered if we respin?
[13:15]  * ogra_ thought that was already considered anyway 
[13:15] <cjwatson> What's its build status?
[13:15] <seb128> the armel build is running dh_builddeb
[13:15] <seb128> which is the last build to complete
[13:15] <cjwatson> ogra_: it's not on the pad
[13:16] <ogra_> oh, ok
[13:16] <ogra_> its just because so many people cared on the weekend that got me this impression
[13:16] <Laney> If it can be copied to -release then sure
[13:17] <seb128> well, we really should get the new one, the current archive one spams dbus appmenu to no end and creates 100% cpu use while lo is running
[13:17] <cjwatson> psivaa: ^- any objections?  don't know if much libreoffice testing has been done yet
[13:17] <seb128> it's spamming so much that unity,dbus keep using 100%cpu for a while after libreoffice is closed
[13:17] <ogra_> i should test on arm them with the current one ... sounds liek a good CPU stresstest :)
[13:17] <ogra_> *like
[13:17] <seb128> ogra_, ahah
[13:17] <cjwatson> seb128: ouch
[13:18] <seb128> cjwatson, yeah, they didn't the "update menu" plugged in at ff time and they though that having a "refresh every second" callback would be a good workaround
[13:18] <seb128> didn't have*
[13:18] <ogra_> hmm, apart from the fact that we dont seem to ship it currently
[13:18] <ogra_> on arm
[13:19] <ogra_> thats a histroical change we should probably revert
[13:19] <Laney> why is it like that?
[13:19] <ogra_> because we constantly had issues making the milestones due to slow builders
[13:19] <seb128> Laney, I guess it was not working on arm at some point...
[13:20] <Laney> hmm
[13:20] <seb128> or that ;-)
[13:20] <cjwatson> We've had to do that in the past as an emergency milestone band-aid, yeah
[13:20] <cjwatson> It's easy to forget to undo it after the milestone
[13:20] <ogra_> it always worked (somehow) but it always got in the way during milestones
[13:20] <Laney> should we undo it now?
[13:20] <psivaa> cjwatson, we do not do any manual release time libreoffice testing at the production level, so i would say that it does not affect ys
[13:20] <psivaa> 8us
[13:20] <psivaa> *us
[13:20] <Laney> still have a couple of publishers to wait at a minimum
[13:20]  * ogra_ greps for arm in the seeds ...
[13:20] <cjwatson> OK, so as long as it's installable basically
[13:20] <ogra_> ... and finds gnucharmap :P
[13:21] <cjwatson> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html has nothing relevant
[13:21] <ogra_> oh, its [i386 amd64] ... not [!armhf]
[13:21] <ogra_> so we dont ship it on ppc either
[13:29]  * ogra_ will revert that but keep that change for after beta so we can test first
[13:56] <Laney> yay, LO finished
[13:57] <seb128> Laney, \o/
[14:01] <plars> the -server versions are good I assume since they don't seem to be expected to be impacted by the things causing respins elsewhere?
[14:01] <Laney> right, the respins are all desktoppish so far
[14:01] <cjwatson> -server ships oem-config which comes from ubiquity
[14:02] <Laney> hmm
[14:02] <cjwatson> Though it won't actually be affected by the bug in question - it'd just be for the sake of version consistency
[14:02] <cjwatson> So I'll drop [6] from the pad there
[14:05] <cjwatson> Riddell: is kubuntu-active-meta for beta-1?
[14:05] <cjwatson> Looks likely, and you're respinning anyway I believe
[14:07] <cjwatson> Ah, there goes libcupsdriver1{,-dev}
[14:07] <cjwatson> So just evolution-exchange and horizon on quantal_probs now
[14:11] <Riddell> cjwatson: yep
[14:12] <cjwatson> OK, accepted
[14:17] <tjaalton> hey, I'm updating mesa to a newer snapshot, but there are two issues: it requires a newer libdrm (2.4.39 vs. 2.4.38 quantal has), and libglu has been split off from it, requiring a new package
[14:17] <tjaalton> libglu is packaged, but would need to go through NEW
[14:20] <tjaalton> libdrm would just need an ack to upload, not much changed there
[14:28] <cjwatson> I'm removing the whole sync-helper / backport-helper / mass-sync edifice from ubuntu-archive-tools; we haven't had any bugs that required their use for at least a month or two now, and with that flow it's perfectly feasible to just use syncpackage / backportpackage for the odd exceptional case
[14:34] <cjwatson> Docs updated accordingly
[14:34] <tumbleweed> which reminds me. ScottK: now that we have ubuntu-archive-tools' queue, do you still need dgetlp?
[14:39] <skaet> goodmorning cjwatson,  am about to start reading the logs, but anything on the urgent list from QA for today's images?
[14:40] <cjwatson> not AFAICS but I have mostly been clearing the archive bug queue
[14:40] <cjwatson> there's a pending respin of $most
[14:41] <cjwatson> (due mainly to a fairly important ubiquity bug)
[14:41] <cjwatson> [6] on the pad
[14:41]  * skaet seeing...
[14:42] <cjwatson> And I think there was consensus to copy over the new libreoffice
[14:42] <tjaalton> can I upload the new libdrm? only seven upstream commits on top of the current one http://paste.ubuntu.com/1183673/
[14:42] <cjwatson> Laney: ^- did that happen?
[14:42] <Laney> still publishing armel afaics
[14:42] <cjwatson> tjaalton: You can upload in any event and it'll land in the queue
[14:42] <ogra_> armel has no images
[14:42] <tjaalton> cjwatson: ok
[14:42] <Laney> it still needs to happen for the copy
[14:42] <cjwatson> tjaalton: We prefer to review things from the queue where possible - better tools for the job
[14:42] <tjaalton> cjwatson: understood
[14:42] <ogra_> ah, k
[14:43] <cjwatson> Laney: It's publishing at the moment - took it ~20 minutes to think about the attached translation tarball
[14:43] <cjwatson> Must fix that, that really doesn't have to be done on pepo
[14:43] <Laney> such joy
[14:44] <cjwatson> It's in ls-lR now, shouldn't be much longer
[14:44] <cjwatson> Actually it's published in every sense that matters for copying
[14:44] <cjwatson> So you might as well copy it now if you're going to
[14:45] <Laney> I've never copied anything
[14:45] <Laney> what's the incantation?
[14:45] <cjwatson> sru-release -r quantal libreoffice
[14:46] <cjwatson> in this case
[14:46] <Laney> ah
[14:46] <Laney> I would have reached for copy-package
[14:46] <cjwatson> That's the general form for -proposed => release copying
[14:46] <cjwatson> It's possible with copy-package too, but easier to use the canned tool even if it is a bit oddly named heree
[14:46] <Laney> will it break because I can't delete from -proposed?
[14:46] <cjwatson> *here
[14:46] <cjwatson> No - it won't delete
[14:46] <cjwatson> That gets GCed later semi-manually
[14:47] <Laney> fair
[14:47]  * Laney fires
[14:47] <cjwatson> Although, you have just as much access to -proposed as you have to the release pocket, no
[14:47] <cjwatson> ?
[14:47] <cjwatson> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Release' in quantal
[14:47] <cjwatson> Queue Administration Rights for ubuntu-release: archive 'primary', pocket 'Proposed' in quantal
[14:47] <Laney> I wasn't aware that let me delete
[14:49] <cjwatson> Oh, looks like deletion is restricted to the archive owner
[14:49] <cjwatson> OK *shrug*
[14:49] <Laney> nae mind
[14:49] <Laney> seems the copy worked anyhow
[14:49] <cjwatson> Yeah, like I say no deletion involved
[14:49]  * skaet marked Quantal Daily as released on iso tracker to avoid confusion now that Beta1 is online.
[14:50] <Laney> skaet: wasn't expecting to see you today ;-)
[14:50] <cjwatson> https://launchpad.net/ubuntu/quantal/+source/libreoffice/1:3.6.1~rc2-1ubuntu3 indeed
[14:50] <skaet> hiya Laney,  needed to finish off a couple of things, so figured better to work than worry.
[14:52] <Laney> fair cop
[14:52] <Laney> should be able to respin $world after next publisher then
[14:59] <cjwatson> I have to go out for a bit to return a couple of hired suits to the shop
[15:00] <cjwatson> Guess it'll take me an hour or so
[15:04] <Riddell> yay, queuebot!
[15:26] <iulian> Now we've got two of them!
[15:27] <Laney> ruh roh
[15:29] <iulian> :)
[15:30] <Laney> ubQueBot is running in the Canonical cloud
[15:32] <tumbleweed> but who is running it. Can we kill it now?
[15:33] <Laney> It Is A Mystery
[15:33] <tumbleweed> thanks to the unaddressed command syntax we can't just ask one to mute itself. (although we could kick one)
[15:37] <skaet> cjwatson, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/987418 - do you know if we're likely to get a fix for this, this week?
[15:37] <ubot2`> Ubuntu bug 987418 in ubiquity "manual partitioner: /dev/sdb (installation media) selected by default as device for boot loader installation" [High,Triaged]
[15:37] <Laney> ok, we apparently have LO published now
[15:37] <Laney> → spinning
[15:39] <skaet> Laney, can you take note of the time it gets for all of them to be spun now?   I'm estimating it will be about 3 hours.
[15:39] <Laney> OK, but I will be out in 3 hours
[15:40] <skaet> Laney,  did you spin from the commands on the pad?   if so,  I'll use the last published one as the estimate then.
[15:43] <Laney> skaet: yeah
[15:43] <skaet> cjwatson,  https://bugs.launchpad.net/ubuntu/+bug/1029351 needs to have a decision made about fix/not and priority assigned.
[15:43] <ubot2`> Ubuntu bug 1029351 in ubuntu "ISO testing: Cannot do an OEM installation a UEFI system" [Undecided,Confirmed]
[15:43] <skaet> ok Laney,  will use that then.
[15:44] <Laney> celbralai is the main bottleneck
[15:44] <Laney> but we're getting another arm image builder I understand?
[15:55] <skaet> infinity will know the details here.  Not sure what will come on line first more arm hardware for the isos or livefs in soyuz work.
[15:56] <ogra_> well, we need both :)
[15:57] <ogra_> still hoping we will get one of the highbank machines into the DC
[15:58] <ogra_> Laney, there is another mandaboax that should have been up since ages (20 pandas in a 4U case)
[15:58] <ogra_> *mandabox
[15:58] <Laney> yeah, I saw
[15:58] <Laney> at least one will be an image builder?
[15:58] <skaet> ogra_, can you look at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137
[15:58] <ubot2`> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
[15:58] <Laney> hahahaha, that bug, he loves it
[15:59] <skaet> it seems to have stalled out, and it staying in the state "incomplete" seems wrong.
[15:59] <skaet> ?
[15:59] <ogra_> skaet, we have a fix for it apparently, but ppisati want on vacation before we coudl do more with it
[15:59] <ogra_> *went
[15:59] <ogra_> and then to plumbers ...
[15:59] <skaet> ogra_, could you add a comment to the bug to that affect and mark it as inprogress then?
[16:00] <ogra_> i'll change to confirmed, no idea why jsailsbury has set it to incomplete
[16:00] <skaet> thanks
[16:00] <ogra_> (surely not on anyones request)
[16:02] <skaet> jamespage, could you please provide more info on: https://bugs.launchpad.net/ubuntu/+bug/1028458?  its sitting as incomplete.
[16:02] <ubot2`> Ubuntu bug 1028458 in ubuntu "iSCSI root based servers appear to fail to boot completely" [High,Incomplete]
[16:03] <jamespage> skaet, yes - missed that one - sorry
[16:03] <skaet> thanks jamespage
[16:04] <ogra_> skaet, erm, why did you open all these precise tasks ?
[16:04] <skaet> ogra_, based on infinity's comment it should be backported to precise.
[16:04] <ogra_> no, thats not possible easily
[16:05] <ogra_> jasper-initramfs handles it in precise
[16:05] <ogra_> (since natty actually)
[16:07]  * skaet stomped on ogra_'s update by accident,... unstomped.
[16:07] <ogra_> not sure if the kernel team will want to backport it ... its worked around in userspace, while kernel might be cleaner its not actually necessary
[16:29] <skaet> Laney,  what's it showing you on the terminal where you kicked things off,  I would have expected some to have published by now and not seeing queuebot reporting them or much on the iso tracker.
[16:29] <skaet> ?
[16:30] <Laney> still waiting for armhf
[16:30] <skaet> none of the alternates should be awiting on that, so I would have expected them to go through already.
[16:31]  * skaet wondering if 3 sessions were set up or just 1?
[16:31] <Laney> oh whoops, I forgot to do those :P
[16:31] <Laney> going
[16:32]  * skaet notes that Beta1 Technical Overview notes are now available for editing/updates by the leads.
[16:35] <Daviey> Ah ubQueBot was me.
[16:36] <Laney> sorry about the image failures, I noticed that I was going to respin server so had to kill it
[16:36] <Daviey> skaet: Can you mute ubQueBot please?
[16:37] <Daviey> Laney: why is server being span, i missed that?
[16:37] <infinity> ogra_: If there's a kernel fix for that that can be isolated and backported, it absolutely should be.
[16:37] <cjwatson> back, sorry for delay, had to take my bike to the shop for a couple of repairs
[16:37] <infinity> ogra_: jasper isn't the only installer we have, after all.
[16:37] <cjwatson> skaet: I'll look at those bugs; at the moment, since I've been away for a week, you should assume I don't know much about anything
[16:38] <skaet> cjwatson,  fair 'nuf,  and thanks.
[16:38] <Laney> Daviey: it is not. I ran a respin that included server by mistake, but aborted it before it got that far
[16:38] <Daviey> ahh
[16:38] <cjwatson> Daviey: mute> how about I just kick it?
[16:38]  * Laney wonders how long the lock is held for
[16:39] <Daviey> cjwatson: Well, seemed easy enough to keep it as a hot-spare.. no?
[16:39] <Daviey> I can just kill it if not.
[16:39] <cjwatson> You can start it up again if needed, surely, we don't need it hanging around all the time :)
[16:39] <cjwatson> I thought the point of the cloud was that you could bring instances up and down quickly
[16:40] <Daviey> smarty pants
[16:40] <infinity> Touché.
[16:42] <Laney> I have to go out now
[16:42] <Laney> hopefully someone can make it so we can spin alternates again ;-)
[16:42]  * Laney hides a bit
[16:43] <cjwatson> hm what?
[16:44] <cjwatson> Ubuntu alternate was intentionally disabled, AIUI
[16:44] <Laney> other alternates
[16:44] <cjwatson> Give me a specific example and I'll look
[16:44] <Laney> {x,k,l} afaics
[16:44] <infinity> Did you break the fragile locking mechanism somehow?
[16:44] <Laney> yes I did
[16:44] <infinity> *slowclap*
[16:44] <Laney> for-project xubuntu cron.daily
[16:44] <infinity> Yay for labor day, and my not caring.
[16:44] <Laney> see your nusakan mailbox for much spam
[16:45] <cjwatson> It only just arrived
[16:45] <infinity> Ooo, yay, my libreoffice upload actually built on all arches.  That's, like, some sort of miracle.
[16:45] <Laney> yeah, my apologies
[16:46] <cjwatson> Oh, I see, OK
[16:46] <cjwatson> I think just removing that file is correct
[16:46] <cjwatson> Done
[16:46] <cjwatson> I'll run Xubuntu alternate now as a test
[16:46] <Laney> cool
[16:47] <cjwatson> Yeah, that should be working now
[16:49] <cjwatson> skaet: bug 1029351 is an ubuntu-cdimage bug and should be relatively easy to fix, but it'll need any amd64 images built before the fix respun (not livefses)
[16:49] <ubot2`> Launchpad bug 1029351 in ubuntu-cdimage "ISO testing: Cannot do an OEM installation a UEFI system" [High,Triaged] https://launchpad.net/bugs/1029351
[16:51] <skaet> cjwatson,  ok.  have added it to the pad a a rebuild trigger.
[16:53] <skaet> ah good,  queuebot's announcing again.  :)
[16:54]  * Laney giggles at .7
[16:55] <skaet> Laney, cjwatson - there's Ubuntu DVD on pad,  that's not part of manifest for Quantal,  must be an oversite from 12.04.1 - removing
[16:55] <cjwatson> Laney: something wrong with it or just the number?
[16:55] <cjwatson> skaet: nowt to do with me :)
[16:55] <Laney> cjwatson: just the number yeah
[16:55] <Laney> we haven't been building the dvd, so yeah just delete the line
[16:55] <ogra_> infinity, sure, but thats a nice to have, not something that deserves critical or high bug prio
[16:57] <Laney> doing k/l alternates
[16:57] <cjwatson> ta
[17:01] <cjwatson> Rolled out fix for 1029351 immediately to minimise respin requirements
[17:01] <cjwatson> I think I was in time for Kubuntu
[17:02]  * Laney wonders where live images are
[17:02] <cjwatson> Which ones?
[17:02] <Laney> ah, CD image ubuntu/quantal/daily-live failed to build on 20120903.3
[17:02] <Laney> we got Xubuntu but I didn't see Ubuntu come out
[17:03] <Laney> so luckily you'll get your fix there too
[17:03] <cjwatson> Hmm, I think I was just a fraction too late for Kubuntu
[17:07] <Laney> kubuntu live is still building
[17:07] <Laney> livefs
[17:18] <skaet> Laney,  can you add a [9] to all the images that look they need to be respun to pick up cjwatson's latest?
[17:19] <Laney> I think it's just xubuntu
[17:19] <skaet> thanks
[17:19] <skaet> I wasn't sure from the comments if it was Kubuntu or not as well.
[17:20] <Laney> Kubuntu livefses are still going
[17:20] <skaet> k
[17:22]  * Laney sees no chinese edition on the pad
[17:27] <infinity> Mirv: https://code.launchpad.net/~adconrad/unity/gles-fixes/+merge/122558
[17:27] <skaet> Laney,  && env UBUNTU_DEFAULTS_LOCALE=zh_CN buildlive ubuntu daily-live && build-chinese-edition; date
[17:27] <Laney> I just added that ;-)
[17:27] <skaet> oh
[17:27] <skaet> :)
[17:27] <Laney> won't be in the current pipeline though
[17:28]  * skaet nods,  ok,  let me know if you leave before triggering it, and I'll kick it off from here.
[17:28] <Laney> I definitely will
[17:28] <Laney> loathe to put anything else onto celbalrai right now
[17:30] <cjwatson> Laney: Chinese edition images are amd64/i386 only
[17:30] <Laney> oh
[17:30] <skaet> That one is only for i386, amd64 so shouldn't be an issue though.
[17:30] <cjwatson> grep zh_CN ~/cdimage/etc/default-arches
[17:30] <Laney> there aren't any chinese arm users?
[17:30] <cjwatson> We don't cater for them in the Chinese edition images
[17:30] <cjwatson> If PES want it they can ask
[17:30] <skaet> http://china-images.ubuntu.com/quantal/daily-live/current/
[17:31] <Laney> 10 june eh
[17:31] <Laney> that looks healthy
[17:31] <skaet> http://china-images.ubuntu.com/precise/daily-live/20120902/
[17:31] <Laney> it is spinning
[17:32] <skaet> hmm... wondering how I got that precise in there...
[17:32] <skaet> interesting,  not seeing any i386 images in the latest quantal ones.
[17:32] <skaet> http://china-images.ubuntu.com/quantal/daily-live/20120831.1/
[17:33] <Laney> I see a fail from the 30th
[17:35] <cjwatson> Uh, I thought I'd finally managed to fix the quantal builds
[17:35] <cjwatson> (amd64)
[17:36] <cjwatson> amd64 was failing long-term until quite recently
[17:37] <cjwatson> i386 failed for a while following my live-build work
[17:37] <cjwatson> Error mail from build-chinese-edition must be buggy; damn those hacks
[17:37] <cjwatson> The livefses seem to be building fine
[17:38] <cjwatson> Oh, livecd-rootfs is meant to produce .iso for that image type but it's only giving us a squashfs
[17:39] <cjwatson> +  * Naming resulting binary isohybrid image binary.hybrid.iso from now
[17:39] <cjwatson> +    on for consistency with the different hdd images later on.
[17:40] <cjwatson> Sigh, GRATUITOUS CHANGES 'R' US
[17:41] <Laney> and we were expecting something else?
[17:41] <cjwatson> binary-hybrid.iso
[17:41] <Laney> classy
[17:41] <cjwatson> live-build upstream likes to change things around pointlessly for "consistency"
[17:42] <cjwatson> it's an utter pain in the arse
[17:42] <cjwatson> But hey, it must be better, it has an upstream
[17:42] <cjwatson> And PES use it
[17:42] <cjwatson> Love and fluffy kittens
[17:43] <cjwatson> livecd-rootfs 2.82 uploaded; please review once it hits the queue
[17:46] <Laney> I am being summoned to the Organ Grinder I'm afraid
[17:46] <Laney> Important date with 568.26ml
[17:47] <cjwatson> Yes, I have to go shortly as well
[17:47] <cjwatson> skaet: ^- please review livecd-rootfs?  it's a one-liner
[17:48] <cjwatson> Well, once LP gives you a diff in the queue, anyway
[17:48] <cjwatson> Oh, it's there now, I wonder why queuediff won't show it
[17:49]  * skaet looking
[17:51] <skaet> cjwatson,  done.
[17:51] <cjwatson> Thanks
[17:53] <skaet> Laney,  what's left to rebuild/kick off again?
[17:59]  * skaet --> lunch,  back in an hour or so.
[18:01] <slangasek> ogra_: is there a bug filed for the flickering?  I'm fine for it to be post-beta, but think it should get on the unity team's radar
[18:02] <ogra_> slangasek, seems its a kernel issue, i just talked to rsalveti in #ubuntu.arm
[18:02] <slangasek> ogra_: ok
[18:02] <ogra_> seems he also already has a fix
[18:02] <slangasek> cjwatson: looking at efilinux-signed
[18:02] <slangasek> cjwatson: btw, I'm working on shim here; need to do some tests to verify that I've got the cert embedding working correctly before I go uploading it
[18:06] <infinity> cjwatson: I'm not against switching back to livecd.sh and seeing how long it takes people to notice. :P
[18:07] <ogra_> ++
[18:07] <ogra_> and double plus !
[18:09] <slangasek> cjwatson: strange; linux-amd64, not amd64, for the arch?
[18:12] <infinity> slangasek: As opposed to linux-any or any-amd64, both of which would be wrong, I assume.
[18:12] <infinity> slangasek: Though, "amd64" on its own would have the same effect. :P
[18:12] <slangasek> infinity: as opposed to 'amd64', which is the canonical name for the arch :)
[18:13] <infinity> slangasek: Maybe it's a subtle hint that, with some mangling, it could be appropriate for any-amd64?
[18:13] <infinity> slangasek: Despite the name, I'm guessing it doesn't need to be linux-specific.
[18:14] <slangasek> infinity: I'm not going to speculate randomly about cjwatson's motivation :)
[18:16] <infinity> slangasek: It's labour day.  It's either speculate randomly, or accidentally work on your day off.  And you wouldn't be doing the latter, would you?  *suspicious look*
[18:16] <infinity> slangasek: Or, you can come share my narcotics.  Whee.
[18:17] <slangasek> infinity: oh, labour day?  I thought this was Libor day; sorry for the misunderstadning
[18:18] <phillw> it could not have fallen at a worse weekend :(
[18:18] <infinity> phillw: My kidney agreed.
[18:18] <infinity> s/agreed/agrees/
[18:19] <phillw> infinity: would http://pastebin.com/vns501PK be okay to send to the testers?
[18:19] <slangasek> infinity: get yourself some jagua fruit juice
[18:20] <phillw> the L-QA ones know me, I'm not sure about cc'ing ubuntu-qa mailing list.
[18:21] <infinity> phillw: Seems pretty negative.  I dunno.  Respins happen.  Lots of them just mean that people are paying attention? ;)
[18:21] <infinity> phillw: (And paying attention is something I've not been doing this weekend, so I'm not a good person to talk to about this)
[18:22] <phillw> infinity: well, the lack of any beta-1 for the whole weekend with the exception of minimal is quite a major mess up?
[18:23] <phillw> infinity: I'll just send it to lubuntu, we had nothing at all.
[18:24] <phillw> kate & nicholas are not about, they usually proof read my emails :)
[18:24] <phillw> I'll leave you guys in peace.
[18:50] <phillw> infinity: FYI, http://pastebin.com/SyzRjDCY is what got sent to L-QA
[20:15] <Daviey> phillw: erm, are you sure you've had 7 spins?
[20:22] <phillw> Daviey: not us, but the count is 20120903.7 for some, it was commented upon earlier, else I wouldn't even have noticed :)
[20:25] <Daviey> phillw: Maybe  misread your mail, but it sounded like Lubuntu had 7 spins today.
[20:26] <phillw> Daviey: not at all, it does state 'some'
[20:29] <Daviey> phillw: "one of the re spins is on .7 (Yes, that is 7 re spins in the same day)".. but ok
[20:29] <jibel> phillw, , xubuntu alternate is numbered .7 but have seen only 2 builds not 8, other builds were just attempts blocked by a lock file according to the build logs.
[20:29] <Daviey> To clarify,  .7 doesn't mean that any image was re-span 7 times
[20:30] <Daviey> It's also a global counter, not a per flavour/product/image counter.
[20:30] <gilir> skaet, indicator-applications-gtk2 uploaded, new review in NEW queue
[20:31] <skaet> thanks gilir, can you remind me of bug number?
[20:31] <phillw> Daviey: jibel believe it, or not, I was attempting to reduce the frustration factor of the testers. http://pastebin.com/SyzRjDCY I was being PM'd and had no information to give them
[20:32] <phillw> I'm working on this one now.
[20:32] <gilir> skaet, sure, bug 1044442
[20:32] <ubot2`> Launchpad bug 1044442 in ubuntu "Re-introduce indicator-applications-gtk2" [High,In progress] https://launchpad.net/bugs/1044442
[20:32] <skaet> Thanks gilir,  adding to pad.
[20:33] <gilir> skaet, thanks
[20:33] <skaet> ScottK,  could you help out by doing a review on ^ ?
[20:33] <Daviey> phillw: oh, sure.. appreciate that.. but i wanted to comment that your mail might have made it sound worse than it is :)
[20:34] <Daviey> gilir: The tracking bug really lacks, any, erm depth
[20:34] <knome> hey gilir :)
[20:34] <phillw> Daviey: it gets slightly worse, as Julien (Lubuntu) did not 'pull' lubuntu builds from the Friday build .. it was assumed
[20:36] <gilir> Daviey, I can give you any details you want :-)
[20:36] <Daviey> phillw: Oh, in Lubuntu world.. i can't comment. :).. But the suggestion of some images up to 7. things being a little haywire in -release, and post-mortems isn't accurate.
[20:37] <Daviey> gilir: The tracking bug would be better if it documented the reason for it's existence.. a plain "tracking bug" with no expansion is really hard to work out why it is tracking :)
[20:37] <phillw> Daviey: I was only refelcting an 'lol' from earlier on today on this channel
[20:37] <skaet> gilir,   +1 what Daviey says ;)
[20:38] <gilir> ok ok, I will add some details :-)
[20:39] <knome> skaet, beta1/techoverview updated to the best of my knowledge
[20:39] <skaet> thanks knome.  :)
[20:40] <knome> oh, there's that another section for known issues
[20:40] <gilir> skaet, and just to make it clear, if it's not fixed for Beta 1, it's not a blocker for Lubuntu
[20:40]  * knome will reorganize
[20:40] <knome> ^ done
[20:41] <phillw> whilst not wishing to get anyone into trouble for having a sense of humour ... (17:54:02) ***Laney giggles at .7
[20:42] <phillw> my apologies if I have caused offence
[20:42] <skaet> gilir, do you know if its a blocker for Xubuntu or Ubuntu Studio?
[20:43] <gilir> skaet, probably not if they removed it from the seed, but I can't talk for them :-)
[20:43] <Daviey> phillw: oh, none taken.. i just wanted to clear up any ambiguity. :)
[20:43] <skaet> gilir,  fair enough.
[20:44] <skaet> Daviey,  could you take a pass at reviewing the indicator-applications-gtk2 in new?
[20:44] <skaet> I'd like to get those images respun to include it before the testing gets started,  or at least have it ready to go if it does turn out to be a blocker for those teams.
[20:49] <Daviey> skaet: it's a real pain not having the full story in the bug, as to why it needs to be reintroduced.. etc.
[20:49] <Daviey> If it's because of the removal bug i'm thinking of.. it thought there was a compat package already?
[20:50] <gilir> Daviey, I added more details on the bug, tell me if you need more background about the issue
[20:50] <Daviey> ah, thanks gilir :)
[20:51] <skaet> Daviey,  it came up in the status' last week.  ie.  https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001850.html
[20:51] <Daviey> gilir: is this just to unlock for beta.. or are you expecting this NEW to be in final quantal?
[20:54] <gilir> Daviey, we expect it in final quantal
[20:54] <Daviey> gilir: The status mail states it's to fix build failures, but the only xubuntu set one i can see is.. https://launchpad.net/ubuntu/+source/libopenraw/0.0.9-3 ?
[20:56] <gilir> Daviey, probably because indicator-applications-gtk2 was part of the seed at some point, which may cause a build failure of ISO
[20:56] <Daviey> ahh, i thought it was package build failures.
[20:57] <gilir> Daviey, but I don't think it's now the case, as they remove it from their seed
[21:01]  * skaet not sure why Laney added the preinstalled and ARM builds in with the rest of the desktop....   rearranging pad.
[21:02] <Daviey> gilir: ugh.. the diff from when this was last in the archive is much larger than i expected.. http://pb.daviey.com/C4DP/
[21:08] <gilir> Daviey, because it's rebased on upstream version 12.10.0 which is in quantal, but not in precise
[21:08] <gilir> Daviey, and I think most of the diff is autofoo changes because of the new version
[21:09] <Daviey> gilir: ahh, debian/changelog made me think it was based off precise
[21:10] <skaet> seb128, around?
[21:11]  * skaet sees not
[21:26] <cjwatson> slangasek: I was matching efilinux, which is a Daniel Baumann package
[21:26] <cjwatson> He tends to overspecify
[21:27] <Daviey> gilir: accepted.
[21:28] <cjwatson> Daviey: the .7 counter is per flavour/product/image, not global
[21:28] <cjwatson> Daviey: you may have been misled by the fact that I never got round to making it per-series
[21:31] <Daviey> cjwatson: Hmm, I don't follow.. I was sure i had seen flavours jump when other flavours were built inbetween.
[21:31] <cjwatson> I've never been aware of that being the case
[21:31] <cjwatson> It's been per flavour/image since 2005
[21:32] <Daviey> cjwatson: ok, i must be mistaken.
[21:32] <cjwatson> STAMP="$CDIMAGE_ROOT/etc/.next-build-suffix-$PROJECT-$IMAGE_TYPE"
[21:32] <cjwatson> is the relevant line
[21:39] <Daviey> cjwatson: Hmm.. Can you grok why there wasn't a ubuntu-server .1 today? http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/quantal/ ?
[21:39] <gilir> Daviey, great, thanks :-)
[21:39] <Daviey> cjwatson: I mean, it's clear that you are correct.. i just want to understand why i thought i had seen jumps before.
[21:40] <cjwatson> Daviey: As I say, the count (buggily) isn't per-series
[21:40] <cjwatson> Daviey: So if there are precise and quantal builds both happening daily, one will get <date> and the other will get <date>.1, depending on which comes first
[21:41] <Daviey> ahh
[21:41] <cjwatson> Daviey: compare http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/precise/ and you should find it fills in the gaps
[21:41] <Daviey> yep, thanks cjwatson
[21:42] <cjwatson> This is certainly confusing and I plan to fix it at some point
[21:42] <cjwatson> It just isn't very high priority :-)
[21:42] <Daviey> i'd say it was sub-low priority
[21:43] <cjwatson> It's only not no priority because it confuses people and thus indirectly takes up time
[21:45] <cjwatson> slangasek: I'm going to move efilinux-signed to universe because it needs to be at least as far out as efilinux, which hasn't been MIRed yet
[21:45] <cjwatson> (in order to build)
[21:45] <cjwatson> Though I perhaps ought to deal with a MIR there at some point
[21:58] <cjwatson> OK, so working with a current desktop image in kvm is now barely usable again, but unity is horrifically slow and it's even slowing down my host desktop.  Do any of you good folks have a trick for making it reasonable again?  Otherwise I'm going to have serious trouble working on any installer bugs.
[22:00] <cjwatson> Well, it's a little less awful once I get as far as starting ubiquity.
[22:07] <plars> is a respin really going to happen on server? skaet mentioned it earlier, but I haven't seen it reflected on iso tracker yet
[22:15] <skaet> plars,  Laney said he started them off on order listed on pad.ubuntu.com/ubuntu-release, and based on that I'd have expected them to have published by now
[22:16] <skaet> so,  given that respin wasn't necessary for them, not sure if they should be respun or not at this point.
[22:16]  * skaet is just expecting WUBI to show up now
[22:17] <plars> skaet: that's good by me then :)
[22:17] <cjwatson> The last ubuntu-server respin that happened started at 12:02 UTC
[22:17] <cjwatson> Somebody with more brain can correlate that
[22:22] <skaet> hmm,  that seems a bit weird.  one on iso tracker right now is from 12:09 UTC.
[22:24] <cjwatson> That's consistent.  :02 was the start time.
[22:24] <cjwatson> :09 would have been about when the i386 build finished.
[22:26] <skaet> yeah, but amd64 finished at :06, and the armhf+omap4 image at :08,  manifests put in there from a couple hours prior.
[22:27]  * skaet suspects the respin is going to happen, its just locked behind WUBI at the moment. :P
[22:28] <skaet> http://cdimage.ubuntu.com/ubuntu-server/daily/20120903.2/
[22:30] <cjwatson> skaet: That all looks entirely normal
[22:30] <cjwatson> I expect there was a long queue of livefs builds in the morning
[22:30] <cjwatson> The ISO9660 part was the part that started at 12:02, not the livefs building part
[22:33] <slangasek> cjwatson: ok
[23:25] <bdrung> can someone accept ncurses in oneiric-proposed?
[23:55] <xnox> kubuntu is affected by bug 1038522
[23:55] <ubot2`> Launchpad bug 1038522 in ubiquity "manual partitioning in installer crashes" [High,Confirmed] https://launchpad.net/bugs/1038522
[23:55] <xnox> this is unrelated to the recent ubiquity bugs in the gtk frontend.
[23:55] <xnox> Some comments on the duplicates are rude.