[00:05] <rawler> cjwatson: exactly how does popularity-contest work?
[00:06] <rawler> does it actually track "usage" of packages somehow, not just which packages is installed?
[00:06] <RoAkSoAx> cjwatson, should I remove them?
[00:11] <cjwatson> rawler: err, probably best to look at its documentation or source or whatever; I haven't looked at it in ages. It does attempt to track usage via atime, though.
[00:11] <cjwatson> RoAkSoAx: if they already exist in a Debian package, removing them would create an unnecessary delta
[00:11] <rawler> cjwatson: oki.. :)
[00:11] <cjwatson> RoAkSoAx: if it's entirely your own package, then it's up to you; they're unnecessary if you don't use emacs
[00:12] <cjwatson> (and personally I think that sort of thing belongs in .emacs so that it applies to */debian/changelog, not in each individual file)
[00:12] <rawler> cjwatson: I don't know if you saw my original question, but I'm pondering a way to auto-detect unused packages, and suggest them for removal, I.E. in cruft remover..
[00:12] <cjwatson> but if it's somebody else's package, leave them be
[00:12] <cjwatson> rawler: I did, but it's after midnight here and I'm about to go ... ;-)
[00:12] <rawler> so, I guess I'll just keep looking.. :)
[00:12] <rawler> me too.. see you all.. I'll probably check back in when I have something more concrete.. :)
[00:12] <RoAkSoAx> cjwatson, Ok. Since they were introduced in the Ubuntu changelog I guess I'll just remove them. Thanks :).
[00:13] <rawler> (IF I can come up with something more concrete)
[02:54] <xMrKrnlx> KernelCheck - tool for an automated build of a kernel from the latest source - up for reviewing: http://revu.ubuntuwire.com/p/kernelcheck
[03:59] <AnAnt> Hello, I am trying to convert a package 'dico' to use dh 7, the issue is that dico got subfolders where I'll have to get into myself & build (ie. I got to override dh_auto_build), now those subfolders got python scripts/modules (ie. setup.py is there), now I wanted to see how dh_auto_build handles setup.py files so I found that it simply runs: python setup.py build
[03:59] <AnAnt> similarly dh_auto_install runs: python setup.py install
[04:00] <AnAnt> shouldn't it be doing something like this: $(subst $(PYDEF),python,$*) setup.py build/install ?
[04:02]  * AnAnt thinks: why did I say this  very long intro  ?!
[04:18] <ScottK> AnAnt: Why are you trying to convert it?
[04:33] <AnAnt> ScottK: good question
[04:33] <ScottK> I generally go by the motto if it's not broken, don't fix it.
[04:33] <AnAnt> ScottK: well, most packages that I converted looked simpler after conversion, that's all, so I'm seeing if the same can be done for dico
[04:34] <AnAnt> ScottK: ok, regardless of the conversion, is what I noticed correct ?
[04:34] <ScottK> AnAnt: IMO "looks simpler" is exactly that.  It isn't simpler, it's just the more of the complexity is hidden.
[04:34] <ScottK> AnAnt: I don't know.  I haven't messed with DH 7 stuff much yet.
[04:34] <AnAnt> shouldn't dh_auto_build/install be doing a $(subst $(PYDEF),python,$*)
[04:34] <AnAnt> ok
[05:02] <AnAnt> ScottK: btw, although the motto 'if it ain't broke, don't fix it' is usually correct, yet sometimes it is nice to cleanup (and sometimes simplify) code for easier future maintainance
[05:07] <ScottK> Certainly.  Preventative maintenance has it's value
[05:11] <StevenK> I like the debhelper 7 stuff for simple packages
[06:41] <cpscotti> Ampelbein, warp10 : Could you (or some other motu) review/advocate the harpia package, it got rejected by the archive by some minor (now solved) dependencies issue. ( http://revu.ubuntuwire.com/p/harpia ). (python app, opencv, computer vision)..
[09:38] <or4n9e> hi there. could it be that casper introduces some local diversions to dpkg-divert --list on every reboot?
[09:39] <or4n9e> I removed a local diversion of /usr/lib/update-notifier/apt-check and once rebooted this diversion is automatically restored
[09:39] <or4n9e> is there a way to adjust this - I permanently need to get rid of the diversion
[09:39] <or4n9e> ?
[10:27] <slytherin> geser: ping
[11:09] <rohitkg> to everyone:i have written a C program, and i wanted to create  a package out of it.
[11:09] <rohitkg> i have done all the steps to create it, but there is a problem during cleaning
[11:09] <rohitkg> can anyone help me out?
[11:10] <rohitkg> these are the pastebin links
[11:10] <rohitkg> http://pastebin.com/d4893c87d for makefile
[11:10] <rohitkg> http://pastebin.com/d1fd60256 for rules
[11:10] <rohitkg> http://pastebin.com/dd0a1060 while package building
[11:11] <rohitkg> maxb:can you look at my problem given above ^^^^^
[11:28] <slytherin> rohitkg: did you actually read the errors?
[11:29] <rohitkg> yeah, it said,there was no such directory as Hello
[11:31] <slytherin> rohitkg: so?
[11:31] <slytherin> fix that error
[11:31] <rohitkg> slytherin:how should i correct that,should i make a change in the makefile?
[11:32] <slytherin> rohitkg: check the clean target in your debian/rules file
[11:33] <rohitkg> ok
[11:42] <rohitkg> slytherin:can you mention,which location it should point to,i'm not gettin it
[11:43] <rohitkg> the source files and the debian directory is under myhello-1.0
[11:43] <slytherin> rohitkg: I don't know. It is your program.
[11:44] <rohitkg> slytherin:can you please go through that pastebin links?
[11:44] <slytherin> rohitkg: sorry, I am busy
[11:44] <rohitkg> ok
[11:44] <rohitkg> thanx anyway
[12:02] <pochu> RainCT: hey, you're doing it wrong (pkg-gnome) :)
[12:02] <pochu> can you join #gnome-debian on GimpNet?
[12:03] <RainCT> pochu: yeah, I asked several times how to do it some time ago but nobody answered :/
[12:03] <pochu> oh
[12:03] <pochu> guess I wasn't around ;)
[12:04] <RainCT> pochu: and now I couldn't even remember the name of the channel lol (why not #debian-gnome like anyone else?)
[12:05] <pochu> 'couse we're special =)
[12:33] <RainCT> DktrKranz: uhm, I can't build that kupfer thing. Maybe it's becoming time I upgrade to Karmic.. :P
[12:34] <DktrKranz> RainCT, probably. I install files in a private location, that is supported with latest pysupport and distutils, I think
[12:34] <RainCT> DktrKranz: well, it fails at the build dependencies already :)
[12:34] <DktrKranz> you need keybinder
[12:35] <DktrKranz> (also uploaded)
[12:35] <RainCT> DktrKranz: yep, and that one needs a new debhelper and python-gnomeapplet or sth which my apt doesn't find
[12:35] <RainCT> ah but there are screenshots at the website, that's all I wanted to see :)
[12:36] <DktrKranz> heh
[12:36] <DktrKranz> I can provide one myself, I've currently installed (Debian box, but it's the same)
[12:37] <DktrKranz>  debhelper | 7.0.17ubuntu4 |        jaunty | source, all
[12:37] <DktrKranz> and yes, you require 7.0.50
[12:45] <sebner> RainCT: pfff, jaunty. pfff. karmic karmic karmic
[12:49] <RainCT> DktrKranz: nah don't worry, was just curious how it looks
[12:49] <DktrKranz> it's much similar to early gnome-do
[12:50] <DktrKranz> well... it's intended to do the same job, so I think it's normal ;)
[12:50] <RainCT> sebner: are you also like this when your X doesn't start? :D
[12:50] <RainCT> DktrKranz: well, it hasn't a dock, so no fun *g*
[12:50] <DktrKranz> RainCT, do you need X? use framebuffer!
[12:51] <DktrKranz> RainCT, my gnome-do won't have dock, compiz and I don't fit well
[12:51] <sebner> RainCT: my X always starts up. You just have to punch it hard enough :P
[12:52] <RainCT> btw, do you also have to press space for your system to boot?
[12:52] <RainCT> (I have the .31~rc2 kernel here and it says something about unsupported video mode 303 -or maybe 606?- and press space to continue or enter to see list of modes)
[12:53] <sebner> RainCT: nope
[12:53] <sebner> RainCT: it just needs 28 seconds to boot up instead of 18 with jaunty ^^
[12:59] <RainCT> sebner: ah, i think here it's faster
[13:00] <DktrKranz> RainCT, what about passing vga=something to grub?
[13:15] <DktrKranz> ScottK, mind rejecting kupfer package in karmic/NEW? I have to reupload a fixed version
[13:16] <ScottK> DktrKranz: I can do that.
[13:17] <ScottK> DktrKranz: Rejected.
[13:17] <DktrKranz> thanks
[13:17] <ScottK> No problem.
[14:23] <slytherin> asac: When is xulrunner-dev likely to depend on xulrunner-1.9.1-dev in karmic?
[14:49] <geser> slytherin: pong
[14:49] <slytherin> geser: I didn't get any build failure again, but build fails in PPA. What do you suggest?
[14:50] <geser> if it fails in PPA, I assume that it will also fail in the main archive
[14:51] <geser> slytherin: I can advocate it if it helps you in someway
[14:51] <slytherin> geser: So should I disable the test case and upload, or should I take chance by uploading right now and if it fails I will disable the test later.
[14:52] <slytherin> geser: I packaged it as it is essential build-dep for jmeter. I have been working on jmeter for past 4 months at least. :-)
[14:53] <Laney> wow
[14:53] <Laney> I think I broke something on my system
[14:53] <Laney> pbuilder tarballs take *ages* to extract/update now
[14:54] <Laney> like 5 minutes
[14:56] <geser> slytherin: advocated as I'm sure you will deal with the FTBFS
[14:56] <geser> so you can upload it now (too busy right now to do it myself)
[14:56] <geser> and the PPA build error is the same I get in my pbuilder
[14:57] <sebner> Laney: seems so. here it takes 1.5 minutes for the whole procress (updating 10 packages from today)
[14:57] <slytherin> geser: uploading. I guess it will take some time to come out of new queue
[14:57] <Laney> does anyone use sbuild/lvm on karmic?
[14:57] <Laney> I get "FATAL: Module dm_snapshot not found.
[14:58] <slytherin> geser: In case you have nothing better to do, can you also take a look at swtcalendar. I have already advocated it.
[14:58] <Laney> FATAL: Module dm_snapshot not found.
[14:59] <slytherin> Laney: probably not available for the kernel version you are running
[14:59] <Laney> any specific reason why it wouldn't be?
[15:00] <slytherin> Laney: no idea, never used sbuild.
[15:09] <geser> slytherin: perhaps later, I hope to finally do the task I wanted to get done the whole week already :(
[15:09] <slytherin> geser: no issues. :-)
[16:09] <gaspa> Laney: do you have a minute?
[16:11] <directhex> he's at the supermarket
[16:23] <jpds> directhex: Waitrose?
[16:26] <cpscotti> Someone there with time to review/advocate the harpia package, it got rejected by the archive by some minor (now solved) dependency issues. It already got one advocate! ( http://revu.ubuntuwire.com/p/harpia ). (python app, opencv, computer vision).
[16:31] <RainCT> cpscotti: out of curiosity, what can it be used for?
[16:32] <cpscotti> RainCT: Computer Vision and Image processing applications
[16:32] <kecskebak> Can anyone suggest a good example of a PyGTK package with yelp help? I'm trying to figure out how to get F1 working in a PyGTK app.
[16:34] <cpscotti> RainCT: For instance, you could generate a "person detector" with a few blocks (3 or 4), set your webcam as input and a shell command as an output (for, lets say, "speak hi" or "shoot").
[16:34] <cpscotti> RainCT: Also, you could easily apply video effects to any home video of yours, images...
[16:35] <cpscotti> In the app's help menu u can find a few examples
[16:42] <RainCT> cpscotti: the README isn't interesting to users of the .deb
[16:45] <RainCT> cpscotti: and the path to the GPL must be "../GPL-3" as the license isn't "or later"
[16:46] <cpscotti> RainCT: could I just remove that readme (I agree with u)
[16:47] <RainCT> cpscotti: sure, just removing debian/docs may do, if it doesn't youll need some special CDBS_ line in debian/rules (I can look it up if you need it)
[17:00] <cpscotti> RainCT: is it all right to add build-essential to Build-Depends ? debuild seems to need it..
[17:01] <RainCT> cpscotti: no, that's always installed
[17:01] <Laney> jpds: asda
[17:01] <cpscotti> RainCT:so... I just uploaded the fixed version
[17:01] <Laney> and now I'm back.... with toffee yum yums!
[17:01] <Laney> gaspa: hi!
[17:21] <RainCT> cpscotti: the README is still being installed
[17:24] <cpscotti> RainCT: could I just remove it?
[17:26]  * cpscotti leaving for lunch 
[17:26] <RainCT> cpscotti: no, there's a proper way to do it, a DEB_DOCS_ALL variable or something like that but I can't recall the exact name :/
[17:26] <RainCT> cpscotti: ok, enjoy your meal
[18:54] <jacob> any MOTU want to do a quick review of gfire? http://revu.ubuntuwire.com/details.py?upid=5744
[18:55] <therm> anyone out there likes reviewing my package? http://revu.ubuntuwire.com/p/swtcalendar
[18:55] <therm> it has been advocated one time
[18:58] <jacob> actually, seems my previous link should be http://revu.ubuntuwire.com/details.py?upid=6004
[19:01] <slytherin> does uscan save the new upstream version number in some environment variable after it finishes the scan?
[19:01] <hyperair> uscan is a child process.
[19:02] <hyperair> it can't change the parent's environment variable
[19:02] <hyperair> unless i'm mistaken
[19:05] <slytherin> hmm, I want to write the get-orig-source such that I can use the version number found out by uscan. I can not use uupdate because the upstream source needs repacking.
[19:18] <jmarsden> slytherin: See an excerpt from a rules file I created that does this... http://pastebin.ubuntu.com/215622/
[19:18] <james_w> slytherin: get-orig-source is not for that
[19:57] <cpscotti> RainCT: Any ideas on how to eliminate the README, or where can I find docs about that "DEB_DOCS_ALL" var or something?
[19:57] <pochu> cpscotti: cdbs?
[19:58] <RainCT> pochu: yes
[20:00] <pochu> /usr/share/doc/cdbs/cdbs-doc.html
[20:00] <cpscotti> I found DEB_INSTALL_DOCS_ALL, is it that?
[20:00] <RainCT> cpscotti: yeah, that's it
[20:01] <RainCT> try adding "DEB_INSTALL_DOCS_ALL=" to debian/rules
[20:02] <cpscotti> building it
[20:03] <cpscotti> works..
[20:03] <cpscotti> =]
[20:08] <cpscotti> RainCT: just uploaded the fixed version
[20:10] <RainCT> cpscotti: have you tried it it works?
[20:16] <RainCT> (yeah it does)
[20:17] <RainCT> cpscotti: uploaded
[20:32] <cpscotti> RainCT: yep, I build the binary and it didn't install the readme