[12:16] <tsmithe> crimsun, are you available to do revuage for my alsa packages?
[12:19] <Adri2000> thanks crimsun for uploading obconf
[12:20] <LaserJock> uggg, 184 MOTU Science bugs :(
[12:20] <Adri2000> do *all* python apps need a rebuild?
[12:20] <LaserJock> probably  not
[12:20] <Adri2000> !info giplet
[12:20] <ubotu> giplet: GNOME IP display applet. In component universe, is optional. Version 0.1.2-0ubuntu1 (edgy), package size 8 kB, installed size 112 kB
[12:21] <Adri2000> what do you think of this one?
[12:21] <LaserJock> Adri2000: what about it?
[12:22] <Adri2000> does it need a rebuild? how can I know?
[12:22] <LaserJock> I'm guessing Matthais already rebuilt the ones that needed to
[12:23] <LaserJock> *Matthias
[12:23] <Adri2000> ok
[12:23] <LaserJock> generally if there is a transition like that he just does it en-mass
[12:23] <geser> Adri2000: only those python apps need a rebuild which depend on python < 2.5
[12:24] <LaserJock> we shouldn't have to many of those I wouldn't think
[12:49] <gnomefreak> LaserJock: most of gnome but universe not too many
[12:49] <gnomefreak> sure there is alot any way you look at it but from what i can see on my system not too many uni/multi are affected
[12:51] <LaserJock> looks like some of the he removed the hard dependency
[02:21] <dakira> Hi.. I just tried to build Vidalia with pbuilder and get some errors I can't make any sense of. Specifically when it tries to install vidalia the make install throws some "permission denied" errors inside the pbuilder environment..
[02:21] <dakira> maybe someone knows this problem.. here's the relevant part of the output: http://pastebin.ca/314767
[02:23] <LaserJock> dakira: it's becuase it's trying to install to /usr/bin/
[02:24] <LaserJock> it needs to install to $(CURDIR)/<packagename/usr/bin
[02:24] <dakira> LaserJock: okay.. so I need to change the "rules"-file, right?
[02:24] <LaserJock> yeah
[02:26] <dakira> LaserJock: wow.. thanks A LOT! This happened to me before with something else and I never figured it out.. so now I get it..
[02:26] <dakira> I just didn't get the concept of pbuilder completely right
[02:27] <LaserJock> well, it's the way packaging works
[02:27] <LaserJock> the .deb is built from inside the debian/ directory
[02:27] <LaserJock> so you need to install files in there
[02:28] <LaserJock> and then it gets compressed up into a .deb with the right paths
[02:28] <LaserJock> that way you aren't *actually* installing to /usr/bin/ everytime you build a package
[02:28] <LaserJock> that would make things pretty messy
[02:28] <dakira> yeah.. I see that now.. I can't believe how blind I was towards this :-)
[02:28] <LaserJock> np, took me a while too ;-)
[02:29] <dakira> well.. it never gets messy since I work inside a pbuilder environment.. but still.. I just got it wrong
[02:32] <somerville32> LaserJock: When I first tried, I tried to install directly to /usr/bin/ too but my thinking (or understanding) was that pbuidler created a chroot and so what ever I did was happening actually in some pesudo file system
[02:32] <somerville32> *pseudo 
[02:33] <dakira> LaserJock: one more question.. do I have to set the --prefix of the configure part in "rules" to $(CURDIR)/<packagename>/usr, too?
[02:33] <LaserJock> I guess that's one of the prices we pay for telling everybody to use pbuilder first off
[02:33] <LaserJock> dakira: no, because that'
[02:34] <LaserJock> that's telling the package where things will be at runtime (i.e. when the .deb is unpacked on the users machine)
[02:34] <dakira> LaserJock: okay.. than the problem is that the vidalia dev hardcoded the install paths and doesn't use --prefix directive
[02:34] <LaserJock> dakira: wahoo, sounds like patch time :-)
[02:34] <dakira> *g*
[02:35] <LaserJock> I've gotta run right now
[02:35] <LaserJock> I might be on later
[02:35] <dakira> thanks for the help and clearing things up!
[02:35] <LaserJock> but there is some patching material in the packaging guide
[02:35] <LaserJock> and on wiki.ubuntu.com/MOTU/School
[02:35] <somerville32> dakira: dpatch is awesome :)
[02:36] <Toadstool> yay! openoffice preventing me from dist-upgrading :)
[02:36] <somerville32> Toadstool: Just remove the packages :)
[02:36] <Toadstool> I can wait 
[02:37] <somerville32> I wouldn't dist-upgrade right now anyhow
[02:37] <somerville32> Now with the python fallout :)
[02:37] <somerville32> *Not
[02:37] <somerville32> Gah, I can't type today :(
[02:37] <Toadstool> heh
[02:38] <dakira> somerville32: i'll have a look at dpatch as soon as a figure out what the dev has done wrongly ;)
[02:39] <persia> What's the policy on applying patches to fix Debian bugs that haven't been reported in Ubuntu?  Should an Ubuntu bug be created that links to the Debian bug with the patch?  The bug is certainly present in Ubuntu.
[02:44] <somerville32> Sounds good to me
[02:47] <Toadstool> persia: link it to the Debian bug too
[02:47] <persia> Toadstool: Of course.  The patch is actually from the Debian bug.
[02:50] <Toadstool> persia: if you could prepare a debdiff fixing as many bugs as possible and poke a MOTU to sponsor your fixes, it would be even better ;)
[02:51] <persia> Toadstool: That's basically what I do all day, every day (until I have to work again), but I usually only upload one debdiff per bug.  I should really fix my gpg configuration and attend the next meeting to become a member :)
[02:52] <Toadstool> great! and then try to become a MOTU, we need more manpower
[02:54] <persia> Toadstool: The main issue is that I will fail to check my email for months at a time when working (cf. my LP page).  Perhaps I'll become a MOTU at some point, but this usually requires two months of effort (and I rarely have that long a break).
[02:56] <Toadstool> persia: oh my bad, I know you... I have seen your real name so many times in changelogs but didn't link it to your nick and thought you were some kind of newcomer :)
[02:57] <persia> Toadstool: No worries :)
[02:57] <somerville32> hehe
[02:57] <somerville32> Should we only package stables releases or are betas good too?
[02:57] <persia> somerville32: betas are only good if they fix known bugs that cause problems.
[02:58] <somerville32> This is for a new package
[02:58] <persia> somerville32: Still, is the beta less buggy?
[02:58] <Toadstool> somerville32: what I usually do is package stable releases and extract patches from development branches
[02:58] <somerville32> k
[03:00] <Toadstool> but of course, if you feel like the beta would be better (let's say you tested thoroughly, no regressions, bug fixes, whatever) then you can package the beta
[03:02] <somerville32> kk
[03:11] <somerville32> Whats the magic tar command to gzip and untar w/o modifying the checksum again?
[03:11] <persia> somerville32: tar xzf works for me.
[03:12] <Hobbsee> somerville32: bunzip2 <tar> gzip -9 resulting tar
[03:12] <somerville32> persia: thanks
[03:12] <somerville32> Hobbsee, :)
[03:15] <somerville32> Woot! :)
[03:18] <Toadstool> somerville32: congrats' :)
[03:19] <Hobbsee> somerville32: yay!
[03:19] <Toadstool> hey Hobbsee!
[03:20] <Hobbsee> hey Toadstool!!!!
[03:21] <Toadstool> how is it going?
[03:21] <Hobbsee> good, and yourself?
[03:22] <Toadstool> alright, lot of work, lot of time with my girlfriend so not as much time as before for Ubuntu
[03:22] <somerville32> ...
[03:22] <somerville32> Umm...
[03:22] <somerville32> somethings wrong
[03:23] <somerville32> They changed the maintainer field to use my personal e-mail instead of my ubuntu one
[03:23] <somerville32> :(
[03:23] <Toadstool> "they"?
[03:23] <somerville32> Somewhere along the way it got changed by someone or something
[03:24] <somerville32> And I can't install the package...
[03:24] <somerville32> How odd
[03:25] <somerville32> E: Package pyneighborhood has no installation candidate
[03:25] <somerville32> And the depends weren't set properly
[03:25] <somerville32> guh...
[03:26] <somerville32> Is it possible I have something in my cache?
[03:26] <persia> somerville32: https://launchpad.net/ubuntu/+source/pyneighborhood reports no package published yet.  Wait a bit.
[03:26] <somerville32> Ok
[03:26] <somerville32> It must be in my cache
[03:26] <Toadstool> somerville32: pyneighborhood is still waiting for approval in new
[03:26] <somerville32> doh
[03:26] <somerville32> Ok
[03:26] <somerville32> Must be in my cache
[03:26] <Toadstool> https://launchpad.net/ubuntu/feisty/+queue?start=20 <-- here
[03:27] <somerville32> How can I clear my cache?
[03:28] <persia> somerville32: Try `sudo aptitude clean`
[03:29] <somerville32> apt-cache show pyneighborhood 
[03:29] <somerville32> Package: pyneighborhood
[03:29] <somerville32> Status: deinstall ok config-files
[03:29] <somerville32> What does that mean?
[03:30] <persia> somerville32: It's uninstalled, but not purged.  You can fix that with `sudo aptitude purge pyneighborhood`
[03:31] <somerville32> Thanks :)
[03:33] <StevenK> Or 'dpkg -P pyneighborhood'
[03:34] <StevenK> With a sudo prepended...
[03:46] <bddebian> Heya gang
[03:46] <Toadstool> hey bddebian!
[03:47] <bddebian> Hi Toadstool
[03:51] <cypherbios> heya bddebian :)
[03:51] <bddebian> Hi cypherbios
[03:54] <cypherbios> bddebian: http://revu.tauware.de/details.py?upid=4015 >> any problem in keep uploading and updating this package on REVU when it isn't archived?
[03:54] <bddebian> cypherbios: Even when packages are archived, you can upload new/updated versions.  It will automagically un-archive them
[03:56] <bddebian> For what? :-)
[03:56] <somerville32> For being such a good person! :)
[03:56] <somerville32> And because I know you'll review my package here in a second
[03:56] <Toadstool> bddebian: don't ask why, you deserve it! :)
[03:56] <somerville32> It's true
[03:56] <bddebian> Hah, I knew there was an alterior motive :-)
[04:04] <somerville32> Is the section util or utils?
[04:11] <StevenK> utils
[04:22] <bddebian> Heya LaserJock
[04:24] <cypherbios> hobbsee ops, wrong channel :)
[04:24] <cypherbios> Hobbsee: can you take a look when you have some time? http://revu.tauware.de/details.py?upid=4015
[04:25] <Hobbsee> lol
[04:31] <somerville32> If a package depends on gtk+, what package do I use?
[04:33] <somerville32> libgtk2.0-0 ?
[04:34] <LaserJock> build-time or run-time?
[04:35] <somerville32> run-time
[04:37] <LaserJock> ajmitch: but aren't you relaxing on a weekend?
[04:37] <manchicken> Anybody well versed in dh_install?
[04:38] <persia> manchicken: What are you looking to accomplish?
[04:38] <manchicken> persia: I'm trying to build adept from bzr.
[04:38] <manchicken> http://bazaar.launchpad.net/~jr/adept/ubuntu/ <-- That bzr repo
[04:39] <LaserJock> persia: you don't?
[04:39] <LaserJock> just bzr branch that url
[04:40] <manchicken> could somebody verify that adept won't build from bzr?
[04:40] <manchicken> Just build?
[04:40] <manchicken> (you'll have to build-dep adept first though I suppose, but that should be trivial to do in a pbuilder)
[04:41] <persia> LaserJock: Thanks.
[04:41] <persia> manchicken: Hold on a bit, and I'll verify.
[04:41] <manchicken> If you just `bzr co http://bazaar.launchpad.net/~jr/adept/ubuntu/ ./` it'll check it out.
[04:42] <LaserJock> yeah, bzr co would be faster then actually branching it
[04:45] <manchicken> It's so nice to be able to play DVDs on my machine again.
[04:50] <persia> manchicken: It doesn't build for me.  Looks like an automake issue.
[04:50] <manchicken> persia: What error are you getting?
[04:50] <manchicken> (just to make sure it's the same issue)
[04:50] <persia> manchicken: config.status: error: cannot find input file: adept/kubuntu_upgrader/Makefile.in
[04:51] <manchicken> Yeah...
[04:51] <LaserJock> mine is still downloading deps
[04:51] <manchicken> run `make -f ./admin/Makefile.common` and then debuild again.
[04:51] <persia> manchicken: It looks like Makefile.am isn't being used to generate Makefile.in.  I'm too annoyed about m4 recursion in autom4te right now to want to look into it deeper.
[04:52] <TheMuso> Hobbsee: I was glad when -devel quieted down.
[04:52] <TheMuso> I am not on -discuss.
[04:52] <manchicken> Persia: run `make -f ./admin/Makefile.common` and then debuild again.  That will get past that issue.
[04:52] <Hobbsee> TheMuso: yeah, exactly.  -discuss is worse than the previous devel
[04:54] <somerville32> I'm on -discuss and I hardly get anything
[04:54] <persia> manchicken: It gets to the compiling now.
[04:54] <somerville32> Or I think I'm on -discuss
[04:54] <manchicken> persia: I'm having ussues when it does the dh_install -padept-manager
[04:54] <Hobbsee> somerville32: likely on -devel then - there's usually heaps on devel-discuss
[04:54] <LaserJock> Hobbsee: it still doesn't look that bad to me
[04:55] <manchicken> w00t, feisty upgrades.
[04:55] <persia> Hobbsee: Are you sure you're not subscribed to devel-discuss-annoy-hobbsee?
[04:55] <LaserJock> hehe
[04:55] <bddebian> heh
[04:56] <ajmitch> LaserJock: the number of useless & unproductive threads has grown
[04:56] <LaserJock> ajmitch: it still seems better than the original -devel to me
[04:56] <ajmitch> I wouldn't say so
[04:56] <Hobbsee> persia: haha
[04:57] <LaserJock> it seems like a lot of dev types on there
[04:57] <LaserJock> I'm not seeing all the noise
[04:58] <teer2> Hi, my email was forwarded to the distribution list yesterday, about packaging commercial game demos.
[04:59] <manchicken> Non-free game demos?
[04:59] <teer2> I did not get back a response that addressed my questions.  Anyone able to hellp?  I did not get a to see the distribution list mail address.
[04:59] <teer2> manchicken: Yes.
[05:00] <manchicken> Why?
[05:00] <teer2> manchicken: Not sure what you mean by non-free actually.
[05:00] <manchicken> teer2: Restricts freedom.
[05:00] <persia> manchicken: A rebuild (after `make -f ./admin/Makefile.common`), didn't have any errors for me.  Is something you want not getting installed?
[05:00] <teer2> manchicken: They are freely distributable, but they are not free software.
[05:01] <manchicken> teer2: That's unfortunate.
[05:01] <persia> teer2: Those are just costless.  Not free.
[05:01] <manchicken> IIRC, Ubuntu has a position that favors free software.
[05:02] <ajmitch> if they are freely redistributable, it may be possible to put them in multiverse
[05:02] <teer2> These are guys trying to make a living making entertainment software for linux, and supporting the software full-time.  Don't you think we should help them out?
[05:02] <manchicken> teer2: Package the newly GPL'ed SecondLife client.  That'd be nice ^_^
[05:03] <manchicken> teer2: They should try to do so without trying to limit the freedom of others.  I do not think we should help others restrict the freedom of others for the sake of their own profit.  But that's just me.  I'm certainly no official voice.
[05:03] <persia> teer2: You'll get a better response from your mailing list post.  People who are responsible for balancing marketing and politics are more likely to be there.  The apps could go in multiverse, or perhaps commercial, depending.
[05:05] <teer2> persia: So what I am seeking is instructions on how these developers can create and submit a package for official (universe/metaverse/commercial) ubuntu distribution.
[05:05] <LaserJock> teer2: where did you email?
[05:05] <manchicken> teer2: If these people wanted to make free software, and earn their living supporting it, I'd support that whole-heartedly.  I just have this bias against fascism ^_^
[05:07] <LaserJock> teer2: I gave you some instructions yesterday didn't I?
[05:07] <persia> teer2: Most Ubuntu list archives are publically accessible from https://lists.ubuntu.com/mailman/listinfo/.  If you mailed one of these lists, you can probably find responses there (although you would likely have been cc'd).
[05:07] <teer2> manchicken: Second life will be a good example to others on how to make games open source commercially, WHEN they finally make it open source (which it isn't now).
[05:08] <manchicken> teer2: It's a beautiful thing that SecondLife is GPL'ed now... but until a program's licensing respects freedom, it should be avoided.
[05:08] <manchicken> teer2: Before it was GPL'ed, I said SecondLife should be avoided.
[05:09] <manchicken> teer2: Now that it is GPL'ed, it should be embraced and used in a manner that suits each user's purpose ^_^
[05:09] <teer2> LaserJock: Yes, thanks for your help, I emailed the games team, and Stefan Potyra emailed me back and said he wasforwarding it to the ubuntu-devel-discuss mailing list.  However, I did not hear a response in the last day.
[05:10] <teer2> manchicken: Commercial software can also produce open-source engines to be shared, also, their full-time support engages them in improving Linux UIs and smoothing out rough edges in distributions.  We have more to gain by being inclusive than exclusive.
[05:11] <manchicken> teer2: No, we don't.  If we embrace companies that seek to restrict our freedom we lose our freedom, and encourage fascism.
[05:12] <manchicken> teer2: We should demand that software licensing respects our freedom.  Anything short of freedom is unacceptable.
[05:12] <teer2> LaserJock: Actually mikecorn responded from the mailing list regarding packaging for a specific ubuntu versions, but not regarding packaging in general.
[05:13] <manchicken> teer2: I'm more than willing to include companies who are willing to respect freedom.
[05:14] <teer2> LaserJock: What I'm seeking is instructions on how these devs can do their packages and submit them - easy step-by-step instructions
[05:15] <teer2> manchicken: Games take months of time to make, usually by one developer working full time.  Unless we can establish a way for them to get compensated financially, then I think we should support the existing compensation model, since no others exist.  It's not like other software where people buy support packages.
[05:16] <manchicken> teer2: If they can't figure out how to make money, it's hardly the users' fault.  Why should people lose freedom because others can't figure out how to make money?
[05:17] <manchicken> teer2: I would even pay for a game if it respected my freedom.
[05:17] <joejaxx> bddebian: are you around?
[05:17] <teer2> manchicken: Because users demand the entertainment, and they will use consoles or windows which restrict their freedom entirely if they cannot find games on Linux.  Either way, they should have the choice between free and non-free software.
[05:19] <manchicken> teer2: non-free is non-free.  It doesn't matter what system it is on.  People should not package, distribute, or otherwise perpetuate this usury of freedom.  It is never okay to restrict another human being's freedom for the sake of profit.  Ever.
[05:19] <somerville32> Interesting conversation going on here
[05:19] <somerville32> However, I think it would be better suited somewhere else.
[05:19] <teer2> manchicken: You propose to restrict their freedom by not allowing them to choose non-free software
[05:20] <bddebian> joejaxx: Sure
[05:20] <teer2> somerville32: I'm just here looking for distribution package instructions.  I realize the room for arguements is down the hall.  Sorry!
[05:21] <manchicken> teer2: Nope.  I say that the software should always be free.  Shame on those developers for releasing non-free software.  They should be able to choose whatever software they want without having to worry about someone trying to steal their freedom.
[05:21] <somerville32> :)
[05:21] <joejaxx> bddebian: i know this might sound stupid but please forgive my ignorance
[05:21] <teer2> manchicken: I will let you have the last word on the subject.
[05:21] <joejaxx> bddebian: where can i download gnu/hurd the os that is
[05:22] <manchicken> teer2: That's fine.  I just hope you don't expect me to keep my mouth shut when you try to subversively distribute software that restricts freedom.
[05:22] <manchicken> ^_^
[05:22] <manchicken> somerville32: I've never been very good at staying on topic.
[05:22] <manchicken> And I still can't build this bloody adept package.
[05:22] <somerville32> Hobbsee, Whats the command syntax for creating a new patch with dpatch again?
[05:23] <manchicken> persia: Yo, could you pastebin your `dpkg -l | sort` for me?
[05:23] <manchicken> somerville32: Are you talking about cdbs-edit-patch?
[05:23] <persia> manchicken: Which pastebin is your favorite?
[05:23] <somerville32> no
[05:23] <somerville32> dpatch
[05:23] <manchicken> Righto.
[05:24] <manchicken> http://paste.ubuntu-nl.org/
[05:24] <Hobbsee> somerville32: dpatch-edit-patch or something
[05:24] <Hobbsee> somerville32: i dont remember, i never use dpatch
[05:24] <somerville32> What do you use?
[05:24] <ajmitch> Hobbsee doesn't need to use tools
[05:24] <joejaxx> bddebian: or is there not a gnu/hurd compilation yet
[05:25] <Hobbsee> somerville32: their converstaion only needs to stop when someoen else asks a question.  it probably is a vaguely relevant conversation.
[05:25] <ajmitch> she creates patches from the editor, knowing all the necessary context
[05:25] <Hobbsee> ajmitch: you're right, actually :P
[05:25] <somerville32> Hobbsee, I just asked a question :P
[05:25] <Hobbsee> hah
[05:25] <bddebian> joejaxx: You can get the Debian K14 install CDs here:  http://www.debian.org/ports/hurd/hurd-cd
[05:25] <bddebian> Well links from there anyway
[05:25] <manchicken> I think HURD can install next to your linux kernel.
[05:25] <joejaxx> bddebian: oh alright thank you :)
[05:25] <manchicken> That'd be neat.
[05:25] <manchicken> "Which kernel do I feel like using today?"
[05:25] <Hobbsee> and LONG LIVE CDBS!!!
[05:26] <ajmitch> manchicken: nice, but there's a completely different ABI, so apps can't be shared :)
[05:26] <manchicken> ajmitch: I suspect you'd merely have to recompile things.
[05:26] <ajmitch> sure, 'merely' recompiling the entire distro isn't much of a hassle, is it?
[05:27] <bddebian> heh
[05:27] <ajmitch> you just have things on separate partitions
[05:27] <manchicken> ajmitch: Details, details.
[05:27] <ajmitch> "Oooh, I feel like dual-booting today - let's start a full recompile!"
[05:27] <Hobbsee> ajmitch: like the python transition and worse :P
[05:27] <ajmitch> Hobbsee: far, *far* worse
[05:27] <Hobbsee> haha
[05:27] <manchicken> ajmitch: Recompiling with apt-get is easy ^_^
[05:27] <ajmitch> imagine recompiling firefox or OOo everytime you want to use it
[05:28] <bddebian> And glibc only takes about a day and a half to compile on GNU/Hurd ;-P
[05:28] <ajmitch> talk to bddebian about the fun of portability & GNU/Hurd
[05:28] <ajmitch> his sanity hasn't returned yet
[05:28] <bddebian> All I have to say is: MAXPATHLEN :-)
[05:28] <manchicken> ajmitch: If I had an extra disk to work on, I wouldn't mind trying some stuff out on it ^_^
[05:29] <ajmitch> at least you have pthreads now!
[05:29] <persia> manchicken: dpkg -l is far too long and the process appears manual (I'm not sure how to paste a file).  Could you paste your error?  That's probably an easier way for me to help.
[05:29] <ajmitch> manchicken: yeah, you're sick
[05:29] <bddebian> heh
[05:29] <Hobbsee> manchicken: keep fixing adept :P
[05:29] <Hobbsee> manchicken: and the rest of kubuntu :P
[05:29] <manchicken> ajmitch: No, I got this 64-bit processor and it LOVES to compile _^^
[05:30] <ajmitch> shame that it'd be wasted with GNU/Hurd
[05:30] <manchicken> Hobbsee: Did I tell you that I got the DVD player working as a DIRECT result of your mailing list responses to someone else's question?
[05:30] <ajmitch> bddebian: what's the current memory limit with gnumach?
[05:30] <manchicken> persia: Gimme a second, I'll get the error for you.
[05:30] <bddebian> ajmitch: Hush up you traitor ;-P
[05:30] <bddebian> ajmitch: 1Gb
[05:30] <bddebian> Well a little less than 1Gb actually
[05:30] <ajmitch> bddebian: I preferred to spend my time where it would be more useful
[05:31] <manchicken> ajmitch: I actually don't like the linux kernel.
[05:31] <ajmitch> should be interesting reading to see where it sucks
[05:31] <manchicken> I don't necessarily like Hurd either though.
[05:31] <manchicken> persia...
[05:32] <manchicken> dh_install -padept-manager
[05:32] <manchicken> cp: cannot stat `./debian/tmp/usr/bin/adept_manager': No such file or directory
[05:32] <manchicken> dh_install: command returned error code 256
[05:32] <manchicken> make: *** [binary-install/adept-manager]  Error 1
[05:32] <bddebian> adept_manager or adept-manager?
[05:32] <ScottK> bddebian: Would you be up for another look at my package? I got the documentation stuff all worked out: http://revu.tauware.de/details.py?upid=4056
[05:33] <bddebian> ScottK: I'll try.  I'm busy playing my NON-FREE game atm ;-P
[05:33] <joejaxx> bddebian: is there a channel for hurd?
[05:33] <bddebian> joejaxx: #hurd
[05:33] <Hobbsee> manchicken: nope?  cool!
[05:33] <persia> manchicken: Oh.  I'm really not sure why it worked for me then.  Looking briefly at debian/dirs, I suspect you need to replace "usr" with "usr/bin".
[05:33] <ScottK> Thanks.  It'd be cool if you did, I have a couple of others and I think I'm ready to get this one behind me.
[05:34] <manchicken> persia: But these files are the same for me as they are for you....
[05:34] <persia> manchicken: That's why I'm not sure why it worked for me :)
[05:36] <manchicken> I'm thinking you have something installed that I don't...
[05:43] <persia> manchicken: I probably do, but your Build-depends looks fine to me, and I'm guessing you are building with newest feisty, so I shouldn't have newer cdbs or debhelper.
[05:44] <bddebian> ScottK: Don't shoot me :-)
[05:44] <bddebian> W: postfix-policyd-spf-perl: manpage-has-errors-from-man usr/share/man/man8/postfix-policyd-spf-perl.8p.gz 167: warning: can't find numbered character 194
[05:44] <manchicken> persia: Could you give me the versions of those two packages?
[05:45] <manchicken> I've got 0.4.46ubuntu7
[05:45] <persia> manchicken: debhelper 5.0.42ubuntu1 and cdbs 0.4.46ubuntu7.
[05:45] <ScottK> Any suggestion on where I look to find out what numbered character 194 is and what I do about it?
[05:45] <ScottK> bddebian: No shooting.  It's my job to get it right and you job to find it when I don't.
[05:46] <manchicken> I got the same versions.
[05:47] <persia> ScottK: Try vim -b on the file.  One of the characters should be \194.  Delete this.  Edit the file in a UTF-8 environment.  Add the correct character.
[05:47] <bddebian> N:   "can't find numbered character" usually means latin1 etc in the input,
[05:47] <bddebian> N:   and this warning indicates characters will be missing from the output.
[05:47] <bddebian> N:   You can change to escapes like \[:a]  described on the groff_char man
[05:47] <bddebian> N:   page.
[05:47] <manchicken> persia: What version of devscripts do you have?
[05:48] <persia> manchicken: 2.9.27ubuntu2
[05:48] <manchicken> Hmm....
[05:50] <ScottK> Does Kate count as a UTF-8 environment?
[05:52] <persia> ScottK: If KDE is in a UTF-8 locale (I think it is by default for Kubuntu).
[05:53] <ScottK> Thanks.  I'll go double check that.
[05:55] <ScottK> Is en-us UTF-8?
[06:01] <Laser_away> teer2: still there?
[06:05] <ScottK> Ironically enough txt2man has no man page.
[06:05] <bddebian> heh
[06:05] <LaserJock> ScottK: really?
[06:05] <LaserJock> does it have a txt? :-)
[06:06] <ScottK> txt2man -h
[06:07] <ScottK> It has a man page, it's just blank, at least here.
[06:15] <somerville32> My dpatches aren't being applied.
[06:16] <LaserJock> you have the right stuff in debian/rules?
[06:17] <somerville32> Yup
[06:17] <crimsun> are they listed in debian/patches/00list ?
[06:18] <somerville32> yes
[06:19] <crimsun> and the dpkg-buildpackage log?
[06:19] <somerville32>  debian/rules build
[06:19] <somerville32> test -d debian/patched || install -d debian/patched
[06:19] <somerville32> dpatch  apply-all  
[06:19] <somerville32> dpatch  cat-all  >>patch-stampT
[06:20] <crimsun> it will enumerate each dpatch as it is applied and report success or failure (ftbfs) on the same line
[06:21] <somerville32> It doesn't
[06:21] <somerville32> so I know my patch isn't being applied
[06:21] <crimsun> url to source package?
[06:21] <somerville32> It isn't uploaded
[06:26] <LaserJock> Hobbsee: is the u-u-s mailing list up and running?
[06:26] <crimsun> yes, it is.
[06:26] <LaserJock> that should be on -motu
[06:26] <somerville32> ultra-ubuntu-secret mailing list?
[06:27] <somerville32> http://revu.tauware.de/details.py?upid=4061
[06:27] <Toadstool> or ubuntu-universe-sponsors iirc
[06:27] <Toadstool> re
[06:28] <somerville32> ah
[06:29] <Hobbsee> LaserJock: yes
[06:29] <crimsun> that source package does not contain a debian/patches/00list and thus no dpatches would be applied.
[06:29] <LaserJock> Hobbsee: excellent, thank you very much. :-)
[06:29] <Hobbsee> LaserJock: :)
[06:30] <LaserJock> I was sad for those emails to go
[06:30] <somerville32> lmao
[06:30] <LaserJock> because navigating +subscribed bugs on that one is a little tough
[06:30] <somerville32> I forgot to debuild -S -sa it again
[06:30] <crimsun> well if it's bug emails you seek, I can send you the six thousand unread I have.
[06:30] <somerville32> thanks crimsun
[06:30] <LaserJock> and I *must* get better at email
[06:31] <LaserJock> crimsun: 6k? dude, how long will it take you to get through that?
[06:31] <crimsun> 30 mins.
[06:31] <somerville32> crimsun == machine
[06:31] <LaserJock> lots of trashing, I'm guessing
[06:31] <somerville32> true
[06:33] <LaserJock> I just get information overload and stare at my screen for a while thinking "Oh my gosh, how can I get anything done"
[06:34] <LaserJock> apparently that's what sets the losers from the crimsuns :-)
[06:35] <LaserJock> bddebian!
[06:35] <somerville32> false
[06:35] <LaserJock> boy, have I a job for you, mwuahaha ;-)
[06:35] <bddebian> Uh oh
[06:36] <LaserJock> according to http://tiber.tauware.de/~laserjock/motuscience/bugs.html we have 184 open science bugs
[06:36] <LaserJock> you wanna have a go at some?
[06:36] <bddebian> Sure
[06:38] <bddebian> Gads, still tetex stuff eh :-(
[06:38] <LaserJock> I'm guessing there are quite a few sync/merge bugs in there
[06:38] <LaserJock> yeah, tetex and gnumeric are the big ones, but they're also in Main so they get more attention I think
[06:38] <bddebian> :-(
[06:39] <manchicken> Do you guys do development in pbuilder?
[06:39] <LaserJock> yes
[06:39] <manchicken> Or do you develop in your normal environment and build and test in pbuilder?
[06:39] <LaserJock> well, we build in pbuilder
[06:39] <bddebian> yes
[06:39] <manchicken> I've never really used pbuilder before.
[06:39] <manchicken> I've just been doing stuff in chroot.
[06:39] <bddebian> I typically only use pbuilder for building
[06:39] <LaserJock> it's good
[06:40] <LaserJock> yeah
[06:40] <LaserJock> I use it occasionally for other things
[06:40] <LaserJock> manchicken: it's small then a chroot when packed (like 50-100MB)
[06:40] <LaserJock> it also makes sure your deps are right
[06:41] <LaserJock> at it's basically the closed we have to the buildd environments
[06:41] <LaserJock> as
[06:41] <LaserJock> *as I meant
[06:41] <LaserJock> shesh
[06:41] <LaserJock> ^^ the Hobbsee shell
[06:41] <Hobbsee> LaserJock: hrm?
[06:42] <Hobbsee> haha
[06:42] <manchicken> I've just been using a chroot and building and installing debs.
[06:42] <manchicken> It's like pbuilder, except I actually do my development in the chroot.
[06:42] <LaserJock> yeah, I know
[06:43] <LaserJock> we just generally prefer using pbuilder before uploading because it's a clean chroot
[06:43] <LaserJock> so deps and stray files aren't a problem
[06:44] <Toadstool> well, most of the time :)
[06:44] <LaserJock> heh, there are always exceptions, it seems
[06:46] <Toadstool> I've once been bitten by a package not build-depending on procps although it needs it iirc (don't ask me why...)
[06:47] <Toadstool> procps is installed in a pbuilder but not on the buildds
[06:47] <Toadstool> or something like that :p
[06:47] <LaserJock> well, we had a case the other day where a package failed to find pkg-config on the buildd
[06:47] <LaserJock> but it worked fine in pbuilder
[06:48] <Toadstool> yup, things happen
[06:48] <LaserJock> I think it must be his gf
[06:48] <Toadstool> heh
[06:51] <Toadstool> visas suck by the way, I don't want to go back to France :p
[06:54] <LaserJock> it seems like REVU has been fairly busy since we did the REVU Sprint
[06:54] <LaserJock> or is it just me?
[06:59] <crimsun> it's you, baby.
[06:59] <crimsun> you're the motu supastar!!!
[06:59] <somerville32> 0_0
[07:06] <LaserJock> crimsun: well, I thought it might have been because I was paying attention to it more
[07:06] <LaserJock> but it really does seem like there is more activity
[07:06] <duluu> what does python (<< 2.5) mean?
[07:07] <crimsun> it means strictly les than 2.5
[07:07] <crimsun> less, even
[07:07] <crimsun> LaserJock: of course, you're the motu superstar.
[07:07] <LaserJock> bah
[07:07] <LaserJock> crimsun: stop it before I turn into bddebian ;-)
[07:07] <crimsun> you two are already motu deities
[07:08] <LaserJock> motu dummies perhaps
[07:08] <bddebian> Hey, I resemble that remark!
[07:08] <duluu> i'm having problem to install ubuntu-desktop on my system 
[07:09] <duluu> because packages that have python (<< 2.5) dependency failing to install
[07:09] <duluu> I use feisty
[07:09] <somerville32> Can someone motu supastar themselves over to http://revu.tauware.de/details.py?upid=4063 ?
[07:09] <LaserJock> duluu: I think that might be just a temporary problem
[07:10] <duluu> but I want to understand the problem, and help 
[07:11] <LaserJock> somerville32: sorry, not today. I'm trying to put plastic over windows and work on the packaging guide
[07:11] <LaserJock> duluu: well, we are switching to python 2.5 as the default python version
[07:11] <somerville32> bddebian, :)
[07:11] <crimsun> duluu: you can't help, really. It's a transition; all the packages are being rebuilt.
[07:12] <duluu> ok 
[07:12] <duluu> thanks
[07:15] <somerville32> Toadstool, :)
[07:16] <duluu> how long it will take, approximately?
[07:17] <LaserJock> not long I don't think
[07:17] <crimsun> a couple more business days max
[07:17] <LaserJock> Matthias uploaded a whole bunch of packages for rebuilding over 12 hrs ago
[08:22] <ScottK> That's done at last.  http://revu.tauware.de/details.py?upid=4064 is free of unexpected lintian errors if any MOTU would please take a look.  
[08:29] <palski> is config.guess meant to be changed during debuild?
[08:30] <LaserJock> it's better to not be in clean:
[08:30] <LaserJock> but otherwise
[08:31] <palski> problem is that I'm trying to merge one package and before dbuild diffs are good but after debuild debdiff has lots of diffs in config.guess
[08:32] <crimsun> right, so either use filterdiff(1), or remove autotools-dev
[08:33] <palski> ok, i'll try
[08:40] <ScottK> 'night all.  I'm off to bed.
[09:02] <somerville32> nvm
[09:02] <somerville32> hehe
[09:09] <palski> Merges should always be marked as wishlist?
[09:09] <persia> palski: Unless they fix some known larger issue, I think so.
[09:10] <palski> persia: ok, thanks
[09:11] <Simon80> so, um, I just packaged logitech_applet, it's got no maintainer, but it's small and doesn't really need one
[09:11] <Simon80> is that a bad enough reason to reject it?
[09:11] <persia> Simon80: If you packaged it, you get to be the maintainer:)
[09:12] <Simon80> yay!
[09:12] <Simon80> alright, someone revu it, easiest revu ever.. the only gripe you may have is no manpage
[09:12] <Simon80> I suppose it's a legitimate gripe
[09:13] <somerville32> Simon80: Has to have a manpage
[09:13] <somerville32> Please make one and reupload :)
[09:13] <tsmithe> could a MOTU please take a look at my two packages for UbuntuStudio? http://revu.tauware.de/details.py?upid=4049
[09:13] <Simon80> lol, somerville, cmon :(
[09:13] <Simon80> bah
[09:14] <persia> Simon80: no manpage will cause a lintian error, which is grounds for further REVU.
[09:14] <somerville32> tsmithe: Did you fix the errors that bddebian listed?
[09:15] <Simon80> it's not an error
[09:15] <Simon80> it's a warning
[09:15] <tsmithe> somerville32, they are unfixable
[09:15] <somerville32> tsmithe, wrong.
[09:15] <tsmithe> err...
[09:15] <tsmithe> how so?
[09:16] <somerville32> W: alsa-firmware: extra-license-file lib/firmware/emagic/license.txt 
[09:16] <tsmithe> oh yeah
[09:16] <somerville32> Remove license.txt from being installed
[09:16] <tsmithe> i thought you mean the errors
[09:16] <somerville32> W: alsa-firmware: old-fsf-address-in-copyright-file 
[09:16] <somerville32> Update the copyright file
[09:16] <somerville32> W: alsa-firmware: description-synopsis-might-not-be-phrased-properly 
[09:16] <somerville32> remove period from end of synopsis
[09:16] <tsmithe> ok
[09:16] <somerville32> W: alsa-firmware: description-starts-with-leading-spaces 
[09:16] <somerville32> Should be able to figure that one out
[09:17] <somerville32> As for the errors, run lintian with verbose enabled
[09:17] <tsmithe> ok
[09:18] <tsmithe> can i use dh_install to uninstall a file, or will it have to be done with a manual rm in the rules?
[09:18] <somerville32> What is installing it? The makefile?
[09:18] <somerville32> Does this package exist in Debian?
[09:19] <tsmithe> yes no
[09:19] <somerville32> Elaborate, please :)
[09:19] <tsmithe> ok
[09:19] <tsmithe> the makefile is installing it
[09:19] <tsmithe> it does not exist in debian
[09:20] <tsmithe> (at least it didn't last time i checked)
[09:20] <tsmithe> well it seems to now
[09:20] <persia> tsmithe: The easiest way to mask the emagic license is probably to delete it with a patch prior to build.
[09:20] <tsmithe> but it's an old version
[09:21] <somerville32> tsmithe: Then you need to download the package and update it
[09:21] <somerville32> Not make your own
[09:21] <tsmithe> to be honest, i thought it didn't exist in debian
[09:21] <somerville32> Thats ok
[09:21] <somerville32> but you still versioned the package wrong then
[09:22] <tsmithe> somerville32, hmm?
[09:22] <somerville32> alsa-firmware_1.0.14rc1-1ubuntu1
[09:23] <somerville32> If it is a new package that doesn't exist in debian, it would be: lsa-firmware_1.0.14rc1-0ubuntu1
[09:23] <somerville32> with the a on front of course
[09:24] <tsmithe> ok
[09:24] <somerville32> Also
[09:24] <somerville32> I would have seperate binary packages for the different blobs
[09:24] <tsmithe> hmm
[09:25] <tsmithe> that's might be a bit confusing
[09:25] <tsmithe> we have alsa-firmware-loaders
[09:25] <tsmithe> as 1 package for many loaders
[09:26] <somerville32> Hmm.. sure
[09:26] <somerville32> w/e works
[09:26] <tsmithe> i'm also updating that to fit with the new alsa-firmware package, upid 3892
[09:27] <somerville32> rm -f $(CURDIR)/debian/alsa-firmware/lib/firmware/*.bin
[09:27] <somerville32> That is in build
[09:27] <somerville32> What does that do?
[09:27] <somerville32> Does that remove the binary you aren't allowed to distribute?
[09:27] <tsmithe> no
[09:27] <somerville32> What does it do?
[09:27] <somerville32> Or sorry, what is it for?
[09:27] <tsmithe> it's left over from when i had troubles with hdsploader
[09:27] <somerville32> Please fix it then
[09:27] <tsmithe> but now it does nothing (as theres nothing there)
[09:29] <somerville32> I also notice you use different e-mails all over the place
[09:29] <somerville32> You also must use a @ubuntu.com e-mail for the maintainer field
[09:29] <somerville32> Anyhows, I don't think your package will get approved since it already exists in Debian
[09:30] <somerville32> I also think that config.* are supposed to be deleted in clean
[09:32] <somerville32> I hope thats helpful to you tsmithe
[09:32] <somerville32> Anyhows, I need sleep :)
[09:32] <tsmithe> it is - very
[09:32] <tsmithe> thanks
[09:32] <tsmithe> night
[09:32] <somerville32> That is... lol
[09:32] <tsmithe> huh?
[09:32] <somerville32> unless someone else needs a review :)
[09:32] <Simon80> it can wait
[09:34] <tsmithe> somerville32, you still around
[09:34] <tsmithe> ?
[09:34] <somerville32> Yup
[09:34] <tsmithe> i was being stupid
[09:35] <tsmithe> when i searched for alsa-firmware in the debian packages, it came up with alsa-firmware-loaders
[09:35] <tsmithe> i didn't read -loaders
[09:35] <tsmithe> it's not in debian
[09:35] <somerville32> ah, k :] 
[09:35] <somerville32> Simon80, Want me to review?
[09:36] <tsmithe> somerville32, one last thing
[09:36] <somerville32> dh_fixperms seems to be very much broken :(
[09:37] <tsmithe> at upid 3892, i have updated ubuntu's alsa-tools package to support my new alsa-firmware... however bddebian complains about manpages. the current ubuntu package doesn't have manpages...
[09:37] <Simon80> how do I incorporate docbook xml processing into my cdbs rules file?
[09:37] <somerville32> tsmithe, It must have a manpage.
[09:38] <tsmithe> must? the existing package doesn't - otherwise it would be in mine
[09:38] <somerville32> tsmithe, Write your own
[09:38] <tsmithe> hmm
[09:38] <tsmithe> that's a bummer
[09:39] <lifeless> somerville32: there is not MUST for man pages.
[09:39] <lifeless> somerville32: its preferred, not required.
[09:39] <Simon80> indeed
[09:39] <lifeless> that said, writing a small one is easy, and a good idea
[09:39] <manchicken> Anybody know if k9copy is main or universe?
[09:39] <somerville32> lifeless: Ther other MOTUs make me have one in all of mine, lol
[09:39] <lifeless> manchicken: apt-cache show k9copy
[09:39] <Simon80> but how do I process it?
[09:39] <lifeless> somerville32: a reviewer can do that ;)
[09:39] <Simon80> someone who's used a manpage.xml, just tell me
[09:40] <manchicken> Beautiful.  Thanks.
[09:40] <lifeless> Simon80: if its a man page, surely patch the package source, as you'll want to feed it upstream
[09:40] <manchicken> I'm learning all sorts of things about dpkg.
[09:40] <Simon80> err... lifeless, no
[09:40] <manchicken> Like, yesterday I learned `dpkg-query -S /usr/bin/perl` will tell you what package /usr/bin/perl was installed by.
[09:40] <manchicken> mmm... dpkg...
[09:41] <tsmithe> tee hee somerville32: my asoundconf-gtk got in ages ago :P
[09:41] <somerville32> tsmithe, I know.
[09:41] <tsmithe> :)
[09:41] <tsmithe> poor poor cody
[09:41] <Simon80> manchicken dpkg -l - lise all packages, dpkg-deb -c *.deb, list files in a deb, dpkg-query -L package, list files in installed package
[09:41] <somerville32> tsmithe, Why am I poor?
[09:41] <Simon80> list*
[09:41] <tsmithe> somerville32, cos you haven't donated to the venezuela fund! :P
[09:42] <lifeless> Simon80: why no ? manpages generally wont be distro specific
[09:42] <somerville32> tsmithe, and I won't ;] 
[09:42] <Simon80> lifeless: I mean, what's the simplest thing to add to my cdbs rules file to get it to build my manpage from manpage.xml
[09:42] <tsmithe> somerville32, so you'l
[09:42] <lifeless> Simon80: so the upstream author will want it
[09:42] <tsmithe> hmm
[09:42] <tsmithe> somerville32, so you'll stay poor
[09:42] <tsmithe> :P
[09:42] <somerville32> tsmithe, But really... why am I poor?
[09:42] <lifeless> Simon80: the simplest thing is not to build man pages from within the distro *packaging rules*, but to build them from within the *source code building rules*
[09:42] <tsmithe> somerville32, cos your app's not in
[09:43] <tsmithe> and monday's a long time away
[09:43] <Simon80> err..
[09:43] <somerville32> tsmithe, https://launchpad.net/~cody-somerville/+packages
[09:43] <Simon80> lifeless: it's inconsequential, there's NO upstream
[09:43] <lifeless> what package is this ? :)
[09:43] <Simon80> logitech_applet
[09:44] <Simon80> it's very small, doesn't even need a manpage, so I'm kind of wanting to get this over with
[09:44] <lifeless> Simon80: is there a configure, and Makefile.am etc ?
[09:44] <Simon80> yeah
[09:45] <lifeless> then thats the place to put the manpage generation
[09:45] <lifeless> as autoconf and automake have a tonne of machinery for doing that
[09:45] <Simon80> oh
[09:46] <lifeless> your debian/ directory should be exclusively for doing 'package the software' tasks - its not geared for doing general software building
[09:46] <Simon80> um, no
[09:46] <lifeless> and trying to do general software builds within it will just generate metric amounts of cruft.
[09:46] <Simon80> debian has to build the software
[09:46] <Simon80> ah
[09:46] <Simon80> well, not really, this is a one time deal
[09:47] <Simon80> and I mean, what you're saying is contrary to what dh_make does, which is put a manpage into debian/
[09:47] <LaserJock> heh, it wouldn't be the first time dh_make does something we generally don't want to do
[09:47] <lifeless> dh_make takes the built manpage and packages it
[09:48] <Simon80> lol
[09:48] <lifeless> it does not *build* the manpage in the first place
[09:48] <LaserJock> it converts it from sgml to man
[09:48] <Simon80> no, dh_make generates a debian directory
[09:48] <LaserJock> which is sort of building
[09:48] <Simon80> you're confusing debhelper with dh_make
[09:48] <LaserJock> no
[09:48] <Simon80> not you
[09:49] <lifeless> later all
[09:49] <Simon80> and I know, dh_make is part of debhelper
[09:49] <LaserJock> I don't think it is
[09:49] <somerville32> I have a file that is not a binary nor a script with perms 0755 in the original tarball from upstream. dh_fixperms does not seem to address the issue so is it ok for me to manually modify the permissions before running make? :)
[09:50] <LaserJock> and lifeless is right in the sense that packaging isn't meant to do a bunch of building, patching, and adding files
[09:50] <Simon80> hrm
[09:50] <LaserJock> it's meant to just "guide" the build process along and make sure things get packaged up into a .deb properly
[09:50] <LaserJock> *normally* things should go upstream
[09:50] <LaserJock> but as you've said there is no upstream
[09:51] <LaserJock> so you need to take vare of it
[09:51] <siretart> LaserJock: you were talking about acroread removed from ubuntu before, no?
[09:51] <somerville32> LaserJock: ^^
[09:51] <LaserJock> yeah
[09:51] <LaserJock> I'm sad to see it go
[09:52] <LaserJock> but I read the bug, it seems difficult
[09:52] <Simon80> from my point of view, this is a tiny package, NO upstream, I've been using a checkinstalled copy for ever, and I don't even care if there's a manpage in it
[09:52] <LaserJock> somerville32: I guess you could but I don't know why you would exactly
[09:52] <Simon80> all I wanted to know is what one liner to add to my rules to get this manpage file taken care of
[09:52] <tsmithe> LaserJock, are you free to review?
[09:52] <somerville32> LaserJock, Because lintian and linda complain
[09:52] <LaserJock> tsmithe: nope
[09:52] <tsmithe> ok
[09:52] <LaserJock> somerville32: ah, then there you go
[09:52] <somerville32> W: catfish; Executable /usr/share/catfish/catfish.glade with perms 0755 is not an ELF file or script.
[09:53] <LaserJock> tsmithe: sorry dude, trying to get to bed
[09:53] <tsmithe> ahh
[09:53] <tsmithe> i'll let you rest then
[09:53] <LaserJock> Simon80: dh_make provides you with the line
[09:53] <Simon80> hasn't seemed to.. I genned a cdbs package
[09:53] <LaserJock> ah, that would be why
[09:54] <LaserJock> just do a quick one in a tmp dir
[09:54] <somerville32> LaserJock: I did chmod -x but it still complains : (
[09:54] <LaserJock> single binary
[09:54] <LaserJock> somerville32: hmm
[09:54] <somerville32> LaserJock: Can I add an override?
[09:54] <somerville32> Actually, no
[09:54] <somerville32> Best just to fix it
[09:55] <slomo> LaserJock: why should acoread be removed?
[09:55] <LaserJock> slomo: apparently the license makes it undistributable
[09:55] <LaserJock> it has been removed from Feisty by tollef
[09:56] <somerville32> LaserJock, What permissions should the gladefile have?
[09:56] <somerville32> I'll just patch the Makefile to set the permissions with install
[09:56] <LaserJock> somerville32: just normal
[09:56] <somerville32> Whats "normal"?
[09:56] <slomo> LaserJock: oh... well, i don't use it anyway ;) maybe this gets more people to use and improve evince/poppler ;)
[09:56] <LaserJock> 660? perhaps
[09:56] <LaserJock> slomo: unfortunately it is a "must have" app for me
[09:56] <crimsun> somerville32: 644
[09:57] <slomo> LaserJock: why?
[09:57] <LaserJock> slomo: all the vast number of university forms
[09:57] <LaserJock> acroread is the only thing that will do the filling out of them properly
[09:57] <crimsun> many of our pdfs are encrypted with forms
[09:58] <slomo> LaserJock: right... but this should change in the near future, people were working on form support for evince and the screenshots looked good already...
[09:58] <LaserJock> for the most part our uni no longer takes hand done forms
[09:58] <LaserJock> slomo: we'll see, Linux acroread barely gets by as it is
[09:58] <LaserJock> I almost have to use wine+acroread
[09:58] <somerville32> What is acroread do?
[09:58] <somerville32> heh
[09:58] <somerville32> What does acroread do?
[09:59] <LaserJock> the acrobat pdf reader
[10:00] <somerville32> Interesting
[10:00] <LaserJock> we get into trouble a fair amount as it is because we us Linux acroread
[10:01] <StevenK> acroread was killed from Feisty, if I recall?
[10:01] <crimsun> yesterday, yes
[10:02] <crimsun> immediately after being ACCEPTed, ironically
[10:02] <slomo> LaserJock: does your university pay you windows licenses? seems that this is the only correct way then for them to fill the forms ;)
[10:02] <Simon80> http://revu.tauware.de/details.py?upid=4065
[10:02] <StevenK> crimsun: Hah
[10:02] <Simon80> perhaps someone would like to just review it, it's just a manpage, NOBODY who is using this utility needs me to copy its --help output into a manpage
[10:03] <tsmithe> somerville32, that rm line is needed
[10:03] <somerville32> tsmithe, Why?
[10:04] <tsmithe> cos otherwise i get two copies of the files it removes
[10:05] <siretart> hm. perhaps we can do something like 'http://debian-unofficial.org' - think of http://ubuntu-unofficial.org or something
[10:05] <LaserJock> slomo: they pay for windows, and office, and full adobe acrobat if I want
[10:06] <somerville32> tsmite: What do you mean?
[10:06] <siretart> who would be interested in helping out maintaining such an repo?
[10:06] <LaserJock> siretart: what would it have in it?
[10:07] <LaserJock> I'm not hugely familiar with debian-unofficial.org
[10:07] <somerville32> siretart: Sure. More practise the better :)
[10:07] <crimsun> I'm still holding out hope for evince (and possibly acroread in feisty-commercial)
[10:07] <somerville32> crimsun: My thoughts exactly :re feisty-commercial
[10:07] <tsmithe> somerville32, otherwise, i get files in /lib/firmware and /lib/firmware/hdsploader
[10:08] <StevenK> crimsun: What about evince?
[10:08] <somerville32> tsmithe, But why?
[10:08] <crimsun> StevenK: hoping that its form-filling capabilities mature
[10:08] <siretart> LaserJock: look at http://debian-unofficial.org/packages.html for getting an idea
[10:08] <StevenK> Ahhh.
[10:08] <tsmithe> cos they are copied by dh_install, but not removed
[10:09] <siretart> perhaps libdvdcss as well
[10:09] <somerville32> tsmithe: Then fix dh_install?
[10:09] <somerville32> Why would dh_install copy it over twice?
[10:10] <tsmithe> it doesn't... the makefile puts it in /lib/firmware, and dh_install copies it to /lib/firmware/hdsploader, leaving the old files... bah; i'll just patch the makefile
[10:10] <somerville32> Good idea! :)
[10:10] <somerville32> But it is best to use the Makefile instead of dh_install
[10:11] <tsmithe> of course
[10:13] <somerville32> crimsun: I have a package that I just uploaded to revu that I'm 99% ready for upload unless I've done something stupid :) Could you review quickly? (the package is small so should be quick too)
[10:13] <somerville32> *sure is
[10:13] <somerville32> Xubuntu related (if thats a motivator ;] )
[10:14] <crimsun> unfortunately it's quarter past 4, and I'm about to collapse. I'll review some later this noon.
[10:14] <tsmithe> in the morning?
[10:14] <somerville32> crimsun: 5am here ;] 
[10:14] <tsmithe> you should sleep!
[10:15] <tsmithe> both of you!
[10:15] <Laser_away> me too, even though it's only 1:00am
[10:15] <somerville32> siretart: How about you? :)
[10:15] <tsmithe> it's 0915 here
[10:16] <Laser_away> don't, your brain will rot
[10:16] <Laser_away> ;-)
[10:16] <Laser_away> good night everybody
[10:16] <tsmithe> :)
[10:16] <tsmithe> night
[10:16] <somerville32> Welp, http://revu.tauware.de/details.py?upid=4066 <-- If anyone wants to review :)
[10:17] <tsmithe> welp? you really should go to sleep
[10:17] <somerville32> I should
[10:17] <somerville32> tsmithe: Why don't you review my package for me?
[10:17] <tsmithe> ok
[10:17] <somerville32> Maybe I've done something stupid because I'm sleepy
[10:17] <tsmithe> i'll try
[10:17] <somerville32> ok :)
[10:18] <somerville32> Simon80, You still around?
[10:19] <somerville32> Simon80, You need to rebuild the source package
[10:19] <somerville32> debuild -S -sa
[10:19] <somerville32> And then reupload
[10:19] <siretart> somerville32: well, I would talk and arrange things with the debian-unofficial guy, but I don't think I can maintain the repo alone
[10:19] <somerville32> siretart: Awesome.
[10:20] <somerville32> siretart: Review me package and it's a deal ;] 
[10:20] <somerville32> Simon80, However, looking through the diff, it appears that there is some issues.
[10:20] <Lutin> hay there
[10:20] <tsmithe> somerville32, that package looks fine and dandy to me
[10:20] <somerville32> tsmithe, Awesome :) Thanks.
[10:21] <Lutin> siretart: could you have a look at this SRU proposal ? https://bugs.launchpad.net/ubuntu/+source/evolution-jescs/+bug/77977
[10:21] <Ubugtu> Malone bug 77977 in evolution-jescs "[SRU] [ftbfs]  typo in evolution-jescs-2.8.2/debian/rules" [Medium,In progress]  
[10:23] <siretart> somerville32: which package?
[10:23] <somerville32> siretart, http://revu.tauware.de/details.py?upid=4066
[10:28] <somerville32> Siretart: If you're reviewing it, just let me know cause I'm waiting for you to finish before I goto bed ;] 
[10:30] <siretart> puh, python stuff. with pysupport :/
[10:32] <somerville32> It is easy!
[10:32] <somerville32> :)
[10:33] <somerville32> Siretart, if I wanted to become a MOTU, would you help me? :)
[10:34] <tsmithe> i want to become a motu - but i need to be a member first...
[10:34] <siretart> somerville32: I've seen you hanging around here for some time, I think you'd make a good ubuntu-dev
[10:34] <somerville32> siretart: Should I get some more experience under my belt before applying with the TB though?
[10:35] <siretart> somerville32: I've just looked at this one package, and I think it is fine. Who did sponsor your previous uploads?
[10:35] <somerville32> siretart: Crimsun and LaserJock
[10:36] <somerville32> Crimsun did my two SRUs and LaserJock did pyNeighborhood
[10:36] <tsmithe> how much does one have to have done to get membership, even?
[10:36] <somerville32> tsmithe: Your not a member yet?
[10:36] <tsmithe> nope
[10:36] <somerville32> *You're
[10:36] <siretart> do you *feel* yourself ready for ubuntu-dev?
[10:37] <somerville32> siretart: Well, I've never done a merge yet, lol
[10:37] <tsmithe> am i ready for membership?
[10:37] <somerville32> tsmithe: Yes.
[10:37] <tsmithe> ok
[10:37] <somerville32> tsmithe, Whats the link to your wiki page?
[10:38] <tsmithe> hang on
[10:38] <siretart> somerville32: well, then just do some. there are plenty left, I think ;)
[10:38] <somerville32> hehe
[10:39] <somerville32> Ok
[10:39] <somerville32> I'll do some after work tomorrow
[10:39] <somerville32> But I really need to goto bed
[10:39] <siretart> sleep well!
[10:39] <somerville32> It is 5:40am now and I have to go into work @ 11am
[10:39] <persia> somerville32: Better hurry.  At current processing rates, there are only three or four days worth of merges left :)
[10:39] <tsmithe> https://wiki.ubuntu.com/TobySmithe
[10:40] <somerville32> persia: I shall do a whole bunch tomorrow :)
[10:40] <somerville32> persia, siretart: Just upload to revu like normal?
[10:40] <somerville32> (if they are in universe)
[10:40] <siretart> somerville32: catfish looks really lovely
[10:41] <Sp4rKy> hi
[10:41] <persia> somerville32: I open a merge bug, make the merge, post a debdiff to the bug, and subscribe u-u-s.  If you are less confident, REVU also works.
[10:41] <tsmithe> Sp4rKy, hi
[10:41] <somerville32> persia: k
[10:41] <Sp4rKy> i'm trying to use ant.mk, and i don't understand how JAVA_HOME var should be set ?
[10:41] <siretart> somerville32: interested in having it in debian?
[10:42] <somerville32> siretart: Yes, please. It is already in Fedora Core so we gotta get caught up ;] 
[10:42] <somerville32> siretart: The program is actually programmed by a member of the Xubuntu Community too :)
[10:42] <somerville32> I picked the name, haha
[10:43] <siretart> somerville32: are you familiar with the debian new maintainers guide, could you file an ITP for catfish? 
[10:43] <somerville32> siretart: I have never done any work with Debian at all
[10:44] <siretart> somerville32: debian coordinates new packages via bugs. to indicate the intend to package new software, we use so called ITP bugs
[10:46] <somerville32> siretart: Alrighty.
[10:46] <somerville32> I'll look into it after work :)
[10:47] <siretart> somerville32: okay, I installed to package on my debian/etch notebook, seems to work fine
[10:47] <somerville32> Awesome :)
[10:47] <siretart> somerville32: your next step is to file an ITP in the debian bug tracker
[10:52] <gpocentek> somerville32: this tool is the same as the zenwalk one, I am wrong?
[10:52] <somerville32> Yup
[10:52] <somerville32> Search4Files is catfish
[10:52] <gpocentek> why don't we keep the name ?
[10:52] <somerville32> gpocentek, upstream renamed it
[10:52] <gpocentek> ah, ok
[10:55] <somerville32> It is interesting that the 15th most used word in this room is my nick, hehe
[10:57] <Lutin> somerville32: according to the new python policy, you should build-dep-indep on python-support (=> 0.5.3), and not (>= 0.3)
[10:57] <somerville32> link?
[10:58] <somerville32> Because I put 0.3 for pyNeighborhood
[10:58] <somerville32> and it is already uploaded to new
[10:58] <Lutin> somerville32: tou also need a XB-Python-Version: ${python:Versions} field for your binary package
[10:58] <Lutin> somerville32: http://wiki.debian.org/DebianPython/NewPolicy
[10:59] <somerville32> Hmm...
[10:59] <somerville32> What should I do about pyNeighborhood?
[11:00] <persia> somerville32: Upload -0ubuntu2 (if it is indeed broken).  Ad a note in the changelog explaining why.
[11:00] <Sp4rKy> does anyone can say me how i have to set JAVA_HOME in debian/rules ?
[11:01] <somerville32> persia: Isn't broken. Just doesn't comply with policy.
[11:01] <persia> somerville32: There is a difference?
[11:01] <somerville32> persia: The package works regardless ;] 
[11:01] <somerville32> Can't I just ask an archive admin to reject it?
[11:02] <tsmithe> right /me out
[11:03] <persia> Sp4rKy: Take a look at some other Java packages.  If you can find one that builds with Ant even better.  That is probably your best guide.
[11:03] <Sp4rKy> ok
[11:17] <persia> crimsun: You're getting faster every day!  Thanks.
[11:18] <crimsun> the whole sleep thing is overrated when I still have 4000 emails to read
[11:19] <somerville32> Lutin, Ok, re-uploaded catfish :)
[11:19] <persia> crimsun: :)
[11:19] <Lutin> somerville32: great 
[11:22] <somerville32> Wahts with all the extra files?
[11:22] <somerville32> Looks like a build log and stuff
[11:22] <somerville32> http://revu.tauware.de/details.py?upid=4066
[11:24] <somerville32> New upload:
[11:24] <somerville32> http://revu.tauware.de/details.py?upid=4068
[11:24] <somerville32> 4068 should be python policy compliant :)
[11:24] <somerville32> Siretart: ping
[11:24] <crimsun> contentless ping warning.
[11:25] <somerville32> Siretart: ping. ^^
[11:25] <crimsun> contentless ping warning.
[11:25] <siretart> somerville32: manual contentless pong
[11:25] <somerville32> lol
[11:26] <somerville32> siretart: Can you take a look at 4068?
[11:26] <somerville32> I just made a few quick mods to make it python policy compliant
[11:26] <siretart> oh, even better
[11:26] <somerville32> :] 
[11:26] <siretart> I admit that I didn't follow the python policy that close after joss turned into such an moron :/
[11:28] <somerville32> lol
[11:28] <somerville32> Who is joss?
[11:28] <gpocentek> somerville32: you have 2 dh_installman calls in debian/rules :)
[11:28] <siretart> the author of python-support
[11:28] <somerville32> Oh noes :(
[11:28] <gpocentek> somerville32: not a big problem, but... only 1 is nicer
[11:29] <gpocentek> somerville32: FYI CDBS rocks :)
[11:29] <somerville32> haha
[11:29] <somerville32> I'm liking debhelper
[11:29] <somerville32> But I'll have to try CDBS sometime soon
[11:29] <persia> somerville32: Then you haven't played enough with cdbs.  It does it for you (yes, all of it).
[11:30] <somerville32> But I figure if I want to become a dev, I should know debhelper too
[11:30] <gpocentek> somerville32: and it seems that fishcat has several command line option, it'd be nice to have them listed in the manpage
[11:30] <siretart> somerville32: rather get used to debhelper than to cdbs.
[11:31] <gpocentek> options*
[11:31] <somerville32> gpocentek, I just uploaded to revu, lol
[11:31] <somerville32> I guess I could add them but I need to get to bed
[11:31] <siretart> somerville32: cdbs is great for packages with a 'standard' build system. if you need to customize things, cdbs gets a hell quickly
[11:31] <siretart> since there is nearly zero real dokumentation
[11:32] <gpocentek> oops s/fishcat/catfish
[11:33] <somerville32> hehe
[11:33] <somerville32> Is there any funky manpage magic I should use?
[11:34] <somerville32> Or can I just plop it in
[11:37] <persia> I've never seen MoM get it so wrong.  aqsis available.
[11:39] <crimsun> bah, over 2 minutes.
[11:40] <crimsun> nah, I'm referring to my lag time
[11:40] <crimsun> I don't think I can break 2 minutes between the debdiff posting and the dput
[11:41] <persia> crimsun: I think you'd need a script.
[11:41] <crimsun> unfortunately doesn't seem scriptable due to LP lag time
[11:42] <crimsun> meaning "yes, it's certainly scriptable, but it won't break 2 minutes"
[11:42] <persia> How long does LP sit on it before allowing others to download it?
[11:42] <crimsun> not very long, but I'd still have to poll the page or wait for an email
[11:45] <persia> crimsun: Right, I forgot about the email.  With that duration included, 2 minutes astonishes me - I often have to wait 5 or more minutes for notice.
[11:49] <crimsun> oh geez, that was a bad misparse (for some reason I misread < as << on the page, which is my cue to go to bed)
[11:52] <persia> crimsun: Sleep well.
[01:06] <zorglu_> q. when i do "dpkg --build debian/tmp ../debian_package" in one of my 'rules', i got "dpkg-genchanges: failure: cannot open upload file ../mypackage.deb for reading: No such file or directory"
[01:07] <zorglu_> but i could swear my package building script worked before. (how many time i have heard that from other :)
[01:07] <StevenK> Why not just use dh_builddeb?
[01:07] <zorglu_> any suggestion on a fix ?
[01:08] <zorglu_> because i failed to understand what they do when i looked. sparse doc and unable to find the code, are the reasons i remember
[01:09] <StevenK> Change it to dpkg-deb -b debian/tmp, it should figure out the archive name on it's own, and double check everything is installing into debian/tmp
[01:09] <zorglu_> how do i specify the destination directory of the built pacakge ?
[01:10] <StevenK> Just put .. then
[01:11] <StevenK> dpkg-deb -b|--build directory [archive|directory] 
[01:12] <zorglu_> it is what i have in fact :)
[01:12] <zorglu_> the weird thing is that the ../debian_package/mypackage.deb got created
[01:12] <zorglu_> only the dpkg-genchanges fails to find it
[01:13] <zorglu_> maybe dpkg-deb --build fails to give it the destination directory ?
[01:14] <zorglu_> dpkg-genchanges: failure: cannot open upload file ../mypackage.deb <- it does get the "debian_package" direcotry specified in the dpkg-dev
[01:14] <zorglu_> b
[01:14] <StevenK> Hrm
[01:14] <zorglu_> and if i put "dpkg-deb --build debian/tmp .." it works ok
[01:15] <StevenK> Neat .
[01:15] <zorglu_> but not if i put "dpkg-deb --build debian/tmp ../debian_package", i mean, genchanges fails vbut the .deb is created
[01:16] <highvoltage> 4
[01:16] <StevenK> More than likely, you're not making a .deb that genchanges is expecting.
[01:16] <zorglu_> yep, genchanges make this clear :)
[01:16] <zorglu_> dpkg-gencontrol may be my mistake
[01:17] <zorglu_> i dunno :)
[01:18] <zorglu_> well i found it very hard to use when i tried :)
[01:20] <StevenK> debhelper so isn't very hard. :-)
[01:21] <zorglu_> lack of documentation forces me to try to analyse their source to understand what they did and i failed to find the source :)
[01:22] <StevenK> All of the debhelper commands are in /usr/bin
[01:22] <zorglu_> ok the dpkg-deb produces a simple "dpkg-genchanges -B" wihtout my destination directory
[01:22] <StevenK> dpkg -L debhelper would have told you that
[01:22] <zorglu_> this is the cause of the trouble, dpkg-genchanges assume a ".." destination directory
[01:24] <zorglu_> well it was my first packaging, so i may have done a lot of mistake :)
[01:25] <StevenK> There's a debhelper tutorial around, that should have gotten you through it
[01:25] <StevenK> Oh, and examples: /usr/share/doc/debhelper/examples/rules.indep 
[01:25] <persia> zorglu_: man dh_<whatever> can also be very helpful.
[01:26] <zorglu_> ok trying to fix with debhelper :)
[01:26] <zorglu_> which doesnt do much good :)
[01:27] <zorglu_> dpkg-genchanges -B <- it is exactly the same genchanges which is outputed
[01:27] <zorglu_> so the destination directory is not really supported ?
[01:28] <StevenK> A destination directory of .. the default
[01:28] <StevenK> s/the/is the/
[01:28] <zorglu_> yep, with ".." it works, with "../debian_package" the .deb is created but genchanges still assume ".."
[01:30] <zorglu_> what i dont understand is how come this script worked before :)
[01:30] <zorglu_> well anyway i need to modify the script to get a workaround
[01:31] <StevenK> dpkg-genchanges -u
[01:31] <StevenK> Reading the manual page for dpkg-genchanges could have told you that.
[01:31] <StevenK> dpkg-genchanges -u<dir>
[01:34] <zorglu_> i got like 6 .deb to generate, i didnt want to put them in the ".." because i didnt want to put them all in the ".." and have this directory "bloated" will all my .deb/.changes of all version, hence my creation of a "../debian_package" for that
[01:34] <zorglu_> StevenK: i saw this one, but how to set this in the dpkg-deb or dh_buildeb ?
[01:35] <zorglu_> oh builddeb allow some, lets try :)
[01:37] <zorglu_> ok lets give up this idea of destination directory :)
[01:38] <zorglu_> btw dh_builddeb allows to send option to dpkg-deb but dpkg-deb doesnt allow to send option to dpkg-genchanges
[01:39] <persia> zorglu_: dpkg-genchanges doesn't support the option.
[01:39] <StevenK> dpkg-genchanges does
[01:39] <StevenK> dpkg-deb doesn't pass it on, as it were
[01:40] <zorglu_> so how do you guys handle this ?
[01:40] <zorglu_> you put everything in ".." and got a ".." with many .deb/.changes ?
[01:41] <StevenK> I use ppbuilder, annd that puts everythhing in /var/cache/pbuilder/result
[01:41] <StevenK> s/ppbuilder/pbuilder/
[01:41] <Amaranth> Some people have a build dir
[01:41] <zorglu_> pbuilder was on my todo list :)
[01:41] <zorglu_> Amaranth: ahhh :)
[01:41] <StevenK> Heh
[01:42] <zorglu_> and this ~/debian got a lot of .deb/.changes in it
[01:42] <zorglu_> and you dont care as it is all handled by pbuilder :)
[01:43] <zorglu_> ok so i need a workaround and the ".." will do it for now :)
[01:43] <Amaranth> you have to build it once to get a dsc file to run through pbuilder
[01:43] <zorglu_> well im a beginer and i dunno what the .dsc file is :)
[01:43] <zorglu_> nor the .changes file :)
[01:43] <zorglu_> nor a lot of other things :)
[01:44] <StevenK> Amaranth: Or use pdebuild
[01:44] <Amaranth> StevenK: ooh
[01:44] <Amaranth> learn something new every day
[01:44] <StevenK> And generating a .dsc is a matter of dpkg-source -b
[01:44] <Amaranth> yeah but i build it once anyway
[01:45] <Amaranth> no need to waste a pbuilder run if it's not going to compile
[01:45] <Amaranth> pbuilder is slow to setup/teardown
[01:46] <zorglu_> oh i got one solution :) "copy all my script and directory in a temporary dir, have it built there, and then copy only the .deb in my destination directory" :)
[01:46] <StevenK> Not with a local miirror. :-)
[01:46] <zorglu_> maouaouaoua
[01:46] <geser> some packages started to mangle the Maintainer field in the source package. shouldn't the Original-Maintainer field be visible when doing apt-cache showsrc?
[01:47] <StevenK> geser: If Launchpad exports it to the Sources.gz
[01:47] <persia> geser: That's an excellent reason to process this field.  Please update bug 78879 with your reasoning.  I'd be happy to make a patch for your desired behaviour (if you could describe it in some length).
[01:47] <Ubugtu> Malone bug 78879 in dpkg "dpkg doesn't support the Original-Maintainer field" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78879
[01:49] <Sp4rKy> is there anyone who know what i have to include in control/rules files to avoid getting this error "java.lang.NoClassDefFoundError: com.sun.tools.xjc.reader.xmlschema.parser.SchemaConstraintChecker" during build ?
[01:50] <StevenK> A Build-Depend?
[01:51] <Sp4rKy> StevenK: i think, but i really don't know what
[01:56] <persia> siretart: I was planning a merge of debian-reference (to 1.10).  Do you have any comments or suggestions before I begin?
[01:59] <white> this mail might be of some interest, at least I would appreciate some feedback from ubuntu folks
[01:59] <white> http://lists.alioth.debian.org/pipermail/utnubu-discuss/2007-January/000539.html
[02:04] <azeem> white: good idea
[02:04] <persia> white: I'm not authoritative, but if the Utnubu team would be willing to support and assist Ubuntu developers working with Debian, it may well be a better contact point to put on the Wiki, etc.  MOTU topics are generally discussed on ubuntu-motu@lists.ubuntu.com, although Ubuntu doesn't use mail nearly as much as Debian (IRC, the Wiki, and Launchpad are primary communication media).
[02:05] <white> persia: yes i thought about that, i am not quite sure about the rest of the team, so i am waiting for some feedback and i do not have any clue about how many MOTUs would want to write to that
[02:06] <white> because if there are 100 MOTUs writing there, but only 2 DDs helping out it might be a bit of a problem :)
[02:06] <white> though it is worth trying it out i guess
[02:06] <geser> StevenK: isn't the Sources-file generated from the .dsc files? if so the Original-Maintainer should also be there and we should add XS-Original-Maintainer to the contol file?
[02:06] <zorglu_> btw is there one of those distro agnostic packaging system (e.g. klick or autopackage or other) which is accepted by default on ubuntu ?
[02:07] <Adri2000> geser: I'm not really conviced of the way to handle that Maintainer field problem, isn't it possible to do that (move Maintainer to Debian-Maintainer and put Ubuntu Developers as Maintainer) automatically, just after the upload and before it hits archive.u.c?
[02:07] <geser> not in the .dsc file as this would break the signature
[02:08] <Adri2000> s/Debian-Maintainer/Original-Maintainer/
[02:08] <Adri2000> hmm
[02:08] <persia> geser: Why XS-Original-Maintainer?
[02:09] <geser> persia: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
[02:09] <geser> if I understand it correctly
[02:09] <geser> Adri2000: for binary packages this is already done on package build
[02:09] <Adri2000> I know
[02:10] <Adri2000> and I was wondering why it was not possible to do the same for source packages
[02:10] <azeem> is it really important to have this for source packages?
[02:11] <persia> geser: Your understanding matches mine, but I was told to follow https://wiki.ubuntu.com/FeistyReleasePlan ("Original-Maintainer") when I asked mdz if the packages should be changed,  and https://wiki.ubuntu.com/DebianMaintainerField calls for "X-Original-Maintainer".
[02:13] <geser> Adri2000: because of the .dsc file which is gpg signed by the uploader, if you modify the .dsc file you either break the gpg signature or have to re-sign it
[02:14] <Adri2000> geser: ok, I understand now
[02:19] <geser> persia: do you know if X-O-M ends in the .dsc? IMHO if we preserve it in a extra-field it should be visible in the .dsc
[02:20] <persia> geser: Building now to check...
[02:23] <persia> geser: No (although this might be another reason to parse the field).
[02:24] <persia> geser: Nevermind.  That was O-M.  Hold on...
[02:25] <persia> geser: Neither O-M nor X-O-M are passed to the .dsc.
[02:28] <zorglu_> btw is there one of those distro agnostic packaging system (e.g. klick or autopackage or other) which is accepted by default on ubuntu ?
[02:28] <azeem> what do you mean "by default"?
[02:28] <Lathiat> zorglu_: if you mean into the ubuntu archives, then no
[02:29] <persia> geser: XS-O-M does the right thing for .dsc (are my patches then incorrect?).
[02:29] <zorglu_> Lathiat: nope, i mean as in installed by default, so user can install those package easily
[02:30] <zorglu_> azeem: by default as in i install the cd and i got the support for this packaging system
[02:31] <persia> geser: Furthermore, should we use XBS-O-M, as pkgmaintainermangler will likely ignore the package due to the @ubuntu,com in the maintainer field?
[02:34] <geser> persia: yes, you are right, it should be XBS-O-M
[02:37] <persia> Well then, I'm glad I had a slow couple days.  There are only a few packages in which I put the wrong value.  What's the best way to provide a reference for this?  Update the spec?  Add a new wiki page?
[02:41] <geser> persia: I would suggest to ask mdz about it and update the wiki page than and perhaps an e-mail with the updated info to u-d-a
[02:42] <persia> geser: I can at least take care of the first two.  Thanks for the guidance.  I'll stop patching for a while :)
[03:02] <siretart> persia: IIRC, there was a (build-)dependency missing when I was about to merge it. otherwise I *think* a sync should be fine.
[03:04] <persia> siretart: I think Debian still doesn't have a .desktop file (checking now).
[03:06] <Adri2000> does someone plan to write an update-maintainer-field script?
[03:07] <persia> Adri2000: Hold on :)  The correct values for use remain uncertain...
[03:08] <StevenK> And it's a one liner in sed ...
[03:10] <persia> siretart: It still waits for latex-cjk-chinese-arphic-bsmi00lp, and needs a merge for the .desktop file.
[03:10] <Adri2000> StevenK: with check to see if it's an ubuntu package (check if the version contains ubuntu)? check to see if it's main or universe? etc... maybe a long line :)
[03:12] <Adri2000> also check if the original maintainer has an @ubuntu.com email
[03:12] <persia> dh_maintainermangle could do all that (and more).
[03:12] <siretart> persia: ah, that'll be it
[03:12] <StevenK> persia: Why would a debhelper program play with the source?
[03:13] <geser> and why on every package build?
[03:13] <persia> siretart: Sorry to bother you then: I'm just trying to ping last uploaders when I see them online before I download and start the merge.  Thanks for saving me the effort of discovering this on my own (halfway through).
[03:15] <persia> StevenK: You're right.  I misread "common tasks related to building debian packages" as "common tasks related to debian packages".
[03:17] <siretart> persia: you are perfectly right doing this!
[03:19] <geser> Adri2000: you could patch pkgmaintainermangler (from pkgbinarymangler) to modify debian/control
[03:24] <Adri2000> Lutin is writing something
[03:25] <Lutin> he means, a quick hack ^^
[03:26] <geser> Lutin: I shouldn't be to hard to modify pkgmaintainermangler to modify debian/control
[03:27] <geser> or at least look at the overrides file from it
[03:27] <Lutin> geser: I don't have much time to dig this, but maybe you're right
[03:32] <somerville32> http://revu.tauware.de/details.py?upid=4069 <-- :)
[03:32] <persia> StevenK: As I'm postponing more merges until I have instructions, I don't support you'd like to discuss your .desktop/menu issue?
[03:33] <StevenK> persia: No, sorry, I'm just about to go sleep
[03:33] <persia> s/support/suppose/
[03:33] <persia> StevenK: No worries.
[03:41] <persia> somerville32: Your menu file doesn't have an icon.  For some reason, I am forbidden to view the ,desktop, but from the directory listings, I'm guessing there's not one there either.  Does upstream not provide anything?  Even something from which an icon could be cut or cropped?
[03:42] <somerville32> persia: I do have an icon I could use but it isn't from upstream. Furthermore, the .desktop does use an icon.
[03:50] <persia> somerville32: I found it (I like icons in /usr/share/pixmaps),  You may still want to make a local catish.xpm (installed into /usr/share/pixmaps) by converting system-search.png (32x32) for reference in the menu file (Add Icon="full-path").
[03:50] <persia> s/catish/catfish/
[04:09] <Adri2000> Lutin's script is here! http://pastebin.ca/315348
[04:13] <Lutin> and Lutin's script has a typo
[04:14] <persia> Lutin: Nice.
[04:14] <Lutin> persia: here it is actually: http://pastebin.ca/315356
[04:15] <persia> Lutin: Ah.  That actually replaces :).  I'm adding this to ~/bin.  Thanks.
[04:16] <geser> Lutin: there are some more exceptions for the mangling
[04:17] <Lutin> geser: for sure. I'd be happy to know them, so I can add them
[04:19] <geser> Lutin: see http://pastebin.ca/315363 for the config file for the maintainer mangler
[04:20] <geser> you are at least missing canonical.com and ubuntu.com.au
[04:20] <bddebian> Heya gang
[04:21] <persia> hi bddebian.
[04:21] <bddebian> Heya persia
[04:24] <ScottK> heya bddebian
[04:25] <ScottK> I think I'm ready for you to look at the package again, but after last night's fun I'm (almost) afraid to ask. http://revu.tauware.de/details.py?upid=4064
[04:25] <bddebian> Heh
[04:26] <bddebian> ScottK: Yeah, give me a bit
[04:26] <ScottK> Thanks.
[04:28] <persia> ScottK: Just for fun, you may want to change "This may be to short..." to "This may be too short..." in the manpage :)
[04:30] <Lutin> geser: is adding the exceptions worth it, I mean if there are plans to handle it on buildd for ex, I won't bother with it
[04:30] <Lutin> ?
[04:32] <geser> Lutin: it's not that straightforward to modify the maintainer of a source package on the builds, as this breaks the gpg signature in the .dsc file
[04:32] <Lutin> geser: hum, you're right
[04:32] <ScottK> persia: This leads to a philosphical question...  I made the man page from the upstream README.  That same spelling error is present there.  Should I fix the spelling error both places for enhanced correctness, fix it only in the man page to keep the diff small, or fix it not at all for consistency with upstream documentation?
[04:33] <persia> ScottK: For myself, I'd fix the spelling, and send a bug to upstream.
[04:33] <geser> Lutin: if it would be possible, I'd assume it would be already happening for source packages also
[04:34] <persia> Lutin: I've added the exceptions locally, if you have yet to do so.
[04:35] <Lutin> geser: ya, think so
[04:35] <Lutin> persia: can you pastebin the changes, so I can add them to the script ?
[04:36] <persia> Lutin: patch at http://pastebin.ca/315380
[04:37] <Lutin> ok persia, thanks :)
[04:37] <persia> I'm fairly certain that will also catch lists.*
[04:42] <ScottK> bddebian: I'm going to fix persia's typo, so on the off chance you are going to advocate my package, I'd prefer you do it to the next rev.  I'll post the url here when it's up.
[04:51] <ScottK> persia: Your reviews have been very helpful.  The next package I am working on is http://revu.tauware.de/details.py?upid=4053.  In this one the upstream mentions the licenses and gave urls, but didn't include license text.  It was bounced from NEW because of this.  The advice I got from Tollef was to rebuild orig.tar.gz adding the text since upstream declined to do a new release for this.  If you have time, I'd appreciate
[04:51] <ScottK> aming right when I rebuilt the orig.tar.gz.
[04:51] <bddebian> ScottK: OK
[04:52] <ScottK> bddebian: Here it is. http://revu.tauware.de/details.py?upid=4070
[04:53] <persia> ScottK: These are extremely long package names.  Users are going to hate typing them :)
[04:54] <ScottK> They should never have to type it.
[04:54] <ScottK> This is a dependency for another package that comes later.
[04:54] <Lutin> geser: does it look ok to you: http://dunnewind.net/~lutin/resource/update-maintainer ?
[04:54] <ScottK> Upstream put it out as a separate package only because it may be useful for other things.
[04:55] <ScottK> The upstream is also working on getting this into Debian and that's the package name he's using there, so I think it's important to be consistent.
[04:55] <ScottK> But, I agree.  It's an extremely long package name.
[04:57] <persia> ScottK: Your first changelog doesn't need to be so specific.  Intiial release is likely sufficient, although it doesn't hurt to follow the practice of documenting everything.
[04:58] <ScottK> Thanks.  Another philosphical question: Upstream provides a /debian directory and most of that is from the upstream.  Is it better to delete it or leave it when it's not necessary?
[04:59] <ScottK> Given I'd already rebuilt orig.tar.gz for this package I decided to change as little else as possible.
[05:00] <persia> ScottK: To reduce confusion, I'd change the license paragraph to "This is free software.  You may use, modify, and distribute it under the terms of either the GNU General Public License (version 2 or later) or the Artistic License.", as the terms don't really match perl's (except in spirit).  On the other hand, I've never written a copyright file, so I'm probably weakest here.
[05:00] <ScottK> Which file are you in?  That shows up more than one place?
[05:01] <persia> ScottK: If the upstream debian/ helps you, leave it.  If it doesn't, remove it.  From my memory of old mailing list discussions, it is generally annoying a few versions down, when upstream makes some change you didn't expect.
[05:01] <geser> Lutin: looks ok for a quick hack :)
[05:01] <Lutin> geser: feel free to test it extensively, I don't really have the time to do it
[05:01] <Lutin> geser: espacially the ignore list and the multi-domains selections
[05:02] <persia> ScottK: I was looking at debian/copyright.  LICENSE seems to indicate these are the same terms as perl, which I don't think is true.
[05:02] <ScottK> No, it's not the same terms.  PERL is GPL v1 too.
[05:02] <geser> Lutin: will do, once it's clear if the field should be Original-Maintainer, XBS-O-M or something else
[05:03] <persia> Lutin: You may wish to move the domains to a variable as well, for improved readability.
[05:03] <ScottK> The feedback I got from Tollef indicated to me that once the actual licenses that were applicable were added, he was OK with that.
[05:03] <Lutin> persia: true, but I'd like to be sure it actually works before cleaning up ^^
[05:04] <Lutin> 1/ make it work flawlessly, make it really clean is extra for the moment :] 
[05:04] <persia> ScottK: That's the person to convince, so if you have already received word that that language is correct, ignore me.
[05:05] <persia> Lutin: understood.  I'll start testing as soon as the decision is published, and let you if I encounter any issues.
[05:05] <ScottK> It was more like didn't object to the revised wording when I e-mailed him back after he bounced it the first time.
[05:06] <Lutin> persia: ok, tested the ignore domains regexp, seems to be ok so moving to a var :)
[05:07] <persia> ScottK: The contents of README.Debian do not appear useful to the average administrator.  I know I at least look at that file whenever I want to understand what something does.  I might move that to README.Packaging, and make sure it didn't get included in the binary deps.
[05:08] <Lutin> persia: have a look at http://dunnewind.net/~lutin/resource/update-maintainer and tell me if it's ok for ya :)
[05:10] <ScottK> Here: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz is says README.Debian-source (I didn't find this before).  Does that sound right?
[05:11] <persia> Lutin: You might use main|restricted) and universe|multiverse) to make it even shorter, but it looks nice.  I'm just not sure about the 3rd from last line.  Thanks a lot for this, it should make things easier.
[05:12] <persia> ScottK: That sounds exactly right.
[05:12] <ScottK> persia: BTW, for the perl-policy thingy I have upstream commit rights for the svn, so I didn't write I bug, I just fixed it.
[05:12] <ScottK> Thanks.  I'll go do that.
[05:12] <Lutin> persia: the line that actually replaces the maintainer .
[05:12] <Lutin> ?
[05:12] <persia> ScottK: When you're upstream, you get all the fun :)
[05:13] <ScottK> Yeah.  The fun part on that is I'm upstream only after the last release (for about 4 days now).
[05:13] <persia> Lutin: Yes, it's whether it should be "...\nOriginal...", "...\nXBS-Original..." or something else.
[05:14] <ScottK> When I was working on packaging I whined about some stuff and the response I got was, OK, then you maintain it...
[05:14] <Lutin> persia: yep, but as far as we don't know, I can't put voodoo in the script to determine it :] 
[05:16] <persia> Lutin: My apologies.  I didn't mean that.  To rephrase, except for the part for which the requirements have yet to be defined, it appears that this application meets current expectations for the user community :)
[05:16] <ScottK> I'm going to clarify debian/copyright too while I'm at it.
[05:17] <Lutin> persia: hehe, np. thanks :)
[05:20] <ScottK> persia: Thanks for the help.  Is there anything else before I upload again or are you still looking?
[05:20] <persia> ScottK: still looking
[05:20] <ScottK> OK.  Thanks.
[05:23] <persia> ScottK: README (not Debian) could use some grammar help.  I'm guessing you don't want to take that upstream?
[05:24] <ScottK> Not today.  English is not the first language of the upstream.
[05:24] <ScottK> His English is very good (far better than my German, so I shouldn't complain).
[05:24] <persia> ScottK: In that case, better to leave as-is: carrying that in a dpatch would be unpleasant :)
[05:24] <ScottK> I will work on that with him for the next release though.
[05:25] <Lutin> geser: when will know what field we have to use for the debian maintainer ?
[05:25] <persia> ScottK: TODO seems fairly useless in this version.  Are you sure you want to include it in debian/docs?
[05:26] <ScottK> Agreed.  I'll remove it.
[05:26] <geser> Lutin: when mdz answered persia's inquiry
[05:27] <persia> ScottK: debian/control: s/virtual DNS/virtual DNS server/ (Domain Name Service).  s/the real DNS/a real DNS server/. (Short description is fine).
[05:28] <persia> ScottK: That's all I see.
[05:28] <Lutin> geser: ok
[05:29] <persia> geser: Are you in a timezone where you are up for a while?  I'd like to sleep, and I think my query will not be answered soon :(
[05:29] <geser> persia: I'm in Europe, do you know which timezone mdz is in?
[05:30] <Adri2000> Timezone:  America/Los_Angeles
[05:31] <persia> geser: No.  He seems to move around.  If he responds before I am active again, would you mind confirming anything that remains vague?  I'll check the backlog when I come back, but don't want to miss the opportunity to find sufficient answers that I can resume merging without further embarassment.
[05:31] <geser> persia: sure, will do
[05:32] <persia> geser: Thanks.
[05:32] <Lutin> hehe, g'night persia
[05:33] <ScottK> Thanks persia.
[06:04] <Lutin> ajmitch: are you around ?
[06:23] <synic> where can I see a list of packages that will be in fiesty?
[06:23] <synic> ... or are already in 
[06:23] <geser> in the Packages file for feisty
[06:24] <synic> there's no list in launchpad somewhere?
[06:46] <Lure> when packaging new upstream, are you supposed to recompress the orig.tar.gz with --best or should we leave it as original?
[06:47] <fdoving> don't touch it, if you don't need to.
[07:10] <geser> Lutin: I've modified the pkgmaintainermangler to modify source packages: http://members.ping.de/~mb/srcmaintainermangler/
[07:21] <Lutin> geser: what's the pkgmaintainermangler used for ?
[07:23] <geser> that's the script the buildds are running to modify the maintainer in the binary debs
[07:23] <Lutin> uh ok
[07:26] <Lutin> geser: cool nice job
[07:31] <Lutin> geser: so, the field will be XBS-Original-Maintainer, or you chose for lack of an actual name ?
[07:38] <geser> Lutin: I chose it until a decision is made
[07:38] <geser> this way O-M will end in the dsc and the debs
[07:41] <Lutin> geser: cool
[07:44] <Lutin> geser: just curious, why did rewrite a whole script ?
[07:44] <geser> most parts where there already
[07:45] <Lutin> ok
[07:45] <geser> all I had to add was to modify the correct file (debian/control instead of DEBIAN/control) and termine the component
[07:45] <geser> and also modify control.in if it exists
[07:46] <Lutin> oh, ok :). I didn't even know pkgmangler existed until today :)
[07:50] <geser> if I would check if the first changelog entry is already for ubuntu I could determine the correct distribution and lookup the correct component (it might have changed between edgy and feisty)
[07:54] <Laser_away> geser: what is it creating? Original-Maintainer: ?
[07:54] <Lutin> geser: quite easy to do :)
[07:54] <geser> Laser_away: it writes XBS-Original-Maintainer into the control file which results in Original-Maintainer in the dsc and debs
[07:55] <geser> Lutin: already working on it :)
[07:55] <Laser_away> geser: where did you get the XBS part from?
[07:55] <Lutin> hehe, kewl
[07:56] <geser> Laser_away: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7
[07:57] <Laser_away> geser: ah, awesome. I always wondered how they chose those
[08:00] <geser> Laser_away: when you look at "apt-cache showsrc xdelta" you will see that O-M is missing
[08:01] <geser> but is in the control file as O-M (without the XBS)
[08:02] <geser> do you know if O-M should also appear in the dsc files?
[08:06] <Laser_away> geser: xdelta has O-M in debian/control?
[08:08] <geser> Laser_away: yes, see http://librarian.launchpad.net/5722532/M79021.patch or the complete diff.gz
[08:09] <Laser_away> geser: bah, this is getting sort of messed up
[08:10] <Laser_away> geser: they should have gotten that spec implementation down better before expecting us to do it
[08:10] <Laser_away> on thousands of source packages
[08:12] <geser> Laser_away: persia tried to ask mdz if O-M is correct or if it should be XBS-O-M, X-O-M or something else
[08:12] <geser> but apparently he wont get an answer before monday
[08:20] <ScottK> If there is a MOTU available and willing, I'd appreciate REVU on two packages, especially http://revu.tauware.de/details.py?upid=4070 and perhaps http://revu.tauware.de/details.py?upid=4071.
[08:24] <vil> hi, i am experimenting with bzr maintained packaging and have question regarding it
[08:25] <vil> i am trying to get rid of precompiled jars from the source so i replace the original file with a symlink
[08:26] <vil> however then dpkg-source complains about unrepresentable change to the source.
[08:26] <Lutin> ajmitch: ping -> could you have a lokk at bug 65894 ?
[08:26] <Ubugtu> Malone bug 65894 in lablgtk "FTBFS in edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/65894
[08:26] <vil> is there any chance to get pass this?
[08:29] <mr_pouit> ScottK, I am not a MOTU, but it seems that libnet-dns-resolver-programmable-perl orig tarball ships a debian/ dir. You should ask upstream to remove it (diff.gz will be more clear and it is easier for you to maintain)
[08:29] <ScottK> I've asked.  They said no.
[08:30] <mr_pouit> oh :/
[08:31] <ScottK> They are open to feedback, so I have hope...
[08:45] <Laser_away> geser: I think we better not do any Original-Maintainer uploads until we get that resolved
[08:52] <bddebian> Laser_away: I think felt is going to need to be dropped from the archive :(
[08:52] <Laser_away> bddebian: how come?
[08:54] <ScottK> bddebian: Did you ever get a chance to look at http://revu.tauware.de/details.py?upid=4070?
[08:54] <bddebian> Laser_away: It's been dropped from Debian, hasn't been updated upstream since 2000 and doesn't build with libglu1-mesa-dev
[08:55] <bddebian> ScottK: Not yet, sorry.  I started to look at it then I saw you and persia talking back and forth so I stopped
[08:55] <Lutin> ScottK: maybe you should move the upstream/ debian to debian.upstream and put your packaging in debian/
[08:55] <ScottK> No problem.  It's ready whenever you are.
[08:56] <ScottK> Lutin: The upstream is working on getting the packages into Debian, so there is value, I think, in keeping his and pushing the changes back up to him.  Less suprise once Debian adopts it.
[08:57] <Lutin> ScottK: oh, indeed
[08:58] <neutrinomass> https://launchpad.net/ubuntu/feisty/+source/libzrtpcpp shows that libzrtpcpp has not been built on i386, which contradicts https://launchpad.net/+builds/+build/274428 . libzrtpcpp is needed as build-deps to twinkle and it doesn't seem to exist for i386
[09:02] <crimsun> neutrinomass: there's no contradiction
[09:02] <crimsun> the UI on the first link doesn't make it immediately obvious that it /has/ built, but there's no contradiction
[09:03] <neutrinomass> crimsun: well, yes, it doesn't state that it has not built... any ideas as to why I can't see it in the repos then? 
[09:09] <crimsun> hmm, possible soname issue?
[09:09] <crimsun> please file a sync request for libzrtpcpp and let me know the bug #
[09:09] <crimsun> you may need to walk the stack for http://packages.qa.debian.org/libz/libzrtpcpp/news/20070107T084703Z.html
[09:10] <neutrinomass> Ok. Sync for 0.9.0-3 ... 
[09:10] <crimsun> in any case, you'll need ubuntu-archive's involvement (whether it's to further debug why the i386 deb doesn't appear and/or the sync req)
[09:12] <neutrinomass> crimsun: How does the sync make a difference? (besides being an attempt to rebuild)
[09:12] <crimsun> there's no way to tell until you try it
[09:12] <crimsun> if it sbuilds fine, then it's an archive problem
[09:13] <ajmitch> morning
[09:13] <Lutin> morning ajmitch
[09:13] <crimsun> morning
[09:13] <ScottK> Good morning.
[09:14] <zul> hey ajmitch 
[09:19] <bddebian> Heya ajmitch, crimsun
[09:23] <crimsun> 'lo bddebian 
[09:24] <ScottK> bddebian: Thanks for the REVU.  re your comment: http://revu.tauware.de/details.py?upid=4070 I don't think the package is contentious as much as I've made a number of small mistakes along the way (my inexperience is showing).  I think it's finally good and so now all I need is one more...
[09:25] <bddebian> ScottK: Well you have been beaten up more than most I think for some reason
[09:25] <ScottK> It's OK.  It's been a good learning experience.
[09:26] <ScottK> I plan to do more of this, so it's all good.
[09:26] <ScottK> Anyone availble to look to be a second advocate?
[09:27] <lritter> hello there
[09:27] <lritter> where do i request inclusion of llvm-1.9?
[09:27] <ScottK> bddebian: If you are still up for more REVU, I believe that http://revu.tauware.de/details.py?upid=4071 is ready for a look.  Appreciate all the help so far.
[09:27] <neutrinomass> crimsun: bug 79126
[09:27] <Ubugtu> Malone bug 79126 in libzrtpcpp "Please sync libzrtpcpp 0.9.0-3 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79126
[09:28] <bddebian> ScottK: I'll probably be doing quite a bit tonight during the Eagles game
[09:29] <Lutin> ajmitch: could you have a llok at bug 65894 ?
[09:29] <Ubugtu> Malone bug 65894 in lablgtk "FTBFS in edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/65894
[09:29] <crimsun> neutrinomass: please do not subscribe ubuntu-archive yourself
[09:29] <ScottK> OK.  I'd appreciate it if you put that one on your list.  It's got a rebuilt orig.tar.gz in response to Tollef bouncing it from NEW because of no LICENSE file.  I think I did it right, but...
[09:30] <neutrinomass> crimsun: sorry, I thought it was standard practice
[09:30] <ScottK> bddebian: I did get feedback from Tollef saying I should rebuild orig.tar.gz.  My concern is did I do it right.
[09:30] <Toadstool> heya everybody!
[09:30] <bddebian> ScottK: NP
[09:30] <bddebian> Heya Toadstool
[09:31] <Toadstool> hey bddebian 
[09:31] <crimsun> neutrinomass: no, a member of ubuntu-dev will ACK your sync request and then sub u-a
[09:32] <crimsun> neutrinomass: for instances such as this one where the Debian component was missing, it helps prevent additional notifications from spamming the inboxes of u-a members
[09:33] <crimsun> hmm, where is Stefan?
[09:34] <neutrinomass> crimsun: Yes, sorry, I was blindly following https://wiki.ubuntu.com/DeveloperResources which doesn't really mention it. Thanks for catching it.
[09:34] <Adri2000> sharms: can I merge lighttpd?
[09:34] <Adri2000> erkkk
[09:34] <Adri2000> shawarma: can I merge lighttpd?
[09:36] <crimsun> hmm, n/m wrt Stefan; reading Debian 402715 clarified.
[09:36] <Ubugtu> Debian bug 402715 in gnome-hearts "gnome-hearts crashes on startup" [Grave,Closed]  http://bugs.debian.org/402715
[09:51] <somerville32> crimsun: Can you review http://revu.tauware.de/details.py?upid=4069 for me? :)
[09:52] <crimsun> < crimsun> ok, I'll look when I finish my alsa triaging work.
[09:52] <crimsun> < crimsun> ETA: a couple hours
[09:52] <crimsun> nixternal: conexant patches merged into BenC's tree
[09:52] <somerville32> Toadstool: Are you available? :)
[09:56] <Toadstool> somerville32: yep
[09:57] <somerville32> Toadstool, http://revu.tauware.de/details.py?upid=4069 :)
[09:57] <Toadstool> ok
[10:38] <Lure> any motu around to check and upload new upstream version of soundkonverter: http://revu.tauware.de/details.py?upid=4072
[10:44] <geser> Lure: I'm seeing it right that it doesn't need two advocates?
[10:45] <bddebian> Not if it's already in the archive
[10:45] <Lure> geser: it is in archive, just new upstream
[11:19] <persia> good morning
[11:20] <geser> hello persia 
[11:20] <persia> Monday, eh?  Oh well.
[11:20] <geser> just a guess
[11:22] <geser> if you are interested: I've modified the pkgmaintainermangler script used by the buildds to work on source packages: http://members.ping.de/~mb/srcmaintainermangler/
[11:25] <persia> geser: That looks more robust, but it's definitely a lot wordier and harder to grasp in a glance than Lutin's.
[11:27] <persia> geser: Lutin: What about adding `dch Modified Maintainer values to match Debian-Maintainer-Field spec` to the script to save that step as well?
[11:28] <Lutin> persia: the point is, the script assumes it was already dch'ed
[11:29] <Lutin> because in case you're modifying a synced package, you need to dch before running the script so that the ubuntu field in changelog can be detected
[11:31] <persia> Lutin: I'm just imagining the case where hundreds of -*ubuntu* packages need to be modified to suit in late April or early May, but I suppose it can be a two step process (like dh_iconcache was), which ensures the appropriate human oversight.
[11:32] <Lutin> persia: yes, I think it'd be better to do it in two steps
[11:43] <Lutin> persia: all the pkges will have to be changed for feisty +1 ?
[11:45] <persia> Lutin: https://wiki.ubuntu.com/FeistyReleasePlan indicates that all the packages will have to be changed for feisty.
[11:45] <persia> Lutin: That's modified packages only.  Sync packages stay the same.
[11:45] <Lutin> persia:ok
[11:46] <Lutin> persia: but if you fix a bug in a sync package, you'll also have to do it, right ?
[11:47] <persia> Lutin: My understanding is that everything with an *ubuntu* version needs it.  Depends how the bug is fixed, but usually.
[11:47] <Lutin> ok
[11:47] <geser> Lure: uploaded soundkonverter
[11:50] <Lutin> persia: what do you mean by 'robust' btw ?
[11:52] <persia> Lutin: Less prone to failure due to user error.  The big difference is that srcmaintainermangler works whether you are in the package root or in the debian folder.
[11:53] <geser> Lutin: have you checked what happens if someone has more Sources lines (e.g. edgy+feisty or feisty+sid)?
[11:54] <Lure> geser: thanks
[11:54] <Lutin> btw, geser; persia: new maintianer field is now in the wiki it seemd
[11:54] <Lutin> -d +s
[11:54] <Lutin> f the Maintainer field is modified, the old value will be saved in a field named X-Original-Maintainer
[11:55] <Lutin> geser: yeah, checked, that works
[11:55] <Lutin> geser: actually the script searches for the firsr distro-specific line
[11:56] <persia> Lutin: That's from July.  It has all the negative effects of both O-M and XBS-O-M, and none of the benefits of either.
[11:56] <Lutin> persia: ah, ok, sorry
[11:57] <geser> some packages use control.in from which debian/rules builds the control file, so you want also modify that file
[11:58] <geser> Lutin: looking how you determine the component it depends on the order in which apt-cache madison prints the Sources lines
[11:58] <geser> so you may end using the edgy line (a package may moved in feisty) or the one from Debian
[11:59] <Lutin> geser: how could that happen ?
[11:59] <Lutin> basically, i take the distro from the changelog
[11:59] <Lutin> and grep -m 1 $distro*sources the result of apt-cache madison
[11:59] <Lutin> can't see how a debian line could be selected
[12:00] <geser> than I have an outdated version of your script
[12:01] <geser> sorry, I was looking at an outdated version
[12:01] <Lutin> np :)
[12:02] <Lutin> updated version is at the same place
[12:05] <persia> Lutin: I realised why adding dch was useful: presumably the script is run after the changelog is updated, but the updater may not know if the maintainer needs to be mangled prior to running the script (due to exceptions, etc.), and may need to update the changelog again, depending on the script output.
[12:06] <Lutin> persia: this way, that would cause the ubuntu revision tu be bumped twice
[12:07] <Lutin> to*
[12:07] <persia> Lutin: Not `dch -i`, just `dch Modified Maintainer values to match Debian-Maintainer-Field spec`, which should add a comment within the same revision.
[12:07] <Lutin> ahhh ok
[12:07] <Lutin> np then
[12:07] <Lutin> adding it right now
[12:10] <Lutin> persia: ok,added
[12:12] <persia> Lutin: Why -m?
[12:13] <Lutin> persia: preserve maintainer name