[01:11] <jdstrand> @pilot out
[01:48] <Kaleo> http://www.indiegogo.com/projects/ubuntu-edge/ amazing
[03:34] <lifeless> jamesh_: ping
[03:34] <jamesh> lifeless: hi.
[03:34] <lifeless> jamesh: django-openid-auth - can we get a release of the current code to pypi ?
[03:36] <jamesh> I'll get on it.
[03:36] <lifeless> jamesh: briliant, thanks!
[03:37] <jamesh> was a bit busy yesterday with other stuff so didn't get round to responding :(
[03:37] <lifeless> jamesh: thats ok
[03:37] <lifeless> jamesh: I can be a squeaky wheel when needed :)
[04:02] <micahg> pitti: can you merge mutagen?   it seems some things build dep on the new version, I'd be happy to do it if you want
[04:46] <pitti> Good morning
[05:38] <pitti> micahg: yep, will do now
[05:41] <micahg> pitti: thanks
[05:50] <pitti> micahg: uploaded
[08:11] <pitti> @pilot in
[08:21] <darkxst> pitti, hey!
[08:21] <pitti> hey darkxst, how are you?
[08:22] <darkxst> good thanks
[08:36] <ivanka> morning rickspencer3
[08:36] <rickspencer3> hiya ivanka
[09:34] <seb128> ev: hey
[09:35] <ev> hiya
[09:35] <seb128> ev: "* Move the .so file from libwhoopsie-preferences0 to libwhoopsie-preferences-dev." ... you need to make libwhoopsie-preferences-dev Replaces libwhoopsie-preferences0 (<< update-version)
[09:35] <ev> gah, sorry and thanks for the catch
[09:35] <ev> fixing
[09:35] <seb128> ev: otherwise updates are going to break, depending of the order where things get unpacked
[09:35] <seb128> ev: yw
[09:39] <ev> seb128: would you mind quickly spot checking this: http://paste.ubuntu.com/5903513/
[09:39] <seb128> ev: +1
[09:39] <ev> whoop
[10:02] <ev> Laney: regarding moving diagnostics as a subdir under security-privacy (https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385/comments/394002) do you mean just in the build tree, or do you want them to effectively be the same plugin?
[10:03] <Laney> ev: Well, diagnostics will be a part of security & privacy
[10:03] <Laney> UI-wise it's fine ATM
[10:03] <Laney> but yeah, I mean to move them in the source tree
[10:04]  * ev nods
[10:04] <ev> off to figure out how to do that in qmake
[10:21] <ev> Laney: how's that http://paste.ubuntu.com/5903621/
[10:22] <Laney> ev: yep, if that works - looks good
[10:23] <ev> it does :)
[10:23] <ev> cheers
[10:55] <doko> mlankhorst, uploaded. my changes are not nice, but it builds ...
[10:55] <pitti> jibel: did you happen to have a look at https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc/+merge/172856 already?
[10:56] <mlankhorst> doko: ok I'll put them in ubuntu packaging at one point :p
[11:02] <rbasak> pitti: thanks for looking. Actually I'll mark that wip - there are a couple of issues I've found since that I need to investigate.
[11:03] <pitti> rbasak: ack, thanks; I don't currently have an LXC setup here to test (using schroot/sbuild), and was asking jibel because I think he has
[11:05] <xnox> doko: about bug 1202153 do I need to reproduce with fsf toolchain and file a bug there, and in the mean time build with gcc-4.7?
[11:05] <jibel> pitti, I didn't yet, I'm buried into daily-release testing on touch, I'd like to release it today or tomorrow
[11:05] <pitti> jibel: no worries, rbasak just said he still wants to make some changes
[11:05] <doko> xnox, I think there is a debian report too
[11:07] <xnox> doko: you mean http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701269 ? merging that didn't help, and i had that applied already.
[11:07]  * xnox ponders if me generating source package on amd64 somehow leaked into the upload.
[11:08] <doko> xnox, I'll redo the debian build ...
[11:10] <ev> anyone know offhand of a qt-based package that does dbus service activation right?
[11:10] <ev> on the consuming end, that is
[11:10] <ev> QDBusInterface.isValid() seems to either be not what I want, or only half of the puzzle.
[11:11] <ev> god I miss google codesearch
[11:12] <Laney> try Debian codesearch
[11:12] <ev> jodh: where's my solr?
[11:12] <ev> ooh
[11:13] <jodh> ev: you mean opengrok :)
[11:13] <ev> Laney: that's definitely a step in the right direction. Thanks!
[11:13] <ev> jodh: that doesn't sound very webscale.
[11:16] <jodh> ev: I can't see through all the buzz-words on the solr page to see what file formats it actually understands... apart from pdf, html and .doc that is...
[11:16] <ev> I'm just toying with you. I'm sure opengrok would be the more appropriate fit.
[11:20] <Laney> ev: I guess maybe you have to watch for NameOwnerChanged too
[11:20] <Laney> I think I probably need to do that as well in my panel
[11:21] <ev> Laney: yeah, stackoverflow suggests that as well: http://stackoverflow.com/questions/1423739/waiting-for-a-dbus-service-to-be-available-in-qt
[11:21]  * Laney nods
[11:22] <ev> you'd figure the convenience API would handle this sort of thing.
[11:24] <Laney> gotta love boilerplate
[13:13] <pitti> @pilot out
[13:20] <marga> How do I indicate in a bug that it is present in Precise but not present in Quantal onwards?
[13:21] <marga> Ah, I don't seem to be able to do it.
[13:21] <marga> https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1004515
[13:22] <marga> One user accidentally clicked "Fix Released", but it was a mistake.
[13:22] <marga> The bug is still present in Precise, and is not present in any later version.
[13:22] <seb128> marga, you mark it fix released and do "also affect precise"
[13:24] <marga> Where is that?  I only see "Also affects distribution" and "Also affects project"
[13:24] <micahg> seb128: only bug control members can target to release
[13:25] <seb128> micahg, other can propose for a serie though
[13:25] <micahg> not for a while now (it was being abused)
[13:25] <marga> :(
[13:26] <marga> I always saddens me when nice features have to be blocked due to abuse
[13:26] <micahg> sorry, devs can target, bug control can request
[13:31] <JackYu> seb128: hi, I submitted two sponsor requests for two new packages at bug #1203958 and bug  #1203931,  would you please help me to upload them?
[13:31] <marga> I'm really sad that I took quite a number of hours to track down the bug and the fix, I created the patch following SRU rules, then waited and waited for the sponsor... And then I get sponsors unsubscribed because it's marked as "Fixed released", when the user that marked it says in the log that it was a mistake. :(
[13:40] <seb128> JackYu, hey, can you try to pitti or barry (they are patch pilot todayà
[13:40] <seb128> )
[13:41] <JackYu> seb128, okey, thanks:)
[13:41]  * barry will likely be piloting in 4h
[13:41] <Ampelbein> marga: I targeted 1004515 to precise and resubscribed the sponsors team.
[13:42] <marga> Ampelbein, tnx
[13:45] <xnox> bug 1004515
[13:46] <seb128> marga, (sorry was in a call, reading backlog)
[13:48] <seb128> marga, sorry about that, don't hesitate to ping here when bugs get wrongly closed or when they are not in the right status and you don't have the right to reopen
[13:48] <marga> tnx
[13:50] <JackYu> barry, hi, would you please help to sponsor two new packages at bug #1203958 and bug  #1203931 when available?
[13:50] <xnox> hmm.... my kvm is broken on saucy. Is there something I can do to unbreak it?
[13:52] <barry> JackYu: happy to look, but it will be a few hours
[13:53] <rbasak> xnox: could this be related to bug 1203211? Are you running 3.10.0-4, and if so try "modprobe kvm_intel"?
[13:53] <JackYu> barry, that's great, thanks.
[13:53] <xnox> marga: uploaded. Had to add a bug reference number, seems like bug 1067414 became a dupe of 1004515 in the mean time, so added both just in case sru-report gets confused.
[13:53] <yolanda> pitti, i saw your comments about libnss-ldap, it's ok for me to take a look at the changelog
[13:53] <marga> xnox, thanks.
[13:53] <yolanda> actually i grouped some of the entries because it was very messi, but i know it can be done better
[13:53] <xnox> rbasak: yes, that's the one.
[13:54] <xnox> rbasak: so i guess i can reboot into older one in the mean time.
[13:54] <xnox> thanks a lot.
[14:07] <tseliot> pitti: is there a way to use jockey with unsigned repositories? (even a hack, just for local testing)
[14:14] <wgrant> pitti: The langpack crontab changes have been deployed now, so you should get something in a couple of days.
[14:17] <wgrant> Friday morning, I guess
[14:26] <shadeslayer> kenvandine: poke poke https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1203336
[14:26] <pitti> wgrant: ah, thanks muchly
[14:26] <pitti> tseliot: I'm afraid you'd have to disable that check in the code
[14:27] <kenvandine> shadeslayer, i would love to have that decoupled
[14:27] <pitti> tseliot: i. e. where it allows "arch: all" packages unsigned
[14:27] <shadeslayer> kenvandine: hurray
[14:27] <tseliot> pitti: right but there is also another condition: "and not pkg.candidate.uri.startswith('file:/')"
[14:28] <tseliot> pitti: so it shouldn't affect my local repository
[14:28] <kenvandine> shadeslayer, but upstream says it isn't trivial
[14:28] <pitti> tseliot: ah, so it should just work then
[14:28] <shadeslayer> kenvandine: oh? I didn't see the plugins linking to empathy in any way
[14:28] <tseliot> pitti: good, thanks
[14:28] <shadeslayer> kenvandine: just a runtime dep?
[14:29] <kenvandine> shadeslayer, empathy has a private libempathy that is needed for the plugins provided by empathy
[14:31] <shadeslayer> kenvandine: oh ... ldd didn't say anything about that
[14:33] <kenvandine> shadeslayer, yeah, it's confusing
[14:34] <shadeslayer> :)
[14:41] <stgraber> jbicha: ping
[14:41] <jbicha> stgraber: hi
[14:41] <stgraber> jbicha: I'm looking at bug 1196667, it looks like there are at least two packages currently depending/recommending appmenu-gtk/appmenu-gtk3, can you get those fixed first?
[14:42] <stgraber> jbicha: that's kubuntu-full and kubuntu-desktop
[14:42] <Riddell> mm?
[14:42]  * stgraber checks the seeds
[14:43] <stgraber> stgraber@castiana:~/data/code/sync-blacklist$ reverse-depends appmenu-gtk
[14:43] <stgraber> Reverse-Recommends
[14:43] <stgraber> [14:43] <stgraber> * kubuntu-desktop
[14:43] <stgraber> * kubuntu-full
[14:43] <stgraber> Riddell: ^
[14:43]  * jbicha defers to Riddell
[14:44] <stgraber> Riddell: ah, I see you have it in you desktop seed for some reason, I'm assuming -full then gets it as it's a superset of -desktop
[14:44] <Riddell> yeah it will
[14:44] <jbicha> well I believe appmenu-gtk used to work with KDE's appmenu implementation but the new unity-gtk-module doesn't
[14:45] <Riddell> so appmenu-gtk is obsolete?
[14:45] <jbicha> yes, it's unmaintained and won't build
[14:45] <roaksoax> cjwatson: howdy! I have a quick question. If a package sits in -proposed for depwait, and then I manaully trigger the build again (through lp), and it builds successfully. Does it gets moved out of proposed automatically? Or needs manual intervention? or should I upload a no change rebuild?
[14:45] <stgraber> Riddell: the equivalents would be unity-gtk2-module and unity-gtk3-module but they may indeed be incompatible and may pull extra stuff you don't want
[14:46] <cjwatson> roaksoax: doesn't need manual intervention, doesn't need a reupload
[14:47] <roaksoax> cjwatson: how long will it sit there then?. I told LP to rebuild last night and it is still sitting in -proposed.
[14:47] <roaksoax> cjwatson: package: corosync
[14:48] <cjwatson> roaksoax: then something else is wrong
[14:48] <cjwatson> trying: corosync
[14:48] <cjwatson> skipped: corosync (1 <- 75)
[14:48] <cjwatson>     got: 102+0: i-102
[14:48] <cjwatson>     * i386: booth-pacemaker, clvm, cman, gfs-pcmk, gfs2-cluster, gfs2-utils, libccs-dev, libccs-perl, libccs3, libcrmcluster1, libcrmcluster1-dev, libfence-dev, libfence4, ocfs2-tools-pacemaker, pacemaker, pacemaker-dbg, pacemaker-dev, pacemaker-mgmt, pacemaker-mgmt-dev, redhat-cluster-suite, rgmanager, sheepdog
[14:48] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[14:49] <stgraber> Riddell: so I don't really care whether you just drop those two packages or you move to unity-gtk2-module and unity-gtk3-module, but I'd like to remove appmenu-gtk from the archive, so let me know which of the two options you want and I'll take care of changing the seeds and uploading.
[14:49] <cjwatson> roaksoax: given the changes involved here, I expect you have a library transition that you need to deal with
[14:49] <Riddell> stgraber: I've removed them from the seeds now
[14:50] <Riddell> stgraber: and updating kubuntu-meta
[14:50] <stgraber> Riddell: cool, are you germinate+uploading the meta too?
[14:50] <stgraber> awesome
[14:50] <stgraber> I'll wait for that to land in the release pocket before processing the removal so I don't break your builds and/or updates
[14:50] <jbicha> Riddell: see bug 1200006
[14:56] <roaksoax> cjwatson: right, so there should really be there no change for package depending in corosync and its libs. The lib remains to be the same version, new libs have been added though.
[14:59] <cjwatson> roaksoax: proposed-migration disagrees and it's usually right :)
[15:00] <roaksoax> cjwatson: yeah I'm looking into why it might be :). Thanks!
[15:00] <cjwatson> roaksoax: I suspect perhaps a binary package got dropped?
[15:01] <cjwatson> roaksoax: There's libcfg4 -> libcfg6 at least
[15:02] <roaksoax> cjwatson: Maybe, but most packages would depend on libcorosync4 or libcorosync-dev which still exists. But yes that might also be one of the reasons. I'm looking into that now! Thanks!
[15:02] <cjwatson> libconfdb4, libcoroipcc4, libcoroipcs4, libevs4, liblogsys4, libpload4 dropped
[15:02] <cjwatson> libtotem-pg4 -> libtotem-pg5
[15:03] <cjwatson> libvotequorum4 -> libvotequorum6
[15:03] <cjwatson> installing cman in saucy-proposed tries to install libconfdb4 for instance
[15:03] <cjwatson> indeed cman directly depends on libconfdb4
[15:04] <roaksoax> yeah, i just spotted that myself. but redhat-cluster-suite is material to be dropped from the archive altogether
[15:04] <roaksoax> but don't know whether that will happen now
[15:04] <infinity> roaksoax: If these are all ABI bumps but not API bumps, rebuilding things is trivial.
[15:04] <cjwatson> pacemaker depends on libconfdb4 directly
[15:05] <roaksoax> cjwatson: not anymore, newer pacemaker version doesn't use it. Which i'm about to upload.
[15:05] <cjwatson> And sheepdog Depends: libcfg4
[15:05] <cjwatson> roaksoax: it's not "not anymore" until it's in the archive and ready for migration itself :P
[15:05] <roaksoax> :)
[15:07] <dbarth> hi, can i ask a quick one for multi-arch experts?
[15:07] <dbarth> this an issue with a citrix package requiring libwebkitgtk-1.0-0:i386 which depends on libwebkitgtk-1.0-common:i386
[15:08] <dbarth> but only libwebkitgtk-1.0-common:all is available (both on precise and raring)
[15:08] <cjwatson> Somebody should probably make libwebkitgtk-1.0-common Multi-Arch: foreign
[15:08] <dbarth> ok, so same as flahplayer installer or something
[15:08] <cjwatson> Not really but whatever :)
[15:08] <dbarth> which i think had the same issue; now fixed in saucy i think
[15:09] <dbarth> ok, i can make a merge prop and see if a test package fixes the problem
[15:09] <cjwatson> Lots of stuff needs M-A annotations, it's rather dramatically well beyond flashplayer
[15:09] <dbarth> ok, then i've spotted one
[15:09] <cjwatson> libwebkitgtk-1.0-0 could use being properly converted to multiarch, but that's a separate problem
[15:09] <dbarth> thanks for the quick feedback
[15:09] <dbarth> well, yes
[15:32] <mpt> ev, have you diagnosed the July 9th spike yet?
[15:33] <ev> mpt: not yet - I've been staying away from Cassandra stuff with the database being in quite a bad way at the moment. I hope to get to that this week though. Adding a reminder.
[15:33] <mpt> k
[16:08] <tedg> jodh, Can I use libupstart without a NIH mainloop?
[16:10] <xnox> tedg: but NIH loop is wonderful =)))) why would you?
[16:11] <tedg> xnox, Because I already have a glib one.  Having two is no fun.
[16:11] <xnox> i think stgraber before had something before to use one or the other, or both. Not sure if it was glib or qt mainloops with nihloop.
[16:12] <Laney> xnox: where's the vcs for libtimezonemap?
[16:12] <xnox> Laney: lp:timezonemap
[16:12] <jodh> tedg/xnox: yes, stgraber had issues with multiple main loops with the dconf-bridge which is now in my court. I guess you don't need to use the nih main loop, but you still need to create NIHDBusProxy objects, etc.
[16:13] <stgraber> xnox: it's the dconf bridge which uses libnih for some bits and glib for the rest, though the loop is glib, trying to get glib to run part of the nih loop or the opposite blew up quite badly
[16:13] <Laney> xnox: lies
[16:13] <Laney> oh
[16:13] <Laney> without the 'lib'
[16:13] <Laney> grr
[16:13] <tedg> jodh, Okay, I just can't use the async stuff.
[16:13] <stgraber> xnox: I was basically trying to call the single iteration function every time the other loop would run but that didn't quite work as well as it should have
[16:13] <jodh> stgraber: right, I'm currently having to essentially "rewrite" bits of NIH in GDBusProxy for the dconf-bridge as there is no way that I can see to convert between all the DBus/GDbus/NihDBus types.
[16:13] <xnox> Laney: that's gtk3 one, there is older project under different name for gtk2
[16:13] <tedg> jodh, That should generally be fine, but then how does nihdbus get the signals back?
[16:14] <tedg> How does upstart-monitor do this?  Is it just all GLib?
[16:17] <jodh> upstart-monitor just uses GLib to monitor the EventEmitted signal.
[16:24] <jodh> tedg: NIH handles the async dbus responses by calling nih_main_loop_add_func(nih_dbus_callback) where that callback just calls dbus_connection_dispatch repeatedly until the result != DBUS_DISPATCH_DATA_REMAINS.
[16:26] <tedg> I guess I was worried that there'd be no watch on the file handle for the dbus connection.
[16:26] <tedg> As the GLib main loop wouldn't select it.
[16:38] <Laney> xnox: I'd appreciate it if you could review/upload timezonemap today so that I can BD on that version from system-settings
[16:38] <Laney> if you have time etc
[16:38]  * Laney proposed the merge
[16:39] <xnox> Laney: I better do it now, as I am off until monday =/
[16:40] <Laney> xnox: or I can just upload and you can fix bzr later
[16:40] <Laney> (or someone else; I guess it's not a team of 1 :P)
[16:40] <xnox> Laney: meh, easy, will do in a sec
[16:40] <Laney> awesomes, thanks
[16:42] <xnox> Laney: well, ev is admin, mterry is lurker, and i am the minion on the team.
[16:42]  * Laney cracks the whip
[16:42] <xnox> Laney: not in public =))))
[16:42] <Laney> ^o)
[16:45] <xnox> Laney: uploaded.
[16:46] <Laney> thanks
[16:46] <Laney> now go have a nice holiday :P
[16:48] <xnox> Laney: thanks :P
[16:49]  * ev feeds the minion
[16:49]  * mterry lurks
[16:49] <ev> lol
[16:49]  * xnox nom nom
[17:14] <ari-tczew> pitti: hi! thanks for sponsoring. I'm sorry for FTBFS in postgis. I did the buildtest only on i386.
[18:25] <lfaraone> Anybody in ~ubuntu-security got a minute?
[18:26] <sarnold> hey lfaraone :)
[18:50] <barry> @pilot in
[19:52] <blitzkrieg3> idia
[21:13] <robert_ancell> mterry, hey, will you still be able to run u-g8 as a mir server if you also make it support running as a mir client? (-> #ubuntu-mir)
[21:50] <robert_ancell> pitti, here?
[21:59] <achiang> is there a quick 'n dirty way to find number of armhf packages without spinning up a VM?
[22:00] <achiang> some web interface would be swell
[22:01] <jpds> achiang: wget http://ports.ubuntu.com/dists/saucy/main/binary-armhf/Packages.gz; gunzip Packages.gz; grep "^Package:"" | wc -l
[22:02] <infinity> achiang: https://launchpad.net/ubuntu/saucy/armhf
[22:03] <infinity> achiang: Or, if you prefer: https://api.launchpad.net/1.0/ubuntu/saucy/armhf
[22:04] <achiang> jpds: infinity: thanks!
[22:16] <roaksoax> infinity: howdy! Do you happen to know why pacemaker remains as "New" and does not seem to be "released" into -proposed? https://launchpad.net/ubuntu/+source/pacemaker/1.1.9+git20130321-1ubuntu1
[22:24] <xnox> roaksoax: have you checked proposed-migrations?
[22:24] <roaksoax> xnox: yeah nothing about pacemaker
[22:24] <xnox> roaksoax: queues?
[22:25] <xnox> roaksoax: https://launchpad.net/ubuntu/saucy/+queue
[22:25] <xnox> roaksoax: pacemaker starting building new packages, one can see if expands a build. thus it requires an Archive Admin to review and accept or reject them.
[22:26] <roaksoax> xnox:ah I see
[22:26] <xnox> roaksoax: usually they accept =) there are only a few archive admin, but things are processed from time to time.
[22:26] <xnox> roaksoax: until then, britney will think it's out of date.
[22:26] <xnox> roaksoax: by the way, pacemaker is mentioned on the excuses page.
[22:27] <roaksoax> yeah I just saw that too
[22:27] <xnox> roaksoax: http://people.canonical.com/~ubuntu-archive/proposed-migration/ see excuses, pacemaker - out of date on bunch of arches, not considered.
[22:27] <roaksoax> xnox: yeah that's what I just saw. Which doesn't make sense to me
[22:27] <xnox> this means britney will not even attempt migrating, as it's not fully build on all arches it previously was built on.
[22:27] <xnox> that =)
[22:28] <xnox> roaksoax: wait, or poke infinity / stgraber / Daviey to process new in saucy =)
[22:29] <roaksoax> yeah I'll just wait. Since I'm EOD anywya :)
[22:29] <roaksoax> xnox: thanks for the info
[22:29] <xnox> no problem =)
[22:40] <ari-tczew> I guess there is a similar bug like on MoM @ http://qa.ubuntuwire.com/bugs/rcbugs/saucy/
[22:40] <ari-tczew> It doesn't take Ubu-version from -proposed.
[22:40] <ari-tczew> Correct me if I'm wrong.
[22:41] <cjwatson> Sure, it just needs NEW processing
[22:41] <cjwatson> I'll do it now
[22:41] <cjwatson> proposed-migration doesn't see things in NEW, which is why it thinks it's out of date
[22:42] <ari-tczew> cjwatson: ok!
[22:45] <ari-tczew> cjwatson: are you on the bug 1202142 as well?
[22:47] <cjwatson> It's on my list
[22:47] <cjwatson> And no, proposed-migration doesn't have a bug where it doesn't know about -proposed.  It would be entirely useless if it did :-P
[22:47] <cjwatson> Given that its entire purpose is to migrate things from -proposed
[22:49] <Laney> I think he thought you were referring to the previous question about the rcbugs page, when in fact you were not
[22:49] <cjwatson> roaksoax: You can drop the libcorosync-dev and libqb-dev deltas from pacemaker at the next merge - we no longer need lower versions there
[22:50] <cjwatson> roaksoax: It might then be worth build-testing to see if the added Build-Depends: libcfg-dev is still necessary, since if it isn't we can just sync pacemaker unmodified
[22:50] <cjwatson> Ah, I see, indeed I was not referring to rcbugs, sorry
[22:50] <ari-tczew> okok
[22:51] <cjwatson> Wouldn't be surprising if it had a similar bug
[22:51] <cjwatson> roaksoax: NEWed
[22:52] <cjwatson> roaksoax: Won't help on its own of course, since at least redhat-cluster-suite and sheepdog still need to be resolved too
[22:52] <cjwatson> Looks like sheepdog is blocked by a couple of build failures
[22:53] <roaksoax> cjwatson: I already have a sheepdog fix, and we are dropping redhat-cluster-suite from the archives (or maybe we;'ll just leave it as a transitional package), but all its binaries will disappear
[22:53] <cjwatson> I did say "resolved", not necessarily fixed
[22:53] <roaksoax> cjwatson: the problem with pacemaker is that in debian, it is build-dep/dep in a revision of corosync that does not exist in debian, hence it would FTBFS in UBuntu without the delta
[22:53] <cjwatson> Point is, don't expect corosync to enter the release pocket until that's done, not just planned
[22:53] <cjwatson> roaksoax: That's not true in the version I checked.
[22:54] <cjwatson> roaksoax: The versions used in Debian experimental exist in Ubuntu just fine
[22:54] <roaksoax> cjwatson: http://packages.qa.debian.org/c/corosync.html experimental shows 2.3.0-1, and pacemaker was Build-dep/dep on 2.3.0-2
[22:54] <roaksoax> cjwatson: and yes, I'll get those two (sheepdog/redhat-cluster) fixed this week
[22:54] <cjwatson> How is that relevant when it's 1.4.4-3 in saucy?
[22:55] <cjwatson> Oh, 2 > 1
[22:55] <cjwatson> Counting hard
[22:55] <roaksoax> yeah so, this is a "major" upgrade of the cluster tools, so pacemaker 1.1.9 depends on corosync > 2.X
[22:55] <cjwatson> roaksoax: OK, fair enough on libcorosync-dev, but that doesn't explain libqb-dev
[22:56] <cjwatson> saucy has 0.14.4-1ubuntu1, so there's no need to drop the build-dep minimum version from 0.14.4 to 0.14.3
[22:57] <cjwatson> And libcorosync-dev depends on libcfg-dev, so on the face of it there doesn't seem a reason to introduce an Ubuntu delta to have pacemaker build-depend on libcfg-dev as well as libcorosync-dev
[22:57] <cjwatson> Looks like the only thing you still need is to drop the libcorosync-dev version
[22:58] <cjwatson> And harass Debian about fixing that properly in experimental
[22:58] <cjwatson> Then we can just sync pacemaker
[22:58] <roaksoax> cjwatson: yeah the thing is that libcorosync-dev is just a transitional package
[22:58] <cjwatson> Hm, it seems kind of anti-transitional if it's stopped depending on libcfg-dev in -proposed
[22:59] <cjwatson> It could just as well have kept that dependency to smooth the transition further
[22:59] <cjwatson> Anyway, minor details
[23:01] <roaksoax> cjwatson: I spotted an issue in the corosync package (the -dev didn't depend on its libraries), so that might be the reason why I had to add the dependency on libcfg-dev while keeping libcorosync-dev
[23:02] <roaksoax> and the reason why I lowered the versioning for libqb was because when I initially worked on this there was no libqb 0.14.4. Debian had just been updated when I was to upload to the arcvhive
[23:03] <roaksoax> or I think i made another upload with the newer version, yeah that was it
[23:08] <cjwatson> roaksoax: *nod*
[23:12] <roaksoax> cjwatson: thanks for looking at it though! :)
[23:35] <TheMuso> @pilot in
[23:46] <ahasenack> does anybody have a tip on how to add a ppa to a local sbuild build?
[23:48] <micahg> pass  --chroot-setup-commands='apt-get install -y python-software-properties' --chroot-setup-commands='add-apt-repository ppa:myppa/foo' --chroot-setup-commands='apt-get purge -y python-software-properties' --chroot-setup-commands='apt-get update'
[23:48] <micahg> replace myppa/foo appropriately
[23:49] <ahasenack> ok, yeah, I was going down that route
[23:50] <ahasenack> I also need sudo
[23:50] <micahg> ahasenack: why do you need sudo?
[23:51] <ahasenack> I think it's how I created this chroot, a long time ago
[23:51] <ahasenack> it has my user, binds my home, etc
[23:51] <ahasenack> and in raring it's software-properties-common, ok
[23:52] <micahg> ISTR someone has a wrapper to make this easier