[00:00] I think "V7 This is the recommended mode of operation." confuses it a bit [00:04] Laney: It also doesn't help that dh_make defaults to 7 iirc [00:05] cody-somerville: What about for a package that uses debhelper v7 features in debian/rules but doesn't need to? [00:05] I'm not sure I see the problem any more [00:05] hardy-backports has dh7, and backporting to anything beyond that is probably pretty rare [00:06] nhandler, You're welcome to upload and change it after it gets accepted but I wouldn't comment on it for packages in revu [00:06] Unless otherwise indicated, all debhelper documentation assumes that you are using the most recent [00:06] compatibility level, and in most cases does not indicate if the behavior is different in an earlier [00:06] compatibility level [00:07] Laney: I know. I'm still not particularly clear on the reason behind requesting users use a lower compat level, but many developers insist on this [00:08] One last question, does the perl artistic license require a copy to be distributed in the source? [00:09] Don't all licenses? [00:09] linking to it is pretty dubious IMO [00:14] Hi all, i really wanna update Netbeans 6.1 to 6.5, but the Feature Freeze already passed, some can tell me what i can do ? Still have another way to solve it without a backport ? [00:14] (update it in Ubuntu+1 ) [00:15] Zetto, ugh... Feature Freeze has *not* passed. [00:15] ops [00:15] :) [00:15] yep [00:15] :P [00:15] So lets get Netbeans uploaded!! woot! [00:16] February 19th didn't passed :P [00:16] cody-somerville, how we can doo it ? [00:16] nhandler: Specifying a higher version dependency than is required is a poor packaging practice. [00:16] It complicates backports substantially. [00:16] And it's just not correct. [00:16] Zetto, you prepare an upload of the new version and then you upload it [00:17] scottk: Just out of curiosity, how does it complicate the backport process since debhelper has been backported? [00:17] Generally speaking with debhelper it's pretty clear in debiah/changelog when stuff appeared. [00:17] To hardy yes, but we still support dapper and gutsy. [00:18] cody-somerville, on the Bug report, Yulia already make packages on yours PPA [00:18] ScottK, In the case nhandler is asking about, the individual uses a new feature available in v7 but they could have done it the "old" way. [00:18] Zetto, Then I recommend you ask someone to sponsor the upload [00:18] In that case the dependency is fine. [00:18] cody-somerville, thanks [00:18] If they actually use dh 7 features, the dependency is correct. [00:19] scottk: Even though there is no reason for the package to use the debhelper v7 features? [00:19] nhandler, maybe more context would be useful [00:19] nhandler: Packages don't need to use debhelper at all. [00:19] The point of debhelper is to make life easier. [00:19] If the packager likes using a particular feature, then that's fine. [00:20] scottk: Ok. And do you know whether the perl artistic license requires a full copy to be distributed in the source? [00:20] I was arguing (apparently on a one sided basis) against arbitrarily selecting the current version as the required version. [00:21] nhandler: Ubuntu requires a full copy of the license in the source. [00:21] nhandler: Also Perl is GPL v1 and follow, so if something is licensed 'on the same terms as Perl' it includes GPL v1. [00:22] I didn't know that. Thanks scottk [00:22] Mithrandir rejected my very first package due to that. [00:37] To upload Netbeans 6.1 to 6.5 I need a sponsor to upload 4 diff files did by a Sun employee, someone can help ? [00:37] *to update [00:41] Zetto: File a bug with the diffs and subscribe ubuntu-universe-sponsors. Who your employer is isn't really a consideration. [00:41] ScottK, thanks, a will subscribe [00:44] ScottK, like we already have the diffs, and the UUSponsors are already subscribed, what should be the status of the bug ? In Progress ? [00:47] Triaged or confirmed. [00:47] In progress is when a sponsor is looking at it. [00:52] ScottK, thanks, i will change all they to Triaged [00:53] You're welcome. [00:53] ScottK, Triaged isn't in the list ^^ [00:53] Then confirmed [00:53] ScottK, do you know why ? [00:53] ScottK, ok [00:53] Yes, it's a restricted status. Not everyone can set it. [00:53] That's why I said confirmed or triaged. [00:54] Triaged is an interesting theory, but the restriction on it's use makes it pretty useless for workflow bugs. [00:54] ScottK, can you change to Triaged or Upload the files ? [00:54] hummm [00:54] I could, but I'm busy with other things currently [00:55] ScottK, ok, can i ask you again in one hour ? [00:55] You can ask, but I find repeated requests demotivating. [00:56] I recommend against it. [00:56] ok === asac_ is now known as asac [02:48] ScottK, are you busy ? [02:48] yes. [02:49] good work, i will Sleep now [02:49] bye all === ziroday` is now known as ziroday === slicer is now known as slicer_ === slicer_ is now known as slicer [13:21] hi pochu [13:30] would a correct conf be at /etc/udev/libmtp8.rules or /etc/udev/rules.d/45-libmtp8.rules ? [13:44] could anyone review this? http://revu.ubuntuwire.com/details.py?package=gnome-format [14:20] hi quadrispro [14:20] I'm reviewing gnome-format [14:21] quadrispro: so we are finally using the orig tarball, aren't we? [14:21] thank you pochu [14:21] in the get-orig-source, there's no need to untar the tarball [14:22] it should be enough to just `bunzip && gzip -9` [14:22] (and that's better, since the .tar checksum won't change) [14:23] pochu: yes, you're right, I'm workin on it [14:23] quadrispro: and a couple more comments [14:23] in the manpage, remove [OPTIONS...], since there is no [OPTIONS] section [14:23] ok [14:24] and in the long description, this looks a bit weird: [14:24] It is designed for Linux based operating systems, like Ubuntu, and for the GNOME desktop. [14:24] I'd remove Linux and Ubuntu from there [14:25] it's ok if you want to mention that it integrates well with GNOME though [14:25] Linux is pointless because Ubuntu only runs on Linux, and Ubuntu is pointless because if the package is in Ubuntu, is because it runs there [14:27] pochu: http://paste.ubuntu.com/115218/ [14:28] gzip -9nf, rather [14:29] quadrispro: looks fine [14:29] quadrispro: you can view it using `man ./gnome-format.1` [14:30] I know :) [14:30] ok :) [14:31] man -l filename.1, precisely [14:31] Laney: -f looks useless for a .tar [14:32] yeah, n is more important [14:36] quadrispro: did you use two spaces in the list of actions in the long description on purpose? [14:36] s/actions/features/ [14:36] quadrispro: if so, good :) [14:36] is svn.debian.org working for you? I can't checkout branches with my ssh key :( [14:38] pochu: 2 spaces?? where? [14:38] DktrKranz: I can update my checkouts fine [14:39] quadrispro: [14:39] Features: [14:39] - Easy to use. [14:39] - Autodetects available media through HAL. [14:39] there are two spaces before the dashes [14:39] pochu, which string do you use? Probably it's a failure by my side [14:39] svn co :) [14:39] yes, there are 2 spaces, is it right? [14:39] quadrispro: yeah, it's perfect [14:39] quadrispro: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480322 [14:39] Debian bug 480322 in gnome-terminal "Description could be better formatted" [Minor,Closed] [14:40] DktrKranz: IIRC my initial checkout was like "svn co svn+ssh://svn.debian.org/svn/foo" [14:40] DktrKranz: with this in my .ssh/config: [14:40] Host svn.debian.org User pochu-guest [14:41] in two lines [14:41] Host svn.debian.org [14:41] same here [14:41] User pochu-guest [14:41] DktrKranz: give me an URI and I'll try [14:41] with s/pochu/dktrkranz/, of course :) [14:41] heh [14:41] I hope :) [14:41] svn+ssh://svn.debian.org/svn/python-apps/packages/bleachbit [14:41] pochu: uploaded to REVU [14:42] DktrKranz: works fine [14:42] quadrispro: ok, I'm going to upload it to the archive if your changes look fine [14:42] gah! [14:43] no way here... [14:45] pochu: REVU doesn't want to work [14:46] DktrKranz: can you checkout without ssh? [14:46] yes [14:46] DktrKranz: there's #alioth on OFTC, btw [14:46] but no write access [14:46] bah, anyway I've uploaded gnome-format to my server -> http://home.alessiotreglia.com/jaunty/result/gnome-format_0.1.1-0ubuntu1/ [14:46] DktrKranz: is your key in alioth.debian.org? :) [14:46] yes [14:46] I did some commits already, but today it doesn't work at all [14:47] no idea then [14:47] mmmh... let's try to connect to our build server [14:47] it uses ssh as login method [14:47] mmmh... no access! [14:47] so, it's seahorse! [14:47] DktrKranz: how long have you been without using it? [14:48] ScottK, any news about this? [14:48] https://bugs.launchpad.net/ubuntu/hardy/+source/amule/+bug/244670 [14:48] the keys were removed due to the ssh disaster ;) [14:48] Ubuntu bug 244670 in amule "[hardy] Request of update of aMule to 2.2.2 final release" [Undecided,Confirmed] [14:48] pochu, my key is old enought to be immune of SSH crisis ;) [14:48] enywat, latest commit is about two weeks ago [14:48] *anyway [14:50] DktrKranz: maybe ask in #alioth [14:51] \o/ I GOT IT! seahorse crashed and no longer managed my keys! [14:51] now, let's see if commit was successful [14:51] I'm experiencing issues with REVU... mmm [14:51] quadrispro: get-orig-source fails here [14:51] with the package from your server [14:52] bunzip2 ../gnome-format-.tar.bz2 [14:52] bunzip2: ../gnome-format-.tar.bz2 is not a bzip2 file. [14:52] make: *** [get-orig-source] Error 2 [14:52] it works, pochu sorry for the noise, it was my seahorse which crashed [14:52] pochu: type uscan --dehs [14:52] DktrKranz: np [14:52] emilio@saturno:~/tmp/gnome-format-0.1.1$ uscan --dehs [14:52] [14:52] uscan: Can't use --verbose if you're using --dehs! [14:52] [14:53] quadrispro: I'm on Debian btw [14:53] oh [14:53] wait [14:53] USCAN_VERBOSE=yes [14:53] that's on my .devscripts :) [14:54] ok [14:54] quadrispro: why do you need --dehs, btw? [14:55] pochu: it's necessary to retrieve the last available version from upstream [14:55] ok [14:55] --dehs just changes the output format, I thought? [14:56] maxb: yes, but then it's easier to parse it I guess [14:56] quadrispro: ok, works now without --verbose [14:56] yeah [14:59] Is get-orig-source really allowed to cd ? [14:59] quadrispro: if you run get-orig-source, do you get this md5sum? [14:59] f6cf5689480fc9cbe6da344175083b08 gnome-format_0.1.1.orig.tar.gz [15:00] maxb: why not? [15:01] pochu: one moment [15:02] pochu: yes [15:03] ok, I'm uploading with that tarball then [15:03] alessio@quadrispro-desktop:~/Desktop/devel/REVU/gnome-format$ md5sum gnome-format_0.1.1.orig.tar.gz [15:03] f6cf5689480fc9cbe6da344175083b08 gnome-format_0.1.1.orig.tar.gz [15:04] pochu: thank you very much :) [15:04] quadrispro: thanks for packaging it :) [15:04] DktrKranz: FYI: sed accepts multiple "-e"'s [15:09] pochu: do you have some minutes for this? https://bugs.launchpad.net/bugs/325882 [15:09] Ubuntu bug 325882 in installation-report-generator "Please update installation-report-generator to 0.2.1" [Undecided,Confirmed] [15:10] quadrispro: Successfully uploaded packages. [15:10] quadrispro: uploaded ;) [15:10] POX, yes, I used multiple instances just for "cosmetic" purposes [15:11] ok then [15:11] thank you pochu [15:11] RainCT: hey, there seems to be some problems with REVU [15:12] RainCT: quadrispro can't upload his package, and I can't login... [15:12] RainCT: El servidor «revu.ubuntuwire.com» está redireccionando de una manera que nunca terminará. [15:12] RainCT: I can access REVU, but when trying to login and clicking on "sign in" in Launchpad, I get that [15:12] pochu: ehm.. did you upload installation-report-generator too? [15:12] POX, new upstream is available, but older one is still in NEW. Is it worth waiting for the older to be accepted right now? [15:12] quadrispro: nope [15:12] ah ok ok :) [15:13] DktrKranz: well, I'd recommed to wait with an upload and ping me right after old one will be accepted [15:13] I'll do that, thanks :) [15:14] DktrKranz: otherwise your package will fall to the bottom of the queue again ;) [15:14] * pochu is already 5th [15:14] pity that they don't process it top-bottom ;) [15:14] > 200 packages \o/ [15:15] * DktrKranz can't wait for valentine's day! [15:15] :) [15:16] quadrispro: let me know when REVU works again and I'll add a comment and archive the package ;) [15:18] What version number is best to use for something that doesn't (hasn't yet) do releases? 0.darcsDDMMYYYY? [15:20] Laney: 0~foo, I'd say [15:20] Also is it required that source files include license headers and copyright information, or is having this in the top-level file enough? [15:20] LICENSE file, that is [15:21] Laney: otherwise, if the first public release is 0.X you will be in trouble ;) [15:21] true [15:21] dpkg --compare-versions "0.darcs" gt "0.0.1" && echo true [15:22] Laney: I think LICENSE is fine, but header in source files is encouraged [15:22] fair, I got the idea from ffmpeg-debian [15:22] not sure if you will get a reject for that [15:23] Laney: they probably use 0.svn before ~ was created [15:23] I'm never going to convince upstream to go back and add headers to all of their files [15:23] so hmm [15:24] hmm, they don't :) [15:24] ffmpeg (0.cvs20040716-1) unstable; urgency=low [15:24] * Initial release (Closes: #199266). [15:24] -- Sam Hocevar (Debian packages) Fri, 16 Jul 2004 12:47:27 +0200 [15:24] but dpkg supports ~ since 2003 [15:24] anyway, ~ is better, otherwise you're screwed [15:24] sure [15:24] Laney: what package is it, btw? [15:24] agda [15:25] http://wiki.portal.chalmers.se/agda/agda.php?n=Main.HomePage [15:25] Agda is a dependently typed functional programming language. [15:25] that one? [15:25] correct [15:35] Hello. I just installed Hardy (kubuntu flavor) and I am looking at using the gdata-python library to write some software to access google calendars. The hardy repo's are supplying version 1.0.9-1ubuntu1 of the gdata-python library but the current version is 1.2.4. The latter version includes examples but I don't know what other changes are included. version 1.0.9 was completed in OCT of 2007. The current version was just done in Jan 22 2008. Is [15:37] surfaz: I have no idea. I'm not in motu-sru, so it's totally not up to me. [15:38] Regarding the issue of updating packages to more current versions, is there a process I can read about somewhere? [15:39] opps, sorry. I ask you because I saw your post in that bug [15:40] * tobor taps side of th keyboard "hello? Is this thing on? ... " [15:44] hm... weird, bug #145572 says unmet dependencies for amd64, but I tried 1.4-12build1 and it builds fine on amd64: https://launchpad.net/~medigeek/+archive/ppa/+build/860601 [15:44] Launchpad bug 145572 in imaze "[UNMETDEPS] imaze has unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/145572 [15:46] surfaz: I was involved in getting the initial updates in, but for the previous releases, no idea. [15:48] hi! [15:48] i'd like to contribute motu as much as i can, but im not sure if i could :) do i need any programming skills etc.? [15:49] Knowing shell scripting (at least a little) is good. [15:49] If you have programming skills they can be helpful, but they are not required. [15:50] i have stuided PHP for couple of months [15:50] but i dont think [15:50] that will help :D [15:53] thanks anyway, i'll check the documentation [15:59] !gettingstarted [15:59] A great place to start your MOTU adventure is https://wiki.ubuntu.com/MOTU/GettingStarted [16:00] ScottK, that getting started doc is being revised. [16:00] too [16:01] Hm... I get a "dh_clideps: Warning! No Build-Depends(-Indep) on cli-common-dev (>= 0.4.4)!" while having "Build-Depends-Indep: ... cli-common-dev (>= 0.6),..." in control. Any ideas? Does it have to be the exact version? [16:16] dpaleino pointed me to http://wiki.debian.org/Proposals/CopyrightFormat on REVU. Should this really be used? There seems to be still a lot of discussion on this proposal. [16:19] pochu: Hey. With which pages do you have that error? [16:19] RainCT: with http://revu.ubuntuwire.com/details?package=gnome-format [16:19] it still happens [16:20] RainCT: the url redirected from Launchpad is this: [16:20] http://revu.ubuntuwire.com/launchpad_login?janrain_nonce=2009-02-07T16%252525252525252525252525252525252525253A23%252525252525252525252525252525252525253A44Zxnl9jD&openid.assoc_handle=%252525252525252525252525252525252525257BHMAC-SHA1%252525252525252525252525252525252525257D%252525252525252525252525252525252525257B4980d3c6%252525252525252525252525252525252525257D%252525252525252525252525252525252525257B4uA4%252525252525252525252525252525252525252Bg [16:20] sorry! :( [16:20] pochu: ah, but only login fails? [16:20] RainCT: yeah [16:20] I can view the page fine [16:20] err right, now I know why I had some mod_rewrite lines commented out :P [16:21] heh [16:22] [16:23] Fixed [16:23] RainCT: ty [16:23] err. or not [16:25] pochu: well, commented that out again :P. Should work now [16:26] RainCT: right, worked now, thanks! [16:44] would a MOTU be so kind as to review my package? Thanks in advance! http://revu.ubuntuwire.com/details.py?package=lmalinux [16:55] sven777: I'm not a MOTU, but I just noticed: changelog should just contain one entry with "Initial release...". Changes made during the REVU process should not be reflected in the changelog. [16:56] hefe - oh ok thanks v. much - I shall change that right now :) [16:59] even if there is a new upstream release? [16:59] sven777: AFAIK yes. I had a similar case with one of my packages. [17:00] hefe_bia: ok thanks again - you wouldn't happen to know of any other "gotchas" like that would you? [17:01] sven777: Might also be better to remove the debian/ dir from the .orig,tar.gz, so you keep packaging separate. [17:01] Because now your .diff.gz is empty. [17:03] For example the debian/ dir would be different if the package was adopted for Debian. [17:04] hrm.. what happened with firefox 3.0.6? [17:05] hefe_bia: is that a problem though? [17:05] it's just going to result in a diff.gz anyway [17:06] sven777: you should avoid modifying the orig.tar.gz at all, that's why we have the .diff [17:06] stdin: He's also upstream [17:06] ya :) [17:06] and what if debian want it? [17:06] just keep the orig.tar.gz for the raw package [17:07] wouldn't they just change some things in the debian dir and that results in a diff anyway? [17:07] no, they's need to modify the orig.tar.gz [17:07] sven777: the debian/ should be in a diff.gz [17:07] ok, I shall remove it [17:07] stdin: not really, but it's still weird [17:08] it's obviously a point of contention, whatever the case - so I'll stick to something more normal [17:08] thx for the help [17:08] sven777: you don't need to put your name in the changelog if you're the only one changing anything [17:08] * RainCT upgrades lintian on revu [17:08] ie: "[ Sven Carlberg ]" is not needed [17:09] stdin - I just noticed some other changelogs and thought it was a more "proper" format [17:09] It's not mandatory, since there are also "native packages", but it is a cleaner approach to separate packaging and the source itself. Not sure about the versioning scheme for Ubuntu native packages also... [17:09] sven777: [ .. ] is only for when several people do something to that revision [17:09] sven777: it's used when more than one person commits changes, to attribute credit [17:09] ok got it, thx [17:11] do you really need debhelper (>= 7) ? [17:11] I was just following a template [17:13] also, you have a debian/dirs, but don't call dh_installdirs [17:13] or dh_installmenu [17:14] dh_installdirs is called in the install rule [17:14] ah, yes it is [17:15] dh_installmenu - didn't know about that one - it didn't show up when I ran dh_make [17:15] should that be in build rule or install? [17:16] I'm guessing install since it sounds like it installs the menu items [17:16] probably under binary-arch, with the bulk of the dh_ rules [17:17] There are 7 packages I have advocated on REVU, any MOTUs looking for low-hanging fruit with a dream of hitting Ubuntu HOF here's your chance!! [17:19] mok0: Hey. Next time you merge your branch with trunk note that you'll have to update the .htaccess file. [17:19] RainCT: OK [17:19] sven777: shouldn't "$(CURDIR)/src/85-logitech_music_anywhere.rules" be "$(CURDIR)/extras/85-logitech_music_anywhere.rules" [17:19] sven777: and it that file useful without the package installed? [17:19] RainCT: what was up with REVU about an hour ago it was all screwed up [17:20] stdin: no, the rules gets rewritten into the src dir [17:20] mok0: "all" or just the login? [17:20] stdin: no it's not, and it gets removed upon uninstallation [17:20] I couldn't log in, but I had a browser where I was logged in first, and it wouldn't let me post a comment === ssweeny_ is now known as ssweeny [17:21] Now it works fine [17:21] sven777: doesn't the Makefile install that? (or should it?) [17:22] it does but it wasn't being picked up by pbuilder [17:22] rather, it was causing a problem because it required root permission [17:23] mok0: I got ride of the ".py" extensions but OpenID could not handle that. About posting a comment, idk, it worked when I tried it. [17:23] so it wasn't being installed in $(DESTDIR) [17:24] stdin: yes you're right - I just put the /etc in there because it doesn't so any good to install it anywhere else [17:24] so=do [17:36] should I do a dput --force to the same package? [17:36] RainCT: It works now [17:36] sven777: yes, or delete the .upload file [17:38] mok0: last time I did a dput it registered in about a minute - it's taking much longer this time - still not seeing update - is that normal? [17:38] sven777: It depends on what time you upload, I think it runs every ten minutes [17:38] ahh ok thx [17:39] sven777: lmalinux? [17:39] yup [17:39] Did you see the comments I submitted ~20 minutes ago? [17:40] oop - no I didn't :) [17:40] reading now [17:40] mok0: I am also waiting for an upload to appear which I did about half an hour ago... [17:40] hefe_bia: what upload is that? [17:41] mok0: new uploads are processed every 3 minutes iirc [17:41] RainCT: aha! [17:42] mok0: tomboy-blogposter [17:42] uhm.. uploads/ is clean [17:42] But I just did a new one anyways since I read in your comment to sven777 that it is indeed preferred to use the new copyright format [17:43] RainCT: Not quite. [17:43] hefe_bia: there's a new upload just now [17:43] jpds: 10 seconds ago it was ;) [17:44] spooky's clock is ahead of time ~3 minutes [17:45] RainCT: apt-get install ntpd pls. [17:45] mok0, http://revu.ubuntuwire.com/p/audacious-skins [17:45] * hefe_bia notices the URL format for REVU packages has changed - nice ;) [17:46] :) [17:46] still no update for the first upload I did about 10 mins ago - just did another a couple mins ago [17:46] oh I see.. some scripts are br0ken [17:46] would it be better to remove the upload file and try again instead of doing --force ? [17:47] jpds: doesn't exist [17:47] sven777: it amounts to the same thing [17:47] jpds: aptitude suggests cyrus-nntpd-2.2 cyrus22-nntpd cyrus21-nntpd ntpdate openntpd [17:47] RainCT: Just ntp then. [17:47] jpds: OK, done [17:47] Uhm.. How can I change the python path for all files in a directory? [17:48] If memory serves me well in __init__.py [17:49] RainCT: python path... explain a bit more [17:49] the scripts need to search somewhere special for modules? [17:51] surfaz: well, if you have all the urls of where to get the various tarballs, it should be possible to make the watch file [17:51] Ah no, __init__.py is only for modules. So if the files are just a collection of scripts that won't work [17:52] RainCT: did I read you correctly earlier? do you have a real-time view of the revu uploads directory? [17:52] sven777: Yes. Wait a moment until uploading again, I've just seen some scripts are broken - sorry [17:53] RainCT: sys.path.insert(1, '/whererever/it/is') [17:53] mok0, all?? :( [17:53] mok0: but then I have to touch all files [17:53] surfaz: if you have them, yes [17:53] rainct: oh ok didn't realize your comment about broken scripts was about revu. thx :) [17:53] RainCT: you can also set the PYTHONPATH [17:54] mok0: Is it possible to set it only for a certain dir? [17:54] you mean something like a .htaccess file? [17:54] mok0: yes, but for those scripts which aren't run through mod_python [17:54] mok0, I don't have all [17:55] surfaz: ok n/m then [17:55] mok0, original xmms-skins package hasn’t a watch file. [17:55] RainCT: How are they run? Maybe you can set the environment variable via apache? [17:55] RainCT: write a shell script that inserts something like this in each of the files: [17:56] import sys [17:56] pydir = "/usr/directory/foo" [17:56]