[02:52] <ScottK> opencv on arm64 now causes an ICE, which is a regression.  What's the best way to deal with that to get it to migrate?
[02:53] <infinity> ScottK: disabling precompiled headers, probably.
[02:54] <ScottK> Fun.  55 MB tarball.
[02:56] <ScottK> At 42 kB/s
[02:56] <ScottK> Double fun.
[02:59] <ScottK> infinity: Would it be reasonable to override pykde being blocked on the apport jenkins failure?  The gtk front end failed too, so I'm pretty sure it's not pykde's fault.
[03:11] <ScottK> infinity: Does your recommendation change if I say the upstream code in question is unchanged, so it's likely a gcc regression?
[03:12] <infinity> ScottK: No, we know it's a GCC issue, but we've already disabled PCH in a few packages to move on for now.
[03:12] <ScottK> Ok.
[03:13] <ScottK> Got an example I can use to try and figure out how to do that?
[03:13] <infinity> https://patches.ubuntu.com/w/wxwidgets3.0/wxwidgets3.0_3.0.1-1ubuntu1.patch
[03:13] <infinity> Assuming you're lucky enough to have a configure switch for it.
[03:14] <ScottK> It's CMake, but it looks like I do.
[03:14] <ScottK> Thanks.
[03:15] <ScottK> ENABLE_PRECOMPILED_HEADERS
[03:15] <infinity> Kay.  So something more like this: http://launchpadlibrarian.net/177701306/sandboxgamemaker_2.7.1%2Bdfsg-2build2_2.7.1%2Bdfsg-2ubuntu1.diff.gz
[03:15] <ScottK> Thanks.
[03:17] <ScottK> That may be a tomorrow thing.  Suddenly I'm tired.
[06:50] <mlankhorst> can someone accept llvm-toolchain-3.4 in utopic?
[06:50] <mlankhorst> seems that llvm-3.4-tools is NEW
[06:51] <infinity> mlankhorst: It's also FTBFS on all !x86, so I was in no rush to accept.
[06:51] <mlankhorst> ah
[06:51]  * mlankhorst looks
[06:51] <infinity> mlankhorst: Due to this, I believe:
[06:51] <infinity>   * Ship the compiler-rt static libraries in libclang-3.4-dev
[06:52] <infinity> mlankhorst: But I didn't have the time to investigate how to unbreak it.
[07:00] <mlankhorst> fun part is that it's not supposed to happen afaict
[07:00] <mlankhorst> # Create this fake directory to make the install libclang-common-dev happy
[07:00] <mlankhorst> # under the unsupported archs of compiler-rt
[07:04] <mlankhorst> except libclang-3.4-dev takes a different source directory, weird stuff :/
[07:12] <mlankhorst> infinity: https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu2.debdiff ?
[07:13] <infinity> mlankhorst: Maybe? :P
[07:13] <infinity> mlankhorst: Give it a test-run on porter-powerpc, perhaps.
[07:14] <mlankhorst> ok
[07:22] <infinity> ^-- That was pre-reviewed by cjwatson, I didn't just pull a fast one.
[08:19] <mlankhorst> infinity: yeah that llvm-toolchain-3.4 debdiff fixes the FTBFS on ppc
[08:33] <infinity> mlankhorst: Uploading.
[09:05] <michagogo> Question: does getting an SRU in before a point release change anything?
[09:05] <michagogo> (For a universe package, that is)
[09:06] <michagogo> In other words, would there be any specific value in bug 1314616 getting in before 12.04.5, or does it not matter?
[09:06] <cjwatson> Doesn't much matter for things that aren't on images.
[09:08] <michagogo> (Btw, do people regularly look at the list of things waiting to be sponsored?)
[09:08] <michagogo> s/e /e that can sponsor/
[09:25] <mlankhorst> there ya go :-)
[09:45] <xnox> Laney: will desktop-next be doing an alpha-1?
[09:45] <Laney> xnox: no
[09:45] <xnox> ogra_: ubuntu-touch for alpha-1?! =)
[09:45] <ogra_> huh ?
[09:45] <Laney> we'd have replied to the thread if so
[09:46] <xnox> ok.
[09:46] <ogra_> xnox, lol, surely not :)
[10:01] <mlankhorst> now we just need armhf :-)
[11:25] <infinity> Wow, britney, seriously?
[11:26] <infinity> cjwatson: Fun misfeature.  Since glibc was new source, britney totally didn't care that its binaries were out of date on some arches and migrated it prematurely.  Whee.
[11:47] <mlankhorst> oops
[12:36] <cjwatson> infinity: I guess that meant nothing was uninstallable in the interim
[12:37] <infinity> cjwatson: True, was just a surprise that it didn't actually care about the binaries being out of date, since it deals with things as source package units.
[12:39] <mlankhorst> yay llvm-toolchain-3.4 built
[13:02] <jamespage> arges, any chance you could accept the neutron and cinder updates from jdstrand into trusty-proposed?
[13:02] <jamespage> coreycb, ^^
[13:20] <cjwatson> final: glibc/arm64
[13:20] <cjwatson> so hopefully that's sorted out
[13:22] <infinity> cjwatson: Yeah, my email implied as much.
[13:22] <cjwatson> Email where?
[13:23] <infinity> cjwatson: The duplicate ACCEPTED mail.
[13:23] <cjwatson> Oh right
[13:42] <arges> jamespage: I can (and was planning on) reviewing them today
[13:43] <jamespage> arges, thankyou!
[13:43] <arges> jamespage: was nova already taken care off (...looks)
[13:43] <jamespage> arges, no - that's still in the queue as well
[13:43] <arges> jamespage: ok yup its on my todo list today
[13:43] <jamespage> arges, ++excellent
[13:57] <cjwatson> That livecd-rootfs upload should sort out */trusty/amd64 livefs builds.  Then it's just Edubuntu to sort out.
[14:02]  * stgraber looks
[14:06] <cjwatson> Thanks
[14:06] <stgraber> cjwatson: accepted. You were missing the usual SRU paperwork, but I guess the testcase is "just rebuild ubuntu gnome" so that's fine.
[14:06] <cjwatson> Er, sorry, yeah.  I plan to switch trusty to PROPOSED=1 and see if it works
[14:07] <cjwatson> Pretty much any vaguely normal flavour exhibits it
[14:08] <cjwatson> I've actually tested it already using the new build-against-PPA facility
[14:09] <arges> Hi. looking at the nova upload in trusty. A security update went in at ubuntu1.2, but the debdiff for ubuntu1.3 includes the changelog entry for the security update as well. Should I reject and request this be done against ubuntu1.2?
[14:09] <arges> In addition to some other changelog mangling; not sure why that happened either.
[14:12] <infinity> arges: I'm not sure I understand the question.  The debdiff contains 1.2 and 1.3 because LP is brain damaged, not because the uploader did anything wrong.
[14:13] <infinity> arges: (It's a debdiff between proposed and proposed)
[14:14] <infinity> arges: The changelog weirdness after that is a bit odd, I'll give you that.  Especially the part where it introduces a spelling error that wasn't there before. ;)
[14:14] <arges> infinity: ok and in that case -proposed is in -updates, so I thought we'd get a debdiff between -updates and what the uploader is requesting
[14:14] <infinity> arges: Yeah, LP's not that smart.  If you want the debdiff from updates, you'll get to do it yourself.
[14:15] <arges> infinity: ok. and second... looking at cinder. I noticed the debdiff is against whats in -proposed; and the current -proposed never got accepted into updates. in that case shoudl we request a debdiff against whats in -update?
[14:15] <infinity> arges: How do you propose to request this?
[14:16] <infinity> arges: If you just mean you want someone to manually do it, you can just as easily do that yourself.  *shrug*
[14:16] <arges>  infinity i can do it. I just want to make sure the upload is oK
[14:17] <arges> infinity: so again, I can attribute this to LP oddness?
[14:17] <infinity> arges: I think it's obvious what's going on in that cinder update, though.
[14:17] <cjwatson> You can always attribute wrong debdiff to LP oddness.  It's always fine to download it yourself and debdiff manually against what rmadison reports for the suites you care about.
[14:17] <infinity> arges: The previous upload was already accepted, and this just adds the security update 1-liner and the changelog bits.
[14:18] <cjwatson> I mean completely wrong base for debdiff, of course.
[14:18] <arges> infinity: yup yup. I'm just making sure I don't mess something up
[14:18] <infinity> To be fair, the cinder debdiff isn't against the wrong base.
[14:20] <infinity> arges: If I were being a pedant, I'd punt the nova one for the weird history mangling, but probably only because the change in attribution and the introduction of a new typo really irk me. :P
[14:21] <infinity> Oh, actually, it also breaks the changelog format.
[14:21] <arges> that's not good
[14:21] <infinity>      exception when starting instances with libvirt LXC or XEN. (LP: #1297962)
[14:21] <infinity>  
[14:22] <infinity> - -- Chuck Short <zulcss@ubuntu.com>  Tue, 20 May 2014 12:04:39 -0400
[14:22] <infinity> -
[14:22] <infinity> ubot93: Not helpful.
[14:22] <infinity>  nova (1:2014.1-0ubuntu1) trusty; urgency=medium
[14:22] <infinity> arges: So, yeah, make chuck fix his mess there, IMO.
[14:23] <arges> jamespage: zul ^^^ I'm going to reject nova because of changelog mangling. want to check it over before I do so?
[14:23] <infinity> arges: But probably worth reviewing the rest of the upload first, and keeping a copy around, so you can enumerate all the bad, and debdiff old.dsc new.dsc when he reuploads to only see what was fixed instead of re-reviewing the whole thing.
[14:23] <zul> arges:  go ahead ill fix it up and re-upload it
[14:23] <arges> infinity: yup I have it local
[14:24] <infinity> zul: I assume you can spot all the bad in http://launchpadlibrarian.net/177877395/nova_1%3A2014.1-0ubuntu1.1_1%3A2014.1.1-0ubuntu1.3.diff.gz and don't need it pointed out? :)
[14:24] <infinity> zul: (In the changelog, that is)
[14:24] <zul> infinity:  yeah
[14:24]  * infinity needs to start stapling "debdiff before you upload" notes to everyone's foreheads.
[14:31] <mlankhorst> but an upload generates the debdiff for you ;-)
[14:44] <arges> infinity: so I re-constructed the cinder upload in trusty. the changelog jumps from 2014.1-0ubuntu1 to 2014.1.1-0ubuntu2. which skips 2014.1-0ubuntu1.1 (in -updates)
[14:45] <infinity> arges: Yeah, I made that out from the debdiff.
[14:45] <infinity> arges: The way it's done looks fine to me.
[14:46] <arges> infinity: ok. I didn't know if it was necessary to have another changelog entry for 2014.1-0ubuntu1.1
[14:46] <infinity> arges: Well, linear history is nice, but I get the impression that Jamie did 1.1 and 2 at the same time, and just did 2 as an addendum to 1, so it sort of makes sense to me.
[14:47] <arges> infinity: yup, I can see that
[14:47]  * arges goes and looks at teh rest of the diff : )
[14:47] <infinity> arges: His 1-liner and weird changelog would be fine with me, anyway.  The rest of it might be scary. ;)
[14:48] <infinity> (But openstack has an MRE, so as long as the diff doesn't look obviously broken, you're good)
[14:48] <arges> well i already reviewed it last week anyway, so mostly it is a glance to ensure changelog matches the features in the usptream changelog / formatting wierdness / etc
[14:51] <arges> also is bug 1185019 supposed to be private/emargoed still?
[14:51] <arges> embargoed
[14:52] <infinity> arges: I would hope not, since it's fixe released all over the place.
[14:52] <arges> infinity: pinging jamie about it
[14:53] <infinity> I can un-private it.
[14:53] <infinity> Done.
[14:53] <arges> infinity: hold on
[14:53] <infinity> Hrm?
[15:40] <arges> zul: ok, so the nova upload is against 2014.1-0ubuntu1.1 while 2014-1-0ubuntu1.2 is in proposed. I tried to reconstruct this using 1.1 and that patch didn't apply; also I notcied that d/p/libvirt-Handle-unsupported-host-capabilities.patch seemed to be dropped.
[15:42] <zul> arges:  crap can you reject it one more time
[15:42] <arges> : )
[16:24] <ScottK> ksudoku has suddenly started FTBFS on armhf and I don't think it will get fixed for alpha1.  It's blocking a stack of other packages from transitioning via libkdegames.  I'd like to either force it or do a binary removal on the one arch.  It's got no rdepends.  Thoughts?
[16:26] <cjwatson> It does have one rdepends: kdegames
[16:26] <cjwatson> That seems a little tricky as you'd have to remove meta-kde/armhf
[16:26] <ScottK> Oh.  Right.
[16:27] <ScottK> I can fix that not to depend on it for armhf.
[16:27] <ScottK> Easy enough.
[16:27] <cjwatson> Right, I think if you do that temporarily it's fine to remove the no-longer-buildable binary
[16:27] <ScottK> OK.  Thanks.
[16:35] <ScottK> OK, that takes care of that one.
[17:22] <ScottK> That worked.  The stack of packages around libkdegames migrated.
[17:22] <cjwatson> Cool
[17:24] <ScottK> Analitza built so that'll resolve two more depwaits on armhf.  I think kalzlium is good now too (waiting to see), so we're getting there.
[18:18] <ScottK> So, it looks like between libav, cups, and gnutls the chances of something like a KDE release making it to the release pocket are nil.
[18:18] <ScottK> Is anyone actively working on these?
[18:21] <xnox> yes
[18:39] <LocutusOfBorg1> xnox, do you have any timeline for libav? or do you need help? I cannot upload, but since the transition is already done in debian I hope the changes should be minimal
[18:40] <LocutusOfBorg1> libavg should just need a sourceful upload in debian and a sync :)
[18:49] <ScottK> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt looks rather scary for libav.
[18:55] <xnox> LocutusOfBorg1: what do you mean "just a sourceful upload for libavg" it fails to build from source with libav10, no?
[18:57] <LocutusOfBorg1> xnox, you are the maintainer right? did you miss this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739664#34
[19:01] <xnox> LocutusOfBorg1: yeah, i  did miss that.
[19:02] <LocutusOfBorg1> wonderful to hear, I was afraid about some showstopper for the new release :)
[19:09] <xnox> LocutusOfBorg1: that upstream release does not compile against libav10
[19:13] <xnox> trying harder
[19:19] <LocutusOfBorg1> :( sorry for that
[19:59] <rtg> can someone just reject Precise openipmi 2.0.18-0.1ubuntu1 ?
[20:00] <rtg> I think I messed it up
[20:06] <stgraber> sure, always happy to reject stuff :)
[20:06] <rtg> well, maybe not. config.guess and config.sub get generated during 'clean' which is the bulk of the diff
[20:07] <rtg> perhaps I'll just come back to this tomorrow. EOD for me.
[20:08] <stgraber> you may be able to trick it into not doing that so you only get the initscript diff but if you can't that's no big deal either, we're used to that kind of automagic spam
[20:08] <rtg> stgraber, ok, if it looks good then please accept it.
[20:55] <ScottK> I think all the Kubuntu stuff that will make it to the release pocket for Alpha 1 without some form of violence on the archive is there.
[20:55] <ScottK> shadeslayer: ^^^
[20:55] <stgraber> as I said in the e-mail this morning, I've got all the participating flavours already disabled in cron, so when you are ready, just trigger a build
[20:55] <stgraber> I'll setup the block shortly too
[20:56] <ScottK> Please ping here when you've set the block.  I may as well wait for that.
[21:08] <stgraber> ScottK: done
[21:23] <ScottK> stgraber: Thanks.
[21:33] <ScottK> And then I managed to request the rebuild, so I think we're off and running.
[21:38] <shadeslayer> ScottK: thx for getting everything in, it was a bank holiday here today
[21:53] <ScottK> stgraber: We should probably have the upgrade milestone for Alpha 1 too.
[22:01] <stgraber> ScottK: ah yeah, I'll add some of those
[22:22] <ScottK> stgraber: Thanks.
[23:13] <wxl> someone correct me if i'm wrong but the difference between amd64 and amd64+mac is that amd64 is uefi and amd64+mac is not, correct?
[23:15] <wxl> i.e. as long as they didn't use uefi, a person with amd64 hardware could test amd64+mac?
[23:16] <infinity> wxl: It's even more subtle than that.  amd64+mac is for booting CDs (but not USB sticks) on a specific generation of broken/weird Macs.
[23:16] <wxl> infinity: my understanding is that there were some amd64 machines that suffered the same fate
[23:16] <infinity> wxl: As for who can successfully boot it without breaking their non-Macs, I'm not entirely sure.
[23:16] <wxl> infinity: do i also gather from your statement that on usb it works with amd64 and intel macs without problem? :)
[23:17] <infinity> wxl: Yeah, if you don't use shiny spinny media, the regular amd64 image should work fine, even on the goofy Macs in question.
[23:18] <wxl> infinity: oh now that's funny.