[00:05] <tritium> Hello, crimsun, \sh.
[00:05] <\sh> moins tritium
[00:06] <tritium> Congratulations, \sh.  Nice to see you.
[00:06] <\sh> tritium, thx :)
[00:06] <tritium> :)
[00:10] <crimsun> 'evening, tritium.
[00:10] <tritium> 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] <rexbron> If anyone is up for a review, please take a look at http://revu.tauware.de/details.py?package=ubuntustudio-controls . Thanks!
[00:19] <somerville32> What package would I depend on to depend on gtk 2?
[00:20] <\sh> libgtk2.0-dev ?
[00:21] <somerville32> libgtk2.0-0
[00:21] <\sh> somerville32, oh for the binary?
[00:22] <somerville32> yea
[00:22] <\sh> I thought as build-dep
[00:22] <somerville32> Ok :]
[00:31] <josesanch_> Any MOTU to ask a question?
[00:32] <\sh> josesanch_, just ask
[00:33] <josesanch_> Thanks sh.. i want to know what is the state of the package gnomecatalog.
[00:33] <josesanch_> 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] <josesanch_> was uploaded by pochu
[00:34] <josesanch_> 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] <josesanch_> Ahh..
[00:35] <\sh> needs to be checked by an archive admin..
[00:36] <josesanch_> but in the bug https://bugs.launchpad.net/ubuntu/+bug/181140
[00:36] <ubotu> Launchpad bug 181140 in ubuntu "gnomecatalog" [Undecided,Fix committed]
[00:36] <josesanch_> the package is in debian since today
[00:37] <josesanch_> do i have to request a sync? or do i have to wait?
[00:37] <RAOF> You have to wait.
[00:38] <RAOF> It'll make it through the NEW queue in good time :)
[00:38] <josesanch_> raof: Thanks. I was a little confused :)
[00:39] <josesanch_> jeje. ok
[01:02] <\sh> hmm...50G should be enough for mirroring hardy i386 amd64 (all components)
[01:46] <somerville32> 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] <ScottK2> Should it?
[01:47] <somerville32> Thats what I'm asking. Should I patch it not to create that directory or will that break some sort of spec
[01:47] <somerville32> +?
[01:47] <ScottK2> Generally speaking you don't want to created empty directories
[01:48] <ScottK2> I'm not sure about that specifically, I most of the stuff I package is server stuff
[01:49] <somerville32> I think I'll just resize the image to 16x16 and get it to install it too
[01:50] <somerville32> lol
[01:55] <persia> 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] <ScottK2> persia: If I was going to do that, I'd want a clear reason why it would actually help things.
[01:56] <ScottK2> Definitely 0ubuntu1 versions
[01:57] <ScottK2> I think your changelog suggestion is exactly correct.
[01:57] <persia> ScottK: Adding myself and altering "Changed-By"?
[01:58] <civija> hey guys
[01:58] <civija> 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] <ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
[01:59] <ScottK2> persia: Yes.  So the other person gets credit for their work, but you're signing on the bottom line for Ubuntu
[01:59] <persia> civija: https://wiki.ubuntu.com/DebianMaintainerField might be the explanation you seek.
[01:59] <persia> 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] <ScottK2> civija: What persia said.
[02:00] <ScottK2> persia: Think of it as signing up for the blame while still giving them credit.
[02:00] <persia> 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] <civija> persia: i've changed that in control file but this post says that i should put that in changelog?
[02:01] <civija> i'm not sure ...
[02:01] <persia> civija: Yep.  You should note in the changelog that you've set an Ubuntu maintainer.
[02:01] <civija> persia: ok, tnx
[02:02] <somerville32> Can anyone tell me whats wrong with my rules file? http://pastebin.ca/865766
[02:02] <persia> 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] <civija> persia: tnx
[02:05] <persia> somerville32: First, binary-post-install/<package>:: is not an exported overridable rule.  You should be using install/<package>:: or binary/<package>:: depending on whether you want it before or after the .deb preparation (probably install/)
[02:05] <somerville32> persia, Weird. Thats what xfce4-utils has in its rules file
[02:06] <somerville32> persia, but I'll change to install/
[02:06] <persia> somerville32: Then you've found two packages to patch :)
[02:06] <persia> 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] <ScottK2> 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] <persia> ScottK: Other than the common posting of a URL to the Debian RFP or ITP?
[02:07] <ScottK2> I went ahead and made a package for the Debian maintainer using my repackage tarball.
[02:08] <ScottK2> persia: It's a new upstream for an existing package
[02:08] <persia> 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] <somerville32> persia, Is just changing the rules file to use install/ instead of post-binary-install/ worth it for xfce4-utils?
[02:09] <somerville32> persia, or should I wait until I have more to do in that package?
[02:09] <ScottK2> 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] <persia> 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] <persia> ScottK: I hope you've also included a get-orig-source to make it easy to verify our tarball...
[02:11] <somerville32> persia, What do you mean by the DEB_DH_MAKESHLIBS_ARGS comment?
[02:12] <persia> 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] <persia> 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] <somerville32> I still get the same error I was getting
[02:14] <persia> somerville32: You've not posted the error yet, so I'm just evaluating syntax :)
[02:14] <somerville32> persia, I posted it along with the paste
[02:15] <somerville32> But basically: debian/rules:8: *** missing separator. Stop.
[02:16] <persia> 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] <somerville32> 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] <somerville32> persia, I'll try those hints out
[02:17] <persia> somerville32: Ah.  Sorry.  I didn't notice that field.
[02:19] <somerville32> persia, That is it exactly
[02:19] <somerville32> persia, I configured gedit to use spaces instead of tabs
[02:20] <persia> somerville32: Right.  Did the line not appear twice in your debdiff?  It should show any whitespace changes to help you discover them.
[02:20] <somerville32> persia, I'm packaging from scratch
[02:21] <persia> somerville32: Ah.  That always makes it harder :)
[02:24] <civija> persia: could you please check is this ok debdiff https://bugs.launchpad.net/ubuntu/+source/slrnface/+bug/184261/comments/3
[02:24] <ubotu> Launchpad bug 184261 in slrnface "slrnface doesn't display X-Face header" [Undecided,In progress]
[02:24] <somerville32> persia, I'm pretty pleased. I was able to create a new package from scratch rather fluidly.
[02:25] <persia> 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] <somerville32> Aye Aye, Sir :)
[02:27] <persia> civija: I usually just use "  * Set Ubuntu Maintainer", but that works.
[02:27] <civija> persia: ok, thank you once again :)
[02:28]  * persia vastly prefers reviewing debdiffs to diff.gz files for new revisions (same upstream).
[03:17] <somerville32> When would be a good time to call dh_icons in cdbs?
[03:28] <persia> somerville32: Are you packaging something non-gnome, non-xfce, and non-kde?  If you must use an overload variable, add it to the install/<package>:: rule (as dh_icons only tweaks the maintainer scripts).
[03:29] <somerville32> Okay
[03:29] <somerville32> It is Xfce
[03:29] <somerville32> So the icon cache should be updated?
[03:30] <persia> somerville32: Are you using xfce.mk?  If so, it should.  For verification, check the postinst in the binary package.
[03:31] <somerville32> ok
[03:31] <somerville32> Thanks
[04:08] <emgent> heya
[04:15] <\sh> sbuild is nice...I have to say..
[04:16] <persia> \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] <persia> \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] <persia> 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] <ScottK2> Anyone know off the top of their heads of a Python package using CBDS that produces multiple binary packages?
[04:20] <persia> \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] <persia> ScottK: What problem are you encountering?  Usually CDBS just generates multiple packages based on debian/control, without many extra hints.
[04:21] <persia> \sh: You need sudo for pbuilder?
[04:22] <ScottK2> persia: How does it know which files to stuff in which packages?
[04:22] <persia> 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] <persia> \sh: Ah.  I understand.  Yet another reason for me to be glad to have never used pbuilder :)
[04:23] <ScottK2> persia: OK.  That's what I thought.
[04:23] <ScottK2> The result so far isn't happy.
[04:23]  * ScottK2 will work on it a bit.
[04:23] <persia> ScottK: For a package split, remember to pull things out of debian/tmp/... to put into the target packages.
[04:24] <ScottK> Thanks
[04:24] <\sh> persia, schroot -a "apt-get install pkg-create-dbgsym pkgbinarymangler pkgstriptranslations" should be enough for all chroots, right?
[04:24] <persia> \sh: I'd not run that, as those packages don't belong in my Debian chroots, but I believe so.
[04:25] <persia> 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] <Nafallo> hmm
[04:34] <\sh> apt-ftparchive builds a archive structure with sorted pool/<component/{lib}[a-z]/ directories, right?
[04:40] <ScottK> 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] <persia> 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] <ScottK> Ah, no thanks.
[04:44] <persia> 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] <ScottK> 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] <persia> 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] <persia> 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] <persia> 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] <ScottK> I assumed that was what you meant
[04:49]  * persia appreciates ScottK's excellent posers of telepathy and intepretation :)
[04:49] <persia> s/posers/powers/
[05:07] <\sh> cu in a few hours
[05:08] <StevenK> persia: I am here ...
[05:08] <StevenK> Given the discussion in Debian about Linda, I'm very tempted to ask for her removal
[05:08] <persia> StevenK: Ah.  In that case, what do you think?
[05:09] <StevenK> My jury is still out
[05:10] <StevenK> Let's just say that Linda didn't really accomplish what I thought she would
[05:10] <persia> What was the goal?
[05:11] <StevenK> To see that Lintian could have a better replacement
[05:11] <StevenK> Instead all I got was people working on Lintian a lot, and heap of bugs and bad-mouthing
[05:12] <StevenK> s/To see/To show/
[05:12]  * StevenK runs off
[05:13] <persia> 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] <wizs> hello
[05:28] <wizs> can anyone please tell me how to become a prosperctive developer?
[05:28] <persia> wizs: You just did.  Congratulations!
[05:29] <persia> Now, you probably would like some suggestions on some work to do.  What sort of development interests you?
[05:29] <wizs> is that all i have to do ? just to join this channel?
[05:30] <persia> wizs: Basically.  I encourage people to also join the ubuntu-motu@, ubuntu-motu-mentors@, and ubuntu-bugsquad@ mailing lists, and #ubuntu-bugs.
[05:32] <wizs> thanks mate!
[05:32] <persia> wizs: Do you already have a project, or do you need some hints for ways to find things to work on?
[05:33] <wizs> sure I do want to know where to start
[05:34] <persia> 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] <wizs> I'm particularly interested in db development and java
[05:35] <wizs> debugging is cool with me.
[05:37] <wizs> 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] <persia> 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] <persia> If you have any questions, please ask them here, and we'll try to answer.
[05:39] <ScottK> wizs: Are you familiar with Berkeley DB (libdb)?
[05:43] <jdong> so I write a hangman game that scrapes /usr/share/dict
[05:43] <jdong> and the first word I got was ampelidaceous
[05:43] <jdong> what luck.
[05:45] <ScottK> jdong: Did you see my clamav backport PPA?
[05:46] <jdong> ScottK: not yet
[05:46] <ScottK> https://launchpad.net/~ubuntu-clamav/+archive
[05:46] <ScottK> https://wiki.ubuntu.com/MOTU/Clamav
[05:46] <ScottK> jdong: I need testers ^^^
[07:34]  * ScottK dusts off "Mastering Regular Expressions"
[07:41] <minghua> Everybody else, please stand back. :-)
[07:43] <ScottK> It was really an easy one, but I need to look it up anytime I do anything with them.
[07:47] <persia> 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] <ScottK> AFAIK, you wait for the next dinstall run.
[07:49] <persia> I thought dinstall pulled from incoming into archives.  Is there an intermediate place?
[07:50] <minghua> a.k.a. "on the way from incoming to the archive"?
[07:50] <persia> minghua: Yes.  Does such a thing exist?
[07:51] <minghua> persia: From a pure external observation, there seems to be a ~3 hours delay.
[07:51] <minghua> 1-5 hours, actually.  Never really measured.
[07:51] <persia> minghua: Ah.  Maybe I've caught it at a bad time then :(
[08:07] <somerville32> Could someone please review thunar-svn-plugin on REVU? http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
[08:11] <persia> 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] <minghua> persia: How do you drop the upstream changelog?
[08:13] <persia> 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] <minghua> persia: Ah, dropping it in the binary package.  I see.
[08:14] <minghua> Probably I should confirm persia's claim and report a bug against lintian.
[08:15] <Burgundavia> anybody else using xchat-gnome?
[08:16] <persia> 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] <minghua> Burgundavia: I do.
[08:17] <Burgundavia> minghua: never mind, found the bug
[08:17] <ScottK> persia: At this point, given the Debian FTP masters announcement, I think bugs against lintian are needed then.
[08:17] <Burgundavia> minghua: it was the 5s locking bug
[08:18] <minghua> Burgundavia: Never seen it.  But then again, this is on Debian.
[08:18] <Burgundavia> there is a pulse audio bug that when joining a new channel/network, x-g locks up for 5s or so
[08:18] <persia> ScottK: I'm not sure I'm in agreement, but that may be because I'm not as concerned about ftpmaster opinions.
[08:20] <minghua> Burgundavia: I see.  Thanks for the head-up.  I think I'll stay away from xchat-gnome on hardy, then.
[08:21] <minghua> 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] <persia> minghua: Ah.  Good point.  Especially because e.g. "useless dependency on debhelper" is of level "Error", and is now lost.
[08:25] <minghua> 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] <persia> somerville32: broken watch file, unversioned b-d on CDBS (when you want a version), and useless b-d on debhelper.
[08:26] <somerville32> persia: how do I test a watchfile?
[08:27] <persia> 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] <somerville32> and you're saying I want a versioned b-d on CDBS?
[08:29] <somerville32> A lot of packages do not
[08:36] <persia> somerville32: You're depending on CDBS to generate the dh_icons calls, right?
[08:36] <somerville32> persia: correct
[08:37] <persia> And you need these, or thunar won't pick up the right icons for files on which the package acts, right?
[08:37] <persia> 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] <LucidFox> Burgundavia> I'm using xchat-gnome
[08:39] <LucidFox> ah, I see
[08:40] <somerville32> persia: so I should just put a greater than or equal to the current version of CDBS?
[08:41] <persia> somerville32: Doesn't have to be current.  Did the REVU comment not show the right version?
[08:41] <somerville32> Ah, I didn't know you commented
[08:45] <somerville32> 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?
[08:59] <\sh> moins
[09:01] <somerville32> hiya \sh
[09:03] <ScottK> 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] <ScottK> 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] <persia> \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] <lucas> it didn't change name?
[09:07] <persia> \sh: Yes.  Else I'd have said falconpl.
[09:07] <\sh> hehe
[09:07] <persia> lucas: I heard something about a plan for that, but haven't heard it to be implemented yet.
[09:09] <ScottK> lucas: I think he's still deciding.
[09:09] <ScottK> But since falconpl changed their package name, we're down to wrestling over /usr/bin real estate.
[09:14] <somerville32> persia: since the tarball includes LGPL code, should I just copy the LGPL into the debian/ directory or something?
[09:14] <LucidFox> somerville32> Is the the rest GPL?
[09:15] <persia> 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] <somerville32> LucidFox: correct
[09:17] <LucidFox> 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] <somerville32> Oh right. Can't you use GPL instead of LGPL with LGPL Code if you want?
[09:18] <minghua> Not really...
[09:18] <LucidFox> minghua> Why not?
[09:19] <LucidFox> If someone links GPL sofware with something under another license, the entire combined work becomes covered by the GPL.
[09:19] <LucidFox> And LGPL contains an explicit GPL conversion clause.
[09:20] <minghua> 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] <LucidFox> The answer is yes.
[09:21] <LucidFox> http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
[09:21] <LucidFox> "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] <minghua> 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] <asabil> hi all
[09:21] <asabil> I uploaded a packaged to revu yesterday
[09:22] <asabil> but it didn't show up yet on the webpage
[09:22] <asabil> is that normal
[09:22] <LucidFox> asabil> No
[09:22] <asabil> (that was my 1st upload to revu)
[09:22] <persia> asabil: No.  What is your launchpad ID?  Also, what was the package name?
[09:22] <gpocentek> LucidFox: how one can know that if the LGPL license is not in the tarball?
[09:22] <asabil> persia: asabil, and libgee
[09:23] <asabil> asabil is my ID
[09:23] <asabil> and I think I was supposed to receive a mail as well no ?
[09:23] <asabil> with the password for revu
[09:23] <asabil> I didn't receive it yet
[09:23] <LucidFox> gpocentek> The LGPL allows to replace the LGPL copyright header with a GPL one
[09:24] <persia> 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] <asabil> ok thanks persia
[09:24] <gpocentek> yes, but if you don't have the full license text, you don't know it
[09:25] <gpocentek> so to me it's needed to have the file in the sources, but I might be wrong
[09:26] <somerville32> gpocentek: The header gives directions on how to get the license if it isn't included in the bundle.
[09:26] <somerville32> 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] <gpocentek> somerville32: better ask an archive admin anyway, they probably have better answers than I do
[09:27] <somerville32> However, I'll need to modify the headers
[09:27] <LucidFox> Generally speaking, it's upstream's job to modify the headers...
[09:28] <somerville32> For now, I think I'll just place a copy of the LGPL in the root of the source directory
[09:28] <LucidFox> So far, however, Ubuntu's semi-official stance seems to be to silently overlook the header issue
[09:28] <somerville32> Ok, well, I'll forgo that then and see what an archive admin says
[09:28] <LucidFox> seeing how eggtrayicon.{c,h} in rhythmbox have LGPL headers even though a LGPL COPYING file isn't there
[09:29] <LucidFox> 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] <somerville32> Oh gawd. Drunk friends wants me to go pick then up.
[09:33] <somerville32> I re-uploaded it.
[09:33] <geser> Hi Hobbsee
[09:35]  * LucidFox pokes yamal
[09:35] <Hobbsee> heh
[09:38] <persia> jscinoz: Did you ever sort out the issues with urbanterror-data?
[09:42] <persia> 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] <asabil> okidoki thanks persia
[09:51] <asabil> dh_install: libgee-dev missing files (usr/include/gee-1.0/gee/*), aborting
[09:51] <asabil> anyone to help me with this please ?
[09:57] <asabil> sorry, got disconnected
[09:58] <persia> OK.  It's REVU Day again.  The keyring is synchronised.  The packages are waiting.  Let's clear them all!
[09:59] <persia> asabil: Sometimes dh_install gets confused.  Try debian/tmp/usr/...
[10:01] <LucidFox> persia> I'm going to email the qconf upstream about missing copyright headers, but I was wondering what action to take
[10:01] <persia> 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] <LucidFox> Yay!
[10:02] <LucidFox> 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] <Hobbsee> Olivier Prieur here?
[10:04] <Hobbsee> wolfger isn't either, it appears
[10:05] <persia> 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] <LucidFox> 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] <Hobbsee> Thorvald Natvig here?
[10:08] <Hobbsee> right.  revu cleaned out
[10:08] <persia> 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] <persia> Hobbsee: Thank you.
[10:09] <LucidFox> Looking at one REVU package, is it okay to have the Homepage field in the binary package section of debian/control?
[10:10] <persia> LucidFox: It should be in Homepage: unless there are (oddly) different homepages for different binaries.
[10:10] <LucidFox> yes, it is in Homepage:
[10:11] <LucidFox> but that line is in the binary package section
[10:11] <LucidFox> as a header
[10:12] <persia> 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] <asabil> persia: it worked :)
[10:15] <asabil> persia: now how can I bribe people to review it ? :D
[10:17] <persia> asabil: I recommend an announcement of the form "I've just uploaded $package, available for review at $url".
[10:18] <asabil> here ? on this channel ?
[10:18] <LucidFox> asabil> yes
[10:18] <asabil> I've uploaded libgee available for review at http://revu.tauware.de/details.py?package=libgee
[10:18] <asabil> :D
[10:18] <persia> 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] <asabil> oki
[10:20] <LucidFox> asabil> First, look at the lintian warnings
[10:21] <asabil> ok
[10:22] <rulus> 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] <geser> rulus: no, you need to check in which package the modules are and list them manually
[10:26] <jscinoz> persia, yes but i havn't gotten much/any feedback on the latest ones
[10:27] <rulus> geser: I only have to depend on that modules that aren't in the default Ubuntu installation?
[10:27] <persia> 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] <mok0> asabil: first round of comments for you
[10:28] <wallyweek> a small update to sdlmame, now waiting for reviews at http://revu.ubuntuwire.com/details.py?package=sdlmame
[10:29] <asabil> thanks mok0
[10:29] <geser> rulus: on every module package your package need
[10:30] <rulus> geser: ok, thanks for the info :-)
[10:30] <LucidFox> asabil> Added a review as well
[10:32] <geser> rulus: think e.g. of kubuntu (or any other customised ubuntu installation/ derivative) where the python gtk module can be not installed
[10:33] <geser> 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] <rulus> geser: aha, I understand
[10:38] <LucidFox> Hmm, I never heard of the Vala programming language, but it sounds very interesting.
[10:54] <asabil> LucidFox, mok0: when I fix all the issues, I should just dput again ?
[10:55] <asabil> no need to bump the version right ?
[10:55] <LucidFox> asabil> yes
[10:55] <LucidFox> no need to bump
[10:55] <asabil> oki thanks
[10:56] <LucidFox> asabil> triaged the needs-packaging bug
[10:57] <asabil> thanks
[10:58] <asabil> btw, concerning your 5th point
[10:58] <asabil> the Maintainer should be set to MOTU ?
[10:58] <asabil> and Original-Maintainer to me ?
[11:03] <LucidFox> asabil> yes
[11:03] <LucidFox> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[11:03] <LucidFox> XSBC-Original-Maintainer: Your Name <you@example.com>
[11:04] <asabil> ok thanks
[11:13] <rulus> 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] <asabil> hmmm, I uploaded a new revision, but it didn't seem to appear on the revu page :/
[11:15] <asabil> what did I do wrong ?
[11:15] <asabil> (I changed the package version from -0 to -0ubunt1
[11:16] <persia> asabil: Maybe just waiting for the refresh (happens every 10 minutes or so)?
[11:19] <LucidFox> rulus> debian/dirs is only needed if you cp something there, or deliberately want to have empty directories in the deb
[11:20] <LucidFox> if the upstream installer creates the directories it needs itself, debian/dirs is not needed
[11:20] <rulus> LucidFox: ok, thanks :-)
[11:25] <asabil> I think I fixed all the issues with my libgee upload
[11:26] <jonnymind> Hello.
[11:29] <jscinoz> persia, what should i be checking about it?
[11:31] <persia> 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] <jscinoz> how can i contact the admisn
[11:47] <persia> 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] <Hobbsee> persia: mithrandir might still be around on #u-d
[11:55] <persia> 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] <persia> \sh: Share?
[12:18] <\sh> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debianchangesfiles
[12:18] <jscinoz> ok thanks
[12:26] <aurax> elkbuntu you idiot :)
[12:31] <persia> elkbuntu always wins :)
[12:32] <elkbuntu> persia, he joined *every* channel i was in to get at me
[12:32] <elkbuntu> of course since i could only get rid of him from some, he got great thrills
[12:32] <elkbuntu> actually, the only ones unscathed were my loco channels :-/
[12:33] <jonnymind> 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] <jpatrick> elkbuntu: he got you in #u-es
[12:33] <jonnymind> currently 0.8.7 version is loaded.
[12:33] <jonnymind> Does it pose any problem if I just dput the new version?
[12:34] <elkbuntu> jpatrick, ah... he did get one of my loco channels then
[12:34] <persia> 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] <elkbuntu> not that it's my loco channel, im just in there to monitor the ascii genitalia gang
[12:34] <jpatrick> elkbuntu: where I prompty throw him out
[12:35] <elkbuntu> \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] <elkbuntu> \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] <Hobbsee> \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] <Hobbsee> \sh:
[12:42] <Hobbsee> 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] <PriceChild> 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] <Hobbsee> persia: bah humbug.  i cleaned up REVU.  that's my good deed for the day
[12:43] <elkbuntu> \sh, you're aware that doing that would exclude most of freenode's users... hence killing the network, right?
[12:43] <persia> Hobbsee: You get a pass for other reasons.  The three would be the other three members of the conversation.
[12:43] <Hobbsee> ahhh
[12:44] <Seveas> persia, cheat.
[12:44] <persia> Seveas: four!
[12:44] <Seveas> Hobbsee should do more revu, lazy ozzie woman
[12:44]  * Seveas should now run
[12:44] <Hobbsee> hah
[12:44] <Seveas> eek
[12:45] <persia> Seveas: conflict of interest.  Check +participation
[12:45] <Hobbsee> 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] <Seveas> Hobbsee, probably gary since he's the default victim
[12:46] <elkbuntu> \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] <elkbuntu> \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] <Hobbsee> elkbuntu: this is a problem?
[12:49] <Seveas> 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] <elkbuntu> Hobbsee, the french might think so
[12:50] <persia> Erm.  OK.  Next person to talk about IRC without first reviewing a package gets a frown!
[12:50] <elkbuntu> 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] <elkbuntu> 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.
[12:59] <jonnymind> persia: thank you, I get it. No, there isn't any comment nor advocation yet.
[13:00] <persia> 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] <jonnymind> k
[13:01] <jonnymind> I'll do that in minutes then.
[13:12] <jonnymind> persia: we have a zlib module that may be optionally built using the system zlib.
[13:13] <jonnymind> 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] <jonnymind> \sh: ack
[13:16] <\sh> jonnymind, another point: no duplicated sources in the archives
[13:16] <jonnymind> \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] <jonnymind> Ah, ok. So I can do this in my local ubuntu copy while packing, right?
[13:18] <jonnymind> np for that.
[13:21] <the_belgain> hi - i'm getting the following lintian errors on my package: http://pastebin.ubuntu.com/3705/
[13:21] <the_belgain> do i need to be splitting this package into separate "fuppes" and "libfuppes" packages here, or is it still acceptable for both the program and the library to be in the same package?
[13:21] <StevenK> the_belgain: The first error is caused by not calling dh_makeshlibs in your rules file
[13:22] <StevenK> the_belgain: Well, are other things going to link against the library?
[13:22] <the_belgain> no
[13:23] <\sh> jonnymind, yepp...
[13:26] <the_belgain> StevenK: looks like adding a call to dh_makeshlibs will get rid of the first two errors - how about the third?
[13:26] <StevenK> the_belgain: Then I think the last error can be ignored
[13:27] <the_belgain> should the error be explicitly overrided in some way, or just left in place?
[13:27] <StevenK> Not sure about that
[13:29] <the_belgain> a couple of other questions - the package doesn't currently have a man page.  there isn't any such documentation in the upstream release; is it normal to just suggest the upstream author adds some documentation, or should some docs be added that are specific to the ubuntu package?
[13:30] <the_belgain> it feels like the package maintainers aren't going to be best-placed to keep eg. a manpage up to date with new releases
[13:30] <asabil> I've uploaded a new revision for libgee package available for review at http://revu.tauware.de/details.py?package=libgee
[13:30] <broonie> the_belgain: Ideally a man page would be written and contributed upstream.
[13:31] <the_belgain> would the absense of a manpage in the meantime prevent a package being accepted into multiverse?
[13:31] <broonie> Very unlikely.
[13:31] <the_belgain> ok, thanks
[13:32] <the_belgain> i'll just request one upstream then
[13:34] <the_belgain> another question - i'd like to add an init script for the program in this package; again done is included in the upstream release.  i probably wouldn't want this to be enabled by default - is there a way to easily add an init script and have it enabled / disabled through the System -> Administration -> Services menu?
[13:45] <tbutter> I uploaded a new version at http://revu.tauware.de/details.py?package=jodviewer fixing the things mentioned by persia and bddebian. Linda still tells me it uses a wrong (too high) standards version. Is the linda on revu an older version or is it a bug in my package?
[13:48] <amarillion> tbutter, I get that too
[13:48] <amarillion> linda on revu is outdated
[13:48] <amarillion> You should be using standards version 3.7.3 IIRC
[13:48] <tbutter> thanks amarillion
[14:07] <jonnymind> soren: people, I am sorry to bring up the topic again, but this is a thing that should be issued peacefully.
[14:08] <jonnymind> soren: sorry, wrong nick
[14:08] <jonnymind> Seveas: people, I am sorry to bring up the topic again, but this is a thing that should be issued peacefully.
[14:08] <jonnymind> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460618
[14:08] <ubotu> Debian bug 460618 in wnpp "ITP: falcon -- Repository manager for .deb packages" [Wishlist,Open]
[14:09] <frafu> persia: A few weeks ago, you reviewed mousetweaks on revu. If you have time, could you (or any other reviewer) please review the new version that I uploaded yesterday.
[14:09] <jonnymind> have you resolved the /usr/bin/falcon nameclash before submitting the package to debian?
[14:12] <frafu> In fact, the graphical user interface of mousetweaks is present in the Mouse control panel since GNOME 2.21.5 and it would be odd to have the gui in hardy, but not the module providing the new functions present in the Mouse control panel.
[14:13] <jonnymind> This is a quite relevant topic, and has also some legal aspect of non-secondary importance. I'd like to discuss this peacefully.
[14:40] <bddebian> Heya gang
[14:41] <geser> Hi bddebian
[14:42] <bddebian> Heya geser
[14:42] <rexbron> persia: iirc, policykit does not have python bindings at the moment, and  I do not want to have to rewrite the app in C++
[14:44] <rexbron> persia: as for the native package thing, I would happily release a source tarball for any other distros that do not use debs, but it is easier for me to develope/maintain with the debian info in the same branch. If you run setup.py sdist, it builds a tarball without any of the vcs or debian files
[15:20] <somerville32> If anyone is interested, please review thunar-svn-plugin: http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
[15:20] <andi5> hi... please excuse my novice question :-) ... how should i start pbuilder (or even what else should i use) to create a minimal (chroot) environment to build a package that will fail to build without pbuilder removing the build directories afterwards? i would like to take a look into that ... thanks in advance!
[15:24] <frafu> andi5: the following page might help:  https://wiki.ubuntu.com/PbuilderHowto
[15:25] <DRebellion> I have upstream source downloaded from the author's website but it is in .zip format. What procedures do I need to do if I am to convert it to .tar.gz ??
[15:27] <DRebellion> Should I simply convert it or do I have to note down somewhere that I have?
[15:28] <andi5> frafu: that is a long page, but i do not find anything that answers my question for me :-( (i have tried to read it before i asked)
[15:28] <broonie> pbuilder login might be what you're looking for.
[15:29] <broonie> There's some other ways to do it in the docs in the pbuilder package.
[15:30] <rulus> I updated my gtkvd package earlier today (http://revu.tauware.de/details.py?package=gtkvd). If someone has time for a review, that would be great :)
[15:30] <andi5> broonie: i.e. i would use pbuilder login --bindmounts and use X then, where X is ... pdebuilder, dpkg-buildpackage, ...?  thanks!
[15:31] <broonie> dpkg-buildpackage
[15:31] <andi5> ah, cool
[15:31] <andi5> broonie: thanks a lot :-)
[15:32] <civija> DRebellion: you can just open .zip file in file-roller and save it as .tar.gz
[15:33] <DRebellion> civija: ok, just checking
[15:33] <broonie> DRebellion: Probably worth putting a note in saying what you'v done (in the copyright file probably)
[15:34] <civija> isn't changelog better place to note that?
[15:37] <DRebellion> should the .tar.gz packages be in the format - <packagename>_<version>.tar.gz or <packagename>-<version>.tar.gz ?
[15:39] <frafu> andi5: install pbuilder and the other modules indicated on that page; create the pbuilder environment with sudo pbuilder create; to build the package, use sudo pbuilder build  softwarename.dsc . To create the *.dsc file, you have to debianize (=create a debian directory with a few control files in your package ) your package and call debuild -S.   Here you can read how to debianize a package: http://doc.ubuntu.com/ubuntu/packagingguide
[15:40] <andi5> frafu: i am testing an ubuntunized package already and my problem is more about failing builds than setting up pbuilder at all :-)
[15:41] <geser> andi5: in such cases I login into pbuilder and build the package there with dpkg-buildpackage -b
[15:42] <frafu> andi5: sorry for getting you wrong
[15:42] <andi5> geser: yep, that is what broonie suggested as well... so i will most definitely go that way, thanks :)
[15:42] <wallyweek> hi all!
[15:43] <wallyweek> anyone could please have a look at http://revu.ubuntuwire.com/details.py?package=sdlmame
[15:50] <foxmike> Hi!  I'm looking into backporting f-spot, but that would mean backporting cli-common from the hardy version.  Does anyone here knows if this is safe to do, or may it break the system?
[15:57] <LucidFox> foxmike> cli-common doesn't need to be backported
[15:57] <LucidFox> (I think)
[15:57] <LucidFox> f-spot should run fine with the old cli-common, I know because I built it on Gutsy
[15:58] <jdong> foxmike: locally, it should be a fairly safe thing to do to your own system
[15:58] <LucidFox> foxmike> Just make sure to build against bundled mono-addins and libflickrnet, as they were only promoted to main in hardy
[15:58] <LucidFox> And I wholly support backporting f-spot.
[15:58] <foxmike> LucidFox: well, f-spot 0.7.1 has libflickrnet as dependency, which in turns has cli-common =>0.5.6 as dependency.
[15:58] <foxmike> (as I understood it...)
[15:59] <LucidFox> 0.7.1?
[15:59] <LucidFox> foxmike> libflickrnet is in universe in gutsy
[15:59] <foxmike> stand-by, I'm looking back my infos...
[15:59] <LucidFox> and f-spot is in main
[15:59] <LucidFox> to backport 0.4.1 to gutsy, you will need to drop meebey's changes from Debian and build it against bundled libflickrnet again
[16:03] <foxmike> LucidFox: Ok thanks, I did not found libflickrnet in gutsy yet (was looking in main I think)  Thanks for the info!
[16:03] <foxmike> And I meant f-spot 0.4.1 (typo...)
[16:03] <LucidFox> foxmike> And while you're at it... against bundled mono-addins as well
[16:04] <LucidFox> mono-addins is in universe in gutsy
[16:05] <foxmike> LucidFox: this would be my very first backport (and packaging experience) and I am not sure what do you mean by "building against mono-addins".  Does it needs to be added to the build-dependencies?
[16:05] <LucidFox> foxmike> On the contrary, my dear Watson - remove them from build-dependencies!
[16:05] <LucidFox> Both mono-addins and libflickrnet
[16:06] <LucidFox> you will also need to drop certain patches, let me see which ones
[16:06] <foxmike> ok great!
[16:07] <LucidFox> foxmike> forward_port_to_flickrnet_2.1.5 and link_system_libs
[16:07] <LucidFox> make sure to also remove them from 00list
[16:08] <LucidFox> or remove them _just_ from 00list so they're there but inactive
[16:08] <LucidFox> and from debian/control, remove libflickrnet2.1.5-cil, libmono-addins0.2-cil and libmono-addins-gui0.2-cil
[16:11] <foxmike> LucidFox: I'm done with debian/control, and I'll give you some feed back concerning 00list, thanks for your help!:)
[16:15] <foxmike> LucidFox: does "40_flickr-export-crash" should be removed from 00list as well?
[16:15] <LucidFox> no
[16:15] <foxmike> ok, thanks
[16:16] <mok0> how can I create a new page on the wiki?
[16:17] <mok0> I can delete pages, but not create them ;-)
[16:17] <stgraber> just enter the URL you want and click on create the page (or something like this)
[16:17] <stgraber> Create new empty page that's
[16:18] <mok0> stgraber: heh, cool.
[16:21] <rexbron> if anyone is interested in getting a head start on revu day, take a look at http://revu.ubuntuwire.com/details.py?package=ubuntustudio-controls . Thanks!
[16:24] <amarillion> Can someone point me to some good docs explaining the use of hyphens in man files?
[16:24] <amarillion> This comes up a lot in reviews yet I can't find documentation for it
[16:26] <emgent> hello people
[16:28] <tbutter> amarillion, maybe this: http://lists.debian.org/debian-devel/2003/03/msg01481.html
[16:29] <geser> amarillion: in UTF-8 there is a difference between - like in --option (\- in manpages) and - like in "two-sided" (- in manpages). Especially in options it's importaant to use the correct one else the searching for it inside the manpage gets harder as the '-' key matches \- in manpages.
[16:30] <amarillion> geser, ok, but which one should I use on the NAME line?
[16:31] <amarillion> (so the whatis info is still correct)
[16:31] <emgent> omg big error in wordpress :P
[16:32] <emgent> default options:
[16:32] <emgent> Name	URL	Categories	rel	Visible	Action 	
[16:32] <emgent> Planet Debian
[16:32] <emgent> 	planet.ubuntu.com	Blogroll 		Yes	Edit	Delete	
[16:32] <emgent> it'snt debian planet, this is ubuntu planet :P
[16:32] <emgent> i go to fix
[16:39] <frafu> Could anybody please review the following package: http://revu.tauware.de/details.py?package=mousetweaks  ? I hope that mousetweaks will make it into hardy as its gui has been integrated into GNOME since GNOME 2.21.5.  Thanks
[16:41] <foxmike> LucidFox: ok it builds well now, I had to change the version number of libndesk-dbus-glib1.0-cil (>= 0.3.0) to libndesk-dbus-glib1.0-cil (>= 0.3-0) as the version installed on gutsy is 0.3-2.  Thanks again for your help!
[16:46] <LucidFox> foxmike> excellent, looking forward to seeing the backport in gutsy
[16:58] <asabil> LucidFox: would it be possible to ask you to review my new libgee package please ?
[16:58] <LucidFox> asabil> I'm not a MOTU
[16:58] <ScottK> Good morning all.
[16:58] <LucidFox> so I can't advocate it anyway
[16:58] <asabil> oh oki
[16:58] <ScottK> LucidFox: But you can give him good feedback and maybe when I MOTU does have time, it gets advocated on the first try.
[16:58] <imbrandon> moins ScottK
[16:59] <LucidFox> ScottK> I already reviewed it once :)
[16:59] <ScottK> Ah.
[16:59] <ScottK> heya imbrandon
[17:02] <ScottK> mok0: Had any luck with avscan?
[17:02] <ScottK> mok0: I think your packaging is looking quite good.  I advocated both of your packages I looked at.
[17:03] <mok0> ScottK: did you see my mail?
[17:03]  * ScottK looks
[17:03] <mok0> ScottK: thanks!
[17:04] <amarillion> REVU needs double-post protection
[17:04] <amarillion> just for kicks, post a comment and press F5 :)
[17:05] <ion_> I don’t understand why webapp developers keep on making programs that directly respond to POST with the resulting page.
[17:06] <ScottK> mok0: I don't seem to find it.
[17:06] <mok0> I sent it to kitterman etc
[17:06] <ScottK> amarillion: The code is on Launchpad.  Patches gratefully accepted.
[17:06] <ScottK> mok0: What was the subject?
[17:06] <amarillion> ok :)
[17:07] <mok0> "avscan woes" :-)
[17:07]  * ScottK looks again.
[17:07] <amarillion> Looks like my package hit a snag
 "alex4 hangs (on AMD64) when starting the game. :-/"
[17:07] <mok0> Scott: sent it to yourfirstname@yourlastname.com
[17:08] <ryanakca> james_w: ping, would you mind testing bzr_1.1-1 on hardy alongside bzr-buildpackage, before I file a sync request?
[17:08] <ScottK> mok0: Right.  I don't seem to have it.  Either in my inbox of my spam folder.
[17:08] <ScottK> mok0: When did you send it?  I greylist, so it could still be in transit.
[17:09] <mok0> ScottK: about 1 hr ago
[17:09] <ScottK> OK.  Depending on your mail server's retry delay, it may be in the air still.
[17:09] <mok0> ScottK: http://paste.ubuntu.com/3711/
[17:10] <ScottK> mok0: Thanks
[17:10] <james_w> ryanakca: sure. I'll get to that in a moment. Thanks for the prod.
[17:11] <ScottK> mok0: I had to make some changes in the clamav packaging to get 0.92 to build on Dapper.  The most extreme change I had to make was to force it to use GCC 3.4.
[17:12] <ryanakca> james_w: kk, thanks :)
[17:12] <ScottK> I didn't have to patch any of the actual code though.
[17:12] <mok0> ScottK: how was the avscan patch made?
[17:13] <mok0> I see the same mods in the feisty version
[17:13] <ScottK> mok0: I took that patch from the feisty avscan and tried to make the same/similar changes to the dapper version.
[17:13] <mok0> ScottK: Aha
[17:13] <ScottK> mok0: Since some of the code had changed, the patch didn't apply cleanly.
[17:14] <smarter> hi
[17:14] <ScottK> mok0: So I'm thinking I missed the definition of something somewhere.
[17:14] <mok0> ScottK: that must be the source of the problem. As I said the other day, the patched code seems to be a mixture of two API's
[17:14] <smarter> can someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer
[17:15] <ScottK> mok0: Since you actually understand C code, you might (would probably) find it easier to start over with the feisty patch and that dapper avscan and see if you can integrate them in a sensible way.
[17:16] <mok0> ScottK: I was trying to do just that, but kept running into some other dependency problem
[17:18] <mok0> ScottK: Is your backported version of clamav working ok on dapper?
[17:18] <ScottK> mok0: Yes
[17:18] <ScottK> It works well with all the other applications I've tested it with.
[17:18] <mok0> ScottK: great.
[17:19] <ScottK> I think I'm very close to being ready to do the backport, but I'd like to find a way to solve the avscan problem.
[17:20] <mok0> ScottK: I will take a closer look at the code tomorrow.
[17:20] <mok0> ScottK: I need to make dinner for the family shortly :-)
[17:20] <ScottK> mok0: Thank you.  There's no way I can solve this, so I'm dependent on help.
[17:20] <ScottK> Understand.
[17:21] <mok0> ScottK: I hope I can help
[17:21]  * ScottK too
[17:25] <yamal> MOTUs, an improved sabnzbd package is awaiting review @ http://revu.tauware.de/details.py?package=sabnzbdplus
[17:25] <amarillion> speed-game is ready for review as well: http://revu.tauware.de/details.py?package=speed-game
[17:26] <mok0> Scott, incidentally, is there a reason not to use the newest avscan version 3.1.1? It's clamav dependency is the same (0.90.1) it seems
[17:26] <amarillion> Could anyone who is on AMD64 help me confirm a bug in alex4? http://revu.tauware.de/details.py?package=alex4
[17:26] <ScottK> mok0: It needed the newer endeavour, which needed some other stuff, and from there it got ugly.  I tried that first.
[17:26] <amarillion> According to danielh it hangs on start but I can't confirm it
[17:27] <mok0> ScottK: I was able to compile feisty's endeavour on dapper
[17:27] <mok0> but perhaps thats not new enough?
[17:27] <ScottK> mok0: Let me look into that then.  I don't think I tried that.
[17:36] <rzr> http://www.vnunet.com/vnunet/news/2207369/microsoft-patents-employee
[17:38] <albert23> amarillion: I can confirm alex4 hangs on amd64 when you start a game.
[17:38] <amarillion> albert23, thanks
[17:39] <albert23> amarillion: no problem
[17:39] <amarillion> dang... this is going to be hard
[17:41] <amarillion> albert23, are you on hardy?
[17:41] <albert23> amarillion: Yes, I am
[17:43] <ScottK> mok0: The irony in this is I hadn't looked at the Feisty version and now that I have, I find I'm the one that uploaded it.
[17:44] <mok0> ScottK: no wonder, considering the amount of uploads you have...
[18:00] <lucas> geser: around?
[18:00] <lucas> geser: when you submit patches about dash-related build failures to debian, it would be great if you could turn them into ready-to-upload NMUs
[18:01] <lucas> that way, I can just apply your patch and upload, and you get credited as the NMUer, instead of me
[18:04] <ScottK> lucas: I gather that's generally true, and not just for geser?
[18:04] <ScottK> I just fixed one here the other day that needs to be dealt with in Debian.
[18:05] <lucas> ScottK: yes. I just noticed that geser filed a lot of those
[18:05] <lucas> I'm trying to fix all those bugs in debian, so better patches are easier for me :-)
[18:06] <ScottK> lucas: If I prepared an NMU to fix a debian/rules bashism and also fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392927, would you sponsor that?
[18:06] <ubotu> Debian bug 392927 in libspf0 "Spfmilter dies unexpectedly with SIGABRT" [Grave,Open]
[18:06] <ScottK> or should I just fix the bashism?
[18:07] <jonnymind> I have removed sources for zlib and so on from the orig package, and I got this warning from dpkg-buildpackage
[18:07] <jonnymind> dpkg-source: warning: ignoring deletion of file modules/feathers/zlib/zlibstream.cpp
[18:07] <jonnymind> and so on. Is this ok?
[18:11] <james_w> jonnymind: it means that the files won't actually be deleted.
[18:11] <jonnymind> Uhm... and is this good or bad?
[18:11] <lucas> ScottK: ok, you can fix both
[18:11] <ScottK> OK
[18:12] <lucas> for #392927, please include a summary of the problem and the fix in the changelog
[18:12] <amarillion> jonnymind, it's easiest just not to delete them
[18:12] <lucas> reading the bug log, the fix is only a good-enough workaround?
[18:12] <james_w> jonnymind: if you really need to get rid of them then repack the upstream tarball. Otherwise you could just leave them there. The important thing is that the files are not used when building.
[18:12] <lucas> ScottK: please use dch --qa
[18:12] <ScottK> lucas: will do
[18:12] <jonnymind> Ah, ok: I was told earlier to remove them as they are duplicate of sources stored also elsewhere.
[18:13] <lucas> and set Maintainer to: Debian QA Group <packages@qa.debian.org>
[18:13] <lucas> and remove the Uploaders
[18:13] <amarillion> jonnymind, yeah I'm confused about that too
[18:13] <james_w> jonnymind: yeah, you want to avoid using them when building to stop creating extra work for the security team etc. However having them in the tarball isn't necessarily bad.
[18:13] <geser> lucas: will remember for the next time
[18:14] <amarillion> in the docs you read everywhere that it's bad form to repack the upstream tarball
[18:14] <jonnymind> In that case, I will leave there. They are optionally used in compilation (useful on those platform that doesn't provide a compatible package).
[18:14] <amarillion> probably best
[18:16] <james_w> amarillion: it is usually preferred to avoid it where possible, but it's not always avoidable.
[18:28] <Dabian> Hiaya!   I just apt-got source for evolution.  However, GDB seems to point to the wrong line.  Is there a hard way to fix that, or even better, a fairly easy way?
[18:34] <jonnymind> ScottK: Ok, new release of falconpl up in seconds.
[18:35] <jonnymind> I am adding download section to the site right now, so uscan will report version missing for a while
[18:38] <wallyweek> hello!
[18:40] <jonnymind> Ops, I forgot a small detail.
[18:42] <wallyweek> anyone willing to review my package, please? :D  http://revu.ubuntuwire.com/details.py?package=sdlmame
[18:55] <jonnymind> Done. -- the official Falcon Programming Langauge 0.8.8 package is up, and the ubuntu falconpl is at BUG 174470
[18:55] <ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[19:08] <Flare183> Search Bugs for Nemo
[19:08] <Flare183> can some one explain to me how to use "install"?
[19:25] <gladier> ey guys - im packaging something up and get this message "dpkg-checkbuilddeps: error: control file must have at least one binary package part" along with "dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting."
[19:26] <james_w> gladier: the first message indicates that your debian/control is not well-formed.
[19:26] <james_w> The second indicates that you need to install some more packages.
[19:26] <gladier> ...
[19:26] <gladier> into my local system?
[19:27] <gladier> onto*
[19:27] <james_w> I can help you correct the first error if you pastebin your control file.
[19:27] <james_w> gladier: yes, indeed.
[19:28] <gladier> http://nopaste.ch/df65f93afaaaa8d.html
[19:29] <james_w> gladier: there is no Version: field, so you should remove that line.
[19:30] <james_w> The other issue is that there is no blank line before the Package: line.
[19:30] <james_w> The parser uses the blank lines to break the file up in to sections.
[19:30] <gladier> ok i spose this drops down to .. what way is best to build a deb?
[19:30] <gladier> thered dpkg -b and dpkg-buildpackage -rfakeroot
[19:31] <gladier> both seem to need files organised differently
[19:31] <james_w> gladier: definitely the latter. You can do the former, but the latter is far, far easier.
[19:32] <gladier> whats the diff?
[19:32] <gladier> ive always had trouble with dpkg-buildpackage -rfakeroot
[19:33] <james_w> dpkg -b is the low level assembly of the .deb itself from the compiled files etc. dpkg-buildpackage uses debian/rules etc. to actually build the package.
[19:33] <gladier> hum ... another wierdness .. i can compile the source manually but throw it through dpkg-buildpackage and it dont work .. *sigh*
[19:35] <james_w> gladier: do you want help to diagnose the issue, or was that just a throwaway comment?
[19:35] <gladier> i dont know lol
[19:35] <gladier> mayaswell learn something and have a hand fixing it
[19:36] <gladier> otherwise it would be a dpkg -b
[19:37] <gladier> james_w: this is the dpkg-buildpackage output
[19:37] <gladier> http://pastebin.com/d4697bf58
[19:40] <james_w> gladier: could the segfault be because of WARNING **: Could not load file or assembly 'Mono.Cairo,?
[19:40] <gladier> i just saw that
[19:42] <gladier> make[1]: *** No rule to make target `Ubuntu'.  Stop.??
[19:42] <james_w> gladier: what did you run?
[19:43] <gladier>  dpkg-buildpackage -rfakeroot
[19:44] <james_w> gladier: and so do you have a call to 'make Ubuntu' in debian/rules?
[19:44] <gladier>         $(MAKE) DESTDIR=$(CURDIR)/debian/oessysmon install
[19:44] <gladier> thats it
[19:45] <gladier> which pulls out to /usr/bin/make DESTDIR=/home/gladier/Novell Ubuntu Repository/Ebuild/app-admin/oessysmon/oessysmon-0.1.6/debian/oessysmon install
[19:45] <james_w> gladier: you need
[19:46] <james_w>         $(MAKE) DESTDIR="$(CURDIR)"/debian/oessysmon install
[19:46] <james_w> or
[19:46] <james_w>         $(MAKE) DESTDIR="$(CURDIR)/debian/oessysmon" install
[19:46] <gladier> of course
[19:47] <gladier> its now a happy little vegemite
[19:48] <gladier> ^^ cant tell im an aussie
[19:49] <gladier> also incase your wondering - im busy getting all of the novell linux stuff from suse -> ubuntu via the n4g Gentoo overlay
[19:51] <LucidFox> This is so annoying, KMail is one of the last two remaining KDE3 applications I still use and I can't replace it :(
[19:51] <LucidFox> Evolution, Sylpheed and Claws-Mail are all ugly and cluttered
[19:52] <smarter> try thunderbird
[19:52] <gladier> groupwise :)
[19:53] <gladier> mozilla products -> bin
[19:53] <LucidFox> gladier> groupwise?
[19:53] <ScottK> LucidFox: KDE4 version is coming soon.
[19:53] <gladier> that free novell thing which does contacts / email (pop/imap/groupwise) / calander
[19:54] <LucidFox> gladier> It's not free, it's proprietary
[19:54] <gladier> its free .. just not open source
[19:54] <gladier> the client is free
[19:54] <LucidFox> It's not free software.
[19:54] <gladier> the server is a totally differnet matter
[19:55] <gladier> but the client is free ... garunteed
[19:56] <LucidFox> As I said, it's not free as in "free software". It's "free" in the sense that it's zero-cost.
[19:56] <LucidFox> But it's proprietary.
[19:56] <gladier> its closed source yes
[20:07] <jonnymind> People, I would really appreciate some early comment on BUG 174470 before the REVU session of tomorrow.
[20:07] <ubotu> Launchpad bug 174470 in ubuntu "[needs-packaging] Falcon Programming Language" [Wishlist,In progress] https://launchpad.net/bugs/174470
[20:08] <\sh> yawn
[20:08] <\sh> why is debmirror not mirroring the Release{.gpg} file?
[20:10] <asabil> any MOTU willing to review a package please ?
[20:11] <\sh> emgent, ping phpbb2 is there already a CVE pending for this XSS ?
[20:11] <\sh> emgent, or did you request it?
[20:47] <rexbron> Anyone looking to get a head start on revu day? Please take a look at http://revu.tauware.de/details.py?package=ubuntustudio-controls . Thanks!
[20:51] <geser> rexbron: the revu day started hours ago
[20:51] <rexbron> geser: timezones
[20:52] <Seveas> geser, he loves spamming his package :)
[20:52] <rexbron> O.o
[20:52] <rexbron> got to get it out there some how
[20:52] <rexbron> rock out, with your... source package...
[20:53] <jonnymind> Oh, so this is ALREADY revu day?
[20:54] <jonnymind> in this case
[20:54] <jonnymind> http://revu.tauware.de/details.py?package=falconpl it's now up and stable.
[20:54] <jonnymind> ready for REVU.
[21:14] <james_w> ryanakca: hi. I'm happy to have bzr-builddeb synced, as long as bzrtools is as well.
[21:15] <james_w> ryanakca: there is one test failure, but that is a problem with the test rather than the plugin. It will require a source change to fix, I will try and release that soon.
[21:17] <ryanakca> james_w: ok, so sync bzr, bzr-builddeb and bzrtools?
[21:19] <emgent> heya
[21:19] <ryanakca> hey emgent
[21:20] <james_w> ryanakca: yeah, I'd say, and bzr-gtk too probably.
[21:20] <ryanakca> james_w: ok, will do
[21:25] <Kmos> that's already requested i think =)
[21:25] <Kmos> so it will be done next week
[21:26] <ryanakca> Kmos: okies :)
[21:32] <james_w> ryanakca: oh, and bzr-svn as well of course.
[21:33] <ryanakca> james_w: *nods*
[21:43] <asabil> any MOTU with some free time wanna check this again please : http://revu.tauware.de/details.py?package=libgee ?
[21:54] <ScottK> mok0: I got the same build problem with the avscan from Feisty.  Not sure what to do next.
[21:55] <ScottK> I uploaded the Feisty endeavour to the ubuntu-clamav PPA for dapper and it built just fine.
[21:56] <ScottK> So at least the build-deps are there now.
[21:58] <ScottK> mok0: It does, however build against Feisty's clamav in a Feisty environment.  Urgh.
[22:01] <ScottK> mok0: Finally got your mail, too.
[22:01] <mok0> ScottK: good
[22:03] <mok0> ScottK: I will try to debug avscan tomorrow, and se what needs to be done to link it against the new clamac
[22:03] <mok0> s/ac/av
[22:08] <ScottK> mok0: Thanks.
[22:20] <rulus> If anyone has time to review http://revu.tauware.de/details.py?package=gtkvd, please do! :)
[22:25] <pochu> bigon`: will you request a sync for d-feed? would be nice to have it in Ubuntu too :)
[22:27] <geser> pochu: you mean d-feet? see bug #184344
[22:27] <ubotu> Launchpad bug 184344 in ubuntu "Please sync d-feet 0.1.8-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/184344
[22:30] <pochu> geser: right, typo. Thank you.
[22:31] <jonnymind> pochu: hello.
[22:35] <pochu> hi jonnymind
[22:35] <jonnymind> :-)
[22:54] <jdong> sourceforge bug 1495942
[22:54] <ubotu> Sourceforge bug 1495942 "MP4Box crash at raw MPEG4 (A)SP import CVS20060527" [Pri: 5,Closed fixed] http://sf.net/support/tracker.php?aid=1495942
[22:54] <jdong> aww.
[22:54] <jdong> ok
[23:04] <crimsun> ok, u-u-s queue time.
[23:04] <crimsun> cd
[23:04] <wallyweek> could anyone please review my package? Thanks :D  http://revu.ubuntuwire.com/details.py?package=sdlmame
[23:05] <bddebian> wallyweek: Any luck with the home dir thing?
[23:05] <jdong> crimsun: do you do the u-m-s queue too?
[23:05] <emgent> heya
[23:05] <wallyweek> bddebian: it works for me. I tried several different configs
[23:06] <bddebian> Hmm, OK
[23:07] <jdong> crimsun: because I'd love to find someone to sponsor bug 182653 :)
[23:07] <ubotu> Launchpad bug 182653 in transmission "Please update to 1.01" [Wishlist,Confirmed] https://launchpad.net/bugs/182653
[23:07] <wallyweek> bddebian: don't mean to bother, but are your sure about the dot in ~/.mame/roms ? <blushing>
[23:13] <asabil> can someone review my package please : http://revu.tauware.de/details.py?package=libgee
[23:13] <asabil> thanks
[23:20] <crimsun> jdong: done.
[23:22] <crimsun> hmph, .ubuntu.com is quite sluggish over my route.
[23:25] <\sh> could be me, mirroring all the day ;)
[23:29] <\sh> damn..this django is addictive
[23:30] <somerville32> \sh: Do you think you could pull yourself away to do a quick review inbetween now and the next game? :]
[23:30] <\sh> somerville32, it's not a game...it's python rails ;)
[23:30] <\sh> somerville32, give me the url :)
[23:30] <somerville32> http://revu.ubuntuwire.com/details.py?package=thunar-svn-plugin
[23:31] <somerville32> :)
[23:31] <geser> \sh: turbogears is also very nice
[23:34] <\sh> geser, I'm coding on "poor mans build service" , well the name is crap I know, but "duk" was also stupid ;) with django as framework in front of the scenes with some xmlrpc stuff etc. import of source files and checking the sigs etc is just finished
[23:34] <\sh> s/mans/men's/
[23:35] <emgent> heya \sh
[23:35] <emgent> :P
[23:36] <\sh> hach...what was the login scheme to revu? LP accounts?
[23:36] <geser> \sh: similar to the opensuse build service?
[23:36] <\sh> geser, yeah, but with debian inside, well hopefully I'll come so far that I can implement RPM building on debian systems ;)
[23:37] <\sh> bah...
[23:37]  * \sh doesn't have any revu powers anymore
[23:37] <somerville32> \sh: You just use your launchpad id and the password they provide
[23:37] <persia> \sh: If you've not been using REVU recently, try the email address from an upload you made in September or so.
[23:38] <somerville32> s/launchpad id/e-mail you used to upload
[23:38] <persia> somerville32: It'S not related to LP id.
[23:38] <\sh> No REVU account for sh@sourcecode.de exists yet.
[23:38] <persia> \sh: Check the other accounts on your key
[23:38] <\sh> persia, my old one is not working either
[23:39] <crimsun> you're probably experiencing the same symptoms I had.
[23:40] <\sh> do i need as a reviewer to be member of this contributor group on LP
[23:40] <persia> Are there any other REVU admins around?  I am about to leave, and would really appreciate it if someone else could enable a reviewer account for \sh.
[23:40] <persia> \sh: You get that from MOTU anyway
[23:40] <geser> \sh: ask an revu admin to create an account for you
[23:41] <\sh> geser, how is admin? siretart, sistopy , persia and?
[23:42] <\sh> well, it's still time ... the new day is only 42 minutes old
[23:42] <effie_jayx> what script can I use for updating the mantainer field }
[23:42]  * persia does it
[23:43] <geser> effie_jayx: there is a script in ubuntu-dev-tools for it
[23:43] <\sh> effie_jayx, update-maintainer from the ubuntu-dev-tools package
[23:43] <wallyweek> it's late... g'night all!
[23:43] <\sh> persia, thx
[23:44] <\sh> effie_jayx, or you can use something like this: http://pastebin.ubuntu.com/3730/
[23:44] <\sh> effie_jayx, push it to ~/bin then :)
[23:44] <\sh> and start it in the debianzed source tree
[23:44] <\sh> quick hacks
[23:45] <effie_jayx> thanks guys
[23:45] <persia> \sh: I won't be able to watch the keyring sync, but you ought to be able to recover your password in 20-30 minutes.
[23:45] <\sh> persia, thx
[23:46] <persia> Oh.  Account is for the email address you complained about first.
[23:46] <\sh> persia, sourcecode.de?
[23:48] <geser> \sh: your script missed those packages which use a debian/control.in file
[23:48] <\sh> geser, yeah
[23:49] <\sh> geser, as I said a quick hack...but good to learn