| xnox | Please demote boost1.53 src+binaries into universe =) | 00:04 |
|---|---|---|
| infinity | xnox: Done. | 00:25 |
| xnox | \o/ | 00:26 |
| doko_ | xnox, so gccxml should go too | 00:30 |
| infinity | Byebye, libperl5.14. | 00:31 |
| xnox | doko_: libboost-python1.54-dev still "Recommends" gccxml. Is main done by build-depeds, depends & recommends? | 00:35 |
| xnox | doko_: or why is gccxml not in components-missmatches. I agree though gccxml should be in universe. | 00:36 |
| infinity | xnox: Recommends will keep it in main. | 00:37 |
| xnox | doko_: unless i package https://github.com/alexleach/gccxml_plugin which removes all gcc4.2 code. | 00:43 |
| infinity | I suppose it's too late to suggest we just drop boost entirely from Debian and Ubuntu? | 00:46 |
| 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:47 |
| wgrant | xnox, doko_: That's why I initially demoted gccxml to Suggests, but someone disagreed. | 00:58 |
| 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:21 |
| xnox | doko__: ok i'll do it for trusty, sometime with next / subsequent uploads. | 01:22 |
| xnox | no rush to do it right now. | 01:22 |
| ScottK | doko__: I'll see if I can find someone with interest, otherwise we can remove it. | 02:18 |
| tseliot | any admins around? | 09:06 |
| tseliot | didrocks: ^ | 09:07 |
| didrocks | tseliot: in meetings | 09:12 |
| tseliot | didrocks: ok, never mind, thanks | 09:12 |
| didrocks | sorry ;) | 09:12 |
| === doko__ is now known as doko | ||
| tseliot | Riddell: are you around? | 09:47 |
| Riddell | hi tseliot | 09:51 |
| 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:53 |
| 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:54 |
| xnox | tseliot: not really, why you need that? | 09:56 |
| Riddell | cjwatson: yeah go for it | 09:56 |
| cjwatson | ta, done | 09:56 |
| 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:57 |
| 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 | 09:58 |
| 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:00 |
| 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:02 |
| tseliot | xnox: supported, I guess | 10:03 |
| 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:04 |
| 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:05 |
| xnox | ouch. | 10:06 |
| tseliot | oh, so it's a bug | 10:06 |
| Riddell | tseliot: just get SRU team to approve it from New then | 10:07 |
| cjwatson | no seed change will affect NEW handling | 10:07 |
| tseliot | cjwatson: ok, thanks | 10:08 |
| tseliot | Riddell: the SRU team is subscribed to the bugs | 10:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| tseliot | good | 10:12 |
| === alex_abreu is now known as alex-abreu | ||
| 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:57 |
| xnox | ok. | 13:58 |
| cjwatson | sflphone is part of the ucommon transition IIRC | 13:58 |
| xnox | yeap, correct. | 13:58 |
| 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 | 13:59 |
| 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:03 |
| cjwatson | I can start on the obvious bits of it at least | 14:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| cjwatson | jpds: released | 14:08 |
| jpds | cjwatson: Thank you! | 14:08 |
| cjwatson | oh, I could've just retried libccaudio2, bah | 14:11 |
| 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:15 |
| 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:57 |
| cjwatson | that's probably NBS in -proposed, give me a minute | 14:58 |
| cjwatson | (proposed-migration needs some manual care in the case where one of the intermediate unmigrated versions has NBS binaries) | 14:59 |
| xnox | ok. | 15:03 |
| cjwatson | xnox: removed, should work after the next publisher run | 15:06 |
| cjwatson | right, let's see if the server image will build | 15:35 |
| cjwatson | if this works I think I'll call it a week | 15:37 |
| * cjwatson quickly fixes up ~cdimage/.isotracker.conf | 15:44 | |
| 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:48 |
| 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:49 |
| infinity | That's more depressing than the regular uninst. | 15:50 |
| infinity | (But actually, not all that bad) | 15:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| infinity | Which works around the apt bug/misfeature we run into with our "publish them all" approach. | 15:56 |
| * cjwatson checks | 15:57 | |
| 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. ;) | 15:59 |
| 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:01 |
| 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:02 |
| infinity | cjwatson: Right, so perhaps not worth trying to be clever at the archive level there. | 16:03 |
| 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 | 20:39 |
| ogra_ | stgraber, ok | 21:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!