[00:55] <ScottK> superm1: ^^^ Would you mind reviewing that?
[00:55] <ScottK> superm1: Also, I'm going to look at the perl module you need in a few hours.
[02:37] <ScottK> superm1: Looking at your perl module now.
[02:37] <superm1> ScottK, basically the source package got renamed in debian, and someone deleted the old one in ubuntu without pulling in the new one
[02:37] <ScottK> yeah.  figured that out.
[02:38] <ScottK> Just checking through it anyway ....
[03:31] <ScottK> superm1:  libimage-size-perl is through New (source and binary), so just need a publisher run now.
[03:32] <superm1> cool thanks ScottK
[03:33] <superm1> i sponsored that thing you pointed at earlier too
[03:34] <ScottK> superm1: Thanks.
[03:34] <ScottK> Whenever someone says DKMS, I think of you....
[03:34] <StevenK> That sounds like a back-handed compliment
[03:41] <ScottK> Heh.  I guess it depends on what you think of DKMS.
[03:41] <ScottK> Hello StevenK.
[04:02] <Ryan52> asac: hm. with your patch (and a few other tweaks) applied trying to build under Debian, I get this failure: http://slexy.org/raw/s21QsPRVLf
[04:03] <Ryan52> asac: do you have any idea what's wrong?
[04:07] <micahg> Ryan52: asac's probably sleeping
[04:07] <Ryan52> micahg: he'll probably look at his away log tho :)
[04:07] <micahg> indeed
[04:45] <maxb> If any universe sponsor feels like a quick simple review, bug 429161
[04:47] <ScottK> maxb: Doesn't that just put it back like it was for ubuntu2 (and then it was uninstallable)?
[04:48] <maxb> the difference is that the files have the proper names before dh_pycentral runs
[04:48] <ScottK> Ah.
[04:48] <ScottK> OK.  Makes sense.
[04:49] <ScottK> I'll sponsor it.
[04:49] <maxb> thanks
[04:56] <ScottK> maxb: BTW, if you find I broke something else, feel free to ping me directly about getting it fixed.
[05:40] <ScottK> maxb: Uploaded.  Thank you for your contribution to Ubuntu (and catching/fixing my mistake).
[06:07] <fabrice_sp> persia, mojito is FTBFS because it misses twitter-glib. Do you of any plan to sync it in Karmic?
[06:08] <fabrice_sp> s/do you/do you know/
[06:14] <ScottK> fabrice_sp: IIRC there is an FFe pending.  You might make sure the relationship with mojito is mentioned in the bug.
[06:15] <fabrice_sp> ScottK, I'll check that. Thanks!
[06:24] <dholbach> good morning
[06:30] <fabrice_sp> hey dholbach !
[06:30] <fabrice_sp> good morning
[06:30] <dholbach> hi fabrice_sp
[09:28] <jetienne> q. i need to store a pidfile, but as a normal user (not root), what is the proper directory to store it ?
[09:28] <jmarsden> jetienne: Create one /var/run/whatever and chown it to the user concerned.
[09:30] <jetienne> jmarsden: it will be removed on boot, no ?
[09:31] <jmarsden> I'm not sure... I don't think it will be removed by default.
[09:31] <jetienne> hm ok thanks
[09:32] <jmarsden> jetienne: For examples see what bacula or openldap do
[09:34] <jetienne> jmarsden: ok i will
[09:41] <AnAnt> Hello, debian made a new release of mutt that Recommends default-mta instead of exim4, which means, that it no more needs merge, but sync. Also there are some patches in that debian release. So the question is, should I file a sync request for mutt ? or should that wait for karmic+1 ?
[09:42] <StevenK> Certainly, file a sync request
[09:42] <AnAnt> StevenK: are you the one on crack ?
[09:45] <Hobbsee> that depends how much of the new queue he's been forced to do on any given day
[09:45] <StevenK> Hah
[09:45] <StevenK> AnAnt: It's just a saying of "Oh, I missed something"
[09:46] <AnAnt> StevenK: ok
[09:53] <AnAnt> btw, can someone comment on this bug 427562
[10:38] <Hosein-mec> hi
[10:38] <Hosein-mec> i have a problem exactly like this => http://ubuntuforums.org/showthread.php?t=616544
[10:38] <Hosein-mec> i dont know how to " Adding the non-interactive "cmake" command to the debian/rules "
[10:40] <Hosein-mec> this is my debian/rule :
[10:40] <Hosein-mec> http://paste.pocoo.org/show/139711/
[10:41] <andv> Hosein-mec, I never used cmake myself, but anyway I guess you should make it running on configure call
[10:43] <Hosein-mec> my main problem is this:  https://launchpad.net/~hoseinhz63/+archive/ppa/+build/1241869
[10:43] <andv> Hosein-mec, your source files should have a README or an INSTALL that tells you which commands you should run to configure / build / install
[10:44] <AnAnt> dh 7 supports cmake
[10:44] <AnAnt> if I recall correctly, dh_auto_build will magically detect this cmake thing
[10:45] <andv> Hosein-mec, yeah, found it
[10:45] <Hosein-mec> andv: yes => http://paste.pocoo.org/show/139712/
[10:45] <andv> Hosein-mec, if you need cmake to run on build target
[10:45] <andv> Hosein-mec, you should remove the make call on debian/rules
[10:45] <andv> Hosein-mec, and put the right cmake rule in there
[10:45] <soren> YokoZar: I have a few applications running in wine. When they quit, the process doesn't terminate, but starts spinning and eating lots and lots of CPU. Assuming this is not by design (to give you that warm, fuzzy, ol'e, Windowsy feel) is this a common/known problem?
[10:46] <andv> Hosein-mec, as I said, I didnt use cmake myself so I don't know the specific options or flags to give it
[10:46] <andv> Hosein-mec, but anyway $(MAKE) should *not* be there if you use cmake
[10:46] <Hosein-mec> andv: thanks. can u tell me exactly which line ? http://paste.pocoo.org/show/139711/
[10:47] <andv> around ~30
[10:47] <Hosein-mec> andv: ok thanks. i go try again
[10:48] <andv> ok, np
[10:49] <YokoZar> soren: It seems to happen to me with any application that uses audio
[10:49] <YokoZar> soren: and not just wine
[10:50] <soren> YokoZar: Oh. This is a wine-only problem for me.
[10:50] <soren> YokoZar: Sometimes wineserver joins the spinning frenzy as well.
[10:50] <YokoZar> soren: if alt+f1 killall -9 pulseaudio doesn't let them quit well then something else is afoot
[10:51] <YokoZar> well I should say only some applications that use audio for me.  One is an SDL full screen game that never quits well.  Are these wine apps similar?
[10:52] <YokoZar> I would expect ms paint to quit well but something like half life 2 to run into the same audio problem I have elsewhere
[10:52] <soren> YokoZar: They're two dictionaries I use ocasionally. I suppose they may go "beep" if I mistype something.
[10:52] <YokoZar> hmmm
[10:52] <YokoZar> can you run notepad and quit it without problem?
[10:53]  * soren treis
[10:53] <soren> tries, even.
[10:53]  * soren doesn't know how to trei
[10:54] <soren> YokoZar: Yup, notepad quits just ifne.
[10:54] <soren> fine, even.
[10:54]  * soren types very poorly today.
[10:55] <YokoZar> Have you tried the wine1.2 package instead of the wine package?
[10:55] <YokoZar> It may just be an old fashioned wine bug
[10:55] <YokoZar> especially if the apps are similar
[11:05] <Hosein-mec> andv: i added 2 commands that needed for compile and make that were in Install readme. like this : http://paste.pocoo.org/show/139721/
[11:06] <Laney> Anyone from motu-release here?
[11:06] <Hosein-mec> andv: this is ture ?
[11:07] <andv> Hosein-mec, remove the $ in front of cmake
[11:08] <andv> Hosein-mec, and make should be removed as well I guess
[11:21] <soren> YokoZar: Oh, I didn't realise there were several wines in the archive. I'll try 1.2
[11:33] <soren> YokoZar: 22747 soren     20   0 2603m  21m  10m R   66  1.1   0:23.68 Engelskordbog20
[11:33] <soren>                                                     ^^
[11:33] <soren> :(
[11:34] <soren> Oh, and wineserver is right beneath it with:
[11:34] <soren> 22750 soren     20   0  5624 2768  632 S   34  0.1   0:09.77 wineserver
[11:34] <soren> For a total of 100%. Yay for dualcore :)
[11:34] <YokoZar> hmmm
[11:34] <soren> YokoZar: I do hear a difference in my earphones when I start the app, though.
[11:35] <YokoZar> this might be related https://bugs.launchpad.net/bugs/428815
[11:36] <soren> YokoZar: Oh, right. Which sound output thing should I use?
[11:36] <YokoZar> try unchecking all of them to test
[11:36] <soren> YokoZar: Oh. Good call.
[11:36] <soren> YokoZar: Same.
[11:37] <YokoZar> ok that's good news I guess
[11:37] <soren> Yes, I'm ecstatic :)
[11:40] <soren> YokoZar: I get a ton of these: 0009: get_message() = PENDING { win=00000000, msg=00000000, wparam=00000000, lparam=00000000, type=0, time=00000000, active_hooks=80000045, total=0, data={} }
[11:40] <soren> YokoZar: ...if I start wineserver with -d.
[11:40] <YokoZar> If it's any consolation there are a couple wine devs trying to get Wine git to actually build in karmic at the moment (apparently some weirdness with mpg123)
[11:41] <YokoZar> So if notepad works fine it might just be your app causing it
[11:41] <YokoZar> do you have any more normal apps you can test with
[11:41] <soren> YokoZar: Nope. Those are the only ones.
[11:41] <slytherin> ScottK: ping
[11:42] <Hosein-mec> andv: is there any guide ti se cmake in debian/rules ?
[11:42] <Hosein-mec> *to
[11:42] <soren> YokoZar: From the same publisher, so they're very similar.
[11:42] <YokoZar> Yeah it could just be those apps and a normal wine bug still
[11:42] <andv> Hosein-mec, don't know sorry : /
[11:42] <YokoZar> soren: Go download windows firefox or something and see if that works normally ;)
[11:42] <andv> Hosein-mec, you should search some examples
[11:43] <soren> YokoZar: Maybe some other day.. :/
[11:43] <soren> YokoZar: Sorry.
[11:43] <YokoZar> soren: anyway, thanks -- sometimes there are wine-wide issues and they look similar to this, but if notepad works it's probably just an app bug
[11:44] <YokoZar> although a deadlock in wineserver is interesting
[11:44] <soren> YokoZar: Wineserver seems to die off when I kill the app.
[11:45] <YokoZar> soren: can you wineserver -k
[11:45] <YokoZar> or do you have to kill -9 the process
[11:47] <soren> Not sure.
[11:59] <slytherin> siretart: ping, do you mind if I try no-change rebuild of jack-audio-connection-kit to fix libffdoN dependency?
[12:23] <sistpoty|work> hi folks
[12:24] <sebner> huhu sistpoty|work :D
[12:24] <sistpoty|work> hi sebner
[12:24] <slytherin> sistpoty|work: hi
[12:24] <sebner> sistpoty|work: desmume got approved btw
[12:24] <sistpoty|work> hi slytherin
[12:24] <sistpoty|work> sebner: saw it :)
[12:24] <sebner> :)
[12:25] <slytherin> sistpoty|work: About bug #427463 should I subscribe archive team?
[12:26] <sistpoty|work> slytherin: not yet, the FFe is approved if two motu-release team members give an ack, so you'll need another +1
[12:26] <slytherin> sistpoty|work: Isn't ScottK's comment counted as +1?
[12:27] <sistpoty|work> slytherin: not too sure actually, ScottK?
[12:27] <_ChanD_> is here used to request a shell?
[12:28] <slytherin> what shell?
[12:49] <sebner> sistpoty|work: I just talked to neuxiz DM, he'll release tomorrow (We'll have to backport the anti-upgrade-warning patch once it's ready though)
[12:50] <sistpoty|work> sebner: oh, nice
[12:54] <sebner> sistpoty|work: should I do the paperwork once it's needed?
[12:54] <sistpoty|work> sebner: yes, please
[12:54] <sebner> sistpoty|work: kk, the kids get nervous bug #355854  :P
[13:32] <ScottK> slytherin and sistpoty|work: That was not a +1, just a "then I won't say no".
[13:33] <sistpoty|work> that's what I assumed, thanks for making it clear ScottK
[13:53] <slytherin> ScottK: Thanks for clarification.
[13:59] <ScottK> james_w: I just uploaded claws-mail without the dillo viewer, so dillo can die now.
[14:30] <sebner> sistpoty|work: I hate FFe. nexuiz 2.5.2 is near :P
[14:31] <sistpoty|work> hehe
[14:43] <geser> sebner: how do you decided to proceed in the libjgrapht-java case?
[14:44] <sebner> geser: first step was to wait until you appear and ask for your thoughts ^^, I'm fine with both solutions so I wanted to hear what you think
[14:47] <geser> I'm fine with both solutions too, but I tend towards syncing libjgrapht0.6-java if possible as libjgrapht-java has some issues like mentioned by the DD (I assume it's about the included .jars in the tarball) which got removed in 0.6.0-8 and replaced with build-dependencies (less duplicated code)
[14:48] <slytherin> geser: sebner: AFAIK, the latest version in Debian unstable is much better. A simple sync should be possible.
[14:49] <sebner> geser: ACK, and to clear things, we need a FFe?
[14:49] <geser> slytherin: not really as the source package got renamed
[14:50] <slytherin> oh, did it? I thought it was same. Didn't pay attention to the source package name.
[14:50] <geser> libjgrapht-java exists only in experimental (the 0.7 version) and 0.6 is packaged as libjgrapht-java
[14:50] <geser> the last one should be libjgrapht0.6-java
[14:50] <geser> (all source package names)
[14:52] <geser> slytherin: the current libjgrapht-java in Ubuntu is split across universe and multiverse as sebner found out. we are discussion what's the best solution now: fix the component mess or sync the improved package
[14:52] <geser> syncing the new source package might need a FFe (we are not sure about it)
[14:53] <slytherin> sync is better option in my opinion.
[14:53] <sebner> geser: I'll ask in -devel now
[14:54] <geser> sistpoty|work: do we need a FFe to sync a renamed source package?
[14:55] <sistpoty|work> geser: if it's the same package, no. But you'll need an archive admin ;)
[14:55] <sistpoty|work> (same package contents even)
[14:56] <geser> it's the same upstream version (minus some removed .jars)
[14:57] <sistpoty|work> geser: then I assume there also shouldn't be problems getting it new'd :)
[14:59] <sebner> sistpoty|work: geser : james_w thinks we don't need a FFe and as sistpoty|work already agreed we are fine imho
[14:59] <geser> sebner: looks like you can go on with syncing
[15:01] <geser> and don't forget to get the current source removed once the new source package is in (add a note to not add it to the sync blacklist as the package might come back when libjgrapht-java (v0.7) moves from experimental to unstable)
[15:02] <sebner> geser: will then a removal of new 0.6 will be necessary again?
[15:03] <geser> no, it's a different API as far I can tell from the changelog entries
[15:03] <sebner> kk
[15:03] <geser> so it will stay till it gets removed from Debian too
[15:04] <superm1> james_w, geser sistpoty|work how come this has happened to a couple of packages in the last few days?  i just had to file a bug about image-size being renamed to libimage-size-perl yesterday
[15:04] <superm1> shouldn't we *not* be automatically removing source packages outside of the autosync period to avoid this type of problem and require manual solutions?
[15:06] <geser> superm1: it looks like some cleanup was done over the weekend (gtk1.2 and glib1.2 got removed, and some more apparently)
[15:06] <sebner> geser: bah, edge is br0ken again for me
[15:06] <geser> don't know if for all removed package a bug was opened
[15:06] <geser> sebner: how?
[15:07] <sebner> geser: If I try to file the sync request (only the titel so far) I get timeout
[15:07] <bddebian> Heya gang
[15:07] <sebner> huhu bddebian :)
[15:07] <geser> luckily you can use requestsync (the version in karmic) without the LP API
[15:08] <sebner> geser: requestsync never worked for me xD
[15:08] <geser> have you tried the current version in karmic?
[15:08] <bddebian> Hi sebner
[15:09] <sebner> geser: cool stuff, worked xD
[15:12] <geser> james_w: do you plan to cherry-pick the changes from launchpadlib r54 to have support for the stable LP API in python-launchpadlib?
[15:14] <sistpoty|work> superm1: iirc the removal script was run recently (not too sure why, but could have been to get rid of a few ftbfs bugs)
[15:14] <sistpoty|work> superm1: what broke by this though? the binary package name didn't change?
[15:14] <sistpoty|work> hi bddebian
[15:14] <superm1> sistpoty|work, the new package wasn't autosynced because we're not in the autosync phase
[15:14] <ScottK> sistpoty|work: For superm1's case it also got NBS'ed I think.
[15:14] <superm1> so i had to file a bug to get it synced in
[15:15] <quentusrex> How do I do an 'apt-get build-dep ./local-package.deb' ?
[15:15] <quentusrex> I have the dsc, and .changes files
[15:15] <superm1> so i just want to make sure we avoid doing this in the future outside of the autosync phase to prevent manually having to pull in new packages like this
[15:16] <sistpoty|work> superm1: interesting, because there are rdeps. Might have been an oversight, but you'd have to ask an archive admin for details
[15:16] <ScottK> superm1: I think it's a good UDS topic.
[15:17] <superm1> sistpoty|work, is there a document somewhere pointing who did this, so we can find out if it was just an oversight, a policy problem then, or a script problem?
[15:18] <superm1> ScottK, yeah i agree, depending on the root cause :)
[15:18] <sistpoty|work> superm1: yes: https://launchpad.net/ubuntu/+source/image-size/3.2-1
[15:18] <bddebian> Heya sistpoty|work
[15:18] <sistpoty|work> superm1: looks like you should ask pitti ;)
[15:28] <james_w> geser: hadn't thought about it
[15:28] <james_w> geser: it's just a constant, but would be worth having I think
[15:30] <geser> yes, so some scripts could use it in karmic and not be forced to use the EDGE one (in case it breaks again)
[15:38] <geser> ScottK, sistpoty|work: another gone missing package: bug 429420
[15:46] <ScottK> geser: I think "whoops, lost the package, let's get it back" is a bug fix.
[15:50] <sistpoty|work> *nod*
[15:57] <RoAkSoAx> morning
[16:53] <DktrKranz> soren: scott pointed me you could need sponsoring with python-mhash, if you need a sponsor feel free to ping me :)
[16:58] <ScottK> (for Debian, just to be clear)
[17:09] <geser> any C coder available to double-check a patch? http://paste.ubuntu.com/271027/
[17:11] <geser> it's for the usual "invalid conversion" error from a FTBFS
[17:20] <sistpoty|work> geser: the first snippet looks overly complex... since the original version had general_lang on the stack, you could simply cast the result to (char *)
[17:22] <geser> sistpoty|work: one problem was that the code in line 1835+1836 should probably work on general_lang to strip the language variant
[17:22] <sistpoty|work> geser: you can also simply cast away the const in the second snippet, zone is not denoted as const, so it's safe to be modified
[17:23] <geser> so I modified it first to strchr(general_lang, '-')[0] = 0; as we are sure that lang contains a "-" (and general_lang then too)
[17:24] <geser> just to releasize that the "-" could be outside the 32 chars, so I changed it more
[17:24] <sistpoty|work> geser: oh, sorry, misread there a lang for a general_lang :(
[17:27] <sistpoty|work> geser: how is lang declared?
[17:27] <geser> the easy change would be to change lang to general_lang in those two lines and ignore lang > 32 chars long
[17:28] <geser> didn't track it till the end but it's the lang attribute of a xml element, e.g. <html lang="de-DE">
[17:28] <geser> or similar
[17:28] <sistpoty|work> geser: no, I meant if it is a char * or a const char *
[17:29] <geser> const char * (line 1821)
[17:30] <geser> and from the description for this function I guess it's a bug that the current code modifies lang at all
[17:30] <geser> if lang is e.g. "fr-FR" then general_lang should be "fr", but lang still be prefered to general_lang
[17:31] <geser> but the current code modifies lang to "fr" and keeps general_lang at "fr-FR" and changing the order in effect
[17:32] <sistpoty|work> hm... well, then your patch seems to do the right thing
[17:33] <sistpoty|work> (at least from what I can gather by looking at the patch)
[17:35] <geser> I guess I try contacting upstream about it before I upload
[17:35] <sistpoty|work> geser: sounds like a good idea :)
[17:37]  * sistpoty|work heads home now... cya
[17:53] <Ng> am I right in vaguely remembering that there's some wicked new magic for packaging python stuff?
[17:53]  * Ng looks at dholbach 
[17:55] <dholbach> err, debhelper 7?
[17:55] <ScottK> dholbach: I think he's thinking about quickly
[17:55] <Ng> dholbach: possibly, I didn't pay much attention at the time I saw references to it. Is there a handy URL I should go and read?
[17:55] <Ng> ScottK: no not quickly, unless that can take an existing python app and package it
[17:55] <ScottK> Nope
[17:56] <dholbach> ScottK: I haven't played with it yet, but I guess you need to use it for the whole project
[17:56] <ScottK> Yeah
[17:56] <Ng> I already finished coding, so I think it's too late for quickly to help me
[17:57] <dholbach> alright, I need to head out - see you guys tomorrow
[17:58] <dholbach> Ng: try out debhelper 7 :)
[17:58] <dholbach> just start with something like this
[17:58] <dholbach> #!/usr/bin/make -f
[17:58] <dholbach> %:
[17:58] <dholbach> 	dh $@
[17:58] <RoAkSoAx> dholbach, Heya! I sent you my answers already, have you received them?
[17:58] <dholbach> RoAkSoAx: no, I'm afraid not
[17:58] <james_w> Ng: python-distutils-extra is probably what you are thinking of
[17:58] <dholbach> which email did you send them to?
[17:59] <Ng> james_w: that also sounds vaguely familiar
[17:59] <dholbach> can you resend to dholbach at ubuntu dot com?
[17:59] <dholbach> RoAkSoAx: ^
[17:59] <Ng> hmm I suppose I should write a setup.py ;)
[18:00] <RoAkSoAx> dholbach, I just replied to the email. And, done, I forwarded it to that other email just now!
[18:01] <dholbach> thanks RoAkSoAx
[18:01] <Ng> james_w: is there a reasonably simple guide for using that?
[18:01] <dholbach> RoAkSoAx: bah - it went to spam!
[18:01] <dholbach> RoAkSoAx: will have a look into it tomorrow!
[18:01] <Ng> maybe I should just persuade nxvl that my new code is as awesome as Terminator and get him to package it too ;)
[18:01] <RoAkSoAx> dholbach, haha ok awesome :) thanks.
[18:01] <dholbach> have a great rest of your day! see you tomorrow! :)
[18:02] <james_w> Ng: not that I know of, sorry
[18:02] <Ng> ok
[18:03] <Ng> even if there was I bet it doesn't handle screensavers, because I'm probably the only person ever to have tried writing a gnome screensaver in python ;)
[18:07] <mzz> Ng: yeah, write a setup.py, packaging is fairly straightforward once you have one (there's a guide on the wiki somewhere)
[18:08] <mzz> Ng: I think the first step in the guide is "write a setup.py if what you're packaging doesn't have a build system yet" :)
[18:08] <Ng> heh
[18:08] <Ng> that would make sense :)
[18:09] <mzz> (there's a bit of magic involved to support multiple python versions automatically, but that's all handled for you automagically if you use cdbs, and still mostly automatically if you use just debhelper, especially if it's a pure python thing)
[18:10] <mzz> I haven't used python-distutils-extra myself.
[18:10] <ScottK> Last time I timed myself it took less than an hour to do a python package once I had setup.py and most of that was making sure I had debian/copyright correct.
[18:11] <mzz> that sounds about right
[18:12] <mzz> (if there's a page out there describing what open source software authors should do to write easily packageable software I wish "explicitly mention which version(s) of the gpl you're distributing under" to be prominently mentioned)
[19:00] <slytherin> hyperair: there?
[19:09] <hyperair> slytherin: pong
[19:09] <slytherin> hyperair: remuco for removed from Ubuntu. https://edge.launchpad.net/ubuntu/+source/remuco-server/+publishinghistory :-(
[19:10] <RoAkSoAx> should changes in a config.guess file appear on debdiff, or in such case, should they be applied when uploading?
[19:10] <hyperair> ah figures. i did get remuco-server removed from debian didn't i?
[19:11] <slytherin> hyperair: right, but the replacement is not in Ubuntu yet, right.
[19:12] <hyperair> slytherin: right. i really need to find time to fix remuco
[19:31] <RoAkSoAx> Heya guys, should changes in a config.guess file be removed from a debdiff, or in such case, should they be applied when uploading?
[19:32] <Laney> filter it out
[19:32] <andv> RoAkSoAx, if the changes are auto-generated during build they should be removed
[19:33] <andv> if you autotoolized the source it shouldnt appear on the debdiff anyway
[19:33] <andv> if you use autotools run the on rules, not randomly on the source
[19:33] <andv> * them
[19:35] <pochu> or put the changes on a patch
[19:35] <pochu> (that's what I do)
[19:35] <RoAkSoAx> ok so I should remove those changes from the debdiff, patch a new source with that debdiff, debuild -S and upload?
[19:36] <andv> RoAkSoAx, if those changes are not wanted they should be removed
[19:37] <andv> therefore you remove then and you should have a clean debdiff
[19:38] <RoAkSoAx> andv, those changes are introduced automatically. So, when I debdiff the debian dsc with the new ubuntu dsc those changes appear in the debdiff.
[19:39] <andv> RoAkSoAx, then remove then
[19:39] <andv> * them
[19:39] <andv> RoAkSoAx, check out diff.gz after debuild
[19:40] <andv> RoAkSoAx, it would be nice that those changes not appear on the diff.gz
[19:40] <fabrice_sp> kklimonda, there? It's about bug #409188
[19:41] <RoAkSoAx> andv, they appear in the diff.gz. How would I remove them if they are automatically generated?
[19:42] <pochu> RoAkSoAx: that's likely because there's something wrong in debian/rules
[19:43] <pochu> i.e. it's copying /usr/share/foo/config.guess in build and not cleaning it in clean
[19:43] <RoAkSoAx> pochu, this is the debdiff: http://pastebin.ubuntu.com/271118/
[19:43] <pochu> or the other way round...
[19:44] <pochu> RoAkSoAx: can you paste debian/rules?
[19:44] <andv> RoAkSoAx, do you remove those files in the clean target?
[19:44] <andv> they are automatically generated so you can remove them
[19:44] <RoAkSoAx> pochu, this is the rule: http://pastebin.ubuntu.com/271119/
[19:44] <andv> RoAkSoAx, yeah, u don't remove them
[19:44] <andv> RoAkSoAx, add a clean target for it
[19:44] <RoAkSoAx> andv, thanks  :)
[19:45] <andv> np, let me know if it worked
[19:45] <pochu> yeah what I guessed :)
[19:45] <pochu> or just run dpkg-source -b foo-1.0/, rather than debuild
[19:46] <pochu> if you don't want to increase the diff with debian
[19:54] <RoAkSoAx> pochu, andv : ok I've added "-rm config.guess config.sub" to the clean target before dh_clean and in the debdiff I now get this: http://pastebin.ubuntu.com/271127/
[19:57] <andv> RoAkSoAx, try placing it before distclean
[19:57] <andv> use rm -f
[20:01] <RoAkSoAx> andv, the same, changes are still showed in the debdiff
[20:02] <andv> RoAkSoAx, cause of this i guess:
[20:02] <andv> ifneq "$(wildcard /usr/share/misc/config.sub)" ""
[20:02] <andv> 	cp -f /usr/share/misc/config.sub config.sub
[20:04] <RoAkSoAx> andv, yes that's the reason, but should those changes be applied? I mean, if that "if" stays there, changes on those files will always be showed on the debdiff.
[20:05] <andv> RoAkSoAx, yes, does previous packages got that in the diff.gz?
[20:05] <Laney> you should remove them in the clean target
[20:06] <andv> Laney, he tried that already
[20:06] <andv> read backlog
[20:07] <Laney> then all you'd see is it being deleted in the debdiff
[20:07] <Laney> thats alright
[20:07] <RoAkSoAx> andv, yes, diff.gz from debian also contains changes in config.sub and config.guess
[20:07] <andv> RoAkSoAx, so keep them
[20:08] <andv> you will have a tainted diff
[20:08] <andv> but as long as it builds / works fine
[20:08] <RoAkSoAx> andv, ok will do. Thanks guys!
[20:08] <andv> np
[20:14] <dhillon-v10> hi all  I need some help with getting source of a package with  dget
[20:27] <geser> what problem do you have?
[20:35] <Daviey> Hi, if i'm moving a script from one package to another.. dropping it in one, introducing it in another, same name and install path
[20:35] <Daviey> should the packages contain a Conflicts for versions pre change?
[20:36] <Daviey> They should be entering the archive at the same time, so should it matter?
[20:36] <Daviey> (for karmic)
[20:37] <geser> Replaces would be a better choice
[20:38] <Daviey> geser: Hmm.. i don't follow.. the rest of the orginal packages still exist
[20:38] <Daviey> just a single script is being ported
[20:39] <geser> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces, 7.6.1 Overwriting files in other packages
[20:39] <geser> that's exactly what you want
[20:40] <Daviey> geser: thanks, i'll read :)
[20:40] <geser> it tells dpkg that's ok that pkg_b overwrites some files which're also in pkg_a
[20:50] <nxvl> james_w: ping
[20:50] <james_w> hey nxvl
[20:50] <james_w> how's it going?
[20:51] <nxvl> james_w: good
[20:52] <nxvl> james_w: i was looking for information on bzr packaging, but i don't remember where are the wiki pages or if there are new ones
[20:52] <nxvl> can you please point me to the docs?
[20:52] <james_w> https://wiki.ubuntu.com/DistributedDevelopment/Documentation
[20:52] <james_w> and /usr/share/doc/bzr-builddeb/user_manual
[20:52] <nxvl> james_w: thank you!
[21:01] <mruiz> james_w, how are you going?
[21:01] <cody-somerville> james_w, I'm using bzr-builder. My packaging branch has the debian directory contents in a directory called debian so when I nest it, I have to nest it inside a directory and can't nest in the root of the branch as a bzr branch already exists there and is locked. So what I'm doing is nesting it in debian and moving debian/debian/* into debian/ and rmdiring debian/debian - is there a simpler way to do this?
[21:03] <cody-somerville> (without breaking my ability to continue to merge in work from debian's branch)
[21:03] <james_w> hi mruiz
[21:03] <james_w> hey cody
[21:03] <mruiz> james_w, thanks for your reply :-)
[21:04] <james_w> cody-somerville: you're the second person with that issue. I haven't thought of an elegant solution yet
[21:04] <james_w> there may not even be one
[21:04] <james_w> mruiz: np :-)
[21:06] <mruiz> james_w, I got the source of a package and I want to make changes. Should I create a new branch ?
[21:06] <james_w> yuppers
[21:32] <RoAkSoAx> hey guys, when fixing a ftbfs, I get a lintian warning about that the compat level is deprecated. Should I raise the compat level?
[21:34] <ScottK> RoAkSoAx: I wouldn't unless you go through the package and make sure it meets the requirements of the new compat level.
[21:36] <ScottK> james_w: If I'm working on a project where I'm trying to convince them to use bzr and I have to deal with git fans complaining bzr is slow, what repository format do I want to be super fast (small project > a dozen developers)?
[21:36] <RoAkSoAx> ScottK, cool thanks. And what about debian-rules-calls-debhelper-in-odd-order dh_makeshlibs or dh_desktop-is-deprecated?
[21:37] <ScottK> I'd understand the odd-order one and see if it does it for a good reason.
[21:38] <ScottK> The others aren't particularly exciting, I don't think.
[21:39] <RoAkSoAx> ScottK, ok cool thanks :)
[22:01] <Ng> so really really strange problem. I'm running karmic and have only py2.6 installed, I've just packaged my app (a python package and a python script), installed the package and the script fails because it can't import my pthon package, but if I run the python interpreter by hand I can import it
[22:02] <james_w> ScottK: the default format in the about to be released 2.0 is the latest and greatest
[22:02] <james_w> Ng: what's the #! of the script?
[22:02] <ScottK> james_w: How is that for compatibility with current bzr?
[22:03] <james_w> it was 1.16 or 1.17 that is the first to be able to read it
[22:03] <Ng> james_w: /usr/bin/python
[22:03] <james_w> the latter I think
[22:03] <ScottK> I see 1.14-rich-root as the most current format (I need git-bzr to work)
[22:03] <Ng> hhand /usr/lib/python2.6/dist-packages is in sys.path, which is where pycentral has put the module
[22:03] <Ng> -hh
[22:03] <soren> Ng: Is the package on revu or something?
[22:03] <james_w> Ng: and I assume that it doesn't do sys.path munging, relative imports or nothing?
[22:03] <Ng> soren: newp, I only made it a few minutes ago
[22:04] <ScottK> OK.   I guess that means I need to get a bzr backport going.
[22:04] <Ng> james_w: it's a "from foo.bar import Baz" where "class Baz:" is in /usr/lib/python2.6/dist-packages/foo/bar.py
[22:04] <james_w> what's the variant of ImportError you get?
[22:05] <Ng> soren: it is on LP though, bzr+ssh://bazaar.launchpad.net/~cmsj/lifesaver/trunk/
[22:05] <james_w> module foo.bar has no member Baz, or module foo has no member bar
[22:05] <Ng> james_w: ImportError: No module named bar
[22:05] <james_w> /usr/lib/python2.6/dist-packages/foo/__init__.py exists?
[22:06] <Ng> james_w: yep. it's just got "pass" in it, but it exists
[22:07] <soren> Ng: can you paste the full error?
[22:07] <james_w> and you say that "/usr/bin/python -c 'from foo.bar import Baz'" works?
[22:07] <Ng> http://paste2.org/p/425384
[22:07] <Ng> james_w: yep
[22:08] <james_w> recursion!
[22:08] <Ng> -(cmsj@kiryo)-(~)- /usr/bin/python -c 'from lifesaver.twitter import Twitter'
[22:08] <Ng> -(cmsj@kiryo)-(~)-
[22:08] <james_w> lifesaver.py
[22:08] <james_w> your script matches the module name
[22:08] <geser> Ng: does the script perhaps modify the search path?
[22:08] <james_w> so it's shadowing the installed module
[22:08] <james_w> causing it to look under that
[22:09] <james_w> causing it to try reading lifesaver.py
[22:09] <Ng> james_w: oh. that's quite annoying ;)
[22:09] <james_w> and then bailing before the infinite recursion strikes
[22:09] <Ng> james_w: how come that doesn't happen when I do a ./lifesaver.py ?
[22:09] <james_w> *handwave*
[22:09] <james_w> no idea
[22:09] <Ng> ohhhh, because pycentral knows about /usr/lib/xscreensaver/lifesaver.pyc
[22:10] <Ng> but not ~/code/blah/lifesaver.py
[22:10] <Ng> hmm
[22:10] <Ng> I'll go figure out a better name for either the module or the script. thank you very much :)
[22:14]  * Ng wonders how wildly wrong it is to be installing the script in the screensaver directory with data_files
[22:16] <geser> james_w: any idea how to force the updated from python-zopeinterface to python-zope.interface? I've just seen that I still had the old package installed as it still fulfills the dependencies (e.g. for python-lazr-restfulclient)
[22:17] <james_w> geser: hmm, good question
[22:17] <james_w> we may need a transitional package
[22:19] <james_w> I'm not in the mood for thinking it through right now though
[22:23] <geser> an other solution would be drop the "| python-zopeinterface" for one central package so that it pulls in python-zope.interface
[23:28] <dtchen> straightforward fix for oprofile at http://launchpadlibrarian.net/31803795/oprofile_0.9.4%2Bcvs20090629-2ubuntu2.debdiff
[23:48] <c_korn> is there a script to get the changelog of a specified package which is installed ?
[23:49] <c_korn> hm, I think zcat /usr/share/doc/$1/changelog.Debian.gz | less is enough :P
[23:50] <azeem> or zless
[23:52] <c_korn> azeem: thanks, never heard of that :)