[12:49] <icf7> persia: Nice to see you. I updated https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball with a new uscan example. Any comments ;) ?
[12:51] <persia> icf7: Looks nice, but you might want to upgrade the first sample (wget) as well :)
[12:52] <icf7> persia: Why? It doesn't use uscan!?
[12:52] <persia> PriceChild: icf7 has been working on improvements to get-orig-source, in part based on gizmod.  You might want to take a look
[12:53] <persia> icf7: Ah.  Right.  So it can still be called from any directory without a problem (sorry - my brain is not fully functional yet).
[12:54] <PriceChild> oook... where?
[12:54] <PriceChild> and wooo gizmod is in repos now :)
[12:54] <icf7> persia: Great. I'll bulk upload new packages then and ask you for reviews ;)
[12:55] <persia> icf7: I'm not sure it's worth an upload just to fix an optional rule - I'd recommend only filing wishlist bugs (Debian would be an even better place to file them, except for Ubuntu-only packages).  On the other hand, if that is also fixed as part of a bugfix upload, it would be nice.
[12:56] <icf7> persia: Last one, and a new package
[12:56] <persia> PriceChild: https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball
[01:19] <StevenK> asac: Oh, damn. Sorry for not checking with you before I touched gnash.
[01:20] <asac> StevenK: no problem.
[01:20] <asac> can you please submit a patch or something
[01:20] <asac> i hate picking things out
[01:20] <StevenK> asac: In other news, I looked at kover again. CFLAGS doesn't exist in configure.in or configure.in.in, and configure.ac doesn't exist, at which point my autotools knowledge buggered off, and I patched configure.
[01:20] <asac> StevenK: look at latest upload
[01:20] <StevenK> asac: Sure, it's just a changelog entry.
[01:20] <StevenK> Of kover, or gnash?
[01:21] <azeem> StevenK: CFLAGS are rarely touched in configure, AFAICT
[01:21] <asac> StevenK: ok ... can you extend that changelog entry a bit ... so i can include a good documentation in bzr branch?
[01:21] <asac> i mean ... i have no idea what this curl breakage means
[01:21] <asac> a short outline will help us to understand the case when we look in a few years ;)
[01:21] <StevenK> asac: This is a long and painful story. :-)
[01:21] <asac> StevenK: look at the latest kover upload
[01:21] <asac> i sponsored
[01:22] <asac> StevenK: anyway ... there should be a simple line to explain it ... at least better than
[01:22] <asac> just saying ... oh this was bad :)
[01:22] <asac> maybe point to a bug or something
[01:22] <StevenK> asac: http://wedontsleep.org/~steven/gnash-changelog.diff
[01:23] <asac> yeah ... please add a bug id for the breakage or something ... just a hint
[01:23] <asac> i still don't know what was going on
[01:23] <asac> e.g. what this rebuild would o
[01:23] <StevenK> They've all been uploaded, though.
[01:23] <StevenK> And retroactively changing changelog entries is naughty.
[01:23] <asac> StevenK: short story for kover ... i dropped the patch, because rene did fix it properly
[01:24] <asac> StevenK: if you are interested in the real fix ... take a look
[01:24] <asac> StevenK: rene from debian
[01:24] <asac> StevenK: thats not a problem
[01:24] <asac> StevenK: e.g changing changelog entries
[01:24] <asac> StevenK: its by far than keeping bogus entries ;)
[01:24] <asac> better
[01:24] <asac> StevenK: if anyone complains just blame me
[01:24] <StevenK> I think it is, but I'm old-school
[01:24] <asac> StevenK: i take full responsibility ;)
[01:25] <asac> old-school like not using verbous changelog entries ;) ... well
[01:25] <asac> i am old-school as well :-D
[01:25] <ajmitch> all these old farts
[01:25] <StevenK> asac: Okay, so curl released a new version which bumped the soname from 3 to 4. There are a large number of curl rdepends, and it got caught up with a number of other transitions. Debian backed out of the changes, and changed the package names back again, and had libcurl3 provide libcurl.so.4 as well.
[01:25] <asac> which is why i know that i won't understand things in a year or two if i don't document properly
[01:25] <StevenK> It's just a rebuild.
[01:26] <asac> oh ... we should have probably just sit and wait?
[01:26] <ajmitch> hello anibal 
[01:27] <asac> afaik that was done as a temporary measure to reduce the amount of transitions done at a time
[01:27] <asac> anyway
[01:27] <anibal> ajmitch, hello :)
[01:27] <ajmitch> anibal: you're in melbourne, right?
[01:27] <StevenK> asac: Now the problem is, a bunch of people in Ubuntu jumped on the curl bandwagon and rebuilt against libcurl4. Which buggered off again. pitti and I decided to bite the bullet and follow Debian, and I mass-uploaded 39 rebuilds last night.
[01:27] <asac> ok
[01:28] <asac> but there should be a bug somewhere ;)
[01:28] <asac> anyway
[01:28] <StevenK> ajmitch: Will you pop up to Sydney, too?
[01:28] <asac> its fine
[01:28] <asac> i will document it then 
[01:28] <anibal> ajmitch, yep
[01:28] <ajmitch> StevenK: I may fly into sydney, not sure
[01:28] <StevenK> It's just a rebuild, the only changes are a changelog entry, so I don't see the point of retroactively changing it.
[01:28] <ajmitch> it's all a guess at the moment, given that I haven't asked for time off
[01:28] <anibal> ajmitch, and dave hall is sitting next to me
[01:28] <ajmitch> anibal: aha :)
[01:28] <StevenK> ajmitch: Ah, fair enough.
[01:29] <asac> StevenK: yeah ... anyway it could be documented better ... i won't be really able to see in the future if that changelog entry really didn't bring any other changes then a rebuild
[01:29] <anibal> StevenK, your name was mentioned in the debconf7 lintian bof 
[01:30] <StevenK> anibal: Yeah, I got told that.
[01:30] <asac> because unfortunately its often not done proper
[01:30] <asac> ok
[01:30] <asac> thanks
[01:30] <StevenK> asac: Have you grabbed the .diff I pasted?
[01:31] <ajmitch> hello Seveas, good to see you back
[01:32] <asac> StevenK: yes
[01:32] <anibal> ajmitch, when are you coming to mel?
[01:32] <StevenK> asac: Right, I'll bin it, then.
[01:33] <ajmitch> anibal: maybe near the start of next month, I haven't planned anything yet
[01:33] <anibal> ajmitch, ok
[01:33] <Seveas> imbrandon, you here?
[01:34] <mohammad> Hello, I am debianizing a package which needs libcommons-io-java ( >= 1.1). would you please add http://packages.debian.org/unstable/libs/libcommons-io-java to universe?
[01:34] <StevenK> Damn it, remember the tabs I had open!
[01:34] <ajmitch> libcommons-io-java |      1.0-3 | http://nz.archive.ubuntu.com gutsy/universe Packages
[01:34] <ajmitch> mohammad: it's in gutsy ^^
[01:35] <Seveas> ajmitch, >= 1.1
[01:35] <ajmitch> ah yes
[01:35] <ajmitch> well the source is in gutsy
[01:35] <Seveas> ajmitch, and it's good to be back, although I'm not really back yet :)
[01:35] <ajmitch> so just fix it to build
[01:35] <Seveas> hehe
[01:36] <asac> StevenK: use a session saver extension?
[01:36] <Seveas> hmm, no imbrandon. Bummer
[01:36] <crimsun> Seveas: likely off with the family for the Fourth.
[01:37] <Seveas> crimsun, ah right
[01:37] <Seveas> forgot that it's the 4th (well, over there it still is)
[01:37] <StevenK> asac: Yeah, I just turned it on, but that doesn't bring back the 12 tabs I had open before I rebooted. :-)
[01:37] <mohammad> is it possible to add libcommons-io-java ( >= 1.1) to universe rep of gutsy? libcommons-io-java (1.0-3) is not enough for my package.
[01:38] <ajmitch> mohammad: I just said, the source is already there but failed to build
[01:38] <crimsun> http://launchpadlibrarian.net/7543640/buildlog_ubuntu-gutsy-i386.commons-io_1.3.1.dfsg.1-1_FAILEDTOBUILD.txt.gz
[01:38] <persia> StevenK: Are you running 2.0.0.4+2-0ubuntu3
[01:38] <crimsun> mohammad: ^^
[01:38] <asac> StevenK: yeah ;)
[01:38] <StevenK> persia: ... possibly
[01:39] <asac> did you manage to install ubufox persia ?
[01:39] <asac> :)
[01:39] <persia> StevenK: I had a session issue there (I promise to get back to you asac, as soon as I have more than an hour free)
[01:39] <persia> asac: Yes, but that didn't make a difference.  I suspect I'll have some time to take another look in ~10 hours.
[01:40] <asac> StevenK: if you don't have ubufox installed ... browser.js startup might be broken due to illegal homepage setting
[01:42] <StevenK> asac: Oh, this is Feisty, not Gutsy.
[01:42] <asac> ah ok
[01:42] <asac> then ... probably just human fault ;)
[01:45] <tonyyarusso> I just had a thought
[01:45] <tonyyarusso> Does gdebi check to see if there is an equal or newer version of a standalone package in the repositories before installing?  If not, it should, and suggest the user always use repos first.
[01:46] <Fujitsu> tonyyarusso: It does that already.
[01:47] <tonyyarusso> Fujitsu: Sweetness.
[01:48] <tonyyarusso> (just never tested, since all of my gdebi uses were b/c they weren't in repos)
[01:54] <mohammad>  ajmitch, crimsun: Do you have any idea when it may be resolved? Do you think it is sensible If I contact debian developer of this package (libcommon-io) and ask him for help?
[01:58] <crimsun> mohammad: you can, of course, fix it yourself :)
[02:20] <Fujitsu> Gr, why does Linux 2.6.22-7 oops when some packages attempt to touch files in /var/log or /var/run?
[02:30] <StevenK> Impressive!
[02:30] <StevenK> % dpkg-parsechangelog| grep Version
[02:30] <StevenK> Version: 1.6.4.dfsg-0ubuntu1build1
[02:30] <Fujitsu> StevenK: Is that your script that created that number?
[02:30] <StevenK> Nope, that's in the archive.
[02:31] <StevenK> I thought it was my script, but I dug deeper.
[02:31] <Fujitsu> Ah, bibletime.
[02:31] <StevenK> Yup.
[02:55] <Fujitsu> They really clutter things up.
[02:57] <anibal> ajmitch, dave hall and russell coker said we should meet with you for a beer :)
[03:00] <icf7> what section in debian/control should be chosen for a generic Java library?
[03:01] <icf7> devel, libs, misc all fit
[03:05] <ajmitch> anibal: if I'm there, it sounds like a good plan :)
[03:42] <StevenK> Sp4rKy: Where's this libtunepimp merge hiding?
[03:58] <mohammad> for the package I am debianizing http://packages.debian.org/unstable/text/liblucene2-java is needed would you please import it?
[04:00] <lousygarua> how do i run a java app and take advantage of my multiple processors? it seems to be using only one cpu
[04:05] <RAOF> lousygarua: Why are you asking this in #ubuntu-motu?  Also, the answer is "re-write the program to use multiple thread-
[04:06] <lousygarua> RAOF: i'm just asking fellow developers that i believe sit around here.. what other channel would be more suitable?
[04:07] <RAOF> lousygarua: #ubuntu, probably.  The question isn't really developer oriented :)
[04:09] <lousygarua> RAOF: i try to avoid #ubuntu... 1000 users is too much for me :)
[04:09] <RAOF> :)
[04:09] <minghua> maybe #java?
[04:10] <RAOF> Also a winner :)
[04:10] <lousygarua> minghua: does not exist
[04:10] <minghua> well, what I meant is that it's not Ubuntu specific.
[04:10] <minghua> I don't write Java myself, and don't know which channel to ask questions.
[04:11] <lousygarua> minghua: i don't write java myself, but i'm giving a test-drive to eclipse and noticed this funny 1 cpu behaviour
[04:12] <mohammad> I will be thankful if some one help me: for the package I am debianizing http://packages.debian.org/unstable/text/liblucene2-java is needed would you please import it?
[04:12] <ajmitch>    lucene2 |    2.1.0-1 | http://archive.ubuntu.com gutsy/multiverse Sources
[04:13] <ajmitch> again, it failed to build, fix it & it will be available
[04:14] <Fujitsu> lousygarua: This `funny 1 cpu behaviour' is how the vast majority of applications work. Not many have multiple threads.
[04:14] <lousygarua> Fujitsu: well, yeah. but when u run a java/python app the virtual machine should be smart enough to make it multi-threaded - IMHO that is
[04:15] <ajmitch> heh
[04:15] <ajmitch> lousygarua: it doesn't work like that - programs have to be explicitly written to use threading
[04:15] <RAOF> lousygarua: That'd be one seriously buggy VM :)
[04:16] <ajmitch> you may be able to start to do that in pure functional languages
[04:17] <Fujitsu> But not in anything like Python or Java... You can't just magically turn something into a SMP-capable app.
[04:17] <mohammad> ajmitch: would you please give me some clue why some source which can be debianized on a debian machine cannot be debianized on ubuntu?
[04:17] <ajmitch> mohammad: dependencies?
[04:17] <Fujitsu> mohammad: Your best bet is to check the build log.
[04:18] <ajmitch> at least the libcommons-io-java appears to be missing an appropriate java compiler
[04:18] <lousygarua> Fujitsu:  hmm.. didn't think about. well i'm trying eclipse so i guess it is multithreaded aware - but i might be wrong again.
[04:19] <ajmitch> only because it's been written in such a manner
[04:20] <mohammad> Fujitsu, ajmitch: but it debianized by my pbuilder-etch now I am trying to debianized it by pbuilder-gutsy
[04:22] <Fujitsu> Riiight. Why does reportbug default to routing through fiordland? That's not going to work in 99% of cases.
[04:22] <RAOF> lousygarua: It's not that it's not "multithread aware" (whatever that means), it's that the the coders haven't explicitly spawned multiple threads doing different things.  Probably partially because there really doesn't seem like there's much scope for parallelism.
[04:23] <mohammad> Fujitsu, ajmitch: it is also debianized successfully with my pbuilder-gutsy. If there is any dependency probrem then I think it shouldn't be debianized on my machince either. Am I right? Maybe I need more clue :)
[04:24] <lousygarua> RAOF: yes i understand basic multithreaded programming but my english is horrible and it may seem as if i am a complete noob that have no idea what he's talking about. but thanks for your help of course
[04:25] <RAOF> lousygarua: Sorry :)
[04:26] <Fujitsu> Do we still have to manually tag apport bugs? I see some from a few days ago (by Gutsy's apport) that haven't been retraced yet...
[04:27] <lousygarua> RAOF: i'm also too tired to think about multithreading right now. so my questions are even stupidier than usual
[04:29] <minghua> For the record, lucene2 failed to build last time because Sun Java failed to install.  Sounds like a good give-back candidate.
[04:34] <Fujitsu> minghua: Why? Java prompts for acceptance of the EULA; I don't think that's fixed.
[04:36] <minghua> Fujitsu: let me read the build log again
[04:36] <minghua> Fujitsu: I see.  You are right.
[04:37] <minghua> In that case all Sun Java build-depended packages should FTBFS.
[04:37] <Fujitsu> They do.
[04:37] <Fujitsu> batik, for example.
[04:37] <Fujitsu> This is a problem.
[04:39] <Fujitsu> I've really got no idea how to fix it, unless we get them working with a Free Java.
[04:40] <minghua> Neither do I.  And I doubt that is a problem MOTU can solve by ourselves.
[04:41] <ajmitch> what do you mean, if?
[04:42] <Fujitsu> ajmitch: It looks somewhat like the LP freeing.
[04:42] <ajmitch> they already have
[04:42] <ajmitch> see openjdk.java.net
[04:42] <Fujitsu> Not the normally runtime, though.
[04:43] <Fujitsu> *normal
[04:43] <ajmitch> there are even packages of 'icedtea' available
[04:43] <Fujitsu> Hah.
[04:43] <minghua> I heard there are efforts to mix Sun's free java parts and other opensource java implementations (classpath?)
[04:44] <ajmitch> yes, icedtea is one such temporary fork
[04:44] <ajmitch> name changed for trademark reasons, etc
[04:47] <minghua> Oh, so it's the coffee vs. tea thing.  In that case I should support icedtea based on name alone. :-P
[04:48] <Fujitsu> Yay, tea.
[04:48] <ajmitch> http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5
[04:50] <minghua> Shouldn't making icedtea self-bootstrapable good enough?
[04:51] <ScottK> Fujitsu: Is there a bug for "[20:20]  <Fujitsu> Gr, why does Linux 2.6.22-7 oops when some packages attempt to touch files in /var/log or /var/run?"?
[04:52] <Fujitsu> ScottK: There are 3 I know of.
[04:53] <Fujitsu> One of which I filed. One of which a friend filed. One other I saw.
[04:53] <Fujitsu> They're different oopses, strangely.
[04:53] <ScottK> Fujitsu: There's a clamav bug that has similar symptoms and so I thought I'd dupe it to something if there was a good master bug.
[04:54] <ScottK> Bug 124095
[04:54] <Fujitsu> bug #124095
[04:55] <ScottK> https://bugs.launchpad.net/bugs/124095
[04:56] <Fujitsu> ScottK: Ah, right, I reassigned that to linux-source a few hours back. I know too little about Linux to dupe it.
[04:56] <ScottK> Fujitsu: Do you know if we are supporting Python 2.4 in Gutsy?  I'm having a heck of a time get a 2.4 only package to build.
[04:56] <Fujitsu> ScottK: I haven't heard anything about it being dropped, and we need it for Zope and the like.
[04:57] <ScottK> Ah.  No wonder I didn't get the bugmail.  I only get bugmail for clamav and it was, of course, no longer a clamav bug.  Thanks.
[04:57] <Fujitsu> So I can't see it vanishing in the next couple of releases.
[04:57] <Fujitsu> ScottK: You don't get bugmail when it leaves your territory? That sounds like a bug.
[04:58] <minghua> ScottK: I am annoyed by that bugmail thing too.
[04:58] <minghua> Anyone knows if that's already reported?
[04:58] <ScottK> Nope.  Only bugmail I got from Fujitsu tonight was about python-scientific.
[04:59] <ScottK> Fujitsu: OK (about python 2.4), which version do we have in the archive for Gutsy: https://launchpad.net/ubuntu/+source/python-defaults
[05:00] <Fujitsu> ScottK: 2.5.1-1ubuntu2
[05:00] <ScottK> Fujitsu: Which version of Python 2.4?
[05:00] <ajmitch> root@augustine:/etc/apache2/sites-enabled# apt-cache madison python2.4 python2.4 | 2.4.4-4ubuntu1 | http://ajmitch.net.nz gutsy/main Packages
[05:00] <ajmitch> sorry about it being on 1 line, but 2.4.4 looks to be it
[05:01] <Fujitsu> ScottK: Ah, what ajmitch said.
[05:01] <ScottK> OK.  Here's my problem... /bin/sh: python2.4: not found on the buildd's.
[05:01] <ajmitch> Fujitsu: seen -devel?
[05:01] <Fujitsu> william@irranat:~/MOTUing$ rmadison -u ubuntu -s gutsy python2.4 python2.4 | 2.4.4-4ubuntu1 |         gutsy | source, amd64, i386, powerpc
[05:01] <ajmitch> ScottK: right build-depends?
[05:01] <Fujitsu> What the &$#@ is he doing there?
[05:02] <ajmitch> don't ask
[05:02] <Fujitsu> Oh no... StevenK didn't post in the forum, did he?
[05:02] <ScottK> Yep.  I even changed it to python-dev (< 2.5) and got a FTBFS on my pbuilder.
[05:02] <ajmitch> I hope not
[05:02] <ajmitch> I know that laserjock posted
[05:02] <Fujitsu> ajmitch: Right.
[05:02] <ajmitch> ScottK: python2.4-dev?
[05:03] <Fujitsu> ScottK: python-dev won't work
[05:03] <ScottK> No, he talked to him within the last 24 hours on the libcurl thing.
[05:03] <Fujitsu> What ajmitch said.
[05:03] <ScottK> OK.  I'll try that.
[05:03] <Fujitsu> ScottK: Oh, poor him :( He hasn't got a chance.
[05:04] <minghua> I think asking for a rebuild of openoffice is not a very bad thing?
[05:05] <ubotu> Launchpad bug 124095 in linux-source-2.6.22 "Gutsy Clamav update configuration fails segfault error" [Undecided,New]  https://launchpad.net/bugs/124095
[05:05] <ScottK> ubotu rises from the dead ...
[05:05] <minghua> Of course by track record I know I probably should read the past logs.
[05:05] <Flannel> And with a vengeance
[05:05] <ajmitch> minghua: it may push him over the edge
[05:06] <ScottK> His fault.  He talked to him.  No no one to blame but himself.
[05:08] <minghua> The IRC logs seem fine.  I may need to read forums to see what havoc he is really causing.
[05:09] <minghua> (and I don't want to go to forums)
[05:09] <Fujitsu> minghua: Mostly mailing lists, actually.
[05:09] <minghua> Fujitsu: I know that part.  That's why I said "track record".
[05:09] <Fujitsu> Ah.
[05:10] <ScottK> By the time he found IRC, I think most people knew what they were dealing with.
[05:10] <Fujitsu> ScottK: I hope/suppose so.
[05:11] <ScottK> python2.4-dev did the trick.  Thanks.  So I guess for debian it would be python2.3-dev | python2.4-dev.
[05:13] <ScottK> Where are we on the libcurl thing anyway?  Is it safe to update my pbuilder yet?
[05:14] <Fujitsu> ScottK: I think all but apt and OOo are fixede.
[05:14] <Fujitsu> s/e.$//
[05:14] <ScottK> Fujitsu: Thanks.
[05:15] <Fujitsu> I was able to build various things, and things that depend on it seem to run again.
[05:26] <StevenK> Fujitsu: No, I didn't.
[05:26] <StevenK> There's apt, OO.o, and libtunepimp. I think.
[05:27] <StevenK> (Sp4rKy mentioned that he had a libtunepimp merge ready, so I was going to use that instead of doing my own rebuild.)
[05:29] <ajmitch> ScottK: debian should not be using python2.3-dev
[05:29] <ajmitch> unless you're doing things for sarge
[05:29] <ajmitch> Hobbsee!
[05:29] <ScottK> ajmitch: OK.  Great.  Thanks.
[05:29] <Fujitsu> Hi Hobbsee.
[05:29] <ajmitch> ScottK: you also should use python-all-dev, iirc
[05:30] <ajmitch> on etch, that has:
[05:30] <ajmitch> Depends: python-all (= 2.4.4-2), python-dev (= 2.4.4-2), python2.4-dev
[05:31] <Hobbsee> ajmitch!
[05:31] <Hobbsee> hiya Fujitsu!
[05:32] <ScottK> Good morning Hobbsee
[05:33] <Hobbsee> morning ScottK!
[05:39] <StevenK> Hrm.
[05:39] <StevenK> 60 rebuilds, and 3 build failures on all archs.
[05:40] <Fujitsu> StevenK: Three failed on all archs, or three arch builds failed?
[05:44] <Fujitsu> Hobbsee: I note you adjusted reportbug to send all mail through fiordland. Isn't that likely to not work very well?
[05:44] <Hobbsee> Fujitsu: it only works for ubuntu members, yes.
[05:44] <StevenK> Fujitsu: 3 of the former, and 3 of the latter.
[05:44] <Hobbsee> Fujitsu: still, having that rather than no smtp servr at all...isnt so great either
[05:45] <ScottK> What mailing address does reportbug use to send mail from?
[05:45] <Fujitsu> Hobbsee: Hard to say...
[05:45] <StevenK> ScottK: DEBEMAIL, usually
[05:46] <ScottK> OK.
[05:46] <ScottK> In that case, I think the default is also problematic for a subset of members too.
[05:46] <ScottK> In my case mail sent through fiordland will fail my SPF policy since I don't include that.
[05:47] <ScottK> Does reportbug relay on port 25?
[05:48] <minghua> Is REVU working?  I can't post comments.
[05:48] <ScottK> If so, it's gonna fail for people who's ISP's block port 25 for spam abatement.
[05:48] <Fujitsu> I've never got around to setting a SPF record on my domain, though I've done it at work.
[05:48] <ScottK> Fujitsu: Cool.
[05:48] <Fujitsu> minghua: Does it give you an error message?
[05:49] <minghua> Fujitsu: Yes.  http://paste.ubuntu-nl.org/28587/
[05:49] <Fujitsu> I set it up at work within I few daays of starting there, as we were having a lot of spammers falsifying From addresses from us.
[05:49] <ScottK> It wouldn't hurt (much) to set it up pre-emptively for your own domain too.
[05:49] <Fujitsu> minghua: Well, looks like your comment is incredibly long.
[05:50] <Fujitsu> Probably not. I just never got around to it.
[05:50] <ScottK> minghua: What Fujitsu said.  Make a shorter comment and it will be fine.
[05:51] <minghua> Err...  Thanks ScottK and Fujitsu.
[05:51] <Fujitsu> VARCHAR(2048) should be enough for most comments, I think.
[05:51] <ScottK> minghua: It isn't random that I know what causes that error...
[05:51] <ajmitch> Fujitsu: evil
[05:52] <Fujitsu> ajmitch: What?
[05:52] <Fujitsu> Using static-length types?
[05:52] <minghua> Yes, cutting my comment in two parts worked.
[05:53] <minghua> But (1) it discourages detailed review; and (2) I would prefer a less cryptic error message, or better, a page says "your comment is too long".
[05:54] <minghua> I realize everyone is busy though, so I'll shut up now until I want to help REVU code.
[05:54] <StevenK> Hrm. Yay, the FTBFSes are all failed to install packages as opposed to anything else.
[05:54] <ScottK> minghua: The code is in bzr and ajmitch accepts patches. ;-)
[05:54] <ajmitch> Fujitsu: TEXT?
[05:55] <ajmitch> at least postgresql doesn't suck like mysql w.r.t varchar
[05:55] <Fujitsu> ajmitch: That is what I would have chosen, but from what I recall it's not that easy in Postgres.
[06:01] <crimsun> bah, soyuz ate my upload again.
[06:03] <Fujitsu> crimsun: It has been doing that a bit lately. Anything special in the changelog like URLs or bug numbers?
[06:03] <crimsun> yes, 25 closed LP bugs.
[06:03] <minghua> Fujitsu: If you have time, I would appreciate your comment for http://revu.tauware.de/details.py?upid=5694 on the static library issue.
[06:04] <ScottK> Yeah.  https://wiki.ubuntu.com/MOTU/Clamav got it's first report of testing the new clamav on Dapper...
[06:04] <minghua> Or any other MOTU who care about science related packages / static libraries.
[06:04] <Fujitsu> ScottK: Let me guess. It doesn't work?
[06:04] <ScottK> Actuall it did.
[06:04] <Fujitsu> minghua: Looking, though I know little about libraries.
[06:04] <ScottK> Related comment is that maybe the package in question doesn't need clamav as a dep. 
[06:04] <ScottK> That might explain why it worked....
[06:05] <minghua> ScottK: LOL
[06:05] <Fujitsu> ScottK: Hahaha.
[06:09] <Hobbsee> StevenK: libtunepimp?
[06:09] <Fujitsu> StevenK: Should anything still depend on libcurl4*?
[06:09] <Hobbsee> StevenK: libtunepimp5 does - please fix
[06:10] <Hobbsee> :)
[06:10] <Fujitsu> Hobbsee: There's a merge from Sp4rKy that'll fix that.
[06:11] <StevenK> Fujitsu: Depend? No.
[06:12] <crimsun> hmph.  /dev/null'd a second time, or the accept is _really_ lagged.
[06:12] <Hobbsee> Fujitsu: right.  cant see it on teh sponsors list
[06:12] <StevenK> Hobbsee: He spoke about it here, last night.
[06:13] <Fujitsu> crimsun: Ask cprov about it. Security uploads have been eaten for reasons such as permissions on CVE tables, so it's almost impossible for a non-god to work out what's killing it.
[06:13] <StevenK> Hobbsee: I told him to wait, since I was in the middle of trying evil hacks with Fujitsu's help.
[06:13] <Fujitsu> Oh, sure, I helped a lot :P
[06:13] <Hobbsee> ah
[06:13] <StevenK> Yes, you did.
[06:15] <Hobbsee> StevenK: it'd be good if you could get that one fixed though - people dont like amarok dying...
[06:15] <Fujitsu> Hobbsee: It's just telling them they should use GNOME. That's no problem.
[06:15] <StevenK> Okay, I'll do a rebuild.
[06:15] <Fujitsu> StevenK: I've got it done locally.
[06:16] <minghua> crimsun: I've also heard that an upload triggered a bug in LP about closing bugs.
[06:16] <Fujitsu> Thought your script is probably faster.
[06:16] <StevenK> I can do it in about a minute.
[06:16] <Fujitsu> There was some strange permissionish stuff with changelog-closes-bugs and various other pieces of deep magic which causes some to fail, depending on the state of the bug.
[06:17] <StevenK> Uploaded.
[06:17] <Hobbsee> Fujitsu: hah.
[06:17] <StevenK> Hobbsee, Fujitsu: ^
[06:17] <Fujitsu> Bug #123968, for example.
[06:17] <ubotu> Launchpad bug 123968 in soyuz "broken security upload" [Critical,Fix committed]  https://launchpad.net/bugs/123968
[06:18] <Fujitsu> StevenK: How long ago did you upload that last batch of curl rebuilds?
[06:18] <StevenK> Um.
[06:18] <StevenK> A little more than 3 hours ago.
[06:18] <Fujitsu> All the buildds are idle, so I think they should probably be published.
[06:18] <Fujitsu> Right.
[06:19] <Fujitsu> I just apt-get updated, but there are still 31 things depending on libcurl4-gnutls. They must have missed the publisher last hour.
[06:20] <StevenK> I have this feeling that libcurl4-gnutls was missed to archive-cruft-checker not telling me.
[06:20] <StevenK> Fujitsu: Can you mail that list to me?
[06:21] <crimsun> wow
[06:21] <Hobbsee> sarah@LongPointyStick:~$ rdepends libcurl4-gnutls | wc -l
[06:21] <Hobbsee> 29
[06:21] <Hobbsee> yummy
[06:21] <crimsun> that's ... sick.  So if I strip the correct changelog syntax, it will be accepted?  Hmph.
[06:22] <Fujitsu> crimsun: Probably. It's all rather stuffed up at the moment
[06:22] <Fujitsu> StevenK: stevenk@u.c?
[06:22] <StevenK> Wait.
[06:22] <StevenK> libcurl4-gnutls was in the last bunch.
[06:23] <Fujitsu> bibletime is in there, so it's probably just not published.
[06:23] <StevenK> bibletime failed.
[06:25] <Fujitsu> Aha. Convenient.
[06:28] <StevenK> Fujitsu: bibletime and gnomesword failed due to sword, which was uploaded a little while ago.
[06:29] <Fujitsu> StevenK: Aha. moc and a number of others on the rdepends list I had seem to have been uploaded in the last batch, so there isn't a whole group you've missed.
[06:29] <StevenK> In which case it's the archive and mirrors being slowish
[06:30] <StevenK> I thought it was forty, though. It's at 62 currently.
[06:30] <Fujitsu> achive.u.c should be updated in 10-15 minutes.
[06:33] <Fujitsu> Hm... X crashed, and the kernel oopsed... How odd.
[06:37] <StevenK> I daresay a whole bunch of libtunepimp/amarok bugs will be filed. Bug 123851 has one dupe already, so people can merge into it.
[06:37] <ubotu> Launchpad bug 123851 in libtunepimp "amarokapp: libcurl-gnutls.so.4: version `CURL_GNUTLS_4' not found (required by /usr/lib/libtunepimp.so.5)" [Undecided,Fix released]  https://launchpad.net/bugs/123851
[06:40] <crimsun> sounds like a bughelper-data candidate.
[06:44] <StevenK> crimsun: Grrm, hum?
[06:44] <Fujitsu> crimsun: It's not going to be around for long enough to warrant that, I don't think.
[06:45] <crimsun> StevenK: meaning one might consider writing a cluefile [https://wiki.ubuntu.com/BugHelper/doc/writing-clue-files]  for bughelper-data
[06:48] <Hobbsee> i only saw 2
[06:59] <StevenK> Oh, twitch.
[06:59] <StevenK> steven@liquified:~% du -sh ubuntu/curl-cruft                                    715M    ubuntu/curl-cruft
[06:59] <Fujitsu> Hahah
[07:00] <StevenK> 2 packed, and 1 unpacked sources for 62 source packages, a few other files
[07:01] <StevenK> Fujitsu: Has the unmet list for libcurl4-gnutls dropped again, or do we need to wait for another mirror pulse?
[07:02] <Fujitsu> StevenK: They seem to be on a.u.c now.
[07:02] <StevenK> Almost all of them?
[07:03] <Fujitsu> StevenK: rdepends shows a lot of cruft due to my local mirror being outdated, so I'll remove it and check...
[07:03] <StevenK> Fujitsu: Thanks.
[07:03] <Fujitsu> william@irranat:~$ apt-cache rdepends libcurl4-gnutls | wc -l
[07:03] <Fujitsu> 13
[07:04] <StevenK> Can you dump that in a /query?
[07:04] <Fujitsu> Sure.
[07:25] <DarkMageZ> does anyone recommend any particular guide for learning how to read and hack apart autotool files? (eg configure.ac & makefile.am)
[07:26] <crimsun> sourceware.org/autobook/
[07:47] <RAOF> DarkMageZ: I was just looking at your non-debdiff.  After patching configure.ac and Makefile.ams, you can manually patch configure and the various Makefile.ins.  That'll reduce the debdiff from megabytes down to a few kb
[07:48] <RAOF> It's actually less hard than it sounds :)
[07:50] <DarkMageZ> RAOF, that would require skills i don't have and can't yet justify learning. the new debdiff results in a .diff of only < 700KB. which is smaller than the original.
[07:53] <RAOF> Ok.  I'm not sure how willing people will be to upload it in its current state.
[07:53] <Fujitsu> A smaller diff is better. I'm not going to really want to review a 700KB diff.
[07:54] <crimsun> pfft.  It's smaller than an Azureus debdiff.
[07:54] <RAOF> DarkMageZ: I may get around to doing it for you, but I can't promise anything soon.
[07:54] <StevenK> How can you review a 700KB diff?
[07:54] <StevenK> Aside from very slowly
[07:54] <DarkMageZ> it's smaller and tidier than the current ubuntu one. i can't soon do better than that...
[07:56] <RAOF> Yeah, but the debdiff is > 1Mb, right?
[07:56] <DarkMageZ> yeah. but that's cause we tidied the package up too efficiently.
[07:57] <DarkMageZ> i could take out the autoconf.patch and run it directly against the sources. that'd drop it down a stackload
[07:57] <DarkMageZ> but then it'd be a dirty package (tho still cleaner than the ubuntu one)
[07:59] <RAOF> If you left the debian changes as they are, and just added the patches, it'd be much, much smaller
[07:59] <Hobbsee> hiya RAOF 
[08:00] <RAOF> The size of the .diff.gz is (I believe) less important than the size of the divergence from debian.
[08:00] <RAOF> Hey Hobbsee!
[08:00] <Fujitsu> RAOF is correct.
[08:00] <Hobbsee> :)
[08:02] <Fujitsu> I think it's my secondary keymap.
[08:04] <RAOF> Hobbsee, StevenK: we should get together sometime with jml when he's up (and staying with me)
[08:04] <Hobbsee> RAOF: that'd be cool.  and lifeless and spiv?
[08:04] <Hobbsee> RAOF: if we're going to have a proper ubuntu meeting and all...
[08:05] <RAOF> Yeah, why not :)
[08:05] <StevenK> Sounds fine to me.
[08:06] <jml> indeed
[08:06] <RAOF> I think I've met at least one of lifeless and spiv, but I have a rotten memory!
[08:06] <jml> RAOF: you've met spiv
[08:06] <RAOF> See.  jml is my external storage :)
[08:07] <StevenK> Fujitsu: Oh yes, I can see the parents agreeing to that. :-P
[08:07] <Fujitsu> Yep, definitely.
[08:09] <StevenK> Hobbsee: libtunepimp should hit archive.u.c soonish, the publisher is running at the moment.
[08:09] <StevenK> Fujitsu: Ditto with sword.
[08:10] <Hobbsee> StevenK: excellent
[08:10] <Hobbsee> :)
[08:10] <Fujitsu> StevenK: They've been there since the last run.
[08:10] <Fujitsu> I've even got them on my local mirror.
[08:11] <StevenK> Huzzah
[08:11] <StevenK> Now to wait for pitti or Mithrandir to appear.
[08:11] <Fujitsu> For various givebacks?
[08:12] <Fujitsu> Or removal?
[08:12] <StevenK> Give backs
[08:12] <Fujitsu> You might be able to poke infinity about that.
[08:12] <StevenK> I don't mind waiting.
[08:13] <Hobbsee> infinity lives on european time even more than i do.
[08:13] <Hobbsee> last i knew, anyway
[08:13] <StevenK> Heh
[08:13] <Sp4rKy> StevenK: hi
[08:14] <StevenK> Sp4rKy: Hey. You'll need to update your merge, I did an upload of libtunepimp
[08:14] <Sp4rKy> StevenK: the merge debdiff is at http://paste.dunnewind.net/3
[08:14] <Sp4rKy> do you think a rebuld will be enough ?
[08:14] <Sp4rKy> or does version number have changed ?
[08:15] <StevenK> I thought we already included libtunepimp5-mp3?
[08:15] <Sp4rKy> yep
[08:15] <StevenK> Hobbsee: Help? ^
[08:16] <Hobbsee> we already have that in the archive, yes
[08:16] <StevenK> Oh right, it's a diff from Debian
[08:16] <Sp4rKy> StevenK: check debdiff line 183~
[08:17] <Sp4rKy> StevenK: it's the final debdiff yes
[08:17] <StevenK> Sp4rKy: Why the debian/libtunepimp5.install change?
[08:18] <StevenK> Sp4rKy: In terms of updating your debdiff, you'll need to grab the changelog entry of what I uploaded about an hour and a half ago.
[08:18] <StevenK> Oh, never mind. I see why.
[08:23] <Sp4rKy> ok
[08:24] <Sp4rKy> StevenK: is it 7.16.2-6ubuntu4 ?
[08:24] <StevenK> curl is, yes
[08:25] <Sp4rKy> ok
[08:26] <Sp4rKy> anyway, i don't understand why the change of curl is important for libtunepimp
[08:26] <Sp4rKy> (except the version number maybe)
[08:26] <Hobbsee> because libtunepimp uses curl...
[08:26] <Hobbsee> so, when curl changes, so does libtunepimp...
[08:26] <Sp4rKy> and ..
[08:27] <Sp4rKy> yes, of course
[08:27] <Sp4rKy> but in that case, a rebuild of libtunepimp should be enough, no ,
[08:27] <Sp4rKy> ?
[08:27] <StevenK> Yes, which I've done.
[08:27] <Hobbsee> which is what StevenK's already done.
[08:27] <Hobbsee> :)
[08:28] <Sp4rKy> and so , i don't understand what i've to change in the merge :)
[08:28] <StevenK> You need to add my changelog entry
[08:28] <Sp4rKy> the changelog entry of what ?
[08:28] <Sp4rKy> not of curl ?
[08:29] <Hobbsee> of the rebuild about curl
[08:29] <Sp4rKy> oh ok :)
[08:30] <Sp4rKy> so i have to grab the changelog entry of the libtunepimp update
[08:30] <Sp4rKy> and not of curl ^^
[08:30] <StevenK> Right
[08:31] <Sp4rKy> ok
[08:31] <Sp4rKy> i do that now
[08:34] <porthose> Vollmer your probably aware of this site but just in case your not check it out http://www.php-security.org/
[08:41] <Sp4rKy> StevenK: there smthg i don't understand
[08:41] <Sp4rKy> your changelog entry just said 'Rebuild for libflac transition.' , right ?
[08:43] <StevenK> Right.
[08:44] <Sp4rKy> StevenK: i thought i don't need to include the changelog entries about rebuild in the debdiff
[08:44] <StevenK> Sp4rKy: You need to include all changelog entries, and that's now one of them.
[08:45] <Sp4rKy> StevenK: oh ok ^^
[08:45] <Sp4rKy> jsut understand
[08:45] <Sp4rKy> i don't have to include this line in my entry, but to include the entry in the diff
[08:45] <StevenK> Exactly.
[08:46] <Sp4rKy> ok
[08:46] <Sp4rKy> seems clear :)
[08:56] <Sp4rKy> StevenK: can you check http://paste.dunnewind.net/6 and say if i can upload to lp ?
[08:57] <StevenK> It looks okay
[08:58] <Sp4rKy> so i can upload it ?
[09:10] <tepsipakki> Seveas: congrats on falcon2 :)
[09:24] <Sp4rKy> StevenK: #124145
[09:28] <dholbach> good morning
[09:28] <Sp4rKy> hi
[09:28] <dholbach> hi Sp4rKy
[09:44] <dholbach> Bixente: gfreqlet is nearly ready to go - I added another small comment
[09:44] <dholbach> Bixente: good work!
[12:02] <shawarma> Seveas: Yay! Welcome back!
[12:04] <shawarma> Seveas: Could you have ubotu join #ubuntu-server?
[12:07] <cbx33> hey all
[12:16] <shawarma> -win 4
[12:18] <\sh> gmrpf...did anybody tried to compile the cpqrid driver from hp on a kernel newer then 2.6.5?
[12:54] <nomad_> hey
[12:54] <Fujitsu> Hi nomad_.
[12:54] <nomad_> hey, can anyone help me with my makefile? http://www.ubuntuusers.de/paste/12461/?format=txt in the folder in which the makefile is exists a file named "example.tex", but with "make" nothing happens
[12:55] <azeem> nomad_: there's no intrinsic for .tex, you will have to write your own rule I guess
[12:55] <azeem> oh, which you did
[12:56] <nomad_> *looking up the word "intrinsic" :D
[12:57] <nomad_> oh, okay ... and how would this rule look like?
[12:57] <azeem> never mind, I just didn't look at the paste before I typed
[12:57] <nomad_> ah okay
[12:57] <nomad_> and whats wrong otherwise
[12:59] <persia> nomad_: You need to use * instead of % for wildcard (see http://www.gnu.org/software/make/manual/make.html#Wildcards)
[01:00] <jussi01> morning all
[01:01] <nomad_> ahh... okay now i know :)
[01:08] <nomad_> okay just another question
[01:08] <nomad_> http://www.ubuntuusers.de/paste/12462/?format=txt
[01:09] <nomad_> how can i make my makefile using "clean" after it has compiled my pdf files?
[01:11] <coNP> add clean to all
[01:11] <persia> nomad_: Add a clean: rule that deletes the generated files.
[01:11] <coNP> I mean all: <deps>\n\tclean
[01:11] <persia> (e.g. rm *.pdf)
[01:11] <coNP> persia: it is present
[01:12] <nomad_> ah okay .. i added the rule to all
[01:12] <persia> .me looks at the paste again
[01:19] <nomad_> i even saq that my clean function does not work. how can i get the value of % on my clean target? is that even possible?
[01:21] <persia> nomad_: You probably want * again, as you're passing an argument to rm
[01:23] <nomad_> and there is no chance to get the value of "%"? because "*" would delete files which arn't involved, files that exists before the other fiels are beeing created
[01:24] <persia> nomad_: You could define a variable that contained a list of the files with basename and wildcard, and then do something with a clean-% rule.
[01:27] <persia> nomad_: Just for clarity, % only has local meaning, either within a function, or in a rule name.  There's no global %.
[01:28] <nomad_> d'you mean this? BASENAMES	= $(patsubst %.tex, %, $(wildcard *.tex))
[01:29] <nomad_> yeah it works
[01:29] <nomad_> thanks :)
[01:30] <persia> nomad_: Right.  That gives you a variable that can later be expanded, either with $(foreach var,list,text) or perhaps somthing else.
[01:31] <persia> nomad_: Just for simplicity, you might also want to use that BASENAMES in all, so you don't have to process the wildcard twice.
[01:33] <nomad_> oh, right ^^ thanks for the tip
[01:35] <Fujitsu> Hm, libfilesys-diskspace-perl fails rather strangely on the buildds, but not on the localhost system, pbuilder, or schroot:
[01:35] <Fujitsu> http://launchpadlibrarian.net/8314534/buildlog_ubuntu-gutsy-i386.libfilesys-diskspace-perl_0.05-11_FAILEDTOBUILD.txt.gz
[01:35] <Fujitsu> s/host//
[02:03] <coNP> StevenK: please have a look at my openbox & obconf packages, if you have some time
[02:06] <StevenK> coNP: Oh dear God, no. I've done 63 uploads in the past 24 hours.
[02:06] <coNP> StevenK: sorry
[02:06] <StevenK> coNP: It's okay, it's not your fault. :-)
[02:10] <xxxxx1> morrrning people
[02:49] <mruiz> hi all
[02:55] <_16aR_> Hello mruiz
[02:56] <_16aR_> I've got a question : If an upstream program is called : xxx-2006-08-11, must I use this as version like that : xxx-20060811 ?
[02:56] <persia> _16aR_: No, but you'll find life easier if you do.
[02:58] <_16aR_> persia: lol
[02:59] <_16aR_> persia: since I've read that : http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1, I wasn't sure if it applied to mine upstream prgs too
[03:00] <_16aR_> so I think it is really needed (and since it makes my life easier, it's great :p)
[03:02] <_16aR_> thanks persia
[03:02] <persia> _16aR_: From my reading of that, it looks like you are supposed to use xxx-2006-08-11-XubuntuY, but hyphens are annoying and confusing
[03:03] <persia> _16aR_: If you have influence over upstream, 20060811 would be a preferable date format.
[03:04] <_16aR_> persia: I'm not english, what are hyphens ? And I really didn't read that (I didn't finish the page ;)) Is there a Ubuntu Policy Manual ?
[03:04] <axxo> '-' == hyphen
[03:05] <_16aR_> persia: At the moment, there is only 1 release of their prog, I don't know if they are moving to another release
[03:05] <_16aR_> I'll check the svn activity
[03:05] <persia> _16aR_: A hyphen is a specific character that looks somewhat like '-', but are easily confused with minus signs (I'm not sure which I typed).
[03:05] <_16aR_> oh
[03:05] <persia> Also, the Debian policy manual is in better shape at the moment, and a better source of guidelines.
[03:05] <_16aR_> for me minus and hyphen are the same
[03:06] <_16aR_> it 's the same key on my keyboard though
[03:06] <persia> They have different unicode representations (which matters for manpages, or other formatted documents).
[03:07] <axxo> ppl really care and not just use -,
[03:07] <axxo> ?
[03:08] <persia> axxo: If you're working with a formatted document, and you get the wrong one, cut & paste to the command line doesn't do what you expect.  For most purposes, it's safe to confuse them.
[03:09] <persia> s/cut/copy/
[03:10] <axxo> persia: so minus is the correct one the use then
[03:11] <axxo> don't bother
[03:14] <persia> (already did :))  Debian versioning uses hyphen (not minus) to separate version from revision.  Shell arguments take minus (not hyphen).
[03:14] <axxo> same char in ascii
[03:15] <persia> Of course, the '-' character on the keyboard is handled the right way in both cases :)
[03:15] <axxo> so same char everywhere that mathers
[03:15] <persia> axxo: Right.  Unless you're working with formatted text (manpages, webpages, etc.), it doesn't matter.
[03:16] <DarkSun88> Hi all
[03:22] <persia> Does anyone feel that http://lists.debian.org/debian-devel-announce/2007/07/msg00000.html should be a target for Gutsy?
[03:24] <Hobbsee> persia: i'd imagine that's something we'd pick up in gutsy+1 - we dont really have the resources now
[03:24] <Hobbsee> as in, it's not really changes we want to make ourselves
[03:24] <Hobbsee> er, affected
[03:25] <persia> Hobbsee: That's what I'm thinking.  I'll send something to devel-discuss@ & ubuntu-motu@ asking that any merges / syncs take the fact that we're not migrating into account for gutsy (I expect we'll see more merges than syncs as a result).
[03:25] <Hobbsee> true
[03:25] <persia> Hobbsee: Thoulsands :)
[03:26] <Hobbsee> yeah, i was expecting that one :(
[03:26] <persia> Right then.  Starting up the mail client :)
[03:27] <siretart> persia: I think we are focusing rather on having proper .desktop files
[03:28] <siretart> so we generally don't need menu files
[03:28] <persia> siretart: Is fixing all the .desktop files a gutsy goal?  I thought it was a do-as-we-can goal.  Regarding menu files, I'd just prefer nobody who enables it has a broken Debian menu.
[03:30] <siretart> persia: fixing/providing .desktop files is a general ubuntu goal which is done on a best efford basis
[03:38] <persia> Any comments or suggestions regarding my draft mail ( http://pastebin.ca/604335 )?
[03:41] <Hobbsee> persia: presumably doing part of these changes only wont work?
[03:42] <persia> Hobbsee: If we move to menu 2.1.35 without updating the menu files, we'll have dropouts in the menus.  If we get new menu files that don't match the 2.1.34 hierarchy, I'm not sure if we'll get an error or dropouts (not tested).  Either is not entirely desireable.  On the other hand, this probably only affects a few thousand users: most people just use the .desktop files.
[03:43] <Fujitsu> > Shall packages implementing the new menu policy conflict with
[03:43] <Fujitsu> > menu (<< 2.1.35) ?
[03:43] <Fujitsu> They shall not. All menu version >=2.0 understand both the new and the
[03:43] <Fujitsu> old menu structure. 
[03:43] <man-di> persia: afaik support was introduced in menu 2.0, it was just announced to do the transition now
[03:44] <Hobbsee> persia: also, this is a main thing, so please CC ubuntu-devel@
[03:44] <Hobbsee> s/thing/thiing too/
[03:44] <persia> Fujitsu: man-di: Thanks.  I'm glad to be proven wrong.  Not sending the mail :)
[03:45] <persia> Hobbsee: the menu-xdg package creates special .desktop files from the menu files (to populate the Debian menu for xdg-complaint menu systems (like gnome, xfce, KDE, etc.).
[03:45] <Hobbsee> persia: ah right, yes
[03:57] <mynameisdeleted> I have wine and crossover office crashing on my latest amd64 ubuntu release with the same error in /lib32/ld-linux.so
[03:58] <Hobbsee> mynameisdeleted: i think you want #ubuntu+1
[03:58] <mynameisdeleted> it didn't do it before I ran the latest apt-get upgrade
[03:58] <Hobbsee> which...doesnt seem to be on that topic, actually
[04:08] <bmm> Any MOTU and persia: I'm stuck with my last REVU comment and would love some extra advice on http://revu.tauware.de/details.py?upid=5856
[04:08] <zul> 5/win 17
[04:09] <persia> bmm: Looking now.  In the worst case, you can cheat with a lintian override (but patching upstream may be better).
[04:10] <bmm> persia: How would patching upstream help me?
[04:11] <persia> bmm: Upstream won't get a lintian error for using -rm Makefile :)
[04:13] <persia> bmm: Ah.  I see.  $(MAKE) clean fails because ./Makefile is missing.  How about using test to see if it's there before running clean?
[04:14] <bmm> persia: should be possible, although -$(MAKE) has almost the same effect.. so I'm not sure it's needed. But then again, if you say so I'd be happy to add it
[04:14] <bmm> Just thought it was weird, so wanted to ask again.
[04:14] <persia> bmm: lintian has a good suggested string for the conditional: run `lintian -iIv ccbuild_1.5.5-0ubuntu1.dsc`
[04:15] <persia> bmm: The idea is that if the source is dirty (say, from a previous build), and there is a different error, you want to know about it: you only want to ignore the case where ./Makefile is missing.
[04:16] <bmm> My lintian -iIv only gives me some notes about "ccbuild source: unknown-field-in-dsc original-maintainer"
[04:16] <Sindwiller> ...
[04:16] <bmm> persia: I can't find the text you are referring to from lintian, but if testing is a good idea I see no harm in doing it and posting a new revision
[04:17] <persia> bmm: http://pastebin.ca/604381
[04:17] <persia> (it takes me around a minute to use a pastebin - no need to poke :) )
[04:18] <bmm> persia: thanks! I'll add that test, then test the whole thing and post a revision.
[04:19] <persia> bmm: Great.  I think the package is finally ready to go in :)
[04:20] <bmm> persia: It actually went in once already :-D But then got rejected on the GPL
[04:20] <bmm> (the RSA MD5 Algorithm, that's why it now depends on libgcrypt for that)
[04:22] <bmm> persia: The rule suggested by lintian works like a charm, thanks!
[04:23] <persia> bmm: If you have a gutsy chroot, you might want to use gutsy linda & lintian: as they grow older, they grow wiser.
[04:23] <mruiz> dholbach: I'm using amsn in my gutsy without problems 
[04:23] <ScottK> persia: Wiser or more pedantic?
[04:24] <bmm> persia: yeah, I really missed that error. But dh_make should get more lintian proof to
[04:24] <dholbach> mruiz: and the moved files are ok too?
[04:24] <persia> ScottK: Is there really a difference?  If you're still unsure, go play shuffleboard a while, and get back to me :)
[04:24] <persia> bmm: Sending a patch to Debian is probably the best way to update dh_make (local changes are likely to cause confusion, and make synchronisation difficult).
[04:25] <persia> ScottK: it's the opportunity for observation :)
[04:25] <bmm> persia: I'll consider it
[04:25] <mruiz> dholbach: sure... working without problem. It has a new gui :-)
[04:25] <dholbach> mruiz: ok
[04:28] <bmm> Any MOTU: ccbuild is looking for it's first advocate, feel free to take a look at the latest upload of ccbuild at http://revu.tauware.de/details.py?upid=5889
[04:31] <dholbach> mruiz: (LP: #12345), not (Closes LP: #12345)
[04:31] <dholbach> mruiz: fixing that
[04:32] <mruiz> ok
[04:32] <mruiz> I was using my debian nomenclature 
[04:33] <ScottK> dholbach: Did you see I posted clamav packages for Dapper?
[04:33] <persia> I thought it matched /.*LP:\s?#?([0-9] *).*/.  Is it more restrictive?
[04:33] <dholbach> ScottK: yes, but did now have time yet to look at it
[04:33] <ScottK> OK.
[04:34] <dholbach> persia: I don't know for sure - that's just what I used up until now and is most common
[04:35] <dholbach> mruiz: uploaded
[04:35] <persia> dholbach: I've been using (and recommending) "(LP: #NNNNNN)" as well, but I've not been correcting debdiffs so long as the Launchpad-Bugs-Fixed: tag appears in .changes.
[04:35] <dholbach> right, I could have checked that before
[04:36] <mruiz> thanks dholbach . In my next packages I will use (LP: #NNNNN)
[04:36] <persia> bmm: Advocated.
[04:36] <dholbach> rock on
[04:37] <bmm> persia: cool! Thanks, hope nobody find a problem and if anybody does I can fix it ;-)
[04:38] <bmm> persia: I can't find the upstream for dh_make, but the package description states: Bugs: mailto:ubuntu-users@lists.ubuntu.com so I'm going to do that
[04:39] <persia> bmm: I'd suggest looking at http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=dh-make.  This isn't a general recommendation for this sort of thing, but dh-make is special.
[04:46] <Hobbsee> lol
[04:54] <bmm> persia: I've posted a bug against dh_make for the [-f Makefile]  || thing, just so you know it's been done
[04:56] <persia> bmm: OK.  (I neither use, nor generally agree with dh_make, but it's probably good for those that do).
[04:56] <bmm> Like me :-D
[04:56] <bmm> persia: in the end it's also good for anybody judging these packages, as every newbie will give you the same problems ;-)
[04:57] <persia> bmm: Probably true :)
[04:58] <ScottK> Hooray!
[04:59] <ScottK> I got several synced and more will be syncable the next time they are uploaded ...
[04:59] <PhinnFort> and they still say the Ubuntu community doesn't give anything back?
[04:59] <PhinnFort> I'm having some trouble signing my package, btw
[04:59] <PhinnFort> gpg claims I have no secret key available
[04:59] <ScottK> PhinnFort: They don't say that in Debian Python Modules Team.  They are very open to Ubuntu participation.
[05:00] <Hobbsee> specify it with -k<yourkeyid>
[05:00] <Hobbsee> or put it in .bashrc
[05:00] <PhinnFort> Hobbsee: It already gets the right ID
[05:00] <persia> PhinnFort: export DEBEMAIL to match the changelog email
[05:00] <PhinnFort> Name <mail>
[05:00] <PhinnFort> persia: it matches
[05:00] <persia> PhinnFort: Are you using a gpg agent on feisty?
[05:00] <PhinnFort> persia: kgpg
[05:00] <PhinnFort> ?
[05:01] <ScottK> PhinnFort: Don't use kgpg.  I could never make it work either.
[05:01] <PhinnFort> the only difference between the ID's, is that KGPG lists my name as Martin Sandsmark (Standard)
[05:01] <persia> PhinnFort: Ah.  You'll have difficulties.  You probably want debsign (it is fixed in gutsy).
[05:01] <PhinnFort> ScottK: I'll rather fix it/track down the bug and fix it;)
[05:01] <PhinnFort> persia: I try with debsign, no go
[05:01] <ScottK> PhinnFort: Then that's a different issue.
[05:02] <ScottK> Look at the gpg man page it tells you how to list the secret keys it has.  Make sure it actually has the secret key.
[05:02] <PhinnFort> ScottK: thanks, I'm in fact already doing it;)
[05:03] <persia> PhinnFort: Sorry.  You've exhausted my list of common signing issues :)
[05:03] <PhinnFort> ok, found out what it was...
[05:03] <PhinnFort> KGPG had made (Standard) a part of the ID
[05:05] <icf7> Anyone here who'd like to comment/advocate on http://revu.tauware.de/details.py?upid=5888 (Janino, a runtime Java compiler)?
[05:06] <persia> icf7: The lintian output on that page has at least one thing to fix (the last shown)
[05:07] <icf7> persia: oops, I just ran lintian locally. Will fix that
[05:07] <persia> icf7: Also, source doesn't have COPYING.
[05:09] <man-di> ScottK: hehe
[05:09] <man-di> I like Java
[05:10] <man-di> damn
[05:11] <man-di> persia: got me
[05:11] <icf7> persia: COPYING? Sorry, I don't really get the problem. Should upstream include it? Where is the need/its content documented?
[05:12] <PhinnFort> ok, what is the dput command to upload to revu?
[05:12] <PhinnFort> I just dput [changesfile] , and it ran cleanly
[05:12] <icf7> PhinnFort: dput revu *source.changes
[05:13] <PhinnFort> ah... revu BEFORE the packagename...;)
[05:13] <persia> icf7: The archive admins require that source be clearly licensed.  See https://lists.ubuntu.com/archives/ubuntu-motu/2007-July/001819.html
[05:13] <persia> PhinnFort: You'll get a REJECTED mail soon :)
[05:13] <PhinnFort> persia: can't wait;)
[05:13] <geser> icf7: COPYING should be included by upstream and contains a copy of the license (it may have also an other name like LICENSE
[05:13] <geser> )
[05:14] <persia> icf7: For BSD licenses, I've also seen it in README
[05:14] <PhinnFort> geser: can't he add the standard GPL license if it says it's GPL somewhere else?
[05:14] <persia> PhinnFort: See https://wiki.ubuntu.com/CommonPackagingMistakes/ChangingTheOrigTarball
[05:15] <PhinnFort> persia: not in the tarball, it gets in the .patch
[05:15] <PhinnFort> .diff
[05:15] <persia> PhinnFort: No.  It needs to be in the tarball.  See the mail URL above.
[05:15] <PhinnFort> oh, ok
[05:16] <geser> PhinnFort: someone fetching only the orig.tar.gz has to also get a copy of the license text
[05:16] <PhinnFort> bubureacrazy
[05:17] <icf7> persia: The license is already included, but in src/org/codehaus/janino/doc-files
[05:17] <PhinnFort> hehe... "Signer has no upload rights at all to this distribution."
[05:17] <persia> PhinnFort: No, it's legal arrangements.  In most jurisdictions, it's a violation of copyright to distribute something not in the public domain without a license from the author.
[05:17] <man-di> icf7: DEBIAN_DIR is always .
[05:18] <man-di> icf7: you dont need to compute this
[05:18] <icf7> man-di: sure, for the get-orig-source rule
[05:18] <persia> icf7: Is that a common place for java packages to ship the license?  If not, I suspect you'll get a complaint from the archive admins.
[05:18] <PhinnFort> persia: still bureacrazy, but now it's LEGALLY binding bureacrazy
[05:18] <man-di> icf7: you dont need it, cd .. is enough
[05:19] <icf7> man-di: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules defenitely states it must be callable from everywhere
[05:21] <icf7> persia: If that is the official position (besides, why isn't there a offical doc listing all these issues/rules?), you honestly advise me to file a bug? What if some other distro requires the copyright file to be there or in coolcopyright/ ? 
[05:22] <PhinnFort> Debian is right. Or it gets forked.
[05:22] <PhinnFort> ;)
[05:22] <man-di> icf7: have you tried building with java-gcj-compat-dev?
[05:23] <man-di> icf7: then your pacakge could enter universe
[05:23] <icf7> man-di: no, not yet.
[05:23] <persia> icf7: I'm not sure (I'm not an archive admin), but just passing news.
[05:23] <man-di> icf7: have you thought about submitting the package to Debian and then syncing it?
[05:24] <persia> icf7: Note: you only need one advocate in Debian :)
[05:27] <PhinnFort> ok, my package upload timed out...
[05:27] <PhinnFort> and now I can't upload again
[05:27] <PhinnFort> Error '553 Could not create file.' during ftp transfer of bookreader_0.1.1-1ubuntu1.dsc
[05:27] <persia> PhinnFort: I'll clean that.  Should take about 2 minutes.
[05:27] <PhinnFort> thanks
[05:28] <icf7> man-di: not yet, as I don't have any debian box here.
[05:28] <persia> PhinnFort: Please try again.
[05:29] <PhinnFort> thanks
[05:29] <PhinnFort> hopefully it won't time out again
[05:29] <man-di> icf7: ping me when you are ready to do it
[05:30] <icf7> man-di: Can I install a debian development environment in less than 2GB?
[05:32] <ScottK> I will mention again that if a orig.tar.gz clearly states what the license is, but merely fails to include a copy of the license, your first recorse is to ask upstream to add it, but you can, if you must, repack the tarball and add it yourself.
[05:32] <persia> PhinnFort: Was there supposed to be a bookreader_0.1.1-1ubuntu1.diff.gz?
[05:32] <PhinnFort> persia: yeah?
[05:32] <PhinnFort> persia: for the files in the debian/ dir?
[05:33] <geser> icf7: you should do with a base installation and install then only the packages you need for building/ working on the package
[05:33] <persia> PhinnFort: That's what I thought.  I didn't see it get uploaded.  Does it show in your .upload file?
[05:33] <PhinnFort> hum, no
[05:33] <PhinnFort> weird
[05:34] <persia> PhinnFort: You probably want to regenerate your source package.  Untar'ing bookreader_0.1.1-1ubuntu1.tar.gz is probably a good place to start.
[05:34] <PhinnFort> oki
[05:37] <man-di> icf7: should work
[05:37] <man-di> icf7: when you build only small packages
[05:37] <man-di> icf7: when building eclipse I need 1 GB alone for building it
[05:38] <man-di> icf7: what you need is only a sid pbuilder
[05:38] <persia> man-di: Which reminds me.  How's that going?
[05:39] <man-di> icf7: my sid pbuilder is around 100 MB
[05:39] <man-di> persia: what is going?
[05:39] <persia> man-di: The eclipse rebuilds.
[05:39] <icf7> man-di: That makes it a lot more easier.
[05:40] <man-di> persia: eclipse is a horror
[05:40] <persia> man-di: Yes.  Somehow the current eclipse in gutsy is FTBFS, and I've not a clue to fix it.
[05:41] <man-di> persia: yeah, doko needs to do it, you need to regenerate debian/control and it should work
[05:41] <man-di> persia: doko works on eclipse too
[05:41] <persia> man-di: Ah.  Sorry then.  I thought that was you, but if doko's on it, I'll take it off my list of things to ask you about (which is now empty :))
[05:42] <man-di> persia: we are both working on it, /me in Debian, doko in Ubuntu
[05:44] <persia> man-di: Ah.  Somehow my name ended up on it with changes attributed to you, which is why I was asking.
[05:54] <jekil> someone can review please? http://revu.tauware.de/details.py?upid=5663
[06:32] <munckfish> Hi, am creating my own local modified version of a dhcp3 to add some debug output. I don't want my version num to hide official updates. Should the version be like dhcp3_3.0.4-12ubuntu4dm1 or the safer dhcp3_3.0.4-12ubuntu4.0.0dm1?
[06:36] <tsmithe> hi all
[06:36] <tsmithe> would anyone be available to review ubuntustudio-sounds, ubuntustudio-look and usplash-theme-ubuntustudio, please?
[06:37] <tsmithe> i think they all have previously had 1 advocate
[06:39] <bigon> could some one have a look at http://revu.tauware.de/details.py?upid=5890, the pkg is incoming
[06:41] <tsmithe> also, could someone take a look at bug 123849
[06:41] <ubotu> Launchpad bug 123849 in Ubuntu "Please sync ubuntustudio-screensaver from the Ubuntu Studio repository" [Undecided,New]  https://launchpad.net/bugs/123849
[06:41] <tsmithe> (i'm not too sure of the process for syncs, yet)
[06:42] <tsmithe> thanks
[06:57] <mohammad> yesterday here I asked libcommons-io-java (1.3) from debian be imported to gutsy, but it seems build was failed. but for me its build in gutsy pbuilder is fine, also I contacted "Michael Koch" the debian maintainer and he confirmed that "Builds fine for him in sid and gutsy pbuilder." 
[06:58] <mohammad> I really appretiate if someone take look and builds it again
[07:04] <luisbg> any motu around?
[07:04] <luisbg> damn this channel is silent lately
[07:12] <tonyyarusso> !weekend
[07:12] <ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
[07:12] <tonyyarusso> Or, close enough, since it's a US holiday time
[07:15] <tsmithe> tonyyarusso, it is?
[07:15] <zul> yesterday was
[07:15] <tsmithe> wow lucky US
[07:15] <tsmithe> what was the occasion?
[07:15] <tonyyarusso> tsmithe: Independence Day
[07:15] <zul> independence day
[07:15] <tsmithe> oh of course
[07:16] <tsmithe> *feels truly ignorant now*
[07:17] <tonyyarusso> meh, I only know the days for US, Canada, and Norway
[08:13] <ScottK> tsmithe: Great mail to ESR yesterday.  Now you can tell all your geek friends you've taught ESR a thing or two.
[08:13] <tsmithe> yep :p
[08:15] <tsmithe> ScottK, would be cooler if i had geek friends who weren't on irc on this server, tho..
[08:15] <ScottK> Oh.  Yes.  Well you will someday.  It's a story that, told properly, has some legs.
[08:15] <superm1> what's ESR?
[08:15] <ScottK> Eric S Raymond.
[08:16] <superm1> ah
[08:16] <ScottK> He's a new Ubuntu user and tsmithe explained some stuff to him yesterday about bug reporting procedures on the motu mailing list.
[08:18] <tsmithe> superm1, he's also quite well known in the community
[08:19] <superm1> what's he well known for it the community?
[08:20] <tsmithe> http://en.wikipedia.org/wiki/Eric_S._Raymond
[08:20] <superm1> of course someone is well known once they are on wikipedia :)
[08:21] <tsmithe> *nods*
[08:25] <superm1> if anyone has a few moments, i'd appreciate a revu if possible: http://revu.tauware.de/details.py?upid=5863, mythbuntu-default-settings
[08:44] <slavik> could someone point me to the tutorial on properly making debs? (using checkinstall, it generates a package that tries to overwrite a file in another package)
[08:44] <DktrKranz> could you please have a look at http://revu.tauware.de/details.py?upid=5884? it's a new upstream release of php-interbase, recently readded to the archives. thanks
[08:45] <DktrKranz> slavik, you could look at https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/
[08:46] <zul> slavik: dont use checkinstall
[08:46] <ScottK> slavik: The Ubuntu packaging guide is the best general documentation (What DktrKranz pointed you to), but there is a lot of information there.  With some idea of what you are trying to package, we could probably help you focus on what you need to knwo.
[08:46] <zul> !checknistall
[08:46] <ubotu> Sorry, I don't know anything about checknistall - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[08:46] <zul> !checkinstall
[08:46] <ubotu> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
[08:47] <ScottK> And yes, as zul says, not using checkinstall is a good first step.
[08:49] <slavik> thanks
[08:51] <bigon> could some one have a look at http://revu.tauware.de/details.py?upid=5890 and http://revu.tauware.de/details.py?upid=5891 ?
[08:54] <ScottK> DktrKranz: That version of php-interbase is in Debian.  Any reason you didn't just request a sync?
[08:55] <ScottK> http://packages.debian.org/unstable/web/php5-interbase
[08:55] <DktrKranz> ScottK, that package belongs to php5 source
[08:55] <DktrKranz> ubuntu's dropped it because it depends on firebird
[08:55] <DktrKranz> which lies in universe
[08:55] <DktrKranz> so we need to handle it separately
[08:56] <DktrKranz> as a standalone source package
[08:56] <ScottK> OK.  I think you need to explain that in the changelog then.
[08:56] <DktrKranz> I'll add it
[08:56] <DktrKranz> mh
[08:56] <DktrKranz> it should be already present
[08:57] <DktrKranz> I'm checking
[08:58] <DktrKranz> "Initial release of out-of-tree build"
[08:58] <DktrKranz> is it sufficient or do I need to explain better?
[09:01] <ScottK> DktrKranz: Since MOTU maintains as a team, think about a MOTU who's never touched the package before noticing it's in a separate source package while in Debian it's not.
[09:01] <ScottK> DktrKranz: Help that MOTU out so he understands why it's the way it is.
[09:02] <DktrKranz> ok, thanks to pointing this out
[09:02] <DktrKranz> apart from that, do you see something which can be adjuested?
[09:02] <ScottK> DktrKranz: That's as far as I got.  I quit reviewing when I saw it was already in Debian.
[09:03] <ScottK> Didn't see any point in spending time on something I thought was just going to be archived.
[09:03] <slavik> how do I install packages for pbuilder environment?
[09:03] <DktrKranz> well, I update changelog with the info you suggested
[09:04] <superm1> slavik, in the pbuilder env?
[09:04] <superm1> or how do you install pbuilder?
[09:04] <superm1> (which is your question)
[09:05] <slavik> in the pbuilder environment
[09:05] <superm1> as you write debian/control
[09:05] <superm1> the dependencies are installed when you queue a build
[09:05] <superm1> so in debian/control your source package
[09:05] <superm1> will have a Depends: 
[09:05] <superm1> line
[09:05] <slavik> I see
[09:06] <slavik> comma delimeted list?
[09:06] <icf7> Different pbuilder question: What should be pbuilder's --mirror option for Debian (Sid). Do I need to add anything else except --distribution sid ?
[09:06] <superm1> slavik, yes
[09:07] <superm1> it's actually Build-Depends:
[09:07] <slavik> ok, going to check it out ^^
[09:07] <slavik> arrgs :P
[09:07] <superm1> take a look at another package for an example
[09:07] <superm1> just apt-get source PACKAGE, and look in the debian/ directory at the control file
[09:08] <ScottK> The pbuilder scripts at http://revu.tauware.de/~laserjock/ give an easy way to set things up.  icf7: there's one there for sid.
[09:08] <icf7> ScottK: Thank you.
[09:09] <slavik> when the configure script for the package runs, it stops here: checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
[09:10] <slavik> the package is libxml-parser-perl
[09:11] <superm1> so add that package to the build depends 
[09:11] <superm1> and rebuild the source package
[09:11] <superm1> and send it back through pbuilder
[09:11] <slavik> I did ...
[09:11] <slavik> I don't have to edit the dsc file, right?
[09:12] <superm1> well it should be generated for you when you use 'debuild -S'
[09:12] <superm1> to make the source package
[09:12] <slavik> I used dh_make
[09:12] <slavik> ls
[09:13] <superm1> i haven't used dh_make before, so i'm not too sure on its functionality
[09:13] <superm1> i always build my source packages with debuild though, debuild -S -sa -i
[09:14] <superm1> which is "build source package, sign it, and ignore .bzr, .svn directories"
[09:15] <tsmithe> i have a package which doesn't have it's main source tree in the top-level directory, and using "cd" in debian/rules doesn't seem to work. what is the syntax for changing directory in a Makefile; or what else can i do to get around this?
[09:15] <slavik> hmm, I am missing debuild :(
[09:16] <ScottK> slavik: apt-get install devscripts
[09:16] <ScottK> sudo ...
[09:16] <slavik> installing now :)
[09:16] <man-di> tsmithe: ( cd dir ; dosomething )
[09:16] <tsmithe> hmm ok :)
[09:16] <tsmithe> can't i just do it once per rule?
[09:17] <man-di> tsmithe: make executes each command in a shell, (...) counts as one command
[09:17] <tsmithe> ahha ok
[09:17] <man-di> tsmithe: no
[09:17] <tsmithe> thanks :)
[09:18] <man-di> tsmithe: but you can but the commands on several lines when line ending with \
[09:18] <slavik> err, says it can't find the debian/changelog anywhere (I am in the root of the source)
[09:18] <tsmithe> man-di, yes, thanks :)
[09:18] <man-di> tsmithe: like http://paste.debian.net/32116
[09:19] <tsmithe> cool, cheers
[09:19] <superm1> slavik, do you have a debian/changelog :)?
[09:23] <slavik> now, I do
[09:23] <slavik> using 'debuild' for building the deb :)
[09:24] <superm1> you can use it to build the deb, but you will want to run it through pbuilder at least once to make sure that you have all the dependencies correct
[09:24] <superm1> *build dependencies 
[09:24] <slavik> wait, pbuilder is supposed to be run before debuild?
[09:24] <superm1> well debuild -S 
[09:24] <superm1> makes the source package
[09:24] <superm1> you can do a normal 'debuild' however too
[09:25] <slavik> source package is the ones that usually end in -dev in the repos, right?
[09:25] <superm1> No, source packages are the ".dsc .diff.gz and .orig.tar.gz"
[09:25] <superm1> when you use pbuilder, pbuilder build NAME.dsc
[09:26] <superm1> the source packages are used to describe how to generate the binary packages
[09:26] <slavik> hmm ... says it could find any signing program (pgp or gpg)
[09:27] <superm1> when you upload it to revu, it will have to be signed, but in the meanwhile there is a switch to provide to debuild
[09:27] <superm1> to skip the signing step
[09:27] <ScottK> debuild -S -uc
[09:28] <slavik> rofl
[09:28] <slavik> now that I have the source package ...
[09:28] <slavik> ahh, the dsc is the source package
[09:28] <ScottK> Now that I can upload to the archive for real, I'm very careful to only sign stuff I think I actually might want to end up there.
[09:30] <slavik> looks like it is downloading all the proper (needed) packages
[09:31] <superm1> how were you doing things before in pbuilder without debuilding the source package?
[09:32] <slavik> if I change the debian/control build-dep, do I have to rerun debuild?
[09:32] <ScottK> Yes
[09:33] <slavik> k
[09:33] <slavik> this is not simple at all :(
[09:34] <ScottK> slavik: No it's not, but it's worth the effort in the long run.
[09:34] <slavik> what type of package are the -dev packages in the repos? (the ones with headers and such)
[09:35] <ScottK> Those are binary development packages of a library package.
[09:35] <slavik> how are those built?
[09:35] <tsmithe> man-di, could you take a look at http://paste.ubuntu-nl.org/28689/ ... it seems to hate configure-stamp..
[09:35] <tsmithe> ( cd wired ; \        cp -f /usr/share/misc/config.sub config.sub ; \ /bin/sh: Syntax error: end of file unexpected (expecting ")")
[09:35] <slavik> ok, looks like I am getting the hang of this, somewhat
[09:36] <ScottK> slavik: I haven't done one, but the general answer, I think, is very carefully.
[09:36] <tsmithe> (i took line breaks out)
[09:36] <ScottK> nixternal was recently working on a new library package IIRC.  Mabye he would have advice.
[09:37] <icf7> ScottK: The pbuilder-sid script exits with this error message: http://pastebin.ca/604782 . What am I doing wrong? Where does the query for restricted originate?
[09:37] <nixternal> ya, don't do it :)
[09:37] <tsmithe> ScottK, slavik, -dev packages usually just ship the header files for the library in question, i thought
[09:37] <tsmithe> maybe depend against needed development packages..
[09:38] <ScottK> tsmithe: Yes, but it's built as one of the binary packages from the source.
[09:38] <tsmithe> yes
[09:38] <tsmithe> so surely dh_install is all that's needed? nixternal, am i right?
[09:38] <tsmithe> or is there more magic?
[09:38] <tsmithe> the library itself is the hard part, i seem to recall, from dabbling when learning
[09:38] <ScottK> icf7: Not sure.  I've never had that happen.
[09:38] <slavik> it seems like -dev packages only have a simple script to put files in proper locations ... since it is mostly header files and static libraries
[09:39] <man-di> tsmithe: why so complicated?
[09:39] <nixternal> it all depends really...I have done about 4 library files now and they have all been different
[09:39] <nixternal> then again, I use cdbs
[09:39] <tsmithe> man-di, how do you mean?
[09:39] <man-di> tsmithe: wouldnt cp -f ... wired/config.sub be better than ( cd wired ; cd -f ... config.sub ) ?
[09:39] <slavik> does pbuilder update it's environment when building other packages?
[09:39] <tsmithe> man-di, damn i'm not thinking straing
[09:39] <tsmithe> *straight
[09:40] <tsmithe> (not feeling particularly well :) )
[09:40] <tsmithe> thanks :)
[09:40] <man-di> tsmithe: get well
[09:40] <man-di> tsmithe: and take a break
[09:40] <man-di> tsmithe: do a walk
[09:40] <man-di> tsmithe: this helps
[09:40] <tsmithe> thanks - if only it wasn't raining :)
[09:40] <man-di> tsmithe: there is no wrong weather, only wrong clothes
[09:41] <icf7> ScottK: Thank you again
[09:41] <tsmithe> man-di, very true. i'll go out :)
[09:41] <tsmithe> the dog will like it too
[09:41] <tsmithe> brb!
[09:41] <man-di> tsmithe: have fun
[09:41] <ScottK> icf7: It's working for me.
[09:42] <ScottK> How did you call the script?
[09:42] <icf7> ScottK: pbuilder-sid create
[09:42] <tsmithe> man-di, before i go, should i generate the configure script in rules, or do that and include it in the diff.gz, or repack the orig? (i know the latter is not nice, but i've already had to dfsg-ise it)
[09:43] <jeromeg> can any motu delete a package from universe/multiverse or is there a special procedure ?
[09:43] <tsmithe> in fact, anyone of course, can answer
[09:43] <man-di> tsmithe: personally I prefer to regenerate the autotools stuff once and add it to the package as a patch in debian/patches
[09:43] <ScottK> icf7: I'd have expected that to work.
[09:44] <tsmithe> man-di, makes sense
[09:44] <man-di> tsmithe: makes upstream uprades more easy
[09:44] <ScottK> icf7: Maybe it's a connectivity issue or something.  Try again in a bit?
[09:44] <icf7> ScottK: Me too, and I got the same error when calling pbuilder manually
[09:44] <tsmithe> yeah - thanks :)
[09:44] <icf7> ScottK: I did, ~4 times to make sure I don't report my bugs
[09:44] <ScottK> OK.  Not sure what to tell you then.
[09:44] <icf7> ScottK: I'm testing it on another machine, let's see
[09:46] <man-di> tsmithe: another tipp
[09:46] <jeromeg> anyone can help me please ?
[09:46] <tsmithe> man-di, yep
[09:46] <man-di> tsmithe: ( cd dir ; make ) vs. make -C dir
[09:47] <man-di> tsmithe: I think you can just avoid using ( ) in your debian/rules
[09:47] <tsmithe> ah yes
[09:47] <tsmithe> i forgot all about -C
[09:47] <tsmithe> thanks lots
[09:47] <man-di> mohammad: hello
[09:47] <man-di> mohammad: I'm Michael Koch
[09:47] <mohammad> hello 
[09:48] <mohammad> man-di: thank you for your response (in email)
[09:48] <man-di> mohammad: I wonder which version of commons-io do you want to merge to gutsy
[09:49] <slavik> ok, I think it build successfully
[09:49] <mohammad> man-di: 1.3.1.dfsg.1-1 http://packages.debian.org/unstable/libs/libcommons-io-java
[09:50] <slavik> where does pbuilder put the debs it creates?
[09:51] <slavik> ahh, found it :P
[09:51] <man-di> mohammad: thats really strang
[09:52] <mohammad> man-di: http://packages.debian.org/unstable/libs/libcommons-io-java the source version is 1.3.1.dfsg but the binary version is 1.0-3
[09:53] <man-di> mohammad: I generate comparison between gutsy and sid on daily basis and it tells me gutsy has 1.3.1.dfsg which it clearly not has
[09:53] <mohammad> man-di: take a look at this page http://packages.ubuntu.com/gutsy/libs/libcommons-io-java
[09:53] <man-di> mohammad: I did
[09:53] <slavik> so, when I add packages to build-depend line in the debian/control, does the required package get added to the pbuilder environment?
[09:53] <man-di> mohammad: I currently wonder about multidistrodtools
[09:54] <man-di> mohammad: I think that was in sync already
[09:54] <man-di> mohammad: back to work
[09:54] <man-di> mohammad: I build the package locally in an uptodate gusty pbuilder and it worked
[09:55] <man-di> mohammad: I think you should just file a sync bug and subscribe ubuntu-universe-sponsors
[09:55] <mohammad> man-di: I did the same thing and I confirmed that in gutsy pbuilder it works for me as well
[09:55] <geser> slavik: yes, it gets installed before the package building begins in pbuilder
[09:56] <man-di> mohammad: cool, so file the bug and enjoy your work ;-)
[09:56] <slavik> hmm, I can't find the deb ... where should I look for it?
[09:57] <mohammad> man-di: I am quite new would you please let me know how I can subscribe ubuntu-universe-sponsors?
[09:57] <jeromeg> is there any special procedure to follow to ask for a package to be removed from multiverse ?
[09:58] <man-di> mohammad: write the bug report
[09:59] <man-di> mohammad: when its in launchpad there is a menu on the left side, one point is "subscribe others"
[09:59] <tsmithe> man-di, thanks so much; it's building :D now i can leave it, and go out!
[09:59] <icf7> ScottK: The pbuilder-sid is a configuration problem, sorry for asking.
[10:00] <man-di> tsmithe: hehe, enjoy your time without packaging and come back with new powers
[10:00] <slavik> error: trying to overwrite `/usr/lib/glade3/modules/libgladegtk.so', which is also in package libgladeui-1-5
[10:00] <geser> slavik: the builds debs get copied to /var/cache/pbuilder/results/
[10:00] <slavik> what is the proper way to "fix" that?
[10:00] <tsmithe> man-di, heh :)
[10:00] <geser> jeromeg: which package do you want get removed?
[10:01] <jeromeg> geser : it has been asked in a bug report to remove f-prot-installer
[10:01] <slavik> hmm, looks like just a generic conflict, since that package is version 3.2 ...
[10:01] <jeromeg> geser : bug 124257
[10:01] <ubotu> Launchpad bug 124257 in f-prot-installer "[Remove]  Please remove f-prot-installer from gutsy" [Undecided,New]  https://launchpad.net/bugs/124257
[10:02] <jeromeg> geser : debian marked it has obsolete
[10:02] <jeromeg> s/has/as
[10:03] <geser> jeromeg: I filed that bug report :)
[10:03] <slavik> hmm, how would I add an icon for the packages?
[10:03] <icf7> ScottK: If you or someone else ever encounter mysterious fetch errors in pbuilder, check twice COMPONENTS is not set anywhere
[10:03] <jeromeg> geser : lol
[10:04] <jeromeg> geser : then I think you've done everything right :)
[10:04] <jeromeg> geser : motus can do that or no ?
[10:05] <xxxxx1> bye all
[10:05] <geser> jeromeg: yes, now I only need to wait till the archive admins process it
[10:06] <jeromeg> geser : ok thank you
[10:07] <ScottK> icf7: No problem.  Glad you got it working.
[10:11] <icf7> Is there an overview of variables preset in debian/rules? If yes, could someone point me to it?
[10:13] <man-di> icf7: the make manual and if you use CDBS the CDBS source code
[10:15] <slavik> what is the procedure to build a development package?
[10:16] <geser> slavik: you mean that your source-package produces a -dev deb?
[10:17] <nixternal> how many advocates does it take to screw in a light bulb?
[10:18] <nixternal> err, I mean how many do you need in REVU before a package gets uploaded?
[10:18] <geser> two
[10:18] <geser> for NEW packages
[10:18] <nixternal> ok, thought so, just wanted to double check
[10:19] <nixternal> http://revu.tauware.de/details.py?upid=5863
[10:19] <nixternal> one down, one to go :)
[10:20] <geser> nixternal: do you know if the package is managed in bzr?
[10:20] <nixternal> according to the rules file, I would have to say yes
[10:20] <effie_jayx> tauware... in my city's local dialect that reseambles to taguara which means a place for cheap beer ;)
[10:20] <superm1> geser, yes it is
[10:20] <nixternal> it screams bzr :)
[10:21] <geser> superm1: what about adding the bzr location into the control files?
[10:21] <superm1> geser, the debian/ directory isn't in bzr
[10:21] <superm1> everything else is however
[10:21] <superm1> i thought that that X-Vcs line was for when you managed debian/ in bzr?
[10:21] <geser> then forget what I said
[10:22] <nixternal> hehe :)
[10:22] <nixternal> sorry, I should have told you checked out bzr to check that as well :)
[10:22] <superm1> geser, is that where we should be going in terms of packages though, managing the debian/ directory in a seperate branch ?
[10:24] <geser> superm1: if you have already everything else in bzr, it would be good to have the debian dir there also
[10:25] <superm1> in the same branch?
[10:25] <Qball> Seveas: where you been.
[10:26] <superm1> the way persia was explaining things to me, its a good idea to use bzr for upstream rather than doing a debian native package
[10:26] <geser> superm1: ask dholbach :) he has probably more experience with packages being in bzr than me
[10:27] <mohammad> man-di: I reported the bug https://bugs.launchpad.net/ubuntu/+bug/124275 thank you for your help :)
[10:27] <ubotu> Launchpad bug 124275 in Ubuntu "sync bug for  libcommons-io-java(1.3.1.dfsg.1-1)" [Undecided,New]  
[10:27] <superm1> for at least this revision of it then, i'll just keep upstream in bzr and later move the debian/ directory into the appropriate place if it will be managed by a bzr branch too
[10:28] <ScottK> superm1: Just don't include /debian in your orig.tar.gz when you release it.
[10:29] <superm1> ScottK, so the idea of having debian/ in bzr, does that mean you would use bzr-buildpackage to get it and build it?
[10:29] <geser> superm1: about the licensing: you should probably a verbatim copy of the license text into the orig.tar.gz but I'm not sure in this case
[10:30] <superm1> because of it being a native package?
[10:30] <ScottK> superm1: I have trouble spelling bzr, let alone using it.  
[10:30] <man-di> mohammad: have you subscribed u-u-s? otherwise noone will look at the bug
[10:30] <ScottK> superm1: A full text copy of the license is an archive requirement.
[10:32] <superm1> ScottK, look at the xubuntu-default-settings source
[10:32] <mohammad> man-di: Ubuntu Sponsors for universe has been subscribed to this bug. (yes) 
[10:32] <superm1> there is no full copy of the license text shipped with the source package
[10:32] <superm1> just the reference in debian/copyright
[10:34] <ScottK> superm1: Doens't matter.  Today it'll get you rejected.  Pitti sent mail to the motu list earlier in the week complaining MOTUs have been insufficiently vigilant about the issue.
[10:35] <superm1> okay.  easy enough to add.  I'll get it in there then :)
[10:35] <geser> mohammad: I've rejected this bug as we can't sync it. we already have this source in gutsy.
[10:36] <man-di> geser: the source is in gutsy already?
[10:36] <geser> mohammad: this probably needs a retry on the buildds
[10:36] <man-di> geser: but why is the binary package so old?
[10:36] <geser> commons-io | 1.3.1.dfsg.1-1 | http://archive.ubuntu.com gutsy/universe Sources
[10:36] <geser> FTBFS: http://launchpadlibrarian.net/7543640/buildlog_ubuntu-gutsy-i386.commons-io_1.3.1.dfsg.1-1_FAILEDTOBUILD.txt.gz
[10:37] <man-di> that is why my multidistrotools said its in sync
[10:38] <man-di> geser: that bug should be fixed since that time
[10:39] <geser> man-di: I asked pitti for a retry on the buildds
[10:39] <man-di> geser: thx
[10:39] <mohammad> geser: thanks
[10:40] <geser> np
[10:41] <PhinnFort> how long should it take for my package to appear on http://revu.tauware.de/?
[10:42] <tsmithe> 5-10 mins, usually
[10:42] <PhinnFort> ok
[10:46] <PhinnFort> 15 mins?
[10:47] <geser> PhinnFort: are you in the ubuntu-motu-contributor team?
[10:47] <PhinnFort> geser: I think so
[10:47] <PhinnFort> geser: at least my launchpad account says so
[10:48] <PhinnFort> maybe I need to update my openpgp keys
[10:49] <PhinnFort> nope
[10:49] <geser> PhinnFort: you need probably someone who can look up on REVU what's going on
[10:50] <PhinnFort> geser: you know of anyone who's actually here, or should I just ping randomly?
[10:51] <PhinnFort> siretart: ping
[10:52] <geser> it looks like most who can do it, are right now not here or away
[10:52] <siretart> PhinnFort: huh?
[10:52] <mohammad> man-di, geser: http://packages.debian.org/unstable/source/lucene2 is not merged in gutsy. Does it need a retry on the buildds? 
[10:52] <PhinnFort> siretart: my package won't show up on revu.tauware.de
[10:53] <PhinnFort> siretart: you where listed on the wiki-page
[10:53] <PhinnFort> ;)
[10:53] <PhinnFort> bookreader is the program I'm creating a .deb for
[10:54] <geser> mohammad: FTBFS: http://launchpadlibrarian.net/8101650/buildlog_ubuntu-gutsy-i386.lucene2_2.1.0-1_FAILEDTOBUILD.txt.gz
[10:54] <geser> sun-dlj-v1-1 license could not be presented
[10:54] <geser> try 'dpkg-reconfigure debconf' to select a frontend other than noninteractive
[10:55] <geser> mohammad: the problem is that sun-java want a confirmation for the license on install which doesn't work on the buildds
[10:57] <mohammad> man-di, geser: I see. what is the solution? is it possilble to use java-compat-dev instead of sun jdk for lucene2?
[10:58] <superm1> geser, ScottK  http://revu.tauware.de/details.py?upid=5893 I added a license in upstream and I added the debian directory to the bzr branch, and modified my get-orig-source rule, is there anything else special to do?
[10:58] <superm1> for X-Vcs
[10:58] <man-di> mohammad: lucene2 is very new und not good packaging
[10:59] <jussi01> hmmmm, why is my memory so bad? could someone remind me how to get source out of .dsc files, please?
[10:59] <geser> superm1: I guess that's all, but I haven't looked in Debian policy about this field
[10:59] <ScottK> jussi01: dget -x name.dsc?
[11:00] <superm1> jussi01, dpkg-source -x *dsc
[11:00] <superm1> is what i've done normally
[11:00] <jussi01> thanks :)
[11:00] <geser> mohammad: either wait till the sun java compiler gets freed or check if the package can also be build with one of the free java compilers
[11:03] <Kmos> Adri2000: http://dad.dunnewind.net/main.php -> bug
[11:04] <Adri2000> Kmos: eh, you are very quick :)
[11:04] <Adri2000> I'm fixing it
[11:04] <Adri2000> (my fault)
[11:04] <Kmos> :-)
[11:04] <Adri2000> Kmos: fixed
[11:04] <Kmos> nice
[11:21] <jekil> anyone can review please? http://revu.tauware.de/details.py?upid=5663
[11:34] <icf7> how can I examine a deb file (see the files packed/meta information)?
[11:35] <crimsun> dpkg-deb(1)
[11:35] <icf7> crimsun: Thank you.
[11:47] <mohammad> can anyone review http://revu.tauware.de/details.py?upid=5883 please?
[11:51] <geser> mohammad: I gave it a quick look and it looks good
[11:52] <mohammad> geser: thank you. would you please let me know How I can find someone to advocate it?
[11:58] <mohammad> geser: do you know any motu who knows Arabic and/or interested in Arabic fonts?
[11:59] <crimsun> it looks fine; I'll advocate it.
[12:00] <crimsun> is the intent to get this into universe then file an M.I.R.?
[12:01] <mohammad> crimsun: ammm .. what is an M.I.R. ?
[12:02] <crimsun> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[12:03] <crimsun> the source & binary packages would need to be promoted to the main component for it to be useful.
[12:05] <superm1> crimsun, do you have a few for another revu?
[12:05] <crimsun> superm1: sure, upid?
[12:05] <superm1> http://revu.tauware.de/details.py?upid=5893
[12:07] <mohammad> crimsun: thank you for advocating :)
[12:08] <ScottK> mohammad: I'm looking too.
[12:08] <Q-FUNK> mohammad: does it cover farsi or just the basic arabic set?
[12:09] <geser> crimsun: you surely meant that a MIR is only needed if the packages should be included in main (and not only universe)
[12:11] <mohammad> ScottK: yes I think It covers persian (farsi) 
[12:13] <mohammad> ScottK: Persian has 4 more letters than Arabic and Scheherazade covers all of them.
[12:13] <ScottK> mohammad: You do need to set an Ubuntu maintainer address.  As long as you and crimsun are OK with it, I'll make that change if I don't find anything else.
[12:13] <ScottK> Interesting.