[05:36] <ScottK> That should do it.
[06:40] <mlankhorst> can llvm-3.2 and wayland-lts-raring be moved to main?
[06:40] <mlankhorst> they seem to be in universe atm
[07:44] <infinity> mlankhorst: Yep.
[07:46] <infinity> mlankhorst: Done.
[07:49] <infinity> Anyone have issues with me releasing my own debmirror SRU, so I get the copy-from-quantal-to-raring bits right?
[07:50] <mlankhorst> ok hopefully mesa-lts-raring will build again now
[08:33] <cjwatson> jibel: Do you have any idea why libgdata got stuck in RUNNING on i386 last night?  (See scrollback from 22:56 UTC or so onwards.)
[08:33] <cjwatson> infinity: Fine by me, though I guess it wants a couple more days?
[08:37] <jibel> cjwatson, no, I haven't found the reason yet.
[08:42] <infinity> cjwatson: I doubt two more days will get it any more testing.  I've been adjusting that threshold based on some sort of common sense for other people's SRUs.  For my own, admittedly, I don't like to be the one who makes that decision in a bubble. :P
[08:42] <jibel> cjwatson, it is because i386 tested libgdata with gnome-online-accounts 3.8.2-1 but the request was for 3.8.2-1ubuntu1
[08:44] <jibel> the test ran before the package is in the archive, I filed an RT to use ftpmaster meanwhile, I can loop until the right version is there but that will allocate testing slots just for waiting
[08:44] <infinity> jibel: Implement an external wait-for-package trigger that sits between the request and the actual test?
[08:45] <cjwatson> jibel: Possibly because adt-britney only has amd64 in its mirror
[08:45] <cjwatson> But yeah, you need to use ftpmaster.internal
[08:45] <cjwatson> infinity: Better to use an archive that's guaranteed at least as up to date as what proposed-migration is using
[08:46] <infinity> cjwatson: Assuming proposed-migration doesn't request things that are subject to arch skew, yeah.
[08:46] <infinity> If its requests are guaranteed to always be satisfied by ftpmaster, then that solves that.
[08:48] <cjwatson> For tests requested for the migrating package itself, that's guaranteed because we won't make the request until amd64 and i386 are up to date, and we only run tests for those
[08:48] <cjwatson> For tests requested for reverse-dependencies, I'm not sure; it's possible in some cases jenkins would have to retry
[08:50] <cjwatson> (The configured aptroot is for saucy-proposed-amd64; I don't know how much that matters to adt-britney)
[08:50] <cjwatson> It has an apturi which is effectively a full mirror of relevant bits of dists/
[09:22] <psivaa> bdmurray: reported bug 1200135 for a r->s upgrade failures
[09:22] <ubot2`> Launchpad bug 1200135 in ubuntu-release-upgrader (Ubuntu) "Raring to saucy upgrade fails with "AttributeError: Values instance has no attribute 'devel_release'"" [Undecided,New] https://launchpad.net/bugs/1200135
[11:28] <rbasak> Daviey: I thought we were going to trump the previous facter SRU and then I'd verify them all at once?
[11:29] <infinity> rbasak: The previous one's been in proposed for over a month, why not just verify it and release it today?
[11:31] <rbasak> infinity: I just thought I could save an interation of verification, that's all. I thought we were going to trump the previous one and verify them all at once, which is why I've been waiting.
[11:31] <rbasak> iteration
[11:31] <Daviey> rbasak: Oh, i didn't realise your queued upload had both fixes present.  I thought that was the /next/ one.
[11:32] <Daviey> infinity: I did indeed say to rbasak that the issues were suitably separated that doing double verification would be OK with this.
[11:32] <infinity> rbasak: Also, if you'd intended to trump the previous one, building with -v and a .changes including both would have been a good hint.
[11:32] <rbasak> Daviey: should be the same either way, right? I'd always include previous fixes in a new upload
[11:32] <infinity> rbasak: But my argument above was just that we could be releasing those month-old ones today, if they were verified, adding on top of them is a new wait.
[11:34] <Daviey> infinity: I'd agree with that if it was someone else waiting on this, or willing to verify it.  But it seems to be rbasak working on this without the original reporters support.  The time to setup an env, is better spent doing both at once IMO.
[11:34] <Daviey> If they've been waiting 36 days without asking, waiting another 7 is reasonable IMO
[11:34] <rbasak> infinity: OK, -v noted for next time, thanks. They weren't month-old when I first proposed the new fix. I thought a plan was agreed at that time. Yeah, the original reporter no longer cares, so I'm prepared to still see iit through but I no longer see any urgency on it.
[11:36] <infinity> rbasak: Anyhow, I have no strong opinion on the matter.  Do whichever thing seems to work best.
[11:36] <rbasak> OK. If it is possible to trump the previous one and verify everything across all releases and both uploads at once, then I'd prefer to do that, please.
[11:38] <Daviey> rbasak: the in-queue upload is only for precise? bug 986973
[11:38] <ubot2`> Launchpad bug 986973 in facter (Ubuntu Precise) "Facter bug causes puppet to hang" [Medium,In progress] https://launchpad.net/bugs/986973
[11:40] <rbasak> Daviey: yes. It's very difficult to verify, but I can do it on Precise as I happen to have a server that's intermittently failing because of the bug on Precise already.
[11:41] <rbasak> I'm concerned that we don't be able to verify Quantal at all.
[11:47] <cjwatson> FWIW it looks as though we should be able to get the Apache 2.4 transition landed this weekend or so
[11:48] <cjwatson> May still need to remove a few intransigent packages
[11:51] <rbasak> I'm still working on php5. Having some issues with mysql tests breaking. I can fix it - it's just taking some time every time I attempt a rebuild.
[11:53] <cjwatson> rbasak: thanks
[11:53] <cjwatson> Let me know if you need help
[12:00] <ogra_> bah, grmbl
[12:00] <ogra_> exporting $NOW in BuildLive\cd obviously doesnt work, i need to hand it to the lb config call :(
[12:00] <cjwatson> No
[12:01] <cjwatson> You need to actually write it into config/binary
[12:01] <ogra_> well, that i do in config/auto
[12:01] <ogra_> err
[12:01] <ogra_> auto/config
[12:02] <cjwatson> No, you don't
[12:02] <cjwatson> You set a shell variable BUILDSTAMP="${NOW}" in live-build/auto/config, and then do nothing with it so it has no effect
[12:02] <ogra_> err, i'm talking about my current local build indeed
[12:02] <ogra_> :)
[12:03] <cjwatson> I'd expect something like http://paste.ubuntu.com/5864713/
[12:03] <cjwatson> Ah, but it's true that you do actually need to pass it through the sudo call
[12:03] <ogra_> that puts a hook in place that actually does something with $NOW ... the prob is that i only have it available if i hand it to the lb config chroot call, the export doesnt suffice
[12:04] <cjwatson> So http://paste.ubuntu.com/5864717/ I guess
[12:04] <ogra_> which is much annoying since that means waiting for IS again
[12:04] <cjwatson> Yes, which is why this should have been tested locally before asking for IS to deploy it in the first place :-(
[12:05] <ogra_> yeah, i prefixed it, but its the same
[12:05] <ogra_> can i see config/binary from inside the build chroot ?
[12:06] <cjwatson> live-build/auto/config already writes to config/binary, and live-build/auto/build already reads it
[12:06] <ogra_> effectively  i need it to end up in /var/log/installer/media-info which means i need to read from cionfig/binary
[12:06] <cjwatson> So you shouldn't need to do anything extra there
[12:07] <ogra_> ah, k
[12:07] <cjwatson> I *think* the patch above should be sufficient, but it should be tested ...
[12:07] <ogra_> yeah, thats more elegant than a hook
[12:07] <ogra_> yep, let me stop the current build and test again ...
[12:07] <cjwatson> Well, arguably.  I think I would actually have used a hook if I'd been doing it myself.
[12:07] <cjwatson> But I went with your approach.
[12:07] <ogra_> btw, we should really have a script that sets up the chroot structure :P
[12:08] <ogra_> took a whie until i had everything in place for a testbed
[12:11] <cjwatson> I believe that IS use modules/schroot/files/make-chroot.sh in lp:canonical-is-puppet.
[12:11] <cjwatson> (Which is private, sorry)
[12:11] <ogra_> ah
[12:12] <cjwatson> Should be visible to ~canonical
[12:12] <ogra_> well, i have it up now
[12:13] <ogra_> and my chromebook is so much faster than the panda :)
[12:13] <ogra_> (though that might be more related to the USB 3 disk than to the chromebook itself)
[12:15] <ogra_> cjwatson, another request i get all the time is to have a stamp in the cdimage output dir that phablet-flash can read, should i create that on the live builder or is it enough if cdimage creates it at publishing time
[12:15] <ogra_> (i guess the latter, but thought i'd rather ask)
[12:16] <ogra_> (pulling from /current wont give us any info about the used image otherwise)
[12:18] <cjwatson> ogra_: If it's going to be anything like http://cdimage.ubuntu.com/ubuntu-touch-preview/daily-preinstalled/current/ubuntu_stamp, that's too complex for cdimage to create itself - it should be done on the live builder and fetched by cdimage
[12:19] <ogra_> ok
[12:19] <ogra_> cjwatson, oh, no, it wont be that complex
[12:20] <ogra_> it should only include the actual build stamp ... )
[12:20] <ogra_> err
[12:20] <ogra_> :)
[12:20] <cjwatson> If it's just the build ID, cdimage can create that, but "ubuntu_stamp" is a poor name since it should be done generically for all flavours
[12:20] <ogra_> it is just that QA cant tell what image they test when pulling from  /pending or /current
[12:21] <ogra_> (and phablet-flash also kind of uses it)
[12:21] <cjwatson> However, you need to be careful since a single file for the whole directory won't work
[12:21] <cjwatson> I would suggest perhaps an extra per-architecture .id file
[12:21] <ogra_> well, the versioned dir works too atm
[12:21] <cjwatson> Sure, but still
[12:22] <ogra_> it should effectively just tell where the current or pending link points to, not more
[12:22] <cjwatson> The set of images in current do not necessarily all have the same build ID
[12:22] <cjwatson> current is not necessarily a link
[12:22] <cjwatson> In general each architecture may have a different build ID
[12:22] <ogra_> they will have the same build id soon ...
[12:22] <cjwatson> No.
[12:22] <ogra_> seems xnox  succeeded with the android packaging
[12:22] <cjwatson> I said *in general*, not for touch
[12:23] <ogra_> so all files in there will come from the same build
[12:23] <ogra_> oh, ok
[12:23] <cjwatson> And this should be done in a general way, not in a touch-specific way
[12:23] <cjwatson> It would be useful for something gema mentioned the other day too
[12:23] <cjwatson> I think
[12:24] <xnox> ogra_: it will be possible in the future to split the builds and have a source package per device (empty), which would build-dep on android-source package, blobs, toolchain. Cause i'd want to be able to rebuild individual devices.
[12:24] <ogra_> well, a per file stamp will surely require a lot of changes to phable-flash
[12:24] <ogra_> or per subarch
[12:24] <cjwatson> I didn't say per-file; I said per-architecture.
[12:24] <cjwatson> I didn't say per-subarch either.
[12:24] <ogra_> oh, ok
[12:24] <cjwatson> So for touch it would in practice be a static file name.
[12:24] <ogra_> so armhf-buildstamp or some euch
[12:25] <ogra_> ok
[12:25] <cjwatson> I was thinking saucy-preinstalled-touch-armhf.id.
[12:25] <ogra_> yeah, indeed with the proper prefix
[12:25] <cjwatson> The more regular the file names are, the less complex cdimage code has to be.
[12:25] <ogra_> yep
[12:43] <chrisccoulson> hi, adobe-flashplugin is currently sat in the proposed pocket in partner. is someone able to copy that to release?
[12:44] <jdstrand> in the past I've done it, is this something I can still do for partner in the age of britney?
[12:48] <cjwatson> jdstrand: Yes, since partner isn't controlled by proposed-migration
[12:48] <jdstrand> ok. I thought so, but wasn't sure if anything changed
[12:49] <jdstrand> chrisccoulson: I'll do it
[12:49] <cjwatson> jdstrand: And in any case proposed-migration only controls the development release, not stables
[12:49] <chrisccoulson> thanks
[12:49] <jdstrand> ah true
[16:19] <rtg> infinity, is this a build bug ? https://launchpadlibrarian.net/144716089/buildlog_ubuntu-saucy-armhf.linux-mako_3.4.0-3.16_FAILEDTOBUILD.txt.gz
[16:19] <rtg> builder bug*
[16:20] <infinity> rtg: Seems unlikely.
[16:20] <rtg> hmm
[16:21] <infinity> rtg: I'll retry it to see if it was cosmic rays, though.
[16:22] <rtg> infinity, it just seems bizarre. the only string changes were:
[16:22] <rtg> -CONFIG_DEFAULT_IOSCHED="cfq"
[16:22] <rtg> +CONFIG_DEFAULT_IOSCHED="deadline"
[16:24] <infinity> Toolchain changes between the builds?
[16:24] <infinity> But yeah, it could have been random corruption.  One never knows how that could manifest.
[16:25] <infinity> If the retry fails the same way, we can start hunting.
[16:25] <infinity> It was only an hour and a half in.
[16:25] <rtg> infinity, this used gcc-4.7 (which I don't think has been updated recently)
[16:25] <infinity> Note since June 18th.
[16:25] <infinity> s/Note/Not/
[16:26] <rtg> infinity, I think I uploaded it twice yesterday
[16:26] <infinity> Yeah, you did.
[16:26] <infinity> So, let's assume cosmic rays for now.
[16:26] <rtg> will do
[16:26] <infinity> My kingdom for buildds with ECC RAM.
[16:27] <rtg> couple weeks yet ?
[16:27] <infinity> In transit to London.  Could still take some effort to get it all online and installed once there.
[16:27] <infinity> Should be happy around sprint time.
[16:27] <infinity> Maybe earlier.
[16:27] <rtg> cool
[16:30] <infinity> Then again, I've been pomising (and promised) these systems for a while, so we'll see when they're actually online and running, shall we? :P
[16:31] <infinity> rtg: http://frylock.redvoodoo.org/~pgraner/4372123.jpg :P
[16:31] <rtg> :)
[23:00] <bdmurray> Could somebody have a look at approving my upload of ubuntu-release-upgrader to raring-proposed?