[00:02] <ion> Oookay. “Could not back up the following files. Please make sure you are able to open them.” ---x------ 1 ion ion 0 loka  19 12:19 .cache/unitydashlegalseen
[00:03] <ion> Interestingly, .cache is in the ignored “folders” list.
[09:22] <OdyX> tkamppeter: did you see http://bugs.debian.org/690982 ? I plan to take a look but my week-end is packed, so if you had a chance I'd be grateful!
[11:33] <perriman> config.add_apps_prefix("cloudsn.desktop")
[11:33] <perriman> sorry
[11:33] <perriman> How must I migrate an application to use the new message indicator?
[11:33] <perriman> I'm using Indicate with gir
[12:28] <vibhav> Any idea when will the archieve for Raving will open?
[12:28] <vibhav> archive*
[12:38] <infinity> vibhav: It'll open for general upload "soonish", when we're done with both toolchain and some infrastructure mangling.
[12:39]  * vibhav waits impatiently
[12:40] <vibhav> I get excited when I imagine myself writing "raring" in the changelogs :P
[12:40] <infinity> That's a curious fetish.
[12:40] <vibhav> heh
[13:29] <alexbligh1> I'm trying to (re)build Precise's openvswitch package on Lucid (yes, I know). Building works fine with a few tweaks until I get to a missing dh_python2. dh_python2 is provided by Precise's python package. Precise's python package has dh_clean erroring on a '7 being the highest version supported by this debhelper' even though debian/compat is 5. Is there an easier way to do this?
[13:53] <infinity> alexbligh1: debian/compat should probably be 7, not 5.
[13:56] <alexbligh1> infinity, but surely debian/compat LOWER than 7 should be fine? (after all I just pulled the source package from precise)
[13:57] <alexbligh1> s/dh_python2/dh_pysupport/ seems to mostly work (fails to include some python bindings I appear not to need), but is not a complete replacement.
[13:57] <infinity> alexbligh1: The one I just grabbed from precise has a debian/compat of 7...
[13:58] <infinity> alexbligh1: But I don't recall the state of dh_python2 in lucid.  I vaguely recall it's incomplete.
[13:58] <alexbligh1> amb@DBS:~/openvswitch/python/python-defaults-2.7.3$ cat debian/compat
[13:58] <alexbligh1> 5
[13:58] <alexbligh1> It's python-defaults that whinging about compat levels.
[13:58] <infinity> Oh.  That was you rebuilding python-defaults, not openvswitch.
[13:59] <alexbligh1> yeah I was rebuilding python-defaults, to get dh_python2, to build openvswitch.
[13:59] <alexbligh1> But my python knowledge can be written on the feet of a snake.
[13:59] <alexbligh1> dh_python2 is non-existent in lucid. There is a bug saying it is meant to be backported
[14:00] <alexbligh1> https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/788524
[14:00] <infinity> I'm unconvinced that just backporting python-defaults would be remotely sane.
[14:00] <alexbligh1> infinity, yeah, that's why I wondered if there was surgery I could do to debian/rules in openvswitch.
[14:02] <infinity> alexbligh1: Sec.
[14:08] <infinity> alexbligh1: http://lucifer.0c3.net/~adconrad/openvswitch.patch2
[14:08] <infinity> alexbligh1: ^-- That should be all of the pysupport->dh_python2 diff, I believe.  So, just apply that backwards. ;)
[14:09] <alexbligh1> infinity, fantastic, thanks
[14:10] <infinity> alexbligh1: (Was a debdiff between 1.2.0-1 and 1.2.1-2 with all upstream changes removed, and random other bits to debian/ that didn't seem to relate)
[14:24] <alexbligh1> infinity, thanks - I think the python bit has worked. It's now complaining about an xml file being in 2 packages, which I suspect even I can sort
[14:42] <alexbligh1> infinity, I can ping between 2 lucid boxes over an openvswitch gre tunnel so it all 'must work' (tm). Needed to adjust the .install files a bit. Patch here. https://github.com/abligh/openvswitch-lucid/commit/621cedca505bb8af473a1625620bc0bf9c64626b
[14:43] <infinity> alexbligh1: And now to upgrade to precise and stop caring? :)
[14:45] <alexbligh1> infinity, yeah that would be nice. Our new release runs on Precise throughout but is built on lucid partly because our build system is tied to lucid, and partly because half our dev is still on lucid so we can still support lucid easily. Once this release is out we no longer need to do that, so there will be a grand upgrading, and just have some legacy lucid build boxen /vms.
[14:46] <infinity> alexbligh1: Well, we support all the way back to hardy on our (Ubuntu's) build machines, but they're all precise with hardy/lucid/etc chroots.
[14:46] <alexbligh1> infact the very reason for me playing with this was to get two Precise VMs that are distant on the same LAN :-)
[14:47] <alexbligh1> infinity, indeed. All doable, it's mainly the developers' own machines which are the pain right now. I think you guys have some fancy tool that generates a chroot of a different distro (schroot or something?)
[14:47] <infinity> alexbligh1: The only caveat is that we use linux32/linux64 --uname-2.6 to work around the fact that some build scripts have a hissy fit about kernels that are 3.x.x
[14:48] <infinity> alexbligh1: mk-sbuild, which is just a fancy wrapper around debootstrap, makes schroot/sbuild chroots, which is what our devs tend to use (or they use full VMs), yeah.
[14:49] <alexbligh1> infinity, yeah we have a backlog of housekeeping stuff awaiting the end of month release (including a long awaited switch from svn to git - finally!)
[14:49] <infinity> alexbligh1: \o/
[14:50] <infinity> Thanks for accidentally reminding me that I need to get around to moving the debian-glibc revision control from svn to git...
[14:50] <infinity> Maybe this is a good week to do that.
[14:52] <alexbligh1> infinity, I think our svn repo is now larger than any one hard disk (eek), due to some design naivity early on. So we have had fun running a constant incremental conversion to git.
[22:44] <jamin> got a permissions regression with polkit between 12.04 and 12.10 (presumably due to move to udisk2): https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1069234