[07:34] <Daviey> infinity: yes
[11:35] <Riddell> cjwatson, infinity: fancy eyeing over these for merge? https://code.launchpad.net/~jr/ubuntu-cdimage/kubuntu-quantal/+merge/109612 https://code.launchpad.net/~jr/livecd-rootfs/kubuntu-quantal/+merge/109611
[11:35] <Riddell> that etc/crontab file in ubuntu-cdimage seems suspicious incomplete to me
[11:41] <Riddell> cjwatson: also kubuntu bits can be moved to universe any time you like
[11:45] <cjwatson> Yeah, it's incomplete at the moment
[11:46] <cjwatson> Riddell: So I meant to talk with you about that - there seemed to be some disagreement on kubuntu-devel about whether that was desirable.  Have you resolved that or are you just taking a leadership decision? :-)
[11:48] <Riddell> cjwatson: making a decision, but maybe ScottK wants to wait and debate it
[11:52] <cjwatson> Riddell: merged your branches plus a little bit more
[11:54] <Riddell> thanks
[12:25] <ScottK> Riddell: I was clearly in the minority, so no problem.
[12:27] <ScottK> Riddell: Once the move is in place, it probably merits a mail to ubuntu-devel-announce.
[12:27] <Riddell> cjwatson: ^^
[13:13] <zul> can someone promote python-jsonschema its been acked by the MIR team (bug #1003729)
[13:13] <ubot2> Launchpad bug 1003729 in python-jsonschema "[MIR] python-jsonschema" [High,Fix committed] https://launchpad.net/bugs/1003729
[13:14] <cjwatson> zul: It's not in component-mismatches.  Are you about to upload something that depends on it?
[13:15] <zul> cjwatson: doh...i need to upload glance first, ill nag you guys on friday
[13:15] <zul> sorry about that
[13:15] <cjwatson> No, that's OK, I can promote it as long as you're about to do the upload
[13:16] <cjwatson> I just want to make sure that's happening since as soon as I move it to main it'll show up on our report for moving back to universe
[13:16] <zul> cjwatson: it will happen this week
[13:24] <cjwatson> zul: I've gone ahead and moved it to main, then
[13:25] <zul> cjwatson: merci buckets
[17:40] <henrix> hi! we have a bunch of kernels waiting to be moved into -updates. any chance of having someone taking a look at those?
[17:41] <henrix> i never know exactly who shall i ask to do this :)
[18:00] <xnox> http://packages.qa.debian.org/libc/libconfig.html package has started uncordinated library transition from libconfig8 -> 9
[18:01] <xnox> currently sitplus fails to build from source in ubuntu
[18:01] <xnox> because it expects libconfig9
[18:01] <xnox> in ubuntu we carry a delta which simply adds shlib symbols files
[18:02] <xnox> is it save to initiate a transition in ubuntu? should I file a bug first?
[18:02] <xnox> 11 packages are affected by the transition
[18:04]  * xnox -> eod
[18:05]  * xnox wrong channel =)
[18:08] <infinity> xnox: If it's just 11 packages without wildly irriating chained dependencies, we can JFDI.
[18:08] <infinity> xnox: Especially if there's no API break.
[18:09] <xnox> infinity: ok, after I do the merge and generate new symbols...... I wonder if libconfig is api compatible as well and the soname bump was worthless
[18:10] <infinity> You mean ABI?
[18:10] <infinity> If there's no ABI break, that's a bit of an oops.
[18:10] <infinity> Anyhow, if you do the merge, I can hammer out all the rebuilds.  No point giving me a ton of empty MPs.
[18:50] <xnox> infinity: =))))) hmmm I like empty MPs =))))) they generated multiple bugs against sponsorship page: including gems such as "group by a certain contributors" and "exclude those merge proposals that can only be reviewed by selected members of foundations team"
[19:00] <xnox> infinity: to be fair you only got half of the rebuilds ;-) I have been doing self-service NMU+sync to rebuild some of them ;-)
[19:01] <infinity> xnox: Heh.
[19:01] <Daviey> xnox: no-change debian NMU then sync to Ubuntu to support a Ubuntu transition ?!
[19:03] <xnox> Daviey: no, no senior, le reale patches NMU por RC ants =)
[19:03]  * xnox spanish/french sucks
[19:03] <slangasek> I'm going to have so much fun with you in Nicaragua
[19:03] <infinity> "RC ants"?
[19:03]  * infinity giggles.
[19:04] <slangasek> infinity: les fourmis CR
[19:04] <seb128> xnox, hey
[19:05] <Daviey> xnox: oh good.. i was kinda wtf'ing :)
[19:05] <infinity> slangasek: Thanks for the translation. :P
[19:05] <xnox> seb128: hallo =)
[19:05] <seb128> xnox, if you diff the libconfig.h between those versions you have a bunch of type changes in functions types
[19:05] <seb128>  extern LIBCONFIG_API int config_lookup_int(const config_t *config,
[19:05] <seb128> -                                           const char *path, long *value);
[19:05] <seb128> +                                           const char *path, int *value);
[19:05] <seb128> xnox, like that one
[19:05] <slangasek> infinity: avec prazer
[19:05] <seb128> xnox, so that count as ABI changes
[19:06] <xnox> seb128: and that's the reason why sitplus is FTBFS currently =) why they did, I do not understand.
[19:06] <slangasek> seb128: that's not a C ABI change
[19:06] <slangasek> but it is an API change
[19:06] <infinity> ^
[19:06] <seb128> slangasek, well, the lib has a cpp variant
[19:06]  * xnox better to do this earlier than later
[19:07] <cjwatson> slangasek: Is that true on all architectures?
[19:07] <slangasek> seb128: but that doesn't look like a C++ api call
[19:07] <slangasek> cjwatson: I'm fairly certain it is, yes; sizeof(long *) == sizeof(int *), so even on archs with weird calling conventions (like alpha), it should have no impact on the ABI
[19:07] <cjwatson> Surely if it's big-endian that could end up writing an int into the top half of a long, if the caller was expecting the old abi
[19:07] <slangasek> oh
[19:07] <slangasek> well right
[19:08] <slangasek> I apparently was being too strict in my definition of "ABI" and should drink more coffee
[19:09] <seb128> they changed some structs as well (dropping members of the struct)
[19:09] <seb128> seems like a valid soname change case
[19:10] <seb128> xnox, slangasek, cjwatson: well anyway that was just to add a piece of datas ;-)
[19:11] <slangasek> agreed
[19:11] <slangasek> agreed that it seems a valid change
[19:11] <slangasek> seb128: thanks :)
[19:11] <xnox> for symbols do I generate all symbols with the latest version of libconfig9
[19:11] <xnox> or shall i reuse the 'introduced' version of the libconfig8
[19:11] <xnox> new library, new symbols, start afread?!
[19:12] <slangasek> xnox: not sure I'm understanding the question
[19:12] <slangasek> are you asking what version number to use in the .symbols file for libconfig9?
[19:12] <slangasek> short answer is "it doesn't matter" since there's an ABI break
[19:12] <seb128> slangasek, I think he's asking "if a symbol is there for age, do we keep the version where it was added for the .symbols or do we reset all symbols to the new soname version"
[19:13] <slangasek> i.e., as long as the version you use is <= the minimum version of libconfig9 found in Ubuntu, it will never be an issue
[19:13]  * slangasek nods
[19:13] <xnox> ok.
[19:13] <xnox> not that the old one was ever used, yet was required for 'main' inclusion...
[19:14] <infinity> Wasn't used in what sense?
[19:14] <infinity> dpkg-shlibdeps prefers .symbols over .shlibs, if it exists.
[19:14]  * slangasek nods
[19:14] <slangasek> it's possible the .symbols never gave a different answer for dependencies than the .shlibs did, but it was certainly used :)
[19:15] <slangasek> (but I don't think it's sane to make this a requirement for main inclusion fwiw)
[19:15] <infinity> No, a sane .shlibs is perfectly reasonable in many/most cases.
[19:17] <xnox> infinity: as in, there was never a newer release of libconfig in ubuntu and debian didn't accept symbols file
[19:18] <seb128> xnox, did they reject it or just ignored it?
[19:18] <xnox> ignore.
[19:18] <seb128> unresponsive maintainer I guess
[19:18] <xnox> and the next upstream version bump upload in debian, was abi bump.
[19:18] <seb128> though that package has a cpp lib, which are not .symbols friendly ;-)
[19:18] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618735
[19:18] <ubot2> Debian bug 618735 in libconfig "libconfig: Add symbols to library packages." [Wishlist,Open]
[19:19] <xnox> Date: Fri, 18 Mar 2011 11:36:06 +1100
[19:20] <xnox> slangasek: do you imply that we should drop our 'symbols' file and sync?
[19:23] <slangasek> xnox: that would be my preference... who requested/required the .symbols file in the first place, do you know?
[19:23] <slangasek> (is this in the MIR history?)
[19:23] <seb128> that's one of the things the MIR team like to require ;-)
[19:24] <xnox> slangasek: https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760/comments/2
[19:24] <ubot2> Launchpad bug 730760 in libconfig "[MIR] b-d for libffado" [High,Fix released]
[19:25] <slangasek> seb128: hunh
[19:25] <infinity> xnox: I'm with vorlon on this; I see no reason to carry a delta just for a symbols file, assuming the shlibs are correct.
[19:26] <seb128> slangasek, well, I just know that mterry consistently require to have a .symbols and the testsuit to be run if there is one
[19:26] <infinity> (Yes, it's also nice to use the symbols file to make sure the ABI doesn't break accidentally, but with something we're syncing with Debian, we can hope it'll get caught there if that happens)
[19:26] <slangasek> seb128: I agree with the latter, and not at all with the former... so I'm going to talk to him about this, since it seems to not be in the MIR wiki page at all
[19:27] <infinity> seb128: The second requirement there, I heartily agree with.
[19:27] <slangasek> xnox: stay tuned for further developments on #ubuntu-devel :)
[19:27] <xnox> the idea was that debian picks it up & we sync. Debian didn't pick it up....
[19:27] <seb128> ;-)
[19:27]  * xnox grabs pop-corn and 'Go vorlon' flags
[19:27] <seb128> right, I think mterry just try to encourage us having one, I don't think that's a strict requirement
[19:29] <slangasek> yep - clarification requested
[19:29] <slangasek> in that case specifically, though, he said "rejected" due to lack of symbols files
[19:29] <xnox> I will commit a transition tracker, and wait for resolution on this issue.
[19:30] <infinity> xnox: A transition tracker for 11 packages seems like overkill (it was only 11, yes?)
[19:30] <infinity> xnox: I can just blat them all at the archive after your library builds. :P
[19:30] <seb128> slangasek, well he has been consistently asking for one so I'm not surprised ;-) not sure we ever argued on "we wrote on, sent it to debian, they didn't take it and it's our only diff with them on this source"
[19:31] <xnox> infinity: i like watching green ticks before going to bed ;-)
[19:31] <xnox> in debian there are transition trackers for like 3 packages
[19:32] <xnox> infinity: i am expecting boost1.49 and/or gcc4.7 failures =)
[19:37] <xnox> http://people.canonical.com/~ubuntu-archive/transitions/libconfig9.html
[23:38] <stgraber> can someone reject lxc from proposed? there's an extra fix that we'd like to bundle
[23:40] <RAOF> Done.
[23:41] <stgraber> thanks