=== cody-somerville_ is now known as cody-somerville [00:39] HorizonXP: Masters Of The Universe. [00:40] oh lol [00:41] so i'm trying to recompile PHP5, because apparently the PDO built-in doesn't support PDO_Informix [00:41] install the build-deps, file a bug if it won't build, assuming you haven't seriously messed up your compilation environment [00:42] well, compiling works so far, but I can't seem to get rid of PDO. i need the right configure options. I did the following command: [00:42] DEB_BUILD_OPTIONS="--with-mysql --with-apxs2=/usr/bin/apxs2 --with-curl --with-xsl --disable-pdo --without-sqlite" fakeroot debian/rules binary [00:42] does that replace the configure options in debian/rules, or just append to them? [00:42] You're misunderstanding what DEB_BUILD_OPTIONS is for. [00:43] Neither. DEB_BUILD_OPTIONS is a list of things like 'noopt', 'nostrip', 'parallel=3', etc. [00:43] oh. [00:44] You want to fiddle with debian/rules. If it's using debhelper the ./configure call will be obivous. If it's using CDBS, you need to work out the black magics. [00:44] you want DEB_CONFIGURE_EXTRA_FLAGS [00:44] Have a goat handy. [00:44] (for CDBS) [00:46] so it's apparently debhelper [00:46] that should be easier === RAOF__ is now known as RAOF [00:56] keep the goat, just in case [00:56] well, i haven't eaten at all today [00:56] so gonna have dinner and get back to it. be back later [00:58] goat curry! [00:59] * HorizonXP mouth waters [01:00] not today. it's chicken curry actually (no joke) [01:06] curry is a wonderful idea [01:36] hi all [01:37] i wanna know if someone here use firestarter [01:37] or [01:37] gksu [01:37] if someone use firestarter, is it for an administrator or for a user with sudoers habilities [01:38] ? [01:40] can someone answer? [01:43] anakron: there's really no difference between the former and the latter [01:44] its a little different [01:44] one is root [01:44] the other can be like root if root give him privilieges [01:45] anakron: in either case, euid == 0 [01:45] :) [01:45] ok ok [01:45] im asking because in firestarter.desktop [01:45] its added in Exec [01:45] gksu -X -c firestarter [01:45] but gksu does not have this options [01:46] and i was asking if it correct to change it to : gksu -S firestarter [01:46] and then it will run asking users(included in sudoers file) pass [01:46] :) that was [01:50] i would hope that passing -S is unnecessary [01:50] mm [01:50] is there documentation of firestarter behaving in a broken manner if one backend is used vice another? [01:51] in that case is better to use gksudo [01:51] mm [01:51] ok [01:51] one question [01:51] gksu by itself should do the right thing based on the gconf key [01:51] nono [01:51] ok [01:51] thanks [01:52] hey, if im interested in mentoring [01:52] asking for [01:52] i must sent an email to [01:53] i must sent an email to [01:53] motu-mentoring-reception@reponses.net [01:53] correct [01:53] :-) ok thanks [01:54] yw [01:58] one more [01:58] ok back, so i'm trying to reconfigure the PHP5 package so that it doesn't compile PDO support into PHP directly, so I can use the PECL modules. [01:59] what i can do if a patch is applied to my source package and i can't apply my change [01:59] in debian/rules, i see a bunch of CFLAGS that seem to set those options. is there not a way to just override those configure options? [01:59] anakron: meaning conflicting patches? it's normally best to use upstream's patch [for maintenance rationale] [02:00] anakron: if you don't mean conflicting patches but just fuzz changes, you can normally rediff your change/patch [02:00] mm [02:00] editing the patch? [02:01] making a debdiff of the changes that ill apply to the patch? [02:02] you certainly could edit the patch directly using a variety of utilities in the patchutils package [02:02] ok [02:02] if the source package has a patching system (e.g., cdbs, quilt), use that instead [02:02] how i can know it [02:03] look at debian/control:^Build-Depends [02:03] you may also need to look at debian/rules [02:03] dpatch [02:04] dpatch in both [02:04] mm so i must use dpatch-edit-patch [02:05] the problem was that th old desktop file use "su-to-root" with -X -c [02:05] but when the patch owner change it , he does not take out -X -c [02:05] and gksu does not have any option like these [02:08] normally that can be migrated directly to gksu (without any options) [02:08] yes [02:08] how can i do it [02:09] is there any particular reason why you're dropping su-to-root? are you trying to remove menu as a dependency? [02:09] now it says, after i do "dpatch-edit-patch 21-gksu.patch [02:09] no [02:09] it was done [02:09] im taking out "-X -c" [02:10] ok [02:10] after doing dpatch appears [02:10] Now launching an interactive shell in your work directory. Edit your files... [02:10] can you explain it please? [02:11] i need to know "HOW" [02:11] just modify the desktop file, then exit 0 [02:11] you might want to take a lok at dpatch-edit-patch(1) [02:14] but editing the desktop file [02:14] it will change the patch? [02:15] ok thanks! [02:15] thanks for your patience [02:33] hi [02:33] what does W: specto source: debhelper-but-no-misc-depends mean? [02:33] It means the package uses debhelper but doesn't have a depends on ${misc:Depends} [02:35] so I should add ${misc:Depends} then? [02:35] Yep [02:35] on build depends, am I right? [02:36] No, in the binary package, Depends: Should be next to ${shlib:Depends} if it uses it. [02:37] it's a python program, so I guess it doesn't use it [02:37] Ah, but it uses ${python:Depends}, right? [02:37] yep [02:37] Just add it after that :) [02:38] Depends: ${misc:Depends}, ${python:Depends}, python-gtk2, python-glade2, .... [02:38] ok? [02:38] I would normally ${python:Depends}, ${misc:Depends} but it shouldn't matter. [02:38] I wanted to keep all the python things together (there are more python- packages) [02:41] also, there is dpkg-source: aviso: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field [02:41] the version is -0ubuntu2~ppa1, iirc this indicates there's no debian package for it, so why does it complain? [02:44] I don't think it can differentiate, but I'm not sure about that one. [02:44] it's harmless then [02:55] hey guys, so i'm trying to recompile PHP5. I'm trying to get PDO_Informix to install, and I figured out that I can just compile it as an extension directly. but how do I get configure to pick it up? my documentation is saying to use buildconf --force [04:40] ScottK, sorry for the late answer (if you are still there). I spli the pacakge this way to avoid lintian warning with both packages (no man page in DVDStyler of desktop command not found, ...) [04:42] fabrice_sp: OK. Reasonable enough. [04:43] fabrice_sp: Since dvdstyler depends on the data package it would have been OK, but not a big deal. [04:45] ScottK, you're right. At first, I put recommend instead of depends, but dvdstyler alone was hardly usable (a lot of errors). I just wanted to have a really clean package(from a lintian stand point :-) At the end, the package size has been divided by 2 [04:46] Good enough. [04:47] The most correct way to do it would have been to move all the arch all data to the -data package and add lintian overrides, but I think it's not a big deal. [04:50] you mean non-arch to data, right? This was the first thing I did (usr/bin from in dvdstyler and usr/share in dvdstyler-data) [04:53] ScottK, I'm changing the package to put usr/bin in dvdstyler and usr/share in dvdstyler-data, and I'll upload again in few minutes (and will have to re-ask mok0 for his advocate :-) ) [04:54] OK. [04:54] Add the lintian overrides too then. [04:54] fabrice_sp: Please test build before you upload. [04:55] yes. I didn't thought about the overrides (and I also always do a sbuild before uploading. That's why I will last a bit :-) ) [04:55] OK. If I'm not still up when you're done I'll advocate it tomorrow. [04:55] ok. Thanks [05:07] ScottK, as I move .desktop file and icon to dvdstyler-data, I should call dh_icons in binary-indep, right? [05:08] Yes. I think that's right. [05:08] ok. === fabrice_sp_ is now known as fabrice_sp [06:30] good morning [06:31] Good morning dholbach [06:31] hiya fabrice_sp! [06:31] After I upload a package to revu, and add a link to it to the bug (tagged with needs-packaging), do I need to do anything else to notify someone that it's ready (email a list) or do MOTU folks just queue through the needs-packaging bugs? [06:35] btm, reviewers go through REVU, in the "Needs review" view. As you can see, there is quite a lot of packages there already, so the better your package is, the quicker it will be [06:38] fabrice_sp: do I need to do anything in revu to flag a package so it shows up in 'needs review'? [06:38] btm, no. Just upload it to revu. [06:40] When I set the maintainer field to motu and moved my name to XSBC-Original-Maintainer in control, revu started throwing lintian errors about this being an NMU. Is this normal? [06:41] btm, it's because your version number is not correct [06:46] Got it. When I set distribution to jaunty in changelog I get 'bad-ubuntu-distribution-in-changes-file [06:51] set distribution to my current distribution (intrepid) and that lintian error went away. [06:59] btm: Change it back to jaunty and ignore that error. [07:00] iulian: gotcha [07:05] revu gives an automatic comment of (legal), clicking on it shows a few files marked UNKNOWN, one with a copyright line. In the file it's clearly marked GPL though. Do I need to resolve these? [07:08] btm, if you are sure that all the source files have a copyright header, it's ok [07:17] fabrice_sp: not all of the source files have a reference to the license, but they have a copyright header. The readme has matching copyright with license information. Is that acceptable? [07:45] morning [07:49] Good morning didrocks, DktrKranz. [07:50] hello iulian [07:50] morning. [07:51] morning [07:51] morning iulian :) [07:54] Hey. If there are any MOTUs around and available, could they review my packages at REVU? One is osm-gps-map, which is a GTK widget for embedding openstreetmap. And the other is pyofa, which creates audio fingerprints for files. http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :-) === BugMaN1 is now known as BugMaN [10:12] DktrKranz: Hey, here's a list of the syncs we still need to do and what they wait on: http://pastebin.com/fe76d603 [10:13] dholbach: I don't see that ftbfs on washngo with an amd64 sbuild chroot :( [10:13] Laney: let me try again [10:14] However at that file it did hang for a long time, but eventually got going [10:14] maybe it's a pbuilder/sbuild thing [10:20] Hi Laney, I didn't look at rebuilds (girlfriend wanted priority...), I'll have a look this evening. For syncs, they can be processed as usual because DEPWAIT are handled automatically, for hdbc-*, they need to be processed at a later stage when hdbc is published. [10:27] Laney: now it got past that point - give me the bug number and I'll ACK it once it proceeded fully [10:30] DktrKranz: I didn't check how tight he made the build-deps actually [10:31] but slangasek has already processed them [10:32] I see [10:32] dholbach: bug #321249 [10:32] Launchpad bug 321249 in washngo "Please sync washngo 2.12-6 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/321249 [10:32] so they could be synced straight [10:33] they can now [10:33] Laney: build succeeded - perfect :) [10:33] Laney: no idea what happened before [10:34] I always do a test build ;) [10:35] Laney: I wasn't saying that you weren't - you're definitely a good guy :-) [10:35] * dholbach hugs Laney === asac_ is now known as asac [10:37] \o/ [10:38] DktrKranz: thanks for the uw-imap work [10:43] james_w: just three rebuilds, no problem :) [11:06] Hello [11:07] Anyone to check my package attempt to hexdiff ? [11:07] on revu, of course [11:10] * tuxmaniac is looking for one more advocate for his package gresisotr on REVU. If someone can have a look at it it will be nice! Thanks in advance. [12:17] san nin faai lok to all our chinese friends out there === Kmos_ is now known as Kmos [13:04] tuxmaniac: looking at gresistor now [13:04] tuxmaniac: the email address in changelog is invalid [13:16] tuxmaniac, n/m, fixed & uploaded [13:20] mok0: thanks :-) [13:21] tuxmaniac: should appear in the new queue shortly [13:21] tuxmaniac: nice app [13:22] What's the method for removing a patch in debian/patches from a package that uses quilt - just delete the patch and the reference to it in debian/patches/series? [13:22] that'll work [13:22] and no need to modify the rules files? [13:22] loic-m: actually, just remove the series entry [13:22] james_w, mok0 thanks a lot [13:23] If it's the only patch, is it better to delete the debian/patches repository? [13:24] loic-m: heh, good question. I find it convenient with a patch system in place in case I want to fix something [13:24] mok0: actually you answered - delete the series entry and leave the patch thx [13:25] the rules files has unpatch in the clean target - is it safe to leave, or better removed? [13:25] loic-m: just leave it [13:25] loic-m: it will discover there's nothing to do [13:25] thanks mok0 === LucidFox_ is now known as LucidFox [13:52] If I update from upstream a package that's usually synced from Debian, do I keep Standards-Version: 3.7.2 or do they use a newer one now (like 3.7.3)? [13:53] RAOF: you can sync banshee now i guess... and probably also taglib-sharp :) [13:56] Anyone to check my package attempt to hexdiff on REVU ? [14:00] loic-m: leave it like the debian version [14:09] !longdesc [14:09] The long description should provide all the information needed to let the user decide whether to install the package. See http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-desc for Best Practices. [14:09] excellent [14:14] !synopsis [14:14] synopsis is The synopsis line (the short description) should be concise. See http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis for Best Practices. [14:15] Anybody in for a review please consider http://revu.ubuntuwire.com/details.py?package=sabnzbdplus (popular binary newsreader, written in python) [14:21] jcfp: You've been working on that for some time ;-) [14:26] jcfp: Does it use that embedded copy of cherrypy? [14:26] mok0: unfortunately :/ people apparently don't fancy reviewing python packages, and thing like newly created libjs-* packages also create delays... [14:26] Laney: no. [14:26] excellent [14:26] jcfp: I will take a look shortly [14:26] mok0: tia [14:43] jcfp: I heard that there's a secret place where people are reviewing Python related packages, few guys here know a magic spell that opens a channel with lots of people who can review your package if you follow some strange rules ;-) [14:44] ScottK, pochu, RainCT: ^^ [14:44] POX: i'm not harry potter but do eloborate :) [14:45] jcfp: +1 [14:45] jcfp: If you're interested in getting your package into Debian and syncing it into Ubuntu from there, you can join #debian-python on OFTC. [14:46] jcfp: https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam [14:47] ScottK: would that be faster? or is there alot of extra work in getting debian to accept too [14:47] mok0: :) [14:47] It wouldn't necessarily be faster, but there's more Python specific expertise. [14:48] Also If POX uploads it to Debian, I'm generally going to make some assumptions about package quality. [14:48] So working in parallel can make it faster. [14:50] so what would be best - trying via revu and directly to debian at the same time? [14:52] jcfp: you'll be waiting forever finding a Debian sponsor, so why not? [14:53] mok0: is it that bad :/ [14:53] Doing it in a team is usually easier [14:53] than e.g. through mentors [14:56] If any reviewers or MOTUs are available, could you please take a look at http://revu.ubuntuwire.com/details.py?package=grnotify ? [14:58] mok0: Not in the Python team. There it's very easy to get sponsored. That's part of what POX was hinting at. [14:58] ScottK, that's good to know [14:59] Piratenaapje: are you in contact with upstream? [14:59] mok0: I am upstream [15:00] Piratenaapje: ah, then I can really have a go at you ;-) [15:00] mok0: That doesn't sound too good :p [15:00] mok0: Factoids added to ubottu database. [15:00] Piratenaapje: just trivial stuff, not hard === a|wen- is now known as a|wen [15:07] Piratenaapje: sorry for not replying to the changes you made. Thanks for that. [15:07] tuxmaniac: That's ok, thank you for reviewing :). [15:12] Hi all. I've fixed all the problems people identified in my packages on REVU. Are there any MOTUs available to review my packages? http://revu.ubuntuwire.com/details.py?package=osm-gps-map http://revu.ubuntuwire.com/details.py?package=pyofa - Thanks :) [15:13] Piratenaapje: I think the right way for closing an LP bug is (LP: #308285 [15:13] * (LP: #308285) [15:14] I might be wrong though :) [15:15] savvas: No, that's fine. [15:16] my bad then [15:16] mok0: thanks for reviewing, I'll try to fix everything later today [15:16] Does Debian accept Standards-Version: 3.8.0 ? I was under the impression it was still 3.7.X, but some packages in Debian have 3.8.0 [15:17] 3.8.0.1 is the current standards version in Debian. [15:17] loic-m: Yes, it does, it's the lastest Debian policy version. [15:18] jpds, ScottK thanks [15:18] packages qa show that as well: http://packages.qa.debian.org/f/flumotion.html [15:18] "The package should be updated to follow the last version of Debian Policy (Standards-Version 3.8.0 instead of 3.7.2)." [15:19] Heya gang [15:19] savvas, thx, when I googled it I didn't find references to the number [15:19] Heha bddebian. [15:19] Heya ScottK [15:20] glad to help out :) [15:20] loic-m: Try rmadison -u debian debian-policy [15:22] * POX think it would be weird if Ubuntu would provide its own version of debian-policy (and thus have its own Standards-Version) [15:22] ScottK: I've noticed that, but why don't they use 3.8.0.1 in the Standards-Version? [15:22] +s [15:23] POX: ubuntu-policy | 3.8.0.1ubuntu4 | jaunty/universe | source, all [15:23] POX: There is a package with ubuntu-policy :P [15:23] oh, so you have your own Standards-Version? /me didn't know that [15:23] savvas: The 4th digit doesn't change policy, it's about the package. [15:23] It's a recent development. [15:24] ah, ok [15:24] You can diff debian-policy and ubuntu-policy and see where the distro policies are different. [15:29] ScottK: is it possible to tell which policy is the package following after looking at Standards-Version? [15:29] No. We don't put the Ubuntu revision in debian/control. [15:30] We just started having a separate policy document recently and so we're trying to figure out what to do with it. [15:31] In fact we have a policy of not changing the policy version in packages we get from Debian as it needlessly clutters the diff. [15:32] * POX suggests to add something to the version that will allow him to detect that this package is not following the Debian policy [15:32] ScottK thanks, I was on another screen. rmadison works well [15:32] u.3.8.0 or 3.8.0-u or 1:3.8.0 or something like this [15:33] ScottK: could you please check my changelog entry at http://paste.ubuntu.com/109839/ ? [15:33] and XSBC-Original-Standards-Version ? :P hehe [15:34] loic-m: Don't bump standards version and don't mention the maintainer change in debian/changelog. [15:34] loic-m: Also 'should be solved' sounds a bit weak. Either it is or it isn't. [15:35] ScottK: I don't have Intel hw to check [15:35] The code isn't there to be patched anymore in the first place [15:39] OK. Then say patch dropped, code changed upstream. [15:39] Don't make a statement about is the bug fixed. [15:40] ScottK: can you tell me how you saw that so I know? [15:40] Make it sound a little better than that though. [15:40] ScottK: or did you also chack the Debian bug report? [15:40] Saw which? The patch thing just from reading your changelog [15:41] No, how did you find "Then say patch dropped, code changed upstream." ? [15:41] The Debian bug comments sin't that assertive [15:41] Because you told me the code had changed upstream and it wasn't there to be patched. [15:42] Ok. [15:42] http://paste.ubuntu.com/109843/ is that ok now? [15:44] I think that's find. [15:44] find/fine [15:44] ScottK: thanks [15:44] no problem. [15:45] Now I'd like to fix the debian/watch but there's something I don't get [15:45] http://sf.net/desmume/desmume-(.*)\.tar\.gz downloads desmume-0.9-mac.tar.gz [15:46] How do I make sure it downloads desmume-0.9.tar.gz ? [15:47] AFAIU, (.*) should only pick the version numbers, shouldn't it? [15:49] loic-m, see http://wiki.debian.org/DEHS | grep dversionmangle [15:51] arf, i misunderstood your question [15:51] try (\d+\.\d+) instead of (.*) [15:53] My package was just rejected, and I don't really get why. It says: Details follow: * grnotify_1.0.2_source.changes:Changed-By: Kristof Bamps [15:53] [15:53] Piratenaapje: That would be my email. [15:53] cosmicray versions his packages weirdly: http://packages.debian.org/changelogs/pool/main/m/missingh/current/changelog [15:53] jpds: Could you explain why it was rejected? I didn't think the mail was too clear [15:54] Piratenaapje: Please see the buttom of the email for steps on how to fix it. [15:55] jpds: Oh, I thought my key actually was on lp, thanks [15:55] jpds: But how did the package got filed under my name if I didn't correctly set my key? [15:56] Piratenaapje: The name is set in debian/changelog. [15:57] Piratenaapje: The package uploads are checked against the keyring and if it can't find your key, just pops your package into rejected/. [15:57] jpds: Ok thanks, I'll have to look into what I did wrong :s [15:57] petski: it works perfect. What man / doc should I look for if I want to learn about the operators like +d without having to learn a programming language? [15:57] hi! w-scan needs a review -> http://revu.ubuntuwire.com/details.py?package=w-scan [15:58] quadrispro: There's an error in macchanger-gtk (1.0-1ubuntu1) [universe] package in jaunty - In debian/control it says "XSBC-Orginal-Maintainer", whereas it should be "XSBC-Original-Maintainer" [15:58] and do I need to mention the change in the watch file in the changelog? [15:58] Piratenaapje: Adding your key to LP and logging into REVU ought to fix everything. [15:58] hi savvas, thank you, I work on it now [15:58] np :) [16:01] Piratenaapje: I'm off for now, but feel free to reply to the email when you're done. [16:01] The key DF191D95B44054ABA32283735B401CF3BC8C303C has already been imported. [16:02] hyperair: I fixed codelite for you [16:02] Piratenaapje: OK; it's in the revu keyring, let me move the upload back to he processing queue. [16:02] jpds: But I didn't do anything :s [16:02] mok0: eh? you did? and reuploaded? [16:03] mok0: got a debdiff? [16:03] Piratenaapje: Hmm, odd, it's in the keyring [16:03] hyperair: I can make one [16:03] mok0: thanks [16:03] hyperair: there were still some COFF binaries [16:03] mok0: yeah i noticed. *.exp [16:03] Piratenaapje: Date: Wed, 14 Jan 2009 16:01:00 +0100 - maybe you added the key recently? [16:03] hyperair: I removed the sqlite3 tree and added it to the build-depends instead [16:03] mok0: did you change debian/rules? [16:03] no [16:03] ah [16:03] removed the sqlite3 tree eh [16:04] hyperair: it was under wxsqlite3 [16:04] hyperair: I hope it works now lol [16:04] mok0: have you tested whether it'll build? [16:04] savvas: bug 321504 :) [16:04] Launchpad bug 321504 in macchanger-gtk "Little typo in debian/control" [Undecided,New] https://launchpad.net/bugs/321504 [16:05] hyperair: it builds fine [16:05] bah, total system freeze :/ [16:05] mok0: okay then [16:05] hyperair: I'll have to bump the release to make a debdiff [16:05] Piratenaapje: Hmm, it's even on REVU: http://revu.ubuntuwire.com/details.py?package=grnotify - I wonder why it got rejected. [16:05] mok0: ah nevermind then [16:05] mok0: you didn't touch debian/ right? [16:06] jpds: I don't know either :s [16:06] hyperair: I added libsqlite3-dev to build-deps [16:06] hyperair: I edited changelog [16:06] DktrKranz: bug #321499, bug #321501, bug #321503, bug #321505 for you good sir [16:06] hyperair: I added README.source [16:06] Launchpad bug 321499 in missingh "Please sync missingh 1.0.3.2 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/321499 [16:06] Launchpad bug 321501 in hdbc-odbc "Please sync hdbc-odbc 1.1.6.0.1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/321501 [16:06] Launchpad bug 321503 in hdbc-postgresql "Please sync hdbc-postgresql 1.1.6.0.1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/321503 [16:06] Launchpad bug 321505 in hdbc-sqlite3 "Please sync hdbc-sqlite3 1.1.6.0.1 (universe) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/321505 [16:06] quadrispro: cool, confirmed! [16:06] * jpds raises eyebrown at Laney. [16:06] hyperair: I changed get-orig-source rule [16:06] hyperair: that's it I think [16:07] * Laney lowers them for jpds [16:07] mok0: could you diff just the debian/ folders then? [16:07] jdps: so everything should be ok now? [16:07] mok0: i'd like to reflect the changes on my local bzr tree. [16:07] Piratenaapje: Yep, sorry for the confusion. [16:07] hyperair: yes [16:07] mok0: thanks [16:07] jpds: Ok thanks :) [16:07] hyperair: of course [16:07] hyperair: 2 minutes [16:09] Laney: mind subscribing me to them? [16:11] hyperair: dcc'ing you the patch [16:12] mok0: i'm not very sure if dcc works. could you pastebin it? [16:13] sure [16:13] hyperair: what's your irc client? [16:13] DktrKranz: done [16:13] jdps: will my package stay in the 'needs work' category? [16:13] mok0: smuxi [16:13] hyperair: http://pastebin.com/fe941212 [16:14] mok0: but dcc's failed miserably before, because i'm behind a router [16:14] hyperair: never heard of it [16:14] mok0: it's in the ubuntu repo =) [16:14] hyperair: using pidgin myself [16:14] mok0: it's a little buggy, but it's lightweight and nice [16:14] hyperair: well I have a quad duo so... [16:15] mok0: i used to use pidgin, until a few weeks back. if you leave it on too long (in my case) it starts hanging every 15 minutes or so if the irc backlog gets too long [16:15] mok0: hmph [16:15] hyperair: I've not noticed that [16:16] mok0: it happens if you're using msn [16:16]