[00:00] <mok0_> jscinoz: the .o file is the compiled files, they need to be linked to generate the program
[00:00] <LaserJock> it's an object file
[00:00] <jscinoz> and these are not included with libjpeg62-dev?
[00:01] <LaserJock> no
[00:01] <LaserJock> .o files get linked to create the program
[00:01] <mok0_> jscinoz: well, they are assembled into a library
[00:01] <LaserJock> .so are what would be shipped in a library
[00:02] <jscinoz> alright, so when someone says " static copy of system library: please change the upstream Makefile to link against Ubuntu’s libjpeg62 instead of using the static copy inside the sources" what do i need to change the make file to reference? the headers? the actual source or what?
[00:02] <mok0_> jscinoz: the makefile, in principle
[00:03] <jscinoz> >_<
[00:03] <jscinoz> ok.
[00:03] <jscinoz> so.
[00:03] <LaserJock> you want it to build against the headers I believe
[00:03] <mok0_> jscinoz: it looks like the program gets linked to the set of .o's from the jpeg subdir
[00:04] <jscinoz> included with the upstream package is libjpeg source, ie .h and .c, it builds these into a bunch of .o it needs to compile, now the libjpeg62-dev package contains no .c, and only a few headers compared to those in the upstream
[00:04] <mok0_> jscinoz: yes, and those headers are being included by other parts of the source
[00:05] <jscinoz> so... in the makefile, i've commented out where it compiles libjpeg from the source in the .c files.
[00:05] <mok0_> jscinoz: you need to define to the compiler where to find those headers (if not in the subdir), and also where to find the library
[00:05] <jscinoz> /usr/lib/libjpeg.so.62 yes?
[00:06] <mok0_> the first is usually with a -I switch, and the latter with a -ljpeg switch to the linker
[00:06] <mok0_> jscinoz: yes, that's the one that replaces the .o files
[00:06] <jscinoz> oh
[00:07] <mok0_> jscinoz: i.e. gcc -I/usr/include program.c -ljpeg -o program
[00:07] <jscinoz> so instead of the multitude of .o files on line 1000-1033, i just need the one .so?
[00:07] <mok0_> jscinoz: yup
[00:07] <jscinoz> ugh
[00:07] <jscinoz> wish i found that out earlier.
[00:08] <jscinoz> the -ljpeg is all i need?
[00:08] <jscinoz> i dont need it to be -l/usr/lib/libjpeg.so.62?
[00:08] <mok0_> jscinoz: no
[00:08] <mok0_> jscinoz: -ljpeg
[00:08] <jscinoz> thank you
[00:08] <mok0_> by default, the linker knows to look for libraries in /usr/lib
[00:09] <mok0_> it knows their names always start with 'lib' and end in '.so'
[00:09] <mok0_> so you only need to specify the "variable" bit = jpeg
[00:10] <ryanakca> hmm... what does this do "common-binary-predeb-arch" ?
[00:10] <ryanakca> and "common-binary-predeb-indep::" ?
[00:14] <jscinoz> mok0_, with -ljpeg can lines 1000-1033 be removed/commented out? or do they need to be changed somewhat
[00:14]  * mok0_ looks
[00:15] <jscinoz> and also line 153, and lines 1553-1554
[00:16] <mok0_> jscinoz: it's not that simple
[00:17] <jscinoz> >_<
[00:18] <mok0_> jscinoz: you need to put it in the LDFLAGS variable, and in fact it looks as if you can do that when calling make
[00:18] <mok0_> jscinoz: make "LDFLAGS=-ljpeg"
[00:19] <jscinoz> make[2]: *** No rule to make target `build/release-linux-i386/client/jcapimin.o', needed by `build/release-linux-i386/ioUrbanTerror.i386'.  Stop
[00:19] <jscinoz> as i said, should line 1k-1033 be commented out?
[00:19] <mok0_> jscinoz: yes that has to go
[00:20] <mok0_> jscinoz: but this makefile is full of ifeq... endif sections so be sure to fix it the right place
[00:20] <jscinoz> new output: http://pastebin.ubuntu-nl.org/52947/
[00:21] <mok0_> jscinoz: looks like it's missing -lGL
[00:22] <jscinoz> hmm
[00:22] <jscinoz> because it didnt have that output before i removed its own jpeg stuff..
[00:22] <jscinoz> same output with -lGL aswell >_<
[00:22] <mok0_> Hmm
[00:23] <mok0_> jscinoz: do you have someone where you live that knows about programming?
[00:23] <jscinoz> no.
[00:23] <jscinoz> hmm
[00:23] <mok0_> jscinoz: Like I said earlier, what you are trying to accomplish is not easy
[00:23] <jscinoz> if i have it still compile its own libjpeg, but remove the lines referncing the *.o's, it gives this same output
[00:24] <jscinoz> so what i think is that -ljpeg isnt linking it properly or something
[00:24] <jscinoz> aye, same output with or without "LDFLAGS=-ljpeg"
[00:24] <mok0_> jscinoz: it could be that it's a modified libjpeg
[00:24] <jscinoz> gah
[00:25] <mok0_> jscinoz: I suggest you tell the motu that you looked into the problem with help on IRC and that it does not seem to be possible to use Ubuntu's libjpeg as a replacement
[00:25] <jscinoz> alright thanks
[00:26] <mok0_> jscinoz: you can say you got indefined references and urbanterror
[00:26] <mok0_> s version seems to be modified
[00:27] <jscinoz> alright
[00:32] <LaserJock> hi Hobbsee and minghua
[00:33] <Hobbsee> heya LaserJock
[00:33] <minghua> Good evening LaserJock.
[00:35] <jscinoz> hmm whats a way to count the amount of lines output by grep/cat
[00:35] <StevenK> grep -c
[00:36] <StevenK> wc -l < file
[00:36] <StevenK> Either works fine
[00:36] <ryanakca> should I write a patch to fix two dozen lines of this? "dpkg-source: warning: file qyoto/csharp/qyoto/core/QObjectExtras.cs has no final newline (either original or modified version)" ?
[00:36] <jscinoz> thanks
[00:37] <ryanakca> s/two/a/
[00:38] <StevenK> pochu: I haven't, it's a little complicated.
[00:54] <ryanakca> hmmm. Ok, so I've got qyoto merged into kdebindings, I'm just wondering how to generate the dsc since I'm getting these errors http://paste.ubuntu-nl.org/52952/ when I run debuild -S -sa -kE95EDDC9
[00:59] <cyberix> I'm looking after first advocate for my package Malbolge. I've fixed all broblems that have been brought up. http://revu.tauware.de/details.py?package=malbolge
[01:03] <LaserJock> ryanakca: it looks like it's from source files and if it doesn't cause a bug I certainly wouldn't worry about it.
[01:03] <ryanakca> LaserJock: was that to the patch question or how to generate the dsc question?
[01:04] <LaserJock> patch question
[01:04] <ryanakca> okies, thanks :)
[01:05] <LaserJock> ryanakca: hmm, it kinda looks to me like there's a lot of stuff going on in the .diff.gz there
[01:06] <ryanakca> LaserJock: yes, well, I copied all of the qyoto sources into kdebindings-3.5.8
[01:06] <minghua> ryanakca: The building error question -- the real problem are the two "cannot represent change" errors.
[01:06] <LaserJock> oh, that's going to be a bit difficult
[01:06] <LaserJock> right, what minghua said
[01:07] <LaserJock> you're trying to add source when packaging is not meant for that
[01:07] <ryanakca> yes... then what would be the appropriate way?
[01:07]  * ryanakca was asked to merge qyoto into kdebindings... generate a new .orig.tar.gz ?
[01:09] <LaserJock> ryanakca: I guess so
[01:09] <LaserJock> is qyoto distributed separately?
[01:09] <pochu> StevenK: Alright. Would be nice though if possible.
[01:09] <ryanakca> LaserJock: okies. take out the debian dir?
[01:09] <LaserJock> ryanakca: hmm?
[01:09] <ryanakca> LaserJock: yes, but kdebindings is just an assortment of libraries which are distributed seperately
[01:10] <ryanakca> take out the debian/ dir when making the .orig.tar.gz ?
[01:10] <LaserJock> how is it distributed?
[01:10] <LaserJock> ryanakca: first we need to figure out how you get the kdebindings .orig.tar.gz
[01:11] <ryanakca> how are they distributed? umm... part comes from http://www.kde.org/download , another comes from the xparts website, some from qyoto.org, kjsembed... umm.. unsure how it was all pieced together originially
[01:11]  * ryanakca reads the changelog
[01:12] <LaserJock> ryanakca: are you working on KDE3?
[01:12] <ryanakca> yes
[01:12] <LaserJock> k, I'm grabbing the source
[01:13] <ryanakca> I was originally supposed to merge the KDE3 package with the KDE4 package from debian, and then merge in qyoto into that merged thing, but then it was decided to just merge qyoto into kdebindings kde3 since the debian kde4 packaging wasn't advanced enough
[01:16] <ryanakca> LaserJock: step by step, what I did was copy the qyoto source dir to kdebindings-3.5.8/qyoto, merge kdebindings-3.5.8/qyoto/debian/* with kdebindings-3.5.8/debian/*, then remove kdebindings-3.5.8/qyoto/debian
[01:16] <LaserJock> right, and I think that's wrong
[01:17]  * ryanakca tars up kdebindings-3.5.8/debian and puts it on his webserver
[01:17] <ryanakca> hmmm.
[01:17] <LaserJock> the problem is that packaging isn't meant to add source to
[01:17] <LaserJock> so your .diff.gz can't represent binary files
[01:18] <LaserJock> and really, you don't want to do that
[01:18] <bddebian> Heya gang
[01:18] <LaserJock> you want to add qyoto to kdebindings
[01:18]  * ryanakca nods
[01:18] <ryanakca> LaserJock: http://blog.ryanak.ca/kdebindings-3.5.8.debian.tar.gz
[01:19] <ryanakca> hey bddebian
[01:19] <LaserJock> so kdebindings is distributed upstream as a tarball
[01:19] <ryanakca> LaserJock: ok, to add qyoto, I'd have to generate a new orig.tar.gz?
[01:19] <bddebian> Hello ryanakca
[01:19] <ryanakca> hmmm
[01:20] <ryanakca> and in that new .orig.tar.gz, I would have to remove debian/, then readd it, debuild, etc ?
[01:20] <LaserJock> well
[01:20] <LaserJock> hmm
[01:20] <LaserJock> this is a bit funky
[01:21]  * ryanakca nods
[01:21] <LaserJock> you want to take the kdebindings upstream tarball
[01:21] <LaserJock> unpack it, add your qyoto source, and retar it
[01:21] <ryanakca> ok.
[01:21] <LaserJock> but that means you're creating a new .orig.tar.gz for the same version of kdebindings
[01:21] <ryanakca> can I do that to the current .orig.tar.gz?
[01:22] <LaserJock> which is not great
[01:22] <ryanakca> hmm... Riddell is probably asleep atm...
[01:22] <LaserJock> ryanakca: I honestly don't know why you're not adding this as a separate package
[01:23] <ryanakca> LaserJock: it currently is a seperate package...
[01:23] <LaserJock> ah ....
[01:23] <ryanakca> LaserJock: *gets the logs from this afternoon describing what he has to do*, just a sec.
[01:25] <ryanakca> LaserJock: http://blog.ryanak.ca/kubuntu-devel.log
[01:28] <ScottK> LaserJock: Do you have time to do some source backports for me (I need a core-dev to upload)?
[01:29] <LaserJock> ryanakca: well, honestly, you've got to talk to Riddell about that. That looks really odd/suspicious to me
[01:29] <LaserJock> ScottK: what do you need
[01:29] <LaserJock> ?
[01:30] <ScottK> LaserJock: I need to you upload the 3 packages with debdiffs in But #183914.
[01:30] <ScottK> Urgh
[01:30] <ScottK> Bug #183914
[01:30] <ubotu> Launchpad bug 183914 in dapper-backports "Please Backport clamav-0.92~dfsg-2 from Hardy to Dapper" [Wishlist,In progress] https://launchpad.net/bugs/183914
[01:31] <ScottK> The won't get published until an archive admin accepts them, but I can't upload them...
[01:31] <ScottK> The/They
[01:31] <ryanakca> LaserJock: ok, will do
[01:32] <RAOF> superm1: Re bug #134197 - as far as I can tell, monodevelop doesn't need a build-dep on firefox at all (but it does need a dep on firefox, & I've filed a debian bug about that).
[01:32] <ubotu> Launchpad bug 134197 in monodevelop "Please merge monodevelop 0.18.1+dfsg-1 from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/134197
[01:32] <mcisbackuk> Hi all, I'd like to get involved in packaging, but a lot of the wiki's are confusing
[01:33] <superm1> RAOF, i didn't want to change things with the way it worked (it build-depends fine with it in there)
[01:33] <RAOF> superm1: Quite true.  It doesn't care whether or not you've got a firefox-dev build-dep or not :)
[01:34] <mcisbackuk> Can anyone help me get started please?
[01:34] <ryanakca> mcisbackuk: the Ubuntu Packaging Guide is a good starting place...
[01:34] <RAOF> mcisbackuk: What would you actually like to do?
[01:34] <RAOF> (Packaging is a broad field ;))
[01:34] <superm1> RAOF, :)
[01:34] <ryanakca> mcisbackuk: http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[01:35] <mcisbackuk> i've had a look at the guide, but it's too broad, as you say, and I'll be honest I'm not that good on linux, but know pc's well (notdeveloper level) and would love to help out, maybe get rid of some on the wishlist to help you guys out :)
[01:36] <LaserJock> !packagingguide > ryanakca
[01:36] <RAOF> superm1: Did you try to xul-1.9ify it at all?
[01:36] <ryanakca> LaserJock: oh? hmm... *checks the new link*
[01:36] <superm1> RAOF, i did not.
[01:36] <ScottK> LaserJock: What do you think, are you up for it?
[01:36] <superm1> RAOF, i was more looking to get the merge done (given the time frame for the impending freeze)
[01:37] <ryanakca> LaserJock: heh, interesting.
[01:37] <ryanakca> mcisbackuk: ignore me :)
[01:37] <mcisbackuk> i havent used irc before how do i reply lol sorry i must sound really stupid now
[01:37] <RAOF> superm1: Yeah, fair enough.  I'll add that to my moderately large "before FF todo" list.
[01:38] <superm1> RAOF, yeah i'm looking for any other big ones that i know people are going to be annoyed by here if they aren't done at this point
[01:38] <mcisbackuk> ryanacka
[01:38] <mcisbackuk> oops
[01:38]  * RAOF would like to fix debian bug #461353 before FF, for example.
[01:39] <ubotu> Debian bug 461353 in monodevelop "monodevelop: Fails to start without Gecko" [Normal,Open] http://bugs.debian.org/461353
[01:39] <RAOF> Argh, wrong one.
[01:39] <ryanakca> mcisbackuk: to reply, put the persons name : message.
[01:44] <mcisbackuk> Am I still connected?
[01:44] <RAOF> mcisbackuk: Yes.
[01:45] <mcisbackuk> RAOF : Thanks
[01:45] <mcisbackuk> RAOF: Thanks
[01:46] <RAOF> It's just that no one is saying anything much :)
[01:47] <RAOF> That happens.
[01:47] <mcisbackuk> Ahh I see :)
[01:48] <mcisbackuk> I really wann get my hands dirty in linux lol
[01:48] <mcisbackuk> Are packages added to the repositories after the feature freeze do you know?
[01:49] <RAOF> Only with a good reason.
[01:49] <mcisbackuk> So not anything silly like someone wants a game then
[01:49] <RAOF> The only really hard freeze is at the end.  All the other freezes mean that you need to make a good argument for why $PACKAGE should be an exception.
[01:50] <ScottK> mcisbackuk: If you are just starting now, you probably want to start learning packaging through bugfixing and merges and then do new packages starting with Hardy +1
[01:50] <mcisbackuk> What if it's built for 7.10 for example though?
[01:50] <mcisbackuk> Ahh I see...
[01:50] <ScottK> 7.10 is done.  Packages can be added/updates from Hardy in gutsy-backports, but that's it.
[01:51] <mcisbackuk> ok
[01:52] <mcisbackuk> I get it now :)
[01:53] <mcisbackuk> So I take it the only time software gets updated is with a new release, and its only bugfixes/security updates until then?
[01:54] <minghua> If you mean "after that" by "until then", basically yes.
[01:54] <RAOF> Pretty much.  And not just any bugfixes; they need to be important (for a certain definition of important).
[01:54] <minghua> From a user's point of view, at least.
[01:55] <mcisbackuk> Like data loss, corruption I take it?
[01:55] <RAOF> That'd certainly qualify.  Also regressions from previous versions (it works in Feisty, but not Gutsy) often qualify.
[01:55] <mcisbackuk> I see
[01:55] <LaserJock> mcisbackuk: you might want to read http://wiki.ubuntu.com/StableReleaseUpdates
[01:56] <ScottK> Up until the beta, my usual definition of sufficiently importatant is someone thougth it was worth the trouble to come up with the fix.
[01:56] <RAOF> Basically the risks of touching a package increase the closer to the release date we are.  *After* the release date the risk is considered very nearly infinite, so you need a *very* good reason for touching anything.
[01:57] <mcisbackuk> Since everything is pretty much working at that point?
[01:57] <zul> evening
[01:57] <ScottK> That's the theory.
[01:58] <ScottK> evening zul.
[01:58] <zul> how is going ScottK
[01:58] <mcisbackuk> Theory's nice lol :)
[01:58] <ScottK> zul: Pretty good.  LaserJock's uploading the source backports for Dapper so we can get the current clamav into dapper-backports.
[01:59] <zul> nifty
[01:59]  * RAOF needs to write a blog post on what "stable" means in the context of Ubuntu releases/archives.
[01:59] <ScottK> I feel like I just did a masters thesis in packaging, testing, and release management.
[02:00] <mcisbackuk> So, sorry guys, what about bug #182693, it says needs-packaging, but its under mentoring available? Does that mean the maintainer is willing to help out someone new with doing it? Sorry you must all think I'm a pain in the backside.
[02:00] <ubotu> Launchpad bug 182693 in ubuntu "[needs-packaging] monkeystudio" [Wishlist,In progress] https://launchpad.net/bugs/182693
[02:00] <ScottK> mcisbackuk: Part of what we do is help people get started.
[02:01] <ScottK> mcisbackuk: You're fine.
[02:01] <RAOF> mcisbackuk: The "in progress" status of that bug suggests that someone is actively working on it, so it might not be a good place to start.
[02:01] <mcisbackuk> ScottK: Thanks :) I just want to learn and help out
[02:01] <ScottK> Then you're in the right place
[02:03] <mcisbackuk> Well I was looking at bug #184791, and it looked like a simple one to start off with, an alarm clock....but none of the guides tell you how to compile the binary/deb in python
[02:03] <ubotu> Launchpad bug 184791 in ubuntu "[needs-packaging] Alarm Clock" [Undecided,New] https://launchpad.net/bugs/184791
[02:05] <mcisbackuk> Or vice versa
[02:08] <ScottK> mcisbackuk: We're pretty close to feature freeze.  It's really unlikely that if you start a new package it would make it into Hardy, but you're certainly free to give it a shot if you want.
[02:09] <mcisbackuk> ScottK: Well I'd like to at least have a go, and try refining the skills needed to package.
[02:10] <RAOF> mcisbackuk: It's much easier to start with bugfixing.  Then you learn bits of packaging at a time.
[02:10] <mcisbackuk> RAOF: Don't you need to know more about the actual code then?
[02:10] <ScottK> mcisbackuk: If you really want to take a shot at that one, find a similar package and see how they did it.
[02:11] <ScottK> mcisbackuk: Do you code at all?
[02:11] <mcisbackuk> Nope - I think that may be the problem lol
[02:11] <ScottK> It's not needed to package.
[02:12] <mcisbackuk> Thank god
[02:12] <ScottK> look for bugs tagged packaging and bitesize
[02:12] <RAOF> mcisbackuk: You don't have to understand the code in many cases.  Some bugs are just in the packaging.  Sometimes you can follow the bug to the upstream bug tracker, where there's a patch to fix it.
[02:12] <mcisbackuk> As in the original from the developers website?
[02:12] <RAOF> Yes.
[02:13] <mcisbackuk> OK, maybe I'll start there :)
[02:13] <mcisbackuk> Can either of you point me to an idiots guide, if there is such a thing?
[02:13] <mcisbackuk> lol
[02:20] <LaserJock> mcisbackuk: and idiots guide to what?
[02:21] <mcisbackuk> LaserJock: Packaging, or as RAOF said re-packaging upstream versions
[02:22] <LaserJock> mcisbackuk: I think the best we've got really is the packaging guide http://wiki.ubuntu.com/PackagingGuide
[02:22] <mcisbackuk> LaserJock: OK I'll have to grit my teeth and buckle down and see if I can work it out, I won't let it get the better of me :)
[02:24] <LaserJock> mcisbackuk: packaging is not all that hard, but does require patience
[02:24] <LaserJock> there is a lot of stuff to remember
[02:24] <LaserJock> but it's definitely learnable
[02:24] <mcisbackuk> I have the patience and the time to do it definately, and I learn quick
[02:28] <jscinoz> well i managed to bork my system >_<
[02:29] <mcisbackuk> Doesn't sound good.....
[02:30] <ScottK> jscinoz: This isn't a support channel.
[02:30] <jscinoz> i know :P just saying it casually lol
[02:31] <jscinoz> and zomg someone check the latest uploads of my urbanterror and urbanterror-data packages, i fixed some more stuff
[02:34] <wolfger> one of my review comments mentions the "python packaging policy". but Google isn't helping me find that. Anybody have a link?
[02:34]  * bddebian would if it wasn't a 300+Mb data package :-)
[02:35] <bddebian> wolfger: http://wiki.debian.org/DebianPython/NewPolicy
[02:36] <wolfger> thx
[03:16] <LaserJock> man, busy day today. Got almost nothing done that I wanted to :)
[04:21] <bddebian> ajmitch: You around at all?
[05:42] <vemon> good morning!
[05:51] <vemon> should i add "Uploaded to REVU: http://...." comment to a [needs-packaging] bug when i do a revu upload?
[05:51] <LaserJock> wouldn't hurt
[05:53] <vemon> if there is someone who knows that LASH is then here's one for review: N:   The source package refers to a 'Standards-Version' that is starting to
[05:53] <vemon> N:   get out of date, compared to current Policy. You can safely ignore
[05:53] <vemon> :D
[05:53] <vemon> N:   this warning, but please consider updating the package to current
[05:53] <vemon> well not that
[05:53] <vemon> N:   Policy.
[05:53] <vemon> http://revu.tauware.de/details.py?package=lashwrap
[05:54] <vemon> sorry for flooding :D middle clicking can be a little hazardous sometimes
[06:32] <LucidFox> vemon> commented
[07:05] <warp10> Heya
[07:05] <yamal> mornin
[07:08] <yamal> MOTUs, your comments please, for the latest and greatest sabnzbd package: http://revu.tauware.de/details.py?package=sabnzbdplus
[08:56] <theseinfeld> cprov: how long does it take to revu to get your dput and email you?
[08:56] <amarillion> Please be so kind to review one of my packages http://revu.tauware.de/details.py?package=alex4 and http://revu.tauware.de/details.py?package=speed-game. These packages are in a good state, all previous comments have been addressed
[08:57] <amarillion> theseinfeld, you won't get an email...
[08:57] <amarillion> but revu is updated once every 12 minutes
[08:57] <theseinfeld> amarillion: yes, I can see that it was received, but I was waiting for the password so I could login...
[08:57] <theseinfeld> amarillion: or did i get it all wrong?
[08:57] <theseinfeld> :(
[08:58] <amarillion> The password won't get emailed either. Just fill out your email address, and press login. It fails, then gives you the option to get a new password
[08:59] <theseinfeld> Once you have uploaded a package to REVU, a password will be created for you. To get it, enter your e-mail address into the login box, leaving the password field blank, and click Login. Click Recover, and REVU will display an encrypted message with your password in it.
[08:59] <theseinfeld> yes
[08:59] <theseinfeld> amarillion: you are right...
[09:00] <amarillion> yeah, do you get a password now?
[09:00] <theseinfeld> amarillion: the problem is that i get this
[09:00] <theseinfeld> No REVU account for theseinfeld@users.sf.net exists yet.
[09:00] <amarillion> Did you sign up for the universe contributors team?
[09:00] <theseinfeld> yes
[09:00] <amarillion> also, do you have a GPG key uploaded to launchpad?
[09:00] <theseinfeld> since yesterday
[09:00] <theseinfeld> the key must be 2 years old
[09:00] <theseinfeld> :D
[09:00] <theseinfeld> yes yes yes
[09:01] <amarillion> oh, it may take a day before the keys get copied to revu
[09:01] <amarillion> so that may be the problem
[09:01] <amarillion> ask persia to do a sync
[09:01] <theseinfeld> whois persia
[09:01] <theseinfeld> ok
[09:01] <theseinfeld> I can wait also...
[09:01] <amarillion> yeah, both will work :)
[09:01] <theseinfeld> I was puzzled that the package is uploaded
[09:02] <amarillion> did you upload a package?
[09:02] <theseinfeld> http://revu.tauware.de/details.py?package=libdc1394-22
[09:02] <amarillion> which one?
[09:02] <philn> hi
[09:02] <theseinfeld> amarillion: libdc1394-22
[09:03] <amarillion> theseinfeld, would you like me to review it?
[09:04] <theseinfeld> amarillion: on phone...just a sec
[09:06] <philn> i created a bug to sync a package in hardy, do i need subscribe someone special so that it's taken care of?
[09:08] <minghua> philn: Yes, read https://wiki.ubuntu.com/SyncRequestProcess and follow instructions.
[09:08] <philn> ok; thx
[09:09] <TheMuso> Hey MOTUs.
[09:09] <TheMuso> and MOTu hopefuls. :p
[09:10] <Hobbsee> hi deity
[09:12] <TheMuso> Hobbsee: lol
[09:12] <Hobbsee> TheMuso: or is that info not public yet?
[09:14] <TheMuso> Hobbsee: Lets just say its not common knowledge.
[09:14] <Hobbsee> fair enough
[09:15] <Hobbsee> we'll just call you a deity without saying the reason tehn
[09:17] <vemon> is the backports repository the only place to get new upstream versions after an ubuntu release?
[09:18] <vemon> meaning: are bug fixes the only changes which are uploaded to the normal repos after release?
[09:18] <minghua> vemon: Yes, unless the new upstream version is a bugfix-only release, and fix important bugs.
[09:21] <Hobbsee> !sru | vemon
[09:21] <ubotu> vemon: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates
[09:22] <slytherin> hi all. Does anyone know if the java license related debconf preseeding on buildd works for both java5 and java6?
[09:22] <geser> slytherin: yes, as both use the same debconf question
[09:26] <slytherin> geser: One more question. Are 'arch: all' packages built on i386 only?
[09:27] <theseinfeld> amarillion: back
[09:33] <geser> slytherin: yes, the i386 buildd builds also the arch:all packages
[09:46] <geser> Hi dholbach
[09:46] <dholbach> hey geser
[09:48]  * TheMuso can't see any major change in that topic.
[09:49]  * StevenK bites his tongue
[09:49] <TheMuso> StevenK: hardy hardy gar
[09:49] <TheMuso> s/gar/har/
[09:51] <theseinfeld> Please be so kind to review the following package: http://revu.ubuntuwire.com/details.py?package=libdc1394-22 . It should be in a good state as it has been discussed with some Debian people. Thank you
[10:10] <psicus78> hi
[10:19] <geser> slytherin: do you know if with sun-java[56] compiled code runs with kaffe? I'm looking at the statcvs package now.
[10:21] <slytherin> geser: Not sure, never used kaffe. But if the code itself doesn't use any sun specific apis/extensions then it should run with any VM. And I guess kaffe supports Java 1.5 apis, but I will have to confirm.
[10:21] <slytherin> geser: What is the problem by the way?
[10:23] <geser> slytherin: no problem, just checking if depends line is still correct after changing build-depends
[10:24] <geser> statcvs depwaits currently on sun-j2sdk* and I want to change it to the available compilers
[10:25] <slytherin> geser: Why not try java-gcj-compat-dev?
[10:25] <geser> I did, doesn't build with it
[10:26] <slytherin> geser: can you paste the error somewhere?
[10:26] <geser> btw: libjibx-java from yesterday doesn't build with gcj either
[10:27] <slytherin> hmm.
[10:29] <slytherin> geser: looks like kaffe is far behind other Free JVMs. http://www.kaffe.org/~stuart/japi/htmlout/h-kaffe-jdk14.html
[10:32] <geser> slytherin: http://paste.ubuntu.com/3773/
[10:33] <psicus78> hi!
[10:33] <psicus78> do you know if it exist any tool that allow to find out (and then install) all the build-dependencies of a package which is not debianized yet? I mean get all the libblabla-dev required at build time?
[10:33] <geser> psicus78: no, try and error
[10:34] <slytherin> geser: Check error number 8, It uses sun specific apis.
[10:34] <geser> psicus78: you can read the README and/or INSTALL file and hope that it contains a list of requirements
[10:34] <minghua> psicus78: There are tools to help, but nothing like "apt-get build-dep"
[10:34] <psicus78> minghua: yes, autotools should help
[10:35] <geser> psicus78: you can also look which packages configure looks for
[10:35] <psicus78> geser: correct, that's what I was thinking
[10:35] <DaveMorris> \me plugs his package for revu - http://revu.tauware.de/details.py?package=opensg It's an OSS distributed scenegraph API for doing some cool 3D graphics across multiple machines or single machines.  Has support for sort 1st and sort last.  I'm currently using it to power a cluster with a 46 million pixel display.  It's cool so please revu it.
[10:35] <psicus78> I was wondering if it would be possible to automate that
[10:36] <geser> slytherin: so build-depend on sun-java[56]-jdk. is kaffe still a good candidate for depends?
[10:36] <psicus78> I believe it is possible
[10:37] <geser> psicus78: you could also check the included headers files
[10:37] <slytherin> geser: No. Obviously in this case since the runtime should also contain those sun specific apis, only Sun JRE qualifies
[10:38] <geser> slytherin: so I change "Depends: classpath, kaffe | java2-runtime" to "Depends: sun-java6-jre | java2-runtime"?
[10:39] <slytherin> geser: only "sun-java5-jre | sun-java6-jre".
[10:40] <geser> slytherin: thanks
[10:42] <psicus78> geser: mmm...if the developer uses autotools he should check everything in configure.ac
[10:42] <psicus78> geser: or configure.in
[10:43] <geser> psicus78: yes, if the developer uses autotools
[10:44] <psicus78> geser: I was wondering if there is something cannot be discovered automatically
[10:44] <vemon> now that you're talking about Depends... what does the {sh:Depends} (probably not typed correctly) actually do?
[10:45] <vemon> i've seen that in many packages and it seems it's not necessary to explicitly define deps for those packages
[10:45] <vemon> i'n debian/control i mean
[10:45] <psicus78> geser:  for instance in network-manager there is some code to check for wireless-tools but not using pkg-config, that could be a problem
[10:46] <geser> vemon: dh_shlibdeps computes the runtime dependencies (by looking at the needed libs) and replaces the the placeholder with it
[10:46] <psicus78> vemon:  I'm not sure 100% but I think {sh:Depends} includes all the packages that contain the shared libraries required at runtime
[10:46] <psicus78> vemon: what I want is build-time depends instead
[10:48] <psicus78> geser: I must suppose that autotools is used, otherwise is impossible
[10:49] <slytherin> Can someone explain to me process of merge?
[10:50] <geser> slytherin: simplified: you take the latest debian revision and the Ubuntu changes, check which are still needed and apply them again
[10:50] <geser> slytherin: you can use the output of MoM as a starting point for most merges
[10:51] <slytherin> geser: Ok. And then which debdiff should I submit? Or should I submit interdiff?
[10:52] <geser> slytherin: debdiff, between the debian revision and the new ubuntu revision
[10:53] <slytherin> ok, thanks.
[10:53] <vemon> are there cases where sh:Depends is not enough? (i guess when some package is only suggested?)
[10:55] <geser> vemon: it works only for libraries (lib*.so.*), so if your app is written in perl/ruby/python/etc. you need to figure the depends yourself out
[10:56] <geser> vemon: another examples are -dev packages, where you want to install the correct version of the lib the headers belong to
[11:00] <vemon> can give me an example?
[11:01] <geser> vemon: an example for what?
[11:11] <vemon> geser, for a dev package which requires a certain version of the lib it gives headers to
[11:19] <geser> vemon: e.g. http://revu.tauware.de/revu1-incoming/libmirage-0801202040/libmirage-1.0.0/debian/control any other package on revu building a -dev package should have it too
[11:26] <slytherin> geser: Are you able to search packages in debian unstable from http://packages.debian.org ? It times out for me for last few days.
[11:31] <man-di> slytherin: works fine here
[11:32] <geser> slytherin: here too
[11:35] <vemon> geser, now i understand. i think i missed the part where you said the package to be built is a dev- package. :)
[11:52] <rexbron> Hey everyone! Got one ack and looking for a second: http://revu.tauware.de/details.py?package=ubuntustudio-controls
[11:55]  * Hobbsee has a look
[11:58] <zul> morning
[11:59] <Hobbsee> rexbron: surely setup.py should have some form of copyright notice too?
[11:59] <Hobbsee> if the rest does?
[12:00] <rexbron> Hobbsee: perhaps, but that is just calling a function. If by convention setup.py should have a copyright notice, I will include one
[12:00] <Hobbsee> rexbron: will leave it, and see what the other archive admins say
[12:00] <rexbron> ok
[12:02]  * Hobbsee acks, uploads
[12:02] <rexbron> :)
[12:02] <rexbron> thanks Hobbsee
[12:03] <Hobbsee> rexbron: you're welcome
[12:03] <slytherin> Can anyone give me any debian package's .dsc url? I wish doe download source for libjcalendar-java but I can't search it due to timeout problems.
[12:03]  * TheMuso hugs Hobbsee 
[12:04]  * Hobbsee hugs TheMuso :)
[12:04] <mok0> whole lotta huggin' going on
[12:04] <geser> slytherin: I use the PTS for such things: http://ftp.debian.org/debian/pool/main/libj/libjcalendar-java/libjcalendar-java_1.3.2-2.dsc
[12:05] <slytherin> geser: Please excuse my ignorance, what is PTS?
[12:06] <geser> slytherin: Debian's package tracking system: http://packages.qa.debian.org
[12:06] <slytherin> geser: Thanks.
[12:07] <geser> slytherin: it has also a nice redirect: http://packages.qa.debian.org/libjcalendar-java will redirect you to the correct page
[12:13] <frafu> Could anybody please review the following package: http://revu.tauware.de/details.py?upid=1379 Thanks
[12:15] <frafu> Please ignore the package from January 21 18:30;  its upload was an error.
[12:16] <ion_> It might be best to reupload the correct one.
[12:19] <frafu> ion_: reuploading does not work: package already uploaded error
[12:19] <slytherin> frafu: use 'dput -f' option
[12:20] <persia> frafu: delete your .upload fle
[12:21] <frafu> thanks for the tips
[12:23]  * ion_ cringes. From the postinst of a third-party deb:
[12:24] <ion_> cp /usr/share/retroshare/retroshare.desktop "$HOME/Desktop"
[12:24] <LongPointyStick> ...blink
[12:25] <persia> It recreates that wonderful "launcher on the desktop on install" feature, except that the install doesn't actually run as the user :)  Perfect for those scenarios where you run X as root.
[12:25] <StevenK> Which gdm doesn't permit, if I recall
[12:26] <persia> StevenK: There are ways around gdm, and gdm can be configured to allow it, but in most cases you are correct (as usual)
[12:26] <frafu> persia: where can I find the .upload  file?
[12:26] <persia> frafu: should be in the same directory as the .changes you uploaded.
[12:29] <frafu> persia: ok; I understand now; I searched for it in my home directory. Thanks again.
[12:36] <persia> Java question: If upstream has mixed-case in their .jar file, I know we flatten for the package name, but do we also flatten the .jar file?
[12:37] <slangasek> I can't see any reason why you would, surely that would induce incompatibility with upstream?
[12:37] <theseinfeld> anybody for reviewing http://revu.tauware.de/details.py?upid=1391 ?
[12:37] <theseinfeld> thanks
[12:37] <persia> slangasek: That's what I was thinking, but I'm a little fuzzy on Java policy.  Thanks for the confirmation.
[12:39] <persia> theseinfeld: There tends to be a significant lull in reviewing just after REVU day (ended 99 minutes ago).  If your package was submitted before REVU day, and nobody looked at it, it will be included in the post-REVU day summary mail, and may get a review.
[12:39] <slytherin> persia: I would recommend not do do that. What if the package has some demo program which uses jar file. The program won't find the file in that case.
[12:40] <persia> slytherin: It shan't be done then :)
[12:41] <slytherin> geser: A little help needed, libhibernate3-java has manual dep wait on libcglib2.1-java, but I can't find that package in Ubuntu as well as Debian.
[12:43] <slytherin> geser: oops, my mistake, it is present in both
[12:48] <mok0> I am still looking for a collaborator to help with torque
[12:48] <mok0> ... I guess not many are interested in cluster computing
[12:50] <persia> mok0: The best way to get help is to ask in the right forum, but it appears you've already done that with https://lists.ubuntu.com/archives/ubuntu-motu-science/2007-November/000010.html :(
[12:50] <mok0> persia: yes
[12:51] <slytherin> Can anyone confirm that package aspectwerkz2 is not synced from debian. I seem to be making search at wrong places today.
[12:52] <tjaalton> can someone with fglrx + amd64 confirm that 32bit GL apps work currently?
[12:54] <persia> slytherin: I don't see it in the Ubuntu repositories.  rmadison might be a tool worth investigating
[12:56] <slytherin> persia: Can absence of a package cause depwait packages that depend on it? looks like cglib2.1 has a depwait for same reason and in turn causes depwait in hibernate3
[12:58] <persia> slytherin: Yep.  depwait only means the build dependencies cannot be satisfied.  This can be a typo, a needed update, a side effect of a removal, or a build failure somewhere else in the chain.
[12:59] <Aloha> its cool that the servers automagically build the binaries
[12:59] <Aloha> woot pbuilder install almost done
[12:59] <slytherin> persia: rmadison returns zero results for aspectwerkz2 as well as libaspectwerkz2-java.
[12:59] <geser> slytherin: bug #184278
[12:59] <ubotu> Launchpad bug 184278 in ubuntu "[Sync request] Please sync aspectwerkz2 2.0.dfsg.1-2 (universe) from Debian unstable (contrib)" [Wishlist,Confirmed] https://launchpad.net/bugs/184278
[13:00] <slytherin> geser: thanks. :-)
[13:00] <Hobbsee> when will someone write a script that gets the address of the .dsc for the latest package in debian?
[13:01] <geser> Hobbsee: start coding :)
[13:01] <persia> Hobbsee: apt will do that, if you like.  I wrote a dirty hack to do it, but these days I find it most convenient to keep an up-to-date sid chroot around and just use apt-get source with /home bind-mounted.
[13:02] <Hobbsee> hm
[13:03] <persia> If you use mk-sbuild-lv from ubuntu-dev-tools to generate the sid chroot, it takes care of all the mounting stuff for you.  You just need a couple gig free for the volume group for the LV in which the chroot lives.
[13:03] <geser> Hobbsee: shouldn't apt-get source -t unstable do it if you have a deb-src line in your sources.list?
[13:03] <Hobbsee> geser: probably.  if i had the deb-src line
[13:04] <AnAnt> man-di: Hello
[13:04] <AnAnt> man-di: I have a couple of questions
[13:05] <AnAnt> man-di: 1. why are you worried that people would depend on IcedTea and forget about gcj, isn't IcedTea free ?
[13:05] <AnAnt> man-di: 2. any news about IcedTea debian package ?
[13:05] <persia> AnAnt: Are you planning to update the ubuntume packages?  I'd really like to see them get into hardy, but I'm getting worried about timing.
[13:05] <jdstrand> emgent: I have uploaded the drupal5 fixes, but please see my comment in bug #181984
[13:06] <ubotu> Launchpad bug 181984 in drupal5 "Drupal5: SA-2007-031, SA-2008-005,SA-2008-006: SQL injection and XSS " [Undecided,Fix committed] https://launchpad.net/bugs/181984
[13:06] <jdstrand> emgent: thanks!
[13:06] <man-di> I am worried because icedtea is currently i386/amd65/powerpc and people woll forget about the other archs
[13:06] <man-di> AnAnt: its currenly uploading
[13:06] <StevenK> amd65. I've not heard of that arch
[13:07] <slytherin> AnAnt: apart from what man-di said, icedtea is not complete yet, may not be stable enough.
[13:07]  * man-di paints StevenK a big 4 into his hand
[13:07] <man-di> *g*
[13:07] <StevenK> Gimme 4?
[13:08] <man-di> AnAnt: slytherin is right. Its a big moving target, nobody knows what Java7 really will include
[13:09] <man-di> StevenK: Its the successor of amd64 with one more address bit to make it possible to address more memory
[13:09] <AnAnt> persia: well, I don't think so. I really dunno what to do about modifying gdm.conf & grub.conf
[13:10] <AnAnt> persia: also the request to host the packages in LP's SVN
[13:10] <Aloha> woohoo!
[13:10] <Aloha> my pbuilder install is done
[13:10] <persia> AnAnt: Hrm.  Have you tried asking one of the other derivatives about it?  Maybe #xubuntu or #ubuntustudio or #icthux would have some pointers.
[13:11] <\sh> persia, mk-sbuild-lv just has this nasty debootstrap->find distro in /usr/lib/debootstrap bug ;) it's fixed in our bzr branch of ubuntu-dev-tools
[13:11] <\sh> moins btw
[13:11] <persia> AnAnt: That was more that either the packages oughtn't be native, or be in LP bzr.  LP accounts are free, but I can understand if there are issues with the service.  The other option is not to publish any Vcs-*, but that can affect maintenance.
[13:12] <persia> \sh: Why is it only fixed in bzr?  Shouldn't it be fixed where we can use it?
[13:12] <\sh> persia, well it would be a good idea to release a new version of ubuntu-dev-tools
[13:13] <Aloha> how do you import signature for apt-get source?
[13:13] <persia> \sh: You have the power...
[13:13] <Aloha> i mean key
[13:13] <persia> Aloha: There's no easy way.  You have to collect the keys of all the developers.
[13:14] <\sh> dholbach, any reasons not to upload ubuntu-dev-tools from trunk?
[13:14] <Aloha> persia, nevermind not worth it. i believe its valid ;)
[13:14] <ScottK> \sh: Does pbuilder-dist work yet?
[13:15] <ScottK> \sh: Also, IIRC it was geser, someone was working on requestsync and I'm not sure they got it done/comitted/merged.
[13:15] <geser> ScottK: I've already committed my changes to bzr
[13:16] <Aloha> whats bazaar used for? is it like PPA?
[13:16] <\sh> ScottK, oh I never used pbuilder-dist ;) I have my own pbuilder framwork
[13:16] <geser> Aloha: have you heard of cvs or svn? bzr is an other version control system
[13:17] <Aloha> geser, gotcha. is it ubuntu specific?
[13:17] <\sh> Aloha, nope
[13:17] <Aloha> oh. never heard of it before
[13:17] <\sh> Aloha, bug canonical sponsors the development of bzr and so it's our default VCS
[13:17] <jdstrand> emgent: I also added a comment on bug #181416
[13:17] <ubotu> Launchpad bug 181416 in wordpress "SQL injection vulnerability in wp-includes/query.php in WordPress CVE-2007-6318" [Undecided,Confirmed] https://launchpad.net/bugs/181416
[13:17] <mok0> persia, and in https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003046.html
[13:17] <Aloha> gotcha
[13:17] <ion_> It’s just orders of magnitude slower than git. :-(
[13:18] <Aloha> so its made by "ubuntu"
[13:18] <\sh> Aloha, nope
[13:18] <\sh> Aloha, it's sponsored by canonical ;)
[13:18] <Aloha> oh sponsored, gotcha
[13:18] <persia> mok0: Yes, but that wasn't the ideally targetted forum (although still a good request).
[13:18]  * \sh 's busy with gnucash
[13:19] <\sh> ScottK, what wasn't working in pbuilder-dist?
[13:19] <mok0> persia: working in this communtity has taught me that patience pays off :-)
[13:19] <ScottK> \sh: I'm not sure, but laserjock was saying he wrote a new script because it wasn't working for him.
[13:20] <ScottK> \sh: Something wrong with create, so if you can make a new pbuilder, then I think it's fine.  Might be worth a quick test.
[13:20] <\sh> ScottK, ok...I'll test after gnucash
[13:20] <ScottK> OK.
[13:21] <\sh> and if anybody has experience with crystalspace, I would like to ask for some testbuilds of new upstream....looks like it's broken somehow but I don't have any clue about it
[13:23] <mok0> There's actually a build machine called "hooker"...
[13:24]  * \sh has his own build machine ;)
[13:24] <ScottK> mok0: I choose to assume it's named after General Hooker.  http://en.wikipedia.org/wiki/Joseph_Hooker
[13:25] <mok0> ScottK: Oh, of course :->
[13:25] <ion_> One of my keyboards (as in, the ones with black and white keys that play sound) has a controller titled “Bender”.
[13:26] <\sh> ion_, I think the "Bender" name for the "make sound keyboards" are older then the name of Futuramas Bender ;)
[13:26] <\sh> "Good News Everyone" !
[13:26] <mok0> "Building bender in hardy on hooker" :-P
[13:26] <ion_> It’s just called “Pitch Bend” in every other keyboard i’ve seen. :-)
[13:28] <\sh> well...looks like we get a new gnucash version soon....after the gconf fix it's building again ;)
[13:29] <Aloha> in apt-get source how do i get an earlier package version, such as hello-debhelper-2.1.1 instead of 2.2?
[13:30] <persia> ion_: I've seen "mod" and "twist" as well.
[13:32] <\sh> ScottK, do you still want to have quilt introduced in gnucash fixing *.desktop* files?
[13:34]  * persia encourages fixing .desktop files, but wonders if it is really worth quilt
[13:35] <\sh> persia, I agree...packages without any patch system where we have to add some trivial fixes could be still be made inside diff.gz
[13:35] <\sh> but I asked better ScottK because he introduced quilt in gnucash ;)
[13:35] <persia> \sh: Depends on the maintainer.  If a maintainer always uses patch system X, and we know that, and we introduce a change, using patch system X is the best way to do that.
[13:36] <\sh> persia, there was no patch system before and after ;)
[13:36] <AnAnt> persia: so, all I have to do is remove the Vcs-* fields ?
[13:37] <\sh> and there are two changes left...libungif4-dev -> libgif-dev and the desktop fixes
[13:37] <AnAnt> persia: and still keep the package source in the current SVN repository ?
[13:37] <persia> AnAnt: That would suit me.  My objection is to specifically asking people editing the package to use the VCS repo, and not granting them access by default.
[13:38] <AnAnt> persia: ah, ok
[13:38] <persia> With LP, it's easy to add the ubuntu-dev group, but externally, it's hard.  If the packaging isn't listed as being in a VCS, people just commit changes to the repo.  Maybe a little harder for you to track, but less confusing for normal package maintenance.
[13:41] <Aloha> wohoo almost done building my first source package
[13:41] <AnAnt> persia: ok, and the svn URL would be mentioned in copyright ?
[13:42] <persia> AnAnt: Well, that gets back to whether it is a native package.  If you downloaded it from some upstream, it isn't native, and shouldn't be treated as such.  If it is native, then there's no upstream from which to download it, and it wouldn't get put in debian/copyright.  Personally, I don't like native packages (and really appreciate the way the mythbuntu team does their packages)
[13:44] <StevenK> Grumbles.
[13:45]  * StevenK wonders how to join lines from stdin
[13:45] <jpatrick> stdin: you around?^^
[13:45] <persia> StevenK: Do you mean like a zipper mixing stdin and a file, or just push a stream onto a single line?
[13:46] <StevenK> persia: Not exactly. I have 1 2 3 4 on seperate lines, and I want to end up with 12 34 on seperate lines.
[13:46] <StevenK> I thought paste could it, but it seems it can't
[13:47] <persia> StevenK: awk can do that.  Now I have to go look for my scripts.  Given your preferences for newfangled human-readable languages, you might find perl easier (only chomp every other input line)
[13:48] <StevenK> Since the script is in shell, I'd rather not pipe to Perl
[13:48] <\sh> awk != human readable ?
[13:49] <StevenK> Since if I'm going to end up piping to Perl, I may as well rewrite the script in Perl
[13:51] <persia> StevenK: awk '/$/ {sub(/\\$/,""); getline t; print $0 t; next}; 1'
[13:51] <persia> Note that this works by accident in a way, as it just grabs the second line when the first terminates, and then skips the actual processing of the second line, as it was already grabbed.
[13:52] <ScottK> \sh: You can be confident that if I introduced a patch system, it wasn't quilt.
[13:52] <StevenK> Haha
[13:52] <\sh> ScottK, ohj well...it was siretart indeed...sorry scott ;)
[13:52] <zul> heh dpatch is worse
[13:53]  * persia suggests that the best patch system is that which allows the person adding patches to have an easy workflow, and is rarely the same for any two parties.
[13:53] <ScottK> Well without dpatch-edit-patch it'd be painful, but with it is pretty easy.
[13:53] <\sh> ScottK, quilt is also not so difficult .. well, when you understand how it works, sure
[13:54] <ScottK> \sh: Yes.  I think if I used it regularly it would be OK.
[13:54] <StevenK> Agreed. I sat down and fleshed out how to write a quilt patch
[13:54]  * TheMuso prefers dpatch.
[13:54] <\sh> not forgetting to set  QUILT_PATCHES=debian/patches that is ;)
[13:55] <\sh> but I set this shell var now as default in ~/.bashrc
[13:57] <siretart> \sh: I did what?
[13:57] <\sh> siretart, introduced quilt in gnucash
[13:57] <LucidFox> persia> Sorry, I was away
[13:57] <siretart> bad siretart
[13:58] <AnAnt> I use quilt
[13:58] <LucidFox> I will try running combinediff right now and see if I can reproduce your problem
[13:58] <\sh> siretart, but you never activated it, that was pkern ;)
[13:59] <siretart> lol
[13:59] <\sh> well, I'd remove it again, because the fixes are trivial...
[14:04] <\sh> oh pbuilder-dist is so broken
[14:06] <\sh> ah
[14:06] <\sh> fixing it ,)
[14:10] <\sh> oh nice
[14:10] <\sh> how to fix this
[14:11] <\sh>  $( [ -z $BINARCH ] || echo "--debootstrapopts \"--arch\" --debootstrapopts \"$BINARCH\"" ) gives
[14:11] <\sh> --debootstrapopts '"--arch"' --debootstrap '"i386"' which failes
[14:20] <mruiz> jono: Hi!  Any advance about LoCo Council ?
[14:20] <mruiz> ups... wrong channel
[14:28] <\sh> gnucash new upstream uploaded
[14:29] <\sh> and hopefully found a fix for pbuilder-dist create
[14:33] <norsetto> heya all
[14:35] <slytherin> man-di: Did you forwarded info about lucene2 to whoever was facing the problem?
[14:35] <mok0> yo, norsetto!
[14:36] <ScottK> Hello norsetto.
[14:36] <norsetto> hey guys
[14:38] <Aloha> what is acceptable in the "section" area of my .changes file?
[14:38] <TheMuso> Hey mok0, norsetto.
[14:38] <norsetto> hey TheMuso
[14:38] <Aloha> i can't figure it out. i put unknown and gutsy and the ppa rejected them both
[14:38] <frafu> Hello, the last version of mousetweaks in revu is again the correct one. Could anybody please review it. Thanks in advance. http://revu.tauware.de/details.py?package=mousetweaks
[14:39] <Aloha> 4311a61ec1e32bc027b27736d858e6be 518 gutsy extra hello-debhelper_2.2-1.dsc for example
[14:39] <man-di> slytherin: yes
[14:39] <slytherin> man-di: Thanks. :-)
[14:39] <man-di> slytherin: and I have a plan when nothing happens in some timeframe
[14:39] <man-di> the package is really outdated anyway
[14:40] <slytherin> man-di: So what is the plan exactly. :-)
[14:41] <norsetto> would anybody have any pointer re. ubuntu/debian udev policies?
[14:41] <Aloha> ok changed to devel, lets see if that works
[14:41] <man-di> slytherin: NMU if really relly needed as it fixes an RC bug
[14:43] <slytherin> man-di: Which bug are you referring to?
[14:44] <man-di> slytherin: that w3c-dtd-xhtml bug
[14:44] <slytherin> man-di: Oh. I didn't know that was RC bug. :-)
[14:44] <man-di> that but is not
[14:44] <man-di> but it needs to be fixed to make lucene2 not FTPFS
[14:44] <man-di> so its indirectly RC
[14:44] <slytherin> ah, ok
[14:46] <\sh> well...what should I do now with a wrong /etc/pbuilder/pbuilderrc that's another reason why pbuilder-dist create failes...
[14:46] <\sh> looks like I have to imrpove the script...
[14:47] <slytherin> man-di: I am not sure if I already mention but lucene2 may build with GCJ. At least the core part built when I disabled the unit tests. I will try again once the dtd bug is solved and package synced in Ubuntu.
[14:48] <persia> slytherin: please subscribe me to the lucene2 sync bug if you get it fixed.  I have a personal interest in seeing that work.
[14:49] <slytherin> persia: Sure. once the w3c-dtd-xhtml package is fixed in debian and man-di uses my fix for lucene2 in debian. :-)
[15:00] <Hobbsee> oh noes, it's dholbach!
[15:01] <ion_> :-((((
[15:02] <mok0> Anyone know of a good versatile benchmark suite, that runs from a script?
[15:03] <persia> mok0: There aren't any.  Or, there are lots, but nobody agrees.
[15:03] <tuxmaniac> Hobbsee, dholbach
[15:03] <Hobbsee> hiya tuxmaniac
[15:03] <mok0> persia: I tried lmbench, but it requires a lot of interactive input
[15:04] <bddebian> Heya gang
[15:04] <mruiz> hi all!
[15:04] <mok0> I have the old Byte Magazine benchmarks in a tar.gz file. I don't think it's in the archives
[15:04] <bddebian> Hello mruiz
[15:04] <persia> Hey bddebian.  Did trustedqsl work for you?  Is survex the last one?
[15:04] <bddebian> persia: survex and ctsim are the hold-outs :(
[15:05] <bddebian> persia: Oh, and Hi :-)
[15:05] <persia> Right.  Have you tried survex 1.1?  I think ctsim is a lost cause, given the upstream response.  Similar reasoning led to dropping a few other packages (or just not building the WX GUI).
[15:07] <bddebian> persia: Not yet.  I asked wookey about it when I filed the RC bug ;-)
[15:07]  * persia cheers the power of RC bugs, and misses ajmitch
[15:08] <norsetto> heya dholbach !
[15:08] <persia> bddebian: Probably worth a shot.  Olly was at least interested, even if neither Phillip or I actually sent him a patch.
[15:09] <bddebian> persia: Well get to work man.. :-)
[15:11]  * persia is currently assigned 6 bugs, a library upgrade (and ensuing transition), REVU, and some upstream community work.  Maybe in a couple weeks, but FF nears...
[15:12] <bddebian> :)
[15:13] <emgent> malone  173153
[15:13] <ubotu> Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153
[15:17] <frafu> In fact, feature freeze is nearing and mousetweaks has not even passed revu yet. As the gui of mousetweaks is in the GNOME Mouse control panel, I wonder how long the main inclusion process will take!? I wonder whether there is a chance for mousetweaks to be shipped with hardy!?
[15:17] <kdub> anyone know of a program that still needs packaging, or a program that needs repackaging because the current version is too old? I have experience with making deb's but i might still need to look at the ubuntu standards page
[15:18] <LucidFox> kdub> you can look at needs-packaging bug in Launchpad
[15:18] <LucidFox> * bugs
[15:19] <kdub> LucidFox: hrm, thanks. i always seems to get lost trying to navigate around launchpad...
[15:19] <LucidFox> kdub> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&search=Search&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=needs-packaging&field.has_cve.used=&field.has_no_package.used=
[15:19] <LucidFox> find a package you like for which the bug is not assigned, assign it to yourself, and begin packaging
[15:20] <persia> There's a shorter URL: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[15:21] <kdub> thanks LucidFox and persia, its funny how i didnt find this in 20 minutes of looking for it
[15:21] <kdub> and this is a motu-newbie question, but once i get it packaged, i can come back here and have someone look over the package to get it in the repos?
[15:21] <persia> bddebian: Tracking down a reference shows Debian bug #418713 for your amusement
[15:21] <ubotu> Debian bug 418713 in trustedqsl "Please build against wxWidgets 2.6" [Wishlist,Open] http://bugs.debian.org/418713
[15:22] <LucidFox> kdub> You can upload it to REVU
[15:22] <persia> !revu > kdub
[15:22] <kdub> ah, very nice. i suppose i'll get to work then :-D
[15:23]  * persia notes that the last REVU day for hardy will be 4th February, so it may not be the best time to start as a new packager.
[15:23] <nixternal> hehe
[15:23] <persia> kdub: You may find the learning path easier with bugfixing (although you'll need to learn launchpad for that)
[15:23] <bddebian> persia: I know, I actually have an NMU prepared for it already ;-)
[15:23] <nixternal> boo
[15:24] <persia> bddebian: OK.  You just asked me before about the fix, and I happened across an old mail while searching for something else, and wanted to make sure the apparent closure in ~test1 hadn't kept it from your sight.
[15:24] <kdub> persia: i've been sifting through bugs already, but i've been mostly just trying to eliminate bugs people report that arent really bugs
[15:24] <LucidFox> Ubuntu has the concept of NMUs?
[15:24] <LucidFox> Or are you talking about Debian?
[15:24] <persia> LucidFox: When they are uploaded to Debian, yes :p
[15:25] <LucidFox> ah
[15:25] <jeromeg> hello
[15:25] <jeromeg> i'm trying to get an SRU for klavaro in Gutsy
[15:25] <jeromeg> bug 184112
[15:25] <ubotu> Launchpad bug 184112 in klavaro "[SRU] klavaro crash" [Wishlist,New] https://launchpad.net/bugs/184112
[15:26] <jeromeg> is my proposal ok ?
[15:26] <persia> LucidFox: And in a looser sense, when the Maintainer is set to a specific team (e.g. media, xubuntu, mozilla, etc.) it is considered good form to check with a member of the team before uploading for any significant changes.
[15:26] <LucidFox> I see.
[15:26] <persia> jeromeg: You probably want to subscribe ~motu-sru to that bug
[15:27] <persia> Further, you likely want to prepare a debdiff (or convince someone else to do so) for review.
[15:27] <jeromeg> persia: ok
[15:27] <jeromeg> i sucribed the wrong team
[15:27] <jeromeg> *suscribed
[15:28] <LucidFox> *subscribed :)
[15:28] <persia> jeromeg: It gets a little confusing.  Both teams are likely interested, although only one is actually responsible for reviewing the change.
[15:28] <jeromeg> persia: ok
[15:28] <jeromeg> LucidFox: thank you :)
[15:29] <norsetto> ping superm1
[15:30] <LucidFox> On an unrelated note, does it make sense to sync -1 from Debian if it's identical to -0ubuntu1? Or if it contains functionally the same changes?
[15:33] <persia> LucidFox: Little benefit to such a sync.  I usually skip those.  Some people like to sync them to make the Ubuntu variance appear less.
[15:34] <danbhfive> hello all, is this the correct channel to ask about MIME types and packaging?
[15:35] <\sh> hmmm
[15:35] <LucidFox> In this case, I'll wait for the new upstream release of SMPlayer, which comes in a week or two, get it into Debian first, and then sync.
[15:35] <\sh> some pakcages I uploaded are not showing up in hardy...strange
[15:37] <LucidFox> doko> I see you have uploaded icedtea to Debian - excellent work!
[15:37] <LucidFox> hopefully more Java packages can move to main now
[15:37] <persia> danbhfive: It is a reasonable forum to ask questions, but not the best place to ask for changes in handling.
[15:37] <nixternal> I am becoming more and more impressed with icedtea every day...I can build most of my standard java apps with it now, which is good
[15:38] <persia> nixternal: Try using it on ARM or Sparc
[15:38] <nixternal> hehe, no thanks!
[15:38]  * persia touts gcj
[15:38] <nixternal> gcj won't build any of my java apps
[15:38] <zul> what hangman? :)
[15:38] <nixternal> and if I forget to update-alternative and I have gcj, I am constantly cussing trying to figure out why it is broke :)
[15:39] <danbhfive> persia: I have a project that I created, and it needs packaging, and it needs a file-type association.  Knowing that, would you say this is the place?
[15:40] <persia> danbhfive: Depends on what you want.  You can ask a question here, but the actual mechanisms that drive it aren't managed by MOTU.
[15:41] <danbhfive> persia: I'm not sure I follow
[15:42] <persia> danbhfive: Just ask a question.
[15:43] <DaveMorris> persia: if the last Revu day is the 4th, how many are there between here and then.  Or have you got a link to a site with the dates on?
[15:43] <danbhfive> how do I set it up so that, when I double click certain text files, they are opened in my python script?
[15:43] <persia> DaveMorris: Happens every Monday, so there are two more.
[15:44] <dx9s_work> been stumped on this (have qt4-dev-tools 4.2.3-0ubuntu3 installed) "qt4-dev-tools:
[15:44] <dx9s_work>   Depends: libqt4-core (=4.3.2-0ubuntu3) but 4.3.2-0ubuntu3.1 is to be installed" when it wants to upgrade
[15:44] <persia> danbhfive: Assign them a MIME type, register the MIME type, and report that your app handles the MIME type in the .desktop file.
[15:44] <dx9s_work> is there a qt4-dev-tools 4.3.2-0ubuntu3.1 ?
[15:45] <persia> dx9s_work: Yes.  In gutsy-updates.
[15:45] <danbhfive> persia: well, I don't know how to do any of that, is there documentation on that stuff?  or can you explain it?
[15:46] <dx9s_work> persia, I have that in my source (did an upgrade from 7.04 Feisty) .. I suspect I am missing a line in /etc/apt/sources.list then...
[15:46] <persia> danbhfive: I'm not the best person to ask (I don't tend to do new packages).  The dh_installmime manpage suggests the mime-support and shared-mime-info packages may have some documentation.  The freedesktop.org website can help with the .desktop file.
[15:47] <persia> dx9s_work: Perhaps the line is missing in the chroot in which you are building?
[15:47] <dx9s_work> not a .deb maintainer.. end user here
[15:47] <danbhfive> persia: cool, thanks, I'll look into those
[15:48] <persia> dx9s_work: In that case, yes, likely /etc/apt/sources.list.
[15:51] <dx9s_work> persia, here is my current sources.list -> http://rafb.net/p/N7Nubr53.html
[15:52] <persia> dx9s_work: Strange.  I have no explanation.  Might check with someone who looks at those more frequently (possibly in #ubuntu) or register a question.
[15:52] <dx9s_work> persia, funny thing is similar setup at home ... and the dev-tools updated.. so it's weird
[15:53] <dx9s_work> I thing -motu was targeted at .deb packaging issues
[15:53] <dx9s_work> (and dependencies)
[15:53]  * persia encourages someone to review awn-extra-applets or opensg, even though it's not REVU day, because they have now missed two REVU days, and really need another pair of eyes.
[15:55] <dx9s_work> persia, do you know how to search the gutsy offical repos for .deb files then I can try to back trace it to a line that I might need to uncomment... those tools might be a part of a backport
[15:55] <jeromeg> pochu
[15:55] <\sh> ScottK, improve pbuilder-dist a bit so it's working now
[15:55] <jeromeg> :
[15:55] <\sh> s/improve/improved/
[15:55] <persia> dx9s_work: They should all be in Packages.gz
[15:56] <jeromeg> pochu: sorry. I was able to test scribes 0.3.3.3-1 and it seems to work fine.
[15:56] <persia> \sh: Any leftovers still broken?
[15:56] <jeromeg> pochu: may I ask for a sync ?
[15:57] <dx9s_work> persia, heh ... sorry to ask .. where is that file?
[15:57] <\sh> persia, I'll check the bug list before I push my changes
[15:58] <persia> dx9s_work: There should be one in every path three levels down from http://archive.ubuntu.com/ubuntu/dists/.  The correct answer depends on what you want.
[15:58] <LucidFox> Finally! mpeg4ip has passed NEW!
[15:58] <pochu> jeromeg: sure. Let me know the # and I'll ack it.
[15:58] <dx9s_work> persia, ty (semi-new to the whole .deb thing -- if you ask me anything about Slackware .tgz's I can answer it :) )
[15:58] <LucidFox> libmp4v2 builds unbroken at long last!
[15:58] <pochu> jeromeg: thanks for testing it!
[15:59] <jeromeg> pochu: np
[15:59] <persia> dx9s_work: Is there a semi-automated system to produce a .dsc from a .tgz?
[15:59] <jeromeg> pochu: oh I'll just test printing before submitting it
[15:59] <\sh> persia, fixed pbuilder-dist create, provide a sane source.list for --aptconfdir and remove $COMPONENTS_LINE which sadly didn't work (I wonder why) , added --http-proxy support and changed the $ARCHIVE workflow a bit, so it's possible to set $ARCHIVE before the pbuilder-dist call
[16:00] <persia> \sh: Although I have never used pbuilder and don't really intend to start, I commend your attitude towards fixing everything for a new upload :)
[16:00] <\sh> persia, hehe :)
[16:01] <ScottK> \sh: Good.  It's nice when stuff actually works.
[16:01] <LucidFox> no kde4libs on hppa? that's a shame
[16:01] <LucidFox> looking at the build log, it just segfaulted for no apparent reason
[16:02] <dx9s_work> persia, okay I can't answer that.. .dsc description files? mainly there is no standard method for dependency checking ... 3rd party tools that do okay but nothing perfect...
[16:03] <persia> dx9s_work: :)  That's OK.  I didn't really expect there to be one.
[16:03] <jeromeg> pochu: the print dialog causes the following erros in terminal but works: http://paste.ubuntu-nl.org/53036/
[16:04] <pochu> Do we need a bulb next to the new packages in REVU? It makes the rows too high
[16:05] <pochu> jeromeg: please go ahead. I don't think that's a regression, and I can't say that's scribes' fault...
[16:05] <persia> pochu: source is in LP :)
[16:05] <dx9s_work> persia, yeah, different methods for updates... some just hack the changelog file and apply them in order (slack-apt) and so forth.. but without dependency checking -- lot of tgz maintainers try to link the binaries to generic (symlinked) libs so instead of libBLAH.so.0.1.123 .. it's libBLAH.so.0 (or *.0.1) so updates don't break because of specific versioning.
[16:05] <pochu> jeromeg: and since it works ;)
[16:05] <jeromeg> pochu: ok :)
[16:06] <persia> pochu: If you're hacking, I'd like to see hearts for >1 advocates, bulbs for 1 advocate, glasses for 0 advocates, and hammers for rejections.  The two icon bit was more important when updates were going to REVU as well (now we use debdiffs & interdiffs).
[16:08] <pochu> persia: how do you reject a package in REVU?
[16:09] <mok0> persia: don't tell him
[16:09] <persia> pochu: A rejection happens when someone who is registered as a reviewer (as opposed to a contributor) leaves a comment without advocating.
[16:09] <persia> mok0: Better to tell him: otherwise he'll be rejecting my accident :(
[16:09] <jeromeg> pochu: bug 185106
[16:10] <ubotu> Launchpad bug 185106 in scribes "Please sync scribes 0.3.3.3-1 (universe) from Debian (unstable)" [Wishlist,New] https://launchpad.net/bugs/185106
[16:10] <pochu> jeromeg: thanks
[16:10] <jeromeg> pochu: np
[16:10] <mok0> :-)
[16:11] <smarter> hi
[16:11] <pochu> persia: I see, thanks
[16:11] <smarter> could someone please review my extremetuxracer package? :) http://revu.ubuntuwire.com/details.py?package=extremetuxracer
[16:12] <mok0> smarter: what's extreme about it?
[16:13] <persia> mok0: It's extremely better than the aging nearly abandoned upstream tuxracer we have in the archives
[16:13] <smarter> mok0: it crashes your computer if it doesn't like your graphic card :P
[16:13] <dx9s_work> persia, fixed it.. gonna compare the pasty to what I have now... not exactly sure which lines I've changed (used the gui -- which is nice, but text files are forever! *lol* )
[16:13] <smarter> tuxracer is not in the repo
[16:13] <smarter> ppracer is in the repo
[16:13] <smarter> and is dead
[16:13] <mok0> smarter: nice excuse for getting a new one :-)
[16:13] <persia> Ah.  Right.  We have planetpenguinracer
[16:14] <smarter> tuxracer is commercial now IIRC
[16:14]  * persia points at Debian bug #461911 as justification for extremetuxracer
[16:14] <ubotu> Debian bug 461911 in planetpenguin-racer "planetpenguin-racer is deprecated, please package Extreme Tux Racer" [Wishlist,Open] http://bugs.debian.org/461911
[16:14] <smarter> and bug #53299
[16:14] <ubotu> Launchpad bug 53299 in ppracer "RFP: Extreme Tux Racer" [Wishlist,In progress] https://launchpad.net/bugs/53299
[16:14] <TheMuso> How many changes does that game have to go through?
[16:15] <TheMuso> First tuxracer, then planet penguin racer, and now this.
[16:15]  * persia corrects the link relationship
[16:16] <persia> TheMuso: Better than most games.  At least in this case, someone always picks up the ball (or hill, depending on how you look at it)
[16:16] <dx9s_work> persia, think it was in universe someplace
[16:16] <TheMuso> persia: True.
[16:17] <\sh> bug #175183 also fixes
[16:17] <ubotu> Launchpad bug 175183 in ubuntu-dev-tools "pbuider-dist fails to create chroot" [Medium,Confirmed] https://launchpad.net/bugs/175183
[16:17] <\sh> -s+d
[16:17] <mok0> smarter: the first thing I do when playing with a new program is to look at the man page. I think your etracer.6 is very short and you may want to sell the program better.
[16:17] <\sh> and bug #172943
[16:17] <ubotu> Launchpad bug 172943 in ubuntu-dev-tools "pbuilder-dist: Optionally allow to use gksudo instead of sudo" [Wishlist,Triaged] https://launchpad.net/bugs/172943
[16:18] <smarter> mok0: well, I basically copy&paste the ppracer man page
[16:18]  * dx9s_work thanks persia  (even tho not much help, it still was enough)
[16:18] <smarter> I'm not very good at doing that ^^'
[16:18] <mok0> smarter: add some of your own enthusiasm for the program
[16:19] <smarter> mok0: I can try ;)
[16:19] <mok0> smarter: why is it better than tuxracer? Is the graphics good? Sound? Music?
[16:19] <mok0> smarter: game play? tell about how tuxracer is cult
[16:20] <mok0> smarter: tell the story of tuxracer, how it developed into extreme
[16:20] <mok0> smarter: what graphics cards are supported
[16:21] <smarter> that's a manpage, not a complete review :o
[16:21] <mok0> smarter: brief description of key bindings
[16:21] <sistpoty|work> mok0: why should that be in a man page?
[16:21] <smarter> and I don't think there's a list of supporter graphic card
[16:21] <mok0> sistpoty|work: because it's nowhere else and he should sell the program
[16:21] <mok0> IMHO anyway...
[16:22] <sistpoty|work> mok0: the (long) discription is for that... in the man page I expect to find information on how program options, eventually directories or controls of it
[16:22] <persia> sistpoty|work: There are lots of manpages with amusing history.
[16:23] <smarter> Is there a good (Qt) manpage editor?
[16:23] <mok0> sistpoty|work: I am not saying that information should not be there
[16:24] <pochu> persia: hearts for >1 or >=1 advocates? I think the later is better, don't you?
[16:24] <mok0> smarter: if you don't like to edit manpages, check out asciidoc, you can generate man pages from a simple layout
[16:25] <mok0> smarter: it's just my opinion, anyway, and I am not a MOTU ;-)
[16:25] <persia> pochu: adv<0:hammer, adv=0:glass, adv=1:bulb, adv>1:heart would be my thought.  "Needs work", "Needs a look", "Turned someone on", "We love it"
[16:27] <pochu> persia: hmm, advocates < 0 ? Does REVU adv -= 1 when you don't advocate a package?
[16:27] <sistpoty|work> pochu: nope, adv=0 can never hapen
[16:27] <persia> pochu: Not really, but when a MOTU leaves a comment and doesn't advocate, it counts as negative advocation in a way (and no, this isn't how the code works)
[16:27] <sistpoty|work> +p
[16:28] <persia> sistpoty|work: Hrm?  Do you mean to say that when a MOTU comments, the state changes (and this cannot be prevented), or that there can never be 0 advocations for a candidate?
[16:29] <frafu> TheMuso: I would like to let you know that I managed to upload the correct version of mousetweaks a second time to revu. So if you still intend to review it (which would be nice), you can simply pick the most recent upload.
[16:29] <sistpoty|work> persia: no, I just wanted to say that my brain (which says kvirc as irc client->german keyboard layout) is making me heavy trouble here at work, where I have a us layout *g*
[16:29] <TheMuso> frafu: I know, I will do my best to get to it, however I am somewhat busy.
[16:30] <persia> sistpoty|work: I completely understand.  My current client has a US layout, which means I tend to pair "*...(" far too often :)
[16:31] <sistpoty|work> persia: so there can never be adv<0, but negative advocations add the hammer (= motu comments w.o. advocate flag set) iirc
[16:32] <persia> sistpoty|work: Right.  pochu's point was that double icons made the page too long.  Given that we discourage existing packages on REVU now, I agreed it made sense to consolidate, and suggested trying for a patch.  (While I'm sure you've enjoyed your recent monopoly on REVU work, I suspect you wouldn't mind a bit of help)
[16:32] <frafu> TheMuso; thanks; should I perhaps ping dholbach, who is also motu and a member of the accessibility team (at least I think so) ?
[16:33] <persia> frafu: You just did :)
[16:33] <TheMuso> frafu: He doesn't do accessibility stuff any more.
[16:33] <dholbach> frafu: I'm a bit busy right now, sorry
[16:33] <sistpoty|work> persia: sure, every patch is welcome :)
[16:33] <TheMuso> dholbach: I will get to it in due course.
[16:34] <dholbach> frafu: I'm not member of the team anymore
[16:38] <jeromeg> persia: could you please have a look at bug 185112 ?
[16:38] <ubotu> Launchpad bug 185112 in torcs "Please sync torcs 1.3.0-2 (universe) from Debian (unstable)" [Wishlist,New] https://launchpad.net/bugs/185112
[16:38] <frafu> dholbach; I just got informed about it; thanks nevertheless for your willingness to do it if you had time; TheMuso: thanks for you doing it. I won't disturb you (both) any longer
[16:38] <jeromeg> persia: i think that the delta you introduced in 0ubuntu1 has been applied to -2 in debian
[16:38] <DaveMorris> can you make a package the same across multiple releases.  i.e. I have a almost 1GB doc package, can you make it so it appears only once in the repo?
[16:39] <persia> jeromeg: I can still crash torcs with a broken sound configuration despite the supposed fix for Debian bug #445806.
[16:39] <ubotu> Debian bug 445806 in torcs "Torcs can crash if OpenAL is unable to open a sound device" [Wishlist,Fixed] http://bugs.debian.org/445806
[16:39] <smarter> I can make a cooler manpage if it's really important but if someone could review my package before I upload again the ~30MB I'll appreciate :) http://revu.ubuntuwire.com/details.py?package=extremetuxracer
[16:39] <jeromeg> persia: but it looks like the patches are the same
[16:39]  * persia looks again
[16:40] <pochu> DaveMorris: I don't think so.
[16:40] <desertc> Greetings grand MOTU.  Thank you for your support of Ubuntu.  It continues to be the best operating system anywhere.  May I ask your attention on a package issue?
[16:40] <desertc> http://packages.ubuntu.com/gutsy/graphics/scribus
[16:41] <desertc> The standard operating procedure in #scribus is to instruct all Ubuntu users to this page, when they say the packaging for Scribus is incorrect in Ubuntu:
[16:41] <desertc> http://wiki.scribus.net/index.php/Getting_Scribus_on_Ubuntu/Kubuntu_up_and_running
[16:41] <persia> jeromeg: Ah.  Yes.  I previously played with the xrandr change, and didn't sync because I didn't think the try/catch clause was also included.  Thanks for bringing it to my attention.
[16:41] <cyberix> persia: Does my new copyright file look ok to you? http://revu.tauware.de/revu1-incoming/malbolge-0801211640/malbolge-0.1.1/debian/copyright
[16:42] <jeromeg> persia: shall i suscribe ubuntu-universe-sponsors or you will take care of the ACK ?
[16:42] <persia> cyberix: Yep.
[16:42] <persia> jeromeg: I'm building it now :)
[16:42] <persia> (plus I get to fix it when it breaks, so ...)
[16:42] <jeromeg> persia: i know i should have asked you before filling the bug but i id things the other way round :)
[16:43] <jeromeg> persia: ok
[16:43] <desertc> The channel admins have said they were unable to get MOTU managers to correct these issues, and they are requesting all Ubuntu users to obtain different versions of the program, instead of the Ubuntu packaged software.
[16:43] <persia> jeromeg: Don't worry about asking me for any of my syncs or merges.  I'm subscribed to bugmail for any packages I'm actually interested in, so I see them anyway, and I'm not very concerned about the size of my +packages
[16:44] <desertc> Is there a representative who can seek clarification in #scribus?  I can see you look very busy, of course.
[16:44] <jeromeg> persia: ok
[16:44] <persia> jeromeg: On the other hand, feel free to ask me any questions about said syncs or merges :)
[16:44] <jeromeg> persia: i just wanted to train a little and do a merge, but in fact I realised it could be synced :)
[16:45] <persia> desertc: I'll visit (although I may not be able to provide a satisfatory explanation)  Please introduce me
[16:45] <desertc> persia: right
[16:47] <zul> StevenK: ping
[16:47] <persia> jeromeg: Processing a merge and discovering a sync is a great way to do that :)
[16:48] <jeromeg> persia: yep, but to not for training to merge packages :)
[16:49] <TheMuso> zul: another 7 hours or so I'd say and he'll be around
[16:49] <zul> damn it
[16:51] <persia> jeromeg: I recommend checking the Debian list of recently closed RC bugs in combination with multidistrotools to find a good source of merge bugs.  The RC bugs tracker is down right now, so it's a bit manual.
[16:52] <jeromeg> persia: i use DaD or MoM
[16:52] <jeromeg> persia: got to go
[16:52] <jeromeg> persia: please let me a comment on the bug report if something is wrong, but for me it builds fine
[16:52] <persia> jeromeg: Those are also useful tools, but not so good at finding the ones that really need the merge.
[16:53] <jeromeg> persia: ok
[16:53] <persia> jeromeg: I'll be advocating after a couple laps (after scribus).  Thanks again
[16:53] <jeromeg> persia: np, thanks.
[16:54] <jdong> LucidFox: I see mpeg4ip pushed thru NEW, have you commenced rebuilds yet? (I'd be happy to do em right now)
[16:55] <jdong> superm1: ooh oooh oooh! new monodevelop!!!!!!! THANKS!!!
[16:55] <jdong> (yeah yeah I just got some dental word done, so deal with intoxicated jdong for a while)
[16:55] <LucidFox> jdong> mpeg4ip hasn't reached the archive yet
[16:56] <LucidFox> gtkpod-aac briefly exited and re-entered depwait when it hit DONE
[16:56] <jdong> LucidFox: ah, ok
[16:56] <LucidFox> faac is also in depwait, so both it and gtkpod-aac should be rebuilt automatically
[16:57] <jdong> LucidFox: ok, let's wait for faac to build, then I'd like to prod through mpeg4ip again with libfaac-dev enabled
[16:57] <LucidFox> ah
[16:57] <jdong> I'm afraid pushing it through right now would put us back at circular dep world :D
[16:57] <LucidFox> you could also sponsor avidemux 2.4.0 :)
[16:57] <LucidFox> after faac builds, that is
[16:58] <jdong> LucidFox: sure, we'll take a look at that soon :)
[16:58] <jdong> ok looks like I should take this shiny new loaner car out for another spin (literally) in the snow :)
[16:59] <jdong> hopefully in an hour when I get back there'll be productive things to do :)
[17:06] <emgent> hello people
[17:06] <sistpoty|work> hi emgent
[17:11] <TheMuso> persia: You're up late.
[17:11] <persia> TheMuso: Far too late :(
[17:19] <superm1> jdong, :)
[17:20] <LucidFox> Well, at least it appears I have an excuse for the removed build-dependency of f-spot on beagle.
[17:21] <LucidFox> "f-spot is in main, and beagle has been demoted to universe"
[17:27] <RainCT> Hi
[17:27] <TheMuso> Hey RainCT.
[17:28] <\sh> RainCT, I fixed some stuff in pbuilder-dist and added some new functionality...(sudo replacements included)
[17:28] <RainCT> mruiz: is it still necessary to modifiy gnome-chess.install now that you've patched the Makefile?
[17:30] <RainCT> \sh: I know. If it was already commited I'd have told you that you're my hero ;P
[17:31] <\sh> RainCT, just testing the packaging...included even the bash completion;)
[17:31] <mruiz> RainCT, I don't think so... I'll fix it
[17:33] <RainCT> \sh: great! :) (but next team please ping me if you work on some bug assigned to me.. if I hadn't had exams I would have already started working some of those)
[17:33] <\sh> RainCT, I tried...;)
[17:33] <\sh> RainCT, ok...I'll push the changes now to bzr
[17:34] <RainCT> (altough I realize they shouldn't be assigned to me until I really start working on them :P)
[17:34] <RainCT> heh
[17:34] <\sh> and if someone has time please test them...before I create a new upload thx :)
[17:34] <RainCT> I'll do so now :)
[17:35] <\sh> ok..rev 60 is just coming up :)
[17:36] <\sh> RainCT, but if you checkout...check your COMPONENTS_LINE code it doesn't work...I fixed it through introducint --aptconfdir with sane sources.list
[17:37] <foolano> hi
[17:37] <foolano> what's the next step after uploading a package to REVU?
[17:38] <foolano> waiting for review?
[17:38] <sistpoty|work> foolano: yep
[17:38] <sistpoty|work> foolano: you can also post a link to your upload right here, maybe s.o. is interested in reviewing ;)
[17:39] <foolano> ok i c
[17:39] <pochu> sistpoty|work, persia: I'm with the REVU patch, and I have a little question. Actually for a package, new = True if it has >= 2 advocates in case it's a new package, or >= advocates in case it's an update. Since we don't want package updates in REVU anymore, does it still make sense to do that distinction?
[17:39] <\sh> RainCT, should be up now...but I don't see the changes on LP until now
[17:40] <RainCT> foolano: yes. if it's Monday somewhere on the world annoy people here asking for review (but only a little bit :P), and if it isn't Monday you can ask anyways :P
[17:40] <sistpoty|work> pochu: feel free to drop that
[17:41] <persia> pochu: Not really.  All the more so because the NEW package checking is a little odd (it only checks at the time of the first upload, so any package first on REVU shows as NEW)
[17:41] <foolano> I've just uploaded two perl modules to REVU we are using in eBox:
[17:41] <foolano> http://revu.tauware.de/details.py?package=libnet-cups-perl
[17:41] <foolano> and http://revu.tauware.de/details.py?package=libtree-perl
[17:41] <sistpoty|work> persia: heh, the complete codebase is a little odd *g*
[17:42] <persia> sistpoty|work: For most use cases (especially when people follow the guidelines (which ought be properly written somewhere rather than passing as textual tradition here)) it works perfectly.
[17:43] <\sh> btw...we don't have this "don't advocate your own packages anymore", right?
[17:43] <pochu> sistpoty|work, persia: sorry, I meant isReady = True if ... So I'll change it to "isReady = advocates > 1" always (without checking whether it's a new package or not). I think that will discourage people to submit updates to REVU, as that means the need 2 acks to get a heart and not 1 as now :)
[17:44] <persia> pochu: Maybe, but the fact that someone checks the packages once every couple weeks, and rejects all the non-NEW packages with a comment helps too :)
[17:44] <persia> pochu: And thanks for helping with the code :)
[17:45] <roderik> I'm having a litte problem creating a rules file that compiles one mono .exe file and installs it in /usr/bin. In build I do " gmcs -out:$$(pwd)/debian/tmp/usr/bin/mmcl.exe" but when running in binary-arch " install -m 755 -T debian/tmp/usr/bin/mmcl.exe  /usr/bin/mmcl.exe" i get a permission denied when building it in pbuilder? This seems strange since the thing uses fakeroot?
[17:45] <\sh> RainCT, and for the --debootstrapopts subshell call, it wasn't working, too, just setting it by default helps a lot and doesn't matter even for the main arch
[17:45] <pochu> persia: my pleasure :) I hope I do more reviews after this is applied... And next thing will be the cookies issue ;)
[17:46] <\sh> btw..when someone reviewed and added a comment, please redirect them to the very same page, if not, press "reload" in your browser, and you have another comment send ;)
[17:50] <RainCT> \sh: I see it's currently priting everything it does (set -x).. forgot to remove this? :P
[17:50] <\sh> argl
[17:50] <\sh> moment
[17:50] <\sh> well...if it works I'll remove it with the next push;)
[17:52] <\sh> oh wow..build failures in gnucash, something I didn't see on amd64
[17:53] <RainCT> \sh: and.. are you saving the sources.list in $BASE_DIR/etc for some reason? (unless I'm overlooking something, I think it would be better to just create it in /tmp and remove it afterwards)
[17:54] <\sh> RainCT, nope...I added --aptconfdir for it...it gives the user the possibility to add even alien archives ;)
[17:54] <sistpoty|work> pochu: sorry, was afk for a moment... as persia wrote: just get rid of that code fragment, I don't think we'll need it any longer
[17:55] <\sh> RainCT, depending on the ubuntu release...for hardy just the default line, for dapper|edgy|feisty|gutsy it enables even the security and updates archive for the pbuilder
[17:58] <RainCT> \sh: «it gives the user the possibility to add even alien archives»   wouldn't the file be overwritten before running pbuilder anyways?
[17:59] <\sh> RainCT, ha...fixing ;)
[17:59] <RainCT> \sh: heh.. now it makes more sense :)
[18:00] <\sh> RainCT, ok..fixed
[18:03] <RainCT> \sh: a last complaint (well, actually it's a suggestion).. what's about looking at $PBUILDAUTH before $DESKTOP_SESSION, to allow people to use arbitrary commands (like using sudo even if they are in GNOME, or run gksudo with -g)?
[18:05] <\sh> RainCT, where is pbuildauth coming from?
[18:06] <rzr> hi
[18:06] <RainCT> \sh: it would be a new variable, that users could set in .bashrc or wherever (like there is $PBUILDFOLDER already)
[18:06] <\sh> RainCT, ah :)
[18:06] <rzr> i was wondering, how command reportbug  is working on ubuntu ?
[18:07] <\sh> RainCT, good idea :)
[18:07] <RainCT> \sh: in bash_completion: «options='create update build login execute dumpconfig'» => «options='create update build clean login execute'»  (and you forgot to change the header) :)
[18:07] <RainCT> \sh: ok, that's all; now I'm happy :P
[18:07] <\sh> RainCT, fixing :)
[18:09] <\sh> RainCT, cool...ok PBUILDAUTH support added
[18:09] <pochu> sistpoty|work, persia: bug 185133 :)
[18:10] <ubotu> Launchpad bug 185133 in revu "Improve package images so that there is just one image per package" [Undecided,New] https://launchpad.net/bugs/185133
[18:11]  * LucidFox pings nixternal
[18:12] <LucidFox> nixternal> looking at the kblogger-kde4 package, cmake.mk has been integrated into cdbs proper, so there's no need to ship it with the package
[18:12] <\sh> RainCT, pushing
[18:13] <jpatrick> LucidFox: I believe the all KDE4 packages se a different version
[18:14] <nixternal> LucidFox: they have fixed the bug then? the reason behind including cmake.mk in debian/cdbs is because of that...all of our KDE 4 packages come with that cmake.mk
[18:14] <LucidFox> ah
[18:14] <nixternal> there is a bug in debian, or was a bug in debian, that broke cmake builds
[18:14] <mruiz> RainCT, I uploaded a new debdiff
[18:15] <RainCT> mruiz: seen it :)
[18:15]  * nixternal checks out debian kde4/cmake repo
[18:20] <\sh> if nobody has objections, I will create a new upload for ubuntu-dev-tools
[18:22] <sistpoty|work> pochu: excellent, thanks...
[18:22] <sistpoty|work> pochu: I'm not entirely sure, if I'll find the time to look at the patch in detail this evening though
[18:22] <\sh> dholbach, ping do you have something for ubuntu-dev-tools which needs to be bushed to trunk?
[18:24]  * sistpoty|work needs to go home now
[18:24] <sistpoty|work> cya
[18:24] <_MMA_> ScottK: Is bzrtools set to be backported from hardy as well?
[18:24] <ScottK> _MMA_: I don't know.  I haven't been doing that one.
[18:25] <foolano> I've just realised that I uploaded the package as a debian-native package. I already fixed that with the proper .orig.tar.gz  and stuff. How should I proceed to update the one which is uploaded in REVU?
[18:25] <dholbach> \sh: no, I don't
[18:25] <\sh> dholbach, ok...preparing a new package then
[18:25] <_MMA_> Ok. Ill have to find out who.
[18:27] <emgent> heya dholbach
[18:28] <ScottK> foolano: Just upload the new package should be enough.
[18:29] <foolano> ScottK: do i have to increase the package version?
[18:29] <ScottK> foolano: No.
[18:30] <foolano> ok thanks
[18:35] <AnAnt> persia: Hello, I just uploaded a new versio of ubuntume-gdm-themes, I hope you would review it
[18:35] <AnAnt> brb
[18:36]  * norsetto -> dinner
[18:38] <desertc> If an application developer wants to work with Ubuntu to improve their packages, what is the official channel of communication?
[18:38] <desertc> Is there a better way to communicate than just submitting a bug-fix request?
[18:38] <ScottK> desertc: Is it in Universe or Main?
[18:38] <\sh> Accepted: ubuntu-dev-tools 0.25 (source)
[18:38] <desertc> Universe, please
[18:39] <ScottK> desertc: Show up here and discuss it has worked in the past (spe being the most recent example).
[18:39] <desertc> Thank you.
[18:41] <\sh> hmm...
[18:42] <\sh> how can I fix this: /usr/bin/ld: .libs/Transaction.o: relocation R_X86_64_PC32 against `mark_split' can not be used when making a shared object; recompile with -fPIC
[18:42] <ScottK> Add -fPIC to the compiler options?
[18:42] <\sh> ScottK, already did...
[18:42] <ScottK> Oh.
[18:42] <\sh> no change...added it to the makefile.am as well, rerun autofoo
[18:43] <\sh> no change
[18:43] <\sh> ah wait..-fPIC is LDFLAGS or CFLAGS?
[18:43] <ScottK> Does the package that provides R_X86_64_PC32  need to be recompiled with -fPIC?  Don't recall.
[18:44] <\sh> ScottK, problem is , how do I determine this?
[18:44] <\sh> which package or which lib ;)
[18:44] <broonie> That's not a name of a symbol, it's a type of relocation but yes, check that whatever it links against isn't busted.
[18:44] <CyberMatt> https://bugs.edge.launchpad.net/ubuntu/+bug/164213 Is there somthing i can do about this
[18:44] <ubotu> Launchpad bug 164213 in ubuntu "[need-packaging] burnstation" [Wishlist,Triaged]
[18:45] <\sh> broonie, what's the easiest way? I think it was introduced in a gnome* upload today somehow
[18:45] <CyberMatt> upstream debian/ upstream = AFK
[18:45] <CyberMatt> freeze soon
[18:46] <broonie> \sh: Off the top of my head, peer at things with readelf -a
[18:46] <\sh> broonie, thx :)
[18:49] <\sh> ok...it looks like on i386 it's not failing...only amd64
[18:50] <broonie> i386 will never get this sort of error, there are so few registers that everything ends up being PIC anyway.
[18:51] <\sh> broonie, I think something was broken by the new gconf upload...which fixed a pkgconfig bug
[18:52] <\sh> broonie, to early for success: ../../src/engine/.libs/libgncmod-engine.so: undefined reference to `mark_split'
[19:00] <warp10> If upstream ships a debian/ within the tarball, what's the best to do if I want to package it?
[19:10] <CyberMatt> warp10, you ask upstream to rm it and if thet don't...
[19:11] <CyberMatt> thats what i'm trying to figure
[19:12] <blueyed> warp10: https://wiki.ubuntu.com/UbuntuDevelopment/FAQ#head-bfd54122250e4e424158dd506e4117dab25f0d21
[19:12] <CyberMatt> i suppose you could hack up getorig-source but I'm lazy
[19:13] <warp10> blueyed: yeah... I was looking for that page, read the whole Pacakging Guide and forgot UbuntuDevlopment/ :-S
[19:13] <warp10> CyberMatt, blueyed: thanks
[19:14] <CyberMatt> blueyed, thanks for finding that
[19:14] <jdong> ooh looks like faac is built in several arches already
[19:14] <CyberMatt> i knew it was there
[19:14] <jdong> well onwards and upwards!
[19:14]  * jdong breaks the rest of the media stack
[19:15] <CyberMatt> warp10, what are you packing just curious
[19:15] <\sh> ok...found why gnucash ftbfs
[19:15] <CyberMatt> \sh, now i can die happy :)
[19:16] <CyberMatt> not really
[19:16] <\sh> CyberMatt, well, I hope it's what I think is buggy ;)
[19:16] <warp10> CyberMatt: Bug #185125
[19:16] <ubotu> Launchpad bug 185125 in ubuntu "[needs-packaging] AutoZen" [Undecided,New] https://launchpad.net/bugs/185125
[19:16] <CyberMatt> cool
[19:18] <blueyed> sounds interesting.. :)
[19:18] <jdong> superm1: what are your rhoughts on restoring faad and faac build deps on mpeg4ip?
[19:18] <superm1> jdong, i'm scared
[19:18] <jdong> superm1: shall we just sit quietly and don't do it till someone figures it out and complains on LP?
[19:18] <warp10> CyberMatt, blueyed: indeed. I didn't think such a software could exist :)
[19:18] <superm1> i dont like circular dependencies
[19:19] <jdong> superm1: Marillat had them both enabled for ages without any significant complaints
[19:19] <jdong> (circular deps aren't my friend either :D)
[19:19] <superm1> well in my last email to him he is dropping one of them
[19:19] <superm1> i forget whihc
[19:19] <jdong> superm1: he dropped faac
[19:19] <jdong> superm1: honestly I don't care about either :D
[19:19] <superm1> are faac and faad rebuilt yet?
[19:19] <jdong> superm1: so let's just sit tight and see if anyone on LP complains about its absence
[19:19] <jdong> superm1: they are partially rebuilt (not all arches)
[19:19] <superm1> oh okay
[19:20] <superm1> jdong, you going to handle queuing rebuilds for other stuff?
[19:20] <superm1> or you want me to grab anything?
[19:21] <jdong> superm1: you just keep mplayer happy, idn where you keep track of all that stuff, I'll try to grab the rest ;-)
[19:21] <superm1> jdong, haha okay
[19:21] <superm1> i'll upload it with a versioned build depend then
[19:23] <jdong> okies
[19:26] <ScottK> jdong: Clamav backport to Dapper is kicked off.
[19:26] <superm1> bah... someone updated mplayer without updating bzr
[19:26]  * ScottK listens to the Dapper Buildd's groan as they wake up.
[19:30] <\sh> G_INLINE_FUNC was the bugger for gnucash
[19:31] <pochu> \sh: are you working on gnucash? Did you see bug 179104?
[19:31] <\sh> bug #179104
[19:31] <\sh> hmm
[19:31] <ubotu> Launchpad bug 179104 in gnucash "Please merge gnucash 2.2.3-1 from debian unstable" [Wishlist,New] https://launchpad.net/bugs/179104
[19:32] <pochu> My syntax was fine ;)
[19:32] <\sh> pochu, gnucash_2.2.3-1ubuntu2.dsc
[19:32] <\sh> pochu, already done...but forgot to set the closes syntax...please set it to fix commited
[19:34] <jdong> superm1: hmm maybe you should do a build check for forgetting to update the VCS and scream loudly :D
[19:34] <jdong> superm1: that would earn evil package of the year award :)
[19:34] <superm1> jdong, haha
[19:34] <superm1> yeah i like idea a lot
[19:34] <jdong> :D
[19:34] <superm1> i'm trying to find out who sponsored this right now
[19:35] <jdong> superm1: funny how LP really doesn't easily tell that :D
[19:35] <superm1> yeah
[19:37] <jdong> gpg: Good signature from "Jonathan Riddell <jriddell@ubuntu.com>"
[19:37] <jdong> superm1: ^^ :)
[19:37] <superm1> argh.
[19:37] <superm1> he should have known better
[19:37] <jdong> superm1: hard to yell at him though :D
[19:38] <superm1> yeah i know
[19:38] <jdong> superm1: though it'd be helpful to drop him a polite heads-up in case it comes up again
[19:38]  * superm1 really considers the VCS check during build
[19:38] <jdong> superm1: but the more I think about it, the more I think a debian/rules VCS check is a good idea
[19:39] <superm1> the problem is that no single package uses a VCS the same
[19:39] <superm1> and mplayer is a lot different than many
[19:39] <superm1> the way it does things
[19:39] <jdong> yeah
[19:39] <\sh> LaserJock, pbuilder-dist is working now ;)
[19:40] <ScottK> jdong and superm1: Since mplayer is maintained by MOTU and there's no MOTU workflow that requires VCS use, I think you've got nothing to complain about.
[19:40] <superm1> ScottK, its maintained by MOTU-media
[19:41] <jdong> ScottK: it's less about complaining/blaming than about wanting to make sure people are aware of the preferred process...
[19:41] <ScottK> superm1: OK.  I saw that and assumed it was MOTU (since that's how MOTU gets displayed in LP).
[19:42] <LaserJock> \sh: oh? good to know
[19:42] <superm1> jdong, i'm almost thinking of doing a check using bzr diff
[19:42] <ScottK> LaserJock: Riddell is executing the clamav backport now.  So far so good.  Thanks again.
[19:42] <\sh> LaserJock, pushed a new package to the archive...should be there soon
[19:42] <LaserJock> ScottK: awesome
[19:42] <\sh> ScottK, please let riddell do some syncs...;)
[19:42] <jdong> superm1: easier, bzr cat :)
[19:43] <jdong> superm1: just compare debian/changelog version numbers
[19:43] <superm1> that requires a filename
[19:43] <jdong> superm1: a diff would take too long
[19:43] <superm1> jdong, bzr diff is very fast
[19:43] <jdong> superm1: not if you don'w have the full version history
[19:43] <superm1> oh.  which i do :)
[19:43] <jdong> superm1: i.e. if I apt-get source mplayer, then you want to diff it to bazaar.lp.net, it'll take a century and a half
[19:44] <jdong> superm1: however, if you just cat the debian/changelog on bzr and diff it to the local one, that is pretty fast
[19:44] <superm1> yeah i was thinking locally, but that would take ages, and annoying to need the whole tree
[19:44] <superm1> can the buildd's access the intarweb during builds?
[19:44] <jdong> superm1: I'm thinking just md5sum the changelogs. requires no version history
[19:44] <jdong> superm1: skip the check if DEBMAIL is unset?
[19:45] <jdong> like what the maintainer spec does
[19:45] <superm1> so perhaps this is better added to devscripts directly
[19:45] <superm1> something to check for the vcs line in debian/control
[19:46] <jdong> superm1: that'd be nice
[19:46] <jdong> superm1: or if lintian can be modified to check VCS tags
[19:46] <superm1> jdong, okay i'll fix this and think about that some more
[19:47] <superm1> i'd rather a big fail than a lintian warning
[19:47] <superm1> people easily overlook lintian stuff
[19:47] <jdong> superm1: well sponsors are typically more paranoid :)
[19:47] <mok0> Hey the new queue is empty
[19:47] <superm1> we can't have that.  quick, everyone upload some NEW stuff :)
[19:48]  * jdong uploads prevu2 :D
[19:48] <mok0> :)
[19:51] <jdong> nice; gtkpod-aac finally rebuilt on most arches
[19:51] <CyberMatt> well ill have somthing in REVU soon so you guys can put somthing in the que or laugh at my mistakes whichever
[20:16] <cbx33> ok guys I've totally forgotten how to submit to revu
[20:16] <cbx33> anyone got any ideas
[20:17] <AnAnt> dput revu <changes file>
[20:19] <cbx33> thanks
[20:20] <cbx33> done
[20:22] <AnAnt> np
[20:27] <the_belgain> hi there - i was wondering whether any MOTU might be able to review my fuppes package in REVU?  I uploaded it a couple of days ago, and would ideally quite like to try and get this accepted in time for hardy...
[20:32] <ScottK> the_belgain: It's not a bad idea to include a link to the package on REVU in your request.
[20:32] <ScottK> CyberMatt: ^^^ - You too.
[20:33] <the_belgain> good point... here it is: http://revu.tauware.de/details.py?package=fuppes
[20:33] <CyberMatt> i don't have it up yet
[20:34] <CyberMatt> finishing touches
[20:35] <smarter> could someone please review my extremetuxracer package? http://revu.ubuntuwire.com/details.py?package=extremetuxracer thanks in advance ;)
[20:40] <vemon> hi! just updated a package in REVU according to the comments: http://revu.tauware.de/details.py?package=lashwrap
[20:41] <vemon> anyone up for re-review? :)
[20:43] <Kmos> vemon: revu day is over.. more next monday.
[20:43] <ScottK> Kmos: There's nothing wrong with asking when it's not a revu day, just less frequently.
[20:44]  * ScottK revu's when he has time, revu day or not.
[20:44] <LaserJock> exactly
[20:46] <nixternal> LaserJocky! HOLA!
[20:47] <LaserJock> nixternal: yo yo, homeskillet
[20:48] <nixternal> damn you, I went with hola cuz you stole it, now you are stealing homeskillet :p
[20:48] <Kmos> ScottK: ok =)
[20:48] <LaserJock> nixternal: yo, u check out the KDE4-izzle my shizzle? ;-)
[20:49] <ajmitch> LaserJock: make the pain stop
[20:49] <nixternal> I have been running KDE 4 fully since October pretty much...I haven't been in KDE 3 since probably the beginning of December...forgot what it looks like :)
[20:49] <nixternal> ajmitch: howdy!
[20:49]  * ajmitch runs
[20:51] <LaserJock> ajmitch: pain? that was nothin'
[20:52] <LaserJock> ScottK: does this look like an OK rules for a python app: http://revu.tauware.de/revu1-incoming/memaker-0801222130/memaker-0.9.4/debian/rules
[20:52]  * ScottK2 looks
[20:54] <ScottK2> LaserJock: Depending on what's in the make file, probably yes.
[20:54] <LaserJock> ok, I just wasn't sure about the use of pyversions
[20:56] <LaserJock> when using pycentral it seems to be a bit more work than necessary
[20:56] <ScottK2> LaserJock: The key thing is to end up with the Python modules in /usr/share/python-central.  Any app goes in /usr/bin as usaul.
[20:56] <tjaalton> hmmh, pbuilder claims that libmozjs-dev is a virtual package, which it isn't. What am I missing?
[20:59] <cbx33> LaserJock, ogra showed me that way
[20:59] <cbx33> ;)
[21:05] <selckin> its amasing how many people give the exact same awnser on some mailing lists
[21:05] <selckin> too lazy to read replies i guess
[21:19] <jdong> selckin: you can't really blame them... I have 500 incoming mails to go through every day, I'm sure I'd sometimes fire back a duplicate reply
[21:20] <selckin> isn't that way more work then quickly glanse over 3 replies?
[21:21] <jdong> selckin: not always when you read the original question and are 1000% confident you have the correct solution
[21:22] <jdong> selckin: you'd be surprised at some of the mailing list blind-leading-the-blind threads how quickly they can wander off to another galaxy :)
[21:22] <selckin> supose
[21:22] <jdong> selckin: but as an asker, I'd feel BETTER about a solution too if more than one person suggest it
[21:23] <jdong> so I don't think multiple replies are entirely useless, unless the OP has replied the problem was solved
[21:24] <selckin> ok, you convinced me
[21:27] <CyberMatt> a few more adjustments
[21:36] <huats> norsetto: Hey Hey hey
[21:36] <huats> :)
[21:37] <huats> such a long time without talking to you :)
[21:38] <apachelogger> anyone knows if I have `libgif-dev | libungif-dev` as build-deps, whether it will prefer libgif over libungif?
[21:39] <LaserJock> yep
[21:39] <LaserJock> if neither are already installed I believe
[21:39] <ScottK> apachelogger: Yes it will if neither is installed.  If libungif-dev is installed, it won't install libgif-dev.
[21:39]  * ScottK high fives LaserJock
[21:39] <LaserJock> ;-)
[21:40] <huats> anyone can tell me who to ask to mentor me to fix this bug 146710
[21:40] <ubotu> Launchpad bug 146710 in hal "backlight brighness control does not work (Samsung Q45 with Nvidia GForce 8400M)" [Undecided,Confirmed] https://launchpad.net/bugs/146710
[21:40] <apachelogger> ScottK: excellent, thanks :)
[21:40] <huats> since I got this laptop at work today and it really bother me...
[21:41] <norsetto> hey huats, how is it!?
[21:45] <nxvl_work> norsetto: hi!
[21:45] <norsetto> hey nxvl_work
[21:45] <nxvl_work> norsetto: how is it going
[21:46] <jdong> anyone know if there's any work towards packaging clutch (transmission remote control UI) or if it's past deadline(s) to do so?
[21:46] <norsetto> nxvl_work: fine thanks, hope you too?
[21:46] <jdong> I think it'd be a great package for Hardy universe to complement our new BT client :)
[21:47] <nxvl_work> norsetto: good, with lots of work, and a little concern about what happens on Bug #18256, but i hope it was just a mistake
[21:47] <ubotu> Launchpad bug 18256 in ubuntu "gpsd: new changes from Debian require merging" [Wishlist,Fix released] https://launchpad.net/bugs/18256
[21:48] <cbx33> hey guys
[21:48] <cbx33> how come I can't advocate on revu
[21:48] <cbx33> Logged in as petesavage@ubuntu.com ( Contributor )
[21:48] <cbx33> I am a MOTU
[21:51] <TheMuso> cbx33: Probably because revu has been down, and has had a db rebuild since the last time you logged on.
[21:51] <cbx33> ahh
[21:51] <cbx33> who is an admin?
[21:51] <TheMuso> cbx33: I'm not sure. I think I have ssh access to the box, but beyond that I don't think I can do much else to help revu.
[21:53] <norsetto> nxvl_work: hmmm, perhaps you mean a more recent bug and dropped a digit?
[21:54] <imbrandon> cbx33: http://people.ubuntuwire.com/~uwsa/
[21:54] <imbrandon> ^^ REVU admins
[21:54] <imbrandon> cbx33: what do you need ?
[21:54] <nxvl_work> norsetto: heh, yes
[21:54] <nxvl_work> norsetto: Bug #182567
[21:54] <ubotu> Launchpad bug 182567 in samba "smb.conf example: Configuration Directive Inconsistencies" [Wishlist,Fix released] https://launchpad.net/bugs/182567
[21:54] <cbx33> can I be able to advocate on revu please imbrandon
[21:54] <emgent> hello there
[21:54] <imbrandon> cbx33: can you login successfully ?
[21:54] <cbx33> yes
[21:54] <emgent> persia, ping
[21:54] <cbx33> i can comment
[21:54] <imbrandon> ok lemme check it
[21:54] <cbx33> just not advocate
[21:55] <cbx33> thanky
[21:55] <emgent> heya imbrandon norsetto
[21:55] <imbrandon> ello
[21:55] <norsetto> hey emgent
[21:55] <norsetto> nxvl_work: why concerned? whats the problem?
[21:56] <nxvl_work> norsetto: that i make a debdiff with some changes, then chuck add some more changes and removes mi name from changelog
[21:56] <norsetto> nxvl_work: oh I see, that kind of concern
[21:57] <norsetto> nxvl_work: well, don't let it bother you, must have been an oversight
[21:57] <emgent> persia, audacity bug it'snt fixed in hardy.
[21:58] <emgent> persia,    defaultTempDir.Printf(wxT("/tmp/audacity%d.%d-%s"),
[21:58] <emgent>                          AUDACITY_VERSION, AUDACITY_RELEASE, wxGetUserId().c_str());
[21:59] <emgent> see too: http://people.debian.org/~nion/nmu-diff/audacity-1.3.4-1_1.3.4-1.1.patch
[21:59] <norsetto> nxvl_work: I think that the problem is that he was asked to look at the bug, so he fixed it, he didn't consider your patch at all
[21:59] <nxvl_work> norsetto: nop, take a look at the changelog entries, those are the ones i wrote
[22:00] <nxvl_work> norsetto: also dholbach always ask for someone of the team to check the diff before sponsoring them
[22:00] <norsetto> nxvl_work: thats right, but since the package is in main and I guess chuck is maintaining it, he did it the fast way
[22:01] <nxvl_work> norsetto: yep, and thats why i hope it was just a mistake
[22:02] <nxvl_work> norsetto: but not less angry
[22:02] <norsetto> nxvl_work: I'm quite sure it was, what is important is that you don't let it bother you, its not really worth it
[22:03] <nxvl_work> norsetto: btw, i see there are calling for net MC Members, would you apply yourself, didn't you?
[22:04] <CyberMatt> are http://revu.ubuntuwire.com/ and revu.t.d the same
[22:04] <norsetto> nxvl_work: why should I? I'm a new guy on the block here, plenty of people more adequate than me for the post
[22:04] <LaserJock> CyberMatt: I think so yeah
[22:05] <nxvl_work> norsetto: because i think you have what it needs to make people happy working on MOTU, a really helpful and nice person
[22:05] <nxvl_work> norsetto: and those things are more important than technical skills
[22:05] <CyberMatt> i've been so busy contributing to debian its been quite awhile
[22:05] <nxvl_work> norsetto: and more for the management of a community
[22:05] <bddebian> Yeah instead of an old crotchedy jerk like me ;-)
[22:05] <LaserJock> lol
[22:07] <nxvl_work> norsetto: and as i think you don't know, it was you who gives me what i needed to make the effort on becoming a MOTU and don't quit :D
[22:07] <nxvl_work> norsetto: since you where so patient, nice and helpful
[22:07] <CyberMatt> good news is my packaging is like 70-80% better bad news is debian-policy = the-bible now
[22:07] <norsetto> nxvl_work: you better stop here before I cry ;-)
[22:09] <norsetto> nxvl_work: I'm also worried about bddebian, he has a tendency to vomit on my shoes if he is not at ease ....
[22:09] <LaserJock> haha
[22:09] <LaserJock> that's a looooong ways to go
[22:10] <LaserJock> transatlantic vomit
[22:10] <bddebian> hehe
[22:10] <norsetto> LaserJock: hmmm, try with the b word and see if it still has the same effect on him
[22:10] <LaserJock> hmm
[22:11] <LaserJock> maybe we should find a pic to put on his wiki page
[22:11] <cbx33> heheh
[22:11] <LaserJock> alright guys, I'm out for a while.
[22:11] <nxvl_work> norsetto: heh
[22:11]  * nxvl_work HUGS norsetto
[22:12]  * norsetto hugs nxvl_work
[22:12] <CyberMatt> HAHA REVU's lintian and linda are out of date
[22:12] <norsetto> nxvl_work: keep going mate, you have a good future ahead ;-)
[22:12] <ScottK> imbrandon: Are you around?  I need some source backport help...
[22:12] <nxvl_work> norsetto: i hope, i have just stop a little with packaging to make my python skills better
[22:13] <Ubulette> which tag should I use to ask for sponsorship in main ?
[22:13] <cbx33> man
[22:13] <Kmos> Ubulette: subscribe to ubuntu-main-sponsors ?
[22:13] <cbx33> it was fun being a motu again
[22:13] <cbx33> ;)
[22:13] <CyberMatt> http://revu.ubuntuwire.com/details.py?package=jailkit
[22:13] <nxvl_work> Ubulette: ubuntu-main-sponsors
[22:13] <Kmos> :)
[22:14] <Ubulette> no tag ?
[22:14] <CyberMatt> could someone take a look
[22:14] <Ubulette> ok
[22:14] <Ubulette> bug 185178
[22:14] <ubotu> Launchpad bug 185178 in libpng "Please sponsor libpng 1.2.24" [Undecided,New] https://launchpad.net/bugs/185178
[22:14] <norsetto> ok, time to go for me, see you all around
[22:14] <TheMuso> cbx33: Was, or is?
[22:15] <cbx33> TheMuso, is
[22:15] <cbx33> I just havn't been around for a while
[22:15] <TheMuso> cbx33: Right. Glad to have you bac.
[22:15] <nxvl_work> Ubulette: you are asking for a merge?
[22:15] <ScottK> cbx33: Welcome back then.
[22:15] <Ubulette> no
[22:15] <Ubulette> nxvl, debian is as behind as ubuntu
[22:15] <nxvl_work> Ubulette: or the inclusion in hardy?
[22:15] <cbx33> hehe
[22:15] <cbx33> I just did my first actual upload to universe
[22:15] <cbx33> heheh
[22:16] <cbx33> I've made pacakge before
[22:16] <cbx33> but someone else always uploaded them
[22:16] <Ubulette> nxvl_work: isn't my description in the bug clear enough ?
[22:16] <Ubulette> 1st line
[22:16] <nxvl_work> nope
[22:16] <nxvl_work> :D
[22:16] <TheMuso> cbx33: What? You became a MOTU, and have never uploaded anything till now?
[22:16] <nxvl_work> heh
[22:16] <nxvl_work> really it is
[22:16] <nxvl_work> :P
[22:17] <Ubulette> ?
[22:17] <Kmos> TheMuso: done by himself :)
[22:17] <vemon> i though only motus have upload rights?
[22:17] <vemon> besides uploading to revu
[22:17] <cbx33> TheMuso, yup
[22:17] <cbx33> funny eh
[22:17] <TheMuso> Kmos: Yes, I know that.
[22:17] <cbx33> ogra did a lot of my uploading
[22:17] <cbx33> cos most of my stuff was going to main
[22:17] <nxvl_work> Ubulette: its almos 5:17 pm here, my brain is turned upside
[22:17] <TheMuso> cbx33: Yeah it is kinda funny.
[22:18] <nxvl_work> i need to sleep
[22:18] <cbx33> but it was great to hit that button
[22:18] <cbx33> ;)
[22:18] <TheMuso> cbx33: Was it a package update you uploaded, or a new package?
[22:18] <cbx33> new
[22:18] <Ubulette> nxvl_work, np, i know the feeling far too much
[22:18] <TheMuso> Well don't forget to announce it to ubuntu-motu@lists.ubuntu.com
[22:18] <cbx33> oh
[22:18] <cbx33> i do?
[22:18] <TheMuso> cbx33: Just a copy of the email you got from the ubuntu archive system is fine
[22:18] <cbx33> oh i see
[22:19] <TheMuso> it allows us to track new package uploads more easily
[22:19] <cbx33> alright
[22:19] <cbx33> will do that tomorrow
[22:19] <TheMuso> Ok.
[22:19] <nxvl_work> well, back to the conversation before
[22:19] <nxvl_work> bah! norsetto is gone
[22:19] <TheMuso> heh
[22:20] <CyberMatt> why do i still have this nick
[23:03] <RainCT> good night
[23:18] <emgent> persia, ping
[23:29] <persia> emgent: You need someone from SWAT to review that, not me.
[23:30] <persia> (and I don't play virtual table tennis)
[23:30] <emgent> persia, done. my debdiff it's attached :P
[23:30] <emgent> heheh ;)
[23:30] <emgent> for gutsy it's ok now, this night i will review for feist, dapper etc.
[23:30] <emgent> :)
[23:43] <rzr> persia: thx it's uploaded https://launchpad.net/ubuntu/+source/jaaa
[23:43] <rzr> now let's sync it to debian
[23:53] <the_belgain> hi - a maybe slightly OT question: I've accidentally uploaded a package to my PPA which doesn't have any ~ppaversion number appended to it.  is there any way for me to remove it from the archive in order to be able to upload multiple version of the package?
[23:54] <the_belgain> i don't want to just bump the main version number, because that would prevent people from being able to just remove the PPA if the package was added to the main ubuntu repo
[23:54] <Flare183> the_belgain: as far as i know you can't remove a package from your ppa yet...
[23:55] <the_belgain> that's quite problematic, because making a single mistake can basically mean that your archive becomes somewhat unusable
[23:57] <Fujitsu> the_belgain: With the next release of Launchpad, you should be able to delete packages easily. For now, you can ask a question on the launchpad project on Launchpad to have it removed.
[23:57] <emgent> Fujitsu, heya!
[23:57] <Fujitsu> emgent: Hi, about to run off again (I'm on holiday with limited Internet connectivity).
[23:57] <the_belgain> Fujitsu: I tried that, but the IRC channel didn't seem to be very responsive.  oh wel
[23:58] <emgent> Fujitsu, hehe np :)
[23:58] <Fujitsu> the_belgain: You obviously didn't - ask a question on the launchpad project on Launchpad, not on IRC.
[23:59] <Laibsch> Hi, I am fairly new to packaging for ubuntu.  I wonder what the recommended procedure is for creating a package from the information for a debian package (not an official debian package)