[02:19] <cjwatson> Our livefs builds are now all using Launchpad, except for ubuntu-touch for which I'll wait till I can double-check with ogra in the morning.
[02:20] <cjwatson> I'll sort out trusty builds in the morning.  We can't quite use PROPOSED=1 yet, but that's one deployment away.
[02:24] <cjwatson> But at least that means this milestone can have much quicker respin cycles if needed.
[03:26] <stgraber> cjwatson: thanks for mentioning it, I completely forgot about alpha-1... Just sent the usual e-mail out to ubuntu-release and I'll be taking care of the rest tomorrow.
[08:12] <xnox> cool!
[09:02] <infinity> cjwatson: \o/
[09:22] <apw> cjwatson, excellent, looking forward to T dailies to sidestep some install issues
[10:55] <cjwatson> infinity: Do we have a list anywhere of which flavours intend to release with the trusty point release?
[10:56] <infinity> cjwatson: Given that all of them have LTS status this time, the assumption would be "everyone" unless someone opts out.
[10:57] <cjwatson> OK
[11:00] <cjwatson> Done
[13:00] <zul> can an archive admin put python3-tornado in main, python-tornado is in main and its blocking a new python-httpretty please?
[13:07] <infinity> zul: Yeahp.
[13:07] <zul> infinity:  thanks
[13:10] <infinity> zul: Done (will publish in ~30m or something).
[13:11] <zul> infinity:  thanks again
[13:12] <infinity> zul: Did python3-oslotest too, which was blocking another of your uploads.
[13:12] <zul> cool! thanks
[14:03] <infinity> zul: Your python-sure upload seems to have missed the part where the binary packages also depend on -rednose...
[14:03] <zul> infinity:  crap ill fix it up
[14:05] <infinity> Makefile:	@nosetests -s --verbosity=2 tests --rednose
[14:05] <infinity> zul: Looks like you'll need to fix that too.
[14:06] <infinity> zul: Alternately, do an MIR for python-rednose?
[14:06] <infinity> zul: Not sure it's worth carrying deltas for this.
[14:13] <zul> infinity: yeah MIR would be best i think
[14:31] <cjwatson> Hm.  So, we have a bit of a problem for trusty image builds.  (Running one right now to demonstrate it)
[14:32] <infinity> cjwatson: Hrm?
[14:32] <cjwatson> We added ${Signed-Kernel-Stem}-generic [amd64] to the live seed in quantal or so to support secure boot
[14:33] <cjwatson> I had to hack up livecd-rootfs in precise post-release to deal with the fact that nothing updates tasks post-release (or even can update them, without regenerating Packages)
[14:33] <cjwatson> In retrospect this should have been an alarm bell
[14:33] <cjwatson> Because now the *-live tasks in trusty include linux-signed-image-3.13.0-24-generic etc.
[14:35] <infinity> cjwatson: Fixable by extending ubuntu-chroot_headers_tidy.patch to do all kernel-related packages instead.
[14:35] <cjwatson> As it happens livecd-rootfs expands the task manually because live-build removed support for it, so I guess we could make it filter out the kernels
[14:35] <infinity> Oh, except that the new apt autoremove stuff will thwart us.
[14:35] <cjwatson> And then add_package live linux-signed-generic
[14:36] <cjwatson> I think I'd prefer to do this mangling in livecd-rootfs, probably
[14:36]  * infinity nods.
[14:36] <cjwatson> Of course I won't be able to verify an SRU until launchpad-buildd 123 is deployed now ...
[14:37] <cjwatson> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu/+build/57 should show the problem in a bit
[14:37] <infinity> Err, wait, what do you mean about livecd-rootfs expanding the task manually?
[14:37] <infinity>         add_task live "$LIVE_TASK"
[14:38] <infinity> That doesn't look very manual...
[14:38] <cjwatson> Look at the add_task function
[14:38] <infinity> Oh.
[14:38] <infinity> Derp.
[14:38] <cjwatson> It's painfully manual :)
[14:39] <infinity> Doesn't live-build just use apt-get install against the package lists?
[14:40] <infinity> In which case "task support" would just mean adding a package named task^
[14:41] <infinity> Anyhow, not that that solves your -signed problem...
[14:43] <cjwatson> infinity: I think that didn't work for some reason; pretty sure I would have tried things like that before writing that add_task function :)
[14:43] <cjwatson> It doesn't seem like the sort of thing that would have been my first resort
[14:43] <infinity> cjwatson: Maybe you felt that file was suffering a shortage of backslashes.
[14:47] <infinity> cjwatson: Any idea what's up with https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/precise/ubuntu-zh-cn/+build/56 ?
[14:52] <infinity> cjwatson: Also, looks like buildlivefs is leaking locale environment.
[14:52]  * stgraber begins to wonder if we may end up skipping alpha-1 entirely, so far nobody said they'd participate :)
[14:52] <infinity> stgraber: I'll participate.  I'd like a freeze of the base system for ubuntu-core, please.
[15:01] <cjwatson> infinity: poking webops.  wdym about buildlivefs?
[15:02] <infinity> perl: warning: Setting locale failed.
[15:02] <infinity> perl: warning: Please check that your locale settings:
[15:02] <infinity> 	LANGUAGE = "en_GB:",
[15:02] <infinity> cjwatson: That sort of business.
[15:02] <xnox> smoser: ^ are ubuntu cloud images doing an alpha-1 ?!
[15:02] <infinity> cjwatson: Nothing gives livefs builds the same LANG=C treatment that sbuild-package does.
[15:02] <xnox> smoser: if yes, ask stgraber to freeze cloud images as well.
[15:02] <stgraber> xnox: that'd be utlemming
[15:02] <xnox> stgraber: oh, right.
[15:03] <xnox> stgraber: as far as i recall, cloud images did do all milestones typically.
[15:03] <infinity> cjwatson: It's entirely possible doing this over and over again in helpers is, of course REALLY STUPID, and we should just cleanse the environment once and for all at the top level of the daemon.
[15:03] <utlemming> xnox: yes, we'll be doing an aplha-1
[15:03] <stgraber> utlemming: mind replying to my e-mail then? :)
[15:04] <smoser> good. thanks.
[15:04] <stgraber> xnox: yeah, so did Kubuntu and Edubuntu, but things have been known to change and those milestones are opt-in, not opt-out :)
[15:05] <utlemming> stgraber: done
[15:05] <stgraber> utlemming: thanks
[15:11] <shadeslayer> btw where can I find documentation to read update_output.txt from britney?
[15:13] <cjwatson> shadeslayer: https://wiki.ubuntu.com/ProposedMigration
[15:13] <shadeslayer> thx, I keep loosing that link
[15:15] <cjwatson> infinity: http://paste.ubuntu.com/7690820/
[15:16] <shadeslayer> cjwatson: btw we /might/ not require PPA handling on the cdimage site
[15:16] <shadeslayer> *side
[15:16] <infinity> cjwatson: kernels are 700, is that trying to read it as the buildd user?
[15:17] <cjwatson> shadeslayer: ok ...
[15:17] <infinity> cjwatson: Note that BuildLiveCD had:
[15:17] <infinity>         for file in ${DIR}livecd.*; do
[15:17] <infinity>                 sudo chown buildd ${file}
[15:17] <infinity> To work around the issue.
[15:17] <cjwatson> infinity: Could be.  live-build/auto/build applies chmod 644
[15:18] <shadeslayer> KDE's desktop stuff might get montly bug fix releases, which I'll try to get MRE'd
[15:18] <cjwatson> I'd rather fix this in ubuntu-defaults-image, I think
[15:18] <cjwatson> It's pointless for the kernel to be 700 in image output
[15:18] <cjwatson> Inside the image, sure
[15:19] <infinity> 600, not 700.  Brain not on today.  But yeah.
[15:22] <infinity> cjwatson: Hrm, we also lost the eatmydata usage when switching from BuildLiveCD to lp-buildd ... Intentional or accidental?
[15:22] <infinity> cjwatson: On the SATA buildds (which is most of them), I suspect that'll make a difference.
[15:27] <cjwatson> infinity: Was never deployed and I don't think it actually worked
[15:27] <cjwatson> infinity: https://code.launchpad.net/~cjwatson/launchpad-buildd/livefs/+merge/193682 has a note about that
[15:29] <infinity> cjwatson: Oh, that BuildLiveCD never went into puppet?  Kay.  Nevermind, then.
[15:30] <cjwatson> I wouldn't be sad if you figured out how to make it work in lp-buildd, though
[15:35] <infinity> cjwatson: Well, I'm not entirely convinced it helps a lot either.
[15:35] <slangasek> AttributeError: 'NoneType' object has no attribute 'timeout'
[15:35] <slangasek> ?
[15:35] <cjwatson> Yeah, on my queue
[15:35] <slangasek> ok
[17:03] <cjwatson> slangasek,infinity: I've uploaded a fairly large stack of installer changes to precise at the request of CTS, to enable HTTPS support for 12.04.5.  Could somebody review?  The relevant packages are base-installer, debian-installer-utils, debootstrap, wget, choose-mirror, apt-setup, kickseed, rootskel (and debian-installer will need an upload too once the rest are in)
[17:03] <cjwatson> These are all pretty straight backports; only choose-mirror required much in the way of adjustment
[17:06] <infinity> cjwatson: I'll have a look.  d-i needs lts-trusty added too, which I was going to do today.
[17:07] <cjwatson> Right.  Let me get my bits committed at least then.
[17:10] <cjwatson> (done)
[18:00] <arges> cjwatson: hi. For bug 833994, does debian-installer also need to be updated? (making sure it wasn't missed.) thanks
[18:01] <infinity> arges: It'll get updated anyway.
[18:02] <arges> infinity: ok. so after stuff gets tested debian-installer may be updated I take it?
[18:04] <infinity> arges: s/tested/built/
[18:04] <arges> ah gotcha
[18:04] <infinity> arges: Well, d-i's being uploaded for other reasons too, but yeah.
[18:59] <wxl> stgraber: hey, i'm having some mailing list issues, but i did want to say that Lubuntu plans on participarting in all milestones
[18:59] <wxl> (hah, 1m before 2100)
[18:59] <wxl> oh wait, no i'm doing my math wrong. ignore me.
[19:06] <stgraber> wxl: ok
[19:06] <stgraber> wxl: yeah, you still had two hours to go :)
[19:25] <jdstrand> I'm not sure if this will block the apparmor migration: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scopes-api/lastBuild/?
[19:25] <jdstrand> but those failed builds have nothing to do with apparmor
[19:38] <stgraber> wxl: I've setup the ISO tracker now and have disabled cron for lubuntu, so feel free to just trigger a daily image rebuild on iso.qa.ubuntu.com once you're ready to start testing for alpha1
[19:51] <wxl> stgraber: forgive me for being the noob release manager, but how do i trigger this? through the tracker itself?
[19:52] <stgraber> wxl: yes
[20:31] <wxl> stgraber: i don't see any images on there to tell to rebuild. are they being manually copied over?
[20:31] <stgraber> wxl: look in the daily milestone
[20:31] <stgraber> wxl: you'll only see images show up in the alpha-1 milestone once you first build one
[20:31] <wxl> ahhhh
[20:45] <wxl> stgraber: it'll take me a bit. seems as if our fearless leader neglected to make my appointment to release manager official. :)
[20:50] <stgraber> wxl: ok, in the mean time I can trigger builds for you if needed
[20:50] <wxl> stgraber: that would be great actually
[20:52] <cjwatson> arges: Yes, I just couldn't upload it before the other pieces were in.  I committed the fixes earlier.
[20:53] <cjwatson> arges: Thanks for the reviews
[20:53] <stgraber> wxl: do you want a first build to happen now or are you waiting for some stuff to land first?
[21:08] <arges> cjwatson: no problem
[21:16] <wxl> stgraber: naw first build now is fine
[21:16] <stgraber> wxl: triggered
[21:16] <wxl> stgraber: thx!!
[22:13] <cjwatson> slangasek: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1413 should hopefully fix that - had forgotten that the build state is set in a separate and earlier transaction, although in retrospect it's obvious (since the build log takes time to fetch from the slave)
[22:15] <cjwatson> stgraber: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/precise/edubuntu/+build/74 - do you happen to remember how ltsp-build-client got into the livefs build chroots?
[22:16] <cjwatson> stgraber: I'd like something better than "hack a special case into launchpad-buildd's livefs build-dep install code", if we can manage it ...
[22:17] <cjwatson> And ltsp-server seems a bit heavyweight to install for all builds
[22:19] <stgraber> cjwatson: ltsp-build-client is a script in ltsp-server so no real ways around this
[22:20] <stgraber> (it's not standalone, it actually depends on a ton of scripts and hooks that are part of ltsp-server)
[22:20] <cjwatson> Sure, we have to get ltsp-server in there somehow, but I don't want to have to install all that stuff for every LP-based livefs build
[22:21] <cjwatson> And I'd rather not have 'if self.project == "edubuntu-dvd" and self.arch_tag == "i386":' in launchpad-buildd
[22:21] <stgraber> is that really that big a deal? I mean ltsp-server without its recommends is tiny
[22:21] <stgraber> 76k and no only external dependency is debconf-utils (when trying an install on a clean trusty system)
[22:21] <stgraber> s/no//
[22:22] <cjwatson> If we can get away without its Recommends, maybe
[22:22] <cjwatson> The alternative would be to invent a way for livefs jobs to specify additional build-deps
[22:22] <stgraber> yeah, the recommends are only needed to actually run the stuff
[22:22] <cjwatson> But maybe that's not worth it
[22:22] <stgraber> well, except squashfs-tools but I suspect we already have that one right?
[22:22] <cjwatson> We do, via livecd-rootfs
[22:23] <stgraber> right, so installing with --no-install-recommends should only install ltsp-server itself then which I guess is reasonable
[22:23] <cjwatson> OK.  I can't promise to have a fix deployed in time for this milestone though.  Maybe we need to revert Edubuntu to the old buildds temporarily
[22:24] <stgraber> cjwatson: edubuntu is lts-only, we don't care :)
[22:24] <cjwatson> Oh, you aren't doing this milestone?  OK
[22:24] <stgraber> nope, we do random daily testing to make sure things aren't completely busted, but the next milestone testing we'll do for real will be 16.04 alpha-1
[22:25] <cjwatson> Oh, fine, I'll just queue it up with other things then
[22:25] <stgraber> wxl: hey, so the bot appears to be sleeping (I'll kick it) but your builds are done and publish on iso.qa.ubuntu.com now
[22:25] <cjwatson> buildd deployments take a bunch of sysadmin effort
[22:25] <wxl> stgraber: noticed, thank you :) sent a request for testers finally
[22:37] <cjwatson> wubi/precise livefs build failure was wrong configuration; fixed and retrying
[23:16] <ari-tczew> can someone rebuild this one? https://launchpad.net/ubuntu/+source/python-pecan/0.4.5-1/+build/6013254