[12:14] <geser> 2
[12:14] <TheDumbo> 3
[12:15] <mok0> Aha! Someone's here :)
[12:15] <tarzeau> 4
[12:15] <Fujitsu> fnf
[12:16] <mok0> Does someone have time to look at my package http://revu.tauware.de/details.py?upid=5478
[12:31] <StevenHarperUK> lo : can anyone review my Package on REVU?
[01:42] <bryyce> Would someone be willing to review a package - editres?  I'm in the process of updating the x11 apps for Gutsy - http://people.ubuntu.com/~bryce/Uploads/ editres* 
[01:48] <crimsun> bryyce: +1.
[01:49] <bryyce> crimsun: thx
[02:52] <joejaxx> :P
[02:53] <joejaxx> well time to build tribe 1 discs :P
[03:56] <persia> Is there a standard way to update php.ini when installing new php libraries?
[03:57] <ajmitch> persia: maybe /etc/php5/conf.d/
[03:58] <persia> ajmitch: Thanks.
[04:15] <bryyce> hi, I've got a bunch of X app updates.  Would someone be willing to review/upload them?  There's 9 packages, all with basically the same changes.  http://people.ubuntu.com/~bryce/Uploads/
[04:17] <persia> bryyce: http://people.ubuntu.com/~bryce/Uploads/editres_1.0.3-0ubuntu1.debdiff seems pretty big, and touches files outside debian/.  What change are you intentionally making?
[04:17] <bryyce> persia: these include new upstream release, plus some packaging changes to debian/control, etc.
[04:20] <persia> bryyce: I'd recommend that you file a bug for each (add the "upgrade" tag), upload them to REVU, attach either an interdiff or diff -urN of debian/ to the bugs and include the REVU URL in a comment, and subscribe ubuntu-universe-sponsors to request upload.
[04:37] <persia> bryyce: Um.  Rather, REVU might take a while.  Still, interdiffs would be great, and subscribing U-U-S makes sure that if nobody looking now gets them all, someone will catch it later.
[04:42] <joejaxx> anyone know how often u-m-s gets checked?
[04:44] <RAOF> What's the best way to get a new upstream version of KVM into universe.  Whip up some packages and put them on revu?  I'd like my KVM to work, and bug #1119254 is in the way :)
[04:45] <RAOF> Debian doesn't have the new upstream version, or I'd just merge/sync it.
[04:45] <bryyce> persia: hmm, thanks for the info, guess I need to do some reading.  I'll try again some other time.
[04:45] <persia> RAOF: Put the new upstream on REVU, but also file a bug, attach the interdiff, and subscribe U-U-S to get attention as a new revision, rather than a new package.
[04:45] <RAOF> persia: Cool, thanks.
[04:45] <persia> bryyce: I'd be happy to help you through it, if you like.
[04:48] <bryyce> persia: thanks, maybe another day; I'm pretty wiped out
[04:49] <persia> bryyce: Sure.  Thanks a lot.
[05:12] <Simon80> I just tried kitchensync, I think I'm going to cry - it looks like there must be two different kitchensyncs, because the opensync frontend is most definitely not what comes down the pipe on an apt-get install kitchensync
[05:13] <Simon80> confusion makes me sad
[05:14] <lifeless> Simon80: check the version
[05:15] <lifeless> what version did you expect?
[05:15] <Simon80> 3.5.6
[05:15] <Simon80> is the apt-get version
[05:15] <lifeless> yes, I know
[05:15] <lifeless> I think you'll find its the 4.x versions that use opensync
[05:15] <Simon80> fun
[05:16] <Simon80> I wish new software would come out of the pipeline sooner :(

[05:17] <jussi01> hmmmm.... my memory is going, someone remind me of the dpkg command to get source from .dsc ? Please....
[05:17] <persia> jussi01: dpkg-source -x foo.dsc
[05:18] <jussi01> persia: thanks... 
[05:30] <persia> Ah.  Nevermind.  I seem to have misterpreted ~revu.  I retract that entirely.
[05:30] <jussi01> lol
[05:49] <nixternal> hi, my name is Rich, and I am an ubuntuholic
[06:11] <rollerskatejamms> Anybody know where the Rails root directory is on ubuntu?
[06:11] <StevenK> /usr/share/rails
[06:25] <persia> RAOF: Are you working on 119254?
[06:28] <RAOF> persia: Kind of.  If you want to work on it, go ahead :)
[06:29] <RAOF> If not, I'll assign it to me.  It seems it's a bit more than just packaging a new upstream, though - I need to check which version works against the 2.6.22-ish kernel we've got.
[06:29] <StevenK> 2.6.22-rc something?
[06:29] <persia> RAOF: No, I just has a minute between things, and checked.  If you are working on it, please assign yourself and set "In Progress".  From what I understand, the easiest solution is the new upstream.
[06:30] <persia> RAOF: Ah.  Good luck.
[06:30] <RAOF> Failing that, I could see whether I could just build the kvm module inside the kvm package.  But I can't think of a package that does that, and there's probably a number of really good reasons for it :)
[06:31] <StevenK> RAOF: At install time?
[06:32] <persia> RAOF: The really big reason not to do that is that the kvm package would need to be rebuilt everytime the kernel had an ABI bump, and there would be a lag (and lots of no-changes rebuild entries in the changelog).  That's why the Ubuntu kernel carries so many modules.
[06:32] <persia> StevenK: even with module-assistant, that doesn't really address the issue.
[06:33] <StevenK> Maybe the solution is to stamp on BenC's forehead, "Don't forget about kvm!"
[06:34] <RAOF> :)
[06:34] <persia> RAOF: If you need an update to the kernel modules source at the same time as the new upstream, add a linux-source-2.6.22 task to the bug after including the relevant patch (or better, a pointer to something that is being accepted into Linus' trunk) to get the right attention.
[06:35] <RAOF> Right, Ok.
[06:35] <persia> RAOF: For extra bonus points, get a local copy of the ubuntu git, and pull the patch to make sure it applies cleanly :)
[06:36] <RAOF> Yeah, that wouldn't be too hard.
[06:51] <RAOF> Wouldn't it be nice if running ./configure would tell you if you're missing a library. Stupid kvm/qemu :(
[06:52] <persia> RAOF: If it doesn't, then ./configure isn't checking for libraries properly.  That's a bug with the package build system.
[06:53] <RAOF> Yes, I know,.
[06:53] <RAOF> kvm's build system is some custom-hacked configure which doesn't check for everything it needs.
[06:53] <persia> ugh :(
[06:53] <RAOF> Yes.
[06:53] <RAOF> Otherwise, I'd just try to *fix it*
[06:53] <RAOF> Autotools may be impenetrable, arcane magics, but at least there's a manual :P
[06:54] <jmg> s/manual/grimoire/
[06:54] <RAOF> :)
[06:54] <jmg> thats why i like sourcemage's changelogs
[06:54] <jmg> Added spell for: firestarter to master grimoire
[06:55] <StevenK> RAOF: If ./configure is missing something, it's probably missing a few lines in configure.in
[06:56] <StevenK>           && rm -f $file && PATH=../src:$PATH no -o $file en.po
[06:56] <StevenK> /bin/sh: no: not found
[06:56] <StevenK> Hrm. Neat.
[06:57] <RAOF> statik: That's assuming there *is* a configure.in.  *custom* *hacked* *configure* :(
[06:58] <RAOF> s/statik/ StevenK /
[06:59] <StevenK> Twitch.
[07:00] <RAOF> Yes
[07:00] <Hobbsee> morning all
[07:00] <persia> Hobbsee: Good afternoon (or did you travel?).
[07:01] <RAOF> Afternoon Hobbsee 
[07:01] <Hobbsee> persia: i live on european time.  or australian time.  or both.  or a mixture
[07:01] <persia> heh
[07:03] <StevenK> No, Hobbsee lives on Hobbsee time.
[07:03] <StevenK> TZ=HST date , etc
[07:03] <StevenK> Hrm, HST actually exists.
[07:04] <StevenK> (And is -10)
[07:04] <Hobbsee> hehe
[07:06] <StevenK> Ah ha. HST == Hawaii-Aleutian time zone
[07:16] <crimsun> there, fixed.  Now we handle user stupidity for most cases.
[07:17] <Hobbsee> woo!
[07:17] <Hobbsee> do you shoot them?
[07:17] <persia> crimsun: In a specific case, or for all pebkac situations?
[07:17] <crimsun> no, we spoonfeed them.
[07:17] <Hobbsee> awww
[07:17] <Hobbsee> shooting them is more effective.
[07:17] <crimsun> we tell them "no, silly, you were supposed to do _this_, so now do it."
[07:17] <lifeless> crimsun: why don't we just do it?
[07:18] <lifeless> crimsun: in the first place?
[07:18] <crimsun> lifeless: because we're not omniscient.
[07:18] <Hobbsee> hiya lifeless 
[07:18] <crimsun> the app in question requires the user to provide a parameter, and the user must provide it for the command to be useful.
[07:19] <crimsun> the app can't simply provide "a sane default"
[07:19] <lifeless> hi Hobbsee, enjoying the weather ;)
[07:20] <Hobbsee> lifeless: brrrr....
[07:20] <Hobbsee> lifeless: and i'm missing playing Mao.
[07:20] <Hobbsee> lifeless: and UDS in general.
[07:20] <crimsun> persia: fairly specific case.  I'd have won some award for the latter...
[07:20] <jsgotangco> you miss Mao eh?
[07:20] <Hobbsee> jsgotangco: yeah
[07:20] <crimsun> persia: (award being an enjoyable early death, I think)
[07:20] <Hobbsee> it's a great game :)
[07:20] <jsgotangco> i suck at it
[07:20] <persia> crimsun: heh
[07:21] <jsgotangco> i'm not too evil enough to play it
[07:22] <lifeless> Hobbsee: organise some local folk
[07:22] <Hobbsee> lifeless: i dont have the contacts :(
[07:22] <Hobbsee> not many, anywya
[07:22] <lifeless> Hobbsee: they don't have to be foss folk
[07:22] <Hobbsee> lifeless: i cant remember - you're in sydney or melbourne?
[07:22] <lifeless> syd
[07:23] <lifeless> you're in melb right?
[07:23] <Hobbsee> oh right
[07:23] <Hobbsee> could just abduct people from SLUG then
[07:23] <Hobbsee> bah, melbourne.  no.
[07:23] <Hobbsee> syd here too.
[07:23] <ajmitch> Hobbsee: you don't have 'winter' there
[07:23] <lifeless> Hobbsee: hmm. Why have you not been turning up at SLUG? :)
[07:23] <lifeless> tsk!
[07:23] <Hobbsee> ajmitch: true that.  i became a wuss since leaving adelaide.  and i'm thin, so i'm allowed.
[07:23] <ajmitch> hello lifeless 
[07:23] <Hobbsee> lifeless: because...many reasons.
[07:23] <lifeless> ola ajmitch 
[07:24] <Hobbsee> lifeless: i did once
[07:24] <ajmitch> RAOF: luxury!
[07:24] <jsgotangco> Hobart seems to be a nice place to stay
[07:24] <RAOF> s/stay/live/
[07:24] <lifeless> Hobbsee: Oh, then I retrack my tsk. kst. There it goes.
[07:24] <RAOF> :)
[07:54] <Q-FUNK> https://bugs.launchpad.net/ubuntu/gutsy/+source/utf8-migration-tool/+edit-packaging
[07:54] <Q-FUNK> I'm trying to add a link to the upstream debian package. I don't understand what that Release Series is all about.
[07:59] <lifeless> its a series of releases where they would all be considered 'roughly the same'
[07:59] <lifeless> e.g. automake 0.16.0 0.16.1 0.16.2 - its the '0.16 series of releases'
[07:59] <lifeless> generally you have a series for the most granular component of the version number
[08:00] <lifeless> in particular in the launchpad model you can only have *one* version of a given series in the distro at once
[08:01] <Q-FUNK> that doesn't tell me the syntax.
[08:02] <lifeless> cmon, give me a break, you didn't ask for syntax you asked for what its all about
[08:02] <lifeless> anyhow looking up, you can't link to the debian package via the packaging-links - they link package to upstream, not package-to-other-distro
[08:03] <Q-FUNK> true enough. :)
[08:03] <Hobbsee> hiya elkbuntu 
[08:03] <lifeless> 'lo elkbuntu 
[08:03] <Q-FUNK> well, debian is the upstream. it's a native package
[08:04] <lifeless> then you would have a project in launchpad for the thing
[08:04] <Q-FUNK> and that info is needed to be able to mark a bug as also affecting another distro.
[08:05] <lifeless> and if the authors have multiple release series - e.g. if they have point releases for sarge etc and a mainline- make them, otherwise just use 'trunk'
[08:05] <persia> Q-FUNK: Rather than using "Also affects Upstream", try "Also affects distribution", and select Debian - just add the link to the BTS.
[08:08] <Q-FUNK> persia: ok, that seems to wokr better.  thanks!
[08:09] <Q-FUNK> strange that debian cannot be considered upstream for a native package, thoguh.
[08:11] <StevenK> And how does that help?
[08:12] <Q-FUNK> alioth only makes sense if a package is team maintained or impossibly complex.  otherwise, it's a waste of alioth's resources.
[08:12] <persia> StevenK: If a previously native package is hosted in an RCS, and "Upstream" releases are made, from which new revisions are generated, all the confusions go away.
[08:12] <persia> Personally, I think native packages are legacy from before alioth.
[08:13] <Q-FUNK> they are not. 
[08:13] <persia> Q-FUNK: I think that native packages should be "upstream" hosted in alioth, with debidan revision numbers, to more easily manage branches for releases, etc.  It's only my opinion, and certanily not relfective of current practices.
[08:14] <StevenK> persia: Being the maintainer of a native packae, I can say hand over heart, don't wanna!
[08:14] <StevenK> package, even
[08:15] <Q-FUNK> understood.  then again, a native debian package tends to be for software that only makes sense within the debian universe. it doesn't usually need to be branched.
[08:15] <persia> StevenK: I completely understand :)  I've convinced one maintainer to do that for Ubuntu native packages, but I don't expect native packages to ever really go away.
[08:16] <persia> Q-FUNK: Branches for each release, or for larger native packages with open maintainers, possibly separate branches for Debian,Ubuntu,Mepis,etc. (although this makes more sense with distributed version control than with SVN).
[08:23] <crimsun> this is a bit troublesome: /dev/dm-0              13G -968M   13G   -  /
[08:24] <Hobbsee> haha...well done!
[08:25] <persia> crimsun: Um..  5% extra special secret admin space?
[08:50] <crimsun> persia: no clue, will have to check on next boot
[09:06] <dholbach> good morning
[09:07] <RAOF> Good evening, dholbach :)
[09:07] <dholbach> hiya RAOF
[09:07] <Hobbsee> hiya dholbach!
[09:07] <RAOF> It'
[09:08] <RAOF> s a bit love-in in -motu!
[09:08] <jussi0l> hello everyone
[09:09] <jussi0l> hello dholbach 
[09:09] <dholbach> heya jussi01
[09:11] <jussi0l> anyone know what the equivalent of debians x-window-system-dev is??
[09:11] <jussi0l> do we have that?
[09:11] <RAOF> xorg-dev?
[09:11] <RAOF> But you're not meant to build-depend on that :)
[09:12] <jussi0l> RAOF, im installing cedega ;)
[09:12] <RAOF> Looks like xorg-dev should cover any deveopment *with* X11 you may require :)
[09:12] <jussi0l> cvs...
[09:13] <RAOF> I'd be surprised if xorg-dev *didn't* pull in everythning you need.
[09:14] <jussi0l> ok..:D 
[09:14] <jussi0l> gah... 
[09:14] <jussi0l> hate errors...
[09:14] <RAOF> Stupid cedega?
[09:14] <jussi0l> RAOF, are you busy?any idea how to fix: WineCVS.sh: 48: Syntax error: "(" unexpected
[09:15] <jussi0l> RAOF, yeah...stupid cedega
[09:15] <crdlb> ...use wine?
[09:15] <crimsun> jussi0l: prepend bash?
[09:15] <jussi0l> my little brother wants need for speed... (rolls eyes)
[09:15] <RAOF> Or edit the file to have a /usr/bash symlink.
[09:15] <RAOF> s/symlink/shebang/
[09:16] <RAOF> And NFS works on cedega but not wine?
[09:16] <jussi0l> yeah
[09:16] <RAOF> Sucks.
[09:16] <jussi0l> sigghh...
[09:17] <jussi0l> caleb@caleb:~/Desktop$ bash sh WineCVS.sh
[09:17] <RAOF> Doesn't make with the working?
[09:17] <jussi0l> /bin/sh: /bin/sh: cannot execute binary file
[09:17] <RAOF> You probably don't want to bash sh :)
[09:17] <RAOF> Just "bash WineCVS.sh" would hopefully work.
[09:18] <jussi0l> heh... now i feel stupid... thanks
[09:18] <RAOF> And that works?
[09:19] <jussi0l> RAOF, yeah, its working... any idea which profile i should use?
[09:21] <RAOF> Oh, so it hasnt' built yet :)
[09:21] <RAOF> Eh.  Whatever the default was.
[09:22] <jussi0l> gah...
[09:22] <RAOF> Or, rather, put it in $HOME, and use latest CVS.
[09:22] <RAOF> I just can't remember the options, frankly :)
[09:22] <jussi0l> hehe..ok
[09:22] <jussi0l> gah, this is a really annoying one
[09:22] <jussi0l> Running Profile : cvscedega_head
[09:22] <jussi0l> Enter root Password: 
[09:22] <jussi0l> su: Authentication failure
[09:22] <jussi0l> Sorry.
[09:22] <jussi0l> oopps
[09:22] <jussi0l> sorry bout the flood
[09:23] <RAOF> You should be able to build/install it to $HOME, which won't requrie root.
[09:23] <RAOF> Or even require root!
[09:29] <jussi0l> wb RAOF 
[09:30] <RAOF> Still working?
[09:30] <StevenK> !test
[09:30] <ubotu> failed
[09:30] <jussi0l> no... i cant get past that root thing
[09:31] <RAOF> I was sure there was a "local only" install.
[09:31] <RAOF> Worst case scenario is you actually set a root password, I suppose
[09:31] <jussi0l> hmmm.. should i run the script as root? or not a good idea??
[09:32] <jussi0l> ie. sudo bash WineCVS.sh ??
[09:33] <RAOF> That'd probably work too.
[09:36] <jussi0l> RAOF, thanks, seems to be working now... 
[09:36] <jussi0l> sorry everyone else for clogging up motu channel with cedega help...
[09:40] <RAOF> c'mon archive.ubuntu.com, be faster.
[09:40] <RAOF> Daddy wants to build a new kvm package, that actually works.
[09:41] <shawarma> RAOF: Use a mirror?
[09:41] <StevenK> RAOF: *Twitch*
[09:41] <RAOF> Well, that would be the obvious solution.  But obviousness is for crazies.
[09:42] <jussi0l> lol
[09:43] <Hobbsee> mmm...crazies...
[09:44] <RAOF> Hungry, Hobbsee ?] 
[09:44] <Hobbsee> yeah
[09:44] <Hobbsee> rathe
[09:44] <Hobbsee> it's about time for breakfast
[09:44] <RAOF> ...
[09:44] <RAOF> It's about time for *dinner*
[09:44] <Hobbsee> bah.  dinner at this hour?
[09:45] <RAOF> Yeah, maybe it's a bit late :)
[09:45] <Hobbsee> it's lunchtime, definetly. but not dinner.
[09:46] <RAOF> That's true.
[09:51] <Hobbsee> ...wow.  http://community.livejournal.com/customers_suck/22037088.html#cutid1
[09:53] <Burgundavia> Hobbsee: need to be logged in
[09:53] <RAOF> Who makes a restricted access blog?
[09:53] <Burgundavia> the skinny?
[09:53] <Hobbsee> oh, point, sorry
[09:53] <Hobbsee> forgot about that
[09:53] <Hobbsee> RAOF: some entries are private - some bosses and such get angry if you display who you work for, etc.
[09:53] <Q-FUNK> even logged in, it fails.  probably only visible to friends.
[09:53] <RAOF> Pfft.
[09:53] <Hobbsee> it's the whole corporate blogging thing
[09:53] <Hobbsee> yeah, sorry, forgot about that.  it's friends only
[09:55] <vil> heya, bluekuja
[09:58] <crimsun> silly blogs.
[09:59] <RAOF> Well, that looks like it was easier than I feared.  Looks like I can just drop in the new upstream KVM and it works.  Yay.
[10:00] <Hobbsee> crimsun: that community stops me from shooting people.  at least a bit.
[10:00] <Hobbsee> (yay, stupid customers)
[10:00] <Burgundavia> jussi0l: I object!
[10:01] <jussi0l> Burgundavia, fix my cedega then...
[10:01] <Burgundavia> no, the last part
[10:01] <geser> vil: if you sponsor uploads: you can use -k to debuild (or dpkg-buildpackage) to get it signed with your key so you don't need to change the changelog to your name
[10:01] <jussi0l> hehe
[10:01] <Hobbsee> weasel boy is objecting.   you must change.  :P
[10:01] <jussi0l> lol
[10:01] <Burgundavia> Hobbsee: I will smack you
[10:01] <Hobbsee> Burgundavia: 
[10:01] <Burgundavia> :D
[10:02] <jussi0l> now now, thats harsh...
[10:02] <vil> geser, right, dholbach just told me
[10:02] <Hobbsee> Burgundavia: i beleive that's called abuse.
[10:02] <Burgundavia> yes, I render you speechless
[10:02] <Burgundavia> it is my stunning wit
[10:02] <Hobbsee> :P
[10:02] <vil> I did not change the changelog but debuild -e did
[10:02] <Hobbsee> it's hte fact that i'm freezing, so cant type
[10:02] <jussi0l> gah.. its telling me it cant find ./configure
[10:03] <Hobbsee> Burgundavia: i believe that's against hte COC, anyway :P
[10:03] <Hobbsee> although, you'd have the power to try to change it now
[10:03] <RAOF> jussi0l: Got autotools installed?
[10:03] <Burgundavia> likely, but I can just vote not to censure me :)
[10:03] <Hobbsee> hehe
[10:04] <Hobbsee> Burgundavia: besides, you'd have to find me.
[10:04] <jussi0l> RAOF, maybe not... this is a fresh install so unlikely...
[10:04] <Burgundavia> Hobbsee: you live in that country down under. Can't be that big
[10:04] <Hobbsee> heh
[10:04] <Burgundavia> remember, I come from Canada. To us, everybody but Russia is small
[10:05] <Hobbsee> heh
[10:08] <Hobbsee> Burgundavia: let's hope your wit is better than your ability to tell ages, then
[10:10] <RAOF> I suppose I really should check whether or not all the patches to kvm are still needed.
[10:15] <Burgundavia> Hobbsee: right
[10:15] <bluekuja> vil: pong
[10:26] <dholbach> when is the next REVU DAY going to be?
[10:27] <Hobbsee> dholbach: today!
[10:27] <crimsun> why not on Thursday?
[10:27] <crimsun> we already have Q&A on Thursday, so having REVU the same day wouldn't be too far a stretch
[10:27] <Hobbsee> revu seems slightly broken at the moment, which makes it hard
[10:27] <dholbach> sounds good
[10:27] <dholbach> it'S really slow for me :/
[10:28] <dholbach> maybe we should try the bzr based approach soon - see how it works
[10:30] <crimsun> MOTUMenuHeader updated
[10:30] <dholbach> ROCK
[10:48] <vil> bluekuja, sorry for stealing your patches
[10:50] <raphink> hi 
[10:50] <raphink> :)
[10:50] <raphink> does anyone know the debuild switch to build both binary and source and include them in the .changes?
[10:51] <shawarma> raphink: That's the default.
[10:51] <raphink> pbuilder will only include the binaries in the .changes but still lists "source" as a built architecture
[10:51] <raphink> that's what I thought shawarma, but there must be a way to force it since pbuilder doesn't do it
[10:51] <bluekuja> vil, don't worry. I hope it wont happen again
[10:52] <shawarma> raphink: pbuilder calls debuild?
[10:52] <raphink> I think so shawarma
[10:53] <raphink> well no
[10:53] <raphink> it calls dpkg-build-package
[10:53] <raphink> it calls dpkg-buildpackage
[10:53] <shawarma> Ah, that makes more sense.
[10:55] <shawarma> raphink: You have DEBBUILDOPTS set in pbuilderrc?
[10:56] <raphink> no
[10:56] <raphink> that's what I'm asking
[10:56] <raphink> if you know the switch to pass it 
[10:56] <raphink> so that it includes the source 
[10:57] <raphink> ah wait
[10:57] <raphink> DEBBUILDOPTS is set to nothing
[10:57] <raphink> so maybe I should set it to -b
[10:58] <raphink> let's try like that :)
[11:03] <shawarma> win 77
[11:03] <DarkSun88> Hi all
[11:04] <Hobbsee> hiya
[11:12] <jussi0l> hmmm, what does XFree86-Mesa = in ubuntu ?
[11:15] <crimsun> not sure what you're asking
[11:15] <crimsun> libgl1-mesa-dev is the build-dep binary package used for most source packages; the source package name is mesa.
[11:15] <jussi0l> crimsun, thanks
[11:16] <jussi0l> exactly what im after i think...
[11:16] <crimsun> what are you trying to compile?
[11:16] <jussi0l> cedega...still
[11:17] <DarkMageZ> cedega is still a waste of time
[11:17] <crimsun> I'm pretty sure `apt-get build-dep wine` should cover all that.
[11:17] <jussi0l> gah... i have that already...hmmm wonder what the problem is...
[11:17] <jussi0l> hah, didnt know i could do that ...
[11:17] <jussi0l> :D
[11:18] <jussi0l> thank you crimsun 
[11:18] <crimsun> np
[11:19] <jussi0l> DarkMageZ, can you recomend something that will make need for speed run on linux then?
[11:20] <DarkMageZ> which need for speed?
[11:26] <jussi0l> underground 2
[11:27] <DarkMageZ> it's probably playable then
[11:27] <jussi0l> only works on cedega afaik tried on wine and it didnt work...
[12:04] <bluekuja> heya guys
[12:04] <bluekuja> a question
[12:04] <bluekuja> if I'm the debian maintainer for a package
[12:04] <jussi0l> crimsun, still up?
[12:04] <bluekuja> when importing it to ubuntu (syncs gonna be closed on 20 june)
[12:05] <bluekuja> should I change maintainer to MOTU
[12:05] <bluekuja> or I can leave myself ?
[12:05] <Hobbsee> you can leave it as yourself, if it's a direct sync
[12:05] <Hobbsee> as in, no ubuntu1 version number on it
[12:05] <Hobbsee> and you can manually rqeuest syncs after that, too
[12:05] <jussi0l> hmmm anyway... if someone can be bothered with my cedega problem... http://paste.ubuntu-nl.org/25215/
[12:05] <bluekuja> Hobbsee, if I want to version it with ubuntu, should I change the maintaine field?
[12:05] <Hobbsee> bluekuja: yes.
[12:05] <bluekuja> Hobbsee, thanks
[12:05] <Hobbsee> bluekuja: but are teh packages in ubuntu and debian supposed to be the same?
[12:05] <bluekuja> Hobbsee, yeah
[12:05] <jussi0l> Hobbsee, to the rescue again :P
[12:05] <Hobbsee> bluekuja: then why not upload it to debian, and sync it straight across?
[12:05] <Hobbsee> and not bother with 2 separate uploads?
[12:05] <bluekuja> Hobbsee, new queue is huge now
[12:05] <Hobbsee> then the autosyncer does it's magic, when i'ts running, too
[12:05] <bluekuja> and it wont be in debian for the 20 june
[12:05] <Hobbsee> bluekuja: they'll get it down.  you wont be abel to bypass the NEW queue by uploading it with an ubuntu version either
[12:05] <Hobbsee> oh wait
[12:05] <Hobbsee> maybe you would
[12:06] <Hobbsee> bluekuja: is this new to debian, or a new version?
[12:06] <man-di> bluekuja: current NEW queue is not too lone
[12:06] <bluekuja> one of them is new
[12:06] <bluekuja> man-di, I'm talking about debian new
[12:06] <man-di> bluekuja: thats processed all in a day or two
[12:06] <man-di> bluekuja: /me too
[12:06] <Hobbsee> bluekuja: sorry, is it currently in ubuntu at all?
[12:06] <bluekuja> Hobbsee, nope
[12:06] <bluekuja> man-di, is there from about 1 week
[12:06] <Hobbsee> bluekuja: then it's faster to put it into debian, and request a sync.
[12:07] <man-di> bluekuja: I know the guy who processes it
[12:07] <Hobbsee> bluekuja: also, you'll have up to new package freeze for that sync to be processed
[12:07] <Hobbsee> bluekuja: and they'll look at the filed date of the sync, when they action it
[12:07] <man-di> bluekuja: he is currently at Debcamp, I'm sure it will be processed soon
[12:07] <bluekuja> man-di, oh ok great :)
[12:07] <bluekuja> Hobbsee, thanks for the hint
[12:07] <Hobbsee> blue
[12:08] <Hobbsee> bluekuja: it'll still get stuck in the NEW queue for longer, if it's a new to ubuntu package, nto in debian.
[12:08] <Hobbsee> because if it's in debian first, then ubuntu knows the debian ftpmasters have already checked a lot of stuff
[12:08] <Hobbsee> no problem
[12:08] <Hobbsee> like, licencing and such
[12:08] <bluekuja> ah yeah
[12:08] <bluekuja> so It should be better to wait debian first
[12:09] <bluekuja> and then sync
[12:09] <Hobbsee> yes
[12:09] <bluekuja> ok
[12:09] <bluekuja> sounds great
[12:09] <bluekuja> :)
[12:09] <Hobbsee> :)
[12:09] <bluekuja> tnx Hobbsee :)
[12:09] <Hobbsee> no problem
[12:17] <icf7> Anyone in here who'd like to review http://revu.tauware.de/details.py?upid=5467 (Sunflow rendering system)? Thank you!
[12:21] <tarzeau> icf7: hey you know pixie?
[12:21] <tarzeau> http://www.cs.utexas.edu/~okan/Pixie/pixie.htm
[12:22] <icf7> tarzeau: No, looks interesting
[12:22] <tarzeau> i made a debian package already
[12:22] <tarzeau> gnu.ethz.ch/debian/pixie/ 
[12:23] <tarzeau> http://sunflow.sourceforge.net/gallery/v0070/cloth_b-anim.mov <- very nice
[12:23] <tarzeau> icf7: do you do 3d modeling?
[12:23] <tarzeau> icf7: know www.sauerbraten.org ? blender? wings3d ? misfit model 3d?
[12:24] <icf7> tarzeau: No, I don't, my brother does
[12:25] <tarzeau> are his models online?
[12:25] <icf7> tarzeau: I normally write 2D web applications, just saw Sunflow was missing packages
[12:26] <tarzeau> i see
[12:26] <icf7> tarzeau: I don't really know, I think not
[12:42] <Sindwiller> Ittadakimasu
[01:02] <shawarma> I forget: What are the requirements for uploading to revu? I've uploaded before, but I'm using a new e-mail address this time. Should that matter?
[01:03] <icf7> shawarma: You should have a working pgp key associated to you address
[01:03] <shawarma> Ah, it appears you also need patience.
[01:03] <shawarma> It's there now.
[01:04] <shawarma> A second pair of eyes on http://revu.tauware.de/details.py?upid=5483 would be much appreciated.
[01:05] <shawarma> It's still two MOTU ACKs or one core-dev ACK ?
[01:05] <Hobbsee> it's still two acks
[01:05] <Hobbsee> shawarma: are you a MOTU?
[01:05] <shawarma> Sure
[01:05] <Hobbsee> (or in core?)
[01:05] <Hobbsee> right, then you're one
[01:05] <shawarma> Not core.
[01:06] <shawarma> Ah, so just one more ack?
[01:06] <shawarma> Great.
[01:06] <Hobbsee> doesnt matter.  you're still in ~ubuntu-dev so that counts
[01:07] <shawarma> Right, right. that was implied in my question: "It's still two (additional) ACKs (apart from my own of course) or one core-dev ACK ?"
[01:07] <shawarma> :)
[01:07] <Hobbsee> looking over it
[01:07] <shawarma> But ok, just two ACKs in total.
[01:07] <Hobbsee> no, it's 2 acks in total
[01:07] <shawarma> Hobbsee: Thanks!
[01:07] <Hobbsee> or last i knew
[01:08] <Hobbsee> shawarma: ooh, python stuff too hey?
[01:09] <Hobbsee> shawarma: FAIL!!!
[01:09] <StevenK> Heh heh
[01:09] <Hobbsee> :P
[01:09] <Hobbsee> shawarma: s/unstable/gutsy, for one.  release number looks wrong, too
[01:09] <shawarma> arh, shit.
[01:10] <Hobbsee> shawarma: perhaps 1.2.35-1.1-0ubuntu1 or whatever?  i havent checked teh big link
[01:10] <shawarma> Hobbsee: Um, why?
[01:10] <Hobbsee> shawarma: link to the homepage in the long description is also good.
[01:10] <StevenK> Yes, I agree. Why?
[01:10] <shawarma> It has none.
[01:10] <StevenK> (Versioning)
[01:10] <shawarma> None that I know of.
[01:11] <Hobbsee> oh, i thought the RPM link was actually a sublink off the main page
[01:11] <Hobbsee> sorry
[01:11] <shawarma> There's a reason why I had to yank it out of a src rpm. /me shudders
[01:11] <shawarma> Hobbsee: No, fedora archive. Man, what a mess.
[01:11] <Hobbsee> ahhhh
[01:12] <Hobbsee> oh right, i see.  adn teh system-config-samba-1.2.35-1.1.src.rpm bit is a fedora thing, too
[01:12] <shawarma> Yes.
[01:12] <shawarma> Alright, that's it. I'm going to do nasty things to linda now.
[01:12] <Hobbsee> haha
[01:13] <StevenK> Keep talking, I'm reloading.
[01:13] <Hobbsee> shawarma: you're aware that the author of linda's in the room, are you not?
[01:13] <shawarma> Hobbsee: Indeed.
[01:13] <Hobbsee> :)
[01:14] <shawarma> So, if DEBEMAIL contains "@ubuntu.com" the latest distro in changelog must be an Ubuntu one. Agreed?
[01:14] <StevenK> Let's just say, he will be aware. :-P
[01:14] <Hobbsee> shawarma: pretty much
[01:15] <Hobbsee> shawarma: although, some people use @ubuntu.com address to upload to debian, occasionally
[01:15] <Hobbsee> it's more "if you want to upload an ubuntu version, you need to upload it to an ubuntu distro"
[01:15] <shawarma> Hobbsee: That's even better, yes.
[01:16] <shawarma> StevenK: Uh.. linda doesn't check the distribution at all right now?
[01:24] <shawarma> So apart from the distribution, it looks good?
[01:24] <shawarma> Hobbsee: Or are you not done?
[01:25] <Hobbsee> yeah, it looked fine to me - but my python isnt so great
[01:25] <shawarma> Alright. Thanks for looking at it.
[01:36] <shawarma> StevenK: Were you looking it over, too?
[01:37] <zakame> hmm is sudo borked?
[01:37] <zakame> I just created a gutsy chroot earlier and sudo isn't behaving as expected
[01:37] <Hobbsee> shawarma: he's TV watching
[01:42] <shawarma> Hobbsee: Gah...
[01:43] <zakame> meh, never mind, missing right /etc/group entries...
[02:05] <xxxxx1> morning people!
[02:06] <Hobbsee> morning xxxxx1 
[02:35] <Nightrose> I wanted to upload my first package to REVU but it got rejected because I have got no upload rights - I suspect my key is not synced yet - can someone please have a look at that?
[02:35] <bluekuja> Nightrose, joined universe contributors team in lp?
[02:36] <Nightrose> yes bluekuja
[02:36] <bluekuja> Nightrose, if you did everything right, just ask to a REVU admin to sync the keyring
[02:36] <bluekuja> siretart: you can do it? :)
[02:36] <Nightrose> ok thx
[02:40] <siretart> bluekuja: updating now
[02:41] <bluekuja> siretart, thanks :)
[02:41] <bluekuja> Nightrose, wait siretart's update and try uploading again
[02:41] <Nightrose> thx bluekuja and siretart
[02:41] <bluekuja> ;)
[02:57] <xxxxx1> hello Ursinha 
[02:57] <Ursinha> hello xxxxx1 
[02:57] <zakame> hi all
[02:58] <Ursinha> hi zakame 
[02:58] <zakame> heya Ursinha
[03:06] <dholbach> can a revu admin get rid of a gdm upload that stalled somehow?
[03:06] <dholbach> that'd be nice
[03:07] <Hobbsee> dholbach: sure
[03:08] <Hobbsee> dholbach: done
[03:08] <Hobbsee> hiya persia 
[03:08] <dholbach> thanks a lot Hobbsee
[03:08] <persia> Hey Hobbsee
[03:08] <zakame> hmmm, mailping's in a knit, our version is 0.0.4ubuntu3, but debian's at 0.0.4-0.2, causing grab-merge to calculate a new version of 0.0.4-0.2ubuntu1...
[03:09] <zakame> should I bump to that, or to version 0.0.4ubuntu4 instead?
[03:09] <Hobbsee> zakame: just ignore it.  syslog-summary does the same
[03:09] <zakame> Hobbsee: meaning? go to 0.0.4ubuntu4?
[03:10] <persia> dholbach: Sorry it's taken so long.  I've finished reading, and comments are being put up at MOTU/WikiCleanUp/SomeReviewNotes
[03:10] <dholbach> persia: WOW
[03:10] <dholbach> persia: I'll read it in a bit
[03:10] <persia> zakame: I'd recommend 0.0.4ubuntu4, as otherwise dpkg --compare-versions will probably complaing
[03:10] <Hobbsee> zakame: has someone already merged the previous changes?
[03:11] <persia> dholbach: I've a couple hundred more to transfer, but I hope it will be a useful place to start from.
[03:11] <Hobbsee> wouldnt surprise me if 4ubuntu3 is already the merged version, though
[03:11] <zakame> persia: yeah, I supposed that
[03:11] <Q-FUNK> hm. don't packages without any ubuntu delta get sync'ed from debian automatically, anymore?
[03:12] <Hobbsee> they do still, iirc
[03:12] <zakame> Hobbsee: no, the newest debian version didn't merge, it was a BSP release
[03:12] <Hobbsee> zakame: BSP?
[03:12] <Hobbsee> Q-FUNK: depends when the freeze is
[03:12] <zakame> Hobbsee: bug squashing party
[03:12] <Hobbsee> zakame: ahhh.  yes
[03:13] <zakame> persia: what complicated this was it was a native package being updated with an NMU
[03:13] <zakame> anyway, thanks :D
[03:13] <persia> zakame: Exactly.  I've enough now, but one of my future agenda items is to address that :)
[03:13] <zakame> hehe
[03:13] <Q-FUNK> Hobbsee: we're not yet in a freeze are we?
[03:13] <StevenK> Nope, no freeze
[03:14] <zakame> no, not, see ReleaseSchedule
[03:14] <dholbach> persia: wow
[03:14] <dholbach> persia: I'm amazed - really great work
[03:14] <Q-FUNK> I thought so.  i wonder why all my packages have been synced except for cups-pdf, then.
[03:15] <persia> dholbach: I'm not likely to actually contribute much towards the rewrite, but I'm hoping to put enough information together that it's easy for those that do.
[03:15] <dholbach> persia: you contribute quite a lot to it :)
[03:15] <Nightrose> bluekuja: my package still gets rejected saying "Signer has no upload rights at all to this distribution." - should I wait longer or is something borked?
[03:16] <bluekuja> Nightrose, did you setup dput properly?
[03:16] <bluekuja> or are you uploading to upload.ubuntu.com? :)
[03:16] <Nightrose> hmm will have a look ;-)
[03:16] <Nightrose> thx
[03:16] <bluekuja> Nightrose, please add REVU at your dput.cf
[03:17] <bluekuja> Nightrose, and then dput name-choosen-in-dput.cd .changes file
[03:17] <bluekuja> *cf
[03:17] <bluekuja> Nightrose, if you have any more question, feel free to ask
[03:17] <mok0> I want to upload extra fixes to REVU, but get the message: Already uploaded to revu.tauware.de
[03:17] <Nightrose> thx bluekuja
[03:17] <bluekuja> Nightrose, ;)
[03:18] <bluekuja> mok0, delete .upload file
[03:18] <persia> Those seeking sponsorship: please review the guidelines available from MOTU/Sponsorship/SponsorsQueue (or the more verbose equivalent in MOTU/Contributing): merge bugs should be confirmed when U-U-S is subscribed.
[03:18] <zakame> persia++
[03:19] <mok0> thx it worked
[03:19] <mok0> but it complained over the orig.tar.gz file not being required
[03:19] <bluekuja> mok0, ;)
[03:20] <bluekuja> mok0, yeah, if already uploaded 
[03:20] <bluekuja> is ok
[03:20] <mok0> so I don't need the -sa switch on debuild anymore?
[03:22] <bluekuja> mok0, yeah, you need it
[03:22] <bluekuja> mok0, just ignore that dput message
[03:23] <bluekuja> mok0, you can drop or use it, nothing change for dput
[03:23] <bluekuja> you just receive that message, that you can easily ignore ;)
[03:24] <Nightrose> so here is my first package ;-) http://revu.tauware.de/details.py?upid=5487 please have a look
[03:26] <mok0> ok thx
[03:27] <bluekuja> mok0, good luck
[03:27] <mok0> persia: can we discuss the xinetd stuff now?
[03:28] <persia> mok0: I'm in the middle of something, but I should be ready in about two minutes.
[03:28] <mok0> Ill get some mocca
[03:32] <xxxxx1> mok0: your comment number "8" is debian related, not ubuntu.
[03:32] <xxxxx1> ubuntu xinetd provides inet-superserver, but debian not.
[03:32] <persia> mok0: OK.  My memory was that you wanted to put an entry in the local inetd, and have it work for either inet-supoerserver, or xinetd, right?
[03:33] <mok0> ok, but there is still the problem of the configuration of the two servers
[03:33] <persia> xxxxx1: Cool!  Thanks for pointing this out :)
[03:33] <mok0> persia: yes
[03:33] <xxxxx1> persia: ;)
[03:33] <mok0> lag :)
[03:33] <persia> mok0: If it provides inet-superserver, it should accept input from update-inetd (with appropriate config adjustments), as I understand it.
[03:33] <lionel> persia: when a merge is confirmed when subscribing U-U-S, that means you have to confirm your own bug? iirc this is unwanted (to confirm your own bugs)
[03:34] <mok0> /etc/xinetd.conf looks very different from inetd.conf
[03:34] <mok0> There are scripts to convert inetd -> xinetd but not the other way around
[03:34] <persia> lionel: Yes.  The general rule "Don't confirm your own bugs" does not apply when requesting work from others (Contributor asking for upload, Developer asking for SYNC, etc.).
[03:35] <lionel> Okay, okay
[03:35] <persia> lionel: The idea being that the receiving team wants to know that the necessary checks have been completed, rather than being a random bug typed in by someone not so familiar with the processes.
[03:36] <lionel> persia: btw, don't you think it would be fine to get the mail "job done" on U-U-S mailing-list for sync and merge
[03:36] <RainCT> Hi
[03:36] <persia> Ah another example: one writing a patch asking for packaging.
[03:36] <lionel> I find the mail useless if it's not the case
[03:36] <lionel> you always have to refer to the bug list on LP to know if something is needed to be done
[03:37] <persia> lionel: I don't subscribe to the mail - the LP queue is more useful to me (I subscribe to the bugs I process - this makes it easier to follow up).
[03:38] <lionel> I tend to first read my mails before going to LP, but that's a matter of taste I believe
[03:38] <persia> lionel: I have the same workflow, but I don't subscribe to the U-U-S list, as I don't find any of that mail useful.
[03:39] <Hobbsee> lionel: what's your suggestion for the ML, sorry?
[03:39] <lionel> Hobbsee: only to get mail for sync acked or merge uploaded on the ML
[03:39] <Hobbsee> i beleive it already does?
[03:39] <lionel> if we unsubscribe U-U-S just after doing the job, the ML does not get the notification
[03:40] <lionel> Hobbsee: if we follow persia procedure, just after doing the job, you unsubscribe U-U-S
[03:40] <Hobbsee> ahh
[03:40] <lionel> and mail does not reach the ML
[03:40] <Hobbsee> true - but does the entire u-u-s sponsor list *want* to know about everything?
[03:40] <Hobbsee> i guess so, if you're using mail only
[03:41] <Hobbsee> which is kinda dangerous -as LP mail can be delayed
[03:41] <lionel> as I said, I tend to read my mail first and see if something is not done then go to LP
[03:41] <StevenK> And LP mail via a list doubly so delayed.
[03:41] <persia> I don't think mail-only is a good way to sponsor: it's easy to have a conflict because of the 300 second LP mail delay.
[03:41] <StevenK> Agreed.
[03:41] <lionel> but, probabily... yes, you're right :)
[03:41] <StevenK> lionel: You lose. :-P
[03:42] <persia> Is there any coordination or discussion on the UUS ML?
[03:42] <lionel> Ok, ok 
[03:42] <StevenK> Nope.
[03:42] <lionel> No
[03:42] <StevenK> It's all bugmail
[03:42] <lionel> So this mailing-list is useless ? :)
[03:42] <StevenK> lionel: Hobbsee and I have spent hours on that list. Thanks.
[03:43] <persia> StevenK: Creating the list in the first place was an important part of getting the team started - think of the new process as a patch: adding to your previous work rather than ignoring it :)
[03:43] <lionel> StevenK: hey, sorry, just asking question, I'm new :)
[03:45] <Fujitsu> persia: Not if you were persistent enough with poking people. I was :P
[03:45] <lionel> yeah, creating u-u-s is a great idea and work very nicely
[03:46] <lionel> (I would no be there if it has not works great)
[03:46] <persia> Fujitsu: Yeah, well, in the beginning, new candidates were uploaded quickly.  Sometime just prior to Dapper release, the firehose started ramping up, and I was not very active during Edgy, so my revisions languished.
[03:47] <man-di> lionel: Debian has removed apache 1.x from unstable. Can I safely remove libapache-mod-jk for apache 1.x for Ubuntu too?
[03:48] <persia> man-di: Not quite.  If Debian removes something, you need to track down all the reverse-depends, and make sure that those that are to be kept are modified to not be reverse depends.  Then, file a bug requesting the remaining packages be dropped from Ubuntu with an explanation of why (removed from Debian is a good starting point), and send for sponsorship (unconfirmed).
[03:49] <lionel> hum... If debian removed apache 1.x, I think we will remove it also
[03:50] <lionel> that that's a transition, not so small...
[03:50] <lionel> we should coordonate it
[03:50] <man-di> I just meant removing on binary package remove from a source package which builds several binary packages
[03:51] <man-di> persia: this needs no removal request. I guess
[03:51] <man-di> lionel: definitely
[03:51] <Hobbsee> shawarma: did you ever get your debdiff reviewed?
[03:51] <man-di> lionel: if we want to be really insane we can still build it for Ubuntu and not for Debian from the same source deb
[03:51] <geser> man-di: either wait till the bug gets fixed in Debian or move ahead and patch the pkg
[03:51] <shawarma> Hobbsee: Which one was that?
[03:52] <Hobbsee> shawarma: the one you asked about earlier
[03:52] <man-di> geser: I'm the debian maintainer of it
[03:52] <shawarma> Hobbsee: The system-config-samba package?
[03:52] <shawarma> Hobbsee: or did I also ask about a debdiff?
[03:52] <Hobbsee> shawarma: that's the one
[03:52] <man-di> geser: I just wanna coordinate this with lionel as he keeps an eye on the Ubuntu side
[03:52] <persia> man-di: Sorry - I was hoping you'd chase the whole transition.  Dropping it from your package is a good start.
[03:52] <Hobbsee> sorry, it was a new package.  my error.
[03:52] <shawarma> Hobbsee: No, but I put it in pitti's review queue. He'll get to it sometime. :)
[03:52] <Hobbsee> this bash has been doing my head in.
[03:52] <Hobbsee> ahhh
[03:53] <Hobbsee> StevenK's around now, if he's up to reviewing something, IDK
[03:53] <shawarma> IDK?
[03:53] <man-di> persia: first my packages I need to care about anyway, then the rest
[03:53] <Hobbsee> i dont know
[03:53] <shawarma> StevenK: poke?
[03:53] <lionel> man-di: I think we are going to sync this package and not merge any more quite soon
[03:53] <shawarma> Hobbsee: Oh, right.
[03:54] <man-di> lionel: syncing would be best, current version in unstable should be synced already
[03:54] <lionel> man-di: before removing apache module, I would like to know if/when we are going to remove apache in Ubuntu
[03:54] <man-di> lionel: oh no, Ubuntu has not synced yet
[03:54] <shawarma> lionel: apache 1.3?
[03:54] <lionel> shawarma: yes
[03:54] <man-di> lionel: understandable
[03:54] <shawarma> lionel: I don't think apache1.3 will be in gutsy.
[03:55] <man-di> shawarma: is this deciced already?
[03:55] <lionel> shawarma: same for me, but before droping packages, we have to be sure :)
[03:55] <lionel> shawarma: but now you're mister Ubuntu Server, aren't you? :)
[03:55] <StevenK> shawarma: Hum?
[03:55] <geser> man-di: it takes some time till removals move from Debian to Ubuntu
[03:56] <shawarma> man-di, lionel: Well, not as such, but it's completely amputated anyway. We don't build php4 at all anymore, and the php5 package doesn't build apache 1.3 modules, etc..
[03:56] <man-di> lionel: that is exactly why I asked. Bad DDs would have just removed it
[03:56] <shawarma> StevenK: Could you be pursuaded to take a look at http://revu.tauware.de/details.py?upid=5484 ?
[03:56] <geser> but you can speed it up with a removal request based on that it got removed from Debian
[03:56] <StevenK> shawarma: Nope. :-)
[03:57] <Hobbsee> StevenK: remember...he'll do nasty things to your machine if he says no
[03:57] <persia> geser: Is there an automated process?  I've found packages that were distributed for over a year after being dropped from Debian.
[03:57] <man-di> geser: do I need a removal request for binary packages? I thought that is for source packages only
[03:57] <shawarma> StevenK: Yeah, what Hobbsee says.
[03:57] <StevenK> persia: It is not
[03:57] <shawarma> StevenK: :)
[03:57] <Hobbsee> StevenK: i thought there was soem form of it.
[03:57] <StevenK> geser: And quote the Debian bug number.
[03:58] <StevenK> There's NBS, which is for binary packages that aren't built any more.
[03:58] <StevenK> I don't think source packages that don't exist in Ubuntu are uncereminously killed, though.
[03:59] <persia> man-di: Removal requests for binary packages are only needed when they are dropped from only some architectures.  Otherwise the scripts catch it, and the archive admins eventually remove them.
[03:59] <StevenK> Er, don't exist in Debian
[03:59] <man-di> persia: so no removal request needed in this case, same as in Debian then
[04:00] <lionel> persia: are you sure? in Universe, I thought we have to do a removal request for binary packages that have NBS
[04:00] <persia> man-di: I think so.  Removal requests are only required for dropped source or architecture-specific dropped binaries.
[04:00] <persia> lionel: Mr. Heen has so advised me that I shouldn't file removal requests for dropped binaries except when it is architecture specific.  It might take a while, but they get to it eventually.
[04:01] <geser> persia: if I find packages removed from Debian I mostly file remove requests. I don't know if it happens automagically and how often.
[04:02] <persia> geser: That's been my practice as well (unless I see a reason to keep it in Ubuntu).  I think that the several of us who do that are the reason that it appears semi-automated.
[04:03] <shawarma> StevenK: There's no chance? Hobbsee said it looked alright, we just want someone with stronger python-fu to say it's good to go.
[04:12] <persia> mok0: Just out of curiosity, did update-inetd work for you, or are you still having an issue?
[04:13] <mok0> persia: I am taking a look at some other packages; what they do there...
[04:13] <persia> mok0: OK.  Let us know if you need help with a fancy postinst :)
[04:18] <zakame> anyone playing with atlas-cpp merge? It sure looks like it just needs a sync
[04:19] <man-di> zakame: I will take care of it
[04:19] <mok0> persia: amanda creates _both_ an entry in xinetd.d and in inetd.conf (via inetd-update)
[04:19] <man-di> zakame: I'm debian maintainer of it
[04:19] <mok0> persia: that's easy and it will work 
[04:19] <persia> mok0: That sounds ideal to me.
[04:19] <zakame> man-di: yeah, I know :)
[04:19] <mok0> persia: :-) great
[04:20] <man-di> zakame: there is a bigger update for all this comming up
[04:21] <man-di> zakame: let me figure all out and then sync everything
[04:21] <zakame> ah, cool
[04:22] <zakame> hmm, what else to merge?
[04:26] <Hobbsee> zakame: *
[04:27] <zakame> Hobbsee: *? I'm trying not to be greedy :P
[04:28] <persia> zakame: Be greedy (but check the bugs on LP first)
[04:28] <Hobbsee> zakame: whatever's not done by now is fair game, imo
[04:28] <zakame> persia: hehe, very well
[04:28] <zakame> Hobbsee: game on, then
[04:28] <persia> I disagree - I argue that anything that hasn't been claimed on LP is fair game.
[04:28] <Hobbsee> :)
[04:29] <zakame> noted
[04:30] <persia> zakame: It's in LP (as any other issues like that should be)
[04:36] <mok0> what uid/group names are standard for inetd daemons?
[04:36] <mok0> nobody/nogroup??
[04:36] <shawarma> mok0: Depends on what it'd have to do..
[04:37] <mok0> it needs no privileges
[04:37] <persia> mok0: That works fine, unless the package needs to write to the filesystem.
[04:38] <mok0> It just needs to write to stdout which inetd redirects to a socket.
[04:38] <mok0> I tnink :-)
[04:38] <persia> mok0: Test, Test, Test, and then rebuild and test again :)
[04:39] <mok0> Yeah yeah yeah
[04:39] <mok0> Why do I ask?
[04:39] <mok0> :)
[04:45] <statik> dholbach: thanks for your comments on http://revu.tauware.de/details.py?upid=5473, I really appreciate them. I did not understand the line about debian/pyversions though.
[04:45] <statik> dholbach: I have a debian/pyversions file, do I need to change what it contains?
[04:54] <zakame> erm, another one on carpaltunnel
[04:54] <zakame> we ought to be more careful when bumping versions on NMUs
[04:56] <mok0> Seems like I need to make an entry into /etc/services. Is there a script to do that?
[04:57] <persia> zakame: Perhaps you'd like to draft a spec?  I've some thoughts on https://wiki.ubuntu.com/EmmetHikory, but as I said, I'm not getting to it soon.
[04:58] <zakame> persia: hmmm, lemme think through it :)
[05:01] <dholbach> statik: oh, forget that line, sorry
[05:01] <statik> dholbach: no worries. I just uploaded a new version with all the other changes
[05:02] <dholbach> rock and roll
[05:05] <dholbach> statik: the package does not build for me anymore - seems it was a bad idea to add setup.py in a patch
[05:05] <dholbach> statik: seems the patch target is called after the clean target, which uses setup.py already
[05:05] <persia> mok0: http://www.debian.org/doc/debian-policy/ch-customized-programs.html is probably a good start.  Can you not work around with current /etc/services?
[05:06] <statik> dholbach: oh! I did not anticipate that problem. I should have checked it in my pbuilder before uploading
[05:06] <dholbach> statik: what I probably meant to write regarding pyversions is that I'd rather add a   XS-Python-Version   line to debian/control
[05:06] <dholbach> statik: but that's fine
[05:06] <mok0> It seems like I need a service name to put in inetd.conf
[05:07] <statik> dholbach: I'm happy to do it with XS-Python-Version instead. Shall I do that and revert the change to setup.py?
[05:07] <mok0> I can easily put it in via a script, but what happens if netbase is updated? Then things might break. 
[05:07] <mok0> This is why xinetd is a Good Thing.
[05:07] <dholbach> statik: yeah, try and see if that fixes the build again :)
[05:08] <mok0> inetd is from the old times where sysadm edited all files manually
[05:08] <mok0> We don't have triggers, do we?
[05:10] <RainCT> (any Python guy here that can help me with some basic stuff?)
[05:10] <mok0> RainCT: what do you need
[05:12] <RainCT> mok0: if I've a program with many .py files that are imported into the main one (so they will go to /etc/share/programname/ when installed), how do I've to write the import in order that it gets them?
[05:14] <mok0> pydir = "/whatever/whereever/pydirectory"
[05:14] <mok0> if not pydir in sys.path:
[05:14] <mok0> sys.path.insert(1,pydir)
[05:15] <SlimG> What method is preferred when building a deb package from a makefile? I'm only familiar with building a dir that resembles the root, and run dpkg --build <folder> .   on it
[05:19] <persia> SlimG: There are different schools of thought, but pbuilder, sbuild, and debuild predominate (or else I'm misunderstanding your question)
[05:19] <RainCT> mok0: thanks
[05:19] <SlimG> persia: I think thats is the ansewer to my vague question :) thanks!
[05:20] <tobiasschulz> can someone check http://revu.tauware.de/details.py?upid=5488 ?
[05:20] <persia> SlimG: Personally, I recommend sbuild if you can free up 10-20GiB of HD space, and pbuilder otherwise.
[05:22] <man-di> SlimG: packaging got much more comfortable then "dpkg --build ..." in the last 10 years
[05:22] <zakame> hehe
[05:25] <SlimG> man-di: The reason I'm using dpkg --build is that I understand it, and I havent understood any other methods sofar, to me dpkg --build is easy
[05:25] <SlimG> is debuild the thing I should use instead of dpkg --build?
[05:26] <man-di> SlimG: yes
[05:26] <persia> SlimG: What exactly are you seeking to accomplish?
[05:26] <man-di> debuild is a wrapper around dpkg-buildpackage
[05:26] <man-di> dpkg-buildpackage uses dpkg --build internally...
[05:26] <zakame> debuild makes it easy to build as well as clean
[05:27] <persia> On the other hand, debuild is not always best when one wants to compile something for a target other than the system on which the compile is performed.
[05:28] <SlimG> I'm going to create a deb from a binary package without touching/editing it's files
[05:29] <zakame> cross-compile?
[05:30] <SlimG> it's closed source, I'm not intending it for the ubuntu archives
[05:30] <persia> SlimG: Ah.  Do you have the source?
[05:31] <SlimG> nope, if I had I would share
[05:32] <persia> SlimG: Careful there - you can't always share source that you can read: always check your licenses.  In any case, for your special situation, `dpkg-deb -b` is probably easiest, although it's really not recommended practice.
[05:34] <SlimG> persia: Sorry, to quick reply from me, I meant if I've created the source code myself
[05:35] <SlimG> Isn't it possible for me to create a Makefile with a proper install section + DEBIAN/control file, and then use one of the deb builder apps to do the rest of the magic?
[05:36] <persia> SlimG: If you have the source (even if it's closed), and are working with it on the local system, it's probably better to create a source package (see a packaging guide), and use debuild to make your binary.  If you create control and changelog, and have a good makefile, a one or two line CDBS debian/rules should do it all for you.
[05:36] <persia> !packaging
[05:37] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[05:37] <SlimG> persia: I don't have access to the source, just binary
[05:38] <SlimG> thanks for your help, I think I'll be able to manage my deb creation with all this info
[05:57] <Hobbsee> they told me it could be reverted, though
[05:58] <persia> Hobbsee: I've just been taught how to search the deleted wiki :)
[05:58] <Hobbsee> ahhh
[06:02] <persia> superm1: bug 111797 was for the (previous) libflac transition (there's a new one now).
[06:02] <ubotu> Launchpad bug 111797 in rezound "libflac++5c2 to libflac++5 transition" [Undecided,Fix released]  https://launchpad.net/bugs/111797
[06:02] <imbrandon> moins & gnight all
[06:05] <persia> umm..  nevermind.  it didn't actually search the deleted wiki :(
[06:06] <persia> superm1: `grep-dctrl-FDependsxlibs</var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_breezy_main_binary-i386_Packages|grep-dctrl--not-FDependslibx11-6-sPackage` is the only grep-dctrl library checking snippet I can find lying around, but it's probably a good place to start.
[06:06] <leonel> keescook:  I'm still fighting with dapper's  clamav    for  CVE 2006-6481  upstream  included new options in the clamscan  and clamav-milter  as  I understood   for  security bugs  only we can patch  but not add or remove  options  I'm I right ?
[06:06] <ubotu> Clam AntiVirus (ClamAV) 0.88.6 allows remote attackers to cause a denial of service (stack overflow and application crash) by wrapping many layers of multipart/mixed content around a document, a different vulnerability than CVE-2006-5874 and CVE-2006-6406. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6481)
[06:16] <SlimG> Could anyone help me to find the source of my character trouble? http://files.iggu.org/testmanual is a manpage that contains the english alphabet + 3 special norwegian characters (,  and ), these three characters displays fine with "cat" but "nroff" has problem displaying them correctly and Lintian gives me a warning, why's this?
[06:17] <SlimG> testmanual is (or should be) UTF8 encoded
[06:19] <SlimG> I've struggled with this issue for a long time, it would mean very much to me if someone wants to help me finding the source of the problem
[06:27] <nixternal> MOTU: take a look at SRU bug 120056 please
[06:27] <ubotu> Launchpad bug 120056 in mga-vid "[SRU]  mga-vid-source does not build due to linux/config.h being dropped from >=2.6.19 kernel" [Undecided,Unconfirmed]  https://launchpad.net/bugs/120056
[06:27] <persia> nixternal: Please indicate why, and also, just subscribe u-u-s when requesting sponsorship :)
[06:28] <nixternal> the bug report says why :)
[06:29] <keescook> leonel: the goal is to only have minimal changes, yeah.
[06:29] <persia> nixternal: You probably want feisty-proposed, and a ubuntu0.1 verision number, just to start.
[06:29] <nixternal> in the changelog?
[06:29] <nixternal> for feisty-proposed that is
[06:30] <leonel> keescook: so  for 6481 does not  apply to dapper's ?
[06:30] <leonel> keescook: I mean  for dapper that wont be patched ?
[06:31] <persia> nixternal: Yep.  Once you've fixed that, use the normal sponsorship request process to get it uploaded.
[06:35] <nixternal> OK, fixed
[06:35] <keescook> leonel: we can patch it as much as we can.  adding new options seems like a bad idea, though.  better to try to solve the CVE in some other way
[06:35] <nixternal> what is the "normal sponsorship request process" ? I always requested it here :)
[06:35] <persia> nixternal: Great.  Now it's in queue, and someone will upload it soon :)
[06:35] <nixternal> damn that was quick
[06:35] <nixternal> you rock persia...don't know if I ever told you that :)
[06:35] <leonel> keescook: debian added  those options
[06:35] <beuno> quick question, why would I be getting this:  dpkg-buildpackage: unable to determine source package is
[06:35] <persia> nixternal: https://wiki.ubuntu.com/SponsorshipProcess
[06:35] <persia> nixternal: The page needs a little work, but the idea is to subscribe UUS or UMS to request actions that only a developer may do (upload, archive request, etc.).
[06:35] <keescook> leonel: if debian has a clean patch for it, then that should be okay.  the theory being that it has been tested and works for them.
[06:35] <nixternal> OK, so I have already done that :)  Ya, I know to always add u-u-s accordingly..didn't know if there was more tot he process
[06:36] <persia> nixternal: There's at least the whole other side of it :)
[06:39] <persia> man-di: eclipse FTBFS.  Would you mind taking a look?
[06:50] <hendrixski> quick question:  the friendly people at nexenta OS (which is Ubuntu on an OpenSolaris kernel)... how much overlap do their packages have with ours?
[06:51] <Hobbsee> hendrixski: absolutely no idea - maybe ask them?
[06:53] <hendrixski> Hobbsee, I stopped by their channel earlier today...'cause I'm interested in what the future of interchangeable kernels would look like... and they're really quiet 
[06:53] <Hobbsee> ahhh
[06:54] <Hobbsee> i dont know of anything from ubuntu, but that doesnt maen there's nothing going on :)
[06:54] <persia> hendrixski: You might try their mailing list, if they're not so active on IRC.
[06:55] <hendrixski> Hobbsee, k... so, we probably don't share packagers and developers with them ... at least not on this channel?
[06:55] <hendrixski> persia, good idea
[06:55] <Hobbsee> hendrixski: well, *i* dont know of any - but i dont live here :)
[06:55] <Hobbsee> and i'm merely one person
[06:56] <hendrixski> Hobbsee, lol.  so like pitching a tent and just camping out here?
[06:56] <hendrixski> :-)
[07:00] <Hobbsee> hendrixski: hehe
[07:00] <Hobbsee> hendrixski: sounds good
[07:00] <Hobbsee> or ask in the ubuntu-motu mailing list
[07:03] <hendrixski> I'll poke around there lists first.... as soon as I figure out why pbuilder is being mean to me
[08:23] <tobiasschulz> may somebody check the last upload of that package? http://revu.tauware.de/details.py?upid=5474
[08:31] <joejaxx> it has been quiet today
[08:31] <ScottK-laptop> tobiasschulz: I'm looking at it.
[08:37] <mok0> how can I list what a given package provides? (i.e. virtual packages)
[08:38] <xxxxx1> mok0: apt-cache show [pkg] 
[08:38] <mok0> yes, thx
[08:58] <DktrKranz> if a package doesn't have a patch system by default, is it legal adding a new one if changes to upstream code are consistent?
[09:01] <geser> sure, but don't introduce one if the changes for the patch system itself are larger than the patch
[09:01] <DktrKranz> I'll try both ways
[09:01] <DktrKranz> thanks
[09:15] <hendrixski> umm... is it normal for pbuilder to take an hour to create a .deb?  I'm repackaging mythtv plugins to get experience with editing code in multiple .deb setups... and it feels like getting the dependencies took in every package known to man ... plus a few not yet discovered
[09:16] <geser> hendrixski: it depends
[09:16] <geser> pbuilder first fetches the needed debs, so this depends on your internet connection
[09:17] <hendrixski> geser, full road runner... I'm just amazed at how many debs it was fetching
[09:18] <geser> and then it depends on the package, there are packages which build in a couple minutes and then there are packages which need an hour
[09:18] <geser> and this depends on how fast your machine is
[09:19] <hendrixski> geser, ah Ok... so it's not completely abnormal that this could be taking me an hour   ... Ok
[09:19] <geser> hendrixski: it caches the downloaded debs, so this part will be faster if you build again
[09:19] <hendrixski> geser, awesome!!!
[09:20] <hendrixski> that's pretty good news actually ... here I was getting all worried and stuff that I was doing something terrible to my system
[09:22] <geser> pbuilder stores them in /var/cache/pbuilder/aptcache/
[09:26] <shawarma> I'd like someone with experience in packaging python things to take a peek at http://revu.tauware.de/details.py?upid=5484
[09:38] <MichaelSpeer> Some time ago I was looking at launchpad.net and saw an error in the emacs-extra package that looked easy to hunt down.  I did so and submitted a patch in the comments at that time.  I saw the error still exists today, tracked it down to its real package ( php-mode ) and found it is not registered there.  Any ideas on my next move.  I don't know where to find a maintainer ( if one exists ).
[09:43] <mok0> how can I list which packages _require_ a certain other (virtual) package?
[09:44] <lamont> it's unfair that a no-change rebuild-upload is ftbfs.
[09:47] <geser> MichaelSpeer: LP works on source packages. The source package for php-mode is emacs-extra: https://launchpad.net/ubuntu/+source/emacs-extra/+bugs
[09:48] <lifeless> lamont: lol :)
[09:48] <lamont> lifeless: stupid dash
[09:48] <lamont> I guess I'll actually test the build before I upload this time.
[09:48] <lifeless> welcome to compatible
[09:51] <geser> mok0: have you tried grep-dctrl?
[09:52] <fdoving> mok0: does 'apt-cache rdepends <package> ' do what you want? 
[09:58] <MichaelSpeer> geser : That is where I had submitted the bug.  I am reassigning the bug to 'ubuntu-universe-sponsers'.  That should notify them correctly, no?
[09:58] <mok0> geser: I didn't know grep-dctrl, will look into it, thx!
[10:01] <geser> MichaelSpeer: ubuntu-universe-sponsors sponsors only complete debdiffs (diff between two source packages)
[10:01] <geser> if you manage to also create a debdifff for your patch, it will get sponsored
[10:02] <mok0> fdoving: apt-cache rdepends works for me! :) 
[10:05] <mok0> Jeez I am finding loads of bugs in the various inetd packages...
[10:06] <mok0> lamont: I am testing out various inetd daemons but they don't install/uninstall cleanly
[10:06] <lamont> mok0: "but why would you ever uninstall my beautiful inetd package???"
[10:06] <mok0> lamont: why don't you have scrollback?
[10:07] <lamont> machine was down.
[10:07] <mok0> Hehe
[10:07] <lamont> so I could go hit the archive, but I'm lazy
[10:08] <mok0> lamont: if you ask me, they should all be banished from the distribution in favour of xinetd
[10:09] <mok0> Anyway, none of them remove the links from /etc/rc*.d when uninstalled which I would call a BUG
[10:10] <jekil> someone can review please? http://revu.tauware.de/details.py?upid=5450
[10:11] <mok0> jekil: sorry not a MOTU 
[10:12] <mok0> Actually, I don't who _is_ a MOTU around here. We're probably all hangarounds :-)
[10:12] <mok0> a.k.a. prospects
[10:13] <fdoving> mok0: removing =! purging, try purging the packages, see if all files vanish then.
[10:13] <mok0> fdoving: ok
[10:15] <mok0> fdoving: what maintainer script is run during purging?
[10:16] <fdoving> mok0: prerm and postrm. there are no .prepurge or .postpurge
[10:17] <mok0> But one thing is leaving config files around -- like for example the apache config file -- another thing is leaving those rc*.d links. 
[10:17] <lamont> DH_OPTIONS='' dh_gencontrol -p$$p -u-v$(TADS2_DEB_VERSION)
[10:17] <lamont> how very, uh, very.
[10:17] <geser> mok0: http://women.debian.org/wiki/English/MaintainerScripts
[10:17] <mok0> When you reboot, the system will still try to start those services long after they're gone
[10:18] <mok0> The links should go when you remove the binary.
[10:18] <beuno> anyone here running sid and gnome to help me debug a package?  it builds fine but I'm having a wierd problem with the menu entry
[10:18] <geser> mok0: what gives "dpkg -l theinetdpkg"?
[10:18] <man-di> mok0: dh_installinit is suppoed to add code to remove them on purge
[10:19] <man-di> mok0: dh_installinit adds that code to prerm or postrm (one of both)
[10:19] <fdoving> mok0: no, it won't cause problems, if it does, it's a bug in the init-script somehow. they will check whether the binaries it is planning to use exists or not, if it doesn't it exits silently and continues.
[10:19] <mok0> geser: pn  netkit-inetd    <none>          (no description available)
[10:20] <mok0> xinetd also has "pn"
[10:20] <geser> then file a bug if files from netkit-inetd are still there
[10:20] <geser> dito for xinetd
[10:20] <fdoving> don't include the ones you modified manually, if any.
[10:21] <mok0> Well it's kinda hard to say exactly _what_ I've done :-)
[10:21] <mok0> Abused the package system, I guess
[10:22] <fdoving> you can use 'debsums' to check the checksums of files in a package.
[10:22] <mok0> ok
[10:23] <fdoving> mok0: 'debsums -e netkit-inetd' for example.
[10:23] <fdoving> -e tells it to only check config files.
[10:24] <mok0> fdoving: debsums is cool! I am learning a lot tonight
[10:47] <MichaelSpeer> geser : I've looked further into the motu system.  By FAQ I located the bug in the debian section of the package and uploaded a diff against it.  This is for the emacs-extra package.  If you could psare a glance, can you tell me if I have done exverything in line with the community procedures?
[10:48] <beuno> what command should I use to add a menu entry in gnome that requieres super user priviledges?
[10:49] <superm1_> siretart, ping
[10:51] <Nafallo> gksu
[10:52] <Nafallo> ...and with that, gnight ;-)
[10:53] <geser> MichaelSpeer: you need to prepare a new source package. I haven't looked at the package yet but it should be only a changelog entry that's missing.
[10:53] <kane77> how do I know what is build dependency and what is the other (library and runtime or whatever it is)?
[10:54] <geser> MichaelSpeer: I will prepare a patched package in a few minutes
[10:58] <mok0> build dependencies are those packages needed to compile yours, header files and such
[10:59] <kane77> I used the script to find what it depends on
[10:59] <mok0> run time dependencies are determined automagically by dh_shlibdeps
[10:59] <kane77> oh so I only fill in the build deps?
[10:59] <mok0> yes, but some packages are needed to compile, but not to run after compilation
[11:00] <mok0> Build dependencies are almost always *-dev packages
[11:00] <mok0> Yes
[11:01] <mok0> If you need something more, lintian will complain and tell you
[11:01] <mok0> For example, if you use dpatch for patch management
[11:01] <MichaelSpeer> geser : I am not trying to put any speed on this.  It is a low priority patch that ensures php-mode is selected when php files are opened.  My system is patched and anyone using it has been dealing for what looks like ( in the change log ) about five years.  Ever since the package was initially placed in unstable.
[11:01] <mok0> you have to specify "dpatch" as a builddep
[11:01] <MichaelSpeer> I was just ensuring I had gotten the motu team what they needed.  Mostly so I will know what to do in the future.
[11:04] <geser> MichaelSpeer: there are round 100 MOTUs responsible for 10000 packages with the same amount of bugs. There more you can prepare the better for us. The best is a ready debdiff, which needs only a review and can be directly uploaded.
[11:11] <MichaelSpeer> geser : Thank you for volunteering your time.  I'm sure I depend on many packages that exist only at the whim of yourself and those working with you.  As for a debdiff in this case, unless I read the information incorrectly I do not believe debdiffs apply to the debian folder, so that is why I created the normal diff.
[11:12] <shawarma> MichaelSpeer: Well, when people want to suggest a fix, we always prefer a debdiff. You are probably thinking of using a patch system to patch things in debian/ which we don't want.
[11:12] <crimsun> debdiffs certainly apply to debian/
[11:16] <MichaelSpeer> shawarma : the problem exists due to a .el file in the ./debian/ folder.  Where would I submit changes to this part of the package if not launchpad.net?
[11:19] <shawarma> MichaelSpeer: It's fine to attach a debdiff to the bug report as a patch.
[11:21] <shawarma> MichaelSpeer: Not only "fine", actually. it would be frickin' excellent! :)
[11:28] <xxxxx1> bye all
[11:28] <MichaelSpeer> shawarma : Actually I was referring to your comment that using patch systems to alter items in the ./debian/ folder was inappropriate, and was asking where the appropriate place is.
[11:32] <MichaelSpeer> shararma : please ignore my last comment, I had missed crimsons comment.
[11:32] <MichaelSpeer> crimson : Thank you for clearing that up.
[11:52] <mok0> I have now uploaded my final (???) version of wulfware to REVU, but it didn't create a debdiff??