[00:29] <anakron> HI all
[00:29] <anakron> :)
[00:29] <anakron> i got today 1000 in bug management in LP
[00:29] <anakron> JEJE
[04:15] <stooj> In the Motu video, Daniel Holbach has a name in the maintainer field for the control file when packaging. The wiki says to use a general address though (<ubuntu-motu@lists.ubuntu.com>). Which is it?
[04:16] <nhandler> The Maintainer should be 'Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>'
[04:19] <stooj> OK, thanks nhandler
[04:20] <nhandler> stooj: Technically, the Maintainer field can be anything with @ubuntu.com in it, but for most packages, you will want to use the address I gave you above
[04:23] <stooj> nhandler, in the video he set up a bashrc profile with a fake name (saying replace with our name) and it seems to put that automatically into the control file
[04:23] <stooj> But I'll remember to change it
[04:24] <nhandler> stooj: There is an update-maintainer utility either in devscripts or ubuntu-dev-tools that might come in handy
[04:25] <stooj> Grand, thanks nhandler
[04:27] <Hobbsee> stooj: you can use your own name if you wish, afaik, but ubuntu has the concept of 'group maintainership', which is why the u-m@l.u.c address tends to be used - it addresses the entire group.
[04:27] <Hobbsee> and thus, anyone can update the package
[04:30] <stooj> Nice! update-maintainer does it for you! Cheers
[04:33] <nhandler> Hobbsee: I thought you could only use your own name if you were an ubuntu member. IIRC, that is in the ubuntu-policy
[04:34] <persia> nhandler, The Ubuntu policy is rather that all packages specific to Ubuntu should be maintained by Ubuntu Members.
[04:34] <Hobbsee> i stand corrected, then.
[04:34] <persia> There's no reason one can't put whatever one wants in the Maintainer field, but it's unlikely to be accepted as an Ubuntu-local package without having commitment from someone with membership.
[04:35] <persia> stooj, If you'd like to be the maintainer, you'd do better to get the package into Debian, and sync it into Ubuntu.
[04:40] <stooj> Och, I'm not interested in being the maintainer for anything yet - just trying to learn how to package properly so that I can help out
[04:41] <stooj> Wanted to make sure I was going about it all the correct way
[04:43] <persia> stooj, I'd *strongly* recommend against trying to package something from scratch as a learning exercise.
[04:44] <persia> Firstly, it's the hardest way to do it, secondly, you'll be unhappy with the result once you learn more, and thirdly, it's the most latent way to get feedback from other developers on your work.
[04:44] <persia> You'd do a lot better to look at the bug tracker, and chase some bugs.  Many of them have patches available, either attached to the bug, or upstream.
[04:45] <stooj> Oh, really? What would you suggest? I'm pretty much working my way through https://wiki.ubuntu.com/MOTU/GettingStarted
[04:45] <persia> By working with the existing packages, and getting the patches applied, you'll become familiar with many different packaging styles, and can better determine what you think is best.
[04:45] <persia> I'd suggest compeltely ignoring that page, but I'm biased.
[04:45] <persia> I like https://wiki.ubuntu.com/MOTU/Contributing
[04:46] <stooj> Maybe work through the recipes on that page?
[04:50] <persia> Well, you could.  I really think you'd do better to look for bugs you can fix.
[04:52] <persia> http://daniel.holba.ch/harvest/ has a list of thousands of things needing doing.  Pick one that looks interesting.  Ask here if you don't understand.  Try to fix it.
[05:04] <stooj> Ok, this may be a particularly stupid question, but as an aspiring MOTU, should I be working with Jaunty?
[05:06] <persia> You should be developing against Jaunty.  If you don't choose to run your primary system on Jaunty, everyone understands, but you should at least have a VM available.
[05:08] <stooj> Grand. Thanks persia
[05:25] <dholbach> good morning
[05:26] <stooj> Good morning
[05:32] <stooj> Jings.
[05:47] <xnox> I have a package which uses quilt. I've tried quilt push. It said that the patch failed. I've put the -f option. It said that it create .rej file. What do I do now??? I'm confused this is first time a patch didn't apply
[05:48] <xnox> I did resolve merge conflicts in bzr/git before. This is something contr-intuitive
[05:48] <xnox> Can anyone please help?
[05:51] <jmarsden> Hi xnox  (i just packaged bibledit, BTW).  Anyway... you should probably look at the .rej and see why the patch is not applying?
[05:52] <xnox> jmarsden: yeah I've looked at it. What do I do now? Am I suppose to edit the original file so that the changes in the .rej are "applied"
[05:53] <jmarsden> No... can you tell why the patch was rejected?  Was it already applied, for example?
[05:53] <xnox> By the looks of it the code has changed so that the think in the rej should be like 10 lines up
[05:55] <jmarsden> OK.  So... you could hack the patch file to match the code, if you're comfortable doing so... or you could try to regnerate the quilt patch by using quilt new and making the "patch" by hand, but for me that is more work than just changing the line numbers in the old patch file!
[05:57] <xnox> can I do this:
[05:57] <persia> The editpatch command may also be useful.
[05:57] <xnox> quilt push -f
[05:57] <xnox> change the files
[05:57] <xnox> quilt refresh
[05:57] <xnox> ????
[05:58] <jmarsden> I don't know, but I don't think that will fix the patch which needs to be updated
[06:00] <xnox> Yeap it did.
[06:00] <jmarsden> OK, cool.  You are on your way.
[06:00] <xnox> It added timestamps as well =D
[06:01] <jmarsden> Are you packaging GnomeSword or BibleTime, or something else?
[06:08] <xnox> GnomeSword
[06:19] <jmarsden> xnox: Great!  I was hoping someone on the team would pick up the front ends and package them.
[06:23] <tritium> xnox: you'r updating the package already in the repos?
[06:28] <xnox> tritium: yeap
[06:29] <tritium> xnox: cool!
[06:31] <xnox> tritium: licensecheck complains (with incorrect FSF address)
[06:31] <xnox> is there a script I can run to update them all and then send the patch upstream?
[06:34] <tritium> xnox: I'm not the right one to ask.  I'm not active MOTU.
[06:34] <persia> xnox, not an existing one: it's usually easy enough to do with the search-and-replace features in your favorite text editor.
[06:35] <xnox> persia, my emacs daemon is getting excited for some elisp fun =D
[06:46] <didrocks> morning everyone o/
[06:49] <Zetto> Someone can include #251173 in the milestone of jaunty-alpha-5 ?
[06:49] <Zetto> Bug #251173
[06:54] <ScottK> Zetto: No.  Didn't need it in 3 channels either.
[06:59] <HorizonXP> i need to remove the built-in PDO support from PHP. i'm wading through debian/rules, but would appreciate some help
[09:29] <_stochastic_> I'm writing up a machine-readable copyright file, and one of the files is under public domain, I'm not sure what to put as the license text
[09:30] <_stochastic_> oh, nevermind, I've found it
[10:19] <savvas> for merges, instead of "Please sync" we use "Please merge" in the title?
[10:20] <james_w> yup
[10:20] <james_w> and attach the debdiff
[10:25] <savvas> that's the hard part :P
[10:25] <savvas> I think I'll have to remove the request for the new libmtp https://bugs.launchpad.net/bugs/315679
[11:09] <quadrispro> hi! does some take a look at http://revu.ubuntuwire.com/details.py?package=w-scan ?
[11:09] <quadrispro> someone *
[11:29] <mok0> iefremov: you've got a +1 from me. Now try to find another advocate!
[11:30] <iefremov> mok0: ok, thanks! don't you know anybody who would be interested?
[11:31] <mok0> iefremov: Any MOTU would be good, it's good to get a second opinion
[11:32] <mok0> You have to ask once in a while on the channel
[11:32] <mok0> I'll ask too
[11:32] <iefremov> ok, thanks
[11:32] <mok0> iefremov: np
[11:32] <Laney> mok0: Good lord! Have you seen the REVU hall of fame? :O
[11:32] <mok0> iefremov: I try to follow up on the packages I advocate
[11:33] <mok0> Laney: no...
[11:33] <Laney> http://hall-of-fame.ubuntu.com/
[11:33] <Laney> heh heh
[11:33] <mok0> Ah, I'm in second place... :-)
[11:33] <mok0> With far to go before I catch up with pers ia
[11:34] <Laney> hmm?
[11:34] <mok0> oh
[11:34] <mok0> Yay, I'm on top!!!
[11:34] <mok0> :)
[11:34] <Laney> by a long long way!
[11:34] <quadrispro> w-scan needs some love :( -> http://revu.ubuntuwire.com/details.py?package=w-scan
[11:35] <mok0> quadrispro: got it covered
[11:35] <quadrispro> :)
[11:36] <stdin> I'm fixing a packaging bug for qtparted, I've bumped the ubuntu revision for jaunty but it should go into intrepid too. currently the version in intrepid and jaunty is the same, so what should be the revision for an intrepid SRU?
[11:37] <Laney> stdin: Intrepid revision +0.1
[11:37] <mok0> stdin: add ~intrepid1
[11:38] <jpds> stdin: versionNumber+0.1 right?
[11:38] <stdin> heh, I'm torn between .1 and ~intrepid1
[11:38] <Laney> there's a page on the wiki (linked from the SRU process) that gives examples
[11:38] <mok0> stdin: oh it depends on whether it's backports or updates
[11:38] <stdin> yeah, but I see examples of both in the archives and wan't sure
[11:38] <stdin> *wasn't
[11:38] <stdin> it should go into -updates really
[11:39] <stdin> the bug stops the app from launching when started from the menu
[11:39] <jpds> Backports have ~intrepid1, security +1, update +0.1, I believe.
[11:39] <mok0> stdin: then add .1 to the jaunty number
[11:39] <mok0> jpds: yes
[11:39] <Laney> jpds: security and SRU are the same
[11:39] <Laney> at least, the SRU page says to use the security scheme
[11:39] <jpds> Hmm.
[11:42] <Piratenaapje> mok0, I think I fixed everything you said in your review, can you or anyone else take another look at http://revu.ubuntuwire.com/details.py?package=grnotify ?
[11:42] <mok0> Piratenaapje: you are now number
[11:42] <mok0> 1
[11:42] <mok0> in the queue
[11:43] <mok0> (music playing)
[11:43] <Piratenaapje> yay
[11:43] <Piratenaapje> thanks :)
[11:46] <Piratenaapje> mok0: I didn't see your comment :s
[11:46] <Piratenaapje> am I allowed to changed the original tarball?
[11:46] <Piratenaapje> without releasing a new version?
[11:47] <tuxmaniac> mok0: there was someone (sorry couldnt remember the nick) yesterday evening wanting a review from you for a "complex bio-informationcs tool". Just for your information
[11:48] <iefremov> tuxmaniac: it was me :)
[11:48] <stdin> hokey-kokey, if someone want to take a look at the bug for me, it's bug #257220
[11:52] <mok0> tuxmaniac: yes I've now given it the golden seal of approval :-P
[11:56] <mok0> Piratenaapje: uhm, you don't have an upload since my latest review?
[11:57] <Piratenaapje> (12:46:03 PM) Piratenaapje: mok0: I didn't see your comment :s
[11:57] <Piratenaapje> (12:46:15 PM) Piratenaapje: am I allowed to changed the original tarball?
[11:57] <Piratenaapje> (12:46:23 PM) Piratenaapje: without releasing a new version?
[11:57] <mok0> Piratenaapje: I thought you were upstream
[11:57] <Piratenaapje> mok0: I am
[11:57] <Piratenaapje> mok0: guess I'll just replace the tarball on sourceforge
[11:57] <mok0> Piratenaapje: of course you are allowed
[11:58] <mok0> Piratenaapje: wait until you make another release anyway
[11:59] <mok0> Piratenaapje: put the new COPYING in your svn
[12:00] <mok0> Piratenaapje: the comments I had about COPYING and the license clause in source code is not urgent, but a recommendation to fix it "soon".
[12:01] <Piratenaapje> mok0: Ah ok, I'll fix it in the next release then
[12:01] <mok0> Piratenaapje: fine
[12:01] <mok0> Piratenaapje: OK, it was a very short review, I will write some more and then you can upload
[12:02] <quadrispro> mok0, thanks for the comment, I'll follow your suggestions to improve the package documentation
[12:02] <Piratenaapje> mok0: Alright, thanks
[12:02] <mok0> quadrispro: great! Almost there
[12:03] <mok0> quadrispro: until another evil MOTU comes along and discovers everything I've missed :-P
[12:03] <mok0> We want perfect packages in Ubuntu, otherwise the Debian guys thumb their noses at us
[12:11] <quadrispro> mok0, I use w-scan at work for scanning DVB-T channels, I'll use my experience to improve the manpage in order to give to the users the chance of being satisfied using it
[12:11] <mok0> Piratenaapje: ok, so there's a few more comments for you to work oin
[12:11] <mok0> quadrispro: perfect!
[12:12] <mok0> quadrispro: I guess you need some kind of tuner?
[12:12] <quadrispro> mok0, sure, we use a TechnoTrend hardware (DVB-T receiver)
[12:12] <Piratenaapje> mok0: Thanks, I'll look into it later
[12:13] <quadrispro> mok0, then we broadcast the stream on Internet with VLC
[12:14] <mok0> quadrispro: ah, cool
[12:14] <quadrispro> using Ubuntu Server, obviously :D
[12:14] <mok0> quadrispro: hehe, of course
[12:23] <james_w> is there something that will push the parts of a source package to an arbtrary sftp location?
[12:23] <james_w> like dput without pre-defined targets?
[12:23] <james_w> can dput in fact do it?
[12:28] <mok0> james_w: you don't want a predefined target?
[12:28] <james_w> not really
[12:28] <james_w> it's just for throwing packages up on a server so that they can be grabbed by someone else
[12:28] <pochu> james_w: default_host_main	= none
[12:28] <mok0> james_w: you can wrap it in a script that first writes a temp config file, then invoke dput --config tmpconfigfile
[12:28] <pochu> in /etc/dput.cf
[12:29] <pochu> err
[12:29] <pochu> ok, I misunderstood :)
[12:29] <Webspot> Hi. Any MOTUs available to review osm-gps-map, a GTK widget to embed openstreetmap in applications? Thanks :) http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[12:29] <james_w> I currently do it by "scp blah.dsc blah.diff.gz blah.orig.tar.gz server:path" but it would save some typing to just pass it a .dsc/.changes and have it work it out
[13:01] <mok0> james_w: make a shell script like I described, it would work
[13:02] <james_w> mok0: oh yeah, I was just wondering if one already existed
[13:02] <mok0> james_w: heh I know
[13:38] <mok0> Webspot: review online for you
[14:01] <sistpoty|work> hi folks
[14:10] <mok0> sistpoty|work: hey
[14:10] <sistpoty|work> hi mok0
[14:17] <ScottK> sistpoty|work: Friday for a meeting ought to be fine for me.
[14:17] <sistpoty|work> ScottK: ok, great, and next Tuesday?
[14:17] <ScottK> What time?
[14:18] <sistpoty|work> same time
[14:18] <ScottK> Should be fine.
[14:18] <sistpoty|work> excellent
[14:25] <iefremov> Hi all! Any motu here to review ugene - genome analysis suite? Already advocated. http://revu.ubuntuwire.com/details.py?package=ugene
[14:39] <Webspot> mok0: Thanks for the review. I've fixed the issue and uploaded. http://revu.ubuntuwire.com/details.py?upid=4673
[14:40] <bddebian> Heya gang
[14:41] <sistpoty|work> hi bddebian
[14:42] <mok0> Webspot: did the .symbols file give you any problems?
[14:42] <bddebian> Heya sistpoty|work
[14:42] <Webspot> mok0: I didn't check, I'll have a look to see if it still builds :p
[14:42] <mok0> Webspot: ah, you didn't check, eh?
[14:45] <Webspot> mok0: Builds fine. Thanks. I'll just go and learn what this symbols file is, for the future, now :)
[14:47] <ScottK> iefremov: I'm looking at ugene.
[14:47] <mok0> Webspot: it's to make it possible for  a newer application to make do with an older library
[14:48] <Webspot> mok0: Ah right. Cool.
[14:52] <mok0> Webspot: you need to do another upload, will you do that?
[14:52] <mok0> Webspot: you need to fix the .symbols file
[14:53] <Webspot> mok0: The latest upload has the .symbols file
[14:53] <mok0> Webspot: in .symbols, delete the suffix +git20090120
[14:53] <Webspot> mok0: Okay. Thanks.
[14:53] <mok0> Webspot: on all entries. Yes I know it's there
[14:54] <rgreening> ScottK: ping
[14:54] <mok0> Webspot: I'm gonna ack it, and I want the next reviewer to have the right .symbols file in there
[14:54] <ScottK> Heya rgreening.
[14:54] <rgreening> ScottK: hey. I have created a bug report for new Kvirc package
[14:54] <ScottK> rgreening: What bug?
[14:54] <rgreening> ScottK: bug 321891
[14:54] <ScottK> ;-)
[14:55]  * ScottK waits for the bot ...
[14:55] <rgreening> Can you review and let me know if there is anything blaringly wrong/missing, etc? Thanks.
[14:55] <mok0> damn lazy bot
[14:55] <rgreening> ScottK: bug #321891
[14:55] <Webspot> mok0: Thanks. I've just uploaded the new symbols file anyway. :)
[14:55] <rgreening> hmm.
[14:55] <rgreening> dead bot
[14:56] <Pici> No bot
[14:56] <rgreening> ScottK: https://bugs.launchpad.net/ubuntu/+source/kvirc/+bug/321891
[14:56]  * Pici looks into it
[14:56] <mok0> Probably off drinking again...
[14:56] <Piratenaapje> mok0: I released a new version in upstream of grnotify, feel free to review it again if you have the time. http://revu.ubuntuwire.com/details.py?package=grnotify
[14:56] <ScottK> rgreening: looking
[14:56] <mok0> Piratenaapje: will do a bit later
[14:57] <rgreening> ScottK: ty. There are a couple of q's I have for you later on the package regarding menu icon (xpm) and how to integrate into cmake build
[14:58] <ScottK> OK.  Please redo your diff.gz without the PPA versioning.  It should be exactly what you want me to upload.
[14:59] <rgreening> ScottK: fair enough :)
[15:00] <rgreening> ScottK: how does the diff look?
[15:00]  * mok0 thinks there should be a law saying that your LP ident and IRC nick should be the same...
[15:02] <ScottK> Didn't look yet
[15:02] <rgreening> ok. reloading then
[15:04] <mok0> Of course, the price for advocacy is to do at least one merge or sync
[15:05] <mok0> AndrewGee: hehe
[15:05] <AndrewGee> mok0: :) - I was going to do it soon anyway.
[15:05]  * mok0 is not used to people paying attention
[15:06] <mok0> Well, honestly, it's hard to keep track of all those names
[15:06] <AndrewGee> mok0: Yeah. I imagine it is.
[15:07] <mok0> F.ex. afaik Piratenaapje is alias  "bamps-kristof-gmail"
[15:08] <Piratenaapje> No idea why I did that :s
[15:08] <mok0> Piratenaapje: isnt the bamps one your LP ident?
[15:08] <Piratenaapje> yes
[15:13] <quadrispro> mok0, I'm sorry for bothering you again :) what do you think about this? -> http://paste.ubuntu.com/110326/
[15:14] <mok0> quadrispro: It's better, but still very technical. I am a total dweeb when it comes to video, and I would know if my hardware would work with it
[15:14] <mok0> s/would/wouldn't/
[15:15] <quadrispro> ah ok I understand, I could insert some informations about what user must have to use it
[15:15] <mok0> quadrispro: but the page is great once you understand what it's about
[15:15] <mok0> quadrispro: yes, that would be good
[15:16] <quadrispro> but I think that these informations should be in the package description
[15:18] <quadrispro> isn't it right?
[15:19] <mok0> quadrispro: yes
[15:21] <quadrispro> ok, working on it
[15:22] <ScottK> iefremov and mok0: I'm a bit confused about src/core/src/ioadapter/ZlibAdapter.  The comments say the Zlib stuff was removed, but that's still there?
[15:22] <mok0> ScottK, the original zlib stuff is not there anymore... I suspect that is some kind of data structure ugene uses
[15:23] <mok0> ScottK, so it can read and write gz packaged files
[15:23] <mok0> ScottK, be warned it takes forever to compile
[15:23] <iefremov> ScottK: yes, mok0 is right
[15:24] <iefremov> it's our adapter which uses zlib
[15:24] <ScottK> iefremov: What's the licensing of the work you derived that from?
[15:25] <ScottK> Based on gun.c ....
[15:28] <Piratenaapje> Am I allowed to run code in the binary-arch target of debian rules, when the architecture is independant? It's python code I use to install with, but lintian gives me a warning about it.
[15:29] <mok0> Piratenaapje: in principle no
[15:29] <mok0> Piratenaapje: the other way is ok
[15:31] <mok0> Piratenaapje: the reason is, that most of the buildd's _only_ build binary-arch
[15:31] <ScottK> mok0: Since src/core/src/ioadapter/ZlibAdapter says it's 'Based on gun.c' from zlib, I think the license information for gun.c should also be in debian/copyright.
[15:31] <ScottK> It's GPL compatible, so not a problem, just need to add it in.
[15:31] <mok0> ScottK, you are right, ues
[15:31] <iefremov> but there is no gun.c in the package
[15:31] <mok0> s/ues/yes
[15:31] <iefremov> so what should i do?
[15:31] <ScottK> iefremov: But src/core/src/ioadapter/ZlibAdapter is derived from it.
[15:32] <Piratenaapje> mok0: So am I allowed to do this in my packages? I want te be able to be indepentantly
[15:32] <ScottK> Add something to debian/copyright that says something like: "src/core/src/ioadapter/ZlibAdapter is based on gun.c from Zlib.  Gun.c is licensed under the following terms:"
[15:32] <ScottK> And then state them.
[15:32] <iefremov> ok, agreed
[15:33] <ScottK> iefremov: It's not a problem for the package, we just need to make sure we get it right.
[15:33] <mok0> ScottK, good catch :-)
[15:33] <ScottK> Virtually all packages that get rejected by an archive admin are for licensing reasons.
[15:33] <ScottK> mok0: Thanks.
[15:33] <mok0> Piratenaapje: if your package builds something arch-dependent it _must_ be in the arch target.
[15:34] <iefremov> ScottK: are there any other issues?
[15:34] <ScottK> iefremov: I'm going to continue to review, but I'm not going to build it until I have your update.  Please ping me when the update is on REVU.
[15:34] <ScottK> iefremov: Not so far.
[15:34] <mok0> Piratenaapje: if you're a good citizen, you separate it a s much as possible
[15:34] <ScottK> I think I'm done with licensing stuff.
[15:34] <Piratenaapje> mok0: It doesn't actually build anything, it basicly just copies stuff to the debian/package/ dir
[15:35] <mok0> Piratenaapje: what's the package?
[15:35] <Piratenaapje> http://revu.ubuntuwire.com/details.py?package=grnotify
[15:35] <Piratenaapje> eum
[15:35] <ScottK> iefremov and mok0: One more thing - The tarball should be versioned to indicate it was repacked.
[15:35] <mok0> Piratenaapje: ah, that :-)
[15:35] <Piratenaapje> It's not in that version though
[15:35] <Piratenaapje> That one IS architecture dependant
[15:36] <mok0> Scott, yes, missed that one
[15:36] <Piratenaapje> debian/control file isn't correct
[15:36] <ScottK> mok0: Were any of the files removed for licensing reasons?
[15:37] <mok0> ScottK, AFAIR; only zlib, for redundancy, and to make sure we use the system version
[15:37] <ScottK> OK.
[15:38] <iefremov> ScottK: do you mean adding '+repack' to version?
[15:38] <ScottK> iefremov: Policy gives you a lot of flexibility about how to name it.
[15:38] <ScottK> That's one option.
[15:38] <ScottK> It's actually the one I was about to suggest.
[15:38] <iefremov> ok
[15:38] <mok0> Me too :)
[15:39] <ScottK> iefremov: The depends on eugene-data should be versioned to the same source version.
[15:40] <ScottK> So the packages don't end up out of sync in the future.
[15:40] <mok0> ScottK, but the -data package will be upgraded too, if it's found in the repo
[15:41] <ScottK> Yes, but if you get, for instance, a bad mirror that doesn't have all the packages you end up with version mismatches and bad things happen
[15:42] <ScottK> If there is a source version depends then you'll know you have a problem at install time.
[15:42] <mok0> ScottK, Hm, yes, I guess that depends on how release-specific the data is... I suspect it's not
[15:42] <ScottK> Dunno.
[15:42]  * ScottK can't predict the future.
[15:42] <iefremov> well, it's not
[15:42]  * mok0 can't either
[15:43] <iefremov> so what should i do?
[15:43] <mok0> iefremov, ScottK, in that case, perhaps it's better not to have the depends...
[15:43] <mok0> Then the mirror situation etc. is not so critical
[15:44] <mok0> I mean the _versioned_ depends, of course
[15:44] <rgreening> ScottK: ping
[15:44] <ScottK> I've never seen a package split where it wasn't versioned.
[15:44] <ScottK> rgreening: Pong
[15:44] <rgreening> ScottK: ok, try again.
[15:45] <rgreening> ScottK: bug/321891
[15:45]  * ScottK looks
[15:45] <mok0> ScottK, it's a bunch of data that hardly ever changes
[15:45] <ScottK> mok0: OK.  It's your field of expertise.  I'll accept that.
[15:45] <rgreening> ScottK: I need to re-upload the src... don't move/use that one uyet
[15:45] <mok0> iefremov: you decide what you want.
[15:45] <ScottK> rgreening: OK.  Let me know when you're actually ready for me to look.
[15:46] <rgreening> ScottK: I just remembered I needed to correct it. 5 secs.
[15:46] <mok0> ScottK, IF the data was not being updated for some reason, I think it's better that you would be able to complete the installation of the main package, and work with the old data
[15:47] <rgreening> ScottK: ok, for reals this time :)
[15:47] <ScottK> mok0: OK.  I'll go either way.
[15:47] <ScottK> rgreening: OK.
[15:47] <ScottK> mok0: Did you test that the get-orig-source rule works?
[15:47] <mok0> ScottK, yes, at one point
[15:48] <ScottK> iefremov: You'll need to update your get-orig-source for -repack or whatever you choose to use.
[15:48] <ScottK> iefremov: I've finished looking at the source, so once you've updated, I'll build it and see how that goes.
[15:49] <iefremov> ScottK: ok
[15:50] <ScottK> iefremov: Just let me know when you've updated it.
[15:50] <iefremov> ScottK: ok, 5 min
[15:58] <rgreening> ScottK: ping me if there are any issues with the kvirc package. ty for reviewing.
[15:58] <ScottK> rgreening: Will do.  Looking at it now.
[15:58] <rgreening> kk
[16:03] <Piratenaapje> ah crap
[16:04] <Piratenaapje> mok0: didn't see you advocated my package, and just uploaded an architecture independant version
[16:04] <Piratenaapje> Could you look again and readvocate please?
[16:04] <mok0> Piratenaapje: ok, I'll take a look..
[16:05] <Piratenaapje> mok0: Thanks, noticed it too late :s
[16:05] <mok0> Piratenaapje: np
[16:05] <mok0> Piratenaapje: you improved that installation?
[16:06] <Piratenaapje> mok0: yes, it's no longer architecture dependant now, had to change the debian/rules file
[16:07] <Piratenaapje> mok0: Hmm somethings seems to have gone wrong :s, diff shows me I've modified something I shouldn't have
[16:07] <Piratenaapje> Bah, I hate making these stupid mistakes
[16:08] <mok0> Piratenaapje: yup, it always happens right before upload
[16:10] <Piratenaapje> I wonder why I stopped getting mails from the package I'm subscribed to
[16:11] <mok0> Piratenaapje: what is it you say that has gone wrong?
[16:11] <Piratenaapje> mok0: the .diff shows there are modifications outside the debian dir
[16:11] <mok0> GoogleReader.py
[16:12] <Piratenaapje> fixed now
[16:12] <mok0> ok
[16:26] <mok0> Piratenaapje: did you upload?
[16:26] <Piratenaapje> mok0: I uploaded 15 mins ago ;)
[16:28] <mok0> Piratenaapje: when I click "(debdiff)" of the penultimate upload, it says   there are mods in GoogleReader.py
[16:28] <Piratenaapje> look at the actual diff
[16:28] <Piratenaapje> the problem existed because I used an older version of the original source
[16:29] <mok0> Piratenaapje: right. Hooray for lsdiff
[16:30] <mok0> Piratenaapje: +1
[16:30] <Piratenaapje> mok0: Yay, thank you for advocating :D
[16:30] <Piratenaapje> mok0: now I can start bothering someone else :p
[16:30] <mok0> Piratenaapje: you're welcome
[16:32] <Piratenaapje> Anyone feel like reviewing http://revu.ubuntuwire.com/details.py?package=grnotify ? It's a Tray notifier for Google Reader, written in python. Already advocated by mok0
[16:33] <quadrispro> mok0: new upload, re-advocate please :)
[16:33] <mok0> quadrispro: done already, you are too slow :-P
[16:33] <quadrispro> mok0: *cough* http://revu.ubuntuwire.com/details.py?upid=4741 *cough
[16:33] <quadrispro> :D
[16:34] <mok0> Hah
[16:34] <mok0> ok
[16:34]  * mok0 browses the debdiff critically
[16:34] <quadrispro> ahhh! deprecated!
[16:35] <quadrispro> mok0: wait a moment, please :D
[16:35] <mok0> quadrispro: ah, more work on the manpage.
[16:35] <mok0> quadrispro: take your time
[16:41] <quadrispro> mok0: now it's ready, if you would take a look to the buildlog, quadr-o-matic's working hard -> http://home.alessiotreglia.com/jaunty/result/w-scan_20081106-0ubuntu1/
[16:44] <mok0> quadrispro: +1
[16:45] <mok0> quadrispro: stop working
[16:45] <mok0> :)
[16:45] <quadrispro> :)
[16:45] <quadrispro> thank you mok0 ;)
[16:45] <mok0> quadrispro: my pleasure
[17:06] <doctormo> gah! this new ppa key sign thing is really hard to overcome. not for me, but for giving instructions to on-technicals\
[17:07] <doctormo> I can't even tell them to download my public key,
[17:11] <loic-m> doctormo: are you looking for instructions to give to users?
[17:11] <doctormo> loic-m: yes
[17:11] <jpds> doctormo: They ought to be on the PPA page.
[17:11] <doctormo> The Software Sources GUI Authentication tab only seems to want to add from a file, but the keyserver is a damned one, won't let them be downloaded
[17:12] <loic-m> doctormo: just got some help from cprov on #launchpad, if you want I can copy/paste them for you if you want
[17:13] <doctormo> loic-m: pastebin it if it's large
[17:15] <cprov> doctormo: click on the fingerprint link in the PPA page, then click on the keyid link on the key index page, voilà you have the public key, c&p into a file and use Software Sources.
[17:15] <loic-m> doctormo: http://paste.ubuntu.com/110355/
[17:15] <loic-m> cprov hope it's ok for you
[17:15] <doctormo> cprov: I think the part about copying and pasting is the bugger right there
[17:16] <loic-m> doctormo: the gpg method was in the doc https://help.launchpad.net/Packaging/PPA#Adding%20the%20keys%20in%20the%20terminal
[17:16] <doctormo> thanks loic-m, cprov
[17:16] <cprov> doctormo: I know, but where do you want to fix it ?
[17:17] <loic-m> doctormo: if you click long enough you get to a page with the public key to copy
[17:25] <ScottK> cprov: How goes packages-arch-specific?
[17:25] <cprov> ScottK: no progress so far
[17:33] <AndrewGee> Any MOTUs available to give the second adovation to osm-gps-map, a GTK widget to embed openstreetmap? http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[17:51] <ScottK> iefremov: Test building now.
[17:53]  * iefremov waits
[17:56]  * sistpoty|work calls it a day... cya
[17:59] <loic-m> Can a MOTU comment if it's the lintian error that's preventing cdemu related packages to be advocated? (see f.e. http://revu.ubuntuwire.com/details.py?package=cdemu-daemon )
[18:01] <mok0> loic-m: the standard solution is to delete them again in the clean target
[18:02] <mok0> loic-m: heh, it's being done backwards in rules
[18:05] <loic-m> mok0: deleting what?
[18:05] <mok0> config.sub, config.guess
[18:06] <loic-m> mok0: I talked with the uploader about that a few days ago (I hadn't spotted the pb, sistpoty did)
[18:07] <mok0> loic-m: it's a construction from before the dogma that there should be no changes outside debian/
[18:07] <loic-m> mok0: he said he can update the pkg if it's a necessity, but was afraid the pkg wouldn't make it for jaunty
[18:07] <mok0> loic-m: well... if he doesn't update it, he can be certain that it wont make it :-)
[18:08] <loic-m> mok0: That's why I wanted to make sure that would prevent the package to be advocated
[18:08] <mok0> loic-m: we might as well see if there are other things as wll
[18:09] <loic-m> mok0: I'll email him then, unless you can state that in REVU
[18:09] <loic-m> mok0: that would be really nice
[18:09] <mok0> loic-m: I'll look at the pkg tonite, right now I have to go for dinner
[18:11] <loic-m> mok0: thanks for you time. Enjoy your meal ;)
[18:12] <mok0> loic-m: thanks, :-) see you later
[18:21] <doctormo> thanks for your helps guys +1, just waiting for ppa building now
[18:55] <kirkland> okay, i'm missing a -X.bzr somewhere in my debian/rules file and I can't figure out where
[18:56] <kirkland> i'm getting a lintian warning, diff-contains-bzr-control-dir .bzr
[18:58] <pochu> kirkland: I think you want dpkg-buildpackage -I
[18:58] <kirkland> i tried to export DH_OPTIONS=-X.bzr at the top of debian/rules, but no luck
[18:58] <pochu> or dpkg-buildpackage -i, not sure
[18:58] <pochu> kirkland: that won't help, the problem is in the diff.gz which is generated independtly of your call to debian/rules
[18:58] <pochu> independently even
[18:59] <kirkland> pochu: ah, okay
[18:59] <pochu> kirkland: you can use -I.bzr and things like that, but the default regexp already includes that and a bunch more
[18:59] <pochu> so just "-I" should do the trick
[18:59] <kirkland> pochu: aha, found it!
[19:00] <kirkland> pochu: i haven't copied over my .devscripts file to my new machine :-)
[19:00] <kirkland> pochu: where i set all of that magic "once and for all" (almost)
[19:01] <pochu> heh
[19:01] <kirkland> pochu: woohoo, thanks for the pointer \o/
[19:01] <pochu> yw :)
[19:02] <pochu> btw, does dpkg-buildpackage read .devscripts ?
[19:03] <pochu> my .devscripts is one liner...
[19:06] <ScottK> iefremov: Advocated.  Catch mok0 when he comes back and see if he'll advocate/upload.
[19:07] <iefremov> ScottK: ok, thanks!
[19:10] <fabrice_sp> Hi. Can some MOTU have a look at my debdiff in Bug #318967?
[19:10] <fabrice_sp> thanks
[19:20] <kaktus2278_> http://www.pennergame.de/change_please/5920981/
[19:43] <ia> hello. if i have i386 machine and tgz image(also for i386, i suppose) for pbuilder on it, is it possible to compile binary package for amd64 architecture? and which values available for "--binary-arch" option in pbuilder?
[19:44] <fabrice_sp> Hi ia
[19:44] <fabrice_sp> no: to build an amd64 package, you need a adm64 machine
[19:45] <fabrice_sp> but in a amd64, you can build i386 packages
[19:46] <fabrice_sp> (this is why I switch to amd64)
[19:47] <ogra> qemu should be able to emulate amd64 on i386
[19:47] <ogra> but its not fast
[19:48] <fabrice_sp> or virtualbox, if you have a virtualization enabled CPU
[19:48] <ogra> vbox can emulate adm64 ?
[19:48] <ogra> thats new to me
[19:48] <fabrice_sp> ogra, there is an option that you can use if you CPU has the VM option, yes
[19:48] <fabrice_sp> it's new in 2.1
[19:48] <ogra> ah
[19:49] <fabrice_sp> for that, you need VT-X/AMD-V compatible CPU
[19:49] <ia> fabrice_sp: well, it's very hard to belive (at least, for me :-) that there is no any native way to crosscompile debpackage for amd at x86 :-/
[19:50] <fabrice_sp> ia, I looked at cross compilation, but the package has to be prepare for that (As far as I remember)
[19:50] <fabrice_sp> you can still have 2 installations of Ubuntu: one i386 and one amd64
[19:51] <fabrice_sp> and dual boot
[19:51] <fabrice_sp> but I didn't find an other way 6 months ago
[19:51] <pochu> PPA!
[19:52] <fabrice_sp> pochu: you're right!
[19:52] <ia> fabrice_sp: well, i don't have amd(or any other 64 machine) :-)
[19:53] <fabrice_sp> ia, pochu is pointing you at PPA
[19:53] <fabrice_sp> amd64 is not amd only (my CPU is intel)
[19:54] <pochu> !ppa | ia
[19:54] <ia> fabrice_sp: yeah, i know - it's a possible solution (ppa), but i just would like to have ability build packages for misc archs at my computer :-)
[19:56] <ia> talking about archs - if processor (32 bit) have HyperThreading feature, should 64bit version of ubuntu correctly runs on it?
[19:57] <fabrice_sp> ia, what is you CPU?
[19:57] <pochu> I think they are unrelated, but I'm no expert in the field
[19:58] <ia> fabrice_sp: intel atom n270 (eeepc 901)
[20:03] <AndrewGee> Hi all. I thought I'd have a look at learning how to do a merge. I've used grab-merge to get conky from MoM. There is a patch in the Ubuntu version that isn't included in the Debian version. What should I do?
[20:05] <fabrice_sp> ia, doesn't seem to be 64 enabled
[20:08] <ia> and another question about archs - if i use 64bit version and install some 32bit binary package, it should runs correctly, right?
[20:08] <fabrice_sp> AndrewGee, see if the patch still apply. If it still apply, do the merge. If not, request the sync
[20:10] <AndrewGee> fabrice_sp: Okay. It still applies so I'll do a merge. Should I file a launchpad bug then?
[20:11] <fabrice_sp> AndrewGee, yes. You need the launchpad bug to request sponsorship when ready, so that a MOTU upload your merge
[20:11] <AndrewGee> fabrice_sp: Okay. Thanks for your help :)
[20:12] <fabrice_sp> AndrewGee, you're welcome. And good luck with the merge ;-)
[20:14] <AnAnt> bddebian: hide
[20:17] <lfaraone> If I'm dealing with a complex multi-bin package and trying to enable a lib in its buildscripts to end up in a different bin package, how exactly would I do that?
[20:19] <pochu> lfaraone: tell make install everything into debian/tmp, and then use dh_install to install files into each package
[20:21] <lfaraone> pochu: /me reads man dh_install :)
[20:21] <_stochastic_> I'm trying to write a machine-readable copyright file, and according to the specification, the entire text of each license needs to appear in the file, but lintian is telling me this is wrong, and that I should be pointing people to /usr/share/common-licenses/
[20:22] <_stochastic_> which should I listen to?  can/should I do both?
[20:23] <lfaraone> _stochastic_: latter.
[20:23] <lfaraone> _stochastic_: example: http://changelogs.ubuntu.com/changelogs/pool/main/g/gnome-python-desktop/gnome-python-desktop_2.24.1-0ubuntu1/python-gnome2-desktop.copyright
[20:24] <_stochastic_> lfaraone, that's not a machine-readable format though, see: http://wiki.debian.org/Proposals/CopyrightFormat
[20:25] <lfaraone> _stochastic_: that's a proposal, and isn't policy.
[20:25] <lfaraone> _stochastic_: debian policy says lintian is right.
[20:26] <_stochastic_> lfaraone, in REVU, mok0 told me to follow the machine-readable format
[20:27]  * _stochastic_ is confused and starting to jog in circles
[20:27] <lfaraone> _stochastic_: is there a reason you arn't submitting your package to Debian?
[20:27] <_stochastic_> lfaraone, because I run ubuntu
[20:28] <lfaraone> _stochastic_: (tbh, I think it's always better to submit to debian and req a sync locally, that way you get your package in all Debian derivitives)
[20:28] <lfaraone> _stochastic_: So? I'm an Ubuntu member and have no debian boxes at all, yet I still ran http://packages.ubuntu.com/jaunty/python-gasp through debian.
[20:28]  * _stochastic_ is just starting to wrap his head around the Ubuntu review process
[20:29] <lfaraone> _stochastic_: what's your package?
[20:29] <_stochastic_> http://revu.ubuntuwire.com/details.py?package=calf
[20:29] <_stochastic_> that last upload has a faulty rules file
[20:30] <lfaraone> _stochastic_: bah, I'm just looking at  http://revu.ubuntuwire.com/revu1-incoming/calf-0901261109/calf-0.0.18/debian/copyright
[20:31] <lfaraone> _stochastic_: Are you expecting this to land in Jaunty or Jaunty+1?
[20:31] <_stochastic_> lfaraone, I'm hoping for Jaunty
[20:32] <lfaraone> _stochastic_: you'll have to get it fixed and sponsered prior to Feb15 then. :)
[20:32] <_stochastic_> I know the deadlines
[20:32] <_stochastic_> I'm working away at it
[20:33] <lfaraone> _stochastic_: ok, it makes sense to try to go through Ubuntu's NEW. But I _highly_ recommend getting it into Debian once you've got it working in Jaunty. If you want, you can ask the Utnubu people for help.
[20:34] <lfaraone> (syncing will be too slow in this case)
[20:35] <lfaraone> _stochastic_: at that point, also look into "collab-maint", they're the Debian MOTU analog. (with smaller scope)
[20:35] <_stochastic_> I'll cross that bridge when I come to it
[20:36] <_stochastic_> I'm worried about copyright files conflicting with lintian right now
[20:37] <lfaraone> _stochastic_: Ok.
[20:37] <lfaraone> _stochastic_: The page you were citing is a proposal. I advise that you listen to lintian as it's correct in this case, since it is following Debian/Ubuntu policy.
[20:54] <AndrewGee> I think I've just completed my first ever merge okay :) If anyone is free, could they have a little check for me? Thanks. https://bugs.edge.launchpad.net/ubuntu/+source/conky/+bug/322035
[20:59] <fabrice_sp> AndrewGee, sorry to say that, but norsetto put as comment in Dad: no need to update to 1.6.1-1
[21:00] <fabrice_sp> (http://dad.dunnewind.net/universe.php)
[21:00] <AndrewGee> fabrice_sp: Oh. Whoops.
[21:00] <AndrewGee> Nevermind.
[21:01] <AndrewGee> Well I guess I learnt some stuff :)
[21:01] <AndrewGee> fabrice_sp: Should I set the status of the bug to invalid and everything then?
[21:01] <_stochastic_> I'm having troubles understanding how to get the icon set in my package to install properly,  does anyone want to take a look: http://revu.ubuntuwire.com/details.py?package=calf
[21:01] <jmarsden|work> xnox: I'm seeing multiple emails about GnomeSword FTBFS... looks like it needs Build-Depends: scrollkeeper
[21:02] <fabrice_sp> AndrewGee, yes, please. Anyway, I was looking at your merge, and  it looks good
[21:02] <AndrewGee> fabrice_sp: Thanks. Hopefully I'll find a good package to try with next time :)
[21:02] <fabrice_sp> AndrewGee, Hope so ;-)
[21:03] <fabrice_sp> Just look in dad before, and ping the previous uploader, to be sure it's worth working on it
[21:04] <AndrewGee> fabrice_sp: I'll bare that in mind for next time :) - I just looked in MoM, so didn't see that :p
[21:06] <fabrice_sp> :-)
[21:10] <gregor_> When will be the kde files from today included into Ubuntu?
[21:26] <stdin> gregor_: when they are built
[21:26] <gregor_> stdin, is there an option to follow this or get noticed when it is done?
[21:27] <stdin> it'll show in http://www.kubuntu.org/news/kde-4.2 (and the #kubuntu topic)
[21:32] <gregor_> btw. http://status.qa.ubuntu.com/ the navigation does not work without javascript.
[21:41] <AndrewGee> Any MOTUs available to review one of the two new packages I'm working on? pyofa - Python module to create audio fingerprints. python-xmltv - Python module to read xmltv data. http://revu.ubuntuwire.com/details.py?package=pyofa http://revu.ubuntuwire.com/details.py?package=python-xmltv - Thanks :)
[21:44] <jmarsden|work> How can I find out why a package (kio-sword) is in hardy but not in intrepid or jaunty?
[21:45] <pochu> AndrewGee: are you interested in getting those into Debian too?
[21:45] <AndrewGee> pochu: Yeah. I thought I'd try and get them into Ubuntu first, however.
[21:45] <pochu> AndrewGee: meet POX; POX: meet AndrewGee :)
[21:46] <pochu> AndrewGee: he can help you get those into Debian, then they can be synced into Ubuntu
[21:46] <pochu> jmarsden|work: http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt has the reason
[21:46] <AndrewGee> pochu: Okay then.
[21:46] <pochu> jmarsden|work: kio-sword #jriddell needs KDE 3
[21:46] <jmarsden|work> pochu: Thanks!
[21:46] <pochu> yw
[21:47] <pochu> AndrewGee: of course you can still try to get them into Ubuntu directly, your call
[21:49] <AndrewGee> pochu: I'll go and modify the packages for Debian and upload to Debian mentors, I think.
[21:50] <pochu> AndrewGee: I'd rather get in touch with POX and/or ask in the debian-python@ ml and #debian-python in OFTC. For Python stuff, that's much much better than Debian mentors, really
[21:50] <AndrewGee> pochu: Okay. Will do.
[21:59] <Chris`> What is the date of the feature freeze?
[22:00] <Chris`> And what exactly does that mean?
[22:00] <pochu> it means no new features in any package without an exception from the release team
[22:00] <pochu> see wiki.u.c/JauntyReleaseSchedule for the date
[22:00] <Piratenaapje> is # See COPYING for info about the license (GNU GPL)
[22:00] <Piratenaapje> # Check AUTHORS to see who wrote this software.
[22:01] <pochu> I think it's feb 19
[22:01] <Piratenaapje> enough in every source file?
[22:01] <Chris`> But new packages can be uploaded?
[22:01] <Piratenaapje> or do I need to include the 4 paragraph GPL clause?
[22:01] <pochu> Piratenaapje: not ideal, but I think it's ok
[22:01] <pochu> Piratenaapje: but the full paragraph is better
[22:02] <Piratenaapje> pochu: Well, it's only 10 files, I'll replace it I guess
[22:02] <Chris`> pochu: Does a feature freeze mean that new software cannot be uploaded?
[22:02] <pochu> Chris`: I think they won't be processed by the archive admins unless there's a good reason
[22:02] <Chris`> pochu: Ah OK then thansk
[22:02] <pochu> Piratenaapje: I assume you're upstream, right? :)
[22:02] <pochu> Chris`: that's what I remember from past cycles, maybe this one it's different :)
[22:03] <pochu> Chris`: how's your package doing? does it still have my advocate?
[22:03] <Piratenaapje> pochu: Not really, I made some modifications and upstream is either going to release my version or make me upstream as well
[22:03] <pochu> ah, cool
[22:03] <Chris`> pochu: It's a different package but I'm still trying to get upstream to sort their copyright before the release
[22:03] <pochu> Piratenaapje: I mean, you don't want to add license headers in a patch ;)
[22:03] <pochu> Chris`: which one is it?
[22:04] <Piratenaapje> pochu: I tried to do that the previous time, wasn't allowed to :P
[22:04] <Chris`> pochu: The package is called crrcsim, there's an Ubuntu bug filed for it but I haven't uploaded anything yet, I'm in contact and waiting for a new tarball/version
[22:05] <Chris`> To hurry them up shall I include at the end of my current email to them "There however one small problem, Ubuntu is going into a feature freeze at Feb 19th which means that the archive admins may not process my request." ?
[22:05] <Piratenaapje> should I list all authors next to "Copyright (C) 2009  " ?
[22:24] <petski> Could one of you MOTU's please take a look at #276603. It's an SRU for main, but the devels would like to see it in intrepid-proposed (and I'm not allowed to upload in -proposed)
[22:29] <pochu> petski: only core-devs can upload to main (even for -proposed)
[22:29] <pochu> bug 276603
[22:30] <pochu> petski: can you ask in #ubuntu-desktop?
[22:30] <petski> I will. Thank pochu
[22:33] <petski> Second question: bug 276603 needs a MOTU hug :)
[22:33] <petski> arf, that was a copy-paste error, wait :)
[22:35] <petski> Now for real: Second question: bug 77980 needs a MOTU hug :)
[22:41] <binarymutant> can someone help me with a distutils problem? I'm trying to use the --prefix option to install to /usr/ instead of /usr/local/ but when I do I get dependency errors :(
[22:43] <pochu> binarymutant: if you use CDBS, the distutils class will do it for you
[22:43] <binarymutant> here's my rules file, http://paste.ubuntu.com/110491/
[22:43] <binarymutant> pochu, CDBS > pycentral?
[22:44] <directhex> dh7!
[22:44] <pochu> binarymutant: no, CDBS > debhelper
[22:44] <pochu> binarymutant: can you paste the error too?
[22:44] <binarymutant> I was seeing the error with gdebi
[22:46] <binarymutant> http://paste.ubuntu.com/110495/
[22:47] <binarymutant> ok hang on, heres my control file, http://paste.ubuntu.com/110498/
[22:48] <binarymutant> why does it say that this app depends on python2.6 when I use python-all(>=2.5) in my control? I think thats the problem
[23:04] <pochu> binarymutant: btw you want ${binary:Depends} in depends too
[23:10] <binarymutant> pochu, what is that for?
[23:11] <pochu> err
[23:11] <pochu> misc:Depends, sorry
[23:11] <pochu> binarymutant: no idea about your error, I think dh_pycentral should put python >= 2.5 in depends...
[23:12] <pochu> maybe ScottK or POX know about it
[23:12] <binarymutant> thanks for listening :)
[23:12] <pochu> I haven't had that problem myself
[23:12] <pochu> anytime
[23:13] <pochu> ah!
[23:13] <pochu> binarymutant: look for the shebangs... you probably have a #!/usr/bin/python2.6 one there
[23:14] <pochu> or just `grep -R python2.6 *`
[23:14] <binarymutant> nothing
[23:16] <pochu> can you put the package somewhere?
[23:16] <pochu> is it on REVU?
[23:18] <binarymutant> ya its on revu
[23:19] <binarymutant> http://revu.ubuntuwire.com/details.py?package=charm
[23:19] <pochu> ok let me have a look
[23:19] <pochu> it's been already uploaded, isn't it?
[23:20] <binarymutant> yes its already in the New queue :/
[23:20] <binarymutant> I built the deb over the weekend and realized it installed to /usr/local
[23:21] <pochu> you don't need that patch to workaround it
[23:22] <binarymutant> oh yeah, that latest upload is still bad, I'm using the --prefix option in the rules file now. Sorry
[23:22] <binarymutant> http://paste.ubuntu.com/110491/
[23:22] <pochu> ok, no problem
[23:22] <pochu>  Depends: python (>= 2.5), python-central (>= 0.6.7)
[23:23] <pochu> I get that building it in Debian
[23:24] <loic-m> nhandler: ping: could you please review the changes I made to ecm at http://revu.ubuntuwire.com/details.py?package=ecm ?
[23:25] <pochu> binarymutant: I'm off to bed, feel free to ping me tomorrow if you have problems or want a review
[23:25] <binarymutant> thanks pochu
[23:26] <pochu> binarymutant: also, if you want it into Debian, ping POX. There's a Python Applications Team there (I myself have a few apps maintained there)
[23:26] <pochu> good night
[23:26] <binarymutant> night, thanks :)
[23:51] <Riddell> is Ivan Efremov about?