[00:00] <Laney> I think "V7  This is the recommended mode of operation." confuses it a bit
[00:04] <nhandler> Laney: It also doesn't help that dh_make defaults to 7 iirc
[00:05] <nhandler> cody-somerville: What about for a package that uses debhelper v7 features in debian/rules but doesn't need to?
[00:05] <Laney> I'm not sure I see the problem any more
[00:05] <Laney> hardy-backports has dh7, and backporting to anything beyond that is probably pretty rare
[00:06] <cody-somerville> 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] <Laney>        Unless otherwise indicated, all debhelper documentation assumes that you are using the most recent
[00:06] <Laney>        compatibility level, and in most cases does not indicate if the behavior is different in an earlier
[00:06] <Laney>        compatibility level
[00:07] <nhandler> 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] <nhandler> One last question, does the perl artistic license require a copy to be distributed in the source?
[00:09] <Laney> Don't all licenses?
[00:09] <Laney> linking to it is pretty dubious IMO
[00:14] <Zetto> 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] <Zetto> (update it in Ubuntu+1 )
[00:15] <cody-somerville> Zetto, ugh... Feature Freeze has *not* passed.
[00:15] <Zetto> ops
[00:15] <cody-somerville> :)
[00:15] <Zetto> yep
[00:15] <Zetto> :P
[00:15] <cody-somerville> So lets get Netbeans uploaded!! woot!
[00:16] <Zetto> February 19th didn't passed :P
[00:16] <Zetto> cody-somerville, how we can doo it ?
[00:16] <ScottK> nhandler: Specifying a higher version dependency than is required is a poor packaging practice.
[00:16] <ScottK> It complicates backports substantially.
[00:16] <ScottK> And it's just not correct.
[00:16] <cody-somerville> Zetto, you prepare an upload of the new version and then you upload it
[00:17] <nhandler> scottk: Just out of curiosity, how does it complicate the backport process since debhelper has been backported?
[00:17] <ScottK> Generally speaking with debhelper it's pretty clear in debiah/changelog when stuff appeared.
[00:17] <ScottK> To hardy yes, but we still support dapper and gutsy.
[00:18] <Zetto> cody-somerville, on the Bug report, Yulia already make packages on yours PPA
[00:18] <cody-somerville> 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] <cody-somerville> Zetto, Then I recommend you ask someone to sponsor the upload
[00:18] <ScottK> In that case the dependency is fine.
[00:18] <Zetto> cody-somerville, thanks
[00:18] <ScottK> If they actually use dh 7 features, the dependency is correct.
[00:19] <nhandler> scottk: Even though there is no reason for the package to use the debhelper v7 features?
[00:19] <cody-somerville> nhandler, maybe more context would be useful
[00:19] <ScottK> nhandler: Packages don't need to use debhelper at all.
[00:19] <ScottK> The point of debhelper is to make life easier.
[00:19] <ScottK> If the packager likes using a particular feature, then that's fine.
[00:20] <nhandler> scottk: Ok. And do you know whether the perl artistic license requires a full copy to be distributed in the source?
[00:20] <ScottK> I was arguing (apparently on a one sided basis) against arbitrarily selecting the current version as the required version.
[00:21] <ScottK> nhandler: Ubuntu requires a full copy of the license in the source.
[00:21] <ScottK> 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] <nhandler> I didn't know that. Thanks scottk
[00:22] <ScottK> Mithrandir rejected my very first package due to that.
[00:37] <Zetto> 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] <Zetto> *to update
[00:41] <ScottK> Zetto: File a bug with the diffs and subscribe ubuntu-universe-sponsors.  Who your employer is isn't really a consideration.
[00:41] <Zetto> ScottK, thanks, a will subscribe
[00:44] <Zetto> 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] <ScottK> Triaged or confirmed.
[00:47] <ScottK> In progress is when a sponsor is looking at it.
[00:52] <Zetto> ScottK, thanks, i will change all they to Triaged
[00:53] <ScottK> You're welcome.
[00:53] <Zetto> ScottK, Triaged isn't in the list ^^
[00:53] <ScottK> Then confirmed
[00:53] <Zetto> ScottK, do you know why ?
[00:53] <Zetto> ScottK, ok
[00:53] <ScottK> Yes, it's a restricted status.  Not everyone can set it.
[00:53] <ScottK> That's why I said confirmed or triaged.
[00:54] <ScottK> Triaged is an interesting theory, but the restriction on it's use makes it pretty useless for workflow bugs.
[00:54] <Zetto> ScottK, can you change to Triaged or Upload the files ?
[00:54] <Zetto> hummm
[00:54] <ScottK> I could, but I'm busy with other things currently
[00:55] <Zetto> ScottK, ok, can i ask you again in one hour ?
[00:55] <ScottK> You can ask, but I find repeated requests demotivating.
[00:56] <ScottK> I recommend against it.
[00:56] <Zetto> ok
[02:48] <Zetto> ScottK, are you busy ?
[02:48] <ScottK> yes.
[02:49] <Zetto> good work, i will Sleep now
[02:49] <Zetto> bye all
[13:21] <quadrispro> hi pochu
[13:30] <savvas> would a correct conf be at /etc/udev/libmtp8.rules or /etc/udev/rules.d/45-libmtp8.rules ?
[13:44] <quadrispro> could anyone review this? http://revu.ubuntuwire.com/details.py?package=gnome-format
[14:20] <pochu> hi quadrispro
[14:20] <pochu> I'm reviewing gnome-format
[14:21] <pochu> quadrispro: so we are finally using the orig tarball, aren't we?
[14:21] <quadrispro> thank you pochu
[14:21] <pochu> in the get-orig-source, there's no need to untar the tarball
[14:22] <pochu> it should be enough to just `bunzip && gzip -9`
[14:22] <pochu> (and that's better, since the .tar checksum won't change)
[14:23] <quadrispro> pochu: yes, you're right, I'm workin on it
[14:23] <pochu> quadrispro: and a couple more comments
[14:23] <pochu> in the manpage, remove [OPTIONS...], since there is no [OPTIONS] section
[14:23] <quadrispro> ok
[14:24] <pochu> and in the long description, this looks a bit weird:
[14:24] <pochu> It is designed for Linux based operating systems, like Ubuntu, and for the GNOME desktop.
[14:24] <pochu> I'd remove Linux and Ubuntu from there
[14:25] <pochu> it's ok if you want to mention that it integrates well with GNOME though
[14:25] <pochu> 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] <quadrispro> pochu: http://paste.ubuntu.com/115218/
[14:28] <Laney> gzip -9nf, rather
[14:29] <pochu> quadrispro: looks fine
[14:29] <pochu> quadrispro: you can view it using `man ./gnome-format.1`
[14:30] <quadrispro> I know :)
[14:30] <pochu> ok :)
[14:31] <quadrispro> man -l filename.1, precisely
[14:31] <pochu> Laney: -f looks useless for a .tar
[14:32] <Laney> yeah, n is more important
[14:36] <pochu> quadrispro: did you use two spaces in the list of actions in the long description on purpose?
[14:36] <pochu> s/actions/features/
[14:36] <pochu> quadrispro: if so, good :)
[14:36] <DktrKranz> is svn.debian.org working for you? I can't checkout branches with my ssh key :(
[14:38] <quadrispro> pochu: 2 spaces?? where?
[14:38] <pochu> DktrKranz: I can update my checkouts fine
[14:39] <pochu> quadrispro:
[14:39] <pochu>  Features:
[14:39] <pochu>   - Easy to use.
[14:39] <pochu>   - Autodetects available media through HAL.
[14:39] <pochu> there are two spaces before the dashes
[14:39] <DktrKranz> pochu, which string do you use? Probably it's a failure by my side
[14:39] <pochu> svn co :)
[14:39] <quadrispro> yes, there are 2 spaces, is it right?
[14:39] <pochu> quadrispro: yeah, it's perfect
[14:39] <pochu> quadrispro: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480322
[14:40] <pochu> DktrKranz: IIRC my initial checkout was like "svn co svn+ssh://svn.debian.org/svn/foo"
[14:40] <pochu> DktrKranz: with this in my .ssh/config:
[14:40] <pochu> Host svn.debian.org User pochu-guest
[14:41] <pochu> in two lines
[14:41] <pochu> Host svn.debian.org
[14:41] <DktrKranz> same here
[14:41] <pochu>     User pochu-guest
[14:41] <pochu> DktrKranz: give me an URI and I'll try
[14:41] <DktrKranz> with s/pochu/dktrkranz/, of course :)
[14:41] <pochu> heh
[14:41] <pochu> I hope :)
[14:41] <DktrKranz> svn+ssh://svn.debian.org/svn/python-apps/packages/bleachbit
[14:41] <quadrispro> pochu: uploaded to REVU
[14:42] <pochu> DktrKranz: works fine
[14:42] <pochu> quadrispro: ok, I'm going to upload it to the archive if your changes look fine
[14:42] <DktrKranz> gah!
[14:43] <DktrKranz> no way here...
[14:45] <quadrispro> pochu: REVU doesn't want to work
[14:46] <pochu> DktrKranz: can you checkout without ssh?
[14:46] <DktrKranz> yes
[14:46] <pochu> DktrKranz: there's #alioth on OFTC, btw
[14:46] <DktrKranz> but no write access
[14:46] <quadrispro> bah, anyway I've uploaded gnome-format to my server -> http://home.alessiotreglia.com/jaunty/result/gnome-format_0.1.1-0ubuntu1/
[14:46] <pochu> DktrKranz: is your key in alioth.debian.org? :)
[14:46] <DktrKranz> yes
[14:46] <DktrKranz> I did some commits already, but today it doesn't work at all
[14:47] <pochu> no idea then
[14:47] <DktrKranz> mmmh... let's try to connect to our build server
[14:47] <DktrKranz> it uses ssh as login method
[14:47] <DktrKranz> mmmh... no access!
[14:47] <DktrKranz> so, it's seahorse!
[14:47] <pochu> DktrKranz: how long have you been without using it?
[14:48] <surfaz> ScottK, any news about this?
[14:48] <surfaz> https://bugs.launchpad.net/ubuntu/hardy/+source/amule/+bug/244670
[14:48] <pochu> the keys were removed due to the ssh disaster ;)
[14:48] <DktrKranz> pochu, my key is old enought to be immune of SSH crisis ;)
[14:48] <DktrKranz> enywat, latest commit is about two weeks ago
[14:48] <DktrKranz> *anyway
[14:50] <pochu> DktrKranz: maybe ask in #alioth
[14:51] <DktrKranz> \o/ I GOT IT! seahorse crashed and no longer managed my keys!
[14:51] <DktrKranz> now, let's see if commit was successful
[14:51] <quadrispro> I'm experiencing issues with REVU... mmm
[14:51] <pochu> quadrispro: get-orig-source fails here
[14:51] <pochu> with the package from your server
[14:52] <pochu> bunzip2 ../gnome-format-.tar.bz2
[14:52] <pochu> bunzip2: ../gnome-format-.tar.bz2 is not a bzip2 file.
[14:52] <pochu> make: *** [get-orig-source] Error 2
[14:52] <DktrKranz> it works, pochu sorry for the noise, it was my seahorse which crashed
[14:52] <quadrispro> pochu: type uscan --dehs
[14:52] <pochu> DktrKranz: np
[14:52] <pochu> emilio@saturno:~/tmp/gnome-format-0.1.1$ uscan --dehs

uscan: Can't use --verbose if you're using --dehs!</errors>

[14:53] <pochu> quadrispro: I'm on Debian btw
[14:53] <pochu> oh
[14:53] <pochu> wait
[14:53] <pochu> USCAN_VERBOSE=yes
[14:53] <pochu> that's on my .devscripts :)
[14:54] <quadrispro> ok
[14:54] <pochu> quadrispro: why do you need --dehs, btw?
[14:55] <quadrispro> pochu: it's necessary to retrieve the last available version from upstream
[14:55] <pochu> ok
[14:55] <maxb> --dehs just changes the output format, I thought?
[14:56] <pochu> maxb: yes, but then it's easier to parse it I guess
[14:56] <pochu> quadrispro: ok, works now without --verbose
[14:56] <quadrispro> yeah
[14:59] <maxb> Is get-orig-source really allowed to cd ?
[14:59] <pochu> quadrispro: if you run get-orig-source, do you get this md5sum?
[14:59] <pochu> f6cf5689480fc9cbe6da344175083b08  gnome-format_0.1.1.orig.tar.gz
[15:00] <pochu> maxb: why not?
[15:01] <quadrispro> pochu: one moment
[15:02] <quadrispro> pochu: yes
[15:03] <pochu> ok, I'm uploading with that tarball then
[15:03] <quadrispro> alessio@quadrispro-desktop:~/Desktop/devel/REVU/gnome-format$ md5sum gnome-format_0.1.1.orig.tar.gz
[15:03] <quadrispro> f6cf5689480fc9cbe6da344175083b08  gnome-format_0.1.1.orig.tar.gz
[15:04] <quadrispro> pochu: thank you very much :)
[15:04] <pochu> quadrispro: thanks for packaging it :)
[15:04] <POX> DktrKranz: FYI: sed accepts multiple "-e"'s
[15:09] <quadrispro> pochu: do you have some minutes for this? https://bugs.launchpad.net/bugs/325882
[15:10] <pochu> quadrispro: Successfully uploaded packages.
[15:10] <pochu> quadrispro: uploaded ;)
[15:10] <DktrKranz> POX, yes, I used multiple instances just for "cosmetic" purposes
[15:11] <POX> ok then
[15:11] <quadrispro> thank you pochu
[15:11] <pochu> RainCT: hey, there seems to be some problems with REVU
[15:12] <pochu> RainCT: quadrispro can't upload his package, and I can't login...
[15:12] <pochu> RainCT: El servidor «revu.ubuntuwire.com» está redireccionando de una manera que nunca terminará.
[15:12] <pochu> RainCT: I can access REVU, but when trying to login and clicking on "sign in" in Launchpad, I get that
[15:12] <quadrispro> pochu: ehm.. did you upload installation-report-generator too?
[15:12] <DktrKranz> 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] <pochu> quadrispro: nope
[15:12] <quadrispro> ah ok ok :)
[15:13] <POX> DktrKranz: well, I'd recommed to wait with an upload and ping me right after old one will be accepted
[15:13] <DktrKranz> I'll do that, thanks :)
[15:14] <pochu> DktrKranz: otherwise your package will fall to the bottom of the queue again ;)
[15:14]  * pochu is already 5th
[15:14] <pochu> pity that they don't process it top-bottom ;)
[15:14] <DktrKranz> > 200 packages \o/
[15:15]  * DktrKranz can't wait for valentine's day!
[15:15] <pochu> :)
[15:16] <pochu> quadrispro: let me know when REVU works again and I'll add a comment and archive the package ;)
[15:18] <Laney> What version number is best to use for something that doesn't (hasn't yet) do releases? 0.darcsDDMMYYYY?
[15:20] <pochu> Laney: 0~foo, I'd say
[15:20] <Laney> 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] <Laney> LICENSE file, that is
[15:21] <pochu> Laney: otherwise, if the first public release is 0.X you will be in trouble ;)
[15:21] <pochu> true
[15:21] <pochu> dpkg --compare-versions "0.darcs" gt "0.0.1" && echo true
[15:22] <pochu> Laney: I think LICENSE is fine, but header in source files is encouraged
[15:22] <Laney> fair, I got the idea from ffmpeg-debian
[15:22] <pochu> not sure if you will get a reject for that
[15:23] <pochu> Laney: they probably use 0.svn before ~ was created
[15:23] <Laney> I'm never going to convince upstream to go back and add headers to all of their files
[15:23] <Laney> so hmm
[15:24] <pochu> hmm, they don't :)
[15:24] <pochu> ffmpeg (0.cvs20040716-1) unstable; urgency=low
[15:24] <pochu>   * Initial release (Closes: #199266).
[15:24] <pochu>  -- Sam Hocevar (Debian packages) <sam+deb@zoy.org>  Fri, 16 Jul 2004 12:47:27 +0200
[15:24] <pochu> but dpkg supports ~ since 2003
[15:24] <pochu> anyway, ~ is better, otherwise you're screwed
[15:24] <Laney> sure
[15:24] <pochu> Laney: what package is it, btw?
[15:24] <Laney> agda
[15:25] <Laney> http://wiki.portal.chalmers.se/agda/agda.php?n=Main.HomePage
[15:25] <pochu> Agda is a dependently typed functional programming language.
[15:25] <pochu> that one?
[15:25] <Laney> correct
[15:35] <tobor> 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] <ScottK> surfaz: I have no idea.  I'm not in motu-sru, so it's totally  not up to me.
[15:38] <tobor> Regarding the issue of updating packages to more current versions, is there a process I can read about somewhere?
[15:39] <surfaz> 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] <savvas> 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:46] <ScottK> surfaz: I was involved in getting the initial updates in, but for the previous releases, no idea.
[15:48] <misblay> hi!
[15:48] <misblay> 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] <ScottK> Knowing shell scripting (at least a little) is good.
[15:49] <ScottK> If you have programming skills they can be helpful, but they are not required.
[15:50] <misblay> i have stuided PHP for couple of months
[15:50] <misblay> but i dont think
[15:50] <misblay> that will help :D
[15:53] <misblay> thanks anyway, i'll check the documentation
[15:59] <skorasaurus> !gettingstarted
[16:00] <skorasaurus> ScottK, that getting started doc is being revised.
[16:00] <skorasaurus> too
[16:01] <hefe_bia> 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] <hefe_bia> 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] <RainCT> pochu: Hey. With which pages do you have that error?
[16:19] <pochu> RainCT: with http://revu.ubuntuwire.com/details?package=gnome-format
[16:19] <pochu> it still happens
[16:20] <pochu> RainCT: the url redirected from Launchpad is this:
[16:20] <pochu> 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] <pochu> sorry! :(
[16:20] <RainCT> pochu: ah, but only login fails?
[16:20] <pochu> RainCT: yeah
[16:20] <pochu> I can view the page fine
[16:20] <RainCT> err right, now I know why I had some mod_rewrite lines commented out :P
[16:21] <pochu> heh
[16:22] <RainCT>  
[16:23] <RainCT> Fixed
[16:23] <pochu> RainCT: ty
[16:23] <RainCT> err. or not
[16:25] <RainCT> pochu: well, commented that out again :P. Should work now
[16:26] <pochu> RainCT: right, worked now, thanks!
[16:44] <sven777> would a MOTU be so kind as to review my package?  Thanks in advance!  http://revu.ubuntuwire.com/details.py?package=lmalinux
[16:55] <hefe_bia> 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] <sven777> hefe - oh ok thanks v. much - I shall change that right now :)
[16:59] <sven777> even if there is a new upstream release?
[16:59] <hefe_bia> sven777: AFAIK yes. I had a similar case with one of my packages.
[17:00] <sven777> hefe_bia: ok thanks again - you wouldn't happen to know of any other "gotchas" like that would you?
[17:01] <hefe_bia> sven777: Might also be better to remove the debian/ dir from the .orig,tar.gz, so you keep packaging separate.
[17:01] <hefe_bia> Because now your .diff.gz is empty.
[17:03] <hefe_bia> For example the debian/ dir would be different if the package was adopted for Debian.
[17:04] <savvas> hrm.. what happened with firefox 3.0.6?
[17:05] <sven777> hefe_bia: is that a problem though?
[17:05] <sven777> it's just going to result in a diff.gz anyway
[17:06] <stdin> sven777: you should avoid modifying the orig.tar.gz at all, that's why we have the .diff
[17:06] <hefe_bia> stdin: He's also upstream
[17:06] <sven777> ya :)
[17:06] <stdin> and what if debian want it?
[17:06] <stdin> just keep the orig.tar.gz for the raw package
[17:07] <sven777> wouldn't they just change some things in the debian dir and that results in a diff anyway?
[17:07] <stdin> no, they's need to modify the orig.tar.gz
[17:07] <pochu> sven777: the debian/ should be in a diff.gz
[17:07] <sven777> ok, I shall remove it
[17:07] <pochu> stdin: not really, but it's still weird
[17:08] <sven777> it's obviously a point of contention, whatever the case - so I'll stick to something more normal
[17:08] <sven777> thx for the help
[17:08] <stdin> 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] <stdin> ie: "[ Sven Carlberg ]" is not needed
[17:09] <sven777> stdin - I just noticed some other changelogs and thought it was a more "proper" format
[17:09] <hefe_bia> 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] <RainCT> sven777:   [ .. ]  is only for when several people do something to that revision
[17:09] <stdin> sven777: it's used when more than one person commits changes, to attribute credit
[17:09] <sven777> ok got it, thx
[17:11] <stdin> do you really need debhelper (>= 7) ?
[17:11] <sven777> I was just following a template
[17:13] <stdin> also, you have a debian/dirs, but don't call dh_installdirs
[17:13] <stdin> or dh_installmenu
[17:14] <sven777> dh_installdirs is called in the install rule
[17:14] <stdin> ah, yes it is
[17:15] <sven777> dh_installmenu - didn't know about that one - it didn't show up when I ran dh_make
[17:15] <sven777> should that be in build rule or install?
[17:16] <sven777> I'm guessing install since it sounds like it installs the menu items
[17:16] <stdin> probably under binary-arch, with the bulk of the dh_ rules
[17:17] <mok0> 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] <RainCT> mok0: Hey. Next time you merge your branch with trunk note that you'll have to update the .htaccess file.
[17:19] <mok0> RainCT: OK
[17:19] <stdin> sven777: shouldn't "$(CURDIR)/src/85-logitech_music_anywhere.rules" be "$(CURDIR)/extras/85-logitech_music_anywhere.rules"
[17:19] <stdin> sven777: and it that file useful without the package installed?
[17:19] <mok0> RainCT: what was up with REVU about an hour ago it was all screwed up
[17:20] <sven777> stdin: no, the rules gets rewritten into the src dir
[17:20] <RainCT> mok0: "all" or just the login?
[17:20] <sven777> stdin: no it's not, and it gets removed upon uninstallation
[17:20] <mok0> 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
[17:21] <mok0> Now it works fine
[17:21] <stdin> sven777: doesn't the Makefile install that? (or should it?)
[17:22] <sven777> it does but it wasn't being picked up by pbuilder
[17:22] <sven777> rather, it was causing a problem because it required root permission
[17:23] <RainCT> 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] <stdin> so it wasn't being installed in $(DESTDIR)
[17:24] <sven777> 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] <sven777> so=do
[17:36] <sven777> should I do a dput --force to the same package?
[17:36] <mok0> RainCT: It works now
[17:36] <mok0> sven777: yes, or delete the .upload file
[17:38] <sven777> 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] <mok0> sven777: It depends on what time you upload, I think it runs every ten minutes
[17:38] <sven777> ahh ok thx
[17:39] <mok0> sven777: lmalinux?
[17:39] <sven777> yup
[17:39] <mok0> Did you see the comments I submitted ~20 minutes ago?
[17:40] <sven777> oop - no I didn't :)
[17:40] <sven777> reading now
[17:40] <hefe_bia> mok0: I am also waiting for an upload to appear which I did about half an hour ago...
[17:40] <mok0> hefe_bia: what upload is that?
[17:41] <RainCT> mok0: new uploads are processed every  3 minutes iirc
[17:41] <mok0> RainCT: aha!
[17:42] <hefe_bia> mok0: tomboy-blogposter
[17:42] <RainCT> uhm.. uploads/ is clean
[17:42] <hefe_bia> 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] <jpds> RainCT: Not quite.
[17:43] <mok0> hefe_bia: there's a new upload just now
[17:43] <RainCT> jpds: 10 seconds ago it was ;)
[17:44] <mok0> spooky's clock is ahead of time ~3 minutes
[17:45] <jpds> RainCT: apt-get install ntpd pls.
[17:45] <surfaz> mok0, http://revu.ubuntuwire.com/p/audacious-skins
[17:45]  * hefe_bia notices the URL format for REVU packages has changed - nice ;)
[17:46] <RainCT> :)
[17:46] <sven777> still no update for the first upload I did about 10 mins ago - just did another a couple mins ago
[17:46] <RainCT> oh I see.. some scripts are br0ken
[17:46] <sven777> would it be better to remove the upload file and try again instead of doing --force ?
[17:47] <RainCT> jpds: doesn't exist
[17:47] <mok0> sven777: it amounts to the same thing
[17:47] <RainCT> jpds: aptitude suggests  cyrus-nntpd-2.2 cyrus22-nntpd cyrus21-nntpd ntpdate openntpd
[17:47] <jpds> RainCT: Just ntp then.
[17:47] <RainCT> jpds: OK, done
[17:47] <RainCT> Uhm.. How can I change the python path for all files in a directory?
[17:48] <hefe_bia> If memory serves me well in __init__.py
[17:49] <mok0> RainCT: python path... explain a bit more
[17:49] <mok0> the scripts need to search somewhere special for modules?
[17:51] <mok0> 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] <hefe_bia> Ah no, __init__.py is only for modules. So if the files are just a collection of scripts that won't work
[17:52] <sven777> RainCT: did I read you correctly earlier?  do you have a real-time view of the revu uploads directory?
[17:52] <RainCT> sven777: Yes. Wait a moment until uploading again, I've just seen some scripts are broken - sorry
[17:53] <mok0> RainCT:  sys.path.insert(1, '/whererever/it/is')
[17:53] <surfaz> mok0, all?? :(
[17:53] <RainCT> mok0: but then I have to touch all files
[17:53] <mok0> surfaz: if you have them, yes
[17:53] <sven777> rainct: oh ok didn't realize your comment about broken scripts was about revu.  thx :)
[17:53] <mok0> RainCT: you can also set the PYTHONPATH
[17:54] <RainCT> mok0: Is it possible to set it only for a certain dir?
[17:54] <mok0> you mean something like a .htaccess file?
[17:54] <RainCT> mok0: yes, but for those scripts which aren't run through mod_python
[17:54] <surfaz> mok0, I don't have all
[17:55] <mok0> surfaz: ok n/m then
[17:55] <surfaz> mok0, original xmms-skins package hasn’t a watch file.
[17:55] <hefe_bia> RainCT: How are they run? Maybe you can set the environment variable via apache?
[17:55] <mok0> RainCT: write a shell script that inserts something like this in each of the files:
[17:56] <mok0> import sys
[17:56] <mok0> pydir = "/usr/directory/foo"
[17:56] <mok0> if not pydir in sys.path:
[17:56] <mok0>     sys.path.insert(1,pydir)
[17:56] <mok0> RainCT: which files are they? I can do some of them
[17:57] <mok0> RainCT: even better, write the above in a module and import it
[17:57] <RainCT> nvm, done. I've added   sys.path.append('../includes')   to all relevant files
[17:57] <mok0> RainCT: It's the prettiest way IMO
[17:58] <hefe_bia> RainCT: .pth files can also be used for such things.
[17:58] <RainCT> some of the files in scripts/ need other files which I moved into includes/.. and this didn't fail before because there were still some .pyc files lying around in scripts/
[17:58] <mok0> hefe_bia: yes!
[17:58] <mok0> RainCT: ah, yes a classic
[17:59] <RainCT> sven777: please try uploading it again now
[17:59] <sven777> done
[17:59] <mok0> RainCT: ... and you wonder wft your changes aren't taking effect :-)
[17:59] <RainCT> hehe
[17:59] <sven777> mod_python error on lmalinux package page now
[18:00] <sven777>   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch
[18:00] <sven777>     default=default_handler, arg=req, silent=hlist.silent
[18:00] <mok0> RainCT: it can't find the config file
[18:01] <RainCT> right, some files were missing  "import sys"..
[18:01]  * RainCT hides :$
[18:01]  * mok0 admires RainCT for his bravery
[18:02] <RainCT> err no, but that's just 1 file
[18:02] <mok0> surfaz: but plz document everything in copyright
[18:03] <mok0> surfaz: we need to know where the tarballs come from
[18:03]  * RainCT doesn't understand anything now XD
[18:03] <surfaz> RainCT, revu crashed!!
[18:04] <mok0> RainCT: shut down revu's apache
[18:04] <surfaz> RainCT, http://pastebin.com/m5c3b8d1e
[18:04] <RainCT> mok0: why?
[18:04] <mok0> surfaz: yeah, we know
[18:05] <mok0> RainCT: oh, just so people don't get this python errors... until its fixed
[18:05] <RainCT> but I need it to debug :P
[18:05] <mok0> ah... yes ;-)
[18:05] <surfaz> mok0, I moved all *.README files to Credits folder.
[18:05] <RainCT> on localhost everything works, that's the weirdest of all
[18:06] <mok0> surfaz: ok, I'll take a look later
[18:09] <hefe_bia> mok0: Btw, I like your proposal for an updated REVU workflow. One of the most frustrating things with the current workflow is getting a "needs work" on a previously advocated package.
[18:14] <RainCT> meh.. it's the "wth am I?" detection that is failing again.. why can't there be a decent way to find out the location of the file being run? -.-
[18:14] <RainCT> (REVU is up again)
[18:15] <sven777> rainct: I uploaded
[18:19] <sven777> rainct: crash again
[18:19] <sven777> ImportError: No module named config
[18:19] <sven777> File "/srv/revu-production/details.py", line 36, in <module>
[18:19] <sven777>     from config import config, connection
[18:29] <mok0> hefe_bia: the new workflow should solve that problem
[18:30] <RainCT> grr
[18:30] <RainCT> adding '../includes' doesn't work as it is relative to the current working directory
[18:30] <hefe_bia> RainCT: revu pages work again now. Not sure whether it does collect new uploads.
[18:33] <mrooney> anyone know a package that uses dh_installman? I have a cdbs package and I am trying to figure out how to install my manpage
[18:33] <RainCT> sven777:  your upload is up now
[18:34] <RainCT> I've added some symlinks so that the scripts work until I can figure out a proper solution
[18:37] <sven777> rainct: thx much
[18:37] <hefe_bia> RainCT: Maybe sys.path.append(path.join(path.dirname(__FILE__), '../includes')) ?
[18:37] <RainCT> uhm yes, that should work
[18:37]  * RainCT tries
[18:39] <hefe_bia> I think its __file__, not __FILE__ (sorry)
[18:39]  * RainCT thinks __FILE__ is right :P
[18:40] <hefe_bia> ok ;)
[18:41] <surfaz> Somebody could look this?
[18:41] <surfaz> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280/comments/10
[18:41] <sven777> "This package could not be extracted; there's no browseable directory for it on REVU. "
[18:42] <sven777> there it goes
[18:43] <RainCT> sven777: how long did it take to uncompress the tarball?
[18:44] <sven777> it gave me an error on the package page at first - I refreshed a couple mins later and it had done it
[18:45] <sven777> the "legal" link on the revu page - those are all the licensing issues that need to be fixed?
[18:45] <surfaz> I think they should upgrade the GParted to version 0.4.2 because this version incorporate support for ext4. Which brings Ubuntu 9.04. I think this error should not qualify as Wishlist
[18:46] <RainCT> sven777: That just tries to find out the license of all files. But yeas, in thise case what it lists should be fixed if you can
[18:46] <RainCT> (ie, changing the FSF address to the new one and adding copyright to the files where it is missing)
[18:47] <sven777> gettext.h is not my file and it is LGPL - is there something I should do about that?
[18:48] <RainCT> hefe_bia: but of course that doesn't work, as __FILE__ is not defined for imported files
[18:49] <RainCT> sven777: that one is fine
[18:49] <sven777> rainct: ok thx
[18:50] <sven777> 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA is the correct address?
[18:50] <RainCT> sven777: I think so. Check /usr/share/licenses/GPL to be sure
[18:50] <RainCT> * common-licenses
[18:52] <nhandler> That looks correct
[18:53] <nhandler> I remember it because the first letters of Franklin Street, Fifth spell FSF (unlike the old address)
[18:53] <sven777> ok thx
[18:56] <sven777> getting that "Warning! This package could not be extracted; there's no browseable directory for it on REVU. " again
[18:56] <sven777> went away right away that time
[18:57] <RainCT> perhaps I should change the script to uncompress the directory first and then show it on the page?
[18:57] <sven777> the legal link - that just lists the legal info for all relevant files?  it doesn't necessarily mean they're incorrect in some way?
[18:58] <RainCT> sven777: right
[18:58] <sven777> ok thanks
[18:59] <RainCT> hefe_bia: err. it is __file__ indeed :P
[19:01] <sven777> ok all those changes everyone ( mok0 hefe_bia stdin rainct pochu ) helped me with are applied - thanks much for all your help!
[19:15] <mrooney> is there another way I should installed manpages with cdbs other than dh_installman?
[19:15] <RainCT> mrooney: debian/<package>.manpages
[19:15] <mrooney> RainCT: does that just automagically install them?
[19:16] <mrooney> I've seen that before but wasn't sure how it worked
[19:16] <RainCT> mrooney: yep
[19:16] <mrooney> RainCT: excellent, thanks!
[19:16] <RainCT> mrooney: CDBS calls dh_installman, and dh_installman looks for debian/*.manpages files to install whatever is listed there
[19:17] <RainCT> yw
[19:20] <RainCT> Does anyone have something to upload? I want to try removing the symlinks
[19:24] <surfaz> something to upload? where?
[19:24] <RainCT> to revu
[19:25] <RainCT> let me reformulate, *If someone is about to upload something to REVU, please tell me before so that I can check something.
[19:26] <hyperair> RainCT: what symlinks
[19:27] <RainCT> hyperair: a workaround I did before figuring out why something was failing :)
[19:27] <hyperair> hm
[19:33] <hefe_bia> RainCT: yes, my package for tomboy-blogposter still did not get recognized
[19:33] <hefe_bia> Should I upload again?
[19:33] <RainCT> hefe_bia: no, I think I can recover it
[19:40] <RainCT> hefe_bia: Still needs the symlink :/. Anyway, your upload is up now
[19:41] <hefe_bia> RainCT: Thanks. Just got the mail notification
[19:43] <RainCT> Uhm.. The activity graphic (that's new! :)) for tomboy-blogposter is nice :)
[19:50] <henrik-hw0> rainct: the vertical lines are those for decoration? could be nice to put them at release or featurefreeze dates.
[19:51] <RainCT> henrik-hw0: they are automatically placed there were there's a month written
[19:52] <RainCT> FF could be added, but it would only be visible once it has already started (as only the active period of time is displayed in the chart)
[19:57] <RainCT> (advocations are also displayed now)
[20:11] <henrik-hw0> rainct: ps. it renders wrong on package libmirage.
[20:24] <surfaz> Somebody could look this?
[20:24] <surfaz> https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/305280/comments/10
[20:24] <surfaz> I think they should upgrade the GParted to version 0.4.2 because this version incorporate support for ext4. Which brings Ubuntu 9.04. I think this error should not qualify as Wishlist
[20:30] <loic-m> surfaz: if your diff.gz is good, you just need to put the Status to confirmed and unassign yourself (leave it empty) and a developer from u-s-m should pick it up and upload it (takes a few days to 2 weeks afaik)
[20:31] <surfaz> ok, thanks
[20:35] <loic-m> surfaz: check the Assigned to field, and if no developer has noticed it in one week, try remind people again. However since it's gparted it should be taken care off easily (since it's important)
[20:37] <surfaz> No is there less than a week to freeze new versions?
[20:39] <loic-m> !schedule
[20:40] <loic-m> https://wiki.ubuntu.com/JauntyReleaseSchedule thankfully there's firefox Aaawesoome bar
[20:40] <loic-m> February 19th for FF, so still 12 days to go
[20:41] <loic-m> hope I put enough a in Aaawesoome, I can never remember how they spell it
[20:45] <surfaz> loic-m, thanks, but I don't know why we wait to the last minute...
[20:46] <loic-m> surfaz: we don't wait to the last minute, it's just that there's a lot of updates to process each day, so it can take time
[20:50] <loic-m> (as far as I understand)
[20:51] <surfaz> Not enough MOTUs?
[20:52] <loic-m> surfaz: gparted is in main, so MOTU don't have the upload rights for it anyway
[20:52] <surfaz> ahh, ok
[20:53] <savvas> loic-m: do you happen to know what's stalling 3.0.6? I heard about some vulnerabilities fixed that affect 3.0.5 and older versions
[20:55] <loic-m> savvas: I can't even start to figure what you're talking about ;)
[20:55] <savvas> woops, I meant firefox :P
[20:56] <loic-m> I'm not a motu, and firefox is in main. Somebody here might now the answer, but else you should ask in #ubuntu+1
[20:57] <loic-m> I must say Jaunty's Firefox is 3.0.6 though
[20:57] <savvas> I know: https://launchpad.net/ubuntu/+source/firefox-3.0
[20:58] <savvas> I guess it's going to arrive sooner or later
[21:58] <sven777> would a MOTU be so kind as to review my package? Thanks in advance! http://revu.ubuntuwire.com/details.py?package=lmalinux
[22:03] <RainCT> From Time Based Releases:  «Present: new features should, in general, be uploaded to the development branch well in advance of FeatureFreeze. It is important for Ubuntu features to be developed openly and visibly.»
[22:03] <RainCT> *cough*like that junk cleaner thing*cough*
[22:04] <Laney> har har
[22:08] <ScottK> RainCT: I gave that one an FFe and I figure not to do that one again.
[22:18]  * calc is bored in his hotel room, beating on OOo split build
[22:19] <calc> apparently i'm the last person leaving, heh
[22:42] <kolby> In a control file, how do I indicate the program will work for any archetecture?
[22:43] <kolby> I tried Architecture: any
[22:43] <RainCT> kolby: Architecture: all
[22:43] <kolby> thanks
[22:43] <RainCT> kolby: "any" builds the package for all architectures
[22:43] <RainCT> kolby: "all" builds it once and uses the same .deb for all
[22:43] <kolby> RainCT: thank you.
[22:44] <kolby> RainCT: When should I use "any"
[22:47] <kolby> I have the uninitialized $binaries being used in debconf file of lintian.
[22:47] <kolby> I wouldn't think that's my failt.
[22:47] <kolby> *fault
[22:58] <kolby> I got this error: binary-arch-rules-but-pkg-is-arch-indep
[22:59] <kolby> what should I do?
[22:59] <RainCT> kolby: are you packaging something written in python/ruby/perl/bash/etc. or something that must be compiled
[23:00] <kolby> something that must be compiled
[23:00] <RainCT> kolby: ah, then "any" was right
[23:00] <kolby> I'll use that and see what happens.  thanks
[23:00] <RainCT> that warning will go away then
[23:02] <kolby> what do I do if debuild tells me it cannot find my secret key?
[23:02] <RainCT> kolby: do you have a GPG key?
[23:02] <kolby> it attempts to sign my changes, then it tells me it can't find the secret key.
[23:02] <kolby> Yes.  I gave it my GPG key with the -k command
[23:03] <kolby> it worked that time for some reason.
[23:04] <RainCT> kolby: Ensure that the string in debian/changelog (after " --") matches that one of your secret key, then you won't need to specify it with -k
[23:04] <kolby> okay
[23:06] <kolby> how do I know which key it is, if it perfectly matches the names and email of two keys?
[23:06] <kolby> is there a gpg config file to edit or something?
[23:10]  * RainCT doesn't know, sorry
[23:11] <kolby> I think I found it
[23:12] <Laney> put DEBSIGN_KEYID in ~/.devscripts
[23:13] <kolby> Laney: okay
[23:14] <kolby> Laney: that file didn't exist before
[23:15] <_16aR_> Hello
[23:15] <RainCT> Hi _16aR_
[23:16] <kolby> I found a guide
[23:16] <kolby> it told me to add "export GPGKEY=YOUR-KEY-ID" to ~/.bashrc
[23:21] <_16aR_> The package fsniper needs 1 more advocate :) : http://revu.ubuntuwire.com/details.py?package=fsniper (daemon which launch a script on each file newly created or modified in a directory )
[23:21] <kolby> Laney: when I ran debuild, it gave me the following error/warning:
[23:21] <kolby> /home/et3/.devscripts: line 1: DEBSIGN_KEYID: command not found
[23:21] <kolby> Laney: I'll be deleting it now
[23:21] <Laney> laney@chicken:~$ cat /home/laney/.devscripts
[23:21] <Laney> DEBSIGN_KEYID="20BFCDC7"
[23:22] <hanska> kolby: be sure not to have spaces
[23:22] <hanska> i.e. DEBSIGN_KEYID = "foo" throws that error
[23:22] <hanska> while it *must* be DEBSIGN_KEYD="foo"
[23:22] <kolby> hanska: thank you
[23:23]  * kolby fixed devscript
[23:24] <kolby> I'm still getting the same error
[23:24] <hanska> kolby: grep DEBSIGN_KEYD ~/.devscripts  ?
[23:26] <kolby> if lintian returns nothing, does this mean no errors/warnings?
[23:27] <directhex> no news is good news
[23:27] <kolby> amazing.  I'm done.
[23:27] <kolby> ^^  I was working on the md4sum package
[23:29] <directhex> md4sum? o_o
[23:29]  * Laney wonders how broken that is
[23:30]  * directhex hands Laney a 300mhz ARM
[23:30]  * Laney collides with directhex 
[23:31] <kolby> thank you all.
[23:32] <kolby> what does this mean:
[23:32] <kolby> No host tea found in config