[00:12] much better. No more menu clutter! [00:31] OK, I'm closer to done with my first packaging attempt... but I've got a bug. Anybody care to help me figure it out? [00:32] go ahead [00:33] I'm packaging a python app, following a tutorial posted here: http://wiki.showmedo.com/index.php/LinuxJensMakingDeb [00:34] wolfger, Upload it to revu so that we can review it with you [00:34] the problem I have is after I alter paths in the python files (to match where they will be installed by the deb), the end product produces an error: [00:35] k. How do I do that, somerville32 [00:35] wolfger, Were you able to generate a source package? [00:35] mok0: RFC822 is obsoleted by RFC 2822. I stopped reading all the RFCs around 3000, so there may also be a newer one. [00:35] RainCT: Let's wait a bit more. If interdiffs are permitted to go away, we won't need it. On the other hand, if Interdiffs are here to stay, it should reduce the number of people who ask me how to process them. [00:35] * persia notes that while both falcons were reviewed, both parties were advised of the other effort, and both candidate packages had other problems in the last review. [00:36] somerville32: yes I get the .dsc and the .deb and the .deb installs the program [00:36] but it doesn't run [00:37] Using the command dput [00:37] passing revu and then the filename of your dsc file [00:37] ie. [00:37] dput revu package.dsc [00:38] somerville32: should be package*.changes [00:38] persia: so you didn't acked it? :( [00:38] kmos, right [00:39] wolfger, Sorry, you'll want to upload the changes file and not the dsc file [00:39] pochu: I avoid ACKing any NEW packages if I can find any excuse to not do so :) [00:39] persia, 2822 has indeed been superseded [00:39] heh [00:39] Seveas: What's the new one? [00:39] somerville32: right. I just got that message... [00:39] ls [00:39] forgot :) [00:40] persia, hmm, looks like I'm mixing a few things I recently needed [00:40] 2822 wasn't superseded [00:41] somerville32: it finished. The package is "memaker" [00:45] wolfger, What is the link to your launchpad page? [00:45] somerville32: https://launchpad.net/~wolfger [00:46] wolfger, You're not a member of the universe-contributors group meaning that your upload to revu was rejected. [00:47] oh, ok [00:47] https:/launchpad.net/~ubuntu-universe-contributors [00:47] dput said "successfully uploaded", so I believed it... [00:47] It was silently rejected [00:48] somerville32: followed the link and joined. I need to dput again, I take it? [00:48] wolfger, Unfortunately, the keyring for revu needs to be synced before you can do so [00:49] alright. When will that be? [00:49] * persia syncs the keyring [00:50] like magic :-D [00:51] could not dput again. "already uploaded" and "doing nothing" [00:51] wolfger: try dput -f [00:52] Kmos: It won't work yet. The keyring sync has not completed [00:53] ah ok =) [00:54] * wolfger waits [01:05] g'night [01:09] wolfger: Done. Please try again. [01:11] persia: RFC 821/822 are still technically the "Standard" for email. Updates for RFC 2821/2822 to advance them to be the standard are close. RFC 2821bis just finished IETF last call and RFC 2822update is expected soon. [01:11] ... why wouldn't they give it a new RFC number? [01:11] * persia grumbles about the use of the Obsoletes: header when the appropriate STD (11) has not been adjusted, and stands corrected. [01:12] StevenK: RFC editor will do that before they get published. Those are "working titles" [01:12] Ah, right. [01:12] persia, Kmos, somerville32: thanks. dput has finished again. [01:13] wolfger: Should get posted around 01:20 UTC then. [01:14] persia: where will I see it/how will I know? [01:14] wolfger: It should show in the index of packages needing review from http://revu.ubuntuwire.com/ [01:15] persia, How often does http://qa.ubuntuwire.com/uehs/no_watch.php get regenerated? [01:16] somerville32: No idea, and the person who administers it is on holiday. [01:25] I don't see memaker [01:25] No REVU account for wolfger@gmail.com exists yet. [01:26] wolfger: You need to upload source.changes, not i386.changes. [01:26] Who has libopengl-ruby? How about vamp-plugin-sdk? [01:27] persia: where would I find that? [01:28] RAOF: thanks for duping debian 436201 :) [01:28] Debian bug 436201 in libasound2-plugins "libasound2-plugins: Could we get an ia32 package for amd64?" [Wishlist,Open] http://bugs.debian.org/436201 [01:28] wolfger: If you build a source package (-S -sa), it should appear in the parent directory of the package directory. [01:29] !revu | wolfger [01:29] wolfger: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [01:31] crimsun: Ok, ok :). I'll attach a bug watch. Maybe I'll even find time for a debdiff. [01:49] * Hobbsee waves [01:51] * ion_ emits a reverse-phase replica wave. [01:52] thus attenuating Hobbsee’s wave. [01:53] heh [01:53] Heya Hobbsee, persia, ion_ [01:53] :) [01:53] Hi bddebian [01:54] Freenode.find_by_chan('#ubuntu-motu').each {|nick| nick.send 'Hello' } [01:54] * RAOF is influenced by the interacting wavefronts to wave himself [01:54] Heh, hello RAOF [02:01] I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge [02:02] I’d appreciate getting a second advocation for http://revu.tauware.de/details.py?package=hardware-connected [02:07] * persia wonders if packaging malbolge is doing a disservice to users, given that it is especially constructed to be difficult. It may even not be in line with the malbolge philosophy to be able to `aptitude install malbolge` [02:07] What is the CDBS option to specify the manpage? [02:07] It isn't in the CDBS docs [02:07] :-D [02:07] persia: Well, there’s a precedent: PHP. [02:08] somerville32: Just add a .manpages file [02:08] ubotu: !cdbs is CDBS is a tool to share common debian/rules fragments by including them in the makefile. Some documentation, including debhelper hint variables and custom rules is available from http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml [02:09] bddebian, thats too easy :P [02:13] persia: Compiling and running malbolge is so much easier than coding with it. So compiling and installing it is actually rather fun compared to coding. I'm taking away the part which is not that hard. Thus the user will feel even weaker. [02:14] cyberix: You might consider that a bug, and try redoing the upstream build process in malbolge itself, with a bootstrap based on m4 macros. [02:15] :-D [02:15] cyberix: Anyway, aside from the philosophical issues, there are only a couple of packaging issues; commented. [02:15] m4 ♥ [02:15] * RAOF backs away from the crazy man [02:16] persia: dh_makeshlibs doesn't do the trick? [02:16] Oh yes. [02:16] ion_: We have a lovely padded room and a comfy jacket for you to wear. [02:17] cyberix: dh_makeshlibs creates a shlibs file for packages that depend upon the package being built, rather than setting the dependencies directly. The manual is a good place to start. [02:17] In one of my more evil systems, there’s a m4 script that is converted to XML by m4, and the XML is converted to a Makefile by XSLT, and the Makefile handles the actual build process (which consists of a pipeline of filtering stuff with XSLT). ;-) [02:17] ion_: Consider adding a port from Makefile to malbolge, and get malbolge entirely self-hosting, and submit upstream. Four passes sounds like too few, but more might make the dependencies awkward. [02:18] http://gitweb.heh.fi/?p=ion/heroes-scrape.git;a=blob;f=pipeline.m4;hb=HEAD is the file converted to a Makefile (and also a graph, http://heh.fi/heroes/heroes-scrape/pipeline.html) :-) [02:23] persia: The copyright years are missing as some of them are quite hard to find. I could add some of them. How ever they do not have any legal meaning. They are just hints for people who want to contact the copyright holder. And in this case there aren't really any copyright holders as the stuff has been placed into the public domain. [02:23] I'm not sure I fully understand what you think I should do. [02:23] My new copyright file has lots of information. [02:25] Sure you were reading the correct one? [02:26] cyberix: http://revu.tauware.de/revu1-incoming/malbolge-0801081640/malbolge-0.1.1/debian/copyright [02:27] Yes. That onw. [02:27] one [02:28] First, I'm presuming you're not following the new RFC822 format, as it doesn't match that. [02:28] So, if you're following the current format, http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html is the appropriate guideline. [02:30] Looking at your copyright as compared to the good example: it doesn't have "This package was...", "It was downloaded from: ...", and the structure differs significantly. The remainder of the content indicates good reasearch, and would be correct. [02:30] s/a// [02:35] I should avoid listing email addresses of upstream authors? [02:38] upstream authors should be ordered by age? [02:38] Reverse-engineering examples doesn't often work as you'd expect. [02:38] Gotta get some sleep now. [02:38] cyberix: Both the Authors: and Copyright: sections are fine. it's the rest I'm complaining about. [02:40] jonnymind: Good call on the ubuntu-motu email. While I'm not sure you'll have more luck there, it is the appropriate place to raise the dispute. [02:40] Who wants a review? [02:42] i do :) http://revu.tauware.de/details.py?package=libopengl-ruby [02:43] go persia, go persia :-) [02:43] snoutmate: The very name of your package makes me shiver. Is that really worthwhile prior to ruby 1.9? [02:43] bddebian: Feel like looking at hardware-connected, mscore, or livemix? [02:44] snoutmate: any reason why not ? [02:44] err [02:44] persia: any reason why not ? [02:45] persia: Look at, as in review? [02:45] snoutmate: relative speed of interpreter and GL calls, but maybe it's just me (and this won't influence my review). [02:45] bddebian: Yep :) === mwolson|test is now known as mwolson [02:45] bddebian: I failed to find any reason to reject any of them, and need some help. [02:46] persia: They were rejected? [02:46] bddebian: Not yet. Perhaps you can find a reason. [02:46] Oh, you want them rejected? ;-P [02:47] bddebian: Unless you can't find anything, yes :) [02:47] Off topic... If I package my own program, is it better to put debian/* into orig.tar.gz or into diff.gz? [02:48] The debian/ dir should never be in orig.tar.gz [02:48] ToyKeeper: diff.gz [02:48] persia: well it builds both against 1.8 and 1.9 if that's what you mean. I don't see the relevance of speed (yeah with 1.9 it's about 3x faster then with 1.8 and actually outperforms perl-opengl), as it is simple an update .. [02:49] snoutmate: We already have libopengl-ruby in the repos. Please submit an interdiff to the sponsors queue. [02:50] snoutmate: Also, you want "(LP: #182449)" to close the upgrde bug, rather than "- closes: #182449". [02:50] persia: yeah, but as this is large update (new project team, new build system, different installed files) i thought uploading to revu was appropriate (sorry i'm new to ubuntu packaging) [02:51] Okay, good. I guess I'm doing it right so far. :) [02:51] snoutmate: No problem. Based on the small debian/, I'm guessing the diff.gz is fairly small, and the main updates are upstream. Best to push to the sponsor queue so you're not waiting for Mondays, and to make sure the right people see it. [02:52] persia: ah, ok [02:52] Who else wants a review? [02:52] thanks [02:52] Could you please define pushing to the sponsor queue? Does that mean subscribing universe-sponsors (or whatever it was) to a new bug report with the interdiff attached? [02:54] ion_: Yes. See https://wiki.ubuntu.com/MOTU/Contributing, https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue, and https://wiki.ubuntu.com/UbuntuDevelopment/Interdiff for more information. [02:54] Thanks for the pointers. [02:57] Is bazaar still recommended for ubuntu packaging? I'm more familiar with hg, svn, and git, but could switch to be consistent. [02:57] I quite like git because it’s insanely faster than bzr and you can have the upstream stuff *and* the packaging in different branches under the same repository. [02:57] it dosent NEED to be in a svn [02:58] err RCS [02:58] That, too. [02:58] ion_: you can do the latter in bzr too [02:58] ToyKeeper: Last I checked, there were over 10,000 packages in the archive. While many people recommend bzr, there are also packages using cvs, svn, hg, git, etc. The vast majority don't use any VCS at all. [02:58] lifeless: In other news, I hit level 61 in WoW. :-) [02:58] lifeless: Yes, but bzr switch is more hassle than what git does. [02:58] StevenK: grats [02:58] imbrandon: VCS. rcs is a cvs precursor [02:58] StevenK: in oter news i hit lvl 14 :) [02:58] lifeless: Thanks :-) [02:59] imbrandon: You're playing? [02:59] StevenK: yea [02:59] StevenK: I've hit 70, and 1/3 attuned for kara [02:59] imbrandon: Which realm? [02:59] * StevenK is trying to sort out his Dreadsteed [02:59] Eldre'Thalas [03:00] I've been playing a bit with mercurial patch queues... seems good for packaging. But I got the impression that new packages use bazaar when possible. [03:00] WoW runs in Ubuntu? [03:00] somerville32: Runs very nicely on my amd64 [03:00] and i386 :) [03:00] imbrandon: I've got a level 61 warlock on Dath'Remar [03:01] Would it run on 1.6Ghz w/ 512mb of ram and a gForce 6 series? [03:01] Mine too. Although either something was screwy last night or there've been some recent wine regressions. [03:01] persia: Well there isn't much too hardware-connected :-) [03:01] I'm using the wine package from Gutsy directly. [03:01] StevenK: ME --> http://www.wowarmory.com/character-sheet.xml?r=Eldre%27Thalas&n=Cabaal [03:01] me also [03:01] ( wine from gutsy ) [03:01] somerville32: I would suggest more RAM. [03:01] ion_: Quick: defend your package against bddebian's accusation of uselessness [03:01] Bwahaha [03:01] heh [03:02] StevenK: it hasent updated yet, i'm 14 now [03:02] 14?? WTF? [03:02] Are there any free, MMORPGs that you guys play that I could play too? :P [03:02] bddebian: i just started playing friday :) [03:02] sigh, more WoW discussion :) [03:02] persia: Did someone claim it’s supposed to be useful? ;-) [03:02] Oh, level 14 [03:02] ajmitch: !!!! [03:02] ajmitch: ! [03:02] bddebian: what? [03:02] lol [03:02] * persia thought adding packages known to be useless to the archive was not preferred. [03:02] ajmitch: Haven't "seen" you in a while [03:02] persia: Not preferred by me [03:03] ajmitch: Welcome back [03:03] bddebian: that's because I haven't been around for awhile [03:03] persia: I'm not back [03:03] ajmitch: I know :-) [03:03] I have no internet connection at home still [03:03] nasty [03:03] Anyway, when you have a list of modaliases for some hardware (say, /usr/share/linux-restricted-modules/$(uname -r)/modules.alias.override/nvidia) and you want to check whether any supported hardware exists in the system, hardware-connected is useful. [03:03] Urk [03:03] still waiting for phone & DSL to be connected [03:03] StevenK: i play on that server because some people at work do too [03:04] ( namely most of the DawnBringers Guild ) [03:04] imbrandon: http://www.wowarmory.com/character-sheet.xml?r=Khaz%27goroth&n=Iosephus <-- me [03:04] * imbrandon looks [03:04] ajmitch: wow [03:04] Crusader of the Flame, eh? [03:05] Lamers [03:05] * StevenK digs his up [03:05] * somerville32 doesn't have one :( [03:06] imbrandon: that's nothing special [03:06] http://www.wowarmory.com/character-sheet.xml?r=Dath%27Remar&n=Kelleigh [03:06] ajmitch: better than my 3 day old lvl 14 :) [03:06] I haven’t retrieved the Amulet of Yendor and ascended yet. [03:06] imbrandon: 3 days? you must be addicted already :P [03:06] Haha [03:06] ascended ? heh , sounds like SG-1 [03:07] imbrandon: That's a nethack reference [03:07] ahh [03:07] ajmitch: Have you dug around Un'Goro Crater? [03:07] (Crappy zone that it is) [03:08] StevenK: of course [03:08] ajmitch: One of my friends was killing gorillas there and one of the loot items was an Empty Barrel [03:09] there's plenty of interesting loot that drops [03:09] * ajmitch wonders if people will put their names forward for the MC [03:09] I just love it due to the Donkey Kong reference. [03:09] Since i have a screen full of offtopicness already, perhaps pasting this to the channel doesn’t hurt. :-P http://johan.kiviniemi.name/blag/2008/01/10/svn-diff-git-diff-speed/ [03:09] imbrandon: You need to learn some professions. [03:09] http://www.wowarmory.com/character-sheet.xml?r=Jubei'Thos&n=Canid [03:10] StevenK: yea i havent left the starting area yet [03:10] StevenK: i probably will later tonight [03:10] lifeless: good luck on those last 10 points in tailoring, they'll be expensive :) [03:10] Haha [03:10] jez, does eveyone play WoW :) heh [03:10] * bddebian doesn't [03:10] imbrandon: yes [03:10] I need to level my tailoring up [03:10] ajmitch: I have the next 5 lined up already [03:11] bddebian: buy the crack [03:11] I have 221 pieces of Runecloth that I can't turn into bolts. [03:11] ion_: yes, but svn is slow. [03:11] heh, they FINALY talked me into it at work [03:11] imbrandon: I'll stick to my single-player NWN thanks :) [03:11] A mage that skins. Interesting [03:11] StevenK: more monies [03:11] StevenK: money while levelling, and mats for higher level tailor items [03:12] * ajmitch had mining & skinning until not long ago [03:12] * imbrandon isnt sure what profession to takeup [03:12] imbrandon: what class are you ? [03:12] * somerville32 nominates persia for MC [03:12] hunter [03:12] lifeless: lvl 14 atm [03:13] skinning for sure [03:13] Except the Armory says level 12 [03:13] armory updates fail sometimes ;) [03:13] StevenK: it hasent updated today yet, i leveld 2 times earlier [03:13] Mmmm [03:13] * persia tasks each of imbrandon, StevenK, and lifeless with one review for filling backscroll with WoW [03:13] :-) [03:13] heh [03:14] I wish my Armory page would update - I'm the Lords of War now, not The Dark Tabards [03:14] s/the/in/ [03:14] imbrandon: also I'd probably suggest leather (makes mail uniques at high levels) or blacksmithing (also can make mail), or engineering (guns and shit) [03:14] yea i thought about mining and engneering [03:15] but definately skinning cause you are going to be killing SO MANY BEASTS as you level [03:15] yea most of the time i just let them lay [03:15] heh [03:15] * StevenK is pondering starting a Rogue after Kelleigh hits level 70 [03:15] i dont even loot anymore atm [03:15] also, three hints [03:15] Anyone willing to review package photoml (http://revu.tauware.de/details.py?package=photoml)? It's already been advocated once (the previous upload, at least), so it should be very close to being acceptable. [03:15] 6 skill levels per character level [03:16] StevenK: if you roll a new char we should start a Ubuntu People Guild [03:16] loot everything [03:16] heh [03:16] buy the biggest bags you can, and upgrade every chance you get [03:16] StevenK: I've started a mage, anyway === jpatrick_ is now known as jpatrick [03:16] * StevenK has a level 24 mage [03:16] * ajmitch needs to get into the 25-man raiding a bit more though [03:17] Is there any free MMORPGs that are like WoW? :P [03:17] It sounds like fun [03:18] lifeless: By that count, you'd hit skill level 375 during 62->63 [03:18] And I was just wondering. How many of you guys complain about using restricted drivers but rely on them to pay WoW? :P [03:18] WoW is too addicting. [03:18] *play [03:18] I don't complain about them. :-) [03:18] heh heh [03:18] i dont complain about them [03:18] neither do I, though I'd really like some free drivers :) [03:18] hello jml [03:19] ajmitch: hi [03:19] flash == much more evil than drivers [03:19] jdong: ping [03:20] persia: i would but it takes a certain mindset for me to review, and $time-of-day isnt now [03:20] heh [03:20] * RAOF occasionally bitches about restricted drivers, and does something about it by building nouveau drivers. [03:20] RAOF: I imagine that WoW wouldn't overly tax nouveau drivers once the various pieces are in place [03:21] ajmitch: Such as any form of textured 3d. [03:21] We should get a #ubuntu-gaming or #ubuntu-game channel going :P [03:21] StevenK: 375/60 [03:22] -wow :) [03:22] join #ubuntu-wow [03:22] lifeless: That's 6.25, though [03:23] StevenK: yes, a little down is tolerable; its about matching the mats you gather to your skill [03:23] persia, bddebian: I posted a use case to http://revu.tauware.de/details.py?package=hardware-connected [03:23] lifeless: Mmmm. [03:23] lifeless: I need more Mageweave. About 50 bolts, by my count. :-( [03:23] I suspect I will be running ZF again for it. [03:23] StevenK: right; and you are not gathering it any more, because you let your skill get too far behind your level [03:24] lifeless: No, because I ran out of Mageweave. [03:25] ion_: Do you need this for the updated nvidia drivers you're working on? [03:26] StevenK: yes, I know you did:) if you'd been trying to keep things synced you could have run areas you'd still get yellow xp for ;) [03:26] persia: I’m not currently working on nvidia drivers, but i’ve considered implementing exactly that change in linux-restricted-modules. [03:26] Ah [03:26] persia: That was my inspiration for writing hardware-connected in the first place, since i implemented that as a sh function and noticed it was unbearably slow. [03:28] ion_: Well, it's been advocated all it needs for universe, but that would require migration to main. I suspect you could get one of your l-r-m sponsors to upload if there's a good chance that an MIR would be approved. [03:29] I’m not sure how soon the nvidia-glx thing could be implemented, and others might find hardware-connected useful for other things, so i was thinking it should go to universe for now. [03:29] ion_: If you're just striving for universe, advertise for an uploader. [03:30] Will do. [03:36] * persia wonders about the difference between "speed" and "speed-game" [03:36] * persia archives "speed" [03:55] Hi everyone, I created the ubuntu package from the actual debian package for gnucash 2.2.3 and I wish to upload it to repositories, so I would need a MOTU to review my work and accept it for Hardy. [03:55] This package includes the upstream fix for a high priority bug with scheduled transaction, use the recently changed libgif ( bug #174252 ) in build-depends and fix bug #179104 [03:55] Launchpad bug 174252 in libungif4 "transition to libgif" [Undecided,In progress] https://launchpad.net/bugs/174252 [03:55] Launchpad bug 179104 in gnucash "[hardy] Please sync 2.2.2 from debian" [Wishlist,New] https://launchpad.net/bugs/179104 [03:56] also bug #155059 [03:56] Launchpad bug 155059 in grisbi "Description does not contain the word money" [Wishlist,New] https://launchpad.net/bugs/155059 [03:57] the new gnucash source package is here [03:57] http://upload.leservicetechnique.com/bugs/gnucash_2.2.3.tar.gz [03:58] saivann: This is a merge from debian? [03:58] persia : right [03:59] saivann: Is there a merge bug? [03:59] anyone got a sec to help me with an error building something with pbuilder? [03:59] I'm getting the error here with intltool: http://ubuntuforums.org/showthread.php?t=525284 [03:59] but since I'm using pbuilder I can't just make a ln -s for getting around the intltool searching only current dir [03:59] persia : Actual debian unstable package + ubuntu bug fix that I mentionned and a fix for the missing icon for ubuntu which is already applied to the current ubuntu gnucash version [04:00] persia : A merge bug? [04:00] rick_h_: What environment are you running in? Dapper has intltool 0.35.0-0ubuntu1. Is there maybe a missing build-dependency? [04:00] !merging | saivann [04:00] saivann: Merging is the process of including changes from other distributions (most commonly Debian) into Ubuntu packages, and is typically a major focus at the beginning of each Ubuntu development cycle. Please see https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information. [04:00] persia: I'm in gutsy with a gutsy pbuilder install [04:00] persia : https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/179104 [04:00] Launchpad bug 179104 in gnucash "[hardy] Please sync 2.2.2 from debian" [Wishlist,New] [04:01] intltool is in the control as a build requirement and when pbuilder runs it shows it getting intltool [04:01] so it seems that it just isn't looking in the right spot [04:01] saivann: Since you need to add an additional patch, retitle the bug as a merge, attach your debdiff against Debian, and subscribe ubuntu-universe-sponsors [04:01] persia: paste of pbuilder here: http://paste.avwsystems.com/paste/79 [04:01] persia : Sorry I didn't know that procedure, do you want me to provide needed debdiffs between the debian version and my actual ubuntu version? [04:02] persia : Ok I'll do it in the next minutes, thanks [04:02] saivann: Yes. Please provide a debdiff with all proposed Ubuntu variation from debian, and subscribe the sponsors. Someone will review, and either upload or reject with an explanantion. [04:02] persia : Thanks [04:04] persia: What's speed-game like? [04:05] bddebian: Haven't tried it. channel traffic included a couple good reviews (nice game, fun). [04:06] Hmm [04:06] rick_h_: Looks to me like there might be a missing file for the intltool check in the upstream tarball. [04:06] Not that I can get jack shit done on the Games Team anyway [04:07] ok, maybe I'll see about trying a bug report in intltool and see what happens then [04:07] bddebian: I thought you just played WoW [04:07] I never play WoW :-) [04:09] rick_h_: I'm not convinced it is a problem with intltool. The error message says "awk: cannot open ./intltool-update.in (No such file or directory)", so I'm guessing that either the script calling awk is being given the wrong path, or that the tarball is missing a file. [04:10] s/being given/giving/ [04:10] Damn, sdlmame is still not in Ubuntu? [04:10] LaserJock: Thanks for the Golden Pony [04:11] Heh, xmame is usually lagging... and I doubt there's as much demand for sdlmame. [04:11] persia: yea, it might be something with the autotools stuff this app is using [04:11] So I'm going to start with the original app mailing list and see what anyone else says [04:11] bddebian: it's really close... [04:12] ScottK: np [04:13] If I knew all it took was being grumpy and argumentative .... [04:14] if all it took was being grumpy, I'd have received a truckload of them [04:15] ajmitch: Must have needed more argumentative then. [04:15] probably [04:15] ScottK: well, even though I don't always agree, I do appreciate somebody taking a firm philosophical stand. Helps keep us honest ;-) [04:16] I prefer to leave the arguing to others, helps with my stress [04:16] * persia thinks if more people agreed with ScottK, we'd have a poor forum for discussion [04:16] LaserJock: Thanks. It takes extremists on both sides to keep to a happy middle. [04:16] * ScottK disagrees with persia. [04:16] Wanna argue? ;-) [04:16] hehe [04:17] ScottK: No value. Your offer demonstrates the value of contrarianism :p [04:18] * ScottK disagrees. [04:18] It demonstrates the value of humor. [04:19] well, I'm afraid this was most likely the last of the Golden Ponies, at least from me [04:19] why the last? [04:19] LaserJock: Why? [04:20] a few reasons [04:20] I'll be graduating/looking for a job/moving when Hardy is finished [04:20] I'm really not very creative [04:20] LaserJock: You just need to add more judges to the Aurean Equine Academy [04:21] that would work [04:21] I would love nominations or something [04:21] but I just don't want people to get upset if they don't get one [04:21] and I don't know as many people as I used to :/ [04:21] * ajmitch isn't completely upset for missing out [04:21] I know that it's not because you hate me (or at least I hope it's not) :) [04:22] heh [04:22] So, pick two or four more judges (odd numbers are good), get their acceptance, and put out a call for nominations around Beta Freeze. That ought produce something useful for just after release :) [04:23] LaserJock: Congratulations on the graduating bit. [04:23] ScottK: heh, well it hasn't happened yet [04:23] but it's supposed to [04:23] * ajmitch wonders if he could collect some 'MOTU emeritus' title [04:23] ohhhh, nice [04:23] We can call \sh_away motu-reloaded. [04:24] haha [04:24] ajmitch: That's not a bad idea. How would you imagine "MOTU emeritus" status to be granted? [04:24] retirement in good-standing? [04:24] hehe [04:25] LaserJock: I'm not exactly in good standing though [04:25] well, you aren't in bad standing :p [04:25] dunno about that [04:25] maybe you're just lucky to be standing ... [04:25] I haven't been lynched yet [04:25] * bddebian gets the ropes [04:26] * persia files some removal bugs [04:26] see [04:27] ajmitch: Actually, should all of gnue-* go, or just the ones that will break when bddebian finishes excising wx2.4? [04:28] persia: Already being done it appears [04:28] * persia checks bugs again [04:29] I mean excising wx2.4 [04:29] * ajmitch shrugs, probably all [04:29] ajmitch: Thanks. [04:32] hmm, this looks nifty/useful: http://www.chris-lamb.co.uk/2008/01/14/gnome-applet-for-monitoring-debian-bugs/ [04:39] LaserJock: be nice if it was a deskbar plugin [04:40] pffft, deskbar ... ;-) === superm1_ is now known as superm1 [04:40] do people actually use deskbar? [04:40] LaserJock: Some do. Quicksilver addicts mostly [04:40] bah [04:41] I'm a quicksilver addict and it's the reason I dislike deskbar [04:41] if you're gonna clone the best at least do it right ;p [04:42] bddebian: I see all the same problems re: WX2.4 as I did for hardy release, and Debian still hasn't fixed trustedsql either. [04:42] s/hardy/gutsy/ [04:42] persia: I have to upload jugglemaster yet and post the newpki-client patch on BTS (I've already sent it to the maintainer). They aren't going to wait for ctsim [04:43] Did anyone ever fix survex, or do I need to stop being lazy about that? [04:51] guest22: photoml commented. Needs more licensing clarity. Especially needs preambles in the source files. [04:51] * persia seeks nominations for a candidate upload to review [04:53] persia: Thanks for the comments. Do I understand correctly that your concerns are with the upstream source rather than the packaging itself? [04:53] guest22: Entirely. The packaging is clean. I'm just not sure the upstream source is licensed in a way that the archive admins wouldn't reject. [04:54] Would you mind expanding on those problems? The license is very clearly spelled out in the README file. Is it really necessary that it also be mentioned in every other file in the distribution? [04:56] guest22: Not the entire license, just the header. See /usr/share/common-licenses/GPL-2 under the "How to Apply These Terms to Your New Programs" section, where it mentions the notice to attach to the start of each source file. [04:57] persia: If there's a full copy of the license in the upstream tarball, it's been my experience that they won't reject for lack of license headers in files (although upstream should definitely be asked to add them). [04:57] I'm not sure the GPL actually requires this, but I've seen packages rejected by the archive admins for not having those four paragraphs in the source files. [04:57] ScottK: I've seen both behaviours. [04:57] It may depend on which archive admin is doing the reviewing. [04:58] Not having the full text of the license is a guaranteed reject [04:58] photoml doesn't suffer from that: only the missing source headers on some files. [04:58] (and no copyright assertion for the manpages) [04:59] If he made the man pages, then that can be fixed [05:00] ScottK: Fixed how? By a new upstream source release, or via some packaging mechanism? [05:00] ScottK: upstream manpages, and yes. Looks like about 3-4 hours work to me to fix everything, and about 30 minutes for the manpages alone (considering the overhead of a new upstream release with release notes, etc.) [05:00] Hmm, in python, is it preferable to put the license info in a docstring or a comment? [05:00] guest22: All the issues are with upstream: best fixed by a new upstream. [05:00] ToyKeeper: Comment is fine [05:01] persia: Could we try to agree now on which files need the copyright, to avoid another iteration later? [05:01] guest22: Best way is a new upstream release. If you can't get that, you can patch the man pages [05:02] ScottK: A new upstream release is fine, but I'd like to make sure I catch all of the remaining problems in that release. [05:02] ScottK: Oh, good. I was hoping I wouldn't need to change it. :) [05:02] guest22: I generally run `less $(suspicious-source)` from the package directory to select which files to inspect. I don't know what the archive admins use. The general rule is that anything not trivial should be licensed. [05:03] persia: What is and isn't trivial is a rather subjective judgement. [05:03] Or rather, anything that falls under copyright should be licensed. This avoids confusion about the meaning of "trivial" [05:04] persia: Surely everything in the package falls under the blanket copyright asserted in the README? [05:04] (and yes, it's still subjective until argued, but nobody here is giving you legal advice) [05:05] guest22: Maybe. I've seen too many rejections for that to feel comfortable advocating or uploading when there are lots of missing headers. You might get other reviewers to advocate and upload the current candidate: as I said, the packaging is fine. [05:06] persia: If there's a potential problem, I'm quite prepared to fix it. (Although hopefully doing another upload won't push photoml so far down the queue as to not have any chance of making it into hardy.) [05:07] guest22: From the current location, a new upload will move it up in queue. On the other hand, being active about advertising your package (as you've been doing) helps a lot towards getting it in. [05:08] persia: It seems to be that I need to add copyright statements to all scripts, man pages, docs, dtd, and xslt. Do you think that covers it? [05:08] For example, some of the makefiles are non-trivial, but surely they don't also need a copyright header? [05:09] guest22: Only the stuff you want to copyright. You may wish to specifically release the DTD or some of the examples into the public domain for reuse for any purpose. If all the perl scripts had it, and most of the stuff with the specific copyright notice, it wouldn't have been sufficient volume to cause a reject from me, only a warning note. [05:10] persia: Any constraints on the form of the header? Will something like "This file made available under the terms of version 2 of the GPL" do? [05:11] guest22: The GPL itself contains information on the recommended header, in the "How to Apply These Terms to Your New Programs" section. [05:11] * persia notes that the GPL should be read carefully and in full by anyone considering the GPL as a license for their software. [05:11] 4 paragraphs seems a bit much sometimes, but it's fairly clear on the issue. [05:13] persia: The full verbiage recommended in the GPL is quite verbose for some of the simpler source files. My question is not what is recommended, but what is the minimum length statement that would be considered acceptable to clearly indicate the licensing? (I presume there is a difference.) [05:15] guest22: I'm not someone who makes the determination as to what is acceptable for inclusion in the archive. From my reading of the GPL, it is a choice between those four paragraphs and nothing, with the GPL indicating that "It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty, and each file should have at least the "copyright" line and a pointer to where the full notice is found.". [05:18] persia: But as you point out, the GPL states "each file should have at least the "copyright" line and a pointer to where the full notice is found.". This seems to imply that including only the copyright line and an explicit pointer to the copyright file in the distribution is sufficient. [05:18] Would you have problems with that approach? [05:20] guest22: It may be. If you disagree with me, feel free to push another candidate to REVU addressing the manpage bit, and leave a comment with your opinion. You may find others who agree with you, and the archive admins may accept it. I don't see any issues with your reasoning, but have seen similar packages be rejected for missing the header in one source file. [05:20] guest22: As ScottK said, it depends on the specific archive admin doing the review. Some will ignore that, and just let it in. [05:22] persia: You clearly have more experience in licensing issues than I do, which is why I want to make sure I understand your advice. Since the GPL itself explictly allows for the copyright-and-license-pointer approach, do you still feel this is potentially problematic? (Your response seems to suggest yes, but I'd like to understand why.) [05:22] guest22: If at all possible, get the full notice into each source file. Then there are no potential issues. [05:22] guest22: I don't know why it would be problematic. I've just seen it be cause for rejection from the NEW queue, and so use that as a guideline when reviewing the packaging. [05:23] ToyKeeper: No potential issues, but as you mentioned above, the full 4 paragraphs are a bit much for some source code. [05:23] guest22: My philosophy is that if I reject for every reason I can imagine, the package will be perfect when it reaches the archive admins. This is not necessarily the best philosophy, and my comments may be too strict. [05:23] persia: You've seen packages rejected because the source had a copyright statement and pointer to the license, but not the full 4 paragraphs? [05:24] guest22: I believe so, yes. I may be wrong. I have also seen packages accepted that didn't meet the licensing guidelines I follow, so I may be too strict. [05:26] * persia complains about the lack of orig.tar.gz for alliance, and encourages speedy reupload [05:27] * ToyKeeper wonders why an extra 600 bytes per source file would be worth increasing the risk of legal confusion [05:27] persia: Questions about the other issues you raised. I assume 1. (patching) is just a suggestion, and not an impediment to advocation. As for 2., what is the file definition file to which you refer? In 3., do trivial example XML files really need a GPL header? [05:28] ToyKeeper: I don't think a clear statement of copyright and pointer to the full license does leave any legal confusion, and prefer to look as little like a lawyer as possible. [05:29] But yes, if that's really required, one might as well suck it up. [05:31] guest22: 1) Yes, just a suggestion. 2) I meant "film" not "file" :) ./xml/definitions.mod, and this was just the first I encountered. 3) I don't think that trivial example files need copyright assertion, let alone licensing. I encourage you to treat these as public domain, for reuse by users for any purpose. [05:32] persia: And what do I need to do to treat those as public domain? [05:35] Depends on how explicit you want to be. A common method is to not assert copyright, describe them as public domain and free for any use in README, and list this in debian/copyright. [05:36] If you want to be extra explicit, you can include something like that on the top of the dh-make debhelper example file, but I think that's overkill. [05:37] For some programs, the examples just fail to assert copyright, and the author doesn't plan on suing anyone (but doesn't indicate that). The risk here is that the author's heirs may not be so considerate. [05:39] persia: Can one make a statement such as "all files not including copyright information are in the public domain" in README, or do these need to be explicitly listed. Is there a required format to the corresponding statement in debian/copyright? [05:40] (This is starting to be more painful than debugging XSLT.) [05:48] guest22: I'd probably put everything in an examples/ folder, and just add a note saying that the examples in the examples folder are public domain. The examples folder would be installed with dh_installexamples. In debian/copyright, you would add a section that the files under the examples directory are public domain. [05:48] Note that "public domain" doesn't mean anything in some jurisdictions, so be sure to also indicate that they are free for any use. [05:50] persia: OK, thanks again for the advice. I'll attempt to implement your suggestions and re-upload. I hope you won't mind taking a look again once I've done that. [05:51] guest22: I generally try to avoid reviewing the same package twice, as I believe the best packages are created when lots of different viewpoints are included. If I've still time when I've finished reviewing all the packages for which I'm not the last reviewer, I'll take a look. [05:52] s/twice/twice-in-a-row/ [05:52] persia: Understood. [06:07] /lastlog jdong [06:07] grr [06:07] and contentless ping loses over sleep :) [06:17] good morning [06:23] jdong, i had pung if you are around still before sleep [06:23] jdong, it was regarding faac [06:23] since you had touched it last [06:24] mornin dholbach [06:24] hey superm1_ [06:24] how's your new year treating you thus far? [06:25] very good - very busy too, but I'm happy [06:25] how 'bout you? [06:25] well i've been on vacation the last week, and just got back this weekend [06:25] finally very relaxing :) [06:26] i was quite scared to see my inbox when i returned [06:26] and how's it looking? [06:27] well it was pretty bad, but its fine now [06:27] vacation sounds great - I have some (long) weekend trips planned in the next months and I look forward to that :) [06:28] * dholbach hugs superm1_ [06:28] additionally i'm moving Tuesday, but don't start work until early February, so i'll have more free time until then which i look forward too as well [06:28] * superm1_ hugs dholbach back [06:29] I wish you all the best with that! [06:29] thanks :) [06:57] Good night all. [06:57] night ScottK [06:57] hey slomo [07:00] hey slomo [07:10] hi everyone [07:23] * persia seeks an alternate reviewer for libserial, qdevelop, and qtsmbstatus. None of these packages have had a review in 2008, and would be happy to get one. [07:25] 2008 has only been 13 days. [07:25] 14, here. [07:25] i've had packages awaiting review when you were still in diapers! [07:25] desrt: Which means that these packages have been waiting two weeks for a review. With a REVU day every week, that shouldn't happen. [07:26] * persia hunts down DOB references for Mr. Lortie [07:26] persia: I suspect qevelop and qtsmbstatus have had no reviewer since people are allergic to QT? [07:26] * desrt /whois persia [07:30] StevenK: Maybe, but I don't like to see things just sitting there this close to FF, and don't want to be the only reviewer for a package I will never use. [07:39] LucidFox: smplayer-themes advocated [07:40] persia> Thanks! [07:56] bobbo: ckkern commented === ember_ is now known as ember [08:06] rulus: gtkvd commented [08:11] does libslab0 contain the "SLAB menu"? From the description, one would think so. Yet nowhere is mentioned, how it can be used/started/integrated. [08:17] thanks persia! [08:17] rulus: Did you ever get anywhere with gnuvd also? I know it's older, and may be deprecated, but getting a patch might be good. [08:17] SWAT: libslab0 contains the shared libraries for that. The package you want is gnome-main-menu [08:18] persia: the bug is filed at Debian and forwarded to the author of gnuvd. Gnuvd is written in C, which I hardly understand. [08:18] rulus: Understood. [08:19] I'll look into the comments later, preparing for an exam now. Thanks again ツ [08:20] tsu [08:20] * persia notes that ツ and シ have specific pronunciations, and are rarely used as smilies in their country of origin [08:21] * rulus knows, but it looks cool [08:21] ダメよう [08:22] ワテファク [08:22] ion_: That's terrible [08:23] s/ble/ble :)/ [08:25] StevenK, thanks. [08:28] amarillion: speed-game commented [08:34] good morning [08:37] Good morning geser. [08:37] Hi TheMuso [08:39] rzr: jaaa advocated [08:40] great [08:40] persia: thx again for all your support [08:41] rzr: There were a few minor notes, if you want to clean them up. I'm also surprised that $(MAINPACKAGE) didn't work. You might ask around to see if there is another variable to avoid you setting it manually. [08:41] yes will to this evening [08:41] i have to go [08:42] later [08:42] geser: Thanks for helping with reviews. It is very nice to see another name in the comments. [08:49] g'morning! [09:02] anyone please review http://revu.tauware.de/details.py?package=sdlmame [09:02] I know I already have some trivial fix to commit, but I'm at work now [09:07] wallyweek: Last review (today) was pretty positive, but until you've applied the fix, I doubt you'll see an advocation. [09:10] James Lee: 1) Please add your IRC nick to your LP page. 2) fuppes commented. [09:15] persia: good, but I would like to know if there's something more to fix to avoid more time waste. Could you have a look at it, please? :) [09:20] wallyweek: You've hit most of what I found already. I suspect you'll get it in faster if I wait to review until you've had a chance to upload again, as I won't want to review it twice this REVU day. [09:21] persia: ok, I'll fix it at lunch time [09:22] persia: do you think section "games" is good? [09:23] wallyweek: I think sdlmame belongs in section games and sdlmame-tools belongs in section misc. Some people might argue that both belong in otherosfs. [09:29] persia: I agree with you. Perhaps I could have a look at other emulators and see how they've been managed? [09:29] wallyweek: That sounds like a good plan. xmame might be a place to start. [09:29] persia: ok, thanks! [09:31] * persia points at http://revu.ubuntuwire.com/revu1-incoming/gnomecatalog-0801132110/gnomecatalog-0.3.3/debian/gnomecatalog.1 as a reference for why automated manpage checkers are not always sufficient. [09:32] thats one short manpage :P [09:34] Hehe [09:34] persia: looks like newer packages for emulators are in otherosfs (stella, dosbox, vice, spectemu) and older ones (xmame, visualboyadvance) are in games [09:34] josesanch: gnomecatalog commented [09:35] wallyweek: To me that indicates that the previous practice was to separate by section, and the current practice is to use otherosfs, but I'm not really that familiar with emulator packaging. [09:36] I’d s/Cd/CD as well. [09:36] +/ [09:37] ion_: If you wanted to provide a manpage patch via email, I'm sure josesanch would appreciate the help. [09:37] persia: that makes sense. I think I should use otherosfs then, xmame and visualboyadvance are no longer maintained upstream afaik [09:37] i bet packagers are didn't look at them for quite a lonk [09:37] time [09:38] whoops! keyboard mess! :) [09:44] norsetto: gimp-normalmap commented [09:56] Hi Fujitsu === bigon` is now known as bigon [10:07] A comment from debian-multimedia.org: [10:07] 'I see two bugs in your package : 1) in the menu files the icon should be the full path with the file extension : icon="/usr/share/pixmaps/qdvdauthor.xpm" instead of icon="qdvdauthor"" [10:07] Is this true? [10:11] LucidFox: Maybe. I was sure I'd seen a number of cases where the icon wasn't absolute, and I know the executable isn't supposed to be absolute, but I can't find evidence either way from the documentation. You might check the source of one or another backend, or use the absolute path for now. [10:11] I typically use the menu-xdg backend, so bare icon names get passed to the icon cache from the generated .desktop, masking whether this would be a bug for other backends. [10:16] wolfger: memaker commented, overflowing the comment space. [10:19] LucidFox: What was #2? [10:21] dh_desktop call should be immediately after dh_installmenu. [10:21] He fixed both when merging the changes. [10:22] LucidFox: I can't imagine it matters where dh_desktop call is placed, as it only adds a clause to postinst and postrm, but I also don't think moving it hurts anything. [10:25] In any case, DMO has merged all Ubuntu changes except for the source-contains-cvs-control-dir Lintian override, and there is also the libxine1-x issue which is Ubuntu specific. This will be a small debdiff. [10:26] LucidFox: libxine1-x is Ubuntu-specific? I thought that transition was underway (or intended to be so) in Debian as well. [10:27] Reply from DMO: [10:27] 'Also libxine1 is badly packaged on Debian, the qdvdauthor package [10:27] still debpends on libxine1 instead of like you, on "libxine1-x | libxine1"' [10:28] Ah, so DMO doesn't want to be compatible with either Debian or Ubuntu :) I understand. [10:28] Heh. [10:28] Are there any other improvements in DMO other than merging the Ubuntu changes? [10:28] New upstream release. [10:28] Ah. Well then, small debdiff it is :) [10:29] Maybe he doesn't yet know that Debian accepted xine-lib with libxine1-x three days ago. [10:31] Maybe worth pointing that out, and waiting for -2? [10:33] geser: SCons upstream believes aqsis is going to need a bug fix - the error handling in scons is obviously crap but aqsis only ever worked through luck. [10:33] Well, it will probably take a while before he uploads the new libxine and rebuilds everything depending on it. [10:34] aqsis ever worked? I remember that package having persistant failures. [10:34] Should I re-add Ubuntu entries to debian/changelog? [10:34] past ones, that is [10:35] LucidFox: If there was never a sync, yes. Once there was a sync, you only need to restore those since the last sync. [10:36] There was a sync of 0.1.2-0.0 in Feisty, so I'll only add entries since then. [10:36] In Edgy, even... Feisty had the same version [10:45] amarillion: alex4 commented [10:52] * Yagisan cries. he just built llvm 2.1 (because the ubuntu packages too old), and that took hours - and he now needs to download and build a 52MB llvm-gcc source package :'( [10:53] A new LLVM would be nice indeed. [10:53] ion_, make sure you CFLAGS/CXXFLAGS has no , in it, or it will FTBFS half way [10:54] ion_, I need it for lostsoul here -> http://dengng.bpa.nu:8010/ [10:57] Yagisan! [10:57] StevenK, ! [10:57] Yagisan: Long time, no see. [10:57] long time no see [10:57] * StevenK grins [10:57] almost finished uni - got about 8 months left [10:59] been abusing my poor ubuntu boxen here [10:59] how have you been StevenK ? [11:01] Yagisan: I've been great! [11:02] my package is complete and requires a revu - http://revu.tauware.de/details.py?package=libserial [11:02] no more jumping on Hobbsee StevenK ? [11:04] Could someone else look at libserial? I've been the last two commenters, and think the package would benefit from another viewpoint. [11:12] Yagisan: She's not here to jump on. [11:13] Yagisan: But, no. [11:13] Yagisan: Check out my Launchpad page and see if you can guess my new employer. [11:16] StevenK, hmm - I wonder [11:16] * StevenK grins [11:18] :'( I understand now why no one updates llvm - I hope I understand these gcc build instructions right [11:21] StevenK> Canonical? [11:24] StevenK, you still down Burwood way ? [11:24] LucidFox: Yup [11:24] Yagisan: Nope. I worked in Burwood, now I work at home. [11:24] StevenK, I'm stuck out in Merrylands [11:25] I'd like one more reviewer for http://revu.ubuntuwire.com/details.py?package=smplayer-themes [11:26] StevenK, I'll take a moment to pimp my ubuntu powered www site -> http://dengng.bpa.nu/wiki [11:26] * Yagisan -> washing bub [11:29] * persia grumbles about REVU day participation, and reviews libserial yet again [11:30] Yagisan: Merrylands is fairly closeish to me [11:30] Hello [11:31] I have a question about a coment about my package [11:31] josesanch: Just ask [11:31] The reviewer says Please don't use an absolute path for the executable in the menu file [11:31] but i don't know how to to that. [11:31] all menu files that i have seen uses absolute path [11:31] persia: thanks for the reminder about that. I've pushed out 0.7 and uploaded to revu again, but as discussed someone else should review it :) [11:32] josesanch: In your menu file, you reference /usr/bin/something. Change that to "something". [11:32] in the manual i don't see anything [11:32] Ng: You'll want to advertise the URL :) [11:32] will work in that way? [11:32] persia: will do once I see the new upload, thanks :) [11:33] josesanch: As long as the executable is in the default path, yes. Further the executable should be in the default path, and there should be no name conflicts for executables in the default path. [11:33] persia: Ahh.. thanks.. [11:34] persia: I have another question is the last thing that i have to address "1) python-support might want to be Build-Depends-Indep:" [11:35] josesanch: I'm not the right person to ask about that, as I'm not an expert in python packaging. Generally, only the packages required to run debian/rules clean belong in Build-Depends: if there are no architecture-specific binary packages built, and python-support in Build-Depends: generated some automated output from one of linda or lintian (probably lintian: linda tends to be less wordy). [11:41] DaveMorris: typo in debian/copyright. Refresh the upload to fix that, and I'll advocate libserial. [11:41] (if it's fairly quick: I'm stopping reviewing soon) [11:42] ok here we go... I have a fresh upload of Terminator in REVU that should resolve all previous comments. Reviewers who aren't persia (because he's given me enough of his time already) would be most welcome: http://revu.tauware.de/details.py?upid=1242 :) [11:42] Ng: Is that because persia threatened to bill you? :-P [11:43] LucidFox: How much does wxsvg differ from DMO? Is there a reason to push this through REVU rather than a merge? [11:43] StevenK: haha, no. fresh eyes and all that :) [11:43] StevenK: I was the last three reviewers, which I try to keep as a limit [11:44] http://revu.ubuntuwire.com/details.py?package=gpp4 is ready for another round of reviewing as well [11:46] persia> It's not in Ubuntu yet [11:47] I assumed that all new packages went to REVU, unless they were synced/merged from Debian [11:48] LucidFox: Let me ask that differently then. Firstly, do you plan to maintain this, or just keep merging from DMO? Secondly, are you pushing to REVU to get a second opinion on your changes, or just because that's how we handle new packages? Thirdly, do we really need such an ugly version string? [11:48] LucidFox: We can have other sync/merge sources, as long as those sources are well maintained, and someone watches them. We just only automatically sync from Debian. [11:50] 1. Keep merging, and advocate serious changes to DMO. 2. Just because that's how new packages are handled. 3. I don't know, but it has been the de facto practice for packages from DMO, even long before I started contributing [11:50] StevenK, how closeish ? [11:52] * Hobbsee glances at the MOTU ML, and sighs. === asac_ is now known as asac [11:55] LucidFox: I think it's a merge, but will put it through a review if you want. On the other hand, I didn't find much in the last couple of your packages I checked, so I'm presuming you've already checked most of it./ [11:55] s/\/$//g [11:56] I'll change the bug to a merge request, then. [11:57] LucidFox: OK. I'll archive the REVU entry. [12:00] persia: I've uploaded it, just waiting for the refresh [12:02] DaveMorris: OK. I encourage you to hunt someone else for opensg, as it's not yet been so long that I think it wouldn't benefit from another reviewer. [12:03] sure, it seems best if different people review them etc. [12:12] DaveMorris: libserial is now back between jaaa and qdevelop in queue, as it was earlier :) [12:13] josesanch: Please collapse your changelog. You might look at some of the packages that were advocated for examples. [12:17] Ng: Not a proper review, but the REVU server has some meaningful output from the automated lintian and linda runs that it would be worth addressing. [12:19] persia: k [12:20] persia: yes, i did [12:20] it's about 100 lines now [12:20] josesanch: I was looking for about 10 [12:20] josesanch: I was looking for about 10 [12:21] 10 lines? [12:21] ok [12:22] josesanch: Most packages go in with a 5-line changelog. Sometimes you need a couple extra for notes like a repack or significant patching. None of the revisions that aren't going into the repositories are interesting. Also, none of the packaging arrangements other than repacks or big patches are interesting for the initial release, as users are encountering this for the first time. For any updates after the first release, entries like in your [12:24] persia: ok.. i'll put a changelog with initial upload to motu. it isn't? [12:25] josesanch: Compare http://revu.ubuntuwire.com/revu1-incoming/gnomecatalog-0801141310/gnomecatalog-0.3.3/debian/changelog and http://revu.ubuntuwire.com/revu1-incoming/terminator-0801141240/terminator-0.7/debian/changelog [12:25] persia: I have got it :) [12:25] You don't need to track changes in REVU with changelog. These are just a way for you to get the package in good shape to start. Once it goes in the repositories, then you want to track all the changes. [12:27] persia: i have to put the launchpad bug? like terminator [12:27] josesanch: Yes. [12:28] Actually, even terminator is wordy. http://revu.ubuntuwire.com/revu1-incoming/smplayer-themes-0801101520/smplayer-themes-0.1.14+svn618/debian/changelog is the standard format. [12:29] persia: I will use smplayer format [12:29] josesanch: Thanks [12:29] persia, Ng: empty /usr/lib/ is a python-central bug. I'd just ignore it, as it's not a policy violation. Debian bug #452227 [12:30] Debian bug 452227 in python-central "Leaves empty /usr/lib in package" [Normal,Open] http://bugs.debian.org/452227 [12:30] pochu: ok [12:31] pochu: Thanks for digging that up. I still think shipping empty directories by accident is bad, but now I know where to blame [12:32] persia: it could be probably workarounded in binary-install, but I think waiting for a fix in pycentral is fine. [12:32] pochu: I'd agree with that. I thought it was a distutils issue. [12:33] persia: what user and passwd should I use to login in REVU? I'd like to make my first comments :) [12:33] nevermind, found it [12:33] pochu: Have you never used REVU? [12:33] pochu: OK. Let me know if you have issues, and I'll bump your access permissions. [12:35] persia: I think I once uploaded a package, but I'm not sure and if I did it was before the other server was compromised. [12:37] persia: No REVU account for pochu@ubuntu.com exists yet. [12:37] persia: I can't find how to create a new one... [12:37] uhm [12:37] try to ping siretart [12:38] ping siretart :) [12:38] pochu: Sorry. Momentarily distracted. I'll set you up. [12:38] :) [12:38] Alright, I didn't know you could :) [12:38] pochu: use the email adress you used the last time you uploaded a package to revu [12:38] siretart: unping [12:38] pochu, haahahaha [12:38] siretart: that was a long time ago, and it was probably removed when the database was restarted [12:38] siretart: Will that work even for people who last used REVU prior to the compromise? [12:39] Didn't work. [12:39] (I used either @ubuntu or @gmail and none of them work) [12:40] fwiw, after I uploaded first I didn't get an email, so I did the password recovery thing and decrypted it fine [12:40] Ng: That's normal. pochu is different as he seeks reviewer access without an upload. [12:41] persia: oh [12:41] well ignore me then ;) [12:42] * siretart at work, sorry [12:43] pochu: no, the database was reset [12:44] * persia stops adding a user, and starts looking at other options. [12:46] pochu: No REVU account for any of the addresses on your key. Creating one for pochu@ubuntu [12:47] +.com === ember_ is now known as ember [12:55] is the revu server sending out emails for you guys, since I'm not getting any more now [12:58] DaveMorris: http://lists.tauware.de/pipermail/motu-reviewers/2008-January/019458.html shows my last REVU comment. Are you subscribed to that list? [12:59] yeah I was, but the last mail I got was on Fri [12:59] DaveMorris: Odd. I'm not sure why the archives would be updating, and not your inbox. [13:00] yeah, my mail server gets other mail fine. [13:00] I'll have to look into it after work [13:01] Hello, could somebody please review my package: http://revu.tauware.de/details.py?package=speed-game ? [13:03] Oh hey, whattaya know :) [13:03] ok, im blank today, someone please give me the address or the new queue? [13:04] jussi01: https://edge.launchpad.net/ubuntu/hardy/+queue?batch=500 [13:05] persia: I dont understand where MAINPACKAGE can be defined , since there is nt any file included in jaaa/debian/rules [13:06] thanks Hobbsee [13:06] you're welcome [13:06] rzr: I thought it came from the environment, but I may well be mistaken. Sorry for the confusion. [13:07] then let's user define it [13:07] rzr: Works for me. [13:07] erm, let the user to define it .. [13:08] maybe the to can me omited too :) [13:08] any native english speakers around to correct me ? [13:09] * Hobbsee ponders reviewing. [13:09] rzr: dpkg-parsechangelog | sed -n 's/Source: \(.*\)/\1/p' will also generate the source package name, if you like. [13:10] neat [13:10] rzr: s/to// [13:10] Hobbsee: thx [13:16] * persia liked "let's user define it", indicating cooperatively using the "user define" function in make to set the value [13:18] in other words (let 'value (getdef (user))) [13:18] or so [13:20] rzr: Well, "let" is usually a synonym for "allow", whereas "Let's" is an abbreviation for "Let us", and if my memory is correct is short for something like "If the fates allow us, we shall ..." [13:21] let it be [13:22] heh [13:22] Would anyone familiar with python be willing to provide shibata some direction with some guidance for http://revu.ubuntuwire.com/details.py?package=termlauncher-applet [13:23] s/with some/or/ [13:25] I'll have a look [13:25] pochu: Thanks. [13:34] ubotu, bug 173507 > mok0 [13:34] Launchpad bug 173507 in ubuntu "[needs-packaging] torque" [Wishlist,In progress] https://launchpad.net/bugs/173507 [13:37] mok0: try /msg ubotu bug #173507. Less keystrokes too :) [13:37] Launchpad bug 173507 in ubuntu "[needs-packaging] torque" [Wishlist,In progress] https://launchpad.net/bugs/173507 [13:37] ubotu: Didn't someone make you a gag to not show the same bug twice in 5 minutes in the same channel? [13:40] persia: heh [13:41] First someone should take a look at IRC RFCs and make ubotu send all automatic messages as NOTICEs instead of PRIVMSGs. :-) [13:42] persia: working on torque ATM. It would be great if it could make it into hardy. Also considering the fact that Mark seems to be interested in "specialist deployments, for example high-performance computing clusters, or vertical market solutions " [13:43] Got worried seeing that there are only two weeks left [13:45] pochu: thanks for your comments - I tried setting DEB_INSTALL_CHANGELOGS_ALL previously and it didn't seem to do anything - is the syntax "DEB_INSTALL_CHANGELOGS_ALL = ChangeLog"? [13:45] Ng: := ChangeLog [13:46] Ng: yes (or whatever upstreams changelog is called [13:46] * Ng tries again, but I'm pretty sure I tried that too [13:46] Ng: ideally you don't need it. ChangeLog is so common that CDBS/debhelper will look for it and include it if found. Works here on a sid pbuilder, but doens't on a hardy one. I'm investigating it. [13:46] Ng: https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml [13:46] pochu: yeah it worked in gutsy too. that bit got added from earlier comments saying it was missing [13:47] yeah, it's not there with "DEB_INSTALL_CHANGELOGS_ALL := ChangeLog" [13:48] That worked for me. [13:48] Ng: put that *after* including debhelper.mk [13:48] (i.e. at the end of the file) [13:48] oh :) [13:49] yay [13:52] pochu: what do you mean about not needing pycompat? I suspect that is something being included by pycentral or debhelper or something, because I don't have it in my tree [13:53] Ng: iirc pycompat was used by dh_python which is obsolete now [13:54] CDBS probably still calls it [13:54] pochu: It's an intentional Ubuntu patch to CDBS to drop the changelogs. As far as I understand, it's a special case for gimp, but applies to more packages for extra informative inclusion. [13:56] persia: with regards to your comment "If upstream is truly dead, and you can provide evidence that upstream agreed to ISC in debian/copyright, that too is likely acceptable (given the terms in speed.txt)." [13:56] persia: what would be acceptable as evidence in this case? [13:56] ... [13:56] this is the email exchange I had with him: http://paste.ubuntu-nl.org/51888/ [13:56] amarillion: In the two cases I've seen it, email was quoted in debian/changelog. [13:56] Ng: it's generated in debian/rules clean. You can avoid it being including by generating the source package with "dpkg-source -b foo-1.0/", or "dpkg-buildpackage -S -sa" (or similars) [13:57] Err.. debian/copyright. Sorry for the confusion. [13:57] ok, I'll include the email text. [13:57] persia: then why should we include the changelog, if it's intented to remove it? :) [13:57] pochu: mine are generated by bzr-buildpacakge, but with source-builder set to 'dpkg-buildpackage -rfakeroot -S -sa' [13:58] pochu: Because it's useful. The changelog removal only has a point to save space on the CDs. For all of universe it just generates bugs. [13:58] persia: right, this isn't in the CD. But bugs? [13:59] Ng: btw if you are using hardy you don't need to pass -rfakeroot, it's now the default if you have fakeroot installed [13:59] aha [14:00] pochu: 1) Not having changelogs makes it harder for triagers to determine when something was fixed, so fewer bugs get closed, 2) not having changelogs means users only see "New Upstream Release (closes: #332748)" in the changelog, are confused by differing behaviour, and file a bug (nothing they can check) [14:01] persia: so the solution is to put the NEWS entry in debian/changelog? ;-) [14:01] * pochu hides [14:01] * persia strings pochu up by his smallest left toe over a pit of eels [14:01] (note that the Desktop Team does that, so half joke half serious) [14:02] * pochu googles for eels [14:02] Ouch [14:02] Hehe [14:02] Heya StevenK [14:03] "All I want is a tank full of sharks with friggin' lasers on their heads!" [14:06] persia: btw I can't find that change in debhelper or cdbs' changelogs. [14:06] pochu: cdbs (0.4.49ubuntu3) [14:08] persia: thanks. I was looking at 0.4.50ubuntu1 which should have mentioned that change. [14:08] lunch :) [14:08] pochu: Yep. Complain to the uploader if you like... [14:09] pochu: Uhm, sounds good... wait... I already _had_ lunch... [14:10] * persia notes that there are only 7 packages left on REVU that have yet to get a review today, and hopes they can all be reviewed during the (local) night [14:11] pochu: apart from the pycompat thing, I've fixed all the other comments :) [14:11] * mok0 notes that there's gonna be 9 in about 10 minutes === _czessi is now known as Czessi [14:31] http://revu.tauware.de/details.py?package=sdlmame updated and ready for reviews! :) === cprov is now known as cprov-lunch [14:41] Hi all [14:47] Hi, persia commented on my upload earlier today: http://revu.tauware.de/details.py?package=gtkvd and I'm trying to fix the issues. However, some questions. About point 1 concerning the upstream changelog, how does this word? Should I just remove the previous entries from the debian/changelog file? [14:47] s/word/work [14:48] Ng: would be nice if the --fullscreen option worked with F11, as gnome-terminal does. Wanna a wishlist in Launchpad? :) [14:49] rulus> It basically means, move everything to a ChangeLog file for upstream changes, and leave only one entry in debian/changelog saying that it's the initial release [14:49] rulus> You're the upstream developer, I take it? [14:49] yes, I'm the upstream developer [14:49] pochu: please :) [14:50] LucidFox: thanks, I understand [14:57] Another question: I added a watch file that checks the +download/ folder from the Launchpad project page (which works as it should btw). This does mean that I should register every release at the project page and upload a .tar.gz for it, right? Also the x.x.x-0ubuntuX ones? [14:57] rulus> yes [14:58] you should have a tar.gz for each upstream release [14:58] not for each Ubuntu release [14:58] because, for example, 0.1-0ubuntu1 and 0.1-0ubuntu2 will have the same orig.tar.gz [14:58] ok, understood, thanks! [15:06] persia: there we go, i've done my work for the day :) [15:06] * Hobbsee dealt with ~6 packages. [15:07] am i exempt from revu day now? :) [15:09] Ng: bug 182863. And I'm advocating it (my first advocate) :) [15:09] Launchpad bug 182863 in terminator "F11 should full-screen terminator" [Undecided,New] https://launchpad.net/bugs/182863 [15:11] What's the best place to make suggestions about REVU? (and were is the code, so I could see if I can make a patch for said suggestions?) [15:11] pochu: sweet :) [15:11] https://bugs.launchpad.net/ubuntu/+source/libflickrnet/+bug/182130 <-- Holy crap!!! [15:11] Launchpad bug 182130 in libflickrnet "package libflickrnet2.1.5-cil 25277-5 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Undecided,In progress] [15:11] pochu: thanks muchly [15:12] "This bug has 31 duplicates " [15:12] LucidFox: yeah I hit that this morning and fudged round it with a symlink on the basis that it was so obvious it would have bee nreported a lot already. I guess I was right ;) [15:12] And now 32 duplicates, since I marked one more bug as a duplicate :) [15:13] Ng: if you don't intend to upload this to Debian I could take care of it. But I encourage to maintain it yourself there :) [15:13] Hi! where can I ask questions related to KDE4 integration? [15:14] pochu: I have to admit to being selfish and lazy and not terribly interested in Debian anymore. I don't even have a debian install anymore to test it on ;/ [15:14] but that's not the right spirit, so I'm happy to help out :) [15:15] zoli2k: #kubuntu-devel [15:15] ScottK: Can you tell me what to do next? - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460449 [15:15] Debian bug 460449 in kdissert "kdissert: Please use dh_icons to update icon cache" [Normal,Open] [15:15] Hobbsee: thanks [15:16] Ng: to be honest I only have Debian on a VM and rarely test my packages :P [15:16] Well I test them in Ubuntu [15:17] and in a sid pbuilder, but not in a Debian installation [15:17] Ng: if you want I can co-maintain it with you. [15:17] pochu: that sounds worth trying :) [15:18] We can maintain it in the Python Applications Packaging Team :) do you have an alioth account? === keffie_jayx is now known as effie_jayx === cprov-lunch is now known as cprov [15:24] Heya gang === josesanch_ is now known as josesanch [15:24] Ng: ^ saw that? [15:24] hey bddebian [15:24] Hi pochu [15:25] bddebian: how are you doing? :) [15:25] OK I guess, thanks. You? [15:25] pochu: sorry missed that. No, I don't have an alioth account. I got one tiny package sponsored into Debian one time and then warty came out and I stopped using debian for most things ;) [15:26] so... [15:26] what's up with falcon? [15:26] Amaranth: did you read the ML? [15:26] yeah [15:26] MLs rather [15:27] and i noticed it went to ubuntu-devel now too [15:27] ant to -archive by dholbach [15:27] where it should probably have gone in the first place and much earlier [15:27] Ng: if you create one we can maintain it in alioth SVN :) [15:27] dholbach: agreed. [15:27] with soren's proposal we should all be fine [15:28] dholbach: but soren's proposal is about the binary, not about the packages. And we still need to hear what Seveas and imbrandon think about it. [15:28] pochu: is there any specific advantage to doing it there instead of in launchpad? (hatred from debian people aside ;) [15:28] pochu: right... but in a different part of the thread renamind the binary packages and source packages to falconpl was already considered [15:29] * dholbach needs to leave now, so see you all tomorrow! [15:30] dholbach: I'm a bit lost. So are you thinking on moving falcon the language to falconpl for the source package but using /usr/bin/falcon, and falcon the repo using falcon for the source package and /usr/bin/falcon-whatever ? [15:30] dholbach: later [15:31] pochu: I think that makes sense, given the point (interpreted scripts) that soren raised [15:31] that sounds perfect [15:31] dholbach: I agree with the binary name. Dunno about the packages name :) [15:31] the 'original' falcon gets the package name, the language gets the binary [15:32] Well it would be a bit confusing if there's a falcon source package but the falcon binary is in a different package, but not an important thing I guess [15:32] Amaranth: 'original' as in what? [15:32] pochu: as in here first :) [15:33] Amaranth: well if here means the archive then it was first, yes. But if it means needs-packaging and the like then it wasn't ;) [15:35] hmm, when my .tar.gz contains another .tar.gz, there's something not right I guess? check http://revu.tauware.de/details.py?package=gtkvd [15:35] got no comments about it, but doens't seem very logical to me [15:36] rulus> Indeed, not logical [15:37] Why is there another tar.gz inside? [15:37] probably because my packaging is wrong, I'll go through the packaging guide again [15:39] rulus> You should make an upstream release prior to packaging [15:40] could anyone please check http://revu.tauware.de/details.py?package=sdlmame [15:40] LucidFox: an upstream release is just all the files in a .tar.gz? [15:41] yes, except for the debian directory, because it's part of the packaging [15:42] then you'll use that tar.gz as gtkvd_0.4.2.orig.tar.gz [15:42] rulus: ideally upstream should release a tar.gz, is not the case in the package you are trying to create? [15:42] aha, that's why I missed the .orig too [15:42] slytherin: I'm upstream [15:43] rulus: :-) [15:44] geser: I am currently trying building batik with sun java. Please tell me, if it works should I first get the debian package and then change it to use sun-jdk (debian has 1.6-4, ubuntu has 1.6-3) [15:45] slytherin: you should use sun-java6-jdk [15:45] or java5, i guess [15:47] Amaranth: yes, I am trying that. The question is not related to which java should I use because I have already found the answer. But the question is whether to submit debdiff against current ubuntu package or get debian package and then submit debdiff. [15:48] Debian. [15:49] The current Ubuntu package was synced from Debian anyway, so it makes sense to use the latest Debian version when submitting your changes. [15:50] LucidFox: Ok, then how should bug filing go? a sync bug with debdiff against debian package attached? [15:51] yes [15:51] (Disclaimer: I'm not a MOTU) [15:52] LucidFox: I would rather then wait for geser's answer with whom I have been communicating for a while regarding the FTBFS [15:56] slytherin: I would suggest submitting the change for inclusion in Debian but if you can get it into Ubuntu sooner that's good too [15:56] Because we can always just do a clean sync later when Debian catches up [15:58] Amaranth: For Debian it may not be justified as arch all packages are not build on buildd. Where as in Ubuntu we need Sun JDK because we can only preseed debconf for Sun JDK license question. [15:59] By the way, does it make sense to request a sync if it merely merges all existing Ubuntu changes? [16:01] slytherin: when you have done it please show me your patch against batik, I hate to see differences between Debian und Ubuntu Java packages when not needed [16:02] man-di: Sure, provided it builds. :-) [16:05] Apparently, the Utnubu team is dead :/ [16:18] slytherin: debdiff against the latest debian package is ok (if you want you can also provide a debdiff from the current Ubuntu package to the new one) === \sh_away is now known as \sh [16:25] <\sh> moins [16:26] Hi \sh [16:26] <\sh> geser, you scared me just now...shermans-aquarium ;) [16:30] man-di: What do you say about this? This is when trying to build Debian batik package in Ubuntu pbuilder, http://paste.ubuntu-nl.org/51899/ [16:30] slytherin: sun-java5 or sun-java6? [16:31] slytherin: the package has only a check for the JAVA_HOME of sun-java6 [16:31] geser: No sun java. No changes, Only thing I needed to do was install the specified jdk inside pnuilder to avoid the license question problem. [16:32] geser: So the package specifies something else in control files and check for something else in rules [16:33] slytherin: please show me "grep Build-Depends < debian/control". I cant look otherwise from here [16:33] man-di: Build-Depends: debhelper (>= 4.2.30), cdbs [16:33] Build-Depends-Indep: sun-j2sdk1.4 | java2-compiler, ant, libbsf-java, libxalan2-java, rhino, libavalon-framework-java (>= 4.2.0-1), libcommons-io-java, libcommons-logging-java [16:34] are there any MOTU heroes currently awake who'd like to look at http://revu.tauware.de/details.py?upid=1252 and advocate? (aiui I need 3 advocates for a NEW package) [16:35] Ng: 2. [16:35] ooh, then I'm 50% there \o/ [16:35] slytherin: thats the problem CDBS expects sun-j2sdk1.4 and ant to be installed during clean target execution [16:36] man-di: that's not the only problem, JAVA_HOME_DIRS doesn't have any directory corresponding to sun-j2sdk1.4 [16:37] slytherin: which dirs does it contain? [16:37] man-di: /usr/lib/j2sdk1.4-sun /usr/lib/j2sdk1.4-ibm /usr/lib/j2sdk1.4-blackdown /usr/local/IBMJava2-ppc-142 /usr/lib/jvm/java-6-sun/ [16:37] the build-depends is strange anyway, it should never use javaX-compiler [16:37] sun-j2sdk1.4 is *definitely* /usr/lib/j2sdk1.4-sun [16:38] sun-j2sdk1.4 is the 1.4 package created with java-package/make-jpkg [16:39] man-di: the home is not correct on Ubuntu system. Let me check for Debian [16:40] what is the preferred version number mangling to repack an orig.tar.gz that needs two binaries removed? [16:40] slytherin: I dont think Ubuntu patched that in java-package [16:40] .repack, +repack? [16:41] jdong: I guess .repack [16:41] Ubuntu dont patched java-package at all [16:42] man-di: hmm, so I guess I need to start from there [16:43] if I remember correctly (I dont worked on that myself) the problem was that packaged JDKs were not able to build batik because the XML stuff in the JDK was too new and incompatible (like interfaces needed new methods which are not implemented in batik) [16:44] jdong: many people add +dfsg{$number} to the version [16:44] man-di: That might be another problem. So it will not build with sun jdk anyway [16:45] not with JDK 5 or 6 [16:45] man-di: right, my mistake [16:45] slytherin: sounds like a showstopper for batik in Ubuntu :-( [16:46] geser: batik will not build with sun jdk 5 or 6. is there no way to adjust debconf for j2sdk package? [16:46] man-di: unless someone packages 1.7 version [16:46] siretart: I thought about that, but I didn't think it's appropriate because mpeg4ip is too restrictive to be called "dfsg" anyway, right? [16:46] slytherin: that is in the works [16:47] slytherin: Vincent (if I remember his name correctly) is working on that [16:47] slytherin> What about icedtea? (You probably tried that first, though) [16:47] jdong: I don't know enough about mpeg4ip enough to comment that. [16:47] man-di: I guess it also requires an additional package. Not sure if it is in Debian yet [16:47] LucidFox: icedtea is too new too [16:47] LucidFox: won't do. [16:47] slytherin: perhaps best to contant Vincent yourself and work together with him [16:48] man-di: will do tomorrow. [16:49] jdong> Well, mpeg4ip is free software, just patent-encumbered [16:49] (which only applies in the US anyway) [16:49] So I think it makes sense to use "dfsg" === lakin_ is now known as lakin [16:51] LucidFox: ok very well then I'll use dfsg. You sure Debian people with pitchforks won't come burn down my house? :D [16:51] lol [16:51] !jdong [16:51] jdong: yes, but you're FULL OF CRACK! [16:51] Hobbsee> o_O [16:51] and can .jpg files be licensed under the MPL either? [16:51] I'm guessing it's a no? [16:51] but isn't mpeg4ip currently in NEW? [16:52] LucidFox: rejected again [16:52] LucidFox: there's a few random binaries in there and other ill-licensed things [16:52] I see it in NEW... [16:52] LucidFox: shouldn't be... was rejected two days ago [16:52] https://launchpad.net/ubuntu/hardy/+queue?start=20 [16:52] unless I was uploading in my sleep... [16:52] uploaded yesterday [16:53] GRUMBLE who uploaded that? [16:53] "Changed-By: Mario Limonciello " [16:53] ah [16:53] * superm1 awakens [16:54] superm1: hey I've got mpeg4ip under control, there's licensing issues in the source tarball and debianization too [16:54] superm1: been rejected twice by archive admins already [16:54] jdong, this i was not aware of [16:54] 0.2 is just a rebuild of 0.1 anyway [16:54] superm1: haha nor was I until last week :D [16:54] superm1: but yeah, it's a real work of art. debian/copyright says GPL while the COPYING file lists like 15 different licenses :) [16:55] lol [16:55] jdong, yeah did you look at my modified debian/copyright? [16:55] superm1: no, what'd you change it to? [16:55] i listed every license I could (more verbosely than COPYING did) [16:55] superm1: grumble stop duplicating work! :D [16:55] there were a few in COPYING that were not referenced previously [16:56] jdong, well i suppose I should have looked for needs-packaging bugs that may have already been opened...., was there one? [16:56] superm1: no I don't think there were any bug reports open [16:56] superm1: I don't think there's any way you could've predicted this :) [16:56] er i mean, "i didn't see any needs packaging bugs opened, so i took initiative" :P [16:56] superm1: you want to finish it up then? :) [16:56] slytherin: looks like the j2jdk1.4 debconf question can be preseed too [16:57] well what more is there too it? [16:57] it appeared to me that mpeg4ip had to be uploaded, faac rebuilt against it [16:57] geser: Good, That will help. :-) [16:57] faad rebuilt against that [16:57] and then $other_things rebuilt against all 3 [16:57] superm1: remove lib/rtp/test-libcommon (ELF binary), remove doc/*.pdf,*.jpg because they cannot be licensed under the MPL [16:58] yes, and now there are a whole lot of new packages blocked by the libmp4v2 transition [16:58] superm1: once that's done the rest look good [16:58] superm1: and we can proceed with all the fun of rebuilding [16:58] images can't be licensed by MPL? [16:58] superm1: can they? [16:58] gtkpod-aac, avidemux, and the x264 transition is also stalled as a side effect... [16:58] superm1: IANAL... if they can then never mind, just the pdf [16:58] jdong, well did archive admins tell you this last time around? [16:58] jdong, or what ended up happening? [16:59] superm1: I was specifically told that the pdf needs to be nixed, as well as the ELF binary [16:59] LucidFox, and mytharchive (and consequently the planned mythbuntu alpha) [16:59] slytherin: the hard part is to get it done in the buildd chroots. Try to get a hold of infinity and convince him to do this. [16:59] superm1: I wasn't told about the picture but I don't think pictures count as source code? [16:59] jdong, well doesn't hurt to nix the images i suppose [16:59] superm1: yeah nothing uses it [17:00] now what do you say about versions though of it 0.2, 0.1? the version on it is 1.6-0.2? [17:00] (from debian-multimedia) [17:00] is that what you're meaning [17:00] superm1: yeah that's fine, but you're gonna have to repack the orig.tar.gz [17:00] superm1: so probably 1.6.dfsg-0.2ubuntu1? [17:00] bah :) [17:00] geser: or perhaps wait a week more and see if batik 1.7 lands in debian. It will build against sun java 5. :-) [17:00] superm1: fun fun fun :) [17:01] jdong, when you did it though.. [17:01] jdong, did you run into issues with the circular dependency [17:01] of faad and faac on mpeg4ip [17:01] superm1: yes, you have to undepend on at least faac [17:01] jdong, well here's the thing [17:01] superm1: faad was still installable the last time [17:01] jdong, the README.html tells you not to build with either [17:01] jdong, so i'm not sure why Christian was in the first place [17:02] Did you try contacting him about that? [17:02] He's very responsive [17:02] superm1: I believe mp4live likes having faac support [17:02] LucidFox, i might have. i sent a lot of emails out this weekend. lets see [17:03] jdong, well the readme at least claims that build problems tend to crop up [17:03] but for now, it will have to be built without it either way [17:03] superm1: well we need to build without it right now anyway [17:03] superm1: we can re-enable their builds aftewards. I personally don't care either way [17:03] superm1: as we're mostly after libmp4v2, not the other crap it comes with [17:03] yeah exactly [17:04] well i'm hoping the licensing is good enough at this point [17:04] you want to take a gander at my debian/copyright in NEW right now [17:04] superm1: let's aim to unbreak the entire MPEG4 stack at this stage, jsut repack the orig and call it a day [17:04] and give it a second look over? [17:04] superm1: I'll download your copy and give it a look [17:04] jdong, hehe :) [17:05] LucidFox, yeah i apparently did send Christian an email at some point this weekend (glad i'm not crazy) [17:05] slytherin: ok, let's wait an other week before I try pinging infinity about the debconf preseeding [17:06] superm1: hmm they're a bit different, let me pastebin mine then let's decide which one to use [17:07] superm1: http://paste.ubuntu.com/3559/ [17:08] persia: can I request the sync for brutalchess? [17:09] jdong> When you're done with mpeg4ip, could you please look at bug #172839 as part of your backports work? [17:09] Launchpad bug 172839 in gutsy-backports "Please backport libqca2 2.0.0-3 from hardy to gutsy" [Undecided,New] https://launchpad.net/bugs/172839 [17:09] jdong, i think i like yours better [17:09] superm1: :) well at least my time wasn't completely wasted last thursday :D haha [17:10] jdong, i'll throw your name in the debian/changelog [17:11] jdong, and call it a day after the repack [17:11] LucidFox: the backport request sounds reasonable to me, I would feel better if afterwards we tell Rid-dell or someone to rebuild the affected KDE packages anyway [17:11] superm1: sounds good, let's hope this is the last round :) [17:11] warp10: have you seen bug #182454? [17:11] Launchpad bug 182454 in brutalchess "Please sync brutalchess 0.5+dfsg-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/182454 [17:12] I should really have advocated it earlier, before the KDE packages were uploaded :/ [17:12] jdong, in case it gets shot down some time this week, feel free to fix any quick things and upload it again your name (i am going to be moving this week and w/o internet access for several days) [17:12] LucidFox: see bug 182605 [17:12] Launchpad bug 182605 in gutsy-backports "Please backport qca2 (2.0.0-3) from Hardy" [Undecided,In progress] https://launchpad.net/bugs/182605 [17:12] superm1: ah, ok, I'll keep an eye on it for you then :) [17:12] Ah, so it's a duplicate then [17:12] geser: ops! I missed it. Ok, never mind. Thank you :) [17:12] LucidFox: yeah, jpatrick filed it later than you though ;-) [17:13] I'll mark mine as a duplicate because it has less activity [17:13] 12:12 -jpatrick(n=patrick@ubuntu/member/jpatrick)- I'm sorry, but I'm away (sleep) [17:13] thanks for the information :) [17:13] boy that's creepy [17:13] LucidFox: yeah since the other one has been approved already [17:14] wait does sudo in Hardy strip environment variables now? [17:15] like SUDO_UID and SUDO_GID? [17:15] or other stuff [17:15] superm1: even other arbitrary variables [17:15] LucidFox: yeah since the other one has been approved already[jdong@blackbook:devel/mpeg4ip-1.6]$ export FOO=bar (01-14 12:15) [17:15] [jdong@blackbook:devel/mpeg4ip-1.6]$ sudo sh -c 'echo $FOO' (01-14 12:15) [17:15] [sudo] password for jdong: [17:15] yeah seems like it strips everything [17:15] well that's crazy. [17:16] odd enough [17:19] when dpkg-buildpackage says me 'source version is 0.4.2-0ubuntu1' then I'm doing something wrong? Shouldn't it tell me the source version is '0.4.2'? [17:20] rulus> Could you paste the entire output of dpkg-buildpackage on http://paste.ubuntu.com/ ? [17:20] I can, one sec [17:20] A native package, perhaps. [17:21] Or maybe nothing is wrong. [17:21] * jdong works on fixing prevu's lp scrapers [17:21] Well, he uploaded a native package to REVU before [17:22] http://paste.ubuntu.com/3560/ [17:22] I just can't remember what dpkg-buildpackage is supposed to say for a non-native package. :-) [17:23] well, nothing is wrong I think [17:23] actually, not "I think" - nothing is wrong [17:23] dpkg-source: building gtkvd using existing gtkvd_0.4.2.orig.tar.gz [17:23] nice [17:24] For convenience, in the future you can call "debuild -S -sa", which will call "dpkg-buildpackage -S -sa -rfakeroot" [17:24] I did call dpkg-buildpackage -S -sa -rfakeroot [17:26] yes, but typing debuild is shorter :) [17:26] I use a shell script, but thanks anyway ;) [17:26] heh [17:33] rulus> I don't see the updated gtkvd on REVU yet... [17:36] I'm trying to make both source and binary package.. Does this require calling dpkg-buildpackage twice? [17:38] how often should I be pestering about something in revu? I don't want to annoy anyone, we're just excited about the prospect of getting into the archive :) [17:38] rulus> Well, REVU only accepts source packages [17:39] LucidFox: I know, but I'd like to test my package locally first [17:39] then it's better to build binary packages from the source package in pbuilder [17:40] ah, I'll check that out, thanks [17:40] this way, you can check for missing build dependencies [17:41] grumble debmail, debemail, same thing.... :) [17:42] there's nothing more fun in the world than setting up a new development box [18:06] hmm, my package apparently install's an empty /usr/lib folder but I have no clue where it comes from.. It's not in debian/dirs nor in setup.py.. [18:07] rulus> can't you just rmdir it? [18:07] alright, time to go install another Ubuntu box [18:07] bbl everyone :) [18:08] LucidFox: how do you mean? [18:08] LucidFox: sorry about the dup, LP didn't show it [18:08] rulus: It's a bug in python-central/python-support. [18:09] ScottK: so I shouldn't care? [18:09] jpatrick> No problem :) [18:09] * ScottK wouldn't care, but I'm not sponsoring your upload. [18:10] *can* I fix it? [18:10] If that bug ever gets fixed, you'd have to remove whatever fix you came with and in the meantime your package would be broken. [18:10] It doesn't actually cause any harm. [18:11] well, in that case I don't care [18:11] ScottK> So I was right that the immediatist vs. eventualist division exists not only in wiki communities :) [18:12] * rulus updated his package at http://revu.tauware.de/details.py?package=gtkvd [18:12] Right. [18:14] LucidFox: In this case it's a issue of prettifying the package now versus maybe a broken package later. If you rmdir that dir and then the dir doesn't exist due to the bug being fixed, the package will FTBFS. [18:14] rulus> hasn't uploaded yet [18:14] probably will in 6 minutes [18:14] well it's uploaded, but had not appeared yet [18:15] s/had/has [18:22] rulus> Since it's not actually a "new" upstream release, debian/changelog should probably read "initial release" [18:22] and Ubuntu uses "LP: #XXX" instead of "Closes: #XXX" [18:23] Here's an example of the first debian/changelog entry, used by persia: http://revu.ubuntuwire.com/revu1-incoming/smplayer-themes-0801101520/smplayer-themes-0.1.14+svn618/debian/changelog [18:24] ok, thanks :-) [18:24] rulus> Also, this is of course your choice, but I would consider licensing it under "GPLv2 or later" rather than just GPLv2 [18:25] or maybe even GPLv3 or later [18:25] LucidFox: I haven't read the GPLv3 yet, and v2 is perfectly reasonable to me [18:26] Of course, you can always relicense it in the future... [18:27] I updated the changelog, should I immediately reupload or wait for comments first? [18:28] I think immediately reupload [18:28] comments probably won't arrive in a while [18:28] (and I'm not a MOTU, so I can't comment either) [18:32] Should I create a new entry in the changelog 0.4.2-0ubuntu2, or just change the -ubuntu1 entry? [18:32] Upload it as -0ubuntu1 [18:32] the revision number is for changes that actually made it into the archive [18:33] it doens't matter there is already a -ubuntu1 uploaded? [18:33] use dput -f [18:35] uploaded [18:35] Maybe I should apply for MOTUship. I'm tired of these "I'm not a MOTU" disclaimers. :) [18:41] LucidFox: That's one sign you might be ready to apply. === Gunirus_ is now known as Gunirus === Lutin_ is now known as Lutin [19:02] stgraber: did you see this? :) http://lists.debian.org/debian-devel/2008/01/msg00506.html === Gunirus_ is now known as Gunirus [19:30] jdong: hello [19:30] could you please confirm a backport request I made ? [19:32] Gah... I should have subscribed to motu-council first, and then send the application [19:36] LucidFox: reject the mail and resent it once you are subscribed :) [19:36] how do I reject it? [19:38] follow the link in the moderation message [19:38] (at least that's possible for messages to -desktop) [19:38] Ah, got it. [19:39] Of course, all the CCs will now receive it twice... oh well === apachelogger_ is now known as apachelogger [19:47] <\sh> geser, are you working on a security update of drupal? if not, I'm preparing some [19:48] \sh, IIRC emgent is after them [19:48] \sh: no, I've only seen that drupal5 got already merged for hardy [19:50] <\sh> geser, well, gutsy is has three sec updates open/ sa-2007-31 -> 5.3 to 5.4 with the fix of 5.5 for the 5.4 fix ;) and 2008-0005 + 0006 -> 5.6 [19:50] <\sh> DktrKranz, well, no bug reported... [19:51] \sh, did you check nominations for gutsy? I think there's something on there [19:52] <\sh> DktrKranz, on the drupal5 src page on LP i don't see any bug report...I'll check motu-swat...hopefully the bugs are not private... [19:54] <\sh> DktrKranz, found it, but the diff is useless :) the bugfix for the security fix is not applied... [19:55] \sh, ah. nevermind then. [19:57] <\sh> DktrKranz, I'll added a comment...if he's going to take it mutch better :) [19:57] \sh: great if you update drupal!! [19:58] <\sh> mok0, well, when emgent is working on it, he needs it :) [19:58] \sh any plans of packaging some themes and modules? [19:58] <\sh> mok0, that was on my mind last days... [19:59] \sh: ;-D [19:59] \sh, I mentor him actually. He's moving his first steps, but it seems he learns quickly [19:59] <\sh> mok0, but when I see all the security advisories on drupal.org security page I wonder if this is a good idea :) [19:59] <\sh> DktrKranz, ah you are his mentor :) [20:00] \sh, at least I try :) [20:00] \sh: security -- I think it's mostly security of the site, rather than security of the host Os [20:01] <\sh> mok0, nah...all those non-core modules are having the usual XSS problems most of the time and they are fixing them ... but despite the good work of drupal-core with their patches, most module maintainers are not patching but releasing new versions [20:01] <\sh> mok0, and that makes maintaining a nightmare [20:02] DktrKranz: You mentioned you had a Debian Python Applications Packaging Team question for me? [20:02] <\sh> mok0, but I like the idea of having a shiny, blinky useful drupal in ubuntu ,-) [20:02] \sh: the version that in there now is age old [20:02] 5.2 I think [20:03] <\sh> mok0, yeah,...but at least this version has all serious bugfixes attached :) [20:03] sh\: cool. [20:03] drupal still exists? [20:03] <\sh> mok0, and if emgent is doing the other fixes too it's even more secure ;) [20:03] <\sh> Amaranth, sure.. [20:03] \sh: lemme know if there is something I can do to help [20:03] ScottK, yes. recently piotr added me to the team and soon I'd like to add my packages to PAPT, so before pushing wrong stuff on SVN, I'd like to ask to someone already involved. [20:04] DktrKranz: OK. Fire away when you have questions. [20:04] ScottK, sure. Thanks. [20:04] \sh: I've been brainwashed into thinking everyone just makes their own using rails or django :) [20:05] What is this django everyone is raving about? [20:06] <\sh> mok0, python style rails ... and yes, it's the wrong attribution for django ;) [20:07] <\sh> Amaranth, I don't know...but for a quick and fast installation of a website with blog etc. drupal is quite ok, even when it is php [20:07] \sh: rails is python style django, it's just more popular :) [20:08] <\sh> Amaranth, well, I don' [20:08] jeromeg: did you test transmission on gutsy, feisty, or both? [20:08] <\sh> t like ruby and I don't like rails...that's my problem [20:08] I've only had the chance to verify on Gutsy [20:09] jdong: 1.0.0-1 only on gutsy I upgraded my feisty box since my original backport request [20:09] jeromeg: ok, I'll approve on Gutsy and wait in Feisty for someone with a build env then :) [20:09] jdong: looks like the backport team needs a bit of work force :) [20:10] jdong: i can test the build for feisty [20:10] but not test if it works ok [20:11] jdong: I know that Lionel Porcheron would be pleased to join the backport team [20:11] my point of view (if it's worth something :) ) is that he is a good candidate [20:11] moreover at the moment almost nobody seems to work on backports [20:12] jeromeg: :) [20:12] so a new skilled contributor would be an asset [20:12] jeromeg: yeah seems like the fresh new members are always the ones that contribute the most ;-) [20:12] jeromeg: currently it looks like the approval guys are fast enough at getting around, it's the QA effort that's lacking [20:12] jdong: if only I was a motu :) [20:12] jeromeg: particularly for Feisty and below the number of people willing to test them is nearly nonexistent [20:13] <\sh> jdong, would you like to try a backport of wine 0.9.53 to gutsy and feisty? I prepare a new upload just now with opencdk enabled [20:13] \sh: shiny :) [20:13] jdong: well I wouldn't say this, for example I submitted a lot of backport requests to gutsy, and none of them got an answer [20:13] i tested everything carefully [20:13] but... === bmk789 is now known as linuxmce_chick [20:14] jdong: Heh, the fresh new members probably just haven't gotten overloaded with long-term side projects. :) === linuxmce_chick is now known as bmk789 [20:15] jeromeg: well perhaps you've tested yours carefully, but as I go down the list in gutsy-backports I don't see any so far I feel ready to just hit the approve button on. [20:15] jeromeg: so it might be other people holding you down ;-) [20:15] maybe :) [20:15] ToyKeeper: yeah, that's usually true, I'm starting to feel that myself already [20:15] ToyKeeper: sometimes I really feel like I've submerged myself in enough half-done projects to take 12hrs a day to dig out of [20:15] :) [20:18] ok, backports clearing time... [20:18] great [20:18] i'm building audacious at the moment [20:19] pochu: ping [20:19] lionel has set up a repo to test pidgin [20:19] my little sisters will be testing it carefully :) [20:19] jeromeg: yeah the nasty part about pidgin is following all the plugins [20:20] and the sucker tends to segfault too on mismatched plugins, not just refuse to load them [20:20] jdong: the hardy->gutsy transition seems ok [20:20] gutsy->fesity is really a shit [20:20] *feisty [20:21] jeromeg: I'm 95% certain the API changed between the two releases, I've looked at it a bit [20:21] ok [20:22] jeromeg: plus, I don't want to know what the heck we'll do if there's a security bug found in the 2.3.1 series [20:22] jeromeg: we'll all be running around poking core-devs to sponsor source change backports :) [20:22] :) [20:22] ok [20:22] jdong: security fixes are not automatically backported if the package is in backports . [20:23] ? [20:23] jeromeg: correct. we are on our own to produce security fixes. [20:23] miam [20:23] jeromeg: I'd feel better if hardy were released AND the package still backports easily, because then we can rely on the security team and backport from hardy-security [20:23] ok [20:24] jeromeg: but anyway, having a sane backports PPA for pidgin is a good idea anyway [20:24] jeromeg: I see too many horribly produced .debs out there [20:24] jdong: yep [20:26] * DaveMorris hopes someone else can advocate his package - http://revu.tauware.de/details.py?package=libserial [20:28] * jdong laughs... he found an unapproved backport that he filed himself in November :D [20:32] * Ng too is looking for another advocate for the robot future of Terminals - http://revu.tauware.de/details.py?package=terminator [20:32] * TheMuso rally thinks some contributors should slow down with their rate of contributing, and be more careful about the work they are doing... [20:33] s/rally/really/ [20:34] TheMuso: you can't knock them for trying though [20:34] DaveMorris: Not at all. Thats not my point. [20:35] * jdong thinks we need a robotic archive admin simulant :D [20:35] The point is, that being so eager to get as many things updated as possible, leaves the possibility of missing something important. IMO anyway [20:35] <\sh> I wonder for what wine needs opencdk... [20:35] I wonder if there could be a way for motu hopefulls to do comments on packages to clear out some of the easier issues for those people who cna actually advocate [20:36] they could just comment, surely? [20:36] jdong: audacious needs libmowgli [20:36] DaveMorris: It could be done. What it primarily lacks is someone hacking the capability into REVU. [20:37] Ng: No. Currently only MOTUs can submit comments on packages they didn't upload. [20:37] * TheMuso is referring to sponsors que stuff [20:37] ScottK: ah [20:37] jdong: libmowgli builds and install fine, and is not in gutsy [20:37] seems to be fine for backporting [20:38] it could be a stepping stone along the way to been a MOTU I guess [20:39] DaveMorris: hacking on REVU? [20:40] no, revuing packages and commenting, but not able to advocate [20:45] g'evening all! === apache|mobile_ is now known as apache|mobile === nuu is now known as nu[year] === nu[year] is now known as nuu [20:46] nxvl_work: contentless pong [20:47] pochu: what's the state of http://revu.tauware.de/details.py?package=terminator [20:48] nxvl_work: it's advocated by me [20:49] can anyone have a look at http://revu.tauware.de/details.py?package=sdlmame [20:49] It should be good for advocation after latest fixes [20:49] pochu: that means accepted? and it's waiting for other advocates? [20:50] nxvl_work: I'd like someone else to advocate it too [20:51] ok, just asking [20:51] :D === azeem_ is now known as azeem [21:06] nxvl_work: not a MOTU but looks fine to me too [21:06] mok0: :D [21:07] mok0: can you review mine?, http://revu.tauware.de/details.py?package=gnomecatalog [21:07] * mok0 looks [21:07] mok0: thanks [21:08] josesanch: why don't you use cdbs? Look at nxvl_work [21:09] 's debian/rules [21:09] i don't know [21:09] it's necessary? [21:10] josesanch: no, it's just easier :-) [21:11] terminator looks quite simple :) [21:11] i mean debian/rules file [21:11] josesanch: In debian/control: Description: Cataloging software for CD, DVD, and hard disk files --- it's kind of obvious that it's software, so make it shorter and more exact [21:12] e.g. "catalog CD, DVD and hard disk files" [21:12] Ok.. [21:12] josesanch: yes :) [21:13] josesanch: ... and the following description, first and second sentences say the same thing. Don't repeat yourself [21:13] josesanch: cdbs is the simpler and easier way to build packages [21:13] mok0: jeje ok [21:13] but i still prefer debhelper [21:13] :P [21:13] hehe [21:13] cdbs is an aquired taste [21:14] josesanch: why is it -0ubuntu10? [21:15] josesanch: should be 0ubuntu1 [21:15] I started by 0ubuntu1, but i had to change things [21:15] Anyone tried mercurial patch queues for managing package patches? [21:15] As long as it's not uploaded to the Ubuntu archive, don't bump the version [21:16] josesanch: yes, but it where unuploaded changes [21:16] josesanch: for ubuntu is the first version [21:16] so it should still be ubuntu1 [21:16] josesanch: debian/gnomecatalog.1 ... September 27, 2002 ????? [21:16] pochu: ouch, looks like we have a lot of activity around those packages :) [21:17] mok0: It's the date when i created the manpage [21:17] josesanch: this packaging has taken you a while, huh ;-P [21:17] * pochu wonders whether stgraber will join the FingerForce team :) [21:18] mok0: yep... is hard :) [21:18] josesanch: 6th last line "The program HAS been developED in python-gtk" [21:18] pochu: hehe, well my free time activity is the QA website, then edubuntu, then bug triaging, then packaging :) [21:19] pochu: I usually do packages for things I want to use and aren't packaged yet (I don't like having non-packaged binary), then if I can have them included without spending more than 2-3 hours I do it [21:20] josesanch: but, with the man page, I think you should write a bit more, and with more enthusiam... Why should people use this program? Can it print an index or create a searchable database? Explain in the manpage [21:20] josesanch: otherwise, I'm cool, good work [21:20] mok0: thanks, my english is not good at all. [21:21] josesanch: it also should be "Initial release for ubuntu inclusion" not just "initial release" since it is the 0.3.3 release of your package [21:21] * emgent hi [21:21] josesanch: NP we are helping each other [21:21] stgraber: yeah, you rock with the qa website. I'm spying you as I'm subscribed to the bzr branch :) [21:21] josesanch: now you just need a MOTU to ack it :-) [21:22] <\sh> emgent, hi :) can you have a look on your drupal5 security update bug report :) [21:22] wow, my pbuilder seem to be rebuilding instead of updating, i need to use/update it more often :S [21:22] mok0: thanks very much. I have done the changes. i'm going to write a better manpage, and reupload again [21:22] pochu: you are only subscribed to the low-traffic one :) (trunk) [21:23] josesanch: great [21:23] josesanch: man page is often the first thing I look at when trying out a new package, so it's good to "sell" the program well in there [21:24] pochu: about the fprint packages, what's the best, let the fingerforce team take care of it and hope we'll have a package ready soon enough for a sync ? [21:24] "fingerforce team"?? LOL [21:33] mok0: thanks i have the changes now. Any other observation or advice? [21:33] stgraber: if feel your package is ready we can et it in and sync it later if it's packaged in time in Debian. [21:33] <\sh> emgent, the patch for sa-2007-0031 had a bug which was fixed with the 5.5 release...and http://drupal.org/node/198321 gives the bugfix for it :) [21:33] stgraber: so we make sure it gets packaged in Hardy [21:33] I have a directory policy question. My package is setup for system-wide install, but the daemon CAN be run by a regular user. If so, the user should create a .ini file for the daemon based on a template in the source. I've currently placed the template in /usr/share/doc/ (by adding it to the .docs).. Is that acceptable? [21:34] \sh, thanks i read your comment [21:34] <\sh> ok...end of business..family time :) [21:34] <\sh> cu tomorrow [21:34] tomorrow i will fix all [21:34] stgraber: unless you aren't that hurry ;) === \sh is now known as \sh_away [21:34] now i go to sleep :P [21:34] josesanch: nope. Just wait for a MOTU to come along... [21:34] pochu: I don't personaly care :) I do have the package for my own use :) [21:34] mok0: thanks again :) [21:35] josesanch: nice work [21:35] stgraber: heh, we can wait a bit and if in February 1st it isn't packaged in Debian get it in here. [21:35] pochu: the only difference for me is that if we upload libfprint to universe, I'll then work on libpam-fprint and fprint-demo too (as libfprint is useless without a software using it) [21:38] no MOTUs online?! :( [21:38] wallyweek: There are quite a number of MOTUs online. [21:38] may I ask once again for reviews on http://revu.tauware.de/details.py?package=sdlmame [21:39] ? [21:39] You can ask. Online doesn't automatically translate into reviewing new packages. [21:40] wallyweek: not a motu, but I can comment [21:40] wallyweek: interested? [21:41] mok0: of course, thanks! :) [21:41] TheMuso, are you talking about me? [21:41] somerville32: no [21:42] wallyweek: debian/control, Description: SDL ... etc... I don't understand what it means. Make it clear to non-nerd what this program does. [21:42] wallyweek: further, the IMPORTANT LEGAL NOTICE stuff absolutely does not belong in a package description. [21:44] ok, I'll fix the description asap... anything more? [21:45] wallyweek: copyright ... I thought expat was James Clark [21:47] mok0: I copied it from source... I assume expat copyright is well... right :) [21:47] wallyweek: you'd think so :-) [21:48] wallyweek: what's the TODO file doing in debian/? [21:49] mok0: It's just a reminder for what should be good to do, I can remove it if you think so [21:49] wallyweek: I do [21:49] wallyweek: keep it somewhere else for your own reference [21:49] mok0: zot! ;) [21:50] Hobbsee: Excellent. Thanks for helping [21:50] LucidFox: After DIF there's no point syncing if Debian just merged our changes. If Debian also has some good bugfixes, then it makes sense. [21:50] wallyweek: what's the contrib dir doing? I don't see it being installed... [21:51] ah [21:51] examples [21:52] mok0: it's just for tidiness... config files ; examples; manpages (which are not in upstream package) [21:52] mok0: I could well put them in debian/ but I feel it would be much confusing [21:52] wallyweek: ok, that's fine. Well with my minimal knowledgem it looks good! [21:53] mok0: thanks for your help! :) [21:53] wallyweek: It was mostly the Description: [21:53] wallyweek: glad to help, I've gotten loads of help here myself [21:55] mok0: description fixed... if I can collect more suggestion I'll make a single upload as package is *big* [21:55] wallyweek: yeah, attention to detail... :-P [22:02] Could somebody help me clarify a reviewers comment? I don't understand what persia meant with #5 here: http://revu.tauware.de/details.py?package=alex4 [22:04] "5) Since you’re already patching the upstream makefile, do you really need all of that in debian/dirs? " [22:04] amarillion: Basically, debian/dirs should only contain those directories needed for package installation that are not already created by the upstream build system. Since you are already carrying a patch for the Makefile, it may be as easy to extend that patch as to put them in debian/dirs. Also, thanks for asking the question generally :) [22:05] And thanks for answering yourself anyway :) [22:05] amarillion: Additionally, that comment is more stylistic than anything. All the created directories get populated, so it's not a reason for not approving the package. [22:07] but what you mean is that I could put a few mkdirs in the makefile? [22:07] to achieve the same effect? [22:08] amarillion: Well, I prefer install -d or install -D in preference to mkdir in an install rule in a Makefile, but yes. [22:10] amarillion: JFTR, I'd have argued the opposite. Upstream isn't likely to want the dirs you're adding, so keep the upstream patching to a minimum and let the package management system do the work for you. [22:10] Yeah then I understand it now. But I just replaced all the install xxx lines with dh_install, so it seems a bit strange to start using dh_install on the one hand and stop using dh_installdirs on the other hand [22:11] Of course I'm not reviewing right now, so I'm not the one you'd have to satisfy. [22:11] As I understand it I have to satisfy at least two people :) [22:13] * ScottK isn't reviewing for Hardy period, so is extremely unlikey to be one of the two. [22:14] Well, I'm not completely sure about that one... I addressed all the other problems though [22:15] Some of these comments could be checked automatically. e.g. problems in the .desktop file. Maybe you'd accept a patch for lintian for that? [22:15] ScottK: upstream wouldn't want /usr/games and /var/games? These are the directories that are carried by the rest of the patches. For /usr/share/*, I'm more inclined to agree with you. [22:15] amarillion: lintian found problems with the .desktop file :) [22:15] really? [22:16] How should I invoke lintian then? [22:16] amarillion: Run it against arch.changes after a binary build. Also, as I said, I don't consider overuse of debian/dirs sufficient reason for non-advocation (and as ScottK said, this may not be overuse anyway) [22:16] lintian -i -I is always good :) [22:16] * persia uses lintian -iIv [22:19] * ScottK2 ponders a script to automatically capture the lintian output and create over-rides. [22:20] ScottK: heh, that'd be a really useful one :) [22:20] heh [22:23] you're right. I'll have to alias lintian as well [22:23] They don't teach you these things in school :) [22:23] one general question: I've just uploaded a new versione of sdlmame, should I comment it or could this prevent people reviewing it as it seems reviewed already? [22:27] wallyweek, I don't think it matters to add a comment [22:27] wallyweek: Only comments from reviewers adjust the "reviewed" status. If there is meaningful information you wish to communicate regarding the changes in the package or some special exception, leave a comment. [22:27] amarillion, persia: thanks! I'll leave some note as usual [22:33] hi, can someone resync the revu uploaders keyring, please? [22:33] Frimost: Sure. Takes about 20 minutes. Please try again then, as I may be away from my keyboard. [22:33] that sounds familiar :-) [22:34] persia: do you think you could have a look at my package :D [22:34] persia: ok thanks [22:34] I finally did get my package up on REVU late last night. Anybody have time to help me figure out what I did wrong? [22:34] wallyweek: sdlmame? I don't really have time right now. If nobody else hits it before I have time again, I'll take a look. Better to put out an advertisement generally. [22:38] persia: ok thank you... I advertised it since this morning, but I had no replies. Of course I understand there's lot to do for reviewers, but it's quite frustrating :( [22:40] wallyweek, Make sure take a break and come back later :] [22:42] somerville32: I'm going to bed in a while ;) [22:45] wallyweek, have you been working on that package for a year already? [22:46] The man pages are from february 2007 [22:48] amarillion: yeah [22:48] ouch... [22:48] that's why it' so frustrating :( [22:49] Why are they in a debian/contrib subdirectory? I haven't seen that before [22:49] I thought it was a good idea to keep them separate from upstream [22:49] Well everything in debian is already separate isn't it? [22:50] Not that I think it should be different, I'm just asking. [22:50] amarillion: I've seen it a few times [22:51] amarillion: it's ok not to clutter debian/ [22:51] it's just for tidiness IMHO... i know that everything but packaging stuff I have written is in debian/contrib/ [22:51] ok, I see [22:52] I think your package is at the point of quality where I can't comment on it [22:53] amarillion: I should take this good, should I? ;) [22:53] I won't pretend I'm an experienced reviewer [22:53] so it's not saying much... [22:54] I don't think so... you probably know more than I do :$ [22:54] Ok, I'll look a bit more :) [22:55] nice! [22:55] Feel free to look at mine too: http://revu.tauware.de/details.py?package=alex4 [23:02] wallyweek, after reviewing your package... [23:02] I've got comments for my own package [23:03] I should put my man page in section 6 too as it is a game as well [23:03] hehe [23:03] amarillion: the only thing I see, manpage needs to make distinction from hyphens and minus signs (only 2 occurrences btw) === Spec is now known as x-spec-t [23:03] wallyweek, yeah, persia told me that before [23:04] but what does that mean exactly? [23:05] amarillion: (not a motu) ... get rid of boilerplate comments at top of rules [23:05] amarillion: hyphens separates words between lines and may cause some mess [23:06] you need mostly minus sign (e.g. for options), and when you need a minus sign you should escape it with a backslash [23:06] amarillion: in rules, make sensible comments instead of boilerplate, and get rid of commented dh_* lines [23:07] ok [23:09] amarillion: just asking: alex4.ini shouldn't go in /etc/ ? It's config file, I presume [23:10] wallyweek, yeah I was unsure about that one [23:10] Should it then be in /etc/alex4.ini or /etc/alex4/alex4.ini? [23:11] amarillion: in copyright, you need to include the full preample [23:11] amarillion: /etc/alex4.ini IMHO, you need a subdir only when you have two or more config files [23:12] wallyweek: agree [23:12] mok0, you mean the preamble of the GPL? [23:12] amarillion: yes [23:12] I'll look at some other packages for examples [23:13] look at the templates in /usr/share/debhelper/dh_make [23:14] Ok, thanks guys [23:14] looks like I have some work to do [23:14] but first: dlrrp [23:15] good night! [23:15] amarillion: ... and when the MOTUs come back to work they will make you change everything again ;-) [23:16] :) [23:17] amarillions left hand was shifted 1 position: sleep -> dlrrp :-) [23:17] known as qwerty encryption [23:21] ...and I was looking for a new interner acronym... :) [23:22] it even sounds like how I say "sleep" when it's really time to do that. [23:23] jdong: and that's what I need indeed... ;) [23:23] g'night everyone! [23:29] Frimost: Just in case you didn't notice already, the keyring sync is complete [23:29] * persia goes away again