[06:50] <eddyMul> persia: just adding check:: doesn't seem to do the trick. hm...
[06:52] <persia> eddyMul: CDBS only checks for check with makefile.mk.  You might want something different for setup.py.  If it's not obvious, you can always brute-force with build/django:: (or whatever).
[06:54] <eddyMul> persia: I'm trying to sort out the sequence of events...
[06:55] <eddyMul> persia: ideally, the check should be performed... after building, before installing....
[06:55] <eddyMul> persia: (maybe?)
[06:57] <persia> eddyMul: CDBS uses makebuilddir, configure, build, install, binary by defaul, and processes overrides after the internal rules, so if you have a build:: override, it should run between build and install, which is a standard place to test.  For some tests, between install and binary may be better (it depends on the tests).
[06:59] <eddyMul> persia: thanx. I'll try with build/django::   (now the buildcore.mk target "depgraph" makes more sense...)
[07:01] <Hobbsee> persia: did you know if it was for *all* metapackages, or just -desktops ?
[07:01] <eddyMul> persia: the target is executed. Now, I'll work on having the tests run properly. I plan to steal code from Gentoo's ebuild (is that "lega"?)
[07:01] <eddyMul> s/lega/legal/
[07:01] <persia> Hobbsee: I didn't check.  Do you want me to look at the code again?
[07:02] <Hobbsee> persia: if it wont take you long, looking would be good
[07:02] <Hobbsee> persia: i may well have screwed up this code, but it is actually coming out correctly, i think
[07:02] <persia> eddyMul: Depends on the license (and I know nothing about Gentoo licensing).  Also, you may get more informative responses (read: not limited by my knowledge) by asking the channel generally, rather than just me.
[07:02] <persia> Hobbsee: redownloading the code now...
[07:04] <persia> Hobbsee: The only reference seems to be "debian/apt.conf.autoremove:  Install-Recommends-Section "metapackages";" (which I think ends up in /etc/apt.conf.d/).  I'm interpreting this as looking at the section only, and ignoring the name of the package.
[07:04] <Hobbsee> fair enough
[07:06] <eddyMul> persia: the Gentoo ebuild is GPL v2
[07:07] <persia> eddyMul: OK.  What license covers each of python-django and the Ubuntu packaging?
[07:07] <eddyMul> where can I find the Ubuntu package's license?
[07:07] <persia> eddyMul: It should be listed in debian/copyright
[07:08] <eddyMul> no "generic" license detected
[07:08] <eddyMul> :(
[07:09] <eddyMul> persia: Django itself is BSD.
[07:10] <persia> eddyMul: I wouldn't recommend using the ebuild packaging, unless you have a really good reason, as GPLv2+BSD=GPLv2, which might annoy someone wanting to hack on Django who uses Ubuntu.
[07:11] <eddyMul> persia: interesting...
[07:11] <eddyMul> but Gentoo packages Django (a BSD app) using a GPLv2 ebuild
[07:11] <eddyMul> what are debian/rules licensed under?
[07:11] <persia> eddyMul: Right.  So Gentoo distributed Django is GPKv2
[07:12] <persia> eddyMul: Depends on the package - see debian/copyright.
[07:12] <eddyMul> i c
[07:12] <eddyMul> so, Debian's stance is: the debian/rules license follows the package's license.
[07:12] <eddyMul> ?
[07:12] <man-di> persia: your interpretation is highly debatable
[07:13] <persia> eddyMul: Unless otherwise specified in debian/copyright
[07:13] <man-di> when the build system is GPLv2 that doesnt make the software GPL
[07:13] <man-di> persia: as the build-system is not linked to the software
[07:14] <man-di> persia: your interpretation would imply that everything you build with GNU make must be GPL
[07:14] <eddyMul> man-di, persia: my point is asking the question is because I want to steal Gentoo's code that runs Django's test suite.
[07:14] <persia> man-di: A couple days ago, discussion here (not an authoritative place), indicated that packaging under one license combined with content under another license as part of the build process generated a combined work, licensed as required.
[07:14] <minghua> man-di: bug eddyMul is talking about stealing patches, so persia is in some part correct
[07:14] <persia> man-di: No - it's the the license of the tools used, but the license of the wrapper scripts and extra content.
[07:14] <man-di> persia: the FSF is not of this opinion
[07:15] <persia> man-di: Which opinion?  Now I'm confused.
[07:15] <man-di> persia: extra content is another issue, but not the normal packaging framework for a package
[07:15] <eddyMul> if it helps, the code I'm planning to steal is the src_test function in http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/django/django-0.96.ebuild?rev=1.3&view=markup
[07:16] <man-di> minghua: not for the software, for the build system
[07:17] <man-di> eddyMul: I wouldnt say this function alone is copyrightable
[07:17] <persia> man-di: OK.  Taking the specific example of a debian-format package.  I have a single binary object, containing several items: some control data (packaging license), some upstream data (upstream license), and some binaries that may have been built including patches, or other modifications as a result of processing debian/rules, for which I believe the license of a combined work applies.
[07:17] <minghua> man-di: Okay, I was wrong.  You guys continue discussing if GPL build-system + BSD code = GPL binary package
[07:18] <man-di> persia: for patches you are rigth, but nor for debian/control or simple debian/rules
[07:19] <eddyMul> I'm sorry if my questions leads to a messy discussion...  :(
[07:19] <persia> man-di: Hmm.  OK.  I can see that.  I'm not sure of the definition of a patch, and my opinion is probably wider than yours, but I can agree in the simple case where it just works.
[07:19] <man-di> eddyMul: legal issues are hard,
[07:20] <persia> eddyMul: No worries.  It's good to ask.
[07:20] <man-di> eddyMul: and all should be aware of them
[07:20] <man-di> eddyMul: IMO it would be okay to just use that function
[07:20] <man-di> eddyMul: nobody will sue you for it
[07:20] <persia> eddyMul: I'm also agreeing with man-di that src_test() is probably too small to copyright, especially as it's just a wrapper for upstream code, and trivial to duplicate.
[07:20] <eddyMul> man-di: :)
[07:21] <eddyMul> persia, man-di: got it. I will Debian-ize it, then... :)
[07:21] <eddyMul> persia, man-di: As you probably figured out, I switched from Gentoo to Ubuntu    :)
[07:22] <man-di> eddyMul: you came to the light ;-)
[07:31] <eddyMul> can I put bash here documents inside a makefile?
[07:31] <eddyMul> currently, make is not liking it... :(
[07:33] <man-di> eddyMul: why not put setting.py directly into the package?
[07:33] <persia> eddyMul: Probably easier to create a debian/tests.py (or whatever) (techinically yes, but the syntax is immensely ugly).
[07:35] <eddyMul> man-di, persia: I'll try that. BTW, I assume the "current directory" is the parent directory of debian/. Am I right?
[07:35] <sacater> sorry to bother, does anyone know what the program is called that appears as "Disk Usage Analyzer"?
[07:35] <eddyMul> sacater: baobab?
[07:35] <man-di> Adri2000: yes
[07:35] <persia> sacater: grep in /usr/share/applications is a handy way to get the answer as well.
[07:35] <eddyMul> sacater: I think it's in gnome-system-utils (or -tools, or something like that...)
[07:43] <sacater> thanks
[07:48] <eddyMul> persia, man-di: it appears as if the target build/python-django is being run twice. hm....
[07:54] <eddyMul> if a package failed its testsuite, should I stop the build process? (currently, it's continuing the build)
[07:55] <minghua> my personal opinion is it should
[07:56] <eddyMul> minghua: should: abort or continue?
[07:56] <eddyMul> minghua: I noticed that python2.5 continues despite errors (but someone turned of the check, unless it's run by buildbot)
[07:57] <minghua> shoud abort
[07:57] <eddyMul> minghua: how can I abort a makefile. Do I "exit"?
[07:57] <persia> exit 1
[07:58] <minghua> normally, any command that returns non-zero should abort the build process
[07:59] <eddyMul> minghua, persia: very cool. I didn't know that. Thanx.
[08:00] <man-di> eddyMul: I would say it should but I maintain some packages where the testsuites fail on some archs, its sometimes really horror to have it enabled
[08:00] <eddyMul> man-di: I understand.
[08:02] <minghua> I would prefer "run-testsuite || true" if possible in that case, and ship the test results in binary package.  But that's just me.
[08:03] <StevenK> Personally, I run Linda's testsuite at build time. But it's arch: all, and uses pure-python modules.
[08:05] <eddyMul> minghua: I don't think I understand what you mean by "ship the test results in binary". Can you elaborate more on that?
[08:06] <minghua> eddyMul: The testsuite usually has a output about which tests passed and which failed.  Put this result in the binary package(s) you build, so that users can know which tests failed.
[08:07] <eddyMul> minghua: I c. And thats goes into.... /usr/share/doc/package?
[08:07] <minghua> eddyMul: yes
[08:08] <eddyMul> minghua: I c. Thanx for clarifying that.
[08:50] <porthose> Hey MOTU's:  would you please review ampache http://revu.tauware.de/details.py?upid=5830, I have made some major changes to it and would appreciate comments thank you
[08:51] <minghua> porthose: Did you see the mail Jordan sent to mailing list?
[08:51] <porthose> yes I did 
[08:52] <porthose> that is why I just want comment
[08:53] <porthose> just wanting to see if I screwed anything up with the changes I made.
[08:59] <persia> porthose: You'll probably do better getting comments from Debian mentors than from Ubuntu MOTUs for a Debian-targeted package, as there are subtle differences of which most of us are now entirely aware.  Aside from that, consider using ampache.dirs and ampache.install to take advantage of dh_install (instead of using install -m).  Wildcards are accepted.
[08:59] <porthose> cool, thank you 
[09:01] <persia> Umm..  Rather than "now entirely aware", I intended to say "not entirely aware".  Sorry.
[09:10] <minghua> BTW I remember the "using dh_install" point is raised on debian-mentors list already.
[09:12] <porthose> good night all
[10:43] <dholbach> good morning
[10:46] <BugMaN> hi dholbach!
[10:46] <dholbach> hi BugMaN
[10:49] <jussi01> morning all!
[10:49] <dholbach> hi jussi01
[10:49] <jussi01> hello dholbach
[10:55] <Hobbsee> morning dholbach!
[10:56] <dholbach> hiya Hobbsee
[11:17] <Fujitsu> Well, Dell is even less reliable that I thought.
[11:17] <Fujitsu> Apparently, 10 to 15 working days equates to 2 working days.
[11:17] <Fujitsu> They are the masters of accurate estimation.
[11:17] <Hobbsee> heh
[11:18] <persia> Fujitsu: That's called "Setting appropriate expectations", and is encouraged in certain communities.
[11:19] <jussi01> lol
[11:19] <Fujitsu> persia: You'd think they could estimate a little better than that, though.
[11:19] <persia> Fujitsu: Be glad.  I've actually seen date-sorted outboxes to ensure that sign-off always takes the three days mandated by the compliance documentation (wouldn't want to send things out early, you know).
[11:19] <jussi01> Fujitsu: its _up to_ 10-15 working days...
[11:20] <Fujitsu> jussi01: I didn't see an `up to' anywhere... and shouldn't that be up to 15 days?
[11:20] <Fujitsu> Aha.
[11:20] <jussi01> well thats what we were taught to say... anyway...
[11:21] <Fujitsu> persia: How... odd.
[11:22] <persia> Fujitsu: Yes.  The original idea was to allow for things not to be signed on weekends, or when people were sick, etc.  The idea aged badly, in the interests of specific job security.
[11:27] <jerome_> persia : hello
[11:28] <persia> jerome_: Hi.  I was just looking at bug 78367 and thinking of you.
[11:28] <jerome_> persia : for the fakesync in bug 122839 what debdiff should i join ?
[11:28] <ubotu> Launchpad bug 78367 in mosml "extend mosml package to include optional libraries (patch included)" [Wishlist,New]  https://launchpad.net/bugs/78367
[11:28] <ubotu> Launchpad bug 122839 in sjfonts "Please sync sjfonts (universe) from Debian unstable (main)" [Wishlist,Invalid]  https://launchpad.net/bugs/122839
[11:28] <jerome_> persia : did something wrong ?
[11:29] <persia> jerome_: For 122839, we need a debdiff against the current Ubuntu packaging, including all of the Debian changes, and a new changelog entry "fakesync from Debian...", with details.
[11:29] <jerome_> persia : ok I'm on it
[11:30] <jerome_> is there a howto for fakesync ?
[11:30] <persia> jerome_: 78367 needs a real revision candidate, with changelog updates, etc.  Also, it needs digging to make sure all the library dependencies are correct, etc.  I'm not at all familiar with Moscow ML, but given your comment, I hoped you might be.
[11:30] <jerome_> persia : not at all, just tested the patch :)
[11:30] <persia> jerome_: Oh well.  Thanks anyway.
[11:31] <persia> jerome_: I can't find a howto on fakesync.  There was an informal lesson on IRC a month or so ago: let me find a log.
[11:32] <jerome_> persia : thx, it's just to know exactly how to report a good fakesync request
[11:35] <persia> jerome_: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-05-25.html, starting from about 04:08.  If you want to pull from this and drop some hints in https://wiki.ubuntu.com/MOTU/Packages/Merging, it would be greatly appreciated.
[11:36] <persia> jerome_: Note that that one didn't turn out to actually be a fakesync, but it still walks though the process fairly well.
[11:36] <jerome_> persia : ok
[11:37] <jerome_> persia this debdiff is ok ? http://paste.stgraber.org/1955
[11:39] <persia> jerome_: Almost.  You'll want to include the changelogs from both 2.0.2-0ubuntu1 and 2.0.2-1, followed by 2.02-1ubuntu1 with your changes (or just a note that it's a fakesync).
[11:40] <jerome_> persia : in the debdiff ?
[11:41] <persia> jerome_: In your local 2.0.2-1ubuntu1 revision candidate, from which you will generate the debdiff.
[11:41] <jerome_> persia : understood :)
[11:42] <jerome_> persia : and it should be named -1build1 as it's a fakesync no ?
[11:42] <StevenK> It's a fakesync because the orig's differ?
[11:43] <persia> jerome_: Yes.  My apologies.  You want 2.0.2-1build1.
[11:43] <persia> StevenK: Yes.
[11:43] <jerome_> StevenK : yep
[11:43] <StevenK> Then I use -1ubuntu1, and mention that it's a manual merge
[11:44] <jerome_> StevenK : you put this in the changelog ?
[11:44] <persia> StevenK: That's at variance with the only doc I can find (IRC session).  Also, "manual merge" vs. "fakesync".  Is there something I'm missing?
[11:44] <minghua> persia: I think -1build1 is wrong
[11:45] <minghua> persia: because next time -2 will be autosynced and fail
[11:45] <persia> minghua: I'm also surprised: but I was taking http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-05-25.html "04:22crimsunnext, we add a new Ubuntu changelog entry. Because it's a fakesync, the version will use build1, not ubuntu1, as a suffix." as my guide.
[11:46] <minghua> persia: I believe there are more than one reason for fakesync
[11:46] <minghua> but I didn't read the log
[11:46] <persia> minghua: Also, I've never seen an autosync for a XbuildY version.
[11:46] <minghua> I think I have
[11:47] <minghua> (but can't think of an example from top of my head)
[11:47] <jerome_> so how should i process ?
[11:48] <persia> minghua: I can't think of a positive example (as I always assume that there are sync bugs I don't see), but my negative example is that at the beginning of a dev cycle, when debian import is running unrestricted, the XbuildY revisions show up in the merge queue, and don't go away until someone prods them.
[11:48] <afflux> can some motu please review this? http://revu.tauware.de/details.py?upid=5843
[11:52] <DarkSun88> Hiall
[11:54] <minghua> persia: Okay.  Since you are the mentor in this case, it's your word.  And crimsun is seldom wrong.
[11:55] <jerome_> persia : so what should i do ?
[11:57] <persia> jerome_: I'm not entirely comfortable giving official advice without further discussion, as I've found that StevenK is generally correct about most things.  On the other hand, I agree with minghua that crimsun is seldom wrong.  If I were doing it, I'd have used 1ubuntu1 by default, but that's not necessarily correct.
[11:58] <jerome_> persia : ok i'll do it with -1ubuntu1
[11:58] <minghua> the thing is, as long as you keep a close watch on the package, -1build1 or -1ubuntu1 won't make much difference
[11:59] <StevenK> Most things. Gee, thanks. :-P
[12:00] <StevenK> Heh
[12:00] <minghua> as a linda user, I would hope the author is generally correct about most things, too :-P
[12:00] <jussi01> lol
[12:01] <StevenK> No, it's all lies!
[12:01] <Hobbsee> lies and propoganda!
[12:01] <StevenK> With a few statistics thrown in. :-P
[12:02] <jerome_> persia : should i put in changelog for 1ubuntu1 that orig tarball changed ?
[12:05] <persia> jerome_: I don't think you need that.  I'm looking for a good fakesync example now.
[12:06] <jerome_> persia: thx
[12:09] <persia> jerome_: ffmpeg (3:0.cvs20070307-4ubuntu1) is one example.  There are surely others, but most are quickly subsumed by new upstream revisions.
[12:10] <persia> (I'm not sure it's a great example - might have been a merge)
[12:10] <jerome_> persia : ok thank you, got to go to have lunch, I will take care of that later.
[12:11] <persia> jerome_: x264 (1:0.svn20070309-4ubuntu1) is a better example.
[12:18] <minghua> persia: I don't know details, but my Debian apt-listchanges generate mails in plain text.
[12:19] <persia> minghua: That's what I expected it to do, but that's not what is in my mailspool.  It may be because I use a UTF8 locale, and so mailx forces the encoding so as to fit through 7bit gateways.
[12:21] <persia> afflux: 5843 commented
[12:21] <minghua> persia: Even in my spool directory it's plain text, and I use en_US.UTF-8.  Perhaps an exim4-vs-postfix thing.
[12:21] <persia> minghua: quite possibly.  In any case, grep isn't as useful as I'd like (for me).
[12:21] <minghua> Hmm
[12:22] <minghua> persia: it's Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit though...
[12:23] <minghua> Now I think I know why some non-ascii characters are messed up in apt-listchanges mails
[12:24] <persia> minghua: Hmm..  I'm getting Content-Type: text/plain; charset="utf-8" and Content-Transfer-Encoding: base64.  I'm suspecting differences in /usr/lib/sendmail implementations now: it appears to be the result of differences in handling text/plain for 8-bit locales.
[12:25] <minghua> persia: In case you file a bug, let me know. :-)
[12:27] <persia> minghua: For me, it's user error (I shouldn't try to search a mailspool with grep - that's what mail readers are designed for).  For you, I think it's a bug with exim4.  Try postfix locally: if you get clean non-ascii characters in your changelogs (but it's all base64), file a bug.
[12:27] <minghua> persia: Makes sense, will do.
[12:41] <afflux> persia: thanks for your comment. You mentioned a "debian/README.Debian-source"... should this really be called README.Debian-source or rather README.Debian?
[12:43] <persia> afflux: README.Debian-source.  README.Debian is installed for end-users (as /usr/share/doc/foo/README.Debian.gz).  README.Debian-source is only in the source package, and contains notes of interest to developers, but not to users (like the answer to the question "How was this orig.tar.gz generated?" or "Why does the packaging use the "experimental" branch in SVN, rather than the "stable" branch for the snapshot?", etc.)
[12:43] <afflux> ah, right. thanks ;)
[12:50] <afflux> persia: updated: http://revu.tauware.de/details.py?upid=5844
[12:52] <persia> afflux: Advocated.  Nice job.] 
[12:52] <afflux> thank you :)
[12:53] <persia> As it's REVU day (for much of the world anyway), someone else should take a look at it as well.
[12:58] <minghua> Hmm, so we have a 1.3K .orig.tar.gz and 3K .diff.gz, huh?
[12:58] <Hobbsee> hehe
[12:58] <gnomefreak> is DaD the list of merges done already?
[12:58] <Hobbsee> impressive
[12:58] <persia> minghua: Take a look at the upstream.  It's an interesting release paradigm.
[12:58] <Hobbsee> gnomefreak: they're the outstanding ones
[12:58] <gnomefreak> hmmmmmm
[12:59] <gnomefreak> why is mine outstanding (looks deeper
[01:03] <jmg> heh
[01:04] <jmg> dough
[01:04] <minghua> persia, afflux: A comment: in debian/README.Debian-source, "The source package contains a patch...".  I think the patch is in .diff.gz?
[01:04] <persia> minghua: Good catch.
[01:05] <minghua> persia, afflux: That's a rather confusing statement to me.
[01:05] <minghua> I know technically, both the .orig.tar.gz and .diff.gz belong to the source package, but still.
[01:05] <minghua> Especially the previous paragraph is talking about .orig.tar.gz.
[01:05] <gnomefreak> DaD is lying to me :(
[01:07] <gnomefreak> where does DaD get the newer version from?
[01:07] <Adri2000> gnomefreak: what's the problem?
[01:08] <minghua> persia: And since I am commenting, I don't see the point of having Build-Depends-Indep.
[01:08] <gnomefreak> Adri2000: DaD is saying that a new version of nspluginwrapper is out and ftp.debian.org doesnt list it neither does anywhere i can find
[01:09] <Adri2000> gnomefreak: DaD is currently using ftp.fr.debian.org. I think the ftp.debian.org mirror is having some problems.
[01:09] <gnomefreak> Adri2000: ah ok ty
[01:09] <persia> minghua: It's pure python, so it's architecture all, so build-dependencies are supposed to be in build-dep-indep.
[01:10] <minghua> persia: I know, but your are never going to build arch-dependent packages anyway, so why the differentiation
[01:10] <gnomefreak> Adri2000: ther eit is
[01:10] <gnomefreak> Adri2000: thanks
[01:10] <minghua> persia, afflux: Also, if you want to call gksudo in the .desktop file, you'd better depend on it (or at least recommend).
[01:10] <persia> minghua: I have no idea, but lintian complains otherwise.  Also, you should probably bug afflux about this: it's new to me.
[01:11] <minghua> persia: That's all right, I am not that curious anyway.
[01:12] <minghua> persia: For things I am rather sure, I am also pinging afflux.
[01:13] <persia> minghua: OK.  No problem.  It just confused me.
[01:14] <persia> Adri2000: Could you add a note to DaD indicating the alternate mirror?  Latency from here to ftp.fr.debian.org is horrid, but otherwise I'm just annoyed.
[01:22] <jerome_> persia: this is the debdiff between the -1ubuntu1 and the debian one, is it ok now ?
[01:22] <persia> jerome_: Um.  Define "this".
[01:23] <jerome_> persia: true :)
[01:23] <jerome_> http://paste.stgraber.org/1963
[01:23] <jerome_> that's better now :)
[01:26] <persia> jerome_: 1) because this requires the Ubuntu orig.tar.gz, you need to debdiff against Ubuntu (as opposed to a merge, where you debdiff against Debian).  2) I'm really not sure about the maintainer mangling.  If you keep it, it's more of a merge (which isn't necessarily bad) than a sync.  Otherwise, I'd expect something more like the x264 1:0.svn20070309-4ubuntu1 changelog.
[01:27] <jerome_> persia : I will correct this
[01:27] <mruiz> hi all
[01:29] <persia> Does anyone else have an opinion on maintainer mangling for fakesyncs?  Does the fact that we now manually mangle source maintainers render the concept of fakesync obsolete?
[01:29] <mruiz> If my upstream version is a file with extension "tar.bz2" or "tgz"... What I have to do? 
[01:30] <jerome_> mruiz : 
[01:30] <jerome_> bunzip2 foo-x.y.z.tar.bz2
[01:30] <jerome_> gzip -9 foo-x.y.z.tar
[01:30] <StevenK> mruiz: tgz is the same as tar.gz
[01:30] <persia> mruiz: For tgz, you just rename it.  For tar.bz2, you need to reprocess it.  See https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball for more information on the recommended procedures for reprocessing.
[01:31] <jerome_> then rename it
[01:31] <mruiz> thanks guys
[01:33] <minghua> persia: I am not aware of any?
[01:35] <jerome_> persia : so I don't put the maintainer change in changelog ?
[01:35] <persia> minghua: dpkg > 1.10.24 and devscripts > 2.9 handle tar.bz2 just fine.  Other things don't.
[01:35] <gnomefreak> if debian used our change to a package and added some more its a simple take debians and add changelog entry and build?
[01:36] <minghua> persia: Oh.  I never tried.
[01:36] <persia> jerome_: If you put in the change, it's a merge (and gets processed like a merge, except that you want to diff against Ubuntu, because you will use the Ubuntu orig.tar.gz).  If you don't put in the change, it's a fakesync.  I'm not sure which is correct.
[01:37] <jerome_> persia : but in both cases I have to put ubuntu-motus as maintainers no ?
[01:37] <persia> jerome_: No.  In the former case, you change the maintainer.  In the latter case, the buildd changes the maintainer.
[01:38] <jerome_> persia : ok
[01:38] <jerome_> persia : let's to do it totally as a fakesync then
[01:44] <mruiz> persia: What is the idea to create a symbolic link between foo.tar.gz and foo.orig.tar.gz ?
[01:46] <persia> mruiz: I suppose mv would work just as well, actually.  There just needs to be a foo.orig.tar.gz in that directory.
[01:46] <mruiz> :-)
[01:48] <persia> mruiz: Looking at the page, you could even just redirect into orig.tar.gz, for a shorter debian/rules.  Also, don't forget about debian/README.Debian-source.
[01:49] <DktrKranz> when have some time to spend, could you please have a look at http://revu.tauware.de/details.py?upid=5757 ? thank you.
[01:49] <afflux> minghua, persia: so I should remove the paragraph from the README.Debian-source that mentiones the patch and add gksudo as Depends?
[01:49] <jerome_> persia : this one should be better : http://paste.stgraber.org/1965
[01:50] <Takesinn> Ey
[01:50] <Takesinn> Is someone working on Enemy Territory?
[01:51] <afflux> minghua, persia: Or rather change the paragraph from "The source package contains a patch" to "I added a patch"?
[01:51] <persia> jerome_: Regarding the format, that looks fine to me.  If you're confident, push it back into the queue (remember to retitle the bug, and set the status to something other than "Invalid".
[01:51] <mruiz> persia: about the names... my upstream filename is Foo-XX-src.bz2 and the directory created is Foo-XX, but the last version is foo-xx...
[01:52] <jerome_> persia : ok thx
[01:52] <jerome_> go to go now
[01:52] <jerome_> coming back soon
[01:52] <minghua> afflux: "I added a patch" would be fine
[01:53] <persia> mruiz: In general, asking the channel is better than asking a person, as you'll get a wider response.  Specifically, I don't understand what you are asking.
[01:54] <mruiz> thanks persia 
[01:56] <mruiz> in my case, the last version of the package has a directory called "foo-xx". The new version is "Foo-xx". Any problem?
[01:58] <broonie> dpkg-source will smash the directory name in the .orig.tar.gz anyway.
[01:58] <persia> mruiz: I think dpkg might be smart enough to process that anyway, but I'm not sure.  Give it a try.
[01:58] <minghua> what's the name of the default ubuntu package manager? update-manager?  adept for kubuntu, right?
[01:59] <persia> minghua: gnome-app-install and adept-installer
[02:00] <minghua> persia: do you have to know if they keep logs and if yes, where the log is?
[02:00] <StevenK> dpkg keeps logs.
[02:01] <persia> minghua: I don't know, but upon further review, update-manager and adept-manager seem to also be part of the default solution.
[02:01] <minghua> okay, I'm dealing with bug 122863 now
[02:01] <ubotu> Launchpad bug 122863 in texlive-bin "package texlive-base-bin 2007-11 failed to install/upgrade: post-installation script spawns thousands of processes" [Undecided,New]  https://launchpad.net/bugs/122863
[02:02] <minghua> I doubt the reporter still have the dpkg log, even if he does, it's probably rather difficult to figure out the package versions
[02:05] <afflux> minghua, persia: okay, updated: http://revu.tauware.de/details.py?upid=5845
[02:06] <minghua> persia: Thanks BTW :-)
[02:06] <persia> afflux: Thanks for the quick turnaround.
[02:10] <minghua> persia, afflux: gksudo is in the gksu package, not gksudo package (which doesn't exist)
[02:10] <minghua> (at least that's the case in Debian)
[02:10] <afflux> gaaaah
[02:11] <minghua> afflux: and as you need to reupload anyway -- don't use "-rm debian/grub-choose-default.8", use rm -f instead.
[02:12] <Hobbsee> persia: you'd better make sure you're checking licence stuff.
[02:12] <Hobbsee> persia: otherwise Mithrandir might eat you.
[02:12] <jerome_> persia : bug 122839, does it look better now ?
[02:12] <ubotu> Launchpad bug 122839 in sjfonts "Please fakesync sjfonts (universe) from Debian unstable (main)" [Wishlist,New]  https://launchpad.net/bugs/122839
[02:12] <persia> Hobbsee: That's my problem.  When the license is clean, I get overexcited.
[02:12] <Hobbsee> heh
[02:13] <minghua> Hmm, Hobbsee has a point
[02:13] <afflux> uploaded: http://revu.tauware.de/details.py?upid=5846
[02:13] <minghua> persia, afflux: Upstream source says GPL v2.  debian/copyright says GPL v2 or later.
[02:14] <minghua> persia: sorry :-(
[02:14] <Hobbsee> persia: it's always a good day for REVU.  for someone other than Hobbsee to review.
[02:15] <persia> minghua: No, it's good.  If I'm not checking carefully enough today, I need to find something more broken to comment about (or contribute in a different way).  Uploading broken things just means more work for archive admins.
[02:15] <Hobbsee> hi white!
[02:15] <persia> Hobbsee: but today is REVU Day.  We decided that in the meeting.  Don't you remember?
[02:15] <white> long time no see
[02:15] <StevenK> Hey white!
[02:15] <white> . o O(actually never, but ...)
[02:15] <white> hi :)
[02:16] <Hobbsee> persia: vaguely.  i cant keep track fo days
[02:16] <Hobbsee> white: heh.  you should come to a conference that we're at, then.
[02:16] <white> which one?
[02:16] <StevenK> According to Hobbsee, days are things that happen to other people.
[02:16] <white> i will come back to melbourne first :) 
[02:17] <Hobbsee> white: whichever :)
[02:17] <white> my horror flight trip leaves duesseldorf on sunday morning
[02:17] <white> Hobbsee: come to debconf
[02:17] <white> or is there any fance ubuntu conference in australia?
[02:17] <Hobbsee> white: there's LCA eventually.  dont think there's anything in au, ubuntu-wise though
[02:17] <Hobbsee> debconf is over, isnt it?
[02:18] <StevenK> Debconf finished about a week ago
[02:18] <white> i could talk about "sponsoring for debian aka poking StevenK " :)
[02:18] <white> but next years debconf is coming :)
[02:18] <StevenK> And I could talk about "Killing rogue DDs for fun and profit."
[02:18] <white> hehe
[02:19] <white> Hobbsee: organize a debian/ubuntu super duper festival and I will come :)
[02:19] <Hobbsee> heh
[02:19] <white> man-di: ah my foo2zjs maintainer, how are you today? ;)
[02:19] <man-di> white: sleepy
[02:20] <white> that's always good :)
[02:20] <StevenK> man-di: If you tell me you've uploaded cyphesis-cpp, eris and sear, I promise I won't kill you. :-P
[02:20] <man-di> white: not with a 13 days old child at home
[02:20] <man-di> StevenK: sear is missing but the rest is up
[02:20] <white> male or female?
[02:20] <StevenK> man-di: Nice!
[02:20] <man-di> white: male
[02:21] <white> hmm then give him a football and let him run around the house ten times
[02:21] <man-di> StevenK: eris is caught in debian NEW queue, that is one reason why I wait with sear
[02:21] <StevenK> man-di: Ah ha.
[02:21] <StevenK> cyphesis-cpp is all okay?
[02:21] <man-di> white: hehehe. I wonder if you could walk when 13 days old
[02:22] <white> oh, i read 13 years, sorry :)
[02:22] <StevenK> I seriously doubt the tyke can hold his head up, let alone his whole body. :-P
[02:22] <white> well then the best is to wait until he is 1,5. Then it is probably getting better :)
[02:22] <man-di> StevenK: should be, but I dont fixed the postgres issue yet
[02:22] <white> ah sigfood :)
[02:23] <StevenK> man-di: Is it worth merging/syncing cyphesis-cpp?
[02:23] <man-di> StevenK: its 4 upstream versions newer, so its worht to merge it
[02:24] <StevenK> man-di: Okay, adding that onto my list after curl. :-)
[02:24] <man-di> StevenK: cool, thanks for the heads up and solving the ubuntu side of issues
[02:25] <StevenK> I'm always happy to give MOTUs and myself less work in future. :-)
[02:26] <gnomefreak> is there a reason why dad lists a merge and merges.ubuntu.com doesnt?
[02:26] <StevenK> MoM has a blacklist, and DaD doesn't.
[02:27] <gnomefreak> blacklist?
[02:27] <man-di> StevenK: I'm no MOTU nor a MOTU Hopeful :-)
[02:29] <persia> man-di: No, but you're a valuable contributor to MOTU activities :)
[02:30] <man-di> persia: when you say so, I try my best
[02:30] <persia> gnomefreak: Some things shouldn't be merged or synced, even when it looks like they should.
[02:30] <man-di> persia: Thanks for the compliment
[02:30] <gnomefreak> persia: ones that shouldnt be merged would be on m.u.c?
[02:30] <gnomefreak> wouldnt*
[02:31] <persia> gnomefreak: Right.  Anything on the blacklist doesn't appear.
[02:31] <gnomefreak> ah ok
[02:32] <Adri2000> DaD lists 89 merges while MoM lists 37, so it's more than just a blacklist. perhaps MoM uses the broken debian mirror?
[02:33] <persia> Adri2000: likely (as it is the official, authoritative mirror).
[02:34] <man-di> persia: if it uses ftp.debian.org, it was outofdate lately for some time (and its not the authoritative mirror)
[02:34] <persia> man-di: No?  I thought ftp-master was restricted, and ftp.d.o advertised as authoritative.
[02:34] <persia> (at least p.qa.d.o depends on it)
[02:35] <minghua> I don't think ftp.d.o is authoritative, it doesn't even have all arches
[02:38] <minghua> well, probably I was thinking about http://www.debian.org/mirror/list-full
[02:38] <afflux> minghua, persia: anything else left beside the copyright issue for grub-choose-default? ;)
[02:38] <minghua> there, under ftp.debian.org: "Comment: This is -NOT- the primary server, it is as good as all other Push-Primary mirrors!"
[02:39] <persia> afflux: Two copyright issues: 1) no COPYING in orig.tar.gz, and 2) GPLv2 vs. GPLv2 or later in debian/copyright.  Plus, you might have issues due to the truncated header in the source file.
[02:40] <minghua> afflux: I've mentioned dependency on gksudo and "-rm" in debian/rules
[02:40] <afflux> minghua: yes, this is fixed with 5846
[02:41] <afflux> persia: well, the upstream doesn't provide any COPYING file. What to do with that?
[02:41] <persia> minghua: Thanks.  I've been using the wrong mirror :)
[02:41] <persia> afflux: Talk with upstream.  You may need to insert it (but I don't know if that's allowed).  tar.gz is good.
[02:42] <minghua> afflux: Nothing from me for now then.  I'm going offline soon, ping me or send an email (minghua@ubuntu.com) if you still need an advocate later.
[02:42] <afflux> thanks minghua 
[02:44] <man-di> persia: ftp-master is authoritive and restricted
[02:44] <persia> man-di: Right.  It's the concept of Push-Primary that I was missing.
[02:45] <man-di> persia: all other just more or less uptodate mirrors
[02:45] <man-di> persia: ah
[02:46] <persia> man-di: I was previously under the impression that ftp.d.o was Push-Primary, and that everything else was Push-Secondary.  I've since been disabused.
[02:46] <persia> (or leaf, but these have always been more obvious)
[02:48] <xxxxx1> morrrning all :)
[02:49] <minghua> Hmm, I learned a new word "disabuse" :-)
[02:50] <persia> minghua: It's not as popular as it might be, but handy.
[02:51] <persia> Hobbsee: Yes, but you don't usually get to perform the first, and the second is just contrary
[02:51] <Hobbsee> heh
[02:51] <Hobbsee> "usually"
[02:51] <Hobbsee> now that all depends
[02:52] <Hobbsee> now if i had a window near work...
[02:52] <StevenK> antidisestablishmentarianism is only used by people wanting to show off. :-P
[02:52] <Fujitsu> StevenK: Oh, you don't regularly use it in sentences?
[02:52] <StevenK> persia: A friend of mine replaced a server at his place of work and called it "defenestrated".
[02:52] <Hobbsee> perhaps that's what i should name my other machine, instead of OnFire
[02:52] <StevenK> Heh.
[02:53] <StevenK> The old install on that hardware was NT 4, hence the name. :-P
[02:53] <persia> StevenK: Nah - when you defenestrate a server, people should know for quite a ways about.
[02:53] <persia> Ahhh....
[02:53] <StevenK> Fujitsu: No, and I can't see you doing it, either.
[02:54] <NeilW> I've uploaded 'vim-rails' to REVU. Comments appreciated. Be gentle though - it's my first time :-)
[02:54] <Hobbsee> jsgotangco: so you're a spammy-iCon now, are you?
[02:54] <jussi01> lol
[02:54] <jsgotangco> lol
[02:55] <Fujitsu> persia: But German has too many insanely long compound words.
[02:55] <Hobbsee> yeah, but that's not english.  that looks german.
[02:55] <minghua> So what do you say about Chinese that doesn't have spaces between words?
[02:55] <persia> Fujitsu: That's the point: keeping them straight.
[02:55] <StevenK> No, Finnish is much better for that.
[02:55] <persia> minghua: Saves paper?
[02:55] <minghua> persia: no, just the way we speak
[02:56] <minghua> In Chinese, all chracters are single-syllable, so no point for spaces.
[02:56] <persia> minghua: Hmm..  I hear inflection in spoken Chinese tounges.  Anyway, back to testing this sync.
[02:58] <jussi01> ahh, now persia, stop it... :P
[03:00] <minghua> persia: Doesn't inflection mean changing pronunciation of a word during speech, instead of changing rhythm?
[03:01] <persia> minghua: Probably.  I don't remember exactly, and realise that a debate of Chinese typography is very far from the things I intended to be doing this evening.
[03:01] <minghua> persia: Sure. :-)  Sorry for dragging you away.
[03:02] <persia> minghua: No need to be sorry - it's just that things that interest me that I haven't thought about in a while tend to pull me from things that interest me that I've been thinking about recently.
[03:06] <minghua> Uh-oh.  Tollef just sent a mail about REVU and licenses.
[03:08] <RainCT> keescook: what's about advocate now, since you said it does work for you?
[03:10] <gnomefreak> does the grab-merge.sh script work if package in not in MoM?
[03:12] <gnomefreak> s/in/is
[03:13] <white> man-di: did you have some time to test new foo2zjs?
[03:13] <man-di> white: not yet
[03:13] <gnomefreak> i run the script and all it does is delete everything in that dir.
[03:14] <Hobbsee> gnomefreak: no it doesnt.  wlel, it does as you say
[03:14] <gnomefreak> it doesnt work still?
[03:14] <gnomefreak> hmmmmmm
[03:15] <Hobbsee> if the package is nto in MoM - what is the intended result?
[03:15] <gnomefreak> its in dad
[03:15] <persia> gnomefreak: I think there's a different grab-merge script for DaD, if you want that.  See the DaD page.
[03:15] <gnomefreak> looking ty
[03:16] <gnomefreak> ah yes there is
[03:18] <viviersf> how can you force a package to update before another package
[03:18] <persia> viviersf: Why do you need to update in a certain order?
[03:20] <gnomefreak> viviersf: dpkg --configure packagename?
[03:22] <white> man-di: i am doing some reviewing now
[03:22] <viviersf> persia, i added a new package, but in order for it to work correctly a buggy old package needs to be updated
[03:23] <persia> viviersf: For that case, you probably want Depends: old-buggy (>= fixed-version) and Conflicts: old-buggy (< fixed-version).
[03:23] <viviersf> persia, cool
[03:30] <man-di> white: cool
[03:43] <white> man-di: review done, you got mail as well :)
[03:45] <man-di> white: thx
[03:46] <StevenK> man-di: MoM can't see that cyphesis-cpp has been updated due to ftp.d.o being braindead, so I'll hold off on the merge/sync until MoM can.
[03:47] <man-di> StevenK: okay
[03:48] <StevenK> I saw it on #debian-devel.
[04:04] <mruiz> ping dholbach 
[04:05] <dholbach> mruiz: pong
[04:05] <mruiz> hi dholbach, how are you today? I sent you an email about a package to review ;-)
[04:07] <xxxxx1> hi dholbach
[04:07] <dholbach> mruiz: fine fine - how are you?
[04:08] <dholbach> mruiz: yes, I received your mail, unfortunately it wasn't the only one over the weekend
[04:08] <dholbach> mruiz: I got several thousands of mails, I'll see that I get around to do the review quickly
[04:08] <dholbach> mruiz: in the the meantime you can ask in the channel or on ubuntu-motu-mentors@ for a review, if you don't mind
[04:08] <mruiz> dholbach, no worries :-)
[04:08] <dholbach> but I promise, I'll try to do it soon
[04:09] <mruiz> I'm patient 
[04:29] <mruiz> I'm packaging a torrent client that depends on libtorrent. In the Ubuntu archive I found the package "libtorrent10" and I have to upgrade it. Why this package is not called just "libtorrent"? 
[04:45] <dholbach> mruiz: best to update it then
[04:45] <dholbach> mruiz: talk to bluekuja - he's part of the torrent team
[04:45] <mruiz> thanks dholbach 
[04:45] <dholbach> np
[04:46] <mruiz> is the same project name, but they are different
[04:46] <mruiz> the package in the archive (libtorrent10) doesn't work for me (in this case)
[04:47] <dholbach> best to agree with bluekuja on a solution for that
[04:47] <mruiz> yes
[04:47] <mruiz> BSD license is allowed ?
[04:48] <ScottK> mruiz: Yes
[04:48] <ScottK> dholbach: Did you get a chance to finish looking into the clamav API changes for 0.90.x
[04:49] <dholbach> ScottK: no, I had no time on the weekend to look into it- but the changes are too large to make a list of them on a wiki page easily
[04:49] <dholbach> I think it's best to try to build them in a chroot and see what happens
[04:50] <dholbach> I know this is not ideal, but the most realistic option before doing archaelogical studies on clamav
[04:50] <ScottK> dholbach: OK.  I had been thinking based on your quicklook during the meeting that if the changes (not additions) to the API were some return code changes, maybe we could patch the old return codes back in for Dapper and not have to backport all the rdepends...
[04:52] <dholbach> lots of other stuff changed to
[04:52] <dholbach> too
[04:52] <dholbach> it had 60K lines of changes
[04:56] <ScottK> dholbach: I'm not suprised.  I was just trying to focus in on what affected interoperability with other packages.
[04:58] <dholbach> we should just try to build the dapper apps against the gutsy clamav in a chroot
[04:59] <dholbach> I think that should be entirely possible to do, so everybody can grab 1-2 source packages
[04:59] <dholbach> did you set up a wiki page with that?
[04:59] <ScottK> dholbach: I set up a stub of one and started a team to make it easier to coordinate.
[05:00] <ScottK> dholbach: I didn't have a lot of time over the weekend either.
[05:00] <ScottK> dholbach: https://launchpad.net/~ubuntu-clamav
[05:00] <dholbach> good good, if we announce that on ubuntu-devel with some instructions, that should make it easier
[05:02] <Sp4rKy> a va le reboot
[05:02] <Sp4rKy> alo ?
[05:02] <Sp4rKy> y'a quelqu'un ?
[05:02] <Toadstool> Sp4rKy: ECHAN
[05:02] <Sp4rKy> oups
[05:02] <Sp4rKy> sorry
[05:02] <Toadstool> hi everybody
[05:03] <Sp4rKy> Toadstool: hi
[05:04] <sommer> ScottK about the clamav team are we focussing on Dapper? 
[05:05] <sommer> I should have some time over the 4th to look into it, but I'm still not 100% clear on where to start.
[05:05] <ScottK> sommer: That's where the greatest need is at this moment.  Not exclusively.
[05:06] <ScottK> sommer: Step one is for me to get a draft package for a clamav 0.90.3 backport to Dapper out for people to use.  I should get that done tomorrow.
[05:06] <ScottK> sommer: Step two is to test different packages that use clamav against this package and see which work and which don't.
[05:06] <sommer> ScottK: cool if you need some testing help let me know.  I setup a test of the Server edition this weekend.
[05:06] <ScottK> Step three is to prepare backports of the packages that don't work.
[05:07] <ScottK> Step four is massive backport of all this cr$p at the same time so nothing (promise) breaks.
[05:07] <ScottK> Step five: Move to Edgy, rinse, repeat.
[05:08] <ScottK> In the meantime, people running Feisty can check the rdpends and make sure nothing got missed during Feisty development (I know clamtk did and I've already asked for a backport).
[05:08] <ScottK> jdong: Are you around?  Any chance of getting the clamtk backport for Feisty approved soon?
[05:09] <ScottK> And just to keep in interesting, clamav 0.91 is at rc2 and will enable a bunch of anti-phishing stuff, so stand by for more fun.
[05:10] <sommer> Ya I thought it looked like 0.91 would be out soon.
[05:10] <ScottK> dholbach: Once I have the clamav package for dapper ready for people to use for building/testing, what would be the best way to publish it for people to use?
[05:10] <sommer> do you know if there are API changes between 0.90 and 0.91?
[05:10] <sommer> I assume there are if they're adding anti-phishing.
[05:11] <ScottK> sommer: I doubt it, but haven't checked the docs.  I'd guess additions, but not changes.
[05:11] <sommer> ah...thats cool.
[05:25] <dholbach> ScottK: just uploade the source packag somewhere - people can built it on their arch in that chroot then
[05:26] <ScottK> dholbach: OK.  I'll do that.  I'll put an i386 binary up too just to save trouble.
[05:26] <dholbach> great
[05:31] <ScottK> sommer: If you have a few minutes (I'm on my way out the door), it'd be nice if you would take the information I gave you above and add it to the MOTU/clamav wiki page.
[05:31] <sommer> ScottK: sure no problem.
[05:32] <sommer> another quick question...is the source for you Dapper package in a public Version Control somewhere?
[05:32] <ScottK> sommer: No.  It'll be the current Gutsy package with a couple of changes in debian/control to make it build on Dapper.
[05:33] <sommer> cool...I'll just be patient.
[05:37] <geser> ScottK: re bug #15485: what's missing? the gpg-agent should get started through Xsession.d
[05:37] <ubotu> Launchpad bug 15485 in gnupg2 "kmail don't ask the phrase for gpg-encrypted mails" [Medium,Confirmed]  https://launchpad.net/bugs/15485
[05:37] <ScottK> geser: The missing bit to get it automatically is you have to add "use-agent" to ~/.gnupg/gpg.conf.
[05:38] <ScottK> geser: See my mail to devel-discuss.
[05:50] <geser> ScottK: that proposal sounds reasonable
[06:03] <mok0> I have several packages sitting in REVU, ready and awaiting review. Most have already been through one or more cycles
[06:21] <bmm> After being rejected by the archive due to licensing issues, there is a new release of ccbuild using libgcrypt instead of another MD5 implementation. So any MOTU please take some time to look at http://revu.tauware.de/details.py?upid=5850
[06:48] <dholbach> mruiz: sent a comment on the package
[06:49] <mruiz> thanks dholbach 
[06:49] <dholbach> anytime
[06:55] <mruiz> why this package (amsn) is not xx-YubuntuZ in previous versions?
[06:55] <dholbach> you mean the 'dfsg' bit?
[06:55] <dholbach> that means that the tarball was repacked
[07:18] <jerome_> i've just downloaded the source package of pommed in gutsy, in debian/changelog there are only entries for debian unstable, how can it be that there are no ubuntu ones ?
[07:24] <jerome_> davromaniak : alors ce perfparse ?
[07:25] <davromaniak> j'ai abandonn perfparse pour tenter avec rrdtools
[07:35] <nixternal> is there a security doc somewhere? I have a package I need to get security fixes in (>= Dapper). I have done this before, but I want to be clear on the steps if possible
[07:39] <giskard> nixternal, https://wiki.ubuntu.com/SecurityUpdateProcedures?highlight=%28security%29
[07:39] <nixternal> thanks giskard 
[07:39] <giskard> try to search security on wiki.u.com
[07:40] <nixternal> I did, overlooked that one
[07:48] <keescook> nixternal: ping me or pitti when you're reading to go; I'm going to be afk for about 20 hours, so if you can't reach either of us, either send email to security@ubuntu.com or the motu mailing list (or open a security-related bug).  :)
[07:49] <nixternal> I am going to do all 3 :)
[07:49] <nixternal> thanks
[07:49] <keescook> sounds good to me.  :)
[07:49] <keescook> out of curiosity, what package is it?
[07:53] <nixternal> KVIrc
[07:53] <nixternal> 2 simple lines for the parseIrcUrl() function to sanitize a couple of characters in their scripting module
[07:58] <tsmithe> hmm where's Mez... i need to congratulate him. asleep methinks
[08:10] <mruiz> hi all
[08:10] <mruiz> I need to rename a directory ( I changed the name of the package, but I need to change the name of the dir as well)
[08:10] <mruiz> How I can do it ?
[08:12] <mruiz> How can I do it ? ;-)
[08:25] <vijay2000> Hi all, can anybody tell me how to decrpyt a encrypted message
[08:25] <vijay2000> gpg --decrypt filename.txt is throwing the following error
[08:26] <vijay2000> gpg: decrypt_message failed: unexpected data
[08:30] <nixternal> keescook: bug 123595 if you are still around
[08:30] <ubotu> Bug 123595 on http://launchpad.net/bugs/123595 is private
[08:43] <crimsun> mruiz: e.g., mv old new && tar cf new_foo.orig.tar new/
[08:45] <mruiz> crimsun, and I have to comment it in debian/README.Debian-source
[08:46] <cbx33> hi guys
[08:46] <cbx33> anyone around to offer a little help?
[08:48] <crimsun> cbx33: depends what you need.
[08:48] <nixternal> messing with security patches, I forgot all about my laundry :/
[08:48] <nixternal> hiya cbx33 
[08:50] <mruiz> crimsun,  Is needed to comment it in debian/README.Debian-source ?
[08:51] <crimsun> mruiz: for a source package rename and/or directory rename?  Not for the latter, no; for the former, it depends if you've made any additional changes.
[08:51] <cbx33> well
[08:51] <mruiz> thanks crimsun 
[08:52] <cbx33> http://codebrowse.launchpad.net/~petesavage/vcs-frenzy/trunk/files/petesavage%40ubuntu.com-20070630095338-6p7c56m6x2gmlb5y?file_id=debian-20070510150647-t31jnlawshlxkqvc-1
[08:52] <cbx33> this is my debian dir
[08:52] <cbx33> the source pacakge builds fine
[08:52] <cbx33> dh_pysupport: debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy doesn't contain modules for any supported python version
[08:52] <cbx33> but i get that error when pbuilding
[08:52] <cbx33> any ideas?
[08:55] <cbx33> is there a way to get pbuilder not to delete everything so I can inspect it?
[08:55] <cbx33> --debug didn't work
[08:56] <iAmaranth> add a hook
[08:56] <iAmaranth> i'm stuck on OS X while my laptop gets fixed so i can't tell you how :)
[08:57] <cbx33> oh
[08:57] <cbx33> like a pause
[08:57] <crimsun> https://wiki.ubuntu.com/PbuilderHowto#head-977029f996a60ad77d13293f40d6adbc8da99652
[08:57] <mruiz> bye all
[09:00] <cbx33> trying now
[09:00] <cbx33> thanks crimsun
[09:03] <cbx33> ok
[09:03] <cbx33> so the prblem isn't there
[09:03] <cbx33> this is driving me nuts
[09:07] <cbx33> ok
[09:07] <cbx33> I'm just inspecting the build directory
[09:07] <cbx33> pete@misato:/var/cache/pbuilder/build/11601/tmp/buildd/vcsfrenzy-0.1.0/debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy$ ls -la
[09:08] <cbx33> -rw-r--r-- 1 1234 1234    0 2007-05-10 07:42 __init__.py
[09:08] <cbx33> drwxr-xr-x 2 1234 1234 4096 2007-07-02 20:06 plugin
[09:08] <cbx33> so
[09:08] <cbx33> why is it failing
[09:08] <cbx33> dh_pysupport: debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy doesn't contain modules for any supported python version
[09:08] <cbx33> with that error message?
[09:10] <cbx33> google has nothing on that error message
[09:51] <ScottK> geser: It might be nice to have a reply on devel-discuss to that effect (i.e. sounds reasonable).
[09:52] <ScottK> crimsun: Welcome to Maryland (I assume).
[10:20] <geser> ScottK: was a bit a hurry, will reread it again and mail to devel-discuss
[10:21] <ScottK> geser: Thanks.
[10:21] <geser> it would be good to fix it in the next gnupg2 upload which to needed for the libcurl4 -> libcurl3 backtransition
[10:32] <bmm> Any MOTU, ccbuild is looking for it's first advocate again but now for the new version of the source. If you have time, please look at http://revu.tauware.de/details.py?upid=5850
[10:46] <cbx33> hi guys
[10:47] <cbx33> if I have a package I want to create
[10:47] <cbx33> and it needs to compile 1 .cpp
[10:47] <cbx33> with a line gcc -Wall -I/usr/include -o phimage-bin phimage.cpp `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` -L/usr/X11R6/lib -lX11 -lglut -lGL -lGLU -lm -g
[10:47] <cbx33> can that just go into the rules file....
[10:47] <cbx33> if so....where and once it's done.....where will the file be created?
[10:48] <geser> cbx33: sure, why not
[10:48] <geser> it will probably end in $(CURDIR)
[10:50] <cbx33> so if I then wanted to make a .install file
[10:50] <cbx33> where would it find it
[10:50] <cbx33> or I suppose
[10:50] <cbx33> hmm
[10:50] <cbx33> ?
[10:51] <cbx33> geser, would that be in debian/
[10:51] <geser> debian/rules is called from the source-directory, so I assume that your compiled file will end there
[10:52] <mok0> cbx33: If it's a .cpp you need to compile with g++
[10:52] <cbx33> oh
[10:52] <cbx33> how come it works ok with gcc
[10:52] <geser> gcc is clever enough to use g++ on an .cc file
[10:52] <cbx33> it's a .cpp
[10:53] <geser> or a .cpp file
[10:53] <cbx33> ok
[10:53] <cbx33> cool
[10:54] <geser> if you want to test why a stage at package build fails you can call it directly
[10:55] <geser> debian/rules build or which target you need
[10:59] <cbx33> if I was building a package
[10:59] <cbx33> and it has to copmile
[10:59] <cbx33> is build-essential a good dep to have?
[11:04] <geser> you should have build-essential installed but don't build-depend on it (every package has an implicit B-D on it)
[11:06] <ajmitch> morning
[11:08] <nixternal> g'morning ajmitch 
[11:08] <ScottK> Good morning ajmitch.
[11:08] <geser> morning ajmitch
[11:08] <mok0> cbx33: you can compile with gcc but not link
[11:09] <mok0> cbx33: you need to use g++ to link a C++ program
[11:09] <ScottK> mok0: Which of your packages on REVU is most ready/would you prefer to have looked at?
[11:09] <mok0> Scott: lemme look
[11:10] <mok0> ScottK: you looked at kaksi before, it failed in your pbuilder, but I fixed the Deps. http://revu.tauware.de/details.py?upid=5662
[11:11] <mok0> ScottK: great, thx
[11:12] <ScottK> mok0: Does it build in pbuilder now
[11:12] <ScottK> ?
[11:20] <cbx33> how big generally does a pbuilders cache get whilst it's building?
[11:22] <cbx33> hmmm
[11:22] <cbx33> in my package i just made it said gcc wasn't found
[11:22] <cbx33> what package do i need to install to get it?
[11:22] <cbx33> i mean
[11:22] <cbx33> as a build dependency?
[11:25] <geser> gcc is part of build-essential which doesn't have to be added to build-depends
[11:25] <geser> cbx33: you mean the pbuilder apt-cache? or the pbuilder chroot?
[11:26] <mok0> ScottK: Yes it builds for me. (Sorry, I was away)
[11:26] <cbx33> chroot
[11:26] <cbx33> geser
[11:26] <cbx33> ahh ok
[11:26] <cbx33> building now
[11:26] <geser> it depends on how much space the build-depends need
[11:26] <cbx33> ydh i guess
[11:27] <cbx33> had a funky idea was all
[11:27] <cbx33> for people with lots of RAM
[11:27] <geser> you need space for the expanded base.tar.gz plus the installed build-depends
[11:27] <ScottK> mok0: No problem.  I'm building it now.
[11:27] <cbx33> g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:27] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \ 
[11:27] <cbx33> g++:  : No such file or directory
[11:27] <cbx33> ???
[11:28] <geser> cbx33: I've seen packages needed over 300 MB of space for the build-depends
[11:28] <cbx33> ouch
[11:28] <cbx33> this one readhes 175Mb
[11:28] <geser> add also space for the files generated during the build
[11:28] <cbx33> why is it dying like that?
[11:29] <geser> cbx33: is that from a builder or from your develeopment environment?
[11:29] <cbx33> builder
[11:29] <cbx33> it builds fine elsewhere
[11:29] <cbx33> infact earlier it was trying to build
[11:30] <mok0> cbx33: I get errors like that when trying to build on an NFS mounted disk
[11:30] <cbx33>         g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:30] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \ 
[11:30] <cbx33>          -L/usr/X11R6/lib -lX11 -lglut -lGL -lGLU -lm -g
[11:30] <cbx33> is that wrong?
[11:30] <cbx33> in my rules file
[11:30] <cbx33> before i added the freeglut3 dependency it was ok
[11:31] <mok0> cbx33: you probably need  freeglut3-dev not freeglut3
[11:31] <cbx33> i have that
[11:31] <cbx33> as a build dep
[11:31] <cbx33> i meant freeglut3 in general
[11:31] <cbx33> :p
[11:32] <mok0> ok
[11:32] <mok0> cbx33: check out your pbuilder environment with a package from the repo that is known to build (choose a small one)
[11:33] <cbx33> hmmm
[11:33] <cbx33> ok
[11:33] <cbx33> as I say
[11:33] <cbx33> twas ok
[11:33] <cbx33> hmmm i know what I'll try too
[11:33] <cbx33> my hook should let me try to copmile from within my build environment
[11:34] <geser> cbx33: you could also login into your pbuilder and check why g++ isn't installed
[11:34] <cbx33> well
[11:34] <cbx33> it was
[11:34] <cbx33> how do i do that?
[11:34] <cbx33> it did it for gcc too
[11:34] <cbx33> dpkg-parsechangelog: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
[11:34] <cbx33> debian: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
[11:34] <cbx33> dh_installdocs
[11:34] <cbx33> dh_installexamples
[11:34] <cbx33> g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:34] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \ 
[11:34] <cbx33> g++:  : No such file or directory
[11:34] <cbx33> make: *** [install]  Error 1
[11:34] <cbx33> pbuilder: Failed autobuilding of package
[11:35] <cbx33> root@misato:/# gcc
[11:35] <cbx33> gcc: no input files
[11:35] <cbx33> root@misato:/# g++
[11:35] <cbx33> g++: no input files
[11:35] <cbx33> root@misato:/# 
[11:35] <cbx33> from the chroot
[11:35] <geser> pbuilder login
[11:35] <geser> and you shouldn't build it in the binary target but in the build target
[11:35] <cbx33> ok
[11:36] <cbx33> W: no hooks of type F found -- ignoring
[11:36] <cbx33> root@misato:/# g++
[11:36] <cbx33> g++: no input files
[11:36] <cbx33> root@misato:/# 
[11:36] <cbx33> g++ is installed
[11:37] <geser> argh, it's definitely to late for me
[11:37] <mok0> cbx33: Don't you have to cd to some dir before doing the compile?
[11:37] <geser> it's not the shell complaining but g++ itself
[11:37] <cbx33> ahhh
[11:37] <geser> is the \ in the second line correct?
[11:38] <cbx33> no idea
[11:38] <mok0> the backslash means continues next line
[11:38] <mok0> there must not be a space after et
[11:38] <mok0> s/et/it
[11:39] <geser> g++ complains that it can't find the file " "
[11:39] <mok0> looks like you may have to get rid of it
[11:39] <cbx33> ahhh
[11:39] <cbx33> ok
[11:39] <mok0> :-D
[11:39] <cbx33> might have solved it then
[11:39] <cbx33> thank you
[11:47] <ScottK> mok0: +1 on kaksi.  Looks good to me.
[11:49] <ScottK> geser: Do you have time to look at http://revu.tauware.de/details.py?upid=5662.  It looked good to me, so it's looking for #2.
[11:49] <mok0> ScottK: Thx!
[11:49] <ScottK> mok0: Thank you for contributing.
[11:49] <mok0> ScottK: kssh was rejected today, due to some license issue
[11:50] <Kmos> ScottK: gambas has synced by seb128
[11:50] <ScottK> mok0: Oops.  I checked licensing more closely on kaksi.
[11:50] <ScottK> mok0: Let me know when kssh is ready to be uploaded again.
[11:51] <mok0> ScottK: OK. The license stuff is difficult. He said that COPYING should be in the orig.tar.gz, but I don't know what he means by that.
[11:51] <mok0> Should _I_ put the license files in?
[12:01] <geser> mok0: no, the orig.tar.gz should contain a copy of the license
[12:02] <geser> usually the license file is called COPYING or sometime also LICENSE
[12:02] <mok0> geser: then upstream must do it?
[12:05] <geser> yes
[12:06] <mok0> that could be problematic
[12:08] <mok0> Often upstream authors don't care about the legalese
[12:10] <ScottK> mok0: The best solution is to ask upstream to release an update with the file.
[12:10] <ScottK> mok0: If they won't, then you can repack the orig.tar.gz to include it.
[12:12] <ScottK> mok0: See http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz for documentation on how you repack orig.tar.gz.
[12:13] <mok0> ScottK: I'll try to get in contact with him
[12:14] <mok0> I'd better send him the files (it's several licenses)
[12:14] <mok0> ... or perhaps a patch
[12:15] <ScottK> mok0: kaksi has a copy of the GPL in it, so it's not a problem for that one.
[12:16] <DarkSun88> Hi all
[12:19] <mok0> ScottK: but it does have unconventional clauses in the .c files :-(
[12:21] <mok0> ScottK: ... and not in _every_ file