[00:03] <Legendario> ion_, thanks. Do i have to build the source again?
[00:12] <jdong> what's the etiquette with the /^REVU: New/ messages on ubuntu-motu? When should they be sent, etc?
[00:13] <crimsun> after you've uploaded and received the NEW.
[00:16] <Legendario> got make erro number 2
[00:17] <Legendario> No rule to make target `/home/kemel/Downloads/Cube/cube-2005.08.29/enet'.  Stop.
[00:17] <Legendario> any clues?
[00:17] <jdong> crimsun: ah, okay. Good to know :)
[00:21] <sladen> Legendario: broken make file?
[00:22] <Legendario> sladen, i guess not... it was not finding the make file that was not on the usual place. So i used the DEB_MAKE_MAKEFILE string ion_ have given me
[00:23] <Legendario> but now i got this message.
[00:24] <ion_> Perhaps you need to give something called enet to it before building.
[00:26] <Legendario> no, the /enet is the folder where the make file is
[00:26] <Legendario> ion_
[00:27] <Legendario> am i doing something wrong. i wrote on the debian/rules:
[00:27] <Legendario> DEB_MAKE_MAKEFILE = /home/kemel/Downloads/Cube/cube-2005.08.29/enet
[00:27] <mok0> ScottK: New courier patch... :-/
[00:28] <mok0> ScottK: Not proud of that...
[00:29] <ion_> legendario: Use a relative path, and that’s not the full path to the Makefile. If you want -C instead of -f, there’s a CDBS variable for that as well.
[00:30] <Legendario> ion_, sorry. could u be more specific?
[00:38] <ion_> legendario: DEB_BUILDDIR is passed as the -C parameter and DEB_MAKE_MAKEFILE as the -f parameter. See make(1). Neither should be an absolute path.
[00:38] <ScottK> mok0: Stuff happens.  I didn't suggest you do courier because it would be easy.
[00:40] <mok0> ScottK: I knew as soon as I hit return that it was a mistake. I should've reverted it before I uploaded the patch, but I only thought of diff -b after your comment
[00:40] <ScottK> No problem.  I'll try and have a look at it tonight.
[00:42] <mok0> ScottK: The init scripts are a bit closer to the debian version. I slightly modified the postinst scripts to make sure /etc/courier exists. I don't know if that explains the russian guys problems, it's a bit far fetched for an upgrade.
[00:43] <ScottK> Usually it's /var/run on a tempfs disappearing when they reboot in the middle of an upgrade to 'fix' something.
[01:11] <Legendario> ion_, so how should i write on the file?
[01:17] <ScottK2> Legendario: Is the package named Cube and your current version is cube-2005.08.29?
[01:17] <Legendario> Scottk2, yes.
[01:21] <ScottK2> What you probably want is $(CURDIR)/enet.  That's a relative path from with the package structure to /home/kemel/Downloads/Cube/cube-2005.08.29/enet
[01:23] <Legendario> ScottK2, thanks dude. That's probably the solution.
[01:24] <ScottK2> No problem.
[01:25] <Legendario> ScottK2, so. it would be: DEB_MAKE_MAKEFILE = ($CURDIR)/enet
[01:25] <Legendario> right?
[01:25] <ScottK2> I think so.
[01:25] <Legendario> great. :-D
[01:25] <Legendario> let me try it
[01:35] <Legendario> ScottK2 still getting error2
[01:35] <Legendario> /bin/sh: Syntax error: "(" unexpected
[01:35] <Legendario> make: *** [debian/stamp-makefile-build] Error 2
[01:36] <ScottK2> OK.  Well play around with it.  That's the sort of syntax yo uwant.
[01:39] <ion_> First, you do not pass a directory to -f, but a filename. Second, you might want -C instead, see make(1). Third, you probably won’t need $(CURDIR) in front of enet. Fourth, $(, not ($
[01:41]  * StevenK sighs. I need notes of what I did so I can undo it again
[01:41] <ion_> Look at the version control history.
[01:42] <ScottK2> rm -rf *
[01:42] <StevenK> ion_: This doesn't help when I'm hacking files directly on an install
[01:42] <ScottK2> That'll take you back to where you started.
[01:42] <TheMuso> StevenK: Still battling that segfault?
[01:42] <StevenK> ScottK2: I've been looking at this problem for the better part of 15 hours, it so won't.
[01:43] <RAOF> Hm.  How's this for a copyright header "GNOME Do is the legal property of its developers.  Please refer to the COPYRIGHT file distributed with this source distribution", then the standard GPL headers.
[01:43] <StevenK> TheMuso: Yup.
[01:43] <ScottK2> Oh.  Nevermind.
[01:43] <RAOF> StevenK: That sounds particularly suckworthy.
[01:45]  * StevenK thinks he has sorted it out
[01:49] <zul> evening
[01:50] <ScottK2> Yes it is.
[01:50] <StevenK> ScottK2: And how sarcastic is your mood tonight?
[01:51] <ScottK2> Middle sarcastic.
[01:53] <slangasek> Anglo-Sarcastic with some Norman influence
[01:53] <crimsun> saivann: did you file #189790?
[01:56] <ScottK2> It can't be as bad as the MOTU that filed a but with Debian suggesting they incorporate our change in a package and remove the iceweasel symlinks.
[01:57] <saivann> crimsun : Yes
[01:57] <Legendario> i gotta go now... thanks for all the help. I'll be back if in need.
[01:57] <TheMuso> ScottK2: ouch
[01:58] <ScottK2> Yeah.  I've spoken to him about it.  He feels bad.
[01:58] <TheMuso> ScottK2: Whoever did that needs to be publically shamed.
[01:58] <TheMuso> IMO
[01:58] <ScottK2> I think we've had enough of that for a while.  I figure I'll write a mail to the MOTU ML soon and anyone who wants to know who it is can figure it out.
[01:59] <ScottK2> Just as a reminder.
[01:59] <crimsun> saivann: while the current source package is suboptimal (!), to ship the binary tarball with the source package is a violation of their license.
[01:59] <TheMuso> ScottK2: Fair enough.
[01:59] <saivann> crimsun : Do you think that it could be considered as a potential long-term solution for the actual problems with flashplugin?
[01:59] <StevenK> ScottK2: Shall we say it was TheMuso and publically shame him?
[01:59]  * StevenK chuckles
[01:59]  * TheMuso gawks at the storm out the window. That storm shoudln't be for another 3/4 hours. :p
[01:59]  * ScottK2 smiles
[02:00] <TheMuso> StevenK: Oh very nice.
[02:00] <StevenK> TheMuso: Sorry, I couldn't resist.
[02:00] <RAOF> TheMuso: What?  You've got the storm too?
[02:00] <ScottK2> I don't think I've seen StevenK and nice in the same sentence before.
[02:00] <TheMuso> RAOF: Yeah, one popped up out of nowhere.
[02:00] <StevenK> It looks stormy here too
[02:00] <saivann> crimsun : That's why I suggest canonical to look if it's possible to have these special rights, but perhaps that I'm too much idealistic
[02:00] <crimsun> saivann: if Canonical were to obtain such a permission, I see no reason for it to even exist.
[02:00] <ScottK2> It mostly looks dark here.
[02:01] <TheMuso> Although it doesn't look like its going to either last long, or give much of a problem.
[02:01] <crimsun> saivann: the point is that as the license currently stands, including the tarball with the source package is a no-go.
[02:01] <saivann> crimsun : Right, would you suggest to set the bug to wontfix?
[02:01] <TheMuso> Lightning sounds like its only cloud to cloud, judging by thunder clap sound.
[02:01] <crimsun> saivann: I would, correct.
[02:01] <saivann> crimsun : Thanks for your confirmation on this
[02:02] <ScottK2> I'm probably just bitter about Canonical core-dev applicants getting head of the line priviledges.
[02:05] <TheMuso> ScottK2: I agree with you, even though I'm no longer in such a position.
[02:05] <ScottK2> If that were the policy, then I'd be fine with it.
[02:08] <crimsun> TheMuso: yay, you're core now?
[02:09] <TheMuso> crimsun: No.
[02:09] <TheMuso> Not yet.
[02:09] <crimsun> d'oh
[02:09] <TheMuso> Was supposed to be last week, but only mdz was around for the meeting, so it didn't happen.
[02:10] <TheMuso> So next week.
[02:10] <crimsun> excellent, right on FF
[02:10] <ScottK2> If they took as in straight order, I'd have been next.
[02:11] <ScottK2> Instead there are two Canonical employees stuffed in ahead.  One of which was one day after the MC gave their approval.
[02:11] <ScottK2> I also asked him if there was any reason he knew of to rush his application and he said no.
[02:12] <TheMuso> crimsun: Better than nothing.
[02:21] <TheMuso> Yay. Manual merge complete. Now to test.
[02:21] <ScottK2> Does anyone know if Debian mia-query works for non-DD maintainers (and if so is there someone with access who'd be willing to check on something for me?).
[02:25] <bddebian> Heya gang
[02:25] <ScottK2> Heya bddebian
[02:25] <bddebian> Hi ScottK2
[02:26] <uniscript> is it my imagination or did pbuilder change syntax from say pbuilder build to pbuilder --build?
[02:29] <TheMuso> StevenK: I take it from your upload, things are fixed?
[02:30] <StevenK> Looks like
[02:31] <Hobbsee> ScottK2: they still *should* be able to do 3 at once, i thought
[03:17] <ScottK2> Hobbsee: There are already 2 Canonical employees added today.
[03:17] <effie_jayx> is it possible to do an package upgrade when upstream has not documented the changes properly ? I have removed all the files that got removed in the new version
[03:17] <Hobbsee> ScottK2: they can't do 3 total?
[03:17] <effie_jayx> but the added files are the ones I should include in the install
[03:19] <ScottK2> Hobbsee: I don't know how many they can do.  There are now three on the agenda.
[03:19]  * effie_jayx thinks about droping the idea
[03:19] <ScottK2> effie_jayx: If they messed up the release tarball and put wrong files in it, ask them to release a new one.
[03:20] <ScottK2> Hobbsee: I just don't get any sign they are interested in community applicants right now.
[03:21] <Hobbsee> ScottK2: perhaps so - but i didn't think they were all canonical members on the TB
[03:21] <effie_jayx> ScottK,  the source package from upstream has no changelog that can really document the changes to the software
[03:21] <TheMuso> Hobbsee: Only mjg59 is not Canonical.
[03:21] <Hobbsee> ah right
[03:22] <ScottK2> effie_jayx: Then you can document the changes in debian/changelog.
[03:22] <effie_jayx> I think I am not making myself understood :S
[03:23] <effie_jayx> 1) the URL to the proyect in debian/copyright is not the url to the proyect anymore.
[03:24] <effie_jayx> 2) upstream released 2.2 without a comprehensive list of changes from 1.1
[03:24] <effie_jayx> hence it would explaing why the packages is orphan in debian
[03:25] <ScottK2> Is it the same upstream moving to a new location or a new developer that's grabbed/forked the package?
[03:25] <effie_jayx> yet we have ubuntu users saying... "I emailed the developer he says we should upgrade to 2 as version 1 is not supported"
[03:25] <effie_jayx> ScottK2, same developer
[03:25] <effie_jayx> ScottK2, http://kipina.sourceforge.net/
[03:26] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[03:26] <ScottK2> Then update debian/copyright to the new location and document the changes as best you can in debian/changelog.
[03:28] <effie_jayx> ScottK2,  right... If I could only figure out the changes made by the developer... aparently the package is missing files (the ones version from 0.1.1) and the new files that the developer included are ????
[03:29] <ScottK2> Right.  It doesn't have to be detailed.
[03:29] <effie_jayx> I removed files from kipina.install but what are the new files he included
[03:29] <ScottK2> If he's using sourceforge and their CVS, there will be commit logs that might be useful.
[03:30] <effie_jayx> ScottK2,  :S
[03:32] <effie_jayx> ScottK2,  you have to admit I did pick a tought scenario for a beginner to be in ;)
[03:32]  * effie_jayx has a knack for dead ends 
[03:33] <jdong> poor effie_jayx, it seems like all the bugs you pick are cursed :)
[03:33] <TheMuso> effie_jayx: THink of it this way. Its making you a better MOTU in the process.
[03:34] <effie_jayx> well, It is frustrating as well
[03:34]  * effie_jayx looks for a bug to fix in something like xteddy 
[03:34] <effie_jayx> :D
[03:35] <TheMuso> Yes, true.
[03:35] <effie_jayx> nah really. I'll put it to rest for a week and see... a new bug is what I need
[03:36] <leonel> scottK I had no time today to check that list tomorrow I MUST give time to it  I hope it's not too late
[03:37] <jdong> effie_jayx: I'll think of you and keep my eyes open as I triage bugs for things that might have happier endings :)
[03:38] <effie_jayx> jdong,  I'll step up. I promiss
[03:40] <jdong> :)
[03:41] <ScottK> leonel: No.  Not to late.
[03:42]  * jdong looks at KTorrent in gutsy and wonders if it's massive SRU time again :(
[03:42] <jdong> urgh I hate telling people "this crash is fixed in gutsy-backports"
[03:43] <jdong> the problem is, there's about 5 distinctive crasher bugs, none of which can be readily reproduced in a 1-2-3 step method, it's all highly dependent on specific circumstances...
[03:43] <jdong> the last KT SRU took nearly 3 months to roll out and by that time it was already pretty useless
[03:55] <rootvzla> hi ^^
[03:57] <TheMuso> If I remember correctly, if an orig tarball is repacked, the tarball name shoudl reflect that correct?
[03:58] <jdong> TheMuso: yeah, either .dfsg or [\.+]repack
[04:00] <TheMuso> jdong: Right, thanks.
[04:00] <TheMuso> jdong: -EPARSE
[04:00] <jdong> TheMuso: I don't know if it's our mandatory policy, but usually get-orig-source in debian/rules to auto-do the repack?
[04:01] <TheMuso> jdong: right
[04:01] <jdong> TheMuso: regex, .repack, +repack, etc
[04:01] <TheMuso> jdong: Regexps are not my strong point. I assume you mean packagename.repack.orig.tar.gz
[04:01] <jdong> sorry, I've been (over)using regex a lot recently... it's made it into everyday conversations too
[04:02] <TheMuso> scary
[04:02] <jdong> packagename_upstreamver.repack1.orig.tar.gz
[04:02] <jdong> or +repack1
[04:02]  * TheMuso tres to think of a nice way to say "use google" on a mailing list
[04:02] <TheMuso> right
[04:02] <TheMuso> thanks
[04:02] <jdong> sure thing :)
[04:03] <superm1> TheMuso, you perform the search with some terms and copy the url that's in your address bar, and say "in the future, you can find answers to similar things like this"
[04:04] <TheMuso> superm1: Right. Its someone who couldn'
[04:04] <TheMuso> argh
[04:04] <TheMuso> superm1: Right. Its someone who couldn't be bothered doing their own googling.
[04:04] <superm1> yeah so you just give them the nudge with the example google search
[04:04] <TheMuso> So in that case, I couldn't be bothered googling myself.
[04:04] <superm1> and hope that they get the right idea
[04:04] <TheMuso> right
[04:08] <TheMuso> Right. Thats out of the way.
[04:08] <ScottK2> TheMuso: You can always hand them a copy of this: http://www.sabi.co.uk/Notes/linuxHelpAsk.html
[04:09] <ScottK2> I didn't mean that one.  Oops
[04:09] <TheMuso> ScottK2: If he bothers me again, I will.
[04:09] <ScottK2> I meant this one http://www.catb.org/~esr/faqs/smart-questions.html
[04:09] <TheMuso> thanks
[04:29] <TheMuso> ember: Thanks for your prompt update.
[04:29] <TheMuso> I'll take another look.
[04:55]  * TheMuso thinks about writing a message to -motu about checking copyright notices in REVU packages. I've found a package that appears to have been rejected, and it had one ACK, yet the licensing to me appears incorrect, re debian/copyright.
[04:57] <ScottK> TheMuso: Please do.  I've been pondering the same thing myself.
[04:57] <TheMuso> ScottK: Just to be clear, the library GPL is not the same as the lesser GPL is it.
[04:58] <ScottK> One is version 2 and one is version 2.1/3.  I always have to look it up.
[04:58] <TheMuso> right
[04:58] <ScottK> IIRC 2 == lesser
[04:58] <TheMuso> yep you're correct
[04:59] <ScottK> So far I've caused two repacked tarballs this due to non-distributable/linkable stuff that others missed.
[04:59] <TheMuso> heh
[04:59] <TheMuso> So far I've knocked back a package because of debian/copyright stating lesser, when its library
[05:01] <TheMuso> Hrm. I think I'll return to a package update now.
[05:01] <ScottK> Of course no one's perfect.  During the Gutsy cycle I downchecked a package due to debian/copyright deficiencies that had been put on REVU by an archive admin.
[05:02] <TheMuso> Right. heh.
[05:09] <Hobbsee> that wasn't me
[05:09]  * Hobbsee just has the advantage of not doing new packages.
[05:09] <jdong> Hobbsee: makes life happier :)
[05:09] <Hobbsee> ScottK: i like your mail
[05:10] <TheMuso> ScottK: Yeah, me too.
[05:10] <Hobbsee> awww, shit.
[05:10] <jdong> ScottK: yeah, me $last+1
[05:10] <TheMuso> Oh well, upstream don't look like they're going to do a new upstream release any time, guess I'll upload this snapshot with tons of bug fixes in it.
[05:11] <TheMuso> c/
[05:29] <ScottK> Thanks
[05:31] <LucidFox> speaking of +1, this reminds me
[05:31] <LucidFox> Is it known when the name of Hardy+1 will be revealed?
[05:33] <ScottK> Probably just after it's to late to upload a lintian that knows about it for Hardy's release.
[05:34]  * Hobbsee snorts
[05:34] <Hobbsee> ScottK: good answer
[05:34] <TheMuso> lol
[05:35] <jdong> Jumpy.......
[05:35] <jdong> umm.....
[05:36] <jdong> jackrabbit?
[05:36] <jdong> the release of ridiculous visual effects?
[05:36] <jdong> or where  we get bouncy dock icons?
[05:36] <ScottK> Itchy Iguana
[05:37] <LucidFox> I'm 90% certain it will be Itchy, but no sure about the animal
[05:57]  * StevenK doesn't like the sound of Itchy
[06:35] <RAOF> jdong: Too late; bouncy dock icons are here *now* (lp:awn)
[06:51] <AnAnt> Hello, I am using cdbs, and I need to pass a -l<path> to dh_shlibdeps, how can I do that ?
[06:52] <ion_> DEB_SHLIBDEPS_INCLUDE_packagename, or DEB_SHLIBDEPS_INCLUDE for all packages
[06:54] <AnAnt> oh, thanks
[06:54] <AnAnt> ion_: where can I find such info ?
[06:55] <ion_> I just looked at the cdbs source.
[06:56] <ion_> cd /usr/share/cdbs/1, grep -r shlibdeps ., oh, there’s an DEB_DH_SHLIBDEPS_ARGS, grep -r DEB_DH_SHLIBDEPS_ARGS ., oh, its definition contains -l $(shell echo $(DEB_SHLIBDEPS_INCLUDE_$(cdbs_curpkg)):$(DEB_SHLIBDEPS_INCLUDE) | perl -pe 's/ /:/g;')
[06:57] <AnAnt> I see, thanks
[07:36] <Hobbsee> ScottK: your mail really does scare me.
[07:43] <slytherin> geser: Is there any work remaining from my side on lucene2? Or is it just that you are very busy? :-)
[08:05] <theseinfeld> anybody up for checking the http://revu.tauware.de/details.py?package=libdc1394-22
[08:06] <theseinfeld> It should be clean now for all errors :)
[08:16] <dholbach> good morning
[08:20]  * LucidFox bods
[08:21] <LucidFox> * nods
[08:21] <Iulian> Morning dholbach
[09:16] <HighNo> oh no, is't me again... short question: when I create the base structure of the deb package with "dh_make -c gpl -b --createorig" I will be asked for a version. Do I enter the upstream version or the complete ubuntu version? (blueproximity-1.2.2 vs. blueproximity-1.2.2-0ubuntu1)...
[09:18] <man-di> upstream version
[09:18] <HighNo> thx
[09:23] <HighNo> can anybody please check why my uploads to revu don't work? my key id is  DSA key ID 2298A62D for  "Lars Friedrichs <LarsFriedrichs@gmx.de>"
[09:23] <HighNo> dput gives no error, the package is lintian clean and it does not pop up on the revu website.
[09:28] <slytherin> HighNo: what do you mean by don't work?
[09:29] <HighNo> dput states: "Successfully uploaded packages." (to revu.tauware.de) but I can't see my package appearing on the revu website.
[09:30] <HighNo> is the server revu.tauware.de ok? I did not change the preset settings of dput.
[09:33] <HighNo> slytherin: this is what dput gives me: http://pastebin.com/d578db3ee
[09:35] <slytherin> HighNo: there is no error, I think it will take some time before the packages show up on revu
[09:37] <HighNo> slytherin: do you know how long that would be? As I followed some discussion here yesterday stating "I just uploaded bla, can someone have a look at it please" and I saw it immediatly on the website. That's what kept confusing me.
[09:38] <mok0> HighNo: Remember, you need to build the source package (-S -sa) and upload the _source.changes file
[09:38] <slytherin> I don't know exact time but should be less than an hour
[09:39] <mok0> Uploads to REVU should show up after 10 minutes max
[09:39] <mok0> The cron job runs at 10, 20, 30, ...
[09:40] <HighNo> moko: that explains the nice timestamps with the packages :-)
[09:40] <HighNo> mok0: but sadly - it does not tell me why my package does not show up as ten minutes are gone by now
[09:41] <mok0> HighNo: you probably uploaded a binary package
[09:42] <HighNo> mok0: this is my dput output: http://pastebin.com/d578db3ee
[09:42] <mok0> Is your sig in REVU's keyring?
[09:43] <mok0> Oh
[09:43] <jeromeg> anyone to review my merge of gnome-chemistry-utils ( bug 188404 ) ? Thanks
[09:44] <mok0> HighNo: Hm I dunno, you have to find an admin that has access to REVU
[09:45] <lionel> jeromeg: I'm on the U-U-S queue, I may reach it :)
[09:45] <jeromeg> lionel: ok, thank you lionel
[09:45] <HighNo> mok0: how could I check if my key is in the keyring?
[09:46] <mok0> HighNo: Looking at the output, it looks like your sig was recognized during the upload
[09:48] <Fujitsu> mok0: That's dput, not REVU.
[09:50] <mok0> Fujitsu: Ah, yes of course. It's dput verifying on the user's end
[09:51] <slytherin> HighNo: you need to join https://launchpad.net/~ubuntu-universe-contributors
[09:52] <slytherin> HighNo: and your public key needs to be available in launchpad so that it will be synced in the revu keyring
[09:52] <HighNo> mok0: would it be possible to be signed twice by different keys? I have another key which was created two days ago, not just yesterday - if that was a timing issue... Can I sign the package with another key (another mail address too) without any problem? Both keys are assigned to my launchpad account.
[09:52] <HighNo> slytherin: been there - done that :-)
[09:52] <HighNo> slytherin: I joined that group two days ago, added one key two days ago and the other one yesterday
[09:53] <slytherin> HighNo: the keys ususally are synced every 24 hours IIRC
[09:54] <mok0> HighNo: You should define your signing key in the env. variable DEBSIGN_KEYID
[09:54] <mok0> HighNo: Of course you need to sign the package with the same key that is on REVU
[09:56] <shibata> hi all.
[09:56] <HighNo> mok0: I know the key has to be there, but as the maintainer I use one mail address (and one key I created just yesterday) and for other stuff I use my company's mail address which I added the day before yesterday. So that key must already be there. The question is - the address for that key is not the same as the one I entered as the maintainer in the packages settings. Does REVU care or would it accept any key that is in the keyring?
[10:00] <mok0> HighNo: you signed the change file with the key 2298A62D. If that is the key you also sent to REVU, it should be ok. However, the email address that you use in debian/changelog must have a subkey in 2298A62D
[10:03] <HighNo> mok0: OK, so I would have to change my mailaddress there too to see a difference. I'll try that.
[10:03] <mok0> HighNo: you can have as many mail addresses (uid's) in your gpg key as you want
[10:06] <HighNo> mok0: I know now, that was just too late. I have two seperate keys now :-( I'll change my package building setup to try my other address now...
[10:07] <mok0> HighNo: Make sure you define DEBSIGN_KEYID in .bashrc
[10:09] <HighNo> mok0: It is now signed with my other key I added the day before yesterday. If that does not work there must be something else broken. Wait a minute...
[10:11] <HighNo> mok0: OK, the upload with dput worked (as always...) I guess I know have to wait ten minutes and see if it's ok
[10:12] <mok0> HighNo: ~7 minutes to next refresh :-)
[10:14] <HighNo> mok0: thx. Anyway do get this correct: the login to the webpage will be created after my first package is accepted for review (does appear in the list). there will be a password mailed to the email address of my key, encrypted with that key?!
[10:18] <mok0> HighNo: No, when you try to login, and it fails, there will be a butten called "Recover". That will give you access to a file that you need to decrypt with your key to get the password.
[10:18] <HighNo> mok0: so how is the login created in the first place?
[10:19] <mok0> HighNo: from your key
[10:19] <mok0> HighNo: the server can encrypt a message with your public key that only you can decrypt with the private one
[10:20] <HighNo> mok0: yes, but when is the account created. Automatically when my key is in REVUs keyring?
[10:22] <mok0> HighNo: The account is based on the key you upload. Your login name can be any of the email addresses that are covered by your key
[10:22] <HighNo> btw, I have an official problem right now. The package is still not in the list. Even if the keyring is only updated once per day the key I used now must be in there. So my problem seems not to relate to my key.
[10:23] <HighNo> mok0: Ok, so my first 'correct' upload will be the initial step. (Of course this seems to be my biggest problem atm :-))
[10:24] <mok0> HighNo: Hmm. You need to get hold of an admin with access to the REVU server. siretart, sispoty or Hobbsee are some of them
[10:24] <HighNo> Anybody with full access to REVU reading this? I have a problem.
[10:24]  * Hobbsee looks in
[10:24] <mok0> HighNo: yes, once your first upload has succeeded everything works
[10:25] <HighNo> Hobbsee: cool, thx
[10:25] <Hobbsee> HighNo: which package?
[10:25] <HighNo> Hobbsee: blueproximity
[10:26] <vemon> anyone care to review http://revu.tauware.de/details.py?package=lashwrap
[10:26] <Hobbsee> oh sigh.
[10:26] <Hobbsee> someone's about to get poked with a very long stick
[10:26] <mok0> Uh-uh
[10:26] <vemon> lashwrap should be quite ready for advocation :)
[10:27] <Hobbsee>  Thomas Dreibholz <dreibh@iem.uni-due.de> here?
[10:27] <mok0> Phew. Some german guy :-)
[10:27] <HighNo> Hobbsee: I hope I'm not the one to see the wrong side of the stick...
[10:27] <HighNo> mok0: I am german :-) but i am not Thomas
[10:27] <Hobbsee> HighNo: no, you've uploaded a source package, not many binary packages
[10:27] <ion_> I am not German, but i am not Thomas.
[10:28]  * Hobbsee wonders why the guy decided to upload it *three* *times* before noticing it was wrong.
[10:28] <ion_> Well, it’s not as if computers are deterministic.
[10:28] <ion_> Oh, wait.
[10:29] <mok0> Just keep doin' it until it works...
[10:29] <HighNo> Hobbsee: to be honest, this is probably my fourth try to upload my package. (but at least I told you guys in here I was having problems :-)
[10:29] <HighNo> ion_: "Hello IT - have you tried turning it OFF and ON again..." :-)
[10:29] <norsetto> howdy all
[10:29] <mok0> norsetto!
[10:30] <Hobbsee> HighNo: yeah, you're not in the keyring
[10:30] <norsetto> mok0!!
[10:30] <Hobbsee> i don't think it's autoamted, either
[10:30]  * Hobbsee updates it
[10:30] <HighNo> Hobbsee: whoohooo
[10:30]  * Hobbsee should really add that to cron
[10:30] <ion_> until dput ...; do echo Huh. I bet it works the next time.; done
[10:30] <mok0> Hobbsee: you mean, REVU does not regularly update the keyring?
[10:30]  * HighNo would appreciate it
[10:30] <Hobbsee> then again, the upload never gets reprocessed anyway
[10:30] <Hobbsee> mok0: don't think so
[10:31] <HighNo> Hobbsee: so i have to upload it again?
[10:31] <HighNo> Hobbsee: thank god bits are so cheap these days...
[10:31] <Hobbsee> HighNo: no, i can let it thru when it's done
[10:31] <HighNo> Hobbsee: great news
[10:32] <mok0> HighNo: -> HighYes
[10:32] <HighNo> :-)
[10:32] <ion_> HighMu
[10:32] <mok0> HighNoon
[10:33] <HighNo> I heard those before :-)
[10:33] <mok0> HighNo: Sorry, I know it's in bad taste making fun of someone's nick :-)
[10:33]  * Hobbsee updates revu
[10:34] <HighNo> mok0: I am >30, I don't mind - in a day I probably can't even remember :-)
[10:35] <Hobbsee> security patches might be nice....
[10:35] <mok0> heh
[10:35] <Hobbsee> (REVU will drop out for a little bit)
[10:37] <HighNo> ah, real question: if I find any errors or change things to be more ubuntuish, can I update the package by just uploading a changed version (with a greater ubuntu subversion number of course)?
[10:37] <Hobbsee> HighNo: to revu?
[10:37] <Hobbsee> HighNo: with revu, you keep teh same version # - it's diffferent to everything else
[10:37] <Hobbsee> to anywhere else, liek the main ubuntu archive, yes
[10:38] <Hobbsee> REVU is back.
[10:41] <HighNo> Hobbsee: OK then. I guess there is a queue REVU is working on and blueproximity is the last in line?
[10:43] <Hobbsee> HighNo: as in, getting it processed, or getting humans to look at it?
[10:45] <mok0> Hobbsee: It's not listed on the webpage yet
[10:45]  * slytherin wonders where geser or persia are :-(
[10:45] <Hobbsee> mok0: i know.  the keyring sync isn't done
[10:45] <Hobbsee> i'll tell you when it is
[10:45] <Hobbsee> slytherin: i ate tehm
[10:46] <slytherin> Hobbsee: couldn't you wait till one of them sponsored my debdiff?
[10:46] <Hobbsee> it takes 20+ mins
[10:46] <Hobbsee> slytherin: nope :P
[10:48] <Hobbsee> HighNo: Accepting upload blueproximity from Lars Friedrichs (Quattro-Scan GmbH) <l.friedrichs@qs.nitag.de>
[10:48] <Hobbsee> there you go :)
[10:48] <HighNo> Hobbsee:  are there so many keys being added every day or does it just take so long to find the newest keys?
[10:48] <HighNo> Hobbsee: whooohooo
[10:48] <Hobbsee> HighNo: it has to do a full resync - i'ts not incremental :(
[10:49] <geser> slytherin: I'm here, I just got 30 min ago out of bed
[10:49] <Hobbsee> i don't know why
[10:49] <Hobbsee> there you are.  REVU cleaned out
[10:50] <HighNo> Hobbsee: (regarding package process) this is just linux - it does take much longer that you expect but you probably learned a whole lot about the system. [which is great for people wanting to learn the system - like me]
[10:50] <slytherin> geser: Can you tell me your location? I will add location to my clock so I will know when to ping you. :-)
[10:51] <HighNo> Hobbsee: thanks again. It looks so sweet - lying there innocently on the webpage - until mean reviews will probably tear it to pieces :-) I hope I didn't make to many errors...
[10:52] <slytherin> HighNo: not 'tear it' but 'hammer and crush' it :-)
[10:52] <Hobbsee> HighNo: hehe :)
[10:52] <geser> slytherin: Dortmund, Germany
[10:54] <slytherin> geser: is it 11:55 am there? And looks like you are having good sunny day. :-)
[10:54] <ion_> 55? It was :54 when you sent that message. :-)
[10:55] <HighNo> slytherin: true - we have a wonderful sunny day here in germany. That increases the good-weather-day-counter for this year up to - ehm - one...
[10:55] <slytherin> So the clock applet works correctly after all
[10:56] <HighNo> geser: (I am from Diepholz, near Bremen)
[10:57] <geser> slytherin: lucene2 uploaded
[10:58] <Hobbsee> hm, a lot of this can probably be archived, too
[10:58] <slytherin> geser: Thanks. :-D
[10:59] <man-di> HighNo: hehe, here in Bremen the count is 2 already :-)
[11:00] <mok0> HighNo: afaics you are not using the proper python install tools
[11:00] <HighNo> now I can officially ask anyone to review  http://revu.tauware.de/details.py?package=blueproximity
[11:00] <HighNo> wow, that was fast :-)
[11:01] <mok0> HighNo: I'm not a motu, but I can give a couple of comments
[11:01] <HighNo> mok0: I know I don't use the standard way but I could always need halp with that one. A standard is a good thing to keep...
[11:01] <mok0> imho experience, the easiest is to use python's disttools
[11:02] <mok0> it works perfectly with cdbs
[11:02] <mok0> HighNo: https://wiki.ubuntu.com/PackagingGuide/Basic#head-1858e9b3d419609c46d89d3afc2b25b0f8e155a5
[11:03] <HighNo> btw, does reviewing include testing that the software actually does what the description tries to tell us? because then I should add the "needs bluetooth" to my request for review...
[11:03] <mok0> HighNo: ubuntu wants to install python programs so they work with several different python versions, the tools take care of that
[11:03] <HighNo> mok0: thanks, I will have a look at that
[11:03] <mok0> HighNo: yes, eventually. But let's first get rid of the packaging issues
[11:05] <HighNo> mok0: ok, but the page you just mentioned refers to python modules. Those are installed at site-packages as I recall. Mine does not install any modules but runs from a single directory. But as you said, we first take a look at the packaging.
[11:05] <mok0> HighNo: another few point: debian/changelog: collapse both entries to one. And... "Initial release" cannot be true of a version 1.2.2, must be "Initial packaging"
[11:05]  * slytherin says fixing lucene2 has been quite a learning experience. :-)
[11:06] <mok0> debian/control: Build-Depends: cdbs is there twice
[11:06] <mok0> Priority -> optional
[11:07] <mok0> ubotu, ! maintainer
[11:07] <ubotu> The "Maintainer" field in a package's information (debian/control) should indicate the Ubuntu team responsible for the Ubuntu specific changes to a package (often the !MOTU for !Universe packages). The original maintainer is preserved in the field "XSBC-Original-Maintainer".
[11:07] <mok0> HighNo: See maintainer: policy ^
[11:07] <HighNo> ok, so I have to add myself as I am the upstream author of the package...
[11:08] <HighNo> I wasn't sure if I had to be in there twice...
[11:08] <mok0> HighNo: No, the maintainer is the ubuntu-motu mailing list
[11:08] <HighNo> ahh, ok
[11:08] <mok0> HighNo: Put yourself as the XSBC-Original-Maintainer
[11:09] <mok0> HighNo: You have a homepage for blueproximity? Put it in a Homepage: field
[11:10] <mok0> HighNo: debian/copyright. Looks good, but remove the boilerplate #'s at the end
[11:10] <Hobbsee> effie_jayx: excellent.  i can request a sync for rbot now
[11:11] <RAOF> mok0, HighNo: If it's the first time it's been packaged in {Ubuntu, Debian}, it's considered an initial release.
[11:11] <mok0> HighNo: debian/dirs is *only* for empty directories you want created. Don't use for things that are created by the install
[11:11] <effie_jayx> Hobbsee, I saw that :D
[11:11] <mok0> RAOF: Hm, ok
[11:13] <mok0> HighNo: debian/docs: the README.txt file is not that interesting. Most of it is duplicated in the long description. The contributing author should be acknowledged in copyright
[11:14] <mok0> HighNo: you have quite a nice HTML manual. That should be included instead. Read about the doc-base system.
[11:15] <mok0> debian/rules: Cool, you're using CDBS. That should keep you out of trouble with the MOTUs :-)
[11:15] <HighNo> mok0: hm, some of this stuff I cannot even see because debuild creates those on the fly... I will still try to fix everything.
[11:15] <HighNo> what would be the exact entry for the maintainer then?
[11:15] <mok0> HighNo: I'm just browsing the stuff on the REVU page.
[11:16] <mok0> HighNo: Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[11:16] <mok0> XSBC-Original-Maintainer:  Lars Friedrichs <LarsFriedrichs@gmx.de>
[11:17] <HighNo> Hobbsee: If I upload my package again with the same name but a different key (because that's the one I ought to use) and the key is already in the keyring, will this give me a problem?
[11:17] <mok0> HighNo: I will paste my comments to the revu page for your reference. And for my future MOTU application ;-)
[11:17] <mok0> HighNo: you keep uploading same version-release
[11:17] <HighNo> mok0: cool
[11:21] <HighNo> mok0:  is the README.txt a real problem? Should I delete it then? Should it just refer to the HTML manual?
[11:21] <mok0> HighNo: Don't delete the file, just don't mention it in docs
[11:22] <mok0> HighNo: ... but credit the contributors in copyright
[11:23] <mok0> HighNo: then there's nothing else in readme..txt afaics
[11:24] <HighNo> I am not sure about the dirs file - since I don't have any 'make install' like installation does it still automatically create the necessary directories?
[11:25] <Hobbsee> HighNo: is the new key in the keyring?
[11:25] <Hobbsee> oh right, yes it is.  then it should be fine
[11:25] <HighNo> Hobbsee: must be, it was added in LP yesterday
[11:25] <Hobbsee> ah right
[11:26] <HighNo> mok0: contributors being also translators?
[11:26] <mok0> HighNo: Whoever you think deserves to be credited. In a sense they all contribute to your application becoming a success
[11:29] <HighNo> mok0: ok, I now work on the doc-base stuff. I don't know what you meant there. Should I add a special dh_installdocs call to the rules file?
[11:29] <mok0> HighNo: no, you just add a blueproximity.doc-base file in debian/
[11:29] <mok0> HighNo: dh_installdocs takes care of the rest, and that is called by CDBS
[11:33] <mok0> HighNo: btw, use a spell checker on all the english texts in your package. I didn't see any spelling mistakes, but you never know. The MOTUs are evil, they will get you for anything :-)
[11:36]  * Hobbsee laughs evilly
[11:36] <Hobbsee> HighNo: Homepage:  <blah> at the bottom of the long description in debian/control would be nice too
[11:36] <Hobbsee> :)
[11:37] <smarter> hi
[11:37] <HighNo> Hobbsee: ok
[11:37] <smarter> what's the standard way to indicate that the .orig.tar.gz has been repacked?
 ?
[11:37] <Hobbsee> smarter: repackaged, as in, files taken out?
[11:38] <Hobbsee> or repacked, from tar.bz2 to .tar.gz?
[11:38] <smarter> Hobbsee: file(actually COPYRIGHT) taken in and tar.bz2 to tar.gz
[11:38] <Hobbsee> smarter: usually <version>-repack-0ubuntu1
[11:38] <mok0> Gotta run guys, see you later!
[11:38] <HighNo> mok0: I have problems understanding the doc-base system. Although somewhat explained here: http://fts.ifac.cnr.it/cgi-bin/dwww?type=file&location=/usr/share/doc/doc-base/doc-base.txt.gz I don't understand how my .doc-base file should look like exactly
[11:38] <smarter> Hobbsee: thanks
[11:38] <Hobbsee> smarter: or something like that
[11:39] <smarter> I've seen "+repack" and "-repack1", I think the first solution is more elegant
[11:39] <HighNo> mok0: thanks so far!
[11:39] <mok0> HighNo: ok, good luck!
[11:40] <smarter> Hobbsee: this is for the tar.bz2 to tar.gz or for the files added/deleted ?
[11:40] <Hobbsee> smarter: i don't think there's a policy on it, so you can pretty much pick
[11:40] <smarter> ok
[11:40] <Hobbsee> smarter: files added/deleted
[11:40] <smarter> roger
[11:40] <Hobbsee> smarter: sometimes it's mentioned in the changelog if you've converted it to .tar.gz, but that's rare
[11:40] <Hobbsee> iirc
[11:42] <HighNo> Hobbsee: maybe you can give me a little guide here: the .doc-base file should include (my ideas about nice values attached) Document: blueproximity Title: BlueProximity Manual , Author and Abstract I can do by myself but what to put in Section: part?
[11:43] <Hobbsee> HighNo: no idea, i don't play much with docs, sorry
[11:43] <sistpoty|work> hi folks
[11:44] <smarter> It's me, or does uscan --force-download doesn't force download anymore with hardy?
[11:44] <norsetto> hodwy sistpoty|work
[11:44] <sistpoty|work> hi norsetto
[11:46] <HighNo> hm
[11:47] <HighNo> Hobbsee: too bad :-/ I will upload a new version anyway. Should I comment on the changes?
[11:49] <Hobbsee> HighNo: if you like, but stick all of the changes in one changelog entry
[11:49] <smarter> TheMuso: ping
[11:50] <smarter> TheMuso: you reviewed my package(http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin) and said that most of the files are under GPL and not LGPL, they all contains "GNU Library General Public" in the header which is the other name of the LGPL
[11:51] <smarter> and the COPYING.LIB file explicitely state "NOTE! The LGPL below is copyrighted by the Free Software Foundation [...]"
[11:51] <sladen> smarter: is there a COPYING file in there somewhere/documentation that states otherwise?
[11:52] <smarter> sladen: there's a COPYING with the GPL(two files are GPL) and a COPYING.LIB with the LGPL
[11:52] <HighNo> Hobbsee: The changes I made are all in the debian dir, so I don't think they should be mentioned in the package itself. But I meant commenting on REVU's page
[11:52] <smarter> I even used licensecheck -r . to make sure
[11:53] <sladen> smarter: that could been the confusing---checking for a COPYING might have been what TheMuso did
[11:53] <TheMuso> No, I saw a difference between what was stated in debian/copyright, and the COPYING files.
[11:54] <TheMuso> debian/copyright said lesser, the COPYING files said library.
[11:55] <webwolf_27> saivann, I sent you an email regarding the packaging of the Brother Drivers for Multiverse, Have you had a chance to check it?
[11:55] <sistpoty|work> smarter: is there a copying file in the orig-tarball, that contains the LGPL?
[11:56] <HighNo> Hobbsee: hmm "dpkg-source: warning: unknown information field 'Homepage' in input data in package's section of control info file" - did I misunderstand you telling me to add that "Homepage: http..." to the control file?
[11:57] <Hobbsee> HighNo: hm, i thikn you ahve to put a space in front if it first
[11:57] <Hobbsee> so it doesn't think it's a field
[11:57] <HighNo> Hobbsee: ahh, that makes sense
[11:57] <Hobbsee> (and we may have an X-homepage: field now, or something, come to think of it)
[11:57] <sistpoty|work> smarter: if not, and there files inside the orig-tarball, that are licensed under the LGPL, you'll need to repack the tarball and a a copy of the LGPL
[11:57] <sistpoty|work> add a copye
[11:57] <sistpoty|work> -e
[12:00] <sladen> ^^ smarter stated that there was both a COPYING.LIB and a COPYING  (LGPL and GPL)
[12:01] <sladen> but the conflict here is presumebly between that and  debian/copyright
[12:01] <sistpoty|work> heh, didn't read irc thourough enough *g*... was confused by "(two files are GPL)"
[12:02] <HighNo> Hobbsee: too funky, if I leave out the directories where stuff is supposed to get in the debuild for the binary package fails due to a call "install: cannot create regular file `/home/python/blueproximity-1.2.2/debian/blueproximity/usr/bin/blueproximity': No such file or directory" which is because the directory is not there. What shall I do here?
[12:03] <smarter> TheMuso: Library GPL == Lesser GPL == LGPL
[12:04] <TheMuso> smarter: Are you sure that they are the same beyond the title?
[12:04] <smarter> TheMuso: http://en.wikipedia.org/wiki/Library_General_Public_License
[12:04] <TheMuso> smarter: And, why was the package originally rejected?
[12:04] <smarter> redirect to LGPL
[12:04] <smarter> TheMuso: I said that most of the files were GPL and some LGPL
[12:04] <smarter> TheMuso: you can check with licensecheck -r .
[12:04] <smarter> in devtools
[12:05] <TheMuso> smarter: The package was initially uploaded, but must haveen rejected. Why?
[12:05] <smarter> "[13:04] <smarter> TheMuso: I said that most of the files were GPL and some LGPL"
[12:05] <smarter> s/I/debian/copyright if you prefer
[12:06] <TheMuso> smarter: Well I'm about to go to bed, so if someone else gives the ok, I will when I come online commorrow.
[12:06] <smarter> TheMuso: ok, thanks
[12:07] <smarter> actually, jpatrick acked it
[12:15] <shibata> My native language isn't English. And I would like to improve my package description. Can anyone check it for me?
[12:15] <slytherin> geser: lucene2 built successfully. :-D
[12:17] <Nightrose> shibata: would help if you say which package and where to find it :)
[12:18] <shibata> Nightrose: thx. My package is http://revu.tauware.de/details.py?package=kita2
[12:21] <luisbg_> what's the best way to handle the placing of the app's .desktop file in the system for the menu to use?
[12:21] <ion_> dh_desktop(1) probably
[12:22] <ion_> Ah, it only seems to be required for .desktop files with MIME types.
[12:22] <luisbg_> ion_, ok, thanks let me check that
[12:22] <luisbg_> well.. if it's the best way in general
[12:22] <Nightrose> shibata: I would remove the !And" at the beginning of the second sentence - but I am not a native speaker either
[12:23] <luisbg_> I don't need the MIME types, but no worries
[12:24] <shibata> Nightrose: Thank you very much. I will remove it.
[12:27] <minghua> Putting the .desktop file in /usr/share/applications and use dh_dekstop, I believe.
[12:27] <slytherin> luisbg_: you have to install them in /usr/share/applications, you can do it in install file.
[12:28] <minghua> You don't need dh_desktop for now if you don't have MIME types, but it may be useful in the future.
[12:28] <luisbg_> slytherin, directly in the app.install file? I thought of that but it seams hacky
[12:28] <luisbg_> or .postint
[12:28] <luisbg_> now wait...
[12:29] <luisbg_>  .install sorry LOL
[12:29] <slytherin> luisbg_ where does the Makefile in the application install the .desktop file?
[12:29] <luisbg_> slytherin, the application has no .desktop file
[12:29] <luisbg_> I'm going to create one for it
[12:29] <luisbg_> and upload as a patch to the ubuntu package
[12:30] <luisbg_> so the makefile doesn't know about this file
[12:30] <slytherin> luisbg_: Oh. You will have to do some trial and error then. I don't know exact solution for this.
[12:31] <luisbg_> slytherin, I have done the .install method for some software I've developed
[12:32] <luisbg_> and clients wanted a deb package, just in a hacky way that didn't had to follow the debian/ubuntu rules
[12:32] <luisbg_> I'll try this approach and maybe in REVU I will be asked to change it to a better way
[12:32] <luisbg_> :)
[12:32] <slytherin> luisbg_ .install method will work. I am not sure if dh_desktop will work if the file is not provided by upstream source
[12:35] <luisbg_> slytherin, ok
[12:47] <minghua> slytherin: It will.
[12:54]  * norsetto -> lunch
[12:57] <slytherin> Can some one look into the 'New' queue and take some action on cglib2.1? It will hopefully clear 1-2 more depwait
[13:35]  * norsetto <- lunch
[14:08] <mruiz> hi all
[14:09] <coolbhavi>  Can we upload new packages of new software in ubuntu and new packages which arent there in ubuntu?
[14:09]  * coolbhavi thinks of working towards becoming a MOTU
[14:10] <coolbhavi> any Info?
[14:12] <slytherin> coolbhavi: Can you please rephrase the question?
[14:12] <Hobbsee> coolbhavi: yes, until feature freeze (the 14th)
[14:13] <RainCT> Hey
[14:13] <Iulian> coolbhavi: Well, start packaging and upload to REVU, and like Hobbsee said until FF.
[14:13] <Iulian> Hi RainCT
[14:13] <coolbhavi> Ok.. Will uploading packages help me towards becoming a motu?
[14:14] <Hobbsee> coolbhavi: yes
[14:14] <ScottK> coolbhavi: It will help, but it's not required.  Showing a broad range of skills which you get through fixing packaging problems, helping with merges, and other more general tasks can be sufficient.
[14:15] <coolbhavi> OK will start active packaging from Hardy+1.. Thanks for the info
[14:15] <slytherin> coolbhavi: It is just a start. You need to do lot of practice, need to be consistent in following processes and improve over the time.
[14:16] <coolbhavi> OK.. :)
[14:16]  * coolbhavi committed and fallen in Love with ubuntu
[14:18] <slytherin> coolbhavi: why hardy+1? You can still help with minor tasks like debdiffs, sync request etc.
[14:18] <jdong> coolbhavi: no need to wait till hardy+1, there's plenty still to be done for Hardy :)
[14:18] <coolbhavi> Ok... :)
[14:19] <jdong> coolbhavi: packaging new software is only a small part of being MOTU -- for example, when my MOTU application was approved I had actually never personally packaged a new program from start to finish :)
[14:19] <coolbhavi> Ok.. :)
[14:20] <jdong> coolbhavi: though, as practice, packaging  some program you like will give you good introductory insight into what a basic deb source package consists of
[14:20]  * slytherin wonders how jdong landed in backports team. :-P
[14:21] <jdong> slytherin: backports team doesn't generate new code / packages :)
[14:21] <jdong> slytherin: in fact, there's severe limitations to how much we can actually do that ;-)
[14:21] <ScottK> slytherin: He did it the hard way.  He invented it.
[14:21] <jdong> what ScottK said
[14:21] <jdong> backports used to be a Sourceforge project
[14:21] <jdong> that checked in an apt repo into Subversion :)
[14:21] <coolbhavi> Will start working towards it... Any Info on Howto on sync,merges and so on?
[14:22] <jdong> packages were built for Warty using debuild -B and whatever environment I was running at the time :D
[14:22] <slytherin> :-)
[14:22] <jdong> I'm sure I used to be the most hated person around here :D
[14:22] <Hobbsee> !jdong | jdong
[14:22] <ubotu> jdong: <Hobbsee> jdong: yes, but you're FULL OF CRACK!
[14:23] <jdong> coolbhavi: almost all MOTU related work and processes is documented at https://wiki.ubuntu.com/MOTU
[14:23] <Hobbsee> slytherin: backports == crack, so jdong was suited to it.
[14:23] <tuxmaniac> Hobbsee, so what is suited for you?
[14:23] <slytherin> Hobbsee: have you been feeding this nonsense to ubotu? :-D
[14:24] <Hobbsee> slytherin: erm.  maybe.  but it's not nonsense!
[14:24] <coolbhavi> Ok jdong thanks for the info mate
[14:24] <Hobbsee> tuxmaniac: good question.  ask soren or dholbach, who are certain to say that i just stick around to whinge.
[14:24] <soren> eh?
[14:24] <jdong> slytherin: and she doesn't accept my !jfuv factoid :D
[14:25] <coolbhavi> It was great talking to you jdong
[14:25] <sistpoty|work> Hobbsee: just saw your mail on the motu ml regarding revu probs: btw, a quick check, if s.o. is in the keyring is sudo -u revu1 (pathto)revu-key list <keyid>
[14:25] <jdong> coolbhavi: you too. Look forward to seeing you around here more often :)
[14:25] <coolbhavi> yup
[14:26] <Hobbsee> sistpoty|work: this is true, but if the guy's managed to upload 3 versions of binaries, and a source too....
[14:26]  * jdong sees he doesn't have posting permission to #ubuntu-devel....
[14:26] <sistpoty|work> Hobbsee: there was/is a source upload? still in the queue, or did it show up on revu yet?
[14:27] <Hobbsee> sistpoty|work: i suspect i rm'd the lot, as i only read the email later
[14:27] <Hobbsee> oh, tha'ts right
[14:27] <Hobbsee> it was an older source
[14:27] <Hobbsee> iirc
[14:27] <mruiz> hi all. For python packaging, which shebang should be used: #!/usr/bin/env python or #!/usr/bin/python2.4 ?
[14:27] <sistpoty|work> Hobbsee: heh, than I hope that things will return to normal, once he uploads the next source (i.e. account created etc.)
[14:28] <slytherin> Has anyone looked at jboss related packages? Looks like there is some circular dependency.
[14:28] <Hobbsee> yeah
[14:28] <jdong> mruiz: what version of python are you looking for?
[14:28] <sistpoty|work> if not, I'll hide *g*
[14:28] <Hobbsee> sistpoty|work: hehe
[14:28] <coolbhavi> Will the hardy changes list keep track of syncs?
[14:29] <mruiz> jdong, python 2.4
[14:29] <slytherin> coolbhavi: of course it keeps track of any changes that occur in repos
[14:29] <jdong> coolbhavi: yes. A sync is considered an upload and hardy-changes tracks all uploads
[14:29] <ScottK> mruiz: It should be /usr/bin/python
[14:29] <coolbhavi> OK
[14:29] <jdong> ScottK: for python 2.4?
[14:29] <slytherin> coolbhavi: make sure that the package builts in Ubuntu before request a sync
[14:30] <ScottK> mruiz: Why do you need 2.4?
[14:30] <jdong> coolbhavi: have you set up a pbuilder environment locally yet? That's a very useful development tool needed to do just about everything
[14:30] <geser> slytherin: re jbossas4: see bug #184557
[14:30] <ubotu> Launchpad bug 184557 in jbossas4 "Circular build-depends, needs initial bootstrapping on the buildds" [Medium,Confirmed] https://launchpad.net/bugs/184557
[14:30] <coolbhavi> OK.. mean there should be no build failure for the package.. :) thanks
[14:30] <ScottK> jdong: /usr/bin/env python would point to 2.5 in an Ubuntu system anyway.
[14:31] <jdong> ScottK: right, that's definitely wrong (tm) anyway
[14:31] <ScottK> jdong: Did you see there's a new ktorrent in Debian?  Didn't check to see if we have it already.
[14:31] <mruiz> ScottK, mnemosyne-1.0 needs it
[14:32] <slytherin> geser: I sometime wonder when will debian guys start using buildd for arch:all packages. It will prevent such type of headaches.
[14:32] <jdong> ScottK: what version do they have?
[14:32] <ScottK> mruiz: Please teach mnemosyne to play nice with Python 2.5 if you can.  That's a better solution for the long term.
[14:32] <jdong> [2008-02-07] Accepted 2.2.5.dfsg.1-1 in unstable (low) (Debian KDE Extras Team)
[14:32] <jdong> ah I see
[14:32] <jdong> ScottK: I put that in Hardy on the 27th Jan ;-)
[14:33] <mruiz> ScottK, I'll try with python2.5 :-)
[14:33] <jdong> mruiz: unless there's a really good reason to lock into one version, accepting the system default /usr/bin/python should be standard practice
[14:33] <ScottK> jdong: Yes.  It'd be good to re-sync with them probably.
[14:33] <jdong> ScottK: right. I'll put looking at that diff on my todo list and see if there's anything that needs to be done
[14:33] <ScottK> Depends on zope is the only good reason I'm aware of right now.
[14:34] <geser> slytherin: there were some discussions about it already on the debian-devel-ML but with no success
[14:35]  * jdong curses DSFG repacks...
[14:35] <ScottK> jdong: Curse the upstream.
[14:36] <jdong> ScottK: yeah I'll need to yell at them again for putting that non-free GeoIP data in there
[14:36] <jdong> ScottK: but other than that, I think personally the other DFSG repack changes are nonsensical
[14:36] <slytherin> geser: By the way, I just took a look at lucene2 2.3.x changes. I think we should better be ready to get the package in Ubuntu. I guess I will try making a packaging in my PPA so we can have some testing.
[14:37] <ScottK> IMO DFSG is a compromise and a reasonable one.  As with all compromises, it sometimes produces odd results.
[14:37] <geser> slytherin: are that big changes in lucene2 2.3?
[14:38] <jdong> ScottK: overall I've found DFSG repacks to be quite reasonable in nature, but ktorrent's particular repack sometimes drives me nuts
[14:38] <HighNo> ok, I managed to fix all previous problems, would somebody like to review http://revu.tauware.de/details.py?package=blueproximity - thanks
[14:38] <jdong> ScottK: they stripped out the flag icons because the terms say "You are free to use these in whatever way you want on your website" and ktorrent != website... despite Azureus and a few other P2P apps in Debian use the same flagset
[14:38] <slytherin> geser: big and supposedly good.
[14:39] <ScottK> jdong: They are right to do so.  Use restrictions are explicitly not allowed.  The other packages are wrong to leave them.
[14:39] <geser> slytherin: perhaps it would be good to get a FF exception even if the packages are ready before FF (which is next week)
[14:40] <jdong> ScottK: *shrug* in that sense then I should bug upstream to switch to a new flag set too
[14:40] <jdong> and it'd be nice to have debian/rules get-orig-source in the package too. I'll put that on my TODO list
[14:40] <slytherin> geser: that is what I was going to suggest. For now let the official package be at 2.2.x so that netbeans guys do some proper testing. After that I can add package to my PPA and make a call for testing.
[14:41] <ScottK> Yes.  That'd be nice or get the existing one relicensed.
[14:41] <emgent> heya
[14:43] <slytherin> geser: do you have rights to accept a package in 'New' queue?
[14:44] <ScottK> slytherin: It takes an archive admin to do that.
[14:45] <slytherin> ScottK: And can i request for package to be processed fast?
[14:45] <ScottK> slytherin: And that will get it done faster or slower depending on if the archive admin gets grumpy about you pestering them.  What's the rush?
[14:46] <slytherin> ScottK: there is one package which may clear the depwait status of at least one more package
[14:47] <ScottK> slytherin: I'd just wait then.  We're early enough in the process that I think you should let them prioritize their work.
[14:47] <slytherin> ScottK: Ok. I will wait
[14:48] <geser> slytherin: no, only archive admins have that right
[14:56] <slytherin> geser: do you think I should point to the w3c-dtd-xhtml package in Ubuntu on the debian bug?
[14:56] <hexmode>  Hi all... Just joined the ubuntu-universe-contributors.  I have a couple of packages for revu when the keyring syncs. https://bugs.launchpad.net/ubuntu/+bug/189928 https://bugs.launchpad.net/ubuntu/+bug/189926
[14:56] <ubotu> Launchpad bug 189926 in ubuntu "include libapache-test-perl" [Undecided,New]
[14:56] <hexmode> I just wait for them to sync from here, right?
[14:57] <geser> slytherin: I doubt that that it will convince the maintainer to accept this change
[14:57] <slytherin> geser: leave it then.
[15:01] <RainCT> http://paste.ubuntu.com/4291/plain/   any idea why this is FTBFSing?
[15:01] <LucidFox> hexmode> I assume so
[15:01] <LucidFox> RainCT> try building the .dsc
[15:02] <LucidFox> instead of .changes
[15:02]  * LucidFox never used pbuilder on .changes
[15:02] <RainCT> LucidFox: argh, right -.-
[15:02] <hexmode> LucidFox: tyvm
[15:02] <RainCT> LucidFox: thanks
[15:15] <jcfp> MOTUs, please take a look at http://revu.tauware.de/details.py?package=sabnzbdplus
[15:15] <jcfp> ScottK RainCT ^^^ :)
[15:16] <ScottK> jcfp: I'm busy with $WORK currently.  I'll see if I can get to it later.
[15:16] <ScottK> jcfp: In general it's not needed to ping me.  I look at REVU as I have time.
[15:18] <RainCT> jcfp: reviewing :)
[15:18] <\sh> yeah $work is holding me up, too ;)
[15:19] <jcfp> duly noted, all of the above
[15:19] <\sh> and now I know that I have to introduce ubuntu here, and push debian out of the dc
[15:20] <linux__alien> Hey LucidFox
[15:21] <LucidFox> linux__alien> yes?
[15:21] <linux__alien> Just wanted to say a big hi to you :)
[15:21] <linux__alien> am reading through the packaging guidelines
[15:22] <linux__alien> and will try a few examples and start contributing as early as possible :)
[15:23] <LucidFox> Awesome.
[15:23] <ScottK> linux__alien: We are very near the freeze for new packages for Hardy, so I'd suggest you focus your initial contributions on trying to fix what we've already got.  Look for bugs tagged packaging and bit-size.
[15:24] <linux__alien> ScottK, Sure will do that i am new to packaging so ve already started going through it and i could also fix bugs in some packages hopefully
[15:24] <ScottK> Perfect.  That's what we need is more fixing.
[15:25] <LucidFox> What's the difference between the "Uploaded packages" and "Maintained packages" sections? Maintained are those where I'm listed in the maintainer field?
[15:25] <linux__alien> but basically i need your help and support for first few days :)
[15:25] <ScottK> LucidFox: Yes.  Unless you've got packages in Debian that will almost always be empty these days.
[15:25] <ScottK> linux__alien: There are lots of people here to help.
[15:26] <linux__alien> yes :) thats what i want :)
[15:26] <RainCT> linux__alien: (*bit-size -> bitesize)
[15:26] <linux__alien> that means ?
[15:27] <LucidFox> ScottK> Yes, my package from Debian got synced and that section appeared, hence me asking :)
[15:28] <ScottK> That's exactly what it is then.
[15:28] <RainCT> linux__alien: ScottK said "Look for bugs tagged packaging and bit-size." before, but this tag he mans is "bitesize" and not "bit-size"
[15:28] <ScottK> What RainCT said ...
[15:28] <ScottK> Thanks.
[15:31] <RainCT> ember: please forward the watch file that you created for nautilus-python to Debian if you haven't already done so (although it isn't really needed as there is a get-orig-source rule already)
[15:32] <LucidFox> Can new packages be backported from Hardy to Gutsy?
[15:32] <ScottK> LucidFox: Yes
[15:32] <LucidFox> Excellent.
[15:32] <ScottK> They have to go through New again so it may take a while.
[15:32] <RainCT> btw, how can I unextract .diff.gz files using the terminal?  tar -xzf doesn't work
[15:32] <ScottK> Backports New is low on the archive's priority.
[15:33] <LucidFox> RainCT> gunzip
[15:33] <LucidFox> or zcat to output the contents to the terminal
[15:33] <ScottK> RainCT: I usually just rm -rf the dir and unpack a clean source again.
[15:33] <RainCT> LucidFox: ah, thanks :)
[15:34] <LucidFox> to auto-apply the diff, you can use: zcat filename.diff.gz | patch -p0
[15:34] <pochu> RainCT: zcat *.diff.gz | patch -p1
[15:34] <LucidFox> -p1 if you're inside the source directory
[15:34] <pochu> Right, it will create a ./debian/ dir
[15:38] <LucidFox> Hmm, apparently multiverse packages are lower in the buildd priority than universe packages.
[15:40] <ScottK> Makes sense.
[15:43] <pochu> TheMuso: I guess your +1 in http://revu.ubuntuwire.com/details.py?package=deskscribe still applies, right?
[15:50] <mneptok> who wants to take responsibility for the flashplugin-nonfree update that just got pushed?
[15:51] <jpatrick> mneptok: best check who did it on LP
[15:51] <HighNo> poor guy :-)
[15:52] <DaveMorris> in the hardy build queue, gmyth is in there twice and 2 slightly different svn numbers, should 1 of them be removed, or will they do that before it's built?
[15:53] <RainCT> is there any package in the repos to "freeze" a user (so that any change that is made gets reverted on reboot)?
[15:54] <ScottK> DaveMorris: It'll sort itself out.  I wouldn't worry about it.
[15:54] <DaveMorris> not worried, just noticed
[15:55] <ScottK> mneptok: There's also who-uploaded (I think it's called) in devscripts.
[15:56] <soren> mneptok: It's got Riddell's name written all over it.
[16:11] <linux__alien> I ve a very basic doubt in packaging should i manually create the changelog file and type the contents manually in it ?
[16:17] <hexmode> linux__alien: use dch
[16:17] <hexmode> linux__alien: emacs has a debian-changelog-mode, and something similar exists for vim, I think.
[16:17] <mruiz> I'm working on a package using python 2.4 only... how should I define this situation: python (=2.4) on Build Depends?
[16:19] <vemon> anyone seen persia?
[16:19] <linux__alien> hexmode, i could also type it manually right?
[16:19] <linux__alien> is there any problem in that coz i am very new to packaging so till i get a hold of it or rather find it i could type it also right?
[16:20] <hexmode> linux__alien: you could, but that is more painful
[16:20] <hexmode> you should just use dch
[16:20] <linux__alien> dch ?
[16:20] <linux__alien> ok let me
[16:20] <linux__alien> try
[16:20] <hexmode> man dch
[16:25] <linux__alien> hexmode, The Packaging Guide does not explain how to create these files however i ve managed to create the changelog using dch
[16:25] <linux__alien> is there any document which explains that ?
[16:26] <hexmode> there is, I don't recall atm. 1s
[16:26] <hexmode> linux__alien: is dch installed on your machine?
[16:26] <linux__alien> yes
[16:26] <geser> mruiz: which package is it? doesn't it work with python 2.5?
[16:28] <hexmode> linux__alien: https://wiki.ubuntu.com/MOTU/Contributing has a bit on dch there
[16:28] <sistpoty|work> hi bddebian
[16:28] <geser> hi bddebian
[16:28] <mruiz> geser, mnemosyne. The new version (1.0) uses python 2.4. With python 2.5 it has problems.
[16:29] <hexmode> linux__alien: From http://www.linuxjournal.com/article/4610: "changelog - The changelog lists changes to the Debian package, not necessarily to the original program. You can create it best with dh_make and add new entries with dch -i."
[16:29] <hexmode>  
[16:29] <bddebian> Heya gang
[16:29] <linux__alien> i did dch --create
[16:29] <bddebian> Hi sistpoty|work, geser
[16:30] <hexmode> linux__alien: that works too ;)
[16:30] <linux__alien> how about for the control file?
[16:30] <geser> mruiz: build-depend on the specific python version (python2.4 or python2.4-dev if you also need the headers) and make sure that scripts use /usr/bin/python2.4
[16:31] <mruiz> thanks geser ... I patched the script to use /usr/bin/python2.4 ;-)
[16:35] <linux__alien> can someone here tell me how to create a control file?
[16:35] <linux__alien> for packaging
[16:35] <linux__alien> i read through the packaging guide but am not able to find the way  of creating these files using dch
[16:36] <bddebian> dh_make
[16:44] <linux__alien> bddebian, i just went through dh_make options but not able to find the way to create control file. i gave dh_make --createorig but it didnt get created
[16:44] <linux__alien> it said a directory by name debian already exists so it will not overwrite anything
[16:44] <linux__alien> and i also gave --addmissing
[16:44] <linux__alien> but does not seem to produce the control file
[16:45] <linux__alien> ok got it
[16:45] <linux__alien> but am not sure whether what ive done is right
[16:45] <linux__alien> i ve got the control file
[16:46] <linux__alien> i gave dh_make --addmissing and then when it showed whether single binary and other options i gave cdbs and then it has created many files in the debian dir
[16:46] <linux__alien> ok got it i guess its generated the file
[16:46] <mok0> ScottK: You had me worried for a while... I am inundated in goofs I've done at the moment :-/
[16:47] <ScottK> Sorry about that.
[16:47] <ScottK> It was late and I was tired.
[16:47] <mok0> ScottK: NP. Did you get the package to build?
[16:47] <mruiz> geser, should I remove python instead of python2.4 on Build Depends ?
[16:48] <ScottK> mok0: I'm up to my eyeballs in $WORK today and so I've not looked again.  It'll probably be tomorrow before I get to it.
[16:48] <mok0> ScottK: Tell me about it ;-)
[16:48] <geser> mruiz: yes, as python will pull in python2.5 which doesn't help you much
[16:49] <linux__alien> Ok thanks for all your help got to go now cya tomorrow with some more updates :)
[16:49] <linux__alien> this is getting very interesting
[16:49] <linux__alien> :)
[16:49] <linux__alien> have a nice day
[16:50] <RainCT> cya linux__alien
[16:50] <linux__alien> cya RainCT :)
[16:54] <HighNo> mok0: could you have a look at my package again? http://revu.tauware.de/details.py?package=blueproximity
[16:54] <mok0> HighNo: Sure
[16:56] <mok0> HighNo: spellchecker: I use aspell, it's simple but ok
[16:56] <HighNo> I sacrificed my hole day where I should have done paid work or studying for my exams. I would be so depressed if it wouldn't go into hardy :-)
[16:57] <HighNo> mok0: thanks, I'll apt-get it right away
[16:58] <HighNo> mok0: funny - it was already installed... I'll have a look on howto use it then...
[16:59] <mok0> HighNo: You must be patient. It normally takes a long time and several reviews before a package gets advocated. But think about it this way: it's good to know that all the other packages have gone through the same careful scrutiny
[17:00] <mok0> HighNo: It's what makes Debian/Ubuntu such high quality distros
[17:03] <mok0> HighNo: in debian/control, move Homepage: line to the "source package" section, for example after "Maintainer:"
[17:03] <mok0> (but that does not matter)
[17:04] <HighNo> mok0: just used aspell to check my CHANGELOG.txt. works great.
[17:04] <mok0> HighNo: :-)
[17:04] <mok0> HighNo: it's fast to scan the words it doesn't like
[17:06] <HighNo> mok0: I tried to put Homepage as a new tag below Maintainer: but dh_make doesn't like that tag. even now i get warnings about using a url in the control file. But using it as a tag by its own does lead to even more warnings though no errors...
[17:06] <mok0> HighNo: Consider using compat version 6. I believe the construction you use in rules actually does not work in gutsy (there variables need to be after the "include")
[17:06] <mok0> HighNo: yeah, you get some warnings from some of the tools, but it's ok
[17:07] <HighNo> my wife and kids want to see me for dinner. I'll read your posts in a few minutes. being afk for 20 mins...
[17:07] <mok0> HighNo: bon appetit!
[17:13] <Aloha> Please review http://revu.tauware.de/details.py?package=sadms
[17:15] <joejaxx> Hello All :D
[17:15] <sistpoty|work> hi joejaxx
[17:16] <LaserJock> hi all
[17:17] <sistpoty|work> hi LaserJock
[17:19] <bddebian> Heya LaserJock
[17:20] <Aloha> laserjock laserjock does what ever a laser can
[17:20] <LaserJock> how are things in MOTU land?
[17:20] <LaserJock> I'm at a laser conference at the moment
[17:20] <sistpoty|work> heh
[17:20] <Aloha> i use lasers at work to setup chairs in a straight line
[17:23] <LaserJock> I use one at home to make sure picture are hung straight
[17:24] <LaserJock> wow, flashplugin-nonfree had a lot of activity
[17:24] <ion_> I use one at home to blind airplane pilots flying above.
[17:25] <LaserJock> ion_, tsk tsk
[17:26] <joejaxx> ion_: lol
[17:27] <ion_> I collect crashed airplanes.
[17:27] <joejaxx> lol
[17:28] <mruiz> geser, I tried to build the package and I got:  pbuilder-satisfydepends-dummy: Depends: python (= 2.4) but 2.5.1-1ubuntu2 is installed.
[17:32] <jpatrick> mruiz: python (>= 2.4)
[17:33] <geser> mruiz: how does your Build-Depends line look like?
[17:34] <mruiz> geser, jpatrick : My Build--Depends: debhelper (>= 5), python (>= 2.4), python (<< 2.5), python-support
[17:35] <geser> mruiz: python is the meta-package which points to the default python version
[17:35] <geser> if you want python2.4 then replace "python (>= 2.4), python (<< 2.5)" with "python2.4"
[17:35] <jpatrick> mruiz: depend on python2.4?
[17:35] <mruiz> jpatrick, yes
[17:36] <jpatrick> mruiz: http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
[17:37] <mruiz> jpatrick, XB-Python-Version field is supported under Ubuntu ?
[17:37] <jpatrick> mruiz: I suggest reading Debian Devel docs - they're very good :)
[17:37] <jpatrick> mruiz: I think so
[17:37] <jpatrick> taking out something like that to a core thing would be just wrong
[17:39] <geser> mruiz: yes, XB-Python-Version is supported in Ubuntu, but XB-P-V is only used with python-central
[17:39] <geser> mruiz: python-support uses now debian/pyversion
[17:40] <ion_> Which one was first, and why was the second one made, btw?
[17:40] <mruiz> geser, then should I include it (python-support) as Depends ?
[17:45] <geser> mruiz: ${python:Depends} should fill in the correct depends on python and python-support
[17:46] <mruiz> geser, ok... I'll drop it :-)
[17:47] <mruiz> uppps, Lintian error : E: mnemosyne source: missing-build-dependency python | python-dev | python-all | python-all-dev
[17:47] <mruiz> again: E: mnemosyne source: missing-build-dependency python-support
[17:48] <HighNo> mok0: re
[17:49]  * sistpoty|work heads home
[17:49] <sistpoty|work> cya
[18:01] <ScottK> mruiz: {python:Depends} does binary depends, not build-depends
[18:03] <mruiz> ScottK, I added python-support to build-depends... but now: E: mnemosyne source: missing-build-dependency python | python-dev | python-all | python-all-dev
[18:05] <mruiz> and I'm using python2.4 as build-depends...
[18:12] <ScottK> mruiz: Did you tell us why you can't use python2.5?
[18:13] <mruiz> ScottK, I did it before... The application doesn't work very well with python2.5
[18:15] <ScottK> mruiz: In what way?  Does it crash?
[18:16] <rzr> hi any hardy users around w/ radeon video hardware ?
[18:20] <ScottK> rzr: Try #ubuntu+1
[18:20] <webwolf_27> whats the proper way to submit a package available binaray-only
[18:20] <rzr> ScottK: thx
[18:22] <pochu> Ng: hey, will you release a new terminator before feature freeze? So you don't have to ask for a freeze exception ;)
[18:22] <TuxCrafter> hi guys i got a basic question: how do i list all the installed files from a packages from the commandline?
[18:23] <Ng> pochu: I'm really hoping so, I have one bug I absolutely have to fix, which I think might have been yours (a crasher)
[18:23] <webwolf_27> TuxCrafter, dpkg -c <packagename>
[18:23] <TuxCrafter> webwolf_27: thanks
[18:24] <webwolf_27> TuxCrafter, np
[18:24] <pochu> Ng: oh yeah. NB: terminator didn't closed
[18:24] <pochu> Ng: were you able to reproduce it?
[18:25] <Ng> pochu: not in an en locale, which is quite annoying because if local specific stuff is going to affect the hotkeys, we're going to need lots more code for them ;)
[18:25] <TuxCrafter> webwolf_27: ehm I is not working here dpkg -c maxima-doc
[18:25] <pochu> Ng: my locale is LANG=en_US.UTF-8
[18:26] <webwolf_27> I'm currently working on this bug https://bugs.launchpad.net/bugs/25966 but the cups-wrapper rely on the lpr-drivers and they are binary only. As I understand it I can only upload source packages
[18:26] <ubotu> Launchpad bug 25966 in ubuntu "Printer drivers for Brother needed" [Wishlist,Confirmed]
[18:26] <Ng> pochu: oh, that's weird
[18:26] <webwolf_27> TuxCrafter, that works on the deb
[18:27] <Ng> pochu: and pressing ctrl-} makes it go mad?
[18:27] <TuxCrafter> webwolf_27: is there a way to doe the same with apt?
[18:27] <ScottK> webwolf_27: If there's no source, but it's legally distributable, it can go in multiverse.
[18:27] <webwolf_27> ScottK, thats where it's planned for
[18:27] <webwolf_27> TuxCrafter, checking
[18:28] <pochu> Ng: no, only the properties + one of []{} (at least)
[18:28] <ScottK> webwolf_27: OK.  I'm not sure how to do it as I've never had to.
[18:28] <Ng> pochu: ah yes (sorry, not read the bug to remind myself exactly what it was). what's properties?
[18:28] <ScottK> You might look for another binary only package in multiverse and see how it was done.
[18:28] <pochu> Ng: the properties key is the one between the right control and the right left. I don't know how it's said in English.
[18:29] <pochu> Ng: err the right control and the right alt ;)
[18:29] <webwolf_27> ScottK, I can make a tarball of the bin's before packaging
[18:29] <mruiz> ScottK, I've read comments about problems with 2.5 ... I send an email to upstream to clarify the situation
[18:30] <ScottK> mruiz: OK.  At this point Python 2.5 has been default for a year here.  Personally, I'd be very reluctant to add python2.4 only software to our repository now.
[18:30] <webwolf_27> TuxCrafter, not that I can find
[18:30] <mruiz> ScottK, indeed
[18:31] <ScottK> And a good point to encourage upstream if they care.
[18:31] <Ng> pochu: like a windows menu key?
[18:32] <TuxCrafter> webwolf_27: ok than i will stick with the first command
[18:32] <pochu> Ng: likely, but that acts as if you pressed mouse2 to open a properties dialog.
[18:33] <pochu> Ng: this is an Spanish keyboard, btw.
[18:33] <Ng> ok
[18:33] <pochu> Ng: I could attach a photo to the bug report if that's useful
[18:33] <Ng> pochu: I'll try and make the code fail sanely and ask you to test it, if thats ok?
[18:34] <AnAnt> Hello, what's meant by native package ?
[18:34] <rzr> no need to repackage it (cleanup etc)
[18:35] <pochu> Ng: sure
[18:35] <Ng> pochu: excellent, thanks
[18:35] <AnAnt> does it mean that 1) it doesn't have separate .orig tarball & .diff.gz file. or 2) that package version doesn't end with -0ubuntuX ?
[18:36] <pochu> AnAnt: 1)
[18:36] <AnAnt> pochu: ok, thanks
[18:36] <pochu> AnAnt: 2) is that it doesn't have ubuntu changes.
[18:36] <ScottK> AnAnt: #1 and this is only for packages only useful in a Debian/Ubuntu context.
[18:38] <AnAnt> ScottK: ok, thanks
[18:46] <TuxCrafter> webwolf_27: thanks for the info
[19:03] <webwolf_27> so time for me to go put the kids to bed. Night folks
[19:03] <webwolf_27> quit "Zzzzzzzzzzzz"
[19:16] <mruiz> hi DktrKranz ... I have sent an email to upstream to clarify the python version issue (2.4 vs 2.5) related to Mnemosyne
[19:17] <DktrKranz> mruiz, GREAT! thanks :)
[19:17] <mruiz> DktrKranz, thank you ... also I didn't change the shebang (it was upstream) ;-)
[19:18] <DktrKranz> mruiz, if python2.5 is supported, there is no need to change it IMHO
[19:21] <mruiz> DktrKranz, I agree ... but #!/usr/bin/env python is the same as #!/usr/bin/python ?
[19:22] <jpatrick> mruiz: no, you can't pass python args to env
[19:22] <mruiz> DktrKranz, then I have to patch the shebang ;-)
[19:23] <mgunes> if a debdiff closes multiple bugs, should I attach the same debdiff to each one and subscribe u-u-s separately?
[19:23] <DktrKranz> mruiz, let's wait for upstream, then. When you have a reply, ping me :)
[19:24] <mruiz> DktrKranz, sure ... :D
[19:24] <geser> mgunes: pick one bug and attach the debdiff there
[19:25] <mgunes> geser, and add separate (LP: #xxxxxx) entries for each in the changelog, and they'll be closed, am I right?
[19:27] <geser> correct
[19:27] <mgunes> thanks
[19:36] <mruiz> is Homepage field supported ?
[19:37] <ScottK> In Hardy, yes
[19:44] <squentin> To upgrade a package to a new upstream version, the wiki says I should attach an interdiff file, but I think this has been changed right ?
[19:46] <squentin> nevermind, I found the note on the interdiff page
[19:50] <gilir> hi
[19:52] <leonel> ScottK:   11 dapper's clamav bugs  and  counting ...  hold on  but not  hold your breath  :-P
[19:59] <ScottK> leonel: Excellent.
[20:00] <ScottK> leonel: The more the better as it solidifies the case.
[20:09] <TheMuso> pochu: If there has been another upload, I don't think so. I think 2 acks are still needed.
[20:09] <leonel> ScottK: I've reached  cves for  0.90 0.91  that may not apply  to 88.2 for the new code  ..
[20:10] <ScottK> leonel: That should be suffiicient then.  Would you please email me the list.
[20:12] <leonel> ScottK: let me check the  remaining 7 cves  ..
[20:12] <ScottK> OK.  Thanks
[20:17] <DaveMorris> evening
[20:17] <DaveMorris> how can I get uscan to only match on a number rather than a word
[20:18] <bddebian> \d
[20:19] <ScottK> DaveMorris: google regular expressions
[20:19] <ScottK> I'd give a more detailed response, but I'm low on time.
[20:20] <DaveMorris> thanks
[20:22] <hendrixski> I made a libMyfirstLib.deb and a libMyfirstLib-dbgsym.ddeb, ran "apt-ftparchive packages"  because I want to add it to my /etc/apt/sources.list   but the result doesn't have the libMyfirstLib-dbgsym.ddeb   ... is there some separate thing I should be running to get the debug-symbol ddeb's listed for download?
[20:23] <hendrixski> err, listed in the repository I mean.  ?
[20:37] <mruiz> is linda up to date? I got a warning "3.7.3 is a newer Standards-Version." and I defined it before.
[20:38] <ScottK> mruiz: No.  It's not.
[20:38] <wallyweek> good evening all!
[20:41] <hendrixski> I know that regular repositories are made using apt-ftparchive... is there another tool for creating debug symbol repositories?
[20:59] <wallyweek> A small question: a build failure for unofficial archs (powerpc, sparc, hppa...) will prevent a package from entering multiverse?
[21:06] <ScottK> wallyweek: You should fix it, but probably not.
[21:08] <wallyweek> ScottK: thanks, I'm looking through the logs and it could be a endness issue. Is there any way to try such builds on my ppa?
[21:11] <ScottK> No.
[21:11] <ScottK> How do you know it's a problem?
[21:12] <geser> wallyweek: btw which package is it?
[21:16] <hendrixski> :-( I've been googling this one for a while.  I have dpkg-create-dbgsym installed and packaged something with the debug symbols but I can't seem to get either dpkg-scanpackages or apt-ftparchive to pick them up :-(
[21:18] <Coper> when I have run pbuild build *dsc Is there anyway to verify that the package is complete? and work correct?
[21:18] <Coper> ls
[21:18] <wallyweek> ScottK: I'm guessing ;) I have none of that machine to try a build
[21:19] <wallyweek> geser: sdlmame -> https://edge.launchpad.net/ubuntu/hardy/+source/sdlmame/+builds
[21:20] <ScottK> Coper: In KDE, I use ark namd_of_.deb to inspect the binary package and see that it's complete/correct.
[21:21] <Coper> okey but I don't get any deb file when I run pbuild or debuild.
[21:25] <ScottK> That's certainly not good.  That or you're looking in the wrong place.
[21:25] <ScottK> Coper: If this is console-freecel the version you had on REVU that I looked at certainly produced one.
[21:26] <Coper> okey, but where do I find it?
[21:28] <jcfp> Coper: try /var/cache/pbuilder/result
[21:28] <mruiz> bye all
[21:32] <Coper> I have to move my file /usr/bin/freecell to /usr/games/freecell using cdbs.
[21:32] <Coper> Anyone that know how to do that?
[21:42] <ScottK> Lutin: Why did you raise the debhelper version dependency requirement to 6 in ristretto?
[21:42] <ScottK> Coper: IIRC if you look in debian/rules for pyspf you can see how it's done.
[21:45] <blueyed> To get a new package from Debian contrib into Ubuntu before FeatureFreeze, you can just request a sync/upload a modified package? Who decides about the section (universe/multiverse)? Is contrib => multiverse? (also if the change would be to use icedtea instead of sun-java?)
[21:46] <jpatrick> blueyed: https://wiki.kubuntu.org/SyncRequestProcess
[21:46] <ScottK> blueyed: Archive admins will decide which place to stick it.
[21:46] <blueyed> jpatrick: so this applies to non-existent packages, too? Great, thanks.
[21:47] <blueyed> In case of ubuntu changes, I would just upload and it would enter NEW then?
[21:47] <ScottK> blueyed: Yes
[21:47] <jpatrick> blueyed: "-n: Specifies that the package is a new package, and requestsync should not attempt to look it up in Ubuntu since it will not exist."
[21:47] <geser> blueyed: if you know that the package needs ubuntu changes it doesn't make sense to sync it first and upload then with ubuntu changes
[21:48] <ScottK> blueyed: You should also check after it's NEWed to make sure it's put the right place.  Sometimes the archive admins miss stuff.
[21:48] <blueyed> geser: therefore I'm asking if I can just upload it directly. I don't mean to sync it first.
[21:48] <ScottK> blueyed: You can.
[21:50] <Lutin> ScottK: does it hurt ? (debhelper 6)
[21:50] <geser> Lutin: it makes at least backporting a little bit harder
[21:51] <ScottK> Lutin: It does.  It makes backporting harder.  Random increasing version dependencies isn't a good thing.
[21:51] <mr_pouit> ScottK: ristretto is already for feisty and gutsy in the xubuntu-team paa
[21:51] <ScottK> Lutin: Arbitrarily bumping to 4 from 1-3 is required because the earlier compats are deprecated.  4-6 should be set as required.
[21:51] <ScottK> mr_pouit: Yes.  Not in an Ubuntu archive.
[21:52] <ScottK> As I understand it we discourage use of 3rd party archives.
[21:53] <Lutin> I wouldn't really call the xubuntu team ppa '3rd party'
[21:53] <ScottK> Lutin: It most certainly is.  It's not an Ubuntu archive.
[21:53] <mr_pouit> well, it's as much 3rd party as the backports ^_~
[21:54] <ScottK> mr_pouit: Not at all.
[21:54] <mr_pouit> ScottK: then stop saying random_thoughts
[21:54] <mr_pouit> +$
[21:54] <ScottK> Backports is an official (but not enabled by default) Ubuntu repository.
[21:55] <ScottK> Go look at the standard installed sources.list and it's there.  Show me your PPA in the same file?
[21:55] <Coper> ScottK: I have sent up a new release for review of console-freecell I have change from using only debhelper to cdbs and using patchs to fix the man page problem.
[21:55] <ScottK> Coper: I'm unlikley to have any reviewing time today.
[21:57] <Lutin> ScottK: it's not because it's not listed in the official sources.list that it has to be considered just as $random_3rdparty_repo
[21:57] <mr_pouit> ScottK: so why are you blaming Lutin for bumping the debhelper dependency if you don't care?
[21:57] <ScottK> Lutin: It's certainly one I'd be more inclined to trust, but it's stil not official.
[21:58] <Coper> okey, time to sleep anyway. :)
[21:58] <ScottK> mr_pouit: I care about correct packaging, including potential for backporting.
[21:58] <ScottK> mr_pouit: If you look at Debian Bug #462547 you'll see he's not the only one I've said this too.
[21:58] <ubotu> Debian bug 462547 in clamtk "clamtk 3.70 has build-dep on debhelper 6, but doesn't actually need debhelper 6" [Minor,Open] http://bugs.debian.org/462547
[21:59] <mr_pouit> ScottK: debhelper 6 is correct, and ristretto won't be backported, no issue there
[21:59] <ScottK> mr_pouit: This recently came up on debian-devel too as an increasingly common bad practice.
[21:59] <Lutin> (compat 6 is the new recommend version btw)
[22:00] <ScottK> mr_pouit: Is dephelper 6 required for the package?  I think not because it's fine in Debian without it.
[22:00] <mr_pouit> 4 or 5 is ok. But using 6 won't break the package...
[22:00] <ScottK> mr_pouit: Are you the sole determiner of what packages get backported?
[22:00] <mr_pouit> ScottK: No, you are :þ
[22:00] <ScottK> mr_pouit: Right, so no reason to push it to 6 and limit the possiblities later.
[22:01] <ScottK> I like to preserve the option when there isn't a reason to forclose it.
[22:01] <ScottK> Taken to an extreme, maybe we should have a script that goes through the archive and bumps everything to 6?
[22:02] <mr_pouit> yeah, and everything to cdbs, that's not fun otherwise =]
[22:02] <ScottK> Also, since we are by policy supposed to try and minimize our diff with Debian, it's bad for that reason too.
[22:02] <StevenK> Usually bumping from one debhelper compat level to another won't cause failures
[22:03] <ScottK> StevenK: Agreed, but it provides no benifit and only limits possibilities if new features of the compat level aren't used.
[22:04] <Lutin> ScottK: as long as there's a diff, I doubt a 2-bytes change matters much, diff-wise
[22:06] <ScottK> This is true, but why make it harder?
[22:06] <Lutin> if it makes harder for you you do have a problem
[22:07] <ScottK> Imagine a year from now Debian incorporates the other changes leaving that the only diff.  Somone else merges it and assumes you bumped it for a reason and keeps that diff.  We've now lost the chance to have the package auto sync'ed for no valid reason.
[22:07] <slangasek> ScottK: how goes the bdb pruning effort?
[22:07] <ScottK> slangasek: Well getting libdb4.6-ruby out of bin New would help ...
[22:08] <ScottK> $WORK kind of has a hold of me right now, but maybe over the weekend I'll make another attack at it.
[22:08] <Lutin> ScottK: then you would catch whoever did that
[22:09] <slangasek> ScottK: heh, hint taken.  I was asking because I'm rebuilding kolab-cyrus-imapd for libldap, and noticed a build-dep on libdb4.2-dev; I suppose you haven't looked at that one at all since it's 4.2?
[22:09] <ScottK> Lutin: Probably not 'cause I don't see everyting.
[22:10] <ScottK> slangasek: I did look at it.  I think it needs to be on the same bdb version as (I'm blanking on the other bdb4.2 package) and so I was going to look at them together.
[22:10] <slangasek> cyrus-imapd-2.2 maybe?
[22:10] <ScottK> That's the one.
[22:10] <slangasek> currently, that one's building against db4.3 ;)
[22:11] <ScottK> OK.  Well then it probably doesn't matter.  I just hadn't looked through it.
[22:11] <slangasek> ok, no worries
[22:11] <ScottK> I'm pretty sure kolab can be bumped to 4.6 then.
[22:12] <ScottK> That and Kolab in Debian/Ubuntu is somewhat broken anyway last I looked, so downside risk is low.
[22:12] <slangasek> well, I'm not in a hurry to make the db changes if no one's looked through them yet, I was just checking whether it was something that could be batched up with the ldap rebuild
[22:13] <ScottK> I think it can
[22:13] <ScottK> The one thing I wasn't sure about was the synchronizaton with cyrus which is clearly not an issue.
[22:16] <slangasek> ScottK: the package uses BDB transactions, and I don't see any upgrade handling in the maintainer scripts; is this handled some other way within the upstream source?
[22:16] <anthony> Question: Once u-u-s is subscribed to a bug with an attached fix, how long would you estimate it normally takes for it to get uploaded and closed?
[22:17] <ScottK> slangasek: Urgh.  Nevermind then.  I'll add it to my transactions list to deal with.
[22:17] <ScottK> anthony: Anywhere from 30 minutes to several weeks.  There's just no telling.
[22:18] <ScottK> slangasek: Sorry about that.  I thought I'd checked Kolab for that.
[22:18] <slangasek> ScottK: ok, again no worries :)
[22:18] <anthony> ScottK: Ah, all righty then.
[22:33] <ScottK> Seen on the web - "I did hear many complaints about Vista before buying it, but I frankly did not believe that it could be that bad, especially after as much as a year since its launch. You've got to see it to believe it!"
[22:34] <slangasek> ScottK: ohwell, kolab-cyrus-imapd also has 64-bit issues with the new ldap anyway, so I'm giving the Debian maintainer time to act on this
[22:35] <ScottK> OK.  Maybe that'll motivate him to update to a newer release.  Last I heard he was declining for reasons that didn't make a lot of sense to me (IIRC it's been about 6 months).
[22:41] <james_w> Hi all. The libx11-dev in Debian experimental has dropped the dependency on libxext-dev. This means that all the work done by MOTUs in adding Build-Depends: libxext-dev is now applicable there.
[22:42] <james_w> If you fixed this in a package, or you come across one with the fix, please forward it to Debian, telling them that it applies to experimental, but it will be a FTBFS serious bug at some point.
[22:43] <slangasek> I think that's been the status quo in Debian experimental for months already, fwiw
[22:44] <james_w> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464593 for an example.
[22:44] <ubotu> Debian bug 464593 in 9menu "9menu: Needs to Build-Depend on libxext-dev" [Important,Open]
[22:44] <james_w> slangasek: I hadn't noticed until now, but there doesn't seem to have been a MBF for it, and Ubuntu has the patches, so we can help.
[22:45]  * slangasek nods
[22:51] <emgent> heya
[23:09] <wallyweek> g'night all
[23:11] <asantoni> Hi guys, I have a problem with REVU
[23:12] <asantoni> I used to have an account before the server wipe, but now it's gone apparently
[23:12] <asantoni> I still have my Launchpad account (with my GPG key registered), and I'm still a member of the contributors group, so how do I get my REVU account back?
[23:13] <tsmithe> asantoni, you need to upload a new package, and recover your login on the revu site
[23:13] <asantoni> (username is gamegod on Launchpad, old REVU account was gamegod@users.sourceforge.net)
[23:13] <asantoni> tsmithe: ok, I tried uploaded a package a few minutes ago, and it hasn't appeared
[23:13] <asantoni> (like 20 mins ago)
[23:13] <tsmithe> odd
[23:14] <RainCT> good night
[23:14] <tsmithe> asantoni, was it a source package, not binary?
[23:14] <asantoni> oh crap
[23:15] <asantoni> yes, it appears I uploaded the i386 binary
[23:15] <RAOF> debuild -S is your friend :)
[23:16] <asantoni> RAOF: yeah, I used pdebuild
[23:16] <asantoni> it's all nicely rolled into Mixxx's build system now though, hah
[23:17] <tsmithe> guys, do you think that, as the "Fluid" soundfont is distributed with a file (README.doc) claiming it to be released to the public domain?
[23:17] <tsmithe> *, we can distribute it?
[23:18] <tsmithe> TheMuso, how does one find out?
[23:18] <RAOF> Sounds OK to me, although "Public domain" apparently means different things in different countries.
[23:18] <TheMuso> tsmithe: I am no license expert, so I don't know.
[23:18] <tsmithe> ok
[23:18] <tsmithe> because if it were ok, it would mean a distributable GM soundfont
[23:19] <tsmithe> which would make a lot of people very happy
[23:21] <tsmithe> i could always package it up, and see what happens
[23:22] <asantoni> http://pastebin.ca/895631
[23:22] <asantoni> I'm missing the source package still after "debuild -S" for some reason
[23:24] <asantoni> (updated the paste with some output)
[23:25] <mok0> asantoni: it's not missing?
[23:26] <mok0> mixxx_1.6.0beta2-0ubuntu1.dsc
[23:26] <asantoni> mok0: hmmm
[23:26] <tsmithe> asantoni, try 'debuild -S -sa'
[23:26] <asantoni> when I uploaded, I used "dput revu *.changes"
[23:26] <mok0> asantoni: _source.changes?
[23:26] <asantoni> well, there's no *_source.changes files
[23:27] <asantoni> tsmithe: will try, thanks
[23:27] <mok0> asantoni: you need that
[23:27] <mok0> asantoni: ^^^
[23:27] <asantoni> ok, that makes sense :)
[23:31] <asantoni> nuts, same problem (new paste): http://pastebin.ca/895646
[23:33] <tsmithe> asantoni, no no. the files will be created in ../
[23:33] <tsmithe> also, you don't need sudo
[23:33] <asantoni> aha, I have a "mixxx_1.6.0beta1-0ubuntu1_source.changes"
[23:33] <asantoni> :)
[23:33] <asantoni> tsmithe: the debs usually end up in /var/cache/pbuilder/result, and I'm too lazy to change the permissions or something
[23:34] <asantoni> but yes, I know I'm an idiot for running that as root :)
[23:34] <tsmithe> yes, pbuilder requires sudo. but debuild doesn't :)
[23:34] <asantoni> ahhh ok
[23:34] <asantoni> thanks :)
[23:34] <tsmithe> anyway, i'm off to bed now - night!
[23:35] <asantoni> good ngiht!
[23:36] <asantoni> *night
[23:36]  * asantoni is uploading with the _source.changes now
[23:41] <asantoni> woohoo, upload worked, thanks guys! http://revu.tauware.de/details.py?package=mixxx
[23:53] <blueyed> Is it sensible to add yourself to "Author(s)" in debian/copyright, when fixing something in a package? (It's in a debdiff, which I wanted to sponsor)
[23:55] <crimsun> I suppose you /could/, but I would argue it's not sensible unless you get the blessing of the author(s).
[23:55] <james_w> blueyed: it's not usually done, however I guess if the author makes a huge change to the project that would mean that upstream would (should?) add a copyright statement for them it could be sensible.
[23:57] <blueyed> well, it's a minor bashism fix, so I'll request a new debdiff.
[23:57] <blueyed> How can I find out if a package has been removed in Debian? apt-cache madison does not show it anymore and I could not find it on p.d.o or anything on bugs.debian.org.