=== dmbq is now known as Guest31556 [01:21] guys, i'm really really confused about the get-orig-source target , actually i want to remove some files & dirs, but they get removed ... i still can see the files i want to remove in the get-orig-source dir created during the run of debian/rules http://pastebin.com/d12c75187 [01:22] even if i do a "touch test_file" before the "rm $(RemoveFromSource)" ... i don't have that file in the source dir ! [01:22] that means i canno do any operations [01:22] cannot* [02:19] paissad: You've got "GET-ORIG-SOURCE" where you meant "GET_ORIG_SOURCE" on that rm -rf line. (Hyphen's aren't allowed in Makefile variable names in any case). [02:25] paissad: And I don't think "cd" command there is going to work as you intend either (as placed, it will have no effect at all, actually. I think you're trying to make it apply to the following "rm" command but it won't. If you can figure out how to do what you want without using "cd" at all, that'll be best, but if not, you'll need to cram the "cd" and whatever it should affect into a parenthesized block on one line, somethin [02:31] paissad: The fact that the "cd" has no effect explains your issue with "touch test_file" also... That file does get created, but in the "current" directory, not down in the directory you tried to cd into. [03:06] How do we handle package renames between releases? [03:07] like, let's say autokey is renamed to autokey-gtk. [03:08] binary or source [03:08] myself I don't usually bother with small source renames; I just ignore em :) [03:09] binary packages, same as usual, start building the new binary, add a transitional package, put the right depends:replaces:breaks: in place. [03:09] lifeless: binary. should it be arch all or arch any? [03:09] lfaraone: the transitional package? all of course. [03:10] persia: hey, do we have canned docs for this? [03:10] persia: its muscle memory for me :P [03:15] lifeless: okay, just checking. I apt-get'd the source for qemu-kvm, and I saw that "qemu", in section "metapackages", was arch "any" <_<; [03:15] lifeless: that's why I asked. [03:15] thats...unusual ;) [03:19] lifeless: should autokey-common "Replace:" autokey, since autokey-common contains files previously in autokey? [03:25] lifeless: in Debian autokey is currently qt-based, and I'm going to upload a dummy package which transitions to autokey-qt. Should I divert from that in Ubuntu and transition to -gtk, so that users of Karmic will continue to use the gtk version/ [03:25] *? [03:25] lfaraone: I don't know the answer to that question [03:26] I suggest discussing in ubuntu-desktop if its a main package, or doing what you think best otherwise. [03:26] lifeless: fortunately, it's in Universe :) [03:33] lfaraone: If upstream switched to Qt as their main U/I, then I think that should be what happens by default. [03:33] (unless you have a very good reason to diverge from upstream) [03:33] ScottK: well, upstream still develops the gtk version, and I'm working with them to merge them into one tree. (where none is provided "as default") [03:34] lfaraone: Right, but which is their default/primary? [03:34] lfaraone: well default should be 'current desktop' surely? [03:35] lifeless: yes, of course. [03:36] ScottK: well, currently they ship autokey_VER.tar.gz (qt) and autokey-gtk_VER.tar.gz (gtk), so I guess you might consider qt their default. ideally they want to have them be feature-identical and supported evenly. [03:36] ScottK: the only reason we'd provide a transitional package in Debian is so that current users of testing/unstable continue using the version they've elected to install. [03:37] lfaraone: I guess my view is the "version they've elected to install" is uptream's default. [03:37] * ScottK thinks users in general care a lot less about what toolkit is used to make a program than developers tend to. [03:37] ScottK: I mean so that current users of autokey in Debian (which is qt) will continue to use the version the users installed. [03:38] OK [03:38] ScottK: actually, when I switched autokey in Debian from gtk to qt I had a few people write annoyed bug reports as to why it was pulling in "all these KDE dependencies". [03:39] but hey, they're using testing, so they're not "users in general" :) [03:41] I would say [03:41] that you should go for autokey-qt and autokey-gtk as binary packages [03:41] use autokey as a transitional package to -gtk, if it currently installs gtk binaries [04:12] can anybody review ubuntu-tweak? http://revu.ubuntuwire.com/p/ubuntu-tweak [04:18] persia: ailurus is updated, please check [04:18] http://revu.ubuntuwire.com/p/ailurus === nhandler_ is now known as nhandler [05:55] Anyone advocate/review my package http://revu.ubuntuwire.com/p/iok .. [06:47] I'm on 9.04, and need an up-to-date package for irssi-plugin-xmpp. I'm willing to learn how to do the update, to try to contribute something back. Can someone point me in the right direction please? [06:50] hi [06:51] toabctl: hi [06:52] rlp10: I'm about to go to bed, but the Packaging Guide is at https://wiki.ubuntu.com/PackagingGuide/Complete and is *the* place to start to learn about Ubuntu packaging. [06:53] jmarsden: That's great. Thanks for your help. And, good night too [06:53] You're welcome. BTW this channel will have a lot more people in it once Europe wakes up, in a couple of hours or so... [06:53] So do ask questions in here once you have read the guide and started trying things out. [06:54] jmarsden: Got it; again thanks for your help [06:56] rlp10: You're welcome, and goodnight :) === Myrtti is now known as Guest10773 === Guest10773 is now known as Myrtti [08:10] good morning [08:11] <\sh> moins [08:12] Need advocate/review for my package http://revu.ubuntuwire.com/p/iok [08:28] tseliot: nice nick [08:29] rlp10: thanks [08:32] Hi All, I'm looking for a reviewer for my package (http://revu.ubuntuwire.com/p/arduino). Thanks in advance! === geser_ is now known as geser [09:09] hi guys. I am working on getting new polygraph package (http://revu.ubuntuwire.com/p/polygraph) to Lucid. There was one review of old upload for Karmic. And all comments from it are fixed now. Can someone review it please? [09:32] How can i get deb source v3 in hardy? [09:32] Don't. [09:33] deb source v3 has even in lucid still issues. [09:33] At least the quilt format. [09:33] Oh, wait, no, dpkg in lucid seems to be in sync now. :) [09:34] hardy has too old dpkg to support source v3. [09:34] Rhonda: could you review ailurus now? [09:35] Rhonda: yeah.. I was hoping there are a ppa of backports someone knew of. [09:35] happyaron: Pardon? :) [09:36] Rhonda: could you review "ailurus" package on revu? [09:38] happyaron: I'm no motu so I'm not sure wether my review would be able to help you much - and besides work is requiring its attention too. :) [09:38] oh thanks [09:46] happyaron: Do you have a link for me? Maybe I could squeeze it in and comment on it? [09:51] Rhonda: here you are revu.ubuntuwire.com/p/ailurus [09:58] happyaron: You write License: GPL-2+ but the text doesn't mention "or later". [09:59] happyaron: And given that GPL-2 (without or later) is incompatible with GPL-3 this is a real issue and not distributable. [09:59] .. on the other hand, the GPL-3 part is only an image, so I guess that wouldn't be an issue here. Still, GPL-2+ means "or later" and that option isn't in the text. [10:01] happyaron: Also, for the fedora copyright part you only show the short snippet and say it's gpl-3+, is there more that could be added about that? [10:02] … and actually, I'm not really a fan of cdbs. But that's a personal thing and I'm not sure wether it's discouraged in the ubuntu area? [10:03] Rhonda: okay, thanks [10:07] The other thing I'd do is run it through "lintian -IE --pedantic" and check for its output and fix it if it sounds reasonable. Didn't try to build it. [10:08] many thanks, :) [10:56] <\sh> grmpf how does someone link upstream bugtracker e.g. [10:57] <\sh> http://savannah.nongnu.org/bugs/?28397 to a lp bug report? [10:57] <\sh> without having another distro [10:58] \sh: Link to project instead? [10:59] <\sh> jpds: project: libunwind resolves to DEB packaging libunwind (regarding edge) [10:59] <\sh> I wonder if this is the correct way of doing that ;) [12:02] Hi All, I'm looking for reviewer for my package (http://revu.ubuntuwire.com/p/arduino). Thanks in advance! [12:04] <\sh> wow...fixed libunwind ;) [12:26] Does anyone know why libaprutil1-dev is uninstallable on amd64? [12:26] the anjuta package FTBFS because of that lib http://launchpadlibrarian.net/39209795/buildlog_ubuntu-lucid-amd64.anjuta_2:2.29.90.0-0ubuntu2_FAILEDTOBUILD.txt.gz [12:58] should I use "Standards-Version: 3.8.3" or "Standards-Version: 3.8.4" in the debian/control file? lintian mark it as error (not updated?) [12:59] BlackZ: 3.8.4 [13:00] sebner: ok, so I ignore the lintian notice? [13:01] BlackZ: aye [13:01] sebner: ok, thank you :) [13:02] BlackZ: It depends on what you are doing. Updating a package? Doing a minor change to a Debian package? Doing a merge? etc. [13:02] slytherin: I'm doing a package [13:02] then 3.8.4 [13:03] slytherin: hmm, I should ask those questions too ^^ [13:03] :-) [13:04] slytherin: ok, thank you too :D [13:08] W: autotrash: unknown-section utilis <- which section should I use for an utility program? [13:09] BlackZ: utils [13:09] randomaction: yes, syntax error [13:09] you can see the sections here: http://packages.ubuntu.com/lucid/ [13:10] Laney: thanks, it will be useful :) [13:19] W: autotrash: binary-without-manpage usr/bin/autotrash <- how can I indicate where is/how install man page? [13:20] dh_installman [13:22] BlackZ: I think creating a file debian/packagename.manpages and listing all the manpages should be sufficient. Not sure though if it works with debhelper. I only used it with CDBS. [13:22] I will try with dh_installman [13:23] I'm reading how to do [13:27] slytherin: yes, that's also a method :) [13:46] Laney: if I do debian/package.manpages should I use dh_installman in debian/rules file too? [13:46] dh_installman has to be run, yes [13:46] but you might not have to list it explicitly [13:48] guys i'm confused about something , actually, the software i'm packaging has 2 conf files i "cannot" move to /etc/ i'd better et them in /usr/share/$package/ knowing if ever i decide to change the place of that conf files, i would have to modify a lot , huge modifications in the source .... it's a huge java software ... i know it' not really linux common having conf files in /usr/share/$package_name/ ... but i would like [13:48] to know if this may cause trouble ? [13:49] i will create debian/conffiles of course [13:50] even upstream developer recommended me not to change the path of the 2 related conf files ! ... i tried but i got some inconveniences [13:51] what do you think about that ? [13:51] may i ? [13:52] if you symlink to them from /etc [13:53] I am not a ubuntu developer, but perhaps it is better to put real files to /etc and symlink them from /usr/share... ? [13:53] sure [13:54] Laney, DmitryKurochkin yeah, i think about that, but if ever the package is remove, then dpkg remove the conf files from /usr/share/$package_name [13:55] no, put them in /etc and make a symlink to where the program wants them [13:55] oh, i got it .... ^^ [13:55] you're right [13:55] dpkg will do the right thing there [13:55] thanks [14:02] Could someone sponsor http://revu.tauware.de/p/turnin-ng please? turnin-ng_1.0.1-0ubuntu1_*.changes are lintian clean. [14:03] Laney: http://paste.ubuntu.com/376868/ that's ok? [14:06] no [14:07] Laney: how can be it? [14:07] put the path to the manpage in a file called autotrash.manpages [14:07] in debian/ [14:08] Laney: done, doc/autotrash.1 [14:08] ok [14:09] Laney: should I modify dh_installman in debian/rules file or is it ok? [14:12] Laney: could you review polygraph package (http://revu.ubuntuwire.com/p/polygraph)? [14:14] * Rhonda was asked why there is no translated CoC. I wonder how much sense that would make actually given that one has to sign the english document anyway - but I would be willing to invest some time into a German translation for it if people would consider that helpful? [14:15] * Rhonda . o O ( Of course with the usual disclaimer: "Only the English original is binding in case of doubts." ) [14:16] Rhonda, actually on the technical side, it wouldn't be difficult to make it translatable in Launchpad. [14:16] BlackZ: maybe [14:17] (depends on your rules file, pastebin it) [14:17] DmitryKurochkin: I don't have time now, sorry [14:18] dpm: Putting it into the wiki might be a good starting point. Actually I am quite surprised that launchpad doesn't seem to be i18n'ed at all. [14:19] Laney: ok, hopefully I am able to find two reviewers before the deadline. [14:19] Laney: http://paste.ubuntu.com/376877/ [14:19] O_O [14:19] remove that random dh_installman target [14:19] Rhonda, that's a longstanding discussion, which was mentioned on the launchpad-users list some weeks ago as well. In short, for the moment it won't be i18n'ed unless someone steps up and is willing to lead the effort [14:20] and you probably need %: to be last [14:20] (maybe) [14:20] and delete line 3 [14:21] Laney: done, so dh_installman -a ? [14:21] no, nothing [14:22] dpm: I rather think I should play around with i18n in something else than launchpad first to get some expertise. ;) [14:22] Laney: ok, so I suppose autotrash.manpages is sufficient [14:22] right [14:22] Precisely spoken, there already is aewan and glob2 on my agenda for digging into that area. %-/ [14:22] Rhonda, yeah, good plan, small steps first :-) [14:22] Laney: thanks for all :) [14:23] * BlackZ gives a coffee cup to Laney [14:23] :P === dholbach_ is now known as dholbach [14:52] guys, i hope this time it's ok ^__ ^ http://revu.ubuntuwire.com/p/pms-linux [14:52] it's really really hard to package AND respect debian/ubuntu policies , lol [14:52] harder if it's a java software ^^ [14:52] i did my best to make i lintian error & warning free, to clean correctly the source from windows binaries & such stuffs ( get-orig-source target in the debian/rules file ) [14:52] well, i just need someone who has enough time tell me if i have to worry about something else again [14:52] thanks for all :) [14:52] there are java teams that probably would be better [15:13] i made a needs packaging bug a couple months ago but nothing has really been done... how could i get someone to look at it? https://bugs.launchpad.net/ubuntu/+bug/416634 [15:13] Ubuntu bug 416634 in ubuntu "[needs-packaging] fastpatx - quick and simple web browser" [Wishlist,New] [15:31] guys, i've been told that i should check if Depends: in control file exist in ubuntu repositories, ..... so i would like to know if this repository is in Ubuntu by default [15:31] http://fr.archive.ubuntu.com karmic-updates/multiverse [15:38] in other words, may i add in Depends: field, some softwares which are in this repository http://fr.archive.ubuntu.com karmic-updates/multiverse [15:38] ? [16:39] sebner: could you merge/sync belpic? [16:39] I need one more advocate for http://revu.ubuntuwire.com/p/python-nltk to get it into Lucid. Since O'Reilly recently published book on NLTK (http://oreilly.com/catalog/9780596516499), I'd like to make "apt-get install python-nltk" possible... but that means I need one more MOTU to review and advocate for this by Thursday. Anyone interested? [16:40] I've gotten great advice (and one advocation) from people last week -- thanks! -- and the technical stuff should all be ironed out, so it shouldn't take too long. [16:41] ari-tczew: /me looks [17:04] Why is libsvn-dev uninstallable? This causes the anjuta package to FTBFS: http://launchpadlibrarian.net/39209795/buildlog_ubuntu-lucid-amd64.anjuta_2:2.29.90.0-0ubuntu2_FAILEDTOBUILD.txt.gz This is only an amd64 issue, it installs fine on i386. [17:06] I think the issue is caused by libaprutil-dev [17:21] lbrinkma: known problem, libmysqlclient16 from mysql-cluster-7.0 broke libmysqlclient-dev on amd64 [17:22] geser: bug #521815 status is fix released, so thats wrong? [17:22] Launchpad bug 521815 in mysql-cluster-7.0 "breaks all builds requiring libmysqlclient-dev" [Critical,Fix released] https://launchpad.net/bugs/521815 [17:24] geser: so why building still fails? [17:24] lbrinkma: the package doesn't build the package anymore but the archive has still the one from the previous upload [17:25] the "real" libmysqlclient16 from mysql-5.1 has to be uploaded with a higher version that the current one [17:26] so mysql-dfsg-5.1 must be reuploaded [17:27] yes (with a proper version to unbreak things) [17:27] geser: what version number does the package need? [17:28] greater than the current version libmysqlclient16 on amd64 has [17:32] geser: higer than 7.0.9-1, so something like 2:5.1.41-3ubuntu5? or could the package removed manually? [17:34] Hi, could someone please review http://revu.ubuntuwire.com/p/sqlite3-pcre ? Even just a small amount of feedback would be great. [17:38] Could a core developer please reupload the mysql-dfgs, so that anjuta and all the other packages that depending on libmysqlclient are working again? [17:40] oojah: looks like you uploaded a .pc directory :) [17:40] i'll give another review in a minute when I get my pc booting again [17:41] lbrinkma: that would work (adding an epoch but it's a last effort and this can't be undone) [17:42] lbrinkma: ask slangasek or zul about the status (as I know they were discussing how to best unbreak it) [17:44] Laney: Damn, that's annoying [18:19] geser: Presumably it's going to be a matter of overriding the version of that binary package to 7.0.9really5.1.41-3ubuntu5 [18:25] Hi everybody [18:26] Is ther some Ubuntu Developer free to advocate a package ? ;) [18:27] My package enna http://revu.ubuntuwire.com/p/enna has already 1 advocation ! Can someone review it please ? [18:27] asbin: I've opened it in a tab, if no one else has looked at it by the time I finish work today I'll take a look at it [18:28] highvoltage: thank you ! :D [18:28] REVU question: I accidentally clicked the "Archive" link next to python-nltk on the main http://revu.ubuntuwire.com/ and now it's no longer listed on the front page. I still want to get a second advocate for it so it can get into Lucid; how can I un-archive it? [18:28] asbin: you're welcome [18:29] It's still visible at http://revu.ubuntuwire.com/p/python-nltk and http://revu.ubuntuwire.com/?archived=true but if it's not on the "main" page fewer people will see it. Can I un-archive it myself, or does it take someone with REVU admin rights to do that? [18:32] ... never mind, just found the un-archive link. I'm blind sometimes. :-) [18:34] highvoltage: if you will have some more time, can you please review polygraph package (http://revu.ubuntuwire.com/p/polygraph)? [18:36] hi MOTUs! I made my first attempt at packaging a new package yesterday, if somebody finds time, feedback is very appreciated. REVU link is: http://revu.ubuntuwire.com/p/colormath [18:38] DmitryKurochkin: I saw your message on the list and also have that open in a tab, so I might be able to look at it a bit later! [18:39] highvoltage: thank you! [18:42] highvoltage: Thank you very much for your ACK !! :) [18:46] Hi All! Could anyone review my package Arduino www.arduino.cc http://revu.ubuntuwire.com/p/arduino? Thanks! [18:46] highvoltage: do you know when a package with 2 ACK is being uploaded in universe ? [18:47] iirc it should be uploaded by the person who gives the second ACK [18:51] fabrice_sp: thank you for your comments on gtklick. i made the changes you suggested, maybe you could take another look? (http://revu.ubuntuwire.com/p/gtklick) [18:52] Hi dooooomi [18:52] sure: let me check [18:56] dooooomi, as a side comment, if you would have used source format 3.0 (quilt), you wouldn't need README.source and dependency on quilt ;-) [18:57] fabrice_sp, i still got a warning that I didn't include README.source when i switched a package to format 3.0 (quilt) [18:57] superm1, in REVU or in lucid? [18:57] fabrice_sp, i ended up just including a symlink to the README.source that's shipped w/ quilt [18:57] * fabrice_sp converted somes packages to get rid of README.source [18:57] fabrice_sp, oh that was from lintian on karmic I suppose... [18:57] * superm1 stabs lintian [18:57] :-D [18:58] and you don't need to build-depend on quilt anymore either when you do dh --with-quilt? [18:59] that's something else i guess I can fix too then :) [19:00] this is what I did, following the Debian's instruction on how to convert a package to 3.0 format :-) [19:00] you sdon't need to do with-quilt at all [19:00] highvoltage: did you upload enna or should I do it? [19:01] superm1, by the way, I think that a comment of mine made loose your advocate on some package (don't remember which one, actually) [19:06] dooooomi, ack'd. You only need another advocate :-) [19:07] persia perhaps? gtkclick is interesting for ubuntustudio [19:07] fabrice_sp, yeah you looked a little more thoroughly than i was looking :) [19:07] fabrice_sp, i think that rhpot1991 is working out a solution yet [19:07] fabrice_sp: awesome, thanks :) [19:08] superm1, ok. As soon as it's fixed, I'll check again, and if its ok, shall I uplaod it or wait for your advocate? [19:08] dooooomi, yw :-) [19:09] fabrice_sp, go ahead and upload as soon as he's got that fixed i say [19:09] rhpot1991, ^ [19:09] ok [19:12] superm1: fabrice_sp waiting for my ppa to build so I can make sure all is good, then I'll push to revu [19:13] hi, it's been a long time i've been doing packaging for ubuntu, so i don't understand dholbach's note about LGPL-3 in debian/copyright here: http://revu.ubuntuwire.com/p/zope.browserresource - could anyone help me with that, please? [19:17] phanatic: debian/copyright is missing a reference to /usr/share/common-licenses/LGPL-3 [19:18] phanatic: i.e., source packages provide a link to the same license on the local Ubuntu install [19:19] Is python-libxml2dom packaged? [19:19] * mok0 is puzzled [19:20] crimsun: but upstream is licensed under the Zope Public License [19:20] phanatic: right [19:21] phanatic: I don't think you actually need a reference to that file, since it isn't LGPL 3 [19:22] crimsun: thanks. in that case i think i've addressed all his points in the new upload :) [19:24] phanatic: yep, just commented [19:25] crimsun: thank you === ShadowChild is now known as lukjad86 [19:36] Any MOTUs have a moment to look at http://revu.ubuntuwire.com/p/python-nltk? All the minor issues from last week should be fixed now, and I have one advocate already. One more advocate and it can go into Lucid. [19:51] Hi All! Could anyone review my package: Arduino www.arduino.cc http://revu.ubuntuwire.com/p/arduino? Thanks! [19:59] abogani, license for libraries/* is PD. What's that? [20:00] fabrice_sp: Public Domain [20:00] you should add the text [20:01] fabrice_sp: Upstream don't release it: simply write " Released under Public Domain". Where I can find text? [20:01] tbh, I don't know [20:02] abogani, there is no disclaimer? [20:06] fabrice_sp: Some of these files don't contains other than C source... (No author, no date, no license _nothing_). [20:07] Only C/C++ source code [20:08] pfff: will have a look tomorrow (too complexe for me right now) [20:13] fabrice_sp: Thanks anyway! :-) === RoAk is now known as RoAkSoax === RoAkSoax is now known as RoAk === RoAk is now known as RoAkSoAx [21:29] Hi All! Could anyone review my package Arduino www.arduino.cc http://revu.ubuntuwire.com/p/arduino? Thanks! [21:46] Hi All! Could anyone review my package Arduino www.arduino.cc http://revu.ubuntuwire.com/p/arduino? Thanks! [21:51] abogani: why is arudiuno.png UUEncoded? [21:53] abogani: re your get-orig-source rule, rather than hardcoding the svntag in debian/rules, could you extract it from the changelog verrsion a la http://wiki.debian.org/SandroTosi/Svn_get-orig-source ? [21:53] lfaraone: I'l take a look! Thanks! [21:54] Anyone have time to be a second advocate for http://revu.ubuntuwire.com/p/python-nltk? Should be a pretty straightforward review, the quirks have been hammered out by now. I'd like to get it in before the freeze. [21:54] lfaraone, could you also look at http://revu.ubuntuwire.com/p/colormath, I'm new at this and eager to get a review ;) [21:55] v0xel: sure, I'm not MOTU, but I'll be glad to take a look. [21:55] lfaraone, thanks! [21:58] abogani: fyi, files in src/processing/xml/* are under zlib/libpng according to licensecheck, not "MIT style" [22:00] abogani: libraries/Ethernet/utility/w5100.c is "(c)COPYRIGHT" and "ALL RIGHTS RESERVED", therefore unfree. [22:02] v0xel: I'll brb in a bit, but I'll get to it by the end of today. [22:03] rmunn: work for you to do ;) [22:05] bdrung_, Thanks. [22:05] P: python-nltk: copyright-refers-to-symlink-license usr/share/common-licenses/GPL - thought I fixed that, argh. Checking now... [22:05] nope ;) [22:06] rmunn: let me know once you are finished [22:06] Hah - yeah, I fixed it... but in the wrong VM. Too many tabs open. :-) [22:07] :) [22:07] bdrung_: If you've got time whilst you're waiting, could you take a look at sqlite3-pcre? [22:07] bdrung_: I l*** you ! Thanks (for enna) !! :) [22:08] rmunn: drop debian/pycompat [22:09] As for the CDBS question - I'm just starting, and CDBS looked simpler than debhelper. Haven't had time to look at dh 7 yet. I'll probably switch it over in a -0ubuntu2 package or once I package it for Debian, but so close to feature freeze I don't want to make any major changes. [22:09] rmunn: it's not a major change (drop cdbs and rewrite debian/rules) [22:10] rmunn: file:///usr/share/doc/debhelper/examples/rules.tiny [22:11] rmunn: man dh [22:12] bdrung_, where can I read about pyversions? I can't find it mentioned anywhere in http://www.debian.org/doc/packaging-manuals/python-policy/ [22:12] (which is where I got XS-Python-Version from) [22:12] rmunn: i looked in /usr/share/doc/python-support/ [22:13] rmunn: in your case the file contains "2.4-" [22:14] bdrung_, Thanks, reading it now... and just created a pyversions file [22:14] lfaraone: get-orig-source and ZLIB (instead of MIT) fixes. Reiman: arduino.png uuencode, strange disclaimer of w5100.c. How do you suggest me to handle this file? [22:18] oojah: i recomment to use dpkg-source 3.0 (quilt) format and DEP-5 for debian/copyright, DEP-3 for patches, you should add a link to debian/watch, run update-maintainer [22:18] oojah: do you want to bring this package to debian, too? [22:19] Lucid's dpkg support 3.0 ? [22:20] abogani: yes [22:20] i moved already many packages [22:20] bdrung_: Thanks [22:35] bdrung_, Thanks for your help, uploading new version to REVU now. Should appear in 2-3 minutes. [22:35] bdrung_: Yes, debian would be good as well. [22:38] bdrung_, Okay, new upload is up at http://revu.ubuntuwire.com/p/python-nltk now with your suggested changes. [22:39] bdrung_, If there's anything else that would prevent you from advocating it, please let me know. :-) [22:48] How can I check to see if a package is installed and only if it is call sudo apt-get purge packagename? [22:48] basically I don't want to ask the user to become root if they don't need to [22:50] bdrung_, you around? You asked me to let you know when I was finished with http://revu.ubuntuwire.com/p/python-nltk. It's ready now. [22:51] doctormo: for example, dpkg -l | egrep ^ii [22:51] doctormo: can you explain the problem a little more? [22:51] why should the user need to remove a package? [22:52] rmunn: yes, i am looking at it. [22:54] bdrung_, Thanks. I feel like I've been inches away from the finish line for a week now on this package, so I'm eager to get it finished. Your help is much appreciated. [22:55] rmunn: i will add a newline to debian/rules and remove the empty line from debian/watch, if you are ok with that. [22:55] bdrung_, Sure. [22:55] geser: If they want to develop groundcontrol, I require that they remove any groundcontrol deb packages so the plugins don't get confused. [22:56] rmunn: why did you need python-yaml in the clean rule? [22:56] bdrung_, Because setup.py does "import nltk" and nltk/__init__.py does (somewhere in its import structure) "import yaml" [22:56] k [22:57] bdrung_, I discovered this because the first version of my package didn't have python-yaml in build-depend, and it FTBFS'ed once I put it up on REVU. [22:57] (I have python-yaml installed on my system, so I'd failed to notice the problem. Taught me to always test with pbuilder first, saves time.) [22:57] doctormo: then the snippet from hggdh should do it [22:58] http://pastebin.com/m70407a55geser: What do you think of this other snippet I was just passed? [22:58] damn irc, geser: http://pastebin.com/m70407a55 [22:59] looks even better [23:04] bdrung_: For sqlite3-pcre, what link should I add to the watch file given that there's only a git repo available and I have a get-orig-source in rules? [23:05] oojah: for example a link to the web interface of git [23:05] bdrung_, Thanks for the +1! Do I need to get sistpoty to re-advocate this, since the REVU software considers his previous advocation obsoleted by the new upload, or are the differences minor enough that it doesn't matter? [23:07] rmunn: i don't care about it. the rule is that two motu have to vote for the package, then it can be uploaded. sistpoty was fine with the package. the changes will probably not change his mind. [23:08] bdrung_, Understood, thanks. [23:08] doctormo: fyi, python-xdgapp was REJECTED from Debian. [23:08] lfaraone: Bah, oh well [23:08] rmunn: can you link bug #514936 to debians ITP bug? [23:08] Launchpad bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] https://launchpad.net/bugs/514936 [23:08] bdrung_, Sure, one sec. [23:08] lfaraone: Rationale? [23:08] doctormo: quoth the installer, "sorry, we cannot add a full source package for every small script. Please try to get it added to python-xdg or a similar package." [23:09] bdrung_, Now that I've gotten it in before the Lucid freeze deadline, my next step is to submit it to Debian. [23:09] lfaraone: It's not a small script, but I'll take it into groundcontrol, the jerks. [23:09] rmunn: yes ;) [23:10] rmunn: you'll want to get it in DPMT (if it's a module) or PAPT, and then ask POX to sponsor :P [23:10] jono: python-xdgapp was rejected from debian [23:10] bdrung_, But since the Lucid deadline was so close, I focused on getting an acceptable package into Ubuntu first. Afterwards I can get it into Debian and lucid+1 can just have python-nltk sync'ed. [23:10] rmunn: one thing before uploading it. why do you call the source package python-nltk instead of nltk? [23:10] lfaraone, I'm unfamiliar with those acronyms... Still new to this. [23:10] rmunn: well, you can get it into debian NEW, and then ask an Archive Admin to sync it :) [23:11] bdrung_, Because python-(foo) seems to be the naming convention for Python libraries: python-yaml, python-elementtree, python-lxml, and so on. [23:11] rmunn: in fact, it's policy! [23:11] rmunn: you can call the source package nltk however. [23:11] rmunn: yes, the binary package must be called python-mltk, but not the source [23:12] rmunn: the source name should be the upstream name. (for example matplotlib is the source for python-matplotlib) [23:12] lfaraone, bdrung_, This is my first package; I haven't yet learned how to make the binary package name differ from the source package name. Feel free to make the change if you want. [23:12] rmunn: http://wiki.debian.org/Teams/PythonModulesTeam == DPMT, http://wiki.debian.org/Teams/PythonAppsPackagingTeam == PAPT. You want the former. They hang out in debian-python, and manage their packages using svn-buildpackage. (which can be a PITA in itself, but whatever) [23:13] rmunn: the source package name is the first line in your control file. [23:13] rmunn: k, will rename the source to nltk [23:14] rmunn: example: http://paste.ubuntu.com/377213/ [23:14] bdrung_, That should make future maintenance simpler, as the upstream tarball is named nltk-###.tar.gz [23:14] lfaraone, Ah, I see. Elegantly simple (as most things in Debian are) once you know how to do it. :-) [23:15] rmunn: the upstream tarball name is irrelevant for making packaging simpler/harder. uscan handle it. [23:15] rmunn: and don't forget the changelog [23:15] It's just quite a bit to learn at once. I thought at first I had done a rather good job making the package, checking copyright issues carefully, etc.... and look how many different uploads and comments ended up on http://revu.ubuntuwire.com/p/python-nltk before I was through. :-) [23:17] bdrung_, Speaking of the changelog -- should it have the source or binary package names in the "python-nltk (2.0~b8-0ubuntu1) lucid; urgency=low" line? [23:17] rmunn: everybody makes mistakes their first time :P [23:17] rmunn: source. [23:17] lfaraone, Naturally. That's why the review process is in place. [23:18] rmunn: that's the source name (imaging multiple binary package made out of one source) [23:18] If it weren't for more experienced packagers looking at my code, I would have ended up with a package version like "2.0b8" (no ~ in there) and been forced to use an epoch once NLTK came out of beta. [23:18] lfaraone: It strikes me that if python-xdgapp was rejected, then it's highly likely that groundcontrol will be too. [23:18] bdrung_: I've made your suggested changes to sqlite3-pcre. [23:18] lfaraone: So I was wondering your opinion on if we should bother? [23:18] Among the many other potential problems that they helped head off... [23:19] doctormo: why would groundcontrol be rejected? [23:19] Conversion to quilt 3.0 was much less painful than I expected. [23:19] doctormo: why was xdgapp rejected? [23:19] lifeless: Too similar to python-xdg [23:19] lifeless: "sorry, we cannot add a full source package for every small script. Please try" [23:19] "to get it added to python-xdg or a similar package." [23:19] lifeless: Even though it wraps around it, we're advised to upstream the features into python-xdg [23:19] doctormo: which is reasonable long-term advice anyway, probablyt. [23:19] doctormo: was that on mentors? [23:20] cause mentors isn't the end-all, archive admins are the actual arbiters [23:20] lifeless: archive admins. [23:20] [and it may be reasonable advice, though I'd need to study more to know] [23:21] Okay, LP #514936 has been linked to the Debian ITP. [23:21] Launchpad bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] https://launchpad.net/bugs/514936 [23:21] lifeless: it's already synced into Ubuntu, so it's not a big deal. (I bribed an *ubuntu* archive admin for that :) ) [23:22] hmm, well I'd probably argue that, but it wouldn't necessarily be pretty [23:22] (the rejection I mean) [23:22] I love how there is already a coherence.extern.xdg module that duplicates xdgapp code for another project. [23:23] ciao [23:23] oojah: you should grab the ownership and update the title (to the new source name) of the ITP [23:23] rmunn: ^ [23:24] bdrung_, Right, taking care of the Debian ITP is next on my todo list. Was going to grab ownership, now I'll also update the source name as well. [23:28] lifeless: you're welcome to, I'm too shy to irk the wrath of archive admins. [23:28] lfaraone: I've emailed the guy behind python-xdg and I've sucked in xdgapp into groundcontrol for now, since it's very unlikely upstream will move quickly enough. [23:29] doctormo: mk. it's very possible btw that we can get a FFe for GC [23:29] lfaraone: what is an FFe? [23:29] feature freeze extention? [23:29] doctormo: feature freeze exception. [23:29] ah [23:29] !ffe [23:29]