[00:01] slangasek: I think the google-calendar issue is a bug in python-4suite-xml rather, I've reassigned the Debian bug. Not sure what to do about it for hardy though [00:01] Any motu-release people around? [00:06] azeem: ok, I'll take a peek at this sometime over the weekend [00:07] easiest would be to apply doko's one line patch to 0.22-4 [00:07] 0.22-5 is botched === Pici` is now known as Pici [00:49] hmm FTBFS for tex4ht ( Build-Depends-Indep dependency for tex4ht cannot be satisfied because no available versions of package java-gcj-compat-dev can satisfy version requirements ) + bug 216027 [00:49] Launchpad bug 216027 in tex4ht "[hardy] unmet dependency blocking upgrade of tex4ht" [Undecided,Confirmed] https://launchpad.net/bugs/216027 [00:49] what do we do if a whole package is broken like this, after the freeze? [00:50] 1) we swear at whoever it was who asked for that package to be synced [00:51] :p [00:51] oh wait, maybe we don't do that [00:52] we can, however, twist doko's arm and demand that he fix it :) [00:54] oh, no [00:54] doko requested it originally, but the latest sync was someone else reopening the sync bug instead of filing their own [00:54] hmm, and mok0's not here to have his arm twisted. :) [00:55] ... or, on reflection, this is entirely my fault because it was meant to be synced from testing instead of from unstable, which means I grabbed the wrong version, hooray! [00:55] * xtknight sports a puzzled look on his face [00:55] bug #131239 [00:55] Launchpad bug 131239 in tex4ht "sync request" [Wishlist,Fix released] https://launchpad.net/bugs/131239 [00:58] oh well. sync happens. [00:58] :) [00:59] well, I think this is fixable just by relaxing the build-dependency [00:59] (doesn't ensure that the package from unstable is usable, but we have to take our chances there :/) [01:00] so it's too late to grab the testing version or too unfeasible at this stage? [01:00] it's too late to do it as a sync, because hardy already has a higher version number [01:00] so it'd have to be an epoch (meaning Debian and Ubuntu would never sync again), or a faked version number (meaning Ubuntu couldn't sync again until the next upstream version) [01:00] I'm going to try the trivial fix [01:01] if it doesn't work, do you want to punch me to get me to try the less trivial fix? :) [01:01] "debian and ubuntu would never sync again" sounds like the universe is ripping apart at the seams [01:02] heh [01:02] there's probably a secret "invent bogus reasons to bump epoch in Debian, so we can sync again" agency somewhere [01:03] I had to add an epoch to an Ubuntu package once, but the Debian maintainer emailed me shortly afterwards saying he'd add it to his next Debian upload to make it less painful. [01:03] (in this case it was due to a naming conflict with an Ubuntu-specific package) [01:09] compiles just fine if you make the java deps >= 1.0.77 (note, compiles fine) [01:10] yep, that's the trivial fix I'm currently attempting [01:10] and it runs although i haven't put any tex files through it [01:11] how would a newer version of tex4ht but the same old version of tex4ht-common get in the archive? aren't things synced by using source? if so how did one binary package get built just fine on the build farm? [01:11] i mean both come from tex4ht source package [01:12] xtknight: because the -common package is arch: all, which means it only gets built once for all archs; so every other architecture, whose buildd isn't supposed to build the arch: all packages, gets the updated tex4ht package without tex4ht-common [01:13] ah [01:14] it seems as though it should automatically file a launchpad bug if a build fails, or notify somebody. maybe that somebody just hasn't noticed [01:16] Is there a good channel for asking non-basic debhelper questions? [01:17] here or #debian i think [01:20] Ok. I'm trying to fix up an existing (poorly maintained) package for ubuntu. In the .install file, it has lines like "usr/bin/perlbal /usr/sbin". Is that first line referring to the directory that gets built in the debian folder? i.e. debian//usr/sbin ? [01:21] yes [01:23] Which dh_* creates those build directories (and the files within)? dh_installdirs? [01:24] dh_install is what processes .install files [01:27] Right, but how does "debian//usr/bin" get created in the first place? Doesn't dh_install go from your build directories (debian//usr/bin/perlbal) to your system directories (/usr/sbin)? [01:29] I guess that's why I'm confused... it seems like the line "usr/bin/perlbal /usr/sbin" is referencing a file IN the build directories, but at the same time, dh_install CREATES those files. Seems circular to me. [01:31] no, dh_install copies files from to debian// [01:31] dh_install has a manpage that's supposed to explain this :) [01:32] It does, and I've read it, but I'm confused about this specific line [01:32] ohhh [01:32] i'm guessing [01:32] that [01:32] the makefile in the PARENT of debian [01:32] is creating a usr/bin/ directory [01:33] as part of the install target, normally, yes [01:33] ahh, i misphrased my first question, which is what got me confused [01:33] ok [01:33] ok [01:38] Last question. I've looked through the debian policy manual and the maintainers guide, I know that template conf files should go in /usr/share/. Is there a standard place to put them in my build package? Can I just make a defaults/ directory as a sibling to debian/ and install it with perlball.install, or is there a special debhelper for that (like for docs)? [01:40] Or would it make more sense to place them within my debian/ folder? [01:40] it's customary to limit oneself to the debian/ directory within the source package [01:41] Makes sense. And then i could just use "debian/perbal.conf.default /usr/share/perlbal" in my .install file. [01:42] Or "debian/defaults/perlbal.conf.default /usr/share/perlbal" [01:43] indeed [01:43] Ok. Thank you very much. [01:43] n/p [02:10] Heya gang [02:11] * slangasek waves [02:14] Hello slangasek [02:17] Hi [02:18] * blueyed is buffled that we have b2evolution in Ubuntu? I remember having asked for it some time ago and somehow it must have been in there already.. totally outdated. [02:19] There's the current stable release in Debian now. So it should get either synced or removed. (I'm part of upstream) [02:38] blueyed: please file a bug against the ubuntu package requesting removal, and subscribe ubuntu-archive [02:38] slangasek: I would rather like to request a sync/upload. Found already typos in the german templates. Or is removal the only option? [02:39] we're in hard freeze [02:39] you can request a sync through motu-release, but I guess they'll probably say no? [02:39] ok, better this way anyway. People should not be stuck at this version for up to 5 years.. :D [02:40] slangasek: status of the bug? new? [02:41] blueyed: "confirmed,medium" [04:14] TheMuso: Shouldn't vlc only recommend the pulse plugin? [04:27] TheMuso: ping [04:27] Hobbsee: Can you poke things through UNAPPROVED, please? [04:28] If LP works now, that is. [04:28] Fujitsu: no. i tried that last night. They broke it again. [04:28] So I saw. [04:28] hmm, i'll try it again, i asked cprov to tell me when he'd fixed it, though [04:29] heya [04:29] Fujitsu: nah, it's still broken. [04:30] Hobbsee: Lovely. [04:30] Fujitsu: i hope for a cherry pick. I'm going to get really annoyed if they don't fix it before the next rollout. [04:31] Fujitsu: then again, if they don't fix it before the next rollout, we'll know they didn't actually test the new bits in the rollout. [04:31] But having no universe archive admins pre-release is *fun*. [04:31] We have no usable archive admins outside very western Europe now, do we? [04:31] mm, correct. [04:31] Hm, and the US, actually. === danielm_ is now known as danielm [04:32] Fujitsu: yeah, that's why i tried for him. [05:51] RAOF, you here? [05:53] Hobbsee: pong [05:53] Fujitsu: Did you read the bug in the changelog? === asac_ is now known as asac [07:51] TheMuso: I did not. [07:54] TheMuso: Recommends are installed by default, and we're going to get hordes of people complaining that they can no longer get rid of PA> [09:38] Hello, how can I create a source.changes file for a source package ? [09:41] join #ubuntu-devel [09:41] whoops forgot the / [09:41] AnAnt, run debuild -S [09:41] eheheh hi xtknight [09:41] :) [09:41] so [09:41] xtknight: should I unpack the source package ? [09:42] AnAnt, yes where did the source package come from ? a tarball or debian? [09:42] xtknight: I got dsc + diff.gz + orig tarball [09:42] about Bug #201462 and Bug #186938 [09:42] Launchpad bug 201462 in gksu "nautilus-gksu stopped working in hardy" [Undecided,Confirmed] https://launchpad.net/bugs/201462 [09:42] Launchpad bug 186938 in nautilus-wallpaper "nautilus-wallpaper not working in hardy heron after update to nautilus-2.21.6" [Undecided,Confirmed] https://launchpad.net/bugs/186938 [09:42] AnAnt, dpkg-source -x *.dsc [09:42] I downloaded them [09:42] ok thaks [09:42] AnAnt, cd resultingdir ; debuild -S [09:42] i should submit a featurefreeeze exception eh? [09:43] hyperair, yup that would be mandatory to provide the info there. i dont know if it's featurefreeze, because it's not a new feature. [09:43] well i dont know for sure [09:43] never filed one myself [09:44] @_@ [09:44] alright [09:44] i haven't either [09:44] what's diffstat? [09:44] i've never heard of it [09:44] dunno [09:44] xtknight: thanks [09:45] hyperair, i think this is what you want https://wiki.ubuntu.com/FreezeExceptionProcess#head-4bba384c89c09d141f4e2cc06816d0405593db5c [09:45] you basically edit the bug's description with the info requested there [09:47] thanks [09:52] hyperair, the only thing is, what you posted on those bugs were not debdiffs, not sure what they are [09:53] whooooops? [09:53] i did debdiff somedeb someotherdeb > bla.debdiff [09:53] it isn't? [09:53] ah you have to use the dsc files [09:53] debdiff somedeb-ubuntu0.dsc somedeb-ubuntu1.dsc > bla.debdiff [09:53] when i did that it complained that it wanted debs [09:53] >< [09:53] you already got it on your ppa so you should have all you need [09:54] eh? [09:54] yeah i have both dscs on my comp [09:54] i mean all you need to generate the debdiffs [09:54] it says... [09:54] debdiff: fatal error at line 262: [09:54] Need exactly two deb files or changes files to compare [09:55] uhhh dunno. make a new folder like orig, download original dsc to there and then do it [09:55] anyone remember the command that'll download the whole source package including .orig.tar.gz & diff.gz & .dsc just by pointing it at the .dsc? [09:56] apt-get source ? [09:56] doesnt seem possible [09:57] nevermind i think i managed it [09:57] =D [09:58] well it's 5am here... sweet dreams [09:58] :o [09:58] lifeless, nope :(. i ment the one that'll pull the source package from "*something* https://launchpad.net/ubuntu/hardy/+source/libvisual-plugins/0.4.0.dfsg.1-2/+files/libvisual-plugins_0.4.0.dfsg.1-2.dsc" [09:59] gdnight then xtknight. thanks for the help [09:59] i know apt-get source libvisual-plugins would work in this case, but if i was pulling from debian or an older version of ubuntu. [10:16] i don't think it's very hard to just download three packages [10:16] =\ [10:16] i mean three files [10:16] orig.tar.gz, diff.gz, and dsc [10:16] just three [10:31] hyperair, when you're downloading 30 or so, cause you're doing something big. then it's important. it's a shame i can't remember what the command for that tool is. [10:31] i remember reading something like that recently [10:31] hmmmm [10:32] try searching in the ubuntu packaging guide [10:33] somewhere in ubuntu wiki [10:33] could be there [10:35] hyperair, ah. yes it was in there. thanks. [10:35] dget [10:35] the program is dget [10:37] they've really modernised the packaging guide since i last saw it. nice. [10:37] hahah [10:37] that's true [10:37] say, have you filed a featurefreeze exception request before? [10:37] i'm not very sure how [10:37] =\ [10:38] should i modify an existing bug to add the required info, or should i file a new bug? [10:50] motu-release guys, is it OK to upload bug 194190? FFe granted already. [10:50] Launchpad bug 194190 in cacti "Please sync cacti 0.8.7b-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/194190 [10:53] Please please please sync it. Though I'm not motu-release. [11:03] heya [11:03] Fujitsu, that would be a merge, though, but I guess we want it in since it has several fixes, especially security-related. [11:04] (and an annoying bug during postinst) [11:04] Yep. [11:04] Better to fix them before release than after. [11:04] Yes, it would be a SRU candidate too [11:04] so, let's fix here :) [11:04] SRU+security == ewww === Lure_ is now known as Lure === Lure is now known as Lure_ === Lure_ is now known as Lure [12:38] hi, i need help creating a deb file from source [12:53] TheMuso: retroactive ack for bip, thanks. === harrisony__ is now known as harrisony [14:24] DktrKranz: buon giorno :) [14:24] heya sebner! :) [14:25] How do I sign my source? [14:26] i create a new package using dpkg-buildpackage -S -sa -rfakeroot [14:26] slangasek: hah, I got some 4suite people to fix the goog-cal plugin to work with python-4suite-xml [14:27] elmargol: then dpkg-buildpackage should sign it (or at least try to), but you can also use debsign on the _source.changes file [14:29] Oh the problem is somewhere else.. somehow the result files of pbuilder arent signed anymore :( [14:30] + the source is not in my results folder [14:30] sigh. people using Debian's sysv-rc 2.86.ds1-5x and expecting things to work in Ubuntu. [14:33] DktrKranz: willing to review something? *once again* ^^ [14:34] sebner, if you have ACK from motu-release, sure [14:34] DktrKranz: I have :) [14:34] someone knows why I dont hate a orig.tar.gz gile in my results folder? [14:34] DktrKranz: debdiff is really small though ^^ bug #216277 [14:35] sebner, ok, point me to some bug numbers, I need do so some housekeeping, but I'll look at them later [14:35] damn ubotu [14:35] DktrKranz: thx :) [14:35] DktrKranz: https://bugs.edge.launchpad.net/ubuntu/+source/python-numpy/+bug/216277 [14:35] Launchpad bug 216277 in python-numpy "missing parentheses in /usr/share/pyshared/numpy/f2py/rules.py" [Undecided,New] [14:35] ubotu: good boy :) [14:35] Sorry, I don't know anything about good boy :) - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [14:35] xD [14:36] is a bad boy, then [14:36] boy, or bot, it depends [14:36] DktrKranz: nvm. I like (crazy) bots :D [15:36] Hobbsee: what info are needed to get an ACK for a sync request right now? [16:19] I have a package on my ppa wich depends a package on my ppa... dow do I include this? [16:20] elmargol: ppa questions in #launchpad [16:20] it's not on topic for here [16:20] thx [16:21] elmargol: I don't think you have to do anything [16:25] During the final freeze how many motu-release acks do I need before I subscribe u-u-s? [16:26] protonchris: still 2 acks [16:26] mok0_: thanks. [16:27] morning all [16:29] Hey LaserJock [16:30] Hey LaserJock [16:41] siretart: please take a look at my debdiff for bug #176332 [16:41] Launchpad bug 176332 in amarok "amarok does not work with pulseaudio [hardy]" [Critical,Confirmed] https://launchpad.net/bugs/176332 [16:41] would someone have time to sponsor the compizconfig-settings-manager which got broken for Finnish as the 0.7.4 got uploaded? bug 216211 - .dsc from my PPA and debdiff attached [16:41] Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211 [16:42] it does nothing besides fixing the PO/fi.po file [16:47] Mirv: you need to get 2 acks from motu-release first [16:48] mok0_: 1 [16:48] just one ack. I'm pretty we enacted that change way back in the first MC. [16:48] pretty sure, even [16:49] ScottK (or someone from motu-release), is it OK to proceed with bug 194190? [16:49] Launchpad bug 194190 in cacti "Please sync cacti 0.8.7b-1 (universe) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/194190 [16:51] anyone from ubuntu-desktop available for ACKing bug 215714 ? [16:51] Launchpad bug 215714 in nautilus-python "The path for python extensions should be reflect the 2.0 api" [Medium,Confirmed] https://launchpad.net/bugs/215714 [17:06] apachelogger: that one is a dupe of a xine-lib bug. test package is available, up to now only one tester has reported back [17:07] siretart: is the test package in the archives? [17:07] apachelogger: in the motumedia PPA [17:08] siretart: gonna test it [17:08] thanks [17:08] but if you used the same patch it should work without problems ;-) [17:09] I'm currently on a local lug event, I'll look a bit later at it === _Czessi is now known as Czessi [17:09] siretart: k [17:14] which command reads debian/manpages, dh_installman or dh_installmanpages? [17:15] dh_installman is the one you want [17:15] reall man dh_installmanpages [17:15] *read [17:23] LaserJock: thanks [17:33] mok0_: ok. [17:34] mok0_: oh, actually I thought on some motu-release mailing list, but there's no such. so where exactly I should get the ack from? [17:35] just here asking from some in the motu release team to put some "ack" in the bug report? [17:37] (a post says either file a bug report (already done) or ask on irc...) [17:37] Mirv: did you subscribe the team to the bug report? [17:37] pochu: yep. [17:37] bug 216211 [17:38] Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211 [17:38] that should be enough then... you could also ask someone here, although I don't promise you they'll be around ;) [17:39] ok, I'll wait until Mon or Tue. hopefully people have time to handle these (everyone's quite busy anyway, whether paid of volunteer..) [17:43] another stupid question.. does using $(CURDIR) or not using it make any difference (ie, might it FTBFS somewhere without it)? [17:44] not sure about a FTBFS [17:44] actually, yeah it could do that [17:45] if it was trying to cp or something a file that no long exists where it thinks it does === Zic_ is now known as Zic [17:47] I'm trying to build this package wich recentrly switched from configure to autogen.sh [17:47] do I need to change control file? [17:47] how? [17:48] LaserJock: ok, thanks again [17:48] zasf: usually autogen.sh just creates a .configure [17:49] hem.. you see, I'm not that expert [17:49] pbuilder complains that [17:49] chmod: cannot access `/tmp/buildd/gnome-applets-2.23.0/./configure': No such file or directory [17:50] yeah, because autogen.sh has to be run to create it [17:50] often times that's done before an official release [17:51] ah, so does it mean I have to run autogen in my source dir before debuild? [17:51] Hi folks! what could be the reason for configure to run twice? any general reason possible or is it case to case? [18:00] LaserJock: I added a 'DEB_CONFIGURE_SCRIPT := $(CURDIR)/$(DEB_SRCDIR)/autogen.sh' to debian/rules.. let's see [18:04] if a package needs tar, should it depend on it or is it supposed to be always installed? [18:04] or rather, is ubuntu-minimal always installed? [18:05] Essential: yes [18:06] tar can not be removed without apt having a major hissy fit [18:07] ah, right. thanks [18:14] (lintian) W: packjam: new-package-should-close-itp-bug [18:14] should this be patched to look for LP instead of Closes? [18:19] perhaps it should be changed in Debian so that if it has 'ubuntu' in the version string, it looks for LP instead of Closes [18:19] pochu: do you know if they have accepted any change like that before? [18:19] sure [18:19] they have merged our entire diff [18:19] I'm pretty sure they've taken a lot of our checks [18:20] ok, great [18:26] uhm.. it already does :). I'm just stupid xD [18:28] RainCT: what was the issue then? did you have -1? [18:28] yeh :P [18:29] for some reason I *always* forget to check the version number, also when reviewing :P [18:30] tsk tsk [18:30] I always forget to add the Closes LP: part [18:36] what woud be the most sane way to pass to a postinst that we are upgrading from an old version? [18:36] i can't think of anything beyond touching something in /tmp in the preinst [18:41] superm1: if [ "$1" = install ] || [ "$1" = upgrade ]; then [18:41] ... [18:41] (or ony upgrade, if you don't need it for a new installation) [18:41] s/ony/only/ [18:42] superm1: look at the gstreamer0.10's postinsts [18:43] and you can also compare the version from which the upgrade happens (iirc it's in $2) [18:51] pochu, i didn't think upgrade was passed in the postinst [18:51] only in the preinst [18:51] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html [18:51] as per that [18:51] postinst passes a configure === evalles_ is now known as keffie_jayx [18:53] superm1: yes, postinst gets passed configure and the old version (if applicable) [18:53] superm1: http://women.debian.org/wiki/English/MaintainerScripts has some nice graphs [18:54] "postinst configure most-recently-configured-version", i dont see any calls with the old version [18:54] its the new version that it is called with [18:55] oh wait, i think i see what you mean [18:55] in that graph now [18:55] most recently configured version means old version [18:56] yes [18:58] thanks geser and pochu [19:00] azeem: yay :) package for me to sync/merge? [19:04] superm1: err, then the gstreamer0.10 stuff is useless? [19:04] well if you are doing it just like that, then it wouldn't do much from what i see in debian policy and that debian women page [19:04] slomo_: ^^ [19:05] pochu, you still do get the old version installed in $2, but $1 needs to be configure then [19:06] phew! [19:06] emilio@saturno:~/deb/gstreamer/gstreamer0.10-0.10.18/debian$ ls *inst [19:06] gstreamer0.10-doc.preinst gstreamer0.10-tools.preinst gstreamer-tools.preinst libgstreamer0.10-0-dbg.preinst libgstreamer0.10-dev.preinst [19:07] slomo_: false alarm, those are preinst so we are safe :) [19:07] gstreamer0.10 has only preinst no postinst [19:07] ah okay :) [19:07] debian/changelog was confusing though :) [19:08] but it didn't make sense to remove directories in postinst [19:09] it really sucks though when you make a bad choice in a convention of where to name files, and then have to deal with it in new versions via postinst/postrm [19:10] superm1: conffiles? [19:11] pochu, no it's for a theme. i didn't realize that when we "changed" the theme, it can cause crashes due to a dated cache [19:11] so the new theme is in its own directory and the old one in its own directory [19:11] but for folks upgrading need a symlink in place [19:11] so that they can use the old one by the same name [19:17] superm1: looks like my change to the backports-modules regexp still had a thinko, fixing now - so the /next/ DVD should really be fixed ;) [19:17] hehe [19:49] pochu: are you there? [19:50] azeem: w00t, google-calendar synced [19:50] slangasek: with evolution? === blueyed_ is now known as blueyed [19:57] stani: I mean that the plugin package has been synced from Debian...:) [19:57] ok, I just got in so missed the context [20:05] I had a question about a particular package and what happens when it's put into the repo. The app has a bug or two that manifests itself when installing from the application's site. But, they don't in the repo version. Would this be the appropriate channel? [20:41] aloha afflux :) [20:42] heya sebner :) [20:42] RB2: what's the package? [21:23] azeem: are the various 'multisync' packages obsolete? [21:24] azeem: for that matter, have you ever used multisync0.90? built on libopensync0, but doesn't appear to see python-based plugins :) [21:24] slangasek: I'm uploading the last (hopefully) ubuntu-docs now [21:25] if that's ok with you, that is ;-) [21:25] LaserJock: go for it :) [21:28] azeem: well, or at least it doesn't see the moto plugin. Kinda hard to say where the problem is yet [21:29] slangasek, we caught a really bad bug on a theme last night that causes mythfrontend and mythbackend to crash during upgrade scenarios. i uploaded a workaround for those upgrade scenarios when you touch all that frozen stuff again [21:30] superm1: that's mythtv-theme-mythbuntu? [21:31] yeah [21:31] accepted [21:31] thanks [21:52] LaserJock, sorry was afk. The package is nexuiz [21:55] RB2: well, we get our package from Debian [21:56] RB2: there are a couple of patches that debian applies to nexuiz [21:58] LaserJock, thanks! Is there someplace that I can take a look at what patches they apply? The new nexuiz releases take a very long time to get into the repos, so I wanted to see if I could make it work correctly. [22:00] RB2: yeah, have a look at http://packages.qa.debian.org/n/nexuiz.html . Down on the lower left are the source package files [22:01] LaserJock, thanks again! [22:34] heya [22:37] hi emgent === danielm_ is now known as danielm [22:49] slangasek: hrm yeah, multisync0.90 should work in theory [22:51] azeem: ok. neither multisync0.90 nor kitchensync seem to like the moto plugin much :) [22:51] but perhaps we're off-topic, since that one didn't manage to get synced for hardy. :) [22:51] slangasek: you need both python-opensync *and* opensync-module-python for that to work [22:52] and they're both installed [22:52] hrm, right [22:52] well, I see it when I run multisync0.90 on unstable [22:52] I don't have my hardy install around currently [22:52] fun [23:00] slangasek: you can try exporting OSYNC_TRACE=/foo and then grep the resulting Thread* files for ERROR [23:00] slangasek: msynctool --listplugins doesn't list moto either, I assume? === boomer` is now known as boomer [23:01] azeem: correct [23:02] azeem: hmm, what do you want to bet that it's because I installed the opensync-module-python .deb from sid without rebuilding it against python 2.5? ;) [23:03] ah [23:04] slangasek: can you maybe try with the one from https://launchpad.net/~debian-opensync/+archive ? [23:04] would be good to know those work, at least for the packages which won't make hardy [23:05] checking [23:09] azeem: ah yes, now it shows up ;) [23:10] yay [23:17] is the process for getting a patch in the same in here and in main? [23:18]