=== bmk789_pingme is now known as bmk789_away_ping [00:03] ion_, thanks. Do i have to build the source again? [00:12] what's the etiquette with the /^REVU: New/ messages on ubuntu-motu? When should they be sent, etc? [00:13] after you've uploaded and received the NEW. [00:16] got make erro number 2 [00:17] No rule to make target `/home/kemel/Downloads/Cube/cube-2005.08.29/enet'. Stop. [00:17] any clues? [00:17] crimsun: ah, okay. Good to know :) [00:21] Legendario: broken make file? [00:22] 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] but now i got this message. [00:24] Perhaps you need to give something called enet to it before building. [00:26] no, the /enet is the folder where the make file is [00:26] ion_ [00:27] am i doing something wrong. i wrote on the debian/rules: [00:27] DEB_MAKE_MAKEFILE = /home/kemel/Downloads/Cube/cube-2005.08.29/enet [00:27] ScottK: New courier patch... :-/ [00:28] ScottK: Not proud of that... [00:29] 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] ion_, sorry. could u be more specific? [00:38] 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] mok0: Stuff happens. I didn't suggest you do courier because it would be easy. [00:40] 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] No problem. I'll try and have a look at it tonight. [00:42] 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. === Ubulette_ is now known as Ubulette [00:43] Usually it's /var/run on a tempfs disappearing when they reboot in the middle of an upgrade to 'fix' something. [01:11] ion_, so how should i write on the file? [01:17] Legendario: Is the package named Cube and your current version is cube-2005.08.29? [01:17] Scottk2, yes. [01:21] 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] ScottK2, thanks dude. That's probably the solution. [01:24] No problem. [01:25] ScottK2, so. it would be: DEB_MAKE_MAKEFILE = ($CURDIR)/enet [01:25] right? [01:25] I think so. [01:25] great. :-D [01:25] let me try it [01:35] ScottK2 still getting error2 [01:35] /bin/sh: Syntax error: "(" unexpected [01:35] make: *** [debian/stamp-makefile-build] Error 2 [01:36] OK. Well play around with it. That's the sort of syntax yo uwant. [01:39] 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] Look at the version control history. [01:42] rm -rf * [01:42] ion_: This doesn't help when I'm hacking files directly on an install [01:42] That'll take you back to where you started. [01:42] StevenK: Still battling that segfault? [01:42] ScottK2: I've been looking at this problem for the better part of 15 hours, it so won't. [01:43] 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] TheMuso: Yup. [01:43] Oh. Nevermind. [01:43] StevenK: That sounds particularly suckworthy. [01:45] * StevenK thinks he has sorted it out [01:49] evening [01:50] Yes it is. [01:50] ScottK2: And how sarcastic is your mood tonight? [01:51] Middle sarcastic. [01:53] Anglo-Sarcastic with some Norman influence [01:53] saivann: did you file #189790? [01:56] 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] crimsun : Yes [01:57] i gotta go now... thanks for all the help. I'll be back if in need. [01:57] ScottK2: ouch [01:58] Yeah. I've spoken to him about it. He feels bad. [01:58] ScottK2: Whoever did that needs to be publically shamed. [01:58] IMO [01:58] 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] Just as a reminder. [01:59] 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] ScottK2: Fair enough. [01:59] crimsun : Do you think that it could be considered as a potential long-term solution for the actual problems with flashplugin? [01:59] 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] StevenK: Oh very nice. [02:00] TheMuso: Sorry, I couldn't resist. [02:00] TheMuso: What? You've got the storm too? [02:00] I don't think I've seen StevenK and nice in the same sentence before. [02:00] RAOF: Yeah, one popped up out of nowhere. [02:00] It looks stormy here too [02:00] 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] saivann: if Canonical were to obtain such a permission, I see no reason for it to even exist. [02:00] It mostly looks dark here. [02:01] Although it doesn't look like its going to either last long, or give much of a problem. [02:01] saivann: the point is that as the license currently stands, including the tarball with the source package is a no-go. [02:01] crimsun : Right, would you suggest to set the bug to wontfix? [02:01] Lightning sounds like its only cloud to cloud, judging by thunder clap sound. [02:01] saivann: I would, correct. [02:01] crimsun : Thanks for your confirmation on this [02:02] I'm probably just bitter about Canonical core-dev applicants getting head of the line priviledges. [02:05] ScottK2: I agree with you, even though I'm no longer in such a position. [02:05] If that were the policy, then I'd be fine with it. [02:08] TheMuso: yay, you're core now? [02:09] crimsun: No. [02:09] Not yet. [02:09] d'oh [02:09] Was supposed to be last week, but only mdz was around for the meeting, so it didn't happen. [02:10] So next week. [02:10] excellent, right on FF [02:10] If they took as in straight order, I'd have been next. [02:11] Instead there are two Canonical employees stuffed in ahead. One of which was one day after the MC gave their approval. [02:11] I also asked him if there was any reason he knew of to rush his application and he said no. [02:12] crimsun: Better than nothing. [02:21] Yay. Manual merge complete. Now to test. [02:21] 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] Heya gang [02:25] Heya bddebian [02:25] Hi ScottK2 [02:26] is it my imagination or did pbuilder change syntax from say pbuilder build to pbuilder --build? [02:29] StevenK: I take it from your upload, things are fixed? [02:30] Looks like [02:31] ScottK2: they still *should* be able to do 3 at once, i thought [03:17] Hobbsee: There are already 2 Canonical employees added today. [03:17] 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] ScottK2: they can't do 3 total? [03:17] but the added files are the ones I should include in the install [03:19] 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] effie_jayx: If they messed up the release tarball and put wrong files in it, ask them to release a new one. [03:20] Hobbsee: I just don't get any sign they are interested in community applicants right now. [03:21] ScottK2: perhaps so - but i didn't think they were all canonical members on the TB [03:21] ScottK, the source package from upstream has no changelog that can really document the changes to the software [03:21] Hobbsee: Only mjg59 is not Canonical. [03:21] ah right [03:22] effie_jayx: Then you can document the changes in debian/changelog. [03:22] I think I am not making myself understood :S [03:23] 1) the URL to the proyect in debian/copyright is not the url to the proyect anymore. [03:24] 2) upstream released 2.2 without a comprehensive list of changes from 1.1 [03:24] hence it would explaing why the packages is orphan in debian [03:25] Is it the same upstream moving to a new location or a new developer that's grabbed/forked the package? [03:25] 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] ScottK2, same developer [03:25] ScottK2, http://kipina.sourceforge.net/ [03:26] Please review http://revu.tauware.de/details.py?package=sadms [03:26] Then update debian/copyright to the new location and document the changes as best you can in debian/changelog. [03:28] 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] Right. It doesn't have to be detailed. [03:29] I removed files from kipina.install but what are the new files he included [03:29] If he's using sourceforge and their CVS, there will be commit logs that might be useful. [03:30] ScottK2, :S [03:32] 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] poor effie_jayx, it seems like all the bugs you pick are cursed :) [03:33] effie_jayx: THink of it this way. Its making you a better MOTU in the process. [03:34] well, It is frustrating as well [03:34] * effie_jayx looks for a bug to fix in something like xteddy [03:34] :D [03:35] Yes, true. [03:35] nah really. I'll put it to rest for a week and see... a new bug is what I need [03:36] 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] 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] jdong, I'll step up. I promiss [03:40] :) [03:41] leonel: No. Not to late. [03:42] * jdong looks at KTorrent in gutsy and wonders if it's massive SRU time again :( [03:42] urgh I hate telling people "this crash is fixed in gutsy-backports" [03:43] 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] the last KT SRU took nearly 3 months to roll out and by that time it was already pretty useless [03:55] hi ^^ [03:57] If I remember correctly, if an orig tarball is repacked, the tarball name shoudl reflect that correct? [03:58] TheMuso: yeah, either .dfsg or [\.+]repack [04:00] jdong: Right, thanks. [04:00] jdong: -EPARSE [04:00] 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] jdong: right [04:01] TheMuso: regex, .repack, +repack, etc [04:01] jdong: Regexps are not my strong point. I assume you mean packagename.repack.orig.tar.gz [04:01] sorry, I've been (over)using regex a lot recently... it's made it into everyday conversations too [04:02] scary [04:02] packagename_upstreamver.repack1.orig.tar.gz [04:02] or +repack1 [04:02] * TheMuso tres to think of a nice way to say "use google" on a mailing list [04:02] right [04:02] thanks [04:02] sure thing :) [04:03] 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] superm1: Right. Its someone who couldn' [04:04] argh [04:04] superm1: Right. Its someone who couldn't be bothered doing their own googling. [04:04] yeah so you just give them the nudge with the example google search [04:04] So in that case, I couldn't be bothered googling myself. [04:04] and hope that they get the right idea [04:04] right [04:08] Right. Thats out of the way. [04:08] TheMuso: You can always hand them a copy of this: http://www.sabi.co.uk/Notes/linuxHelpAsk.html [04:09] I didn't mean that one. Oops [04:09] ScottK2: If he bothers me again, I will. [04:09] I meant this one http://www.catb.org/~esr/faqs/smart-questions.html [04:09] thanks [04:29] ember: Thanks for your prompt update. [04:29] I'll take another look. === asac_ is now known as asac [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] TheMuso: Please do. I've been pondering the same thing myself. [04:57] ScottK: Just to be clear, the library GPL is not the same as the lesser GPL is it. [04:58] One is version 2 and one is version 2.1/3. I always have to look it up. [04:58] right [04:58] IIRC 2 == lesser [04:58] yep you're correct [04:59] So far I've caused two repacked tarballs this due to non-distributable/linkable stuff that others missed. [04:59] heh [04:59] So far I've knocked back a package because of debian/copyright stating lesser, when its library [05:01] Hrm. I think I'll return to a package update now. [05:01] 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] Right. heh. [05:09] that wasn't me [05:09] * Hobbsee just has the advantage of not doing new packages. [05:09] Hobbsee: makes life happier :) [05:09] ScottK: i like your mail [05:10] ScottK: Yeah, me too. [05:10] awww, shit. [05:10] ScottK: yeah, me $last+1 [05:10] 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] c/ [05:29] Thanks [05:31] speaking of +1, this reminds me [05:31] Is it known when the name of Hardy+1 will be revealed? [05:33] 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] ScottK: good answer [05:34] lol [05:35] Jumpy....... [05:35] umm..... [05:36] jackrabbit? [05:36] the release of ridiculous visual effects? [05:36] or where we get bouncy dock icons? [05:36] Itchy Iguana [05:37] 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] jdong: Too late; bouncy dock icons are here *now* (lp:awn) [06:51] Hello, I am using cdbs, and I need to pass a -l to dh_shlibdeps, how can I do that ? [06:52] DEB_SHLIBDEPS_INCLUDE_packagename, or DEB_SHLIBDEPS_INCLUDE for all packages [06:54] oh, thanks [06:54] ion_: where can I find such info ? [06:55] I just looked at the cdbs source. [06:56] 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] I see, thanks [07:36] ScottK: your mail really does scare me. [07:43] geser: Is there any work remaining from my side on lucene2? Or is it just that you are very busy? :-) [08:05] anybody up for checking the http://revu.tauware.de/details.py?package=libdc1394-22 [08:06] It should be clean now for all errors :) [08:16] good morning [08:20] * LucidFox bods [08:21] * nods [08:21] Morning dholbach [09:16] 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] upstream version [09:18] thx [09:23] can anybody please check why my uploads to revu don't work? my key id is DSA key ID 2298A62D for "Lars Friedrichs " [09:23] dput gives no error, the package is lintian clean and it does not pop up on the revu website. [09:28] HighNo: what do you mean by don't work? [09:29] dput states: "Successfully uploaded packages." (to revu.tauware.de) but I can't see my package appearing on the revu website. [09:30] is the server revu.tauware.de ok? I did not change the preset settings of dput. [09:33] slytherin: this is what dput gives me: http://pastebin.com/d578db3ee [09:35] HighNo: there is no error, I think it will take some time before the packages show up on revu [09:37] 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] HighNo: Remember, you need to build the source package (-S -sa) and upload the _source.changes file [09:38] I don't know exact time but should be less than an hour [09:39] Uploads to REVU should show up after 10 minutes max [09:39] The cron job runs at 10, 20, 30, ... [09:40] moko: that explains the nice timestamps with the packages :-) [09:40] mok0: but sadly - it does not tell me why my package does not show up as ten minutes are gone by now [09:41] HighNo: you probably uploaded a binary package [09:42] mok0: this is my dput output: http://pastebin.com/d578db3ee [09:42] Is your sig in REVU's keyring? [09:43] Oh [09:43] anyone to review my merge of gnome-chemistry-utils ( bug 188404 ) ? Thanks [09:44] HighNo: Hm I dunno, you have to find an admin that has access to REVU [09:45] jeromeg: I'm on the U-U-S queue, I may reach it :) [09:45] lionel: ok, thank you lionel [09:45] mok0: how could I check if my key is in the keyring? [09:46] HighNo: Looking at the output, it looks like your sig was recognized during the upload [09:48] mok0: That's dput, not REVU. [09:50] Fujitsu: Ah, yes of course. It's dput verifying on the user's end [09:51] HighNo: you need to join https://launchpad.net/~ubuntu-universe-contributors [09:52] HighNo: and your public key needs to be available in launchpad so that it will be synced in the revu keyring [09:52] 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] slytherin: been there - done that :-) [09:52] slytherin: I joined that group two days ago, added one key two days ago and the other one yesterday [09:53] HighNo: the keys ususally are synced every 24 hours IIRC [09:54] HighNo: You should define your signing key in the env. variable DEBSIGN_KEYID [09:54] HighNo: Of course you need to sign the package with the same key that is on REVU [09:56] hi all. [09:56] 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] 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] mok0: OK, so I would have to change my mailaddress there too to see a difference. I'll try that. [10:03] HighNo: you can have as many mail addresses (uid's) in your gpg key as you want [10:06] 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] HighNo: Make sure you define DEBSIGN_KEYID in .bashrc [10:09] 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] 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] HighNo: ~7 minutes to next refresh :-) [10:14] 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] 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] mok0: so how is the login created in the first place? [10:19] HighNo: from your key [10:19] HighNo: the server can encrypt a message with your public key that only you can decrypt with the private one [10:20] mok0: yes, but when is the account created. Automatically when my key is in REVUs keyring? [10:22] 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] 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] mok0: Ok, so my first 'correct' upload will be the initial step. (Of course this seems to be my biggest problem atm :-)) [10:24] 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] Anybody with full access to REVU reading this? I have a problem. [10:24] * Hobbsee looks in [10:24] HighNo: yes, once your first upload has succeeded everything works [10:25] Hobbsee: cool, thx [10:25] HighNo: which package? [10:25] Hobbsee: blueproximity [10:26] anyone care to review http://revu.tauware.de/details.py?package=lashwrap [10:26] oh sigh. [10:26] someone's about to get poked with a very long stick [10:26] Uh-uh [10:26] lashwrap should be quite ready for advocation :) [10:27] Thomas Dreibholz here? [10:27] Phew. Some german guy :-) [10:27] Hobbsee: I hope I'm not the one to see the wrong side of the stick... [10:27] mok0: I am german :-) but i am not Thomas [10:27] HighNo: no, you've uploaded a source package, not many binary packages [10:27] 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] Well, it’s not as if computers are deterministic. [10:28] Oh, wait. [10:29] Just keep doin' it until it works... [10:29] 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] ion_: "Hello IT - have you tried turning it OFF and ON again..." :-) [10:29] howdy all [10:29] norsetto! [10:30] HighNo: yeah, you're not in the keyring [10:30] mok0!! [10:30] i don't think it's autoamted, either [10:30] * Hobbsee updates it [10:30] Hobbsee: whoohooo [10:30] * Hobbsee should really add that to cron [10:30] until dput ...; do echo Huh. I bet it works the next time.; done [10:30] Hobbsee: you mean, REVU does not regularly update the keyring? [10:30] * HighNo would appreciate it [10:30] then again, the upload never gets reprocessed anyway [10:30] mok0: don't think so [10:31] Hobbsee: so i have to upload it again? [10:31] Hobbsee: thank god bits are so cheap these days... [10:31] HighNo: no, i can let it thru when it's done [10:31] Hobbsee: great news [10:32] HighNo: -> HighYes [10:32] :-) [10:32] HighMu [10:32] HighNoon [10:33] I heard those before :-) [10:33] HighNo: Sorry, I know it's in bad taste making fun of someone's nick :-) [10:33] * Hobbsee updates revu [10:34] mok0: I am >30, I don't mind - in a day I probably can't even remember :-) [10:35] security patches might be nice.... [10:35] heh [10:35] (REVU will drop out for a little bit) [10:37] 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] HighNo: to revu? [10:37] HighNo: with revu, you keep teh same version # - it's diffferent to everything else [10:37] to anywhere else, liek the main ubuntu archive, yes [10:38] REVU is back. [10:41] Hobbsee: OK then. I guess there is a queue REVU is working on and blueproximity is the last in line? [10:43] HighNo: as in, getting it processed, or getting humans to look at it? [10:45] Hobbsee: It's not listed on the webpage yet [10:45] * slytherin wonders where geser or persia are :-( [10:45] mok0: i know. the keyring sync isn't done [10:45] i'll tell you when it is [10:45] slytherin: i ate tehm [10:46] Hobbsee: couldn't you wait till one of them sponsored my debdiff? [10:46] it takes 20+ mins [10:46] slytherin: nope :P [10:48] HighNo: Accepting upload blueproximity from Lars Friedrichs (Quattro-Scan GmbH) [10:48] there you go :) [10:48] Hobbsee: are there so many keys being added every day or does it just take so long to find the newest keys? [10:48] Hobbsee: whooohooo [10:48] HighNo: it has to do a full resync - i'ts not incremental :( [10:49] slytherin: I'm here, I just got 30 min ago out of bed [10:49] i don't know why [10:49] there you are. REVU cleaned out [10:50] 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] geser: Can you tell me your location? I will add location to my clock so I will know when to ping you. :-) [10:51] 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] HighNo: not 'tear it' but 'hammer and crush' it :-) [10:52] HighNo: hehe :) [10:52] slytherin: Dortmund, Germany [10:54] geser: is it 11:55 am there? And looks like you are having good sunny day. :-) [10:54] 55? It was :54 when you sent that message. :-) [10:55] 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] So the clock applet works correctly after all [10:56] geser: (I am from Diepholz, near Bremen) [10:57] slytherin: lucene2 uploaded [10:58] hm, a lot of this can probably be archived, too [10:58] geser: Thanks. :-D [10:59] HighNo: hehe, here in Bremen the count is 2 already :-) [11:00] HighNo: afaics you are not using the proper python install tools [11:00] now I can officially ask anyone to review http://revu.tauware.de/details.py?package=blueproximity [11:00] wow, that was fast :-) [11:01] HighNo: I'm not a motu, but I can give a couple of comments [11:01] 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] imho experience, the easiest is to use python's disttools [11:02] it works perfectly with cdbs [11:02] HighNo: https://wiki.ubuntu.com/PackagingGuide/Basic#head-1858e9b3d419609c46d89d3afc2b25b0f8e155a5 [11:03] 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] HighNo: ubuntu wants to install python programs so they work with several different python versions, the tools take care of that [11:03] mok0: thanks, I will have a look at that [11:03] HighNo: yes, eventually. But let's first get rid of the packaging issues [11:05] 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] 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] debian/control: Build-Depends: cdbs is there twice [11:06] Priority -> optional [11:07] ubotu, ! maintainer [11:07] 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] HighNo: See maintainer: policy ^ [11:07] ok, so I have to add myself as I am the upstream author of the package... [11:08] I wasn't sure if I had to be in there twice... [11:08] HighNo: No, the maintainer is the ubuntu-motu mailing list [11:08] ahh, ok [11:08] HighNo: Put yourself as the XSBC-Original-Maintainer [11:09] HighNo: You have a homepage for blueproximity? Put it in a Homepage: field [11:10] HighNo: debian/copyright. Looks good, but remove the boilerplate #'s at the end [11:10] effie_jayx: excellent. i can request a sync for rbot now [11:11]