=== doko_ is now known as doko
=== locutus_ is now known as LocutusOfBorg1
[09:55] <xnox> I download http://cdimages.ubuntu.com/daily-live/current/utopic-desktop-amd64.iso and i get sha256 checksum failure. (does not match SHA256SUMS)
[09:57] <cjwatson> gosh, that's impressive
[09:57] <cjwatson> broken on the master - how on earth did that go wrong
[09:58] <xnox> ok, i thought maybe just the wire-tap wonky on my connection =)
[09:58] <xnox> (edward snowden interview on TED was funny)
[09:59] <stgraber> c960526985ce357b51feb961d4c80cd9ce060ddde43d34ed06de5dbb5080a2d3  www/full/daily-live/20140520/utopic-desktop-amd64.iso
[09:59] <cjwatson> I'll force a rechecksum for now
[09:59] <stgraber> so SHA256SUMS for current contains the checksum of 20140520 but the symlinks points to 20140515
[10:00] <xnox>  /pending/ is all correct.
[10:00] <cjwatson> yes, 20140515 and 20140520 are fine in isolation
[10:00] <stgraber> do we have locking to prevent a race between a new build and jenkins marking a new image as current?
[10:01] <cjwatson> there's no race there
[10:01] <cjwatson> mark-current from ordinary builds won't update things that are expected to be updated by jenkins
[10:02] <cjwatson> hm, I guess actually there is a possible race
[10:02] <cjwatson> might be worth a lock there, though it seems very rare, can somebody file a bug?
[10:03] <cjwatson> xnox: should be fixed nowish
[10:03]  * stgraber volunteers xnox 
[10:04] <xnox> stgraber: i can honestly say, i did not touch/code any components involved in all of this =)
[10:05] <xnox> cjwatson: stgraber: are trusty dailies not enabled? or am i just failing to find them?
[10:05] <xnox> i am expecting something like http://cdimages.ubuntu.com/trusty/ but that's 404
[10:09] <xnox> cjwatson: daily-live/current - all is good. ubuntu-server/daily/current still fails verification.
[10:10] <xnox> same issue?!
[10:11] <cjwatson> They aren't enabled right now
[10:11] <cjwatson> Since we're still building precise, I'd kind of like to wait until the LP livefs code is in place before starting that, if possible
[10:12] <bdrung_work> ScottK, can you copy ifupdown for the other releases besides trusty?
[10:12] <cjwatson> (BTW the canonical hostname is cdimage.ubuntu.com)
[10:12] <xnox> cjwatson: ack.
[10:14]  * xnox wishes to know how to unteach my browser history....
[10:18] <doko> xnox, https://launchpadlibrarian.net/175890344/buildlog_ubuntu-utopic-amd64.autopilot-gtk_1.4%2B14.04.20140107-0ubuntu3_FAILEDTOBUILD.txt.gz
[10:18] <xnox> doko: yes, there is a better fix by pitti (either MP or upload, not sure)
[10:18] <xnox> doko: https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/+merge/220075
[10:19] <pitti> I prodded the AP guys about landing it; I was promised "this week"
[10:19] <pitti> if it becomes a blocker, I can also upload directly and then we just use the MP to sync back bzr
[10:20] <doko> well, gcc-4.9 will take a while to build, but not more than 8 hours
[10:41] <Laney> cjwatson: did you want to review my cdimage MP some more?
[10:44] <Laney> that reads like a prod to do it now - I meant it to read as a question :)
[10:46] <Laney> ah, thanks
[10:47] <cjwatson> Laney: done anyway.  one mistake I noticed after merging - "daily" should've been "daily-live", but I just made it a wildcard since there's no reason to limit it
[10:47] <Laney> oh yes, in default-arches
[10:49] <cjwatson> where do the seeds live?
[10:49] <cjwatson> and does this need any debian-cd handling?
[10:50] <Laney> inside ubuntu-touch.utopic
[10:50] <Laney> and I'm not sure, how do I answer that question?
[10:50] <cjwatson> is the image an ISO?
[10:50] <Laney> yes
[10:51] <cjwatson> right, then it will need some more work
[10:51] <cjwatson> let me see
[10:52] <Laney> Happy to look given pointers
[10:54] <cjwatson> I've done the boring and fiddly debian-cd bits
[10:55] <cjwatson> but we need to educate this about seed locations
[10:55] <cjwatson> Laney: I think you need something in lib/cdimage/germinate.py:Germination.seed_dist
[10:55] <Laney> Okay, it wasn't clear how this all fit together
[10:56] <cjwatson> Cases where one flavour is embedded in another's seed collection are exceptional and seed_dist needs to be told about those
[10:57] <cjwatson> Laney: Also I suspect that this flavour needs universe enabled, so add it to the list of flavours that have CDIMAGE_UNSUPPORTED set to 1 in lib/cdimage/build.py:configure_for_project
[10:58] <Laney> I see, touch wasn't in seed_dist because it fits the default case
[10:59] <Laney> I've just added a branch for ubuntu-desktop-next → ubuntu-touch
[10:59] <cjwatson> Also touch is simpler than this because it doesn't build an ISO
[10:59] <Laney> does it need to know that we're using "desktop-next" within ubuntu-touch?
[10:59] <cjwatson> Something like ubuntu-gnome is probably a better template
[11:00] <cjwatson> Err is there any chance that you could harmonise the seed names instead?
[11:00] <cjwatson> list_seeds is roughly what controls all this
[11:00] <cjwatson> (lib/cdimage/germinate.py)
[11:01] <cjwatson> In fact pretty much the whole GerminateOutput class there
[11:01] <cjwatson> It's probably mainly the ship-live seed that matters
[11:02] <cjwatson> We're going to need at least some things in ship-live, such as grub-efi/grub-efi-amd64-signed
[11:02] <cjwatson> So copy that seed over from ubuntu.utopic and cut it down as you see fit
[11:03] <cjwatson> Given that the desktop-next seed is in a different seed collection, is there any reason not to just call it desktop?
[11:03] <cjwatson> That would be easier to cope with
[11:03] <Laney> Sorry this is a bit opaque to me currently
[11:03] <Laney> I was following the name of the project
[11:03] <cjwatson> OK, if you don't have a good reason just rename it to desktop :)
[11:03] <cjwatson> We're also going to need a Launchpad change to make it generate tasks for the ubuntu-touch seed collection
[11:03] <Laney> ship-live> can we just use the ubuntu one?
[11:04] <cjwatson> You can probably just copy it
[11:04] <cjwatson> Can't use it directly from ubuntu.utopic because the seed inheritance would be all wrong
[11:05] <cjwatson> For Launchpad, you'll want to change cronscripts/publishing/cron.germinate and add ubuntu-touch to the FLAVOURS list
[11:05] <cjwatson> I don't think there are any meaningful tests for that but it doesn't much matter
[11:06] <cjwatson> That will bloat up Packages a bit more with the other touch tasks, but that's probably a drop in the ocean and arguably they should be there anyway
[11:09] <cjwatson> Is that enough to be going on with?
[11:10] <Laney> I'll see what I can do, not confident I'm going to get the germinate part in cdimage right first time but we'll see
[11:12] <cjwatson> The best way to make it simple is to have the seed collection as much like others as possible
[11:12] <cjwatson> So it's probably enough to rename desktop-next -> desktop and add ship-live, and the associated STRUCTURE tweaks
[11:13] <cjwatson> I don't mind if it goes wrong a couple of times in production and we need to rerun :)
[11:14] <Laney> In ubuntu.utopic/STRUCTURE ship-live inherits from boot and live
[11:14] <Laney> do we need to take care of that here?
[11:15] <cjwatson> Probably, yes
[11:15] <cjwatson> You need a live seed because otherwise there's no way to avoid having the installer still exist on the installed system
[11:16] <cjwatson> boot is in platform.utopic so you don't need to copy it (unlike live), but you probably do want to mirror ubuntu.utopic's STRUCTURE inheritance for the relevant seeds as closely as possible unless you enjoy debugging thoroughly obtuse bits of germinate
[11:48] <ScottK> bdrung_work: I'll get to the other releases.  I only had time for trusty last night before I went to bed.
[12:17] <ScottK> bdrung_work: Done.
[12:22] <bdrung_work> ScottK, thanks
[12:39] <sergiusens> can someone please take a look at golang-udm (source) in the utopic queue?
[12:51] <rcj> stgraber, Is now a better time to look at the SRU in bug #1275656?  This is regarding the port of trusty's open-vm-tools to precise as a new package for HWE support
[12:52] <stgraber> rcj: yep, I'm around now
[12:54] <rcj> stgraber, great.  This is the package we spoke about in person.  I tried to capture everything in the SRU template but I'm sure there will be questions.
[12:55] <stgraber> rcj: reading the bug report now
[13:00] <stgraber> rcj: I think I'd have preferred the prefix be -lts-trusty to be in line with what's done for the kernel, the X stack and openvswitch but since there won't be any further backports, it's not critical
[13:01] <rcj> stgraber, I didn't use that because it would work with the the saucy hwe kernel as well.  I thought that trusty was in early test and wouldn't be supported until 12.04.5.
[13:02] <stgraber> well, the trusty X stack also works fine with the saucy kernel :) I usually assume the -lts-X to simply be an indication of the source of the package more than a requirement that they all be installed together
[13:02] <rcj> stgraber, ah, good to know.
[13:03] <stgraber> but anyway, it really doesn't matter this time around since it's just a single backport and we won't be backporting from utopic to precise
[13:03] <rcj> sure, but I'll keep it in mind for the future
[13:04] <stgraber> rcj: so I assume you already test built all of those locally, made sure that installing the -hwe packages on a machine which already has the non-hwe bits work fine and that upgrading a machine with those -hwe to trusty works with your updated trusty package?
[13:05] <rcj> Yes.  Tested each of those scenarios.
[13:08] <stgraber> rcj: ok, so one problem with the precise backport is its version number. You should upload with something like ~precise1 as a prefix to avoid the case where we need to fix a bug in open-vm-dkms-hwe in precise, therefore bumping the version and as a result end up with binary packages that have an higher version number than those on trusty (breaking the transition)
[13:09] <stgraber> (when a binary is moved from one package to another as is the case here with your transitional package, the version of the new source package must be higher than that of the old one for an upgrade to happen)
[13:09] <rcj> stgraber, so '2:9.4.0-1280544-5ubuntu6~precise1', correct?
[13:09] <stgraber> yep
[13:10] <rcj> okay, I can fix that.
[13:10] <stgraber> I'm taking a quick look at the source too to see if there's anything else that should be fixed at the same time
[13:13] <stgraber> rcj: so the debdiff from the precise hwe to trusty is: http://paste.ubuntu.com/7492904/
[13:13] <stgraber> quickly going through it, there appears to be some missing conflicts
[13:14] <stgraber> unless it's indeed possible to co-install open-vm-tools-desktop and open-vm-tools-hwe-desktop for example
[13:15] <rcj> stgraber, that's the correct debdiff.  I'll fix that and figure out why I didn't catch that in testing
[13:18] <stgraber> rcj: cool, I'll reject what's in the queue, let me know when you have an updated package uploaded. (Note that I'm not working the rest of the week, so you may want to catch someone else if you don't want to wait until next week)
[13:19] <stgraber> rcj: apw pointed out in private messages that ~precise1 is a suffix not a prefix, though you apparently assumed as much since your proposed version string was correct :)
[13:20] <rcj> stgraber, thanks for the review.  I'll get this fixed up.
[13:41] <cjwatson> infinity: FYI, between didrocks and I, I believe we now have it so that people will be notified if there's some kind of error from the async copy job when they publish a package from the CI Train.
[13:42] <didrocks> cjwatson: I need to dedicate some time to do the modification, but I'll before EOW
[13:43] <cjwatson> didrocks: I thought you already did
[13:43] <cjwatson> I wasn't highlighting you to request that you did anything :-)
[13:43] <didrocks> not that one, only the assigning to landers that we discussed on thursday and friday
[13:44] <cjwatson> Oh, right
[13:44] <didrocks> but not about the async copy
[13:44] <cjwatson> Well, at least a real person gets the mail now, even if it's the wrong real person
[13:44] <didrocks> yeah
[13:44] <didrocks> if it's a rejection, not if the async job is stuck or anything (we need someone to ssh to the machine for now)
[13:45] <didrocks> I'll expose some logs, just need to find what level is suited to append to a file
[13:48] <cjwatson> Hm, rejections might be a different matter
[13:48] <cjwatson>             # This possibly should be sending a rejection email but I
[13:48] <cjwatson>             # don't think we need them for sync rejections.
[13:48] <cjwatson>             return
[13:48] <cjwatson> Thanks, whoever wrote that
[13:49] <didrocks> oh, yeah, as it's a sync…
[13:51] <cjwatson> I was looking at actual errors or OOPSes
[14:02] <rcj> stgraber, I'll make the change to -lts-trusty as well with this.  Is there a preferred naming for this... open-vm-tools -> open-vm-tools-lts-trusty, but for open-vm-tools-dkms I used open-vm-tools-lts-trusty-dkms.  Any preference against the -dkms suffix after -lts-trusty?
=== jhodapp__ is now known as jhodapp
=== jhodapp is now known as jhodapp|mtg
[14:37] <stgraber> rcj: looking at our existing examples (X stack), we currently always put the -lts-trusty after the normal package name so it'd be open-vm-tools-dkms-lts-trusty but I'm not too attached to it personaly so whatever
[14:38] <mlankhorst> yeah except for -dbg :p
[14:38] <rcj> stgraber: okay
[14:39] <rcj> stgraber, I'll make sure that -lts-trusty comes last on all of the packages
=== Ursinha is now known as Ursinha-afk
[14:40] <rcj> stgraber, re-reading that.  -dbg must come last. right?
[14:42] <stgraber> rcj: yeah
[14:42] <mlankhorst> I did that just in case, to keep symmetry
[14:42] <rcj> stgraber, mlankhorst; thanks.  I'll clean this up to make it sane and consistent.
[14:47] <rcj> stgraber, and when you asked about the missing conflicts I was forgetting that those packages don't exist in the precise open-vm-tools so that's deliberate.
[14:48] <mlankhorst> rcj: do you want to add those packages to xorg-lts-transitional perhaps? :p
[14:48] <mlankhorst> in trusty
[14:50] <stgraber> rcj: ah, ok, makes sense then, sorry I didn't check for that particular case.
[14:51] <rcj> mlankhorst, I don't believe so.  This package backport enables some additional guest customizations when running in a vmware vCHS host environment.  It needs a 3.9 or later kernel but doesn't relate to anything in the X stack.
[14:53] <rcj> mlankhorst, the backport is to support that env for cloud images and otherwise I would rather that users need to install it manually so that they know what they're getting with this.
[14:54] <mlankhorst> rcj: xorg-lts-transitional is a package in trusty, and used when upgrading from precise to trusty
[14:54] <mlankhorst> and contains dummy packages with epoch 3 (bigger than anything in the xorg stack) so all the xorg lts-* packages get upgraded to the unrenamed xorg packages :)
[14:55] <rcj> mlankhorst, I'm confused as to what it gets me for open-vm-tools?  They would be upgrades to open-vm-tools in trusty per the packaging changes I'm making for that package.
[14:56] <rcj> typo..  The precise packages would be upgraded to open-vm-tools in trusty per the packaging changes I'm making for that package.
[14:58] <mlankhorst> ok
=== Ursinha-afk is now known as Ursinha
[15:13] <marrusl> Hello.  Anyone happen to know when the trusty X stack is expected in -proposed?
[15:13] <marrusl> precise-proposed
[15:15] <mlankhorst> it's in NEW, just pending review
=== seb128_ is now known as seb128
[15:25] <marrusl> thanks mlankhorst
[15:27] <sergiusens> slangasek: hey, do you mind looking at golang-udm? We uploaded it directly instead of through the train since the changelog it created for the new package didn't look that nice
=== jhodapp|mtg is now known as jhodapp
[18:08] <sbeattie> Hi, is there a reason the i386 iso image 20140520 for ubuntu-desktop hasn't been promoted from pending/ to current/ but the rest of the images have been? (Also, partially promoting images like this breaks the checksum files)
[18:20] <cjwatson> sbeattie: Thought I fixed the checksums this morning, and it isn't supposed to break them, we think it might be a race
[18:21] <cjwatson> sbeattie: The amd64 and i386 images go through automatic testing before they're promoted to current/; the others don't have automated testing set up so they go straight through
[18:21] <cjwatson> (autotesting was the entire point of the pending/current split)
[18:21] <cjwatson> sbeattie: https://bugs.launchpad.net/utah/+bug/1199349 has been blocking autotesting
[18:22] <cjwatson> And I see that http://ci.ubuntu.com/smokeng/utopic/desktop/ shows a pass on amd64 now which is probably why only i386 is held back now
[18:23] <cjwatson> So yeah, I see that the i386 checksums are broken again.  We need to figure out what's causing that, since now I don't buy the race theory any more
[18:23] <sbeattie> cjwatson: thanks. It's the broken checksum issue that made me ask.
[18:24] <cjwatson> (but I have to run, so not right now)
[19:41] <rtg> I uploaded a utopic package (openipmi) that should also be in trusty. is it sufficient to request a pocket copy, or should I futz with the trusty version and re-upload ?
[19:46] <infinity> rtg: If you uploaded to utopic first, we won't copy it backward.
[19:47] <infinity> rtg: So, yes, if it's an SRU we should have, please SRU it in the usual fashion.
[19:47] <rtg> infinity, ok, I'll swizzle the version and SRU it.
[19:48]  * rtg should have done trusty first. oops.
[19:55] <slangasek> we're far enough along that two uploads are preferred anyway
[19:55] <slangasek> it's just that we *never* copy backwards, whereas we *sometimes* copy forwards
[19:55] <slangasek> (except, er, for shim)
=== beidl_ is now known as beidl