[00:04] <xnox> Please demote boost1.53 src+binaries into universe =)
[00:25] <infinity> xnox: Done.
[00:26] <xnox> \o/
[00:30] <doko_> xnox, so gccxml should go too
[00:31] <infinity> Byebye, libperl5.14.
[00:35] <xnox> doko_: libboost-python1.54-dev still "Recommends" gccxml. Is main done by build-depeds, depends & recommends?
[00:36] <xnox> doko_: or why is gccxml not in components-missmatches. I agree though gccxml should be in universe.
[00:37] <infinity> xnox: Recommends will keep it in main.
[00:43] <xnox> doko_: unless i package https://github.com/alexleach/gccxml_plugin which removes all gcc4.2 code.
[00:46] <infinity> I suppose it's too late to suggest we just drop boost entirely from Debian and Ubuntu?
[00:47] <xnox> infinity: to be honest, majority of packages should switch to C++11 & STL. Half of things only uses crap like unique_pointer & command-line-arg-parser from boost.
[00:58] <wgrant> xnox, doko_: That's why I initially demoted gccxml to Suggests, but someone disagreed.
[01:21] <doko__> xnox, wgrant: the objections for the suggests were for saucy. please do it for trusty
[01:21] <doko__> xnox, nice plugin, however should stay in universe
[01:22] <xnox> doko__: ok i'll do it for trusty, sometime with next / subsequent uploads.
[01:22] <xnox> no rush to do it right now.
[02:18] <ScottK> doko__: I'll see if I can find someone with interest, otherwise we can remove it.
[09:06] <tseliot> any admins around?
[09:07] <tseliot> didrocks: ^
[09:12] <didrocks> tseliot: in meetings
[09:12] <tseliot> didrocks: ok, never mind, thanks
[09:12] <didrocks> sorry ;)
=== doko__ is now known as doko
[09:47] <tseliot> Riddell: are you around?
[09:51] <Riddell> hi tseliot
[09:53] <tseliot> Riddell: hi, we filed a MIR in bug 1204820 but we didn't specify that we needed that for both saucy and precise
[09:53] <ubot2> Launchpad bug 1204820 in nvidia-prime (Ubuntu) "[MIR] nvidia-prime & fglrx-pxpress" [Undecided,Fix released] https://launchpad.net/bugs/1204820
[09:54] <cjwatson> Riddell: can I sync webcit and drop https://launchpadlibrarian.net/142321538/webcit_8.16-dfsg-1_8.16-dfsg-1ubuntu1.diff.gz ?  Same reason as citadel or citadel-client or whichever it was the other day
[09:54] <tseliot> Riddell: so now the two packages are in main only in Saucy. Would it be ok if I added the two packages to the seeds for precise and we moved them to main?
[09:56] <xnox> tseliot: not really, why you need that?
[09:56] <Riddell> cjwatson: yeah go for it
[09:56] <cjwatson> ta, done
[09:57] <Riddell> tseliot: mm didn't we release precise last year?
[09:57] <xnox> tseliot: sometimes security team picks up support for previous releases, if same package gets into main into latter release.
[09:57] <tseliot> xnox: because packages in main cannot depend on packages in universe
[09:57] <tseliot> Riddell: well, there are point releases
[09:58] <xnox> tseliot: ok, but we don't change components post-release without a good reason. and if done the change would only be visible in -security and/or -updates only.
[09:58] <tseliot> and the two packages were included in 12.04.3
[09:58] <xnox> tseliot: what are the packages in question?
[09:58] <tseliot> xnox: nvidia-prime and fglrx-pxpress
[10:00] <xnox> tseliot: neither of which have reverse dependencies in precise/main, or do you plan to introduce one?
[10:00] <Riddell> xnox: he wanted to add to seed
[10:00] <Riddell> I suppose it makes sense but I've not done it before so it makes me a little nervous I'm missing something
[10:02] <xnox> tseliot: i'm not sure. Where did you want to seed them into? "supported" or on to desktop-cd?
[10:02] <tseliot> xnox: for now it's just that if I upload the package, it ends up in NEW
[10:02] <tseliot> as it happened to nvidia-prime
[10:03] <tseliot> xnox: supported, I guess
[10:04] <tseliot> or whatever else can prevent my packages from ending up in NEW
[10:04] <xnox> tseliot: yeah, that's unfortunate bug in launchpad, but pretty much only affects you so far and poor AA who needs to de-new it constantly.
[10:04] <Riddell> tseliot: it needs a SRU request
[10:04] <Riddell> if you want new versions in precise
[10:04] <tseliot> Riddell: yes, I've done that
[10:04] <xnox> tseliot: and i don't think seeding in main will help at all, cause i think launchpad still says "oh look precise-release didn't have it" => NEW, and it should learn to look at -updates pocket.
[10:04] <Riddell> it won't end up in new there's already packages in precise
[10:05] <Riddell> tseliot: bug no?
[10:05] <cjwatson> Riddell: yeah it will
[10:05] <xnox> Riddell: i think those two packages fall under "hardware enablement stacks" with respect to kernel & graphics packages.
[10:05] <xnox> cjwatson: ^ wouldn't it?
[10:05] <cjwatson> Riddell: there's an LP bug relating to post-release pockets and ancestry
[10:05] <cjwatson> but it's not a huge problem
[10:05] <tseliot> Riddell: bug 1224098 and bug 1219650
[10:05] <ubot2> Launchpad bug 1224098 in nvidia-prime (Ubuntu Saucy) "xserver wont start after nvidia-prime installation" [High,In progress] https://launchpad.net/bugs/1224098
[10:05] <ubot2> Launchpad bug 1219650 in nvidia-prime (Ubuntu Saucy) "Failed to install on 12.04.3 , /var/lib/dpkg/info/nvidia-prime.postinst: 36: printf: 08: not completely converted" [High,In progress] https://launchpad.net/bugs/1219650
[10:06] <xnox> ouch.
[10:06] <tseliot> oh, so it's a bug
[10:07] <Riddell> tseliot: just get SRU team to approve it from New then
[10:07] <cjwatson> no seed change will affect NEW handling
[10:08] <tseliot> cjwatson: ok, thanks
[10:08] <tseliot> Riddell: the SRU team is subscribed to the bugs
[10:09] <Riddell> tseliot: ok so upload package, add to seed, get SRU to approve it, if an archive admin needs to move to main that's the last step I think
[10:09] <tseliot> Riddell: but really it should be at least removed from NEW so that it ends up in the "pending approval" state
[10:09] <cjwatson> tseliot: dude it makes no difference
[10:09] <cjwatson> don't obsess about the new vs. unapproved thing
[10:09] <cjwatson> it requires manual action either way
[10:10] <cjwatson> and we *can't* move it from new to unapproved anyway
[10:10] <cjwatson> not without fixing the lp bug
[10:10] <tseliot> cjwatson: can any member of the SRU team move it from NEW without being an admin?
[10:10] <cjwatson> any member of the SRU team should be able to accept it if they think the changes are appropriate, yes
[10:10] <cjwatson> we don't have per-queue permissions
[10:11] <tseliot> ok, good
[10:11] <cjwatson> ubuntu-sru has queue admin permissions for <all stable releases>-{proposed,updates}
[10:11] <tseliot> it's a rather serious issue, so I didn't want it to get stuck for any reason
[10:12] <tseliot> good
=== alex_abreu is now known as alex-abreu
[13:57] <xnox> I've uploaded sflphone rebuild against boost1.54, it's build-deps are not installable in trusty-proposed, but they are in trusty. Can that source package be somehow build with just "trusty" pocket enabled (a non-virt ppa?), binaries copied to trusted-proposed & migrated to trusty?
[13:57] <xnox> ( i guess that can be last resort, if the build-deps uninstallability is not solved)
[13:57] <cjwatson> a non-virt PPA is possible, but fairly cumbersome; last resort as you say
[13:58] <xnox> ok.
[13:58] <cjwatson> sflphone is part of the ucommon transition IIRC
[13:58] <xnox> yeap, correct.
[13:59] <xnox> i've bumped it to boost1.54, and it does build correctly in -release, so it shouldn't cause any additional entanglement in the ucommon transition.
[13:59] <cjwatson> I don't especially object but I wonder if it would be better to just slap that transition through ASAP
[14:03] <xnox> well, i'm juggling slepc mini-transition and ogre-1.9 mini-transitions, to finally get off boost1.49.... having 3 boosts in the archive is too much.
[14:04] <cjwatson> I can start on the obvious bits of it at least
[14:05] <xnox> ack. and I think boost1.54 will eventually be stuck on libav9 transition, unless e.g. old blender is rebuilt in trusty-release, bypassing new upstream release.
[14:05] <jpds> Anyone from the SRU team know when https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/995719 will go into -updates ?
[14:05] <ubot2> Launchpad bug 995719 in puppet (Ubuntu Precise) "process_name.rb removed in 2.7.11 but still provided by puppet-common" [High,Fix committed]
[14:06] <xnox> jpds: from http://people.canonical.com/~ubuntu-archive/pending-sru.html it looks like it's good to go, but SRUs are not usually released on Fridays.
[14:07] <xnox> (due to many developers missing typically over the weekend to handle a regression)
[14:07] <cjwatson> We don't normally.  That one looks harmless enough though?
[14:07] <xnox> i think it is harmless enough.
[14:07] <jpds> "Mostly harmless."
[14:07] <cjwatson> Yeah, just removing a file
[14:08] <cjwatson> jpds: released
[14:08] <jpds> cjwatson: Thank you!
[14:11] <cjwatson> oh, I could've just retried libccaudio2, bah
[14:15] <cjwatson> hm, the libucommon-dev -> libgnutls28-dev dep is going to be troublesome, and the ucommon changelog says it fails to build against libgnutls-dev
[14:57] <xnox> I don't understand britney's excuse for not considering gnuradio. Can somebody help me, please? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[14:58] <cjwatson> that's probably NBS in -proposed, give me a minute
[14:59] <cjwatson> (proposed-migration needs some manual care in the case where one of the intermediate unmigrated versions has NBS binaries)
[15:03] <xnox> ok.
[15:06] <cjwatson> xnox: removed, should work after the next publisher run
[15:35] <cjwatson> right, let's see if the server image will build
[15:37] <cjwatson> if this works I think I'll call it a week
[15:44]  * cjwatson quickly fixes up ~cdimage/.isotracker.conf
[15:48] <infinity> cjwatson: FWIW, I concur that we should probably pull arm64 out of slow_arches nowish.  New uploads should take precedence, so the only reason it would lag is build failures, which we'll have to deal with one way or another.
[15:48] <cjwatson> Yeah, I was considering doing it before I finish for the day.
[15:48] <infinity> I'd certainly be more comfortable if our builders were more reliable, but I'm not holding my breath on that happening soon.
[15:49] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty_uninst_full.txt  if anyone fancies a project :-)
[15:49] <cjwatson> that's with considering arch: all on all architectures rather than just i386
[15:50] <infinity> That's more depressing than the regular uninst.
[15:50] <infinity> (But actually, not all that bad)
[15:51] <cjwatson> It isn't quite as terrible as I'd expected.
[15:51] <infinity> ppc and armhf are a bit worse than I suspected.  Lots of "do we actually care?" versus "arch:all packages that depend on :any should probably not be :all" decisions to take there.
[15:52] <infinity> Or, arguably, a Soyuz bug/misfeature to fix in some cases.
[15:52] <cjwatson> I tried to persuade the nodejs people of the error of their ways a couple of weeks ago.  Not sure I've got the message across yet.
[15:52] <cjwatson> (I think all their packages should be Architecture: any Build-Depends: nodejs
[15:52] <cjwatson> )
[15:52] <infinity> As in, if there's no build for a source in a DAS, perhaps we shouldn't publish the arch:all packages on that arch.
[15:53] <infinity> Not counting things that are all-only.
[15:53] <infinity> So, it gets a bit messy to get the heuristic right.
[15:53] <infinity> But I still suspect that's a correct heuristic to apply.
[15:53] <cjwatson> I think most of these are all-only with arch-specific deps.
[15:54] <infinity> Yeah, that's a harder problem that should be addressed at the package level.
[15:54] <cjwatson> You may have a point in some cases, yeah
[15:54] <infinity> I'm thinking of sources that are "i386 amd64 all", where the all seems to have a legit right to exist, but just shouldn't exist on !x86.
[15:54] <cjwatson> Though I'd kinda like to persuade Debian of it first
[15:54] <infinity> And I'm not sure, but I think DAK might get that case right.
[15:54] <cjwatson> Just in case there are weird exceptions ...
[15:54] <cjwatson> Never heard of it does so.
[15:55] <cjwatson> *doing
[15:55] <infinity> I know they pull some tricks to not publish arch:all stuff when the :any build on an arch is lagging.
[15:55] <cjwatson> I thought they just kept publishing the old one.
[15:55] <infinity> Yes, but not the new one.
[15:55] <cjwatson> Oh, right, yeah
[15:55] <cjwatson> I guess that might imply this
[15:56] <infinity> Which works around the apt bug/misfeature we run into with our "publish them all" approach.
[15:57]  * cjwatson checks
[15:59] <cjwatson> infinity: Nope - 7kaa is Architecture: amd64 i386 all, but 7kaa-data is published in unstable/powerpc
[15:59] <infinity> Ahh, kay, so much for the hope that someone else got that more right than us. ;)
[16:01] <infinity> I guess it's hard to know for sure that you got it right.  One could construct a package that produces "foo-i386, foo-amd64, foo-sparc, foo-python-portable" and you'd actually want the last one on all arches.
[16:01] <infinity> Or whatever.
[16:02] <cjwatson> infinity: I think there really are such cases with Java.
[16:02] <cjwatson> Build foo-java on all architectures, foo-jni on some.
[16:03] <infinity> cjwatson: Right, so perhaps not worth trying to be clever at the archive level there.
[20:39] <stgraber> ogra_, lool: I've turned off import-images for system-image as the last touch build is breaking the delta generation tool, I need to look into the specific problem
[21:25] <ogra_> stgraber, ok