[00:05] Hello, crimsun, \sh. [00:05] <\sh> moins tritium [00:06] Congratulations, \sh. Nice to see you. [00:06] <\sh> tritium, thx :) [00:06] :) [00:10] 'evening, tritium. [00:10] Good to see you, crimsun. [00:14] <\sh> I wonder where sbuild hides the source packages when you add -s to it's commandline [00:19] If anyone is up for a review, please take a look at http://revu.tauware.de/details.py?package=ubuntustudio-controls . Thanks! [00:19] What package would I depend on to depend on gtk 2? [00:20] <\sh> libgtk2.0-dev ? [00:21] libgtk2.0-0 [00:21] <\sh> somerville32, oh for the binary? [00:22] yea [00:22] <\sh> I thought as build-dep [00:22] Ok :] [00:31] Any MOTU to ask a question? [00:32] <\sh> josesanch_, just ask [00:33] Thanks sh.. i want to know what is the state of the package gnomecatalog. === davi_ is now known as davi [00:33] was REVU: New: gnomecatalog 0.3.4-0ubuntu1 on 17 january [00:33] <\sh> oh..dunno...i didn't do any review work.... [00:34] was uploaded by pochu [00:34] but still is not in in hardy [00:34] <\sh> https://edge.launchpad.net/ubuntu/hardy/+queue [00:34] <\sh> it's in the new queue [00:34] Ahh.. [00:35] <\sh> needs to be checked by an archive admin.. [00:36] but in the bug https://bugs.launchpad.net/ubuntu/+bug/181140 [00:36] Launchpad bug 181140 in ubuntu "gnomecatalog" [Undecided,Fix committed] [00:36] the package is in debian since today [00:37] do i have to request a sync? or do i have to wait? [00:37] You have to wait. [00:38] It'll make it through the NEW queue in good time :) [00:38] raof: Thanks. I was a little confused :) [00:39] jeje. ok [01:02] <\sh> hmm...50G should be enough for mirroring hardy i386 amd64 (all components) [01:46] I'm creating a new package and it creates a directory (/usr/share/icons/hicolor/16x16/apps/) but doesn't place anything in it [01:47] Should it? [01:47] Thats what I'm asking. Should I patch it not to create that directory or will that break some sort of spec [01:47] +? [01:47] Generally speaking you don't want to created empty directories [01:48] I'm not sure about that specifically, I most of the stuff I package is server stuff [01:49] I think I'll just resize the image to 16x16 and get it to install it too [01:50] lol [01:55] Does anyone have an opinion on pulling Debian candidate pacakges, perhaps from mentors, SVN, or in Debian bug reports? While I'm fairly certain that version numbers should be -0ubuntu1 or -Xubuntu$(Y+1), I'm not sure how to handle the changelog. Should it be preserved? Should I add "imported into Ubuntu" as an additional act of work with the other changes (and end up with Changed-By: me)? [01:56] persia: If I was going to do that, I'd want a clear reason why it would actually help things. [01:56] Definitely 0ubuntu1 versions [01:57] I think your changelog suggestion is exactly correct. [01:57] ScottK: Adding myself and altering "Changed-By"? [01:58] hey guys [01:58] could someone please explain me this https://bugs.launchpad.net/ubuntu/+source/slrnface/+bug/184261/comments/2? what should I put in changelog about maintainer? [01:58] Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress] [01:59] persia: Yes. So the other person gets credit for their work, but you're signing on the bottom line for Ubuntu [01:59] civija: https://wiki.ubuntu.com/DebianMaintainerField might be the explanation you seek. [01:59] ScottK: That's what I was thinking. Just feels a bit odd, as I think they deserve credit unless I am also making another change. Thanks for the confirmation. [01:59] civija: What persia said. [02:00] persia: Think of it as signing up for the blame while still giving them credit. [02:00] ScottK: That works for me. Now to make sure this won't otherwise get in before feature freeze, and maybe unbreak a couple things... [02:00] persia: i've changed that in control file but this post says that i should put that in changelog? [02:01] i'm not sure ... [02:01] civija: Yep. You should note in the changelog that you've set an Ubuntu maintainer. [02:01] persia: ok, tnx [02:02] Can anyone tell me whats wrong with my rules file? http://pastebin.ca/865766 [02:02] civija: More generally, any changes to a package should be noted in the changelog. In the special case of a new upstream version, it is acceptable to only indicate major changes (as long as the details are available in the upstream changelog). In the special case of a new package for inclusion into the distribution, it is acceptable to only include a short description of the patches that had to be applied to upstream. [02:03] * persia grumbles at the existence of the Calibration DataBase System [02:04] persia: tnx [02:05] somerville32: First, binary-post-install/:: is not an exported overridable rule. You should be using install/:: or binary/:: depending on whether you want it before or after the .deb preparation (probably install/) [02:05] persia, Weird. Thats what xfce4-utils has in its rules file [02:06] persia, but I'll change to install/ [02:06] somerville32: Then you've found two packages to patch :) [02:06] somerville32: Second, you probably want to set DEB_DH_MAKESHLIBS_ARGS after the include statements (or at least this is how the CDBS Documentation suggests doing things). [02:07] So I came up with a solution to the problem of two different tarballs for Debian/Ubuntu when we upload first and it needs repacking. [02:07] ScottK: Other than the common posting of a URL to the Debian RFP or ITP? [02:07] I went ahead and made a package for the Debian maintainer using my repackage tarball. [02:08] persia: It's a new upstream for an existing package [02:08] ScottK: In that case, makes sense to point at the Ubuntu tarball in the Debian upgrade bug (although larger patches are also likely welcome). [02:08] persia, Is just changing the rules file to use install/ instead of post-binary-install/ worth it for xfce4-utils? [02:09] persia, or should I wait until I have more to do in that package? [02:09] persia: Right, I just went ahead and made a package without our changes. We'll see if he uploads it and then I get to merge it back ... [02:09] somerville32: It ensures that xfce4-utils won't later FTBFS if CDBS changes. On the other hand, it's only worth an upload if you would otherwise forget: it may be just as good to have a bug. [02:09] ScottK: I hope you've also included a get-orig-source to make it easy to verify our tarball... [02:11] persia, What do you mean by the DEB_DH_MAKESHLIBS_ARGS comment? [02:12] somerville32: The CDBS documentation recommends setting debhelper hint variables after the include statements. In your rules file, you set it before. Depending on how this is actually defined in CDBS, the default may override the previous statement. [02:13] Remember that := means evaluate at parse time, and that make does a full parse pass in the order of the file (with includes parsed at the point they appear) before evaluating the rules. [02:14] I still get the same error I was getting [02:14] somerville32: You've not posted the error yet, so I'm just evaluating syntax :) [02:14] persia, I posted it along with the paste [02:15] But basically: debian/rules:8: *** missing separator. Stop. [02:16] somerville32: Right. Somehow it didn't get to me. That usually means you've used spaces rather than tab to indent the rule definition. It may also mean you need another newline at the end of the file. [02:17] persia, By along with the paste, I mean I posted the error in the post description (which is displayed just above the paste) [02:17] persia, I'll try those hints out [02:17] somerville32: Ah. Sorry. I didn't notice that field. [02:19] persia, That is it exactly [02:19] persia, I configured gedit to use spaces instead of tabs [02:20] somerville32: Right. Did the line not appear twice in your debdiff? It should show any whitespace changes to help you discover them. [02:20] persia, I'm packaging from scratch [02:21] somerville32: Ah. That always makes it harder :) [02:24] persia: could you please check is this ok debdiff https://bugs.launchpad.net/ubuntu/+source/slrnface/+bug/184261/comments/3 [02:24] Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress] [02:24] persia, I'm pretty pleased. I was able to create a new package from scratch rather fluidly. [02:25] somerville32: Excellent. It gets even earlier with more practice :) While we're close for hardy, I expect you'll close a good heap of the needs-packaging bugs for the next release. [02:25] Aye Aye, Sir :) [02:27] civija: I usually just use " * Set Ubuntu Maintainer", but that works. [02:27] persia: ok, thank you once again :) [02:28] * persia vastly prefers reviewing debdiffs to diff.gz files for new revisions (same upstream). [03:17] When would be a good time to call dh_icons in cdbs? [03:28] somerville32: Are you packaging something non-gnome, non-xfce, and non-kde? If you must use an overload variable, add it to the install/:: rule (as dh_icons only tweaks the maintainer scripts). [03:29] Okay [03:29] It is Xfce [03:29] So the icon cache should be updated? [03:30] somerville32: Are you using xfce.mk? If so, it should. For verification, check the postinst in the binary package. [03:31] ok [03:31] Thanks [04:08] heya [04:15] <\sh> sbuild is nice...I have to say.. [04:16] \sh: Remember to install pkg-create-dbgsym, pkgbinarymangler, and pkgstriptranslations in your schroot. [04:17] <\sh> persia, well, I just played around with it... [04:17] <\sh> persia, wrote a simple infinite build server [04:18] \sh: Sure, but if those packages are present, you end up with something that can mostly replicate Soyuz build failures (there are a few corner cases where they differ remaining), which makes it lots easier to test oddities. [04:18] <\sh> now I need a database behind it, a webpage [04:18] infinite build server? Rebuilding everything over and over again? [04:20] <\sh> persia, no ...just shove some source packages into a dir, it checks for .dsc and starts building, write locks to not catch them up again, building for X archs, you decide, check for Arch: all packages etc. [04:20] Anyone know off the top of their heads of a Python package using CBDS that produces multiple binary packages? [04:20] \sh: Nifty. You might also be interested in https://launchpad.net/debomatic [04:21] <\sh> persia, well, sbuild doesn't need sudo ;) [04:21] <\sh> persia, a big advantage [04:21] ScottK: What problem are you encountering? Usually CDBS just generates multiple packages based on debian/control, without many extra hints. [04:21] \sh: You need sudo for pbuilder? [04:22] persia: How does it know which files to stuff in which packages? [04:22] ScottK: debian/package.install files, from the calls to dh_install. [04:22] <\sh> persia, well, if you don't change all the paths...the default needs a root user for the bind mounts" [04:23] \sh: Ah. I understand. Yet another reason for me to be glad to have never used pbuilder :) [04:23] persia: OK. That's what I thought. [04:23] The result so far isn't happy. [04:23] * ScottK2 will work on it a bit. [04:23] ScottK: For a package split, remember to pull things out of debian/tmp/... to put into the target packages. [04:24] Thanks [04:24] <\sh> persia, schroot -a "apt-get install pkg-create-dbgsym pkgbinarymangler pkgstriptranslations" should be enough for all chroots, right? [04:24] \sh: I'd not run that, as those packages don't belong in my Debian chroots, but I believe so. [04:25] Err, and you might need to use schroot -uroot -a ... [04:27] <\sh> yeah [04:28] <\sh> now it works .) [04:28] <\sh> nice...really [04:29] hmm [04:34] <\sh> apt-ftparchive builds a archive structure with sorted pool/ persia: There was a note to debian-devel (I think yesterday) describint linda as deprecated and not used in Debian NEW processing anymore since lintian covered essentially everything linda covers. I'm thinking (as soon as we have the latest lintian) we should update our process docs similarly. [04:43] ScottK: Maybe. I still have a soft spot for linda, but she is aging, and the maintainer doesn't want to update until some speed improvements can be applied. My python-fu has so far not been up to figuring out the right data structure to handle in-memory investigation (rather than untarring it and handling the labs). Perhaps you'd like to give it a shot? [04:43] Ah, no thanks. [04:44] Part of the reason for keeping linda is because I think there should be two compliance checkers: if they disagree, discussion is required. If there is only one, it's harder to catch the bugs. [04:44] Personally, I think if lintian is good enough for Debian, it's good enough for us. I think that makes sense, but we should follow Debian. [04:45] ScottK: I can't agree with that in the general case, but I do agree that linda's utility is limited until she gets an update. Moving to 3.7.3 isn't that hard, but there are core issues that would be better resolved (e.g. the fact that one cannot produce a debdiff for the migration to 3.7.3 due to the nature of linda internals). [04:47] In other words, feel free to strip it from our process recommendations. There is value to keeping her, but until someone is both sufficiently interested and able to update, it doesn't make sense as a policy guideline. [04:48] Err. Revise that. Feel free to raise it for the next MOTU meeting, and expect to receive my support for a proposal to strip it from our recommendations. [04:48] I assumed that was what you meant [04:49] * persia appreciates ScottK's excellent posers of telepathy and intepretation :) [04:49] s/posers/powers/ [05:07] <\sh> cu in a few hours [05:08] persia: I am here ... [05:08] Given the discussion in Debian about Linda, I'm very tempted to ask for her removal [05:08] StevenK: Ah. In that case, what do you think? === \sh is now known as \sh_away [05:09] My jury is still out [05:10] Let's just say that Linda didn't really accomplish what I thought she would [05:10] What was the goal? [05:11] To see that Lintian could have a better replacement [05:11] Instead all I got was people working on Lintian a lot, and heap of bugs and bad-mouthing [05:12] s/To see/To show/ [05:12] * StevenK runs off [05:13] Ah. So instead of replacing lintian, linda merely spurred development to get all the current fixes in place. Hmm... [05:13] * persia still thinks she was useful, even if she does get removed [05:27] hello [05:28] can anyone please tell me how to become a prosperctive developer? [05:28] wizs: You just did. Congratulations! [05:29] Now, you probably would like some suggestions on some work to do. What sort of development interests you? [05:29] is that all i have to do ? just to join this channel? [05:30] wizs: Basically. I encourage people to also join the ubuntu-motu@, ubuntu-motu-mentors@, and ubuntu-bugsquad@ mailing lists, and #ubuntu-bugs. [05:32] thanks mate! [05:32] wizs: Do you already have a project, or do you need some hints for ways to find things to work on? [05:33] sure I do want to know where to start [05:34] There's lots of ways to start. Depends on what you know, and what you want to do. Are there any types of packages that interest you? Any bugs that particularly annoy you? Do you like debugging? [05:35] I'm particularly interested in db development and java [05:35] debugging is cool with me. [05:37] ok. about myself. a software eng graduate. currently an application developer in .NET and Java. and going to start a phD degree in database [05:38] I'd start by either searching for bugs in the databsae tools, or in any of the packages listed from `apt-cache rdepends java-gcj-compat`. You may find a few you think you can fix, or at least describe better for other developers. If you think you can fix one, you might look at https://wiki.ubuntu.com/MOTU/Contributing for hints on preparing a new candidate for inclusion in the archive. [05:38] If you have any questions, please ask them here, and we'll try to answer. [05:39] wizs: Are you familiar with Berkeley DB (libdb)? [05:43] so I write a hangman game that scrapes /usr/share/dict [05:43] and the first word I got was ampelidaceous [05:43] what luck. [05:45] jdong: Did you see my clamav backport PPA? [05:46] ScottK: not yet [05:46] https://launchpad.net/~ubuntu-clamav/+archive [05:46] https://wiki.ubuntu.com/MOTU/Clamav [05:46] jdong: I need testers ^^^ [07:34] * ScottK dusts off "Mastering Regular Expressions" [07:41] Everybody else, please stand back. :-) [07:43] It was really an easy one, but I need to look it up anytime I do anything with them. [07:47] Does anyone have any hints as to where a package can be found if PTS reports received, sid cache reports unavailable, and it doesn't appear in incoming? (not NEW) [07:49] AFAIK, you wait for the next dinstall run. [07:49] I thought dinstall pulled from incoming into archives. Is there an intermediate place? [07:50] a.k.a. "on the way from incoming to the archive"? [07:50] minghua: Yes. Does such a thing exist? [07:51] persia: From a pure external observation, there seems to be a ~3 hours delay. [07:51] 1-5 hours, actually. Never really measured. [07:51] minghua: Ah. Maybe I've caught it at a bad time then :( [08:07] Could someone please review thunar-svn-plugin on REVU? http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin [08:11] ScottK: Just thought of something: lintian doesn't notice when the upstream changelog is dropped. There may well be another couple tests missed (someone ought compare, rather than just it being those someone remembers). [08:12] persia: How do you drop the upstream changelog? [08:13] minghua: Don't install it in the binary package. There are several ways to achieve this, the easiest being to use Ubuntu CDBS. [08:13] persia: Ah, dropping it in the binary package. I see. [08:14] Probably I should confirm persia's claim and report a bug against lintian. [08:15] anybody else using xchat-gnome? [08:16] Also "useless debhelper dependency". I'm not convinced that linda doesn't still have utility from this review (and I haven't even run against the binary packages yet). [08:17] Burgundavia: I do. [08:17] minghua: never mind, found the bug [08:17] persia: At this point, given the Debian FTP masters announcement, I think bugs against lintian are needed then. [08:17] minghua: it was the 5s locking bug [08:18] Burgundavia: Never seen it. But then again, this is on Debian. [08:18] there is a pulse audio bug that when joining a new channel/network, x-g locks up for 5s or so [08:18] ScottK: I'm not sure I'm in agreement, but that may be because I'm not as concerned about ftpmaster opinions. [08:20] Burgundavia: I see. Thanks for the head-up. I think I'll stay away from xchat-gnome on hardy, then. [08:21] persia: I think it's for our own sake. "Debian's ftp-master would see this warning" sounds a pretty good incentive to fix something. [08:23] minghua: Ah. Good point. Especially because e.g. "useless dependency on debhelper" is of level "Error", and is now lost. [08:25] All this make me thinking -- apparently, a regular REVU reviewer sees much more (both in quantity and variety) lintian/linda diagnosis than a Debian ftp-master. [08:26] somerville32: broken watch file, unversioned b-d on CDBS (when you want a version), and useless b-d on debhelper. [08:26] persia: how do I test a watchfile? [08:27] somerville32: There are lots of ways. The two I use (which may not be sufficient for all purposes) are `uscan --report-status` to make sure the watch file can be parsed and upstream is accessible, and `uscan --force-download` to compare the md5sum with the package. [08:29] and you're saying I want a versioned b-d on CDBS? [08:29] A lot of packages do not [08:36] somerville32: You're depending on CDBS to generate the dh_icons calls, right? [08:36] persia: correct [08:37] And you need these, or thunar won't pick up the right icons for files on which the package acts, right? [08:37] Essentially, if your package wasn't so deeply integrated into a desktop environment, I wouldn't really care if dh_icons might be broken. Because it is, it matters. [08:39] Burgundavia> I'm using xchat-gnome [08:39] ah, I see [08:40] persia: so I should just put a greater than or equal to the current version of CDBS? [08:41] somerville32: Doesn't have to be current. Did the REVU comment not show the right version? [08:41] Ah, I didn't know you commented [08:45] gpocentek: Regarding the duplication of gtk in the source, you say that you're not fond of that but is that relevant to advocation or was that just a comment? === \sh_away is now known as \sh [08:59] <\sh> moins [09:01] hiya \sh [09:03] Good morning \sh [09:03] * ScottK is off to bed. Good night all. [09:03] <\sh> so good the morning not is [09:03] * \sh is tired...just slept 3 hours [09:03] <\sh> thinking about a new cool project [09:04] Sounds good. [09:04] <\sh> yeah... [09:04] <\sh> taking opensuse buildservice and create something better ,-) [09:05] <\sh> soyuz for home usgae [09:06] \sh: You might consider looking at deb-o-matic and falcon, both of which do some of that. Could save you a bit of work. [09:06] <\sh> persia, falcon == seveas project? [09:07] it didn't change name? [09:07] \sh: Yes. Else I'd have said falconpl. [09:07] <\sh> hehe [09:07] lucas: I heard something about a plan for that, but haven't heard it to be implemented yet. [09:09] lucas: I think he's still deciding. [09:09] But since falconpl changed their package name, we're down to wrestling over /usr/bin real estate. [09:14] persia: since the tarball includes LGPL code, should I just copy the LGPL into the debian/ directory or something? [09:14] somerville32> Is the the rest GPL? [09:15] somerville32: I'm not really clear on how that is supposed to work. I believe that upstream is supposed to provide you with the file. Better to ask someone else (I've never done new packaging). [09:15] LucidFox: correct [09:17] I had such an issue recently. Got a package rejected on the grounds that it didn't have a LGPL COPYING file. Later they agreed that the GPL automatically swallows the LGPL since the entire work can only be GPL, and accepted the package. [09:17] Oh right. Can't you use GPL instead of LGPL with LGPL Code if you want? [09:18] Not really... [09:18] minghua> Why not? [09:19] If someone links GPL sofware with something under another license, the entire combined work becomes covered by the GPL. [09:19] And LGPL contains an explicit GPL conversion clause. [09:20] LucidFox: I am not sure what somerville32 meant, but if it's "there is a piece of LGPL code, I don't own any copyright of it, but I want to license it to GPL" (which is my understanding), then I believe the answer is a clear "NO". [09:20] The answer is yes. [09:21] http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License [09:21] "One feature of the LGPL is that one can convert any LGPLed piece of software into a GPLed piece of software (section 3 of the license). This feature is useful for direct reuse of LGPLed code in GPLed libraries and applications, or if one wants to create a version of the code that software companies cannot use in proprietary software products." [09:21] Well, I think it's no. But I've had more than enough licensing argument today, so I'll shut up right now. [09:21] hi all [09:21] I uploaded a packaged to revu yesterday [09:22] but it didn't show up yet on the webpage [09:22] is that normal [09:22] asabil> No [09:22] (that was my 1st upload to revu) [09:22] asabil: No. What is your launchpad ID? Also, what was the package name? [09:22] LucidFox: how one can know that if the LGPL license is not in the tarball? [09:22] persia: asabil, and libgee [09:23] asabil is my ID [09:23] and I think I was supposed to receive a mail as well no ? [09:23] with the password for revu [09:23] I didn't receive it yet [09:23] gpocentek> The LGPL allows to replace the LGPL copyright header with a GPL one [09:24] asabil: No. There is no mail. Looks like you joined the contributors group too recently. I'll resync the keyring, and then you'll have to upload again. Hold on a bit... [09:24] ok thanks persia [09:24] yes, but if you don't have the full license text, you don't know it [09:25] so to me it's needed to have the file in the sources, but I might be wrong [09:26] gpocentek: The header gives directions on how to get the license if it isn't included in the bundle. [09:26] And the LGPLv2, section 3 states: "You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library." [09:27] somerville32: better ask an archive admin anyway, they probably have better answers than I do [09:27] However, I'll need to modify the headers [09:27] Generally speaking, it's upstream's job to modify the headers... [09:28] For now, I think I'll just place a copy of the LGPL in the root of the source directory [09:28] So far, however, Ubuntu's semi-official stance seems to be to silently overlook the header issue [09:28] Ok, well, I'll forgo that then and see what an archive admin says [09:28] seeing how eggtrayicon.{c,h} in rhythmbox have LGPL headers even though a LGPL COPYING file isn't there [09:29] and as I said, my package inkblot was rejected on these grounds, then archive admins discussed it with each other and it was accepted [09:31] * Hobbsee waves [09:32] * somerville32 waves. [09:33] Oh gawd. Drunk friends wants me to go pick then up. [09:33] I re-uploaded it. [09:33] Hi Hobbsee [09:35] * LucidFox pokes yamal [09:35] heh [09:38] jscinoz: Did you ever sort out the issues with urbanterror-data? [09:42] asabil: You should be good to upload now. Let us know if it doesn't show up within about 15 minutes of your upload. [09:42] okidoki thanks persia [09:51] dh_install: libgee-dev missing files (usr/include/gee-1.0/gee/*), aborting [09:51] anyone to help me with this please ? [09:57] sorry, got disconnected === persia changed the topic of #ubuntu-motu to: Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Unmet Deps time! http://qa.ubuntuwire.com/debcheck/ | QA resources from http://qa.ubuntuwire.com | It's REVU Day! Reviewers, FeatureFreeze nears: it's time to clear the queue at http://revu.ubuntuwire.com/. Packagers, be sure to announce your uploads. [09:58] OK. It's REVU Day again. The keyring is synchronised. The packages are waiting. Let's clear them all! [09:59] asabil: Sometimes dh_install gets confused. Try debian/tmp/usr/... [10:01] persia> I'm going to email the qconf upstream about missing copyright headers, but I was wondering what action to take [10:01] As a reminder, peer comments are now enabled: all contributors should feel free to look at other packages: any feedback you provide increases the chance that a MOTU will be looking at your package instead. [10:01] Yay! [10:02] he's reluctant to add copyright headers because the files in modules/ and conf/ are included in other files [10:02] * persia is looking carefully this time [10:03] * Hobbsee cleans out revu [10:03] Olivier Prieur here? [10:04] wolfger isn't either, it appears [10:05] LucidFox: My issue is mostly that "For license information, see the COPYING file in the qconf base directory." is wrong. Dropping that, and replacing with either a notice of free reuse or something ISCish would be acceptable. So would adding the license preamble. This is unacceptable precisely because they will be included in other places, where the "qconf base directory" may not have meaning. [10:06] Well, the previous version 1.3 had no copyright notices in these files altogether. I asked to add copyright headers, and got... this. [10:06] Thorvald Natvig here? [10:08] right. revu cleaned out [10:08] LucidFox: The problem is that copyright (with penalties for reuse) is implicit in authorship (or possibly publication) in many jurisdictions. This is slightly better than nothing, but still not good enough :( [10:08] Hobbsee: Thank you. [10:09] Looking at one REVU package, is it okay to have the Homepage field in the binary package section of debian/control? [10:10] LucidFox: It should be in Homepage: unless there are (oddly) different homepages for different binaries. [10:10] yes, it is in Homepage: [10:11] but that line is in the binary package section [10:11] as a header [10:12] LucidFox: That's fine, although in the Source: stanza is generally better (again, unless the package oddly has different homepages for different binaries). [10:15] persia: it worked :) [10:15] persia: now how can I bribe people to review it ? :D [10:17] asabil: I recommend an announcement of the form "I've just uploaded $package, available for review at $url". [10:18] here ? on this channel ? [10:18] asabil> yes [10:18] I've uploaded libgee available for review at http://revu.tauware.de/details.py?package=libgee [10:18] :D [10:18] Yes. Here. Now. Not more than once a day, except for REVU day (today), when once every 4-5 hours doesn't tend to annoy too many people. [10:19] oki [10:20] asabil> First, look at the lintian warnings [10:21] ok [10:22] I got some comments on my upload at http://revu.tauware.de/details.py?package=gtkvd , and I have some questions (again) ;) About the first one: how do I know on which modules I need to depend? Is there some tool to generate this? [10:26] rulus: no, you need to check in which package the modules are and list them manually [10:26] persia, yes but i havn't gotten much/any feedback on the latest ones [10:27] geser: I only have to depend on that modules that aren't in the default Ubuntu installation? [10:27] jscinoz: I'm just curious if you've checked with the archive-admins about urbanterror-data. If not, I'm not sure an advocation of urbanterror would mean much. [10:28] asabil: first round of comments for you [10:28] a small update to sdlmame, now waiting for reviews at http://revu.ubuntuwire.com/details.py?package=sdlmame [10:29] thanks mok0 [10:29] rulus: on every module package your package need [10:30] geser: ok, thanks for the info :-) [10:30] asabil> Added a review as well [10:32] rulus: think e.g. of kubuntu (or any other customised ubuntu installation/ derivative) where the python gtk module can be not installed [10:33] rulus: there is only a small set of packages which are essential that is guaranteed to be installed everywhere (which you don't need to list in depends) [10:33] geser: aha, I understand [10:38] Hmm, I never heard of the Vala programming language, but it sounds very interesting. [10:54] LucidFox, mok0: when I fix all the issues, I should just dput again ? [10:55] no need to bump the version right ? [10:55] asabil> yes [10:55] no need to bump [10:55] oki thanks [10:56] asabil> triaged the needs-packaging bug [10:57] thanks [10:58] btw, concerning your 5th point [10:58] the Maintainer should be set to MOTU ? [10:58] and Original-Maintainer to me ? [11:03] asabil> yes [11:03] Maintainer: Ubuntu MOTU Developers [11:03] XSBC-Original-Maintainer: Your Name [11:04] ok thanks [11:13] About the last comment (http://revu.tauware.de/details.py?package=gtkvd), do I need debian/dirs? I think the needed folders are created automatically by setup.py? [11:15] hmmm, I uploaded a new revision, but it didn't seem to appear on the revu page :/ [11:15] what did I do wrong ? [11:15] (I changed the package version from -0 to -0ubunt1 [11:16] asabil: Maybe just waiting for the refresh (happens every 10 minutes or so)? [11:19] rulus> debian/dirs is only needed if you cp something there, or deliberately want to have empty directories in the deb [11:20] if the upstream installer creates the directories it needs itself, debian/dirs is not needed [11:20] LucidFox: ok, thanks :-) [11:25] I think I fixed all the issues with my libgee upload [11:26] Hello. [11:29] persia, what should i be checking about it? [11:31] jscinoz: Last review asked you to check with the archive admins to see if the size would be an issue. [11:41] * rulus updated gtkvd: http://revu.tauware.de/details.py?package=gtkvd [11:44] how can i contact the admisn === Zdraaa is now known as Zdra [11:47] jscinoz: They are often on #ubuntu-devel on weekdays from around 8-22 UTC. You could also send email to ubuntu-archive@l.u.c [11:54] persia: mithrandir might still be around on #u-d [11:55] jscinoz: ^^ [12:16] <\sh> hmm...does anyone know where the .changes format documentation is hiding on debians server? [12:18] <\sh> got it [12:18] \sh: Share? [12:18] <\sh> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debianchangesfiles [12:18] ok thanks [12:26] elkbuntu you idiot :) [12:31] elkbuntu always wins :) [12:32] persia, he joined *every* channel i was in to get at me [12:32] of course since i could only get rid of him from some, he got great thrills [12:32] actually, the only ones unscathed were my loco channels :-/ [12:33] To all motus: I have a fast question about tomorrow revu: I'd like to present the official Falconpl 0.8.8 package. [12:33] elkbuntu: he got you in #u-es [12:33] currently 0.8.7 version is loaded. [12:33] Does it pose any problem if I just dput the new version? [12:34] jpatrick, ah... he did get one of my loco channels then [12:34] jonnymind: Last I saw, falconpl was awaiting review. If you update it, the status doesn't change. If there was an advocation I didn't see, you lose the advocation with an update. [12:34] <\sh> .oO(/ignore is a bliss when it's known...bans is so 90ties) [12:34] not that it's my loco channel, im just in there to monitor the ascii genitalia gang [12:34] elkbuntu: where I prompty throw him out [12:35] \sh, for an op to ban a troublemaker who's insulting everyone who speaks in his presence, is irresponsible [12:37] <\sh> elkbuntu, this jerk is registered on freenode...a k-line is more useful of an irc admin to stop those jerks..a ban is temporary and most likely he just reconnect his router and get a new ip et voila [12:37] <\sh> so /mode +b is not enough to get rid of these people [12:38] * \sh wonders why nobody learned from the experiences of the 90ties where IRC was more like a wargame [12:39] \sh, yes, and we have people trying to get staffers (rare at this time of day), but i still have to keep an eye on him until then [12:40] \sh: if they were actually giving out staffing access, with klines... [12:41] <\sh> Hobbsee, hopefully not...k-lines are irc admin territory and not for customers of a service (s/customers/users/) [12:42] \sh: [12:42] even the newer staff aren't getting kline powers [12:42] <\sh> Hobbsee, the idea behind k-lines are : just put the whole /24 in the server config reload it and wait for the ISP to complain so an irc admin can give evidence to the ISP that one user is misbehaving [12:42] you have to get enough xp before you get o-lines and klines etc. [12:42] * persia notes that it is REVU day, and three people should go do REVUs rather than talking about IRC stuff. [12:43] persia: bah humbug. i cleaned up REVU. that's my good deed for the day [12:43] \sh, you're aware that doing that would exclude most of freenode's users... hence killing the network, right? [12:43] Hobbsee: You get a pass for other reasons. The three would be the other three members of the conversation. [12:43] ahhh [12:44] persia, cheat. [12:44] Seveas: four! [12:44] Hobbsee should do more revu, lazy ozzie woman [12:44] * Seveas should now run [12:44] hah [12:44] eek [12:45] Seveas: conflict of interest. Check +participation [12:45] Seveas: now, if i *ever* get kline powers...you know who the first to go will be? [12:45] <\sh> elkbuntu, yes, but e.g. vandalism of my service is just like someone would enter my house and destroy my furniture... [12:46] Hobbsee, probably gary since he's the default victim [12:46] \sh, yes it is. however jailing the rest of the town for the crimes of that one person would not bide well anywhere [12:48] <\sh> elkbuntu, e.g. on my webserver I have 182 /24er blocked...because of heavily spamming drupal...most of those /24er are coming from china, russia and other not well behaving countries..around 1/4 of networks which are not coming from those countries are from germany...and I already have connections to most of the ISPs here, and they are hunting their users now [12:49] \sh, that's great for a non-realtime service, but it would ruin an irc network like freenodes. heck if one person from wanadoo messed up, you're excluding half of france for it [12:49] elkbuntu: this is a problem? [12:49] elkbuntu, we've done that in the past with half of turkey and poland :) [12:49] * Hobbsee hides from all the french people [12:49] Hobbsee, the french might think so [12:50] Erm. OK. Next person to talk about IRC without first reviewing a package gets a frown! [12:50] Seveas, indeed we have, but not for *one* person [12:50] <\sh> elkbuntu, you block not the whole ISP but a block of 255 ip addresses hence a /24 (or old nameing class C network) [12:50] frown away, persia [12:50] * persia frowns at \sh and elkbuntu [12:50] * \sh works on something... [12:51] * \sh wonders if it's possible with a magic gpg cli switch to remove the ascii armor from a signed file [12:51] <\sh> after checking the sig e.g. === Zdraaa is now known as Zdra [12:59] persia: thank you, I get it. No, there isn't any comment nor advocation yet. [13:00] jonnymind: Then it's safe to upload a new candidate. Best do it now before someone looks and maybe advocates (as it can be annoying waiting for NEW processing when there are improvements ready). [13:00] k [13:01] I'll do that in minutes then. === bigon` is now known as bigon === cprov is now known as cprov-afk [13:12] persia: we have a zlib module that may be optionally built using the system zlib. [13:13] would ubuntu prefer we to link against system zlib and set proper dependencies, or woudl it prefer we to use our internal version? [13:15] <\sh> jonnymind, system zlib..less maintaince when zlib is broken [13:16] \sh: ack [13:16] <\sh> jonnymind, another point: no duplicated sources in the archives [13:16] \sh: you mean we should strip our source off of zlib source code? [13:17] <\sh> jonnymind, normally we strip duplicate sources out of the orig.tar.gz, yes...most known libs which are shipped with upstream sources are ffmpeg or zlib or boost ;) [13:18] Ah, ok. So I can do this in my local ubuntu copy while packing, right? [13:18] np for that. [13:21]