[00:03] <mcisbackuk> matthijs_: OK, did you set the tag to needs-packaging, and put it in the bug report subject line? If so, then it's just a waiting game, someone will sort it out :)
[00:04] <matthijs_> yes, I added [needs-packaging] to the start and end of both summary and description
[00:05] <mcisbackuk> matthijs_: OK, what bug # is it?
[00:06] <matthijs_> #187894,
[00:06] <matthijs_> the id is #187894
[00:07] <mcisbackuk> bug #187894
[00:07] <mcisbackuk> What's wrong with the bot?
[00:08] <LjL> it's not there?
[00:08] <LjL> bug #187894
[00:08] <ubotu> Launchpad bug 187894 in ubuntu "[needs-packaging] veejay-1.0 - http://veejayhq.net [needs-packaging]" [Undecided,New] https://launchpad.net/bugs/187894
[00:08] <mcisbackuk> weird
[00:09] <matthijs_> it was doing *something* in it's corner.
[00:09] <mcisbackuk> matthijs_: Yeah that's fine, I edited the tags to needs-packaging so contributors can have a look, but yeah that's fine for now :)
[00:09] <LjL> it wasn't doing anything, it wasn't in the channel
[00:09] <mcisbackuk> lol how did it suddenly come back then?
[00:09] <LjL> by rejoining the channel
[00:10] <mcisbackuk> It hasn't been here for about an hour lol
[00:10] <LjL> ubotwo was.
[00:10] <LjL> and, networks sometimes have problems.
[00:10] <mcisbackuk> It didn't answer me an hour ago stupid bot lol
[00:10] <mcisbackuk> Oh well it's working now :)
[00:11] <matthijs_> I'm telling ya, he's been at it again, visiting those other channels, talkin' dirty
[00:11] <matthijs_> oh well, enough for this night. I should go to sleep now, long day ahead tomorrow
[00:12] <matthijs_> Thank you guys for the help, I wouldn't have figured this out using google I think.
[00:12] <matthijs_> bye!
[00:25] <ryanakca> can someone please answer the questions I placed in reply to the comment on http://revu.tauware.de/details.py?package=basic256 ?
[00:30] <LaserJock> ryanakca: the Debian menu has changed a bit
[00:30] <LaserJock> ryanakca: you'd need a new enough lintian/linda to check
[00:30] <ryanakca> LaserJock: ah, ok.
[00:31]  * ryanakca tries upgrading hardy
[00:31] <LaserJock> Apps has been replaced by Applications, that's why you get the particular warning
[00:31] <ryanakca> aha, okies.
[00:31] <LaserJock> but some categories were also moved around
[00:31] <LaserJock> so it's good to check
[00:32]  * ryanakca wonders if the Debian people should be prodded to update http://www.debian.org/doc/maint-guide/ch-dother.en.html#s-menu
[00:32] <nixternal> LaserJock: feeling any better tonight?
[00:32] <LaserJock> nixternal: no way
[00:33] <ryanakca> LaserJock: and, about the man page?
[00:34] <LaserJock> ryanakca: I would say do it
[00:34] <LaserJock> even if it's not that informative
[00:34] <ryanakca> eh, ok... I guess it wouldn't matter too much if its 90% copy-paste from control/copyright?
[00:35] <neurostumit> Hi, does anybody here know if there is a gtkglext-1.2 deb file?  the ubuntu repo only has version 1.1
[00:41] <superm1> who was the one with wxformbuilder?
[00:41] <superm1> i was just revu'ing it but had a question for the packager
[00:45] <ryanakca> superm1: rjmyst3
[00:46] <superm1> ah yeah he's not online
[00:46] <superm1> okay i'll just leave a comment on the revu then for him to take a look
[00:47] <neurostumit> Hi, does anybody here know if there is a gtkglext-1.2 deb file?  the ubuntu repo only has version 1.1
[00:50] <ryanakca> neurostumit: Version: 1.2.0-0ubuntu1
[00:50] <ryanakca> neurostumit: in hardy, apt-cache show libgtkglext1
[00:56] <mcisbackuk> Hey guys, I'm trying to build an upgraded upstream, but pbuilder keeps coming up saying that its depends: libgettext-ruby1.8, libgtk2-ruby1.8 and libxul-dev are virtual packages.
[00:56] <neurostumit> will that work in gutsy?
[00:57] <neurostumit> ryanakca: will a simple apt-get install libgtkglext1 work then?
[01:00] <ryanakca> neurostumit: no
[01:00] <ryanakca> neurostumit: you need to be running hardy
[01:00] <ryanakca> neurostumit: unless gutsy also has 1.2.0
[01:00] <neurostumit> no gutsy's repos doesn't
[01:02] <mcisbackuk> Is there a way round this virtual package issue? Any help at all would be appreciated!
[01:02] <neurostumit> well they didn't a couple of weeks ago
[01:04] <neurostumit> ryanakca:  does apt-cache show libgtglext1 show if gtkglext is available?
[01:05] <ryanakca> neurostumit: dunno, look on packages.ubuntu.com
[01:06] <mcisbackuk> Please help someone this pbuilder is doing my head in!! lol it keeps whinging about virtual packages, dependencies unmet, any ideas anyone please?
[01:07] <neurostumit> ok
[01:07] <neurostumit> also is there a way to download a deb file with apt and not install it?
[01:09] <blueyed> persia: congrats! Can you add me to u-u-s, please?
[01:21] <ryanakca> can someone please review http://revu.tauware.de/details.py?package=basic256
[01:24] <pochu> sorry for the duplicate mail on revu, I received a ProgrammingError and thought the comment wasn't posted...
[01:31] <TheMuso> pochu: I've had that before.
[02:02] <cheguevara> ping RAOF
[02:05] <ScottK2> TheMuso: Would you please add me back as a member of UUS?
[02:05] <ScottK2> TheMuso: My LP id is kitterman.
[02:13] <ScottK2> Heya bddebian.
[02:14] <bddebian> Heya gang
[02:14] <bddebian> Hi ScottK2
[02:15] <bddebian> ScottK2: Hey, you never answered my /query window :-)
[02:16] <ScottK2> bddebian: I don't think I got it.
[02:16] <ScottK2> bddebian: /msg me again.
[02:16] <bddebian> It was a day or two ago :-)
[02:21] <freakabcd> hi all
[02:21] <bddebian> Hello freakabcd
[02:21] <freakabcd> ok, i've got pbuilder setup. and a source package from hardy
[02:21] <freakabcd> i want to build this in gutsy
[02:21] <freakabcd> i can make the necessary changes in the control/etc. files
[02:22] <freakabcd> i just want to know how to build it now
[02:22] <TheMuso> ScottK2: Just a sec.
[02:22] <ScottK2> TheMuso: Thanks.
[02:23] <TheMuso> ScottK2: have you applied?
[02:23] <emgent> hello there, in #ubuntu-hardened is avaiable a bot (nick ubuSecurity) that paste in realtime CVE advisory, bugtraq advisory and milw0rm POC. if someone is interested please join. :)
[02:23] <ScottK2> TheMuso: Do I need to?
[02:24] <TheMuso> ScottK2: No
[02:24] <ScottK2> TheMuso: No.  I haven't.
[02:24] <TheMuso> ok
[02:24] <TheMuso> Done. You should receive an email about it shortly.
[02:25] <ScottK2> Thanks.
[02:25] <TheMuso> np
[02:32] <blueyed> TheMuso: can you add me, too? (blueyed on LP)
[02:32] <blueyed> you cannot apply there, btw.
[02:33] <mcisbackuk> Hey guys, I'm getting an error during pbuilder from my rules file: install -o0 -g0 -m 0644 LWP.pm debian/tmp/usr/share/perl5/LWP.pm
[02:33] <mcisbackuk> install: cannot stat `LWP.pm': No such file or directory
[02:33] <mcisbackuk> any ideas?
[02:33] <TheMuso> blueyed: People have done so, but I'll add you directly
[02:33] <mcisbackuk> oops sorry scrolling
[02:34] <TheMuso> blueyed: done
[02:34] <ScottK2> mcisbackuk: Whatever package provides that file you need to build-dep on.
[02:34] <blueyed> TheMuso: thanks
[02:34] <ScottK2> TheMuso: Thanks.
[02:34] <TheMuso> np
[02:34]  * Hobbsee waves
[02:34] <ScottK2> Heya Hobbsee.
[02:34] <TheMuso> heya Hobbsee
[02:35] <mcisbackuk> ScottK2: How do I find that out? Google it?
[02:36] <ScottK2> mcisbackuk: apt-file find LWP.pm
[02:37] <ScottK2> That'll narrow it down.
[02:38] <mcisbackuk> ScottK2: Brilliant thanks :)
[03:07] <ryanakca> can someone please review http://revu.tauware.de/details.py?package=basic256 ?
[03:25] <superm1> ryanakca, i left you a comment on revu
[03:27]  * jdong wonders if we can adapt REVU into a dating service
[04:00] <ryanakca> jdong: lol
[04:00] <ryanakca> superm1: thanks
[04:01] <ryanakca> superm1: if I upload, can you check & advocate please?
[04:07] <ryanakca> hmm... revu only scans every 10 minutes by the looks of it...
[04:08]  * ryanakca wants time to move faster so he can go to bet
[04:08] <ryanakca> s/bet/bed
[04:08] <bddebian> persia: You on?
[04:10] <ryanakca> can someone please review http://revu.tauware.de/details.py?package=basic256 ?
[04:10]  * ryanakca => bed :)
[05:05] <ScottK2> If anyone is looking for a security upload to do, Bug #174615 needs fixing in Dapper/Edgy/Feisty/Gutsy.
[05:05] <ubotu> Launchpad bug 174615 in heimdal "[heimdal] [CVE-2007-5939] possible remote vulnerability of  unknown impact via an invalid username" [Undecided,Fix released] https://launchpad.net/bugs/174615
[05:09] <rjmyst3> superm1: Thanks for the review! I just uploaded a wxformbuilder package with the versions fixed.
[05:09] <superm1> rjmyst3, great!
[05:09] <superm1> i'll take a look in a moment
[05:09] <rjmyst3> thank you
[05:10] <superm1> rjmyst3, so this is like an advance release upload :)?
[05:10] <rjmyst3> yes
[05:11] <rjmyst3> superm1: i am an upstream dev
[05:11] <superm1> cool.  okay i'll upload it to the archive then.  thanks a bunch :)
[05:11] <rjmyst3> thank you
[05:12] <rjmyst3> superm1: does this mean that it will be in hardy? - sorry, this is my first package, and I don't know if there are more steps or not
[05:12] <superm1> rjmyst3, this is it for steps on your end
[05:13] <superm1> archive admins need to look it over still
[05:13] <superm1> and if there are any issues they will contact both you and me
[05:13] <superm1> me since i'm sponsoring the upload
[05:13] <superm1> and you for the issues
[05:13] <superm1> but it should be in hardy yes.
[05:13] <rjmyst3> ok
[05:13] <rjmyst3> i'll keep my fingers crossed
[05:13] <rjmyst3> thank you for your help
[05:14] <rjmyst3> when will I know for sure?
[05:14] <rjmyst3> (or how?)
[05:15] <superm1> rjmyst3, you'll get some email if there are any concerns
[05:15] <superm1> otherwise you can keep an eye on the NEW queue
[05:16] <superm1> to see once it gets accepted
[05:16] <superm1> there are two stages to it getting accepted, first the source package
[05:16] <superm1> then it will build
[05:16] <superm1> and then they accept the binary packages that are generated
[05:16] <superm1> https://launchpad.net/ubuntu/hardy/+queue
[05:16] <superm1> you can see its now at the top of the list on the queue
[05:18] <rjmyst3> yes
[05:18] <rjmyst3> i see that
[05:18] <superm1> those queues are processed on a regular basis, but they are only one of the tasks of archive admins, so it might be there for a week or so
[05:18] <rjmyst3> ok
[05:19] <rjmyst3> then it will move to accepted or rejected?
[05:19] <superm1> once it's accepted, it will automatically go into build mode
[05:19] <superm1> and the binaries will show up in there
[05:19] <rjmyst3> ok, i understand now
[05:20] <rjmyst3> thank you very much, i'm off to bed now
[05:20] <superm1> thanks for your contribution :)
[05:20] <superm1> night
[05:20] <rjmyst3> your welcome - good night
[05:45] <joejaxx> :)
[05:53] <ScottK2> persia: I think we ought to add debmake to our list of packages to get removed from Hardy.
[05:53] <ScottK2> It looks like an easy enough one to knock off.
[05:54] <joejaxx> haha apparently laserjock, persia and you ScottK2 talk the most in here :D
[05:54] <joejaxx> :P
[05:55] <superm1> was there a scientific way you determined that?
[05:55] <joejaxx> http://core.joejaxx.net/~joejaxx/ircstats/freenode/ubuntu-motu/
[05:56]  * superm1 wonders how persia is the in the top 10 for activity for all hours of the day
[05:56] <joejaxx> Lol
[05:57] <joejaxx> apparently his nick is the in the top 5 for said phrases
[07:00] <Aloha> please review http://revu.tauware.de/details.py?package=sadms :)
[07:11] <warp10> Good morning
[07:11] <Aloha> warp10, morning!
[07:12] <warp10> Hey Aloha
[07:12] <wastrel> hi, i have a bug with a fix from upstream & needs someone to bring it into ubuntu
[07:13] <wastrel> 184505
[07:14] <desertc> geser: Heya, I was taking a look at a package you uploaded, OnScripter , and I was interested in possibly updating it.  I am not familiar with packaging yet, but I thought this might be a good way to learn about it.
[07:15] <emgent> malone  184505
[07:15] <ubotu> Launchpad bug 184505 in jppy "jppy fails to launch" [Undecided,New] https://launchpad.net/bugs/184505
[07:17] <desertc> There is a June2007 version out now, compared to the existing Oct2005 version in the Ubuntu universe repository.
[07:27] <desertc> Wowz, there is even the original Japanese version that was updated just today.  It's still a very active project.
[07:28] <desertc> Heh - and the Japanese version is already in Debian repositories.
[07:29] <superm1> Aloha, i left you some comments
[07:29] <Aloha> superm1, thank you
[07:33] <Aloha> superm1, how do i prevent stuff from being installed into /usr/local?
[07:33] <superm1> Aloha, typically you have to pass --prefix=/usr
[07:33] <superm1> to your configure script
[07:35] <Aloha> superm1, isn't that upstream?
[07:35] <superm1> Aloha, you can override lots of things with parameters
[07:35] <superm1> it is done at a packager level though
[07:35] <Aloha> superm1, how so?
[07:37] <superm1> well this package of yours is a bit interesting
[07:37] <superm1> it doesnt have a configure script
[07:37] <superm1> well then what you will need to do is patch the Makefile
[07:38] <superm1> so your package will need to adopt a type of patching system to do that
[07:38] <Aloha> superm1, i don't know how to do that. can you point me to the right place? :)
[07:39] <superm1> this will get you started here: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[07:42] <Aloha> superm1, thnx
[07:45] <LucidFox> superm1> Is a configure script required, though?
[07:45] <superm1> LucidFox, no its not
[07:45] <superm1> and in this case there isn't one
[07:46] <superm1> i was just generalizing that one normally is around for passing parameters
[07:46] <LucidFox> or is the Makefile hardcoded to use /usr/local as a prefix?
[07:46] <superm1> the Makefile is hardcoded
[07:46] <LucidFox> Eep.
[07:53] <Aloha> so i should send the patch upstream to help them out yeah?
[07:53] <Aloha> superm1, so in my patch i'm changing /usr/local to /usr in the Makefile correct?
[07:54] <superm1> Aloha, your patch will remain local to the package
[07:54] <superm1> because upstream distributes it like that so that people can install without disturbing /usr
[07:54] <Aloha> gotcha
[07:54] <superm1> it is bad that they dont offer a configuration facility
[07:55] <superm1> so if you wanted to provide them with a patch that did that, that would be of use to them
[07:55] <superm1> but probably more effort than its worth after looking at their build system
[07:55] <Aloha> superm1, heh
[07:55] <superm1> Aloha, but yeah you need to change any instance of /usr/local to /usr
[07:55] <superm1> and it looked like you might need to define prefix =
[07:55] <superm1> you'll have to experiment and see what works out
[08:03] <Aloha> superm1, how do i debhelper the changelog?
[08:03] <LucidFox> Aloha> dh_installchangelogs changelog_file_name
[08:03] <dholbach> good morning
[08:03] <Aloha> dholbach, morning!
[08:03] <Aloha> LucidFox, thnx
[08:03] <emgent> heya dholbach
[08:04] <LucidFox> good [insert time of day here] :)
[08:04] <dholbach> hey Aloha, emgent
[08:11] <Aloha> superm1, my debianrules file has a debhelper for the changelog
[08:11] <Aloha> s/debianrules/debian\/rules
[08:12] <superm1> hm
[08:12] <superm1> interesting
[08:12] <superm1> well dont worry about that right now then
[08:12] <Aloha> superm1, ok
[08:12] <Aloha> superm1, i created the patch for the Makefile
[08:13] <Aloha> superm1, i don't know how to fix pam_parse.awk failing syntax checks. i don't know what that means
[08:13] <superm1> Aloha, you will probably have to make patches for the other things i've listed too
[08:13] <superm1> either that or modify that behavior in debian/rules
[08:13] <superm1> i got several of those things i listed from running linda or lintian on the resultant deb
[08:13] <Aloha> superm1, that other stuff was in the Makefile also
[08:14] <superm1> after you build it
[08:14] <superm1> which tells you a lot about what is wrong with the build and needs to be improved upon
[08:14] <superm1> and in some cases points you at how to work on those types of things
[08:15] <Aloha> superm1, cool. what arguments do you give them?
[08:16] <superm1> Jan 25 04:56:08 <persia>	superm1: I use lintian -iIv and linda -v -f long -t E,I,W,X, but those are only a subset of my review checks.
[08:16] <superm1> those are quoted from persia
[08:16] <Aloha> superm1, thnx
[08:17] <Aloha> its times like these i love the xfce notes plugin ;)
[08:18] <Aloha> superm1, how do you build the packge to run lintian and linda on it? dpkg-buildpackage -rfakeroot?
[08:18] <superm1> Aloha, i build my packages in a pbuilder
[08:18] <superm1> and then i run linda /lintian on the .changes file
[08:18] <superm1> that is created
[08:19] <superm1> that runs it on all of the debs that are produced from the pbuilder run
[08:19] <Aloha> superm1, oh i didn't know builder creates .changes file. whats the syntax for that? sudo pbuilder build <filename>.dsc?
[08:19] <Aloha> s/builder/pbuilder/
[08:20] <superm1> Aloha, yeah it does create .changes files
[08:20] <Aloha> cool
[08:20] <superm1> depending on how you configure your pbuilder that would be a possible command to run
[09:01] <isaac> hi there
[09:02] <isaac> can any REVU admin re-sync the REVU uploaders keyring? :)
[09:02] <isaac> foolano: yo
[09:02] <Hobbsee> isaac: doing
[09:02] <isaac> Hobbsee: thanks
[09:02] <Hobbsee> er, attempting to do
[09:06] <Hobbsee> hm, would help if i ran the right script, i'll bet...
[09:06] <foolano> hi isaac
[09:06] <isaac> Hobbsee: I reckon it might help ;)
[09:06] <Hobbsee> this output looks more promising :)
[09:06] <isaac> brill
[09:07] <Aloha> its helps to debuild before you run pbuilder hehe..... /me smacks forehead
[09:07] <Aloha> no wonder why it didn't update
[09:08] <Hobbsee> hehe
[09:08] <Hobbsee> this si why i used to like pdebuild
[09:09] <Aloha> i don't want to repartion my disk just to build packages. especially when i don't know what i'm doing ;)
[09:09] <Aloha> TLE, hi :)
[09:09] <Aloha> ivoks, hihi :)
[09:09] <ivoks> buahahaha to you too :)
[09:10] <Aloha> buahahaha?
[09:10] <TLE> hallo
[09:10] <soren> Hi, TLE :)
[09:12] <ivoks> soren: virt-manager in hardy got special attention from phoronix :)
[09:12] <soren> "phoronix"?
[09:12] <ivoks> soren: http://www.phoronix.com/scan.php?page=article&item=983&num=1
[09:12] <isaac> Hobbsee: so I should be able to upload to REVU already, right?
[09:13] <Aloha> isaac, welcome to REVU :)
[09:13] <TLE> :)
[09:13] <isaac> Aloha: thanks
[09:13] <soren> ivoks: Oh, nice.
[09:13] <Hobbsee> isaac: it's still not finished
[09:13] <isaac> Hobbsee: I still have some work to do in the package
[09:13] <isaac> so it's ok :)
[09:14] <isaac> Aloha: I am hoping for a "quick" welcome to MOTU ;)
[09:14] <Aloha> isaac, are you an experienced packager?
[09:14] <isaac> Aloha: I have been a debian developer for three years IIRC
[09:14] <isaac> Aloha: but I have switched to ubuntu now
[09:14] <Aloha> isaac, cool glad to have you on the right side ;)
[09:14] <ivoks> soren: thinking about dovecto/postfix, i think we should give up on modifing main.cf trough init script
[09:15] <isaac> Aloha: haha
[09:15] <isaac> Aloha: both sides are right ;)
[09:15] <ivoks> soren: no one likes that :/
[09:15] <Aloha> isaac, thats what i said ;)
[09:17] <soren> ivoks: I think it's kind of sexy.
[09:18] <ivoks> soren: ...and wrong :D
[09:50] <Aloha> if upstream has a debian based tarball do we do <packagename>-0ubuntu1? i couldn't find the actual upstream in debian repos
[09:53] <LucidFox> Aloha> Debian-based tarball?
[09:53] <Aloha> LucidFox, yeah its a tarball of the source with a debian directory in it
[09:54] <LucidFox> Aloha> Then repackage the tarball and remove the debian/ directory from it
[09:54] <LucidFox> note it in debian/copyright, and add a get-orig-source rule to automate this
[09:54] <Aloha> LucidFox, ok i'm thinking i shoulda started with that since the main tarball tries to build based on distribution
[09:55] <Aloha> its getting really complicated heh
[10:03] <LucidFox> That's one really borked upstream build system
[10:06] <Aloha> yeah
[10:06] <Aloha> it tries to build a package of itself and then install the package
[10:06] <Aloha> wtf?
[10:06] <Aloha> heh
[10:15] <Aloha> what if upstream doesn't include man pages for their binaries? how do i solve that?
[10:19] <superm1> write one :)
[10:19] <Aloha> yay ;)
[10:19] <Aloha> all the docs are html files... blah
[10:20]  * Aloha looks for html2man
[10:27] <Hobbsee> hi jono
[10:27] <jono> heya Hobbsee
[10:28] <huats> moring everuyone
[10:28] <Hobbsee> jono: taken over the world yet?
[10:28] <jono> Hobbsee: nearly there :P
[10:28] <Hobbsee> heh, nice work
[10:29]  * Hobbsee should do something useful, like cook dinner and write email.
[10:29] <Aloha> Hobbsee, or chat ;)
[10:29] <Hobbsee> no, tha'ts nto really useful :)
[10:30] <Aloha> Hobbsee, it stimulates your need for artificial interaction ;)
[10:31] <Aloha> thats kinda useful
[10:31] <Hobbsee> heh
[10:31] <Hobbsee> yeah well, there is that
[10:31]  * Hobbsee has always been somewaht of a hermit anyway
[10:32]  * Hobbsee used to only say around 20 words a day, at all.
[10:34]  * jono starts on the packaging guide again
[10:35] <Aloha> jono, rewriting it?
[10:35] <jono> Aloha: nope, learning it :)
[10:35] <Aloha> jono, oh. :) its fun :)
[10:35] <jono> :)
[10:35] <Aloha> jono, i learned how to patch today. woohoo
[10:36] <jono> wicked :)
[10:37] <Aloha> i still can't get over this build system
[10:38] <Aloha> its like a self replicating robot. it finds what system you're running and it packages itself to that spec and then installs the package
[10:38] <Aloha> nuts
[10:40]  * persia rings the bddebian gong
[10:41] <persia> superm1: The trick is being absent for spans across sampling periods.
[10:41] <Aloha> blah
[10:41] <persia> ScottK: I completely agree.  There's actually a few packages that lintian recommends we purge that I think are achievable.
[10:41] <emgent> ehm people..
[10:41] <emgent> http://blog.emanuele-gentili.com/images/google_love_kubuntu.png
[10:41] <emgent> see this.
[10:42] <Aloha> the only problem with this build is that the resulting package totally violates debian policy in like every way possible
[10:51] <jono> quick question
[10:51] <persia> jono: Just ask (and I doubt I will provide a short answer)
[10:52] <jono> can someone be a packager and not have programming experience? as in...could I look at bugs with patches attached and apply the patch and do an upload without having to hack on code?
[10:52] <jono> or do MOTUs need programming experience?
[10:52] <persia> Yes, very much so.
[10:52] <jono> good stuff :)
[10:52] <persia> There are several classes of bugs.  Some just require a little investigation as to what happened, and a set of rebuilds in the right order.
[10:53] <ogra> jono, note that experience with diff and patch is rare without programming (at least scripting) experience
[10:53] <persia> Some require small adjustments to packaging: perhaps the build-dependencies, the description, patches to correct spelling, file installation locations, etc.
[10:53] <jono> gotcha
[10:53] <jono> I am thinking of new MOTUs who have never coded
[10:53] <jono> sorry, new "potential" MOTUs
[10:53] <persia> Having experience with make or shell scripting is a big advantage, as it allows one to start working on bugs with maintainer scripts, debian/rules, etc.
[10:54] <jono> right
[10:54] <persia> From there, it gets more complicated, either code integration issues (local coding) or bugfix patches (which likely should be pushed upstream).
[10:54] <jono> thanks :)
[10:54] <jono> is it clear with the bug what kind of fix it needs?
[10:54] <persia> In many cases, upstream already has a fix, and some discussion with upstream, and the application of the patch, and some testing is enough to resolve the bug.
[10:54] <jono> or do I need to check the patch?
[10:55] <persia> It's not always clear.  Bugsquad processes about 1000 bugs a week, but those don't always reach a state of sufficient triage to be obvious.
[10:56] <persia> You should always check the patch to see if it makes some sense.  Even if you don't know the programming language, there should be some relation between the patch and the bug (and if there isn't, ask the patch author for some explanation).
[10:56] <jono> is there a triage label or tag that indicates the complexity of the fix?
[10:56] <jono> right
[10:56] <jono> good stuff
[10:56] <persia> This is more because you want to know what you signed: kind of like reading contracts before you sign them.
[10:56] <jono> wise
[10:56] <jono> :)
[10:56] <jono> thanks persia
[10:57] <Aloha> you read contracts? ;)
[10:57] <persia> There's not really such a tag.  Bugs that appear obviously easy get the "bitesize" tag, but there's lots of easy bugs that aren't tagged.  Well understood bugs are usually status: triaged, but that doesn't mean they are easy to solve.
[10:57] <persia> Aloha: Are you free next wednesday?  I have a business proposition.
[10:57] <Aloha> persia, heh
[10:58] <Aloha> persia, i'd almost be tempted to take up your offer just to see where i end up ;)
[10:58] <persia> Anyway, about bugs, my recommedation is that people interested in helping with development get involved with bugsquad (in #ubuntu-bugs: there are people there despite the bot) to get a better handle on how the bugs are organised, etc.
[10:59] <persia> Also, this often gives a first chance to grab the easy ones, and get a good list of fixes in the archive, which can be satisfying.
[11:00] <persia> Aloha: Please send me private email with details of a hotel reservation near you, and information regarding with whom I should arrange for transportation.  I'll present the opportunity, and bring along some paperwork.
[11:01] <Aloha> persia, which hotel do you want? Theres like 1000 here
[11:02]  * persia puts away the bait & tackle
[11:15] <Hobbsee> so, apparently slicing your fingers open is a bad idea.
[11:18] <isaac> soren: I have uploaded a package called unblock-signals to REVU, which is needed to fix a problem in ebox related to apache2 blocking some signals , I am not sure if foolano has told you about it
[11:18] <persia> Hobbsee: Generally.  Lots of nerves and stuff.  If you're just curious about the contents, someone else's fingers are recommended.
[11:18] <soren> isaac: He hasn't.
[11:18] <isaac> soren: thing is that apache2 blocks some signals
[11:19] <isaac> soren: and then sometimes gconfd2 is spawned from inside apache2 by libgconf
[11:19] <soren> erk..
[11:19] <soren> Ok.
[11:19] <isaac> soren: and it doesn't unblock these signals so it's impossible to terminate it gracefully
[11:19] <foolano> i filed a bug in gnome's bugzilla
[11:19] <isaac> this is the only workaround we have managed to think of that doesn't involve modifying any other package
[11:20] <soren> Modifying other packages is not out of the question.
[11:20] <soren> At all :)
[11:20] <isaac> soren: the thing is the package we would need to modify is gconf
[11:20] <isaac> soren: and I guess that's quite an important part of ubuntu
[11:21] <isaac> soren: foolano already provided a patch to upstream
[11:21] <isaac> soren: but gconf is unmaintained by upstream
[11:21] <isaac> it's in a kind of "it works for us so nobody needs to touch it"
[11:21] <Aloha> if a script needs permissions changed do i patch that or just change  it?
[11:22] <isaac> Aloha: what do you mean? you are a shipping a script in a package that needs to have its permissions changed?
[11:22] <soren> isaac: gconf is unmaintained? This is news to me.
[11:22] <isaac> soren: by upstream
[11:22] <isaac> soren: we joined the #gnome-hackers channel some days ago
[11:22] <isaac> soren: to ask about the issue
[11:22] <isaac> and we were told that there were no current maintainer for gconf
[11:22] <Aloha> isaac, lintian complains about file not being executable
[11:22] <isaac> if something breaks there I am sure they will fix it
[11:22] <isaac> Aloha: just add a chmod in your debian/rules
[11:22] <persia> Aloha: That often means it's not supposed to be executable.
[11:23] <soren> isaac: Well, if the patch is good, we can apply it in Ubuntu.
[11:23] <isaac> persia: if lintian is complaining it's because the script has a shebang
[11:23] <Aloha> isaac, it does
[11:23] <Aloha> isaac, should i just patch it out? all of his files have shebangs and it complains about all of them heh
[11:23] <persia> isaac: Right.  In many cases, this happens where it shouldn't, e.g. random python snippets in /usr/share
[11:23] <isaac> Aloha: you can't patch that
[11:24] <isaac> Aloha: just make sure to set the right permissions after you install your files in debian/tmp/ or debian/package-name/
[11:24] <Aloha> isaac, ok. i was gonna just remove the shebang but i guess thats a bad idea
[11:24] <isaac> persia: yes, in that case just adding a lintian override should be ok
[11:24] <persia> (or, if they aren't actually executed, just remove the #! lines)
[11:24] <persia> isaac: No, better to drop #!.
[11:24] <isaac> persia: uhm, if it's an example it's ok for it to have the #~
[11:24] <isaac> #!
[11:25] <persia> isaac: Yes.  Examples are special cases.
[11:25] <soren> isaac: I recommend you file a bug against gconf2 in Ubuntu and attach the patch.
[11:25] <isaac> Aloha: so what's exactly the case here?
[11:25] <isaac> soren: ok
[11:25] <Aloha> isaac, its an actual script. the build system is wack so its hard to tell what it does exactly
[11:26] <Aloha> i can create a patch to remove the shebangs and see if it still builds
[11:26] <persia> Aloha: Where is the offending file installed?
[11:26] <Aloha> if not i'll just remove the patch
[11:27] <Aloha> /usr/share/sadms-2.0.12/*
[11:27] <Aloha> theres a bunch of python scripts
[11:28] <Aloha> actually they're expect and awk scripts
[11:28] <Aloha> python is different error. i fixed that one
[11:29] <persia> Aloha: It's generally safe to strip #! lines from everything in /usr/share.  Note that some packages rely on internal executables, and may need patching to include, source, or otherwise call out to those, rather than relying on a system call to be policy compliant.
[11:30] <persia> Err, with the exception of /usr/share/doc/$package/examples, as isaac rightly pointed out previously.
[11:31] <mok0> Does feature freeze include merges?
[11:32] <soren> mok0: Depends..
[11:32] <soren> mok0: Merging stuff is fine if it's for the sake of fixing bugs.
[11:32] <mok0> soren: ok
[11:32] <soren> mok0: If it's to get new features and stuff, you need to ask.
[11:32] <persia> mok0: Only as much as DIF included merges.  We still like bugfixes, but new upstreams and new features require FFe.
[11:32] <mok0> persia: thx
[11:33] <mok0> starting to feel the stress...
[11:33] <persia> mok0: That's a good sign :)
[11:33] <mok0> persia: yep. I tend to get things done only when I'm stressed :-)
[11:36] <Hobbsee> persia: heh :)
[11:39]  * persia encourages someone looking for a quick upload to review and test the patch for bug #66623.  Seems to be wide user interest, and a candidate fix already extracted from upstream.
[11:39] <ubotu> Launchpad bug 66623 in ruby-gnome2 "warning: GRClosure invoking callback: already destroyed" [Low,Confirmed] https://launchpad.net/bugs/66623
[11:54] <Nafallo> any german guys around?
[11:55] <Nafallo> persia: you speak german, don't you? :-)
[11:55] <isaac> soren: https://bugs.launchpad.net/ubuntu/+source/gconf/+bug/188007
[11:55] <ubotu> Launchpad bug 188007 in gconf "gconfd does not unblock signals properly" [Undecided,New]
[11:55] <dholbach> Nafallo: I do
[11:55] <persia> Nafallo: Nur ein bisse
[11:55] <isaac> soren: we would need either that fixed or the package I uploaded in the archive
[11:55] <Nafallo> yay! I have something I can't understand :-)
[11:56] <Nafallo>     *  Grund: Es wurde ein FastCGI-User mit UID und GID <1000 angegeben. Dies ist nicht erlaubt.
[11:56] <Nafallo>     * Lösung: User und Gruppe mit UID/GID >=1000 angeben. Ändern des Besitzers des Skripts nicht vergessen.
[11:56] <Nafallo> what does that say?
[11:57] <isaac> soren: well, it's just a corner case that shouldn't happen "often", but it could biete some users
[11:57] <dholbach> Nafallo: "a fastcgi-user with uid and gid < 1000 were submitted - that's not allowed - solution: use user and group with uid/gid>=1000, also don't forget the owner of the script."
[11:57] <persia> Nafallo: You shouldn't try to do things like that.  Use a UID/GID > 1000 for normal system users.
[11:57]  * persia notes that translation is better than gloss
[11:57] <Nafallo> aha. thanks :-)
[11:57] <Nafallo> persia: what can I say... it's CentOS and cPanel ;-)
[12:12] <proppy> oy
[12:45] <dholbach> MOTU Q&A session in 15 minutes in #ubuntu-classroom
[12:52] <yamal> Tr;1c'tm@M$m
[13:33] <norsetto> howdy all
[13:36] <pochu> hi norsetto
[13:36] <norsetto> hey pochu
[13:37] <RainCT> hi
[13:37] <warp10> hi norsetto!
[13:37] <norsetto> hey warpie!
[13:38] <norsetto> congrats RainCT, welcome in the team :-)
[13:38] <highvoltage> hey norsetto, long time no see
[13:38] <warp10> how are you doing, norsetto? :)
[13:38] <RainCT> norsetto: thanks :)
[13:38] <norsetto> warp10: pretty busy, and you?
[13:38] <norsetto> highvoltage: hi jonathan!
[13:39] <warp10> norsetto: fighting against flu. And flu is winning
[13:39] <norsetto> warp10: perhaps you should see a doctor ....
[13:39] <norsetto> warp10: ( I know, that was an easy one ....)
[13:39] <warp10> norsetto: indeed! Do you know one? :P
[13:39] <warp10> norsetto: (eheh)
[13:44] <allee> siretart: hi.  thx for fai 3.2.4.  rebuild without change on gutsy.  Btw. you remember which pkgs was 'broken' short before gutsy release that left fai PXE  unusable?
[13:46] <ryanakca> RainCT: Mind giving the last advocate? http://revu.tauware.de/details.py?package=basic256
[13:48] <RainCT> ryanakca: have you add a manpage?
[13:49] <RainCT> ryanakca: ok :)
[13:52] <ryanakca> RainCT: thanks :)
[13:52]  * ryanakca goes back to cooking breakfast
[13:53] <RainCT> ryanakca: the manpage says "ComicBook was written by Ian Larson <drblast@users.sourceforge.net>, Tony Dann <supertony007@googlemail.com> and Ferry Hendrikx <ferry.hendrikx@gmail.com>.", otherwise it looks great :)
[13:53] <RainCT> ryanakca: tell me what that should be and I'll upload
[14:09] <cyberix> Only one revu day left before Hardy?
[14:11] <sistpoty|work> hi folks
[14:16] <ryanakca> RainCT: sorry, I copied it over from my old package and modified :)
[14:19] <ryanakca> RainCT: wait to upload, rexbron gave me some things to work on in #ubuntu-ca
[14:19]  * ryanakca will reupload in a few minutes
[14:22] <norsetto> heya sistpoty
[14:22] <RainCT> ryanakca: reading the log, you can use dh_*'s
[14:22] <sistpoty|work> hi norsetto
[14:22] <RainCT> ryanakca: but you don't need dh_desktop as cdbs calls it automagically
[14:22] <RainCT> ryanakca: and instead of dh_install I recommend you using a debian/install file
[14:23]  * ryanakca nods
[14:26] <rexbron> ryanakca: as RainCT said, you could do away with teh extra lines in debian/rules as CDBS handels that behind the scenes
[14:29] <ryanakca> rexbron: :)
[14:33] <ryanakca> RainCT: ping, ok. 'dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package...'
[14:33] <ryanakca> so, would I need to put a 'postinstall' to move usr/bin/BASIC256 to usr/bin/basic256 ?
[14:36] <RainCT> rexbron: does using cp instead of dh_install  make any difference?
[14:41] <ScottK> ryanakca: IIRC that's how I've done it.
[14:44] <ryanakca> ScottK: thanks
[14:45] <ryanakca> RainCT: I'll run it threw my sbuild and if it doesn't complain, I'll upload to REVU
[14:46] <RainCT> ryanakca: okay :)
[14:46]  * norsetto -> afk
[14:46] <norsetto> ah ....
[14:51] <jdong> superm1: thanks for the advocating vote :)
[14:52] <jdong> MOTU's only need one advocate right? After that what's the next step in the procedure? To upload?
[14:53] <sistpoty|work> jdong: MOTU's are only encouraged to have it reviewed, but may upload entirely w.o. a review
[14:54] <jdong> sistpoty|work: oh, ok, I was under the impression that MOTU's needed to have an ACK on REVU before uploading. But in any case, a review is always a good idea :)
[14:55] <sistpoty|work> wtf... someone wrongly updated the developer reference again... grml
[14:55] <ryanakca> hmm.. is it .postinstall or .postinst ?
[14:55] <jdong> ryanakca: postinst
[14:55] <ryanakca> thanks
[14:55] <Lutin> is there a problem with qa.ubuntuwire.com/ftbfs ?
[14:56] <soren> sistpoty|work: Er... What?
[14:56] <sistpoty|work> soren: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[14:56] <soren> sistpoty|work: New packages need to be OK'ed by two MOTU's.
[14:56] <pochu> soren: not now
[14:56] <sistpoty|work> soren: the link to the new packages policy decision for MOTUs is even correct, but the text is wrong
[14:56] <soren> What? Since when?
[14:57] <sistpoty|work> 23 Feb 07
[14:58] <pochu> soren: https://wiki.ubuntu.com/MOTU/Council/Meetings/2007-02-23
[15:00]  * soren is deeply surprised.
[15:00]  * sistpoty|work always had the feeling that many people weren't aware of this
[15:00] <ryanakca> can I use $(CURDIR) in .postinst?
[15:01] <sistpoty|work> ryanakca: nope, $(CURDIR) is only valid in a Makefile
[15:01] <ryanakca> sistpoty|work: ok, so instead of say "s
[15:02] <ryanakca> "mv $(CURDIR)/debian/basic256/usr/bin/BASIC256 \", I would use "mv debian/basic256/usr/bin/BASIC256 \" ?
[15:02] <jdong> ryanakca: postinst runs after installation, not during build
[15:02] <jdong> ryanakca: I'm quite sure debian/ won't exist :)
[15:02] <ryanakca> jdong: ok. So, during build, if I wanted to move usr/bin/BASIC256 to usr/bin/basic256, where would I do so?
[15:03] <sistpoty|work> ryanakca: in debian/rules
[15:03] <jdong> ryanakca: probably as a part of the install target in rules
[15:03] <RainCT> what is X-Ubuntu-Gettext-Domain (.desktop) for?
[15:03]  * ryanakca puts it back into debian/rules.
[15:04]  * jdong uploads his advocated clutch to NEW and crosses his fingers :D
[15:06] <ryanakca> RainCT: ok... so I guess the dh_install part was only for the .desktop file, and I could've left my magic for installing the binary?
[15:06] <ryanakca> s/magic/cp/
[15:08] <RainCT> ryanakca: yes. I think that cp is also fine for .desktop files, but I'm not sure about this..
[15:08] <ryanakca> hmm...
[15:09] <ryanakca> can you have something other than 'file dest' in a .install file?
[15:10] <soren> ryanakca: Er..
[15:10] <soren> ryanakca: Why?
[15:10] <ryanakca> soren: example "debian/basic256.desktop usr/share/applications/
[15:11] <ryanakca> soren: because dh_install doesn't support renaming files
[15:11]  * ryanakca is looking to move "usr/bin/FOO" to "usr/bin/foo"
[15:11] <amarillion> ryanakca, I had the same problem
[15:11] <soren> So the real question is: "How do I install foo as bar?"
[15:11] <amarillion> I couldn't find a way to do ith with dg_install
[15:12] <ryanakca> there's also the problem that upstream has no "make install", so I have to copy the file from the root of the sources to usr/bin/
[15:12] <ryanakca> soren: exactly
[15:13] <amarillion> You just have to add a line like this in debian/rules: "install -m 755 FOO /usr/bin/foo"
[15:13] <amarillion> or rather debian/pkgname/usr/bin/foo
[15:13] <soren> ryanakca: I don't think dh_install will do that.
[15:13] <ryanakca> soren: no it won't
[15:13] <soren> From dh_install:                                 doit("cp", "-a", $src, "$tmp/$dest/");
[15:14] <ryanakca> amarillion: hmm.. I had that, but was told I should use dh_install http://revu.tauware.de/revu1-incoming/basic256-0802011520/basic256-0.9.2/debian/rules
[15:14] <ryanakca> amarillion: oh well, I'll just keep what I have
[15:14] <amarillion> yeah, the MOTU's are not always right
[15:14] <ryanakca> lol
[15:15] <amarillion> and often disagree amongst each other. Just take it with a grain of salt :)
[15:15]  * ryanakca reruns it threw sbuild...
[15:15] <amarillion> ryanakca, what is the name of your package? That link doesn't work for me
[15:16] <ryanakca> basic256
[15:16] <amarillion> ah I see. Yeah andrew said it would be "preferable" but in this case you have a good reason to do otherwise
[15:16] <soren> ryanakca: Upstream has no "make install"?
[15:16] <sistpoty|work> btw.: what I find a good practice for reviewing is to differentiate between stuff that's a must or stuff that's merely aesthethic (e.g. dh_install vs. cp in debian/rules)... maybe this can help?
[15:17] <soren> ryanakca: Then why "DEB_MAKE_INSTALL_TARGET  := install INSTALL_PREFIX=$(CURDIR)/debian/basic256/usr" ?
[15:17] <ryanakca> soren: nope
[15:17] <ryanakca> soren: I took that out
[15:18]  * ryanakca just hasn't uploaded it yet :)
[15:18] <soren> ryanakca: Oh, ok.
[15:18]  * ryanakca nods
[15:19] <RainCT> ryanakca: btw, running lintian on the .deb says:  W: basic256: wrong-name-for-upstream-changelog usr/share/doc/basic256/ChangeLog.gz. If there is an upstream changelog file, it should usually be installed as /usr/share/doc/<pkg>/changelog.gz
[15:20] <ryanakca> RainCT: took care of that :) maybe have a two reviewer comment boxes or string over them suggesting to seperate the "You must fix this" and "If you want an A+ package, you'll probably want to do this"
[15:20] <ryanakca> oops
[15:20] <ryanakca> lol, I stuck two messages together
[15:20] <vorian> can someone be so kind as to review http://revu.tauware.de/details.py?package=guake  :)
[15:20] <ryanakca> split the line at the ':)'
[15:22] <ryanakca> RainCT: ... or thought I did... according to 'mc', its called changelog.gz... but according to sbuild, its '-rw-r--r-- root/root      1851 2007-03-01 13:18 ./usr/share/doc/basic256/ChangeLog.gz'
[15:22] <ryanakca> RainCT: I guess I need to add an install line in rules to fix it?
[15:23] <ion_> dh_installchangelogs(1)
[15:23] <soren> DEB_INSTALL_CHANGELOGS_ALL in cdbs
[15:24] <ryanakca> ion_, soren thanks :)
[15:26] <bddebian> Heya gang
[15:27] <sistpoty|work> hi bddebian
[15:27] <bddebian> Heya sistpoty|work
[15:27] <ryanakca> hey bddebian
[15:27] <bddebian> Hello ryanakca
[15:29] <RainCT> Hey
[15:30] <bddebian> Hi RainCT
[15:33] <ScottK2> Bashism check please.  cp {index,category}.rhtml $(DESTDIR_)/share/dhelp/ is a bashism, right?
[15:33] <RainCT> ScottK2: yes
[15:33] <ScottK2> RainCT: Thanks.
[15:35]  * RainCT just found an easily reproducible crash in desktop-file-validate.. :/
[15:35] <jpatrick> hey bddebian, do you do mentor.debian.net sponsers? :)
[15:35] <RainCT> Is any bored C guy around? :P
[15:36] <ryanakca> RainCT: uploaded...
[15:37] <ryanakca> from the looks of it, REVU was changed to only scan every ten minutes on the tens, instead of every five minutes?
[15:38] <ScottK> ryanakca: AFAIK it's always been 10.
[15:38] <sistpoty|work> ryanakca: iirc yes, but I could also look at the cron entry if you want definite numbers ;)
[15:38] <bddebian> jpatrick: I upload lots of shit to mentors if that is what you mean.  IANADD. :-)
[15:38] <jpatrick> bddebian: ah, ok :)
[15:39] <bddebian> RainCT: So fix it ;-)
[15:39] <RainCT> bddebian: I can't :)
[15:39] <ryanakca> sistpoty|work: lol, no need :)
[15:39]  * ryanakca just gets impatient :)
[15:41] <effie_jayx> for changelogs is (LP: 1234567) or is it (LP: #1234567)
[15:41] <effie_jayx> ?
[15:41] <geser> Hi bddebian
[15:41] <bddebian> Heya geser
[15:41] <mok0>  (LP: #1234567)
[15:41] <jpatrick> effie_jayx: later
[15:41] <effie_jayx> jpatrick,  cool
[15:41] <geser> ScottK: check also if SHELL is not set to /bin/bash in /debian/rules
[15:41] <jpatrick> bddebian: you're not the first guy I've pinged today thinking of a DD :)
[15:42] <geser> RainCT: what C problem do you have?
[15:42] <ScottK> geser: Thanks.
[15:44] <bddebian> jpatrick: Well I'm in the NM queue now but I'll probably be dead and buried before that ever happens ;-)
[15:46] <RainCT> geser: bug #188073 :P
[15:46] <ubotu> Launchpad bug 188073 in desktop-file-utils "Reproducible segfault in desktop-file-validate" [Low,Confirmed] https://launchpad.net/bugs/188073
[15:48] <RainCT> ryanakca: "Comments for upload of February  01  15:20"   it isn't this or?
[15:48] <ryanakca> RainCT: wrong one...
[15:49] <geser> RainCT: nice, I can reproduce it and will see I what I can do to fix it
[15:49] <ryanakca> RainCT: I uploaded the fixed copy to the wrong place... :)
[15:49] <ryanakca> should up up in a few minutes :)
[15:49] <RainCT> geser: cool :)
[15:50] <ryanakca> RainCT: its up :)
[15:51] <RainCT> offtopic, anyone here uses openbox?
[15:59] <mok0> I have a question about writing changelog entries in a merge
[16:00] <mok0> I was told earlier to duplicate all the entries from earlier ubuntu merges and put them at the top
[16:01] <mok0> However, I have worked with DD to backport some of the ubuntu changes, so I am not sure how much ubuntu custimization is actually left in the merged package
[16:01] <wastrel> i've got a bug that has an upstream fix that needs to be updated in hardy
[16:03] <wastrel> 184505   if a kindly motu would take a look
[16:03] <jdong> bug 184505
[16:03] <ubotu> Launchpad bug 184505 in jppy "jppy fails to launch" [Undecided,New] https://launchpad.net/bugs/184505
[16:03] <sistpoty|work> mok0: I usually strip off all old changelog entries, because I take the debian package and redo every ubuntu customization that's present (i.e. I don't really merge it *g*)
[16:04] <sistpoty|work> mok0: however if doing so, make sure to not drop any info (lp bugs numbers, who submitted what patch, why was a patch applied etc.)
[16:04] <mok0> sistpoty|work: I got things from DaD
[16:04] <geser> mok0: in such cases, I ignore the changelog at first, create a debdiff, check what's in the debdiff and write then the changelog entry
[16:04] <mok0> geser: that seems doable
[16:04] <geser> mok0: of course check if the other changes in the old ubuntu delta are really included in the debian package
[16:05] <jdong> wastrel: I'll take a look when I get home this afternoon, if nobody else has taken care of it by that time
[16:05] <ScottK> Then there are the fun undocumented changes you discover that way and wonder if they should really be there or not.
[16:06] <mok0> I'd think that unless the changes are really important, it would be better to get as close as possible to the debian version
[16:06] <geser> ScottK: I check then if there are in the old ubuntu delta and drop any undocumented changes to .po files usually (when working with MoM)
[16:07] <sistpoty|work> mok0: that depends... if you get almost close, you still have a merge instead of a sync. Nonetheless it's worth trying to do that.
[16:08] <mok0> sistpoty|work: how do you change a merge to a sync?
[16:08] <ScottK> geser: That's about what I do too.  One of my recent main merges had some undocumented debian/rules trickery that it took quite some time to sort out.
[16:08] <sistpoty|work> mok0: if there are no changes left, it's a sync
[16:09] <ScottK> slangasek: Is killing off old DB versions an official release goal for Lenny (I don't see it documented)?
[16:09] <wastrel> merci
[16:09] <sistpoty|work> ScottK: iirc killing duplicate code in the archives is (and I guess that would include old DB versions)
[16:10] <sistpoty|work> duplicate library code even
[16:11] <zoli2k> Hi! I write a howto for the compilation of some source code on ubuntu. How can I track, all the dependencies of compilation and calculate which packages are necessary to compile a source. Do I need a fresh installation?
[16:11] <zoli2k> I strongly apologize if I m asking this on wrong channel.
[16:11] <geser> zoli2k: try&error
[16:12] <ryanakca> can someone please review http://revu.tauware.de/details.py?package=basic256 ?
[16:12] <wastrel> zoli2k: one trick is  apt-get build-dep <packagename>
[16:12] <geser> zoli2k: reading INSTALL or README for requirements often helps
[16:12] <wastrel> if the thing you're compiling is also packaged in the repos
[16:12] <geser> wastrel: that only works if there is a package already :)
[16:12] <wastrel> yah
[16:13] <sistpoty|work> zoli2k: if it does compile in your system, you could do a objdump -p <executable_or_library> | grep NEEDED and try to see what the build-dependend libraries could be
[16:13] <sistpoty|work> zoli2k: if not, I usually look at upstream's README to find some hints
[16:13] <geser> zoli2k: an other help is to check which libs configure tries to find
[16:13] <zoli2k> I am trying to write a compiling howto for l7 filter.
[16:15] <zoli2k> thanks, I this will help a lot. I just want to be sure that a step-by-step howto will be correct if the user apply it on a fresh installation.
[16:16] <dcordero> if someone has report a sync request from Debian. And the only change is to change the maintainer to motu. is that the right way send a debdiff to launchpad?
[16:17] <sistpoty|work> dcordero: no, then it's really a sync request and should get synced by the archive admins
[16:17] <dcordero> oki
[16:17] <dcordero> thanks
[16:19] <mok0> So I open an LP bug and attach the debdiff, and subscribe u-u-s, right?
[16:19] <RainCT> superm1: does your advocation for basic256 still apply?
[16:20] <sistpoty|work> mok0: right
[16:21] <mok0> sistpoty|work: any particular tag needed?
[16:22] <sistpoty|work> mok0: no idea... haven't looked at the sponsors queue for ages myself and am not up to date on policy there :/
[16:23] <ScottK> mok0: No particular tag needed for a merge.
[16:23] <mok0> ScottK: ok thx
[16:23] <RainCT> ryanakca: great, advocated :). If superm1 agrees, I'll upload it
[16:24] <ryanakca> RainCT: thanks :)
[16:26] <RainCT> @now europe/berlin
[16:26] <ubotu> Current time in Europe/Berlin: February 01 2008, 17:26:18 - Next meeting: MOTU in 3 hours 33 minutes
[16:26] <sistpoty|work> ryanakca: out of interest: did you try to build base256 on an amd64?
[16:27] <jpatrick> RainCT: /msg ubotu thing
[16:27] <slangasek> ScottK: dunno, honestly; it's a goal of mine for lenny, and I haven't hesitated to file bugs and NMU :)
[16:28] <ScottK> slangasek: I've got an NMU for dhelp almost ready to fix a bashim and bump them to a later libdb4.xruby.  Would you sponsor it for me then?
[16:29] <RainCT> jpatrick: btw, where is the meeting? #ubuntu-meeting?
[16:29] <nxvl_work> dholbach: around?
[16:29] <jpatrick> RainCT: yeah
[16:29] <dholbach> nxvl_work: yes
[16:29] <slangasek> ScottK: oh, there /is/ a later libdb4.x ruby?  sure, I could have a look at that
[16:30] <nxvl_work> dholbach: i have just read your mail about the Developer week
[16:30] <dholbach> nxvl_work: cool
[16:30] <nxvl_work> dholbach: and i was thinking on a session about the DCT, and how to colaborate back to debian
[16:30] <nxvl_work> dholbach: about best practices and stuff
[16:30] <ScottK> slangasek: Yes.  libdb4.4-ruby got added to the archive late in December.  I've asked to have it sync'ed into Ubuntu so we can kill libdb4.2-ruby and libdb4.3-ruby.
[16:31] <dholbach> nxvl_work: sounds good - make sure you talk to james_w about it - he was interested in doing that too
[16:31] <dholbach> nxvl_work: you have his email address?
[16:31] <slangasek> ScottK: ah, so "newer" but still lagging :)
[16:31] <ScottK> slangasek: Yes.
[16:31] <nxvl_work> dholbach: nop, but i think it should be on LP
[16:31] <dholbach> nxvl_work: hang on, I'll give it to you
[16:31] <slangasek> ScottK: in that case it might be better to push for a libdb4.6-ruby first, since db4.4 should actually be a "lower-hanging" target than db4.2 (thanks to openldap :/)
[16:31] <ScottK> slangasek: But I think killing off db4.2 and 4.3 would be a good achievement for Hardy.
[16:31] <nxvl_work> dholbach: ok, thanks
[16:32] <rexbron> RainCT: In answer to your question, using .install files instead of cp or calling dh_install on the files directly is far cleaner and allows one call to dh_install in the rules file to install files for multiple binaries
[16:32] <ScottK> slangasek: But you're going to get the openldap thing sorted, so it'll go away in the end, right?
[16:33] <slangasek> ScottK: I'm not actively working on sorting openldap; it blocks on bdb upstream resolving openldap upstream's performance concerns
[16:33] <RainCT> rexbron: right, but not really if there's just one or two files or if it needs to be renamed :)
[16:33] <ScottK> slangasek: It was more of a royal you.
[16:33] <rexbron> RainCT: that is up to the packager then
[16:34] <slangasek> ScottK: ok :)
[16:34] <rexbron> RainCT: in ryanakca case, since he is using cdbs, it makes more sense to just use .install files and let cdbs take care of it
[16:35] <RainCT> rexbron: in his case, he needed to rename
[16:35] <slangasek> ScottK: in any case, I think it's unlikely that we'll see db4.2 gone for hardy; so in terms of priorities I think db4.4 might be the better target
[16:35] <ScottK> OK.
[16:35] <rexbron> Moot point, I prefer .install files rather than explicit calls
[16:36] <rexbron> IMO, it is better to teach the practices that are useful for more complex packages when applicable to simple ones.
[16:37] <sistpoty|work> well, you can also use cp for multiple packages...
[16:37] <sistpoty|work> (and I don't find using .install files much cleaner actually)
[16:37] <effie_jayx> I have the debdiff ready for launchpad... I change the bug to fix Commited and subscribe main-sponsors? or I just subscribe main-sponsors
[16:37] <sistpoty|work> however I think it's not so nice to mix both install files and using cp somewhere
[16:39] <ScottK> slangasek: OK.  At a glance making a new db4.x-ruby package appears trivial.
[16:41] <Coper> It how do I do for lintian should more errors?
[16:41] <Coper> when I run it it's says nothing but on review I got alot of warnings.
[16:41] <ryanakca> Coper: lintian -I foo      iirc
[16:41] <nxvl_work> scottK: thanks for sponsoring my packages
[16:41]  * nxvl_work HUGS scottK
[16:42] <RainCT> effie_jayx: just subscribe
[16:42] <ScottK> nxvl_work: Thank you for contributing.  According to slangasek (see above) DB 4.3/4.4 might be better ones to be working on killing off.  Just watch for packages that use transactions in BDB.
[16:43] <effie_jayx> RainCT,  thanks
[16:43] <slangasek> ScottK: hmm, this discussion may have just led me to the fix for Debian bug #463397 in php :)
[16:43] <ubotu> Debian bug 463397 in php5 "dba_open fails" [Important,Open] http://bugs.debian.org/463397
[16:43] <ScottK> Cool.
[16:44] <RainCT> Coper: if you aren't doing so, check both the .dsc (or source) and .deb
[16:44] <sistpoty|work> ryanakca: nevermind my previous question... (I just remembered a basic interpreter that was far from 64bit clean, but that was a completely different one)
[16:44] <ScottK> slangasek: My recommendation for php bugs is always removal, but no one listens.  What's the fix?
[16:44] <mok0> Before Christmas, I did some changes to xtide-data, which should be scrapped, the packaged should be a straight sync. How do I do that?
[16:45] <Coper> I got a problem that the package is not installed in /usr/games how can I change install dir?
[16:45] <RainCT> mok0: request a sync on launchpad explaining why the changes can be dropped and subscribe u-u-s
[16:45] <slangasek> ScottK: the fix is to lart my comaintainer for overriding the build-dependency on libdb4.6-dev when building ;)
[16:45] <ryanakca> sistpoty|work: hmmm?
[16:45]  * ryanakca scrolls back
[16:46] <mok0> RainCT: ok sounds simple
[16:46]  * ScottK smiles
[16:46] <sistpoty|work> ryanakca: /me asked if you tried building basic256 on amd64
[16:46] <ScottK> slangasek: Except there is not libdb4.6-dev in Debian.
[16:46] <ryanakca> sistpoty|work: ah. Nope, haven't tried... feel free to try if you want... *isn't running an amd64 / 64bit kernel*
[16:47] <sistpoty|work> ryanakca: heh, well, need to get work done atm... but I took a quick glance at the code and it looks very clean (and very different from the basic interpreter I once tried)
[16:48] <sistpoty|work> ryanakca: so I guess there shouldn't be issues ;)
[16:48] <ryanakca> lol, okies ;)
[16:54] <slangasek> ScottK: libdb4.6-dev is a Provides: of libdb-dev; and it's what you have to build-depend on if you want to have control over which version of libdb you're building against
[16:54] <slangasek> (this is the "libdb-dev is ill-advised, etc., etc." from yesterday)
[16:55] <ScottK> slangasek: OK.  I guess I got the wrong impression then from reading debian/changelong in the latest Ubuntu revision.
[16:55] <ScottK> I thought only Ubuntu has that now.
[17:09] <Coper> I have some problem to find a way to change install dir from /usr/bin to /usr/games
[17:15] <geser> RainCT: bug #188073 fixed
[17:15] <ubotu> Launchpad bug 188073 in desktop-file-utils "Reproducible segfault with desktop-file-validate" [Low,Confirmed] https://launchpad.net/bugs/188073
[17:15] <RainCT> geser: great :)
[17:28] <ScottK> slangasek: I did my bit on the libdb4.x-ruby thing by making a 4.6 package.  If you'd push it on through NEW, then we could get on with killing off BD 4.3/4.4.
[17:29] <slangasek> ScottK: ok, I'll have a look in a bit
[17:29] <slangasek> are you wanting a reverse-sync to Debian too? :)
[17:29] <ScottK> slangasek: Thanks.
[17:30] <ScottK> slangasek: Yes, but I figured I'd hit lucas up for that so it gets into the right team in Debian.
[17:32] <rexbron> Coper: Have you looked at dh_install?
[17:33] <slangasek> ScottK: fair enough :)
[17:33] <RainCT> I'm off for a while.. cya
[17:41] <smarter> Hey (:
[17:41] <smarter> Could someone please review some of my packages? http://revu.ubuntuwire.com/details.py?package=extremetuxracer and http://revu.ubuntuwire.com/details.py?package=kde4-style-bespin thanks!
[17:42]  * sistpoty|work heads home
[17:42] <sistpoty|work> cya
[17:42] <jpatrick> smarter: you seem to be... upside down
[17:44]  * smarter likes upside down smileys
[17:51] <lucas> ScottK: yup, that would be appreciated.
[17:51] <ScottK> lucas: I just filed the ITP.
[17:51] <lucas> ScottK: are you sure that 4.6 is actually supported by upstream? I think it wasn't last time I checked
[17:51]  * ScottK goes and checks some more.
[17:53] <ScottK> slangasek: I think I need to do some more testing before you new that package.
[17:53] <slangasek> ok
[17:53] <lucas> ScottK: bdb-0.6.2.tar.gz doesn't really say that it works with 4.6
[17:54] <ScottK> Agreed.
[17:54] <slangasek> I'd be surprised if it didn't, fwiw
[17:54] <slangasek> but I won't discourage you from testing :)
[17:54] <ScottK> lucas: The changelog doesn't say much as all (several versions not mentioned at all).
[17:55] <lucas> I'll mail the upstream
[17:55] <LaserJock> hot doc, I upgraded to Hardy and tracker actually works
[17:55] <LaserJock> *hot dog
[17:55] <ScottK> lucas: Thanks.
[17:55] <ScottK> LaserJock: I'm sure someone's working on fixing that.
[17:56] <LaserJock> ScottK: fixing it to not work again? :-)
[17:56] <CyberMatt> could someone please advocate this http://revu.tauware.de/details.py?package=jailkit
[17:56] <ScottK> LaserJock: Yes ;-)
[17:57] <lucas> ScottK: you packaged it using libdb4.4-ruby as a basis?
[17:57] <ScottK> lucas: Yes
[17:58] <lucas> ScottK: ok
[17:58] <lucas> ScottK: I mailed the upstream. wait and see :)
[17:58] <ScottK> Great.
[17:58] <CyberMatt> two people if your feeling nice (:
[17:58] <ScottK> lucas: I even changed your credit in debian/copyright to credit you in libdb4.4-ruby
[17:59] <lucas> heh ;)
[18:00] <LaserJock> ScottK: quite possible. In gutsy it wouldn't actual index much of anything but my email
[18:00] <LaserJock> now that I'm working on my dissertation indexing journal articles is a  big plus
[18:01] <effie_jayx> the package is in multiverse .. who do I subscribe to the bug
[18:02] <ScottK> effie_jayx: For a bugfix/merge it's still UUS
[18:03] <effie_jayx> ScottK,  for a bug fix
[18:03] <effie_jayx> UUS?
[18:04] <ScottK> ubuntu-universe-sponsors
[18:04] <effie_jayx> ScottK,  ok
[18:12] <tuxmaniac> LaserJock, hello
[18:12] <LaserJock> hi tuxmaniac
[18:33] <ryanakca> is it normal that you can apt-cache show <foo>, but not apt-get source <foo> ?
[18:34] <ryanakca> ex, http://blog.ryanak.ca/topal
[18:34] <ScottK> ryanakca: The first foo is a binary package name.  The second one wants a source package name.
[18:35] <ryanakca> ScottK: okies
[18:35] <ryanakca> !info topal
[18:35] <ubotu> topal (source: topal): Links Pine and GnuPG together. In component multiverse, is extra. Version 0.7.13.6-1ubuntu1 (gutsy), package size 222 kB, installed size 660 kB (Only available for i386 sparc powerpc)
[18:36] <ryanakca> ScottK: same binary/source package name according to that...
[18:36] <ScottK> Next question would be do you have multiverse turned on.
[18:36] <superm1> ScottK, actually you can use binary or source package name in the second case
[18:36] <superm1> i just tried
[18:36] <ryanakca> ScottK: nvm :)
[18:37] <ryanakca> ScottK: might be interesting to update the package... it can now go into universe since its GPL :)
[18:38] <ryanakca> ScottK: ... and yes, multiverse is enabled
[18:38] <ryanakca> oh well, I'll just dget
[18:44] <blueyed> ryanakca: try apt-cache madison <foo>, which works for both foos.
[18:48] <LaserJock> showsrc is also good
[18:57] <ion_> Awesome news for people maintaining packaging in a git repository: http://kitenet.net/~joey/blog/entry/generating_pristine_tarballs_from_git_repositories/
[18:58] <LaserJock> ion_: ah, that is nice
[19:00] <nixternal> afternoon :)
[19:02] <LaserJock> nixternal: how ya feelin'?
[19:02] <nixternal> a tad bit better today
[19:03] <nixternal> but looking outside and seeing nearly a foot of snow makes me sad...I sure hope it doesn't melt quick, I need to hurry up and get well, I have some snowmobiling to do! :)
[19:03] <LaserJock> heh
[19:11] <slicer> Anyone have time to go through http://revu.tauware.de/details.py?package=mumble with me and get the final pieces in place?
[19:22] <jdong> ryanakca: apt-cache source foo only works if you have deb-src lines to match the binary repo in question
[19:23] <jdong> ryanakca: if that's met, apt-cache source foo even works if you specify a binary package name corresponding to some available source package
[19:23] <jdong> ryanakca: some of us have dirty little HTTP scrapers that directly locate and retrieve source packages from launchpad ;-)
[19:30] <superm1> jdong, you want to take a stab at my revu on there too needing an ack?
[19:31] <ScottK2> Anyone thinking their about ready to apply for MOTU is welcome to take a stab at the pending Courier merge.
[19:34] <LaserJock> huh, MS wants to buy Yahoo
[19:34] <ScottK2> So I've got this box that I should have upgraded two years ago and didn't.  It's got Xandros 3 (based on Sarge) and I'd like to see if I can cross-grade it to Kubuntu.  My current plan is upgrade to Dapper and then follow the releases from there.  Comments?
[19:34] <ScottK2> LaserJock: Yes.  Old news :-)
[19:35] <LaserJock> ScottK2: well *I* just read it so it's new news to me ;-)
[19:35] <ScottK2> Yeah.  There is that.
[19:36] <LaserJock> ScottK2: that upgrade plan sounds sort of reasonable. Is is a desktop machine?
[19:36] <LaserJock> *is it
[19:36] <smagoun> Hi all, I'm looking for a sponsor to get an update to the moblin-applets package into universe: https://bugs.edge.launchpad.net/ubuntu/+source/moblin-applets/+bug/187181
[19:36] <ubotu> Launchpad bug 187181 in moblin-applets "Upgrade to moblin-applets 0.27" [Undecided,In progress]
[19:36] <ScottK2> LaserJock: Laptop.
[19:37] <LaserJock> why not wipe it?
[19:37] <LaserJock> or are you just wanting to experiment
[19:38] <ScottK2> Wanting to experiment and it's got a bunch of accounts on it and I'd rather not have to recreate them all.
[19:39] <ScottK2> I'll back everything up first, so it's no great trouble if it doesn't work.
[19:46] <ryanakca> jdong: lol :)
[19:46] <LaserJock> bah, I think I found a nice little regression in Hardy
[19:47] <LaserJock> in the mouse setting for a touchpad the "Tap to click" check box doesn't seem to do anything
[19:48] <LaserJock> how annoying, perhaps I can find the code for it
[19:53] <jdong> superm1: what do you have on REVU? I need to look at lucidfox's tovid package too. I have both planned for later after I finish packing, and lucidfox will need two ACKs too
[19:53] <zul> smagoun: you might have an easier time in the -mobile channels
[19:53] <superm1> jdong, gmyth
[19:53] <superm1> i can take a look at tovid after i finish packaging baracuda
[19:53] <jdong> superm1: ok, sweet. What a busy day huh :D
[19:54] <smagoun> zul: thanks. I'm at the mobile sprint right now, in fact. Trying to do this the 'right way'...
[19:54] <superm1> jdong, yesterday all i did was revu stuff :)
[19:54] <zul> ah
[19:54] <superm1> that and watch lost
[19:54] <superm1> but you know
[19:58] <nixternal> umm, meeting time?
[19:59] <ScottK> nixternal: Thanks for the reminder
[19:59] <nixternal> heh, only reason I remembered is because I fixed my script to grab the ical file from the fridge and import it into Kontact for me :)
[19:59] <nixternal> I just got the warning
[20:03] <vemon> any motu's who are interested in linux audio production? http://revu.tauware.de/details.py?package=lashwrap (LASH wrapper for non-LASHified audio/midi apps) http://revu.tauware.de/details.py?package=ghostess (dssi host)
[20:05] <desertc> Anyone familiar with the discussions with Thorvald from the Mumble project?  I am trying to work with him and coax him in the right direction to get his software packagable.  The discussion seems to have stalled out on Launchpad.
[20:06] <desertc> He says he has been in this channel trying to work with people, but he doesn't remember who, but he feels like the Speex issue has been resolved.
[20:07] <hellboy195> hoi jono, our well known community manager :)
[20:07] <jono> hey hellboy195 :)
[20:10] <joejaxx> :)
[20:10] <joejaxx> has anyone seen Zelat?
[20:10] <joejaxx> Zelut*
[20:11] <desertc> It would obviously be awesome to have voice conferencing software integrated into Ubuntu by Hardy, so I have been trying to track the progress and help where I can.  Persia, I hate to tap you again, but Thorvald said he had talked with you about the packaging.
[20:12]  * desertc gives praise to the superstar persia.
[20:13] <frafu> Hello, I am trying to use dh_gconf in a package using debhelper, but I don't know how to do it. What else do I have to do apart adding dh_gconf to the binary-arch target?
[20:17] <superm1> hm if an export from cvs/svn/hg/git doesn't have autogen.sh, how are you supposed to build configure/Makefile
[20:17] <frafu> If I got it right, I can remove  --with-gconf-schema-file-dir=/usr/share/gconf from the configure command in debian/rules, but the schemas always end in /usr/etc/gconf (report from lintian)
[20:18] <geser> superm1: ask upstream how they do it
[20:18] <superm1> geser, yeah that's what i was thinking i was gonna have to do
[20:20] <superm1> geser, it appears that autogen.sh from http://buildconf.brlcad.org/ works, so i'll add that to get-orig-source and let upstream know they need to start shipping it too then
[20:22] <desertc> geser: Do you have any recollection of the OnScripter package?  Wondering if it is worth updating.
[20:24] <geser> desertc: no, from looking at the debdiff I guess it was a fix for a build-failure.
[20:24]  * blueyed also cheers persia :)
[20:26] <desertc> geser: I talked with the developers who release graphic novels with OnScripter, and they said they typically package whatever versions with each release, so it's probably not imperative to have Ubuntu's OnScripter up-to-date, even though our version is 3 years old.
[20:27] <desertc> gaser: Just wanted to get your opinion on it, since your name was associated with the package.
[20:28] <blueyed> What's the best method to get *.ogg from a http path in the current directory?
[20:29] <geser> desertc: if you think it should be updated that go on, I've no opinion on it
[20:44] <desertc> Back to the Mumble topic again, I just learned *wave* that slicer is the lead developer and is perma-idled here in #ubuntu-motu .  He's very eager to resolve any remaining issues.
[20:47] <ScottK2> desertc: Reading the description ... Why do we need a package for yet another proprietary VOIP protocol in the archives?
[20:49] <leonel> the patches fixed in ubuntu  get back to  debian  ??
[20:49] <desertc> ScottK2: Mumble is similar in function to Teamspeak and Ventrilio, where multiple users join a channels on a server.  It is often used for online games.  To my knowledge, there is nothing available for Linux like Mumble.
[20:49] <ScottK2> leonel: Sometimes
[20:49] <leonel> ok
[20:49] <ScottK2> desertc: Fair enough.
[20:49] <ScottK2> leonel: Did you have something specific in mind?
[20:49] <leonel> just to clear  a discussion overhere ..
[20:50] <leonel> not a real patch to send to debian
[20:50] <frafu> Somebody knows a package using debhelpers and dh_gconf, so that I can look how to set it up?
[20:50] <ScottK2> Where there is an ubuntu change, it shows up on the Debian Package Tracking System.
[20:50] <ScottK2> So Debian maintainers know about it.
[20:51] <desertc> ScottK2: Also, worth mentioning quickly, Mumble is open source software, unlike Teamspeak or Ventrilio, which may support or plan to support Linux versions.
[20:51] <ScottK2> leonel: Good Ubuntu developers will file bugs with patches in Debian.
[20:51] <ScottK2> desertc: OK.  I'm convinced.  I'll go back to looking.
[20:51] <leonel> ScottK2:  thanks
[20:53] <ScottK2> desertc: Since we already have speex in the archive, can the package use that instead of it's own copy?  Code duplication is hell for maintenance.
[20:54] <geser> and for security updates
[20:55] <ScottK2> Absolutely.
[20:55] <desertc> ScottK2: This is the information I gathered through my discussion with the Mumble developer: http://pastebin.ca/888059
[20:57] <desertc> It is his opinion that this issue has already been resolved through discussions he had in this channel (user name: slicer ), however, he does not have logs on with whom he discussed this topic.
[20:59] <ScottK2> desertc: It wasn't resolved with me, so I ask.
[20:59] <desertc> Anyway, any resolution we can come to on the topic of Mumble / Speex should be documented on the launchpad page, imho.
[20:59] <desertc> Since, right now it looks like an open issue.
[21:02] <desertc> Even if there can be a decision made that this is not acceptable.  At least the specific roadblock would be documented.
[21:03] <ScottK2> Would it make sense to update the current speex version in the archive to the one Mumble is using?  Would that cause problems with other packcages?
[21:03] <desertc> Yes, I asked about this too, which generated the response that I pastebin'd: "The problem really is that there is no modern and stable version of Speex;"
[21:04] <ScottK2> Right, so let's pick one
[21:05] <desertc> Sounds good to me, at least.  " slicer " told me he had to go afk for company who visited his house.
[21:05] <desertc> Sounds like we could choose the version he is presently using in his latest stable, and see what conflicts would arise from using it.
[21:06] <ScottK2> Nevermind.  I just looked and speex has a LARGE number of packages depending on it.
[21:06] <ScottK2> It'd take some testing.
[21:07] <desertc> Right.  Which is surely why Ubuntu is using an old version.  But eventually, that will need to get updated anyway.  I wonder about the processes in place to test that functionality.
[21:09] <desertc> As the developer mentioned, with Speex, you can choose the 1.2 which is beta, or the 1.0.5 which is not even recommended by the Speex team: http://www.speex.org/downloads/
[21:09] <slangasek> or, apparently, you can choose 1.1.12 which is what we have in hardy
[21:10] <ScottK> Yes.
[21:10] <desertc> ... and also in Gutsy
[21:11] <slicer> 1.1.12 is one of the alpha versions of the 1.2 betas.
[21:11] <ScottK2> slicer: Then it'd at least make sense to update that to a later beta.
[21:11] <desertc> So, perhaps this Mumble package needs to wait until Speex 1.2 stabilizes and we can all formalize on that standard?  He is planning on adopting 1.2 as soon as it is available
[21:12] <desertc> oh, welcome back slicer - I can stop putting words in your mouth now.  ;-)
[21:12] <slicer> ScottK2: That will probably break a few packages. Any package which uses any of the more advanced functionality of speex will not compile with 1.2b.
[21:12] <slicer> ScottK2: Nor will it compile with earlier versions of 1.1
[21:13] <slicer> And it still will not include any of the changes we've made to speex.
[21:13] <ScottK2> OK.  Fair enough.  Don't be suprised to have this conversation a few more times before it's all over.
[21:14] <slangasek> well, "we've changed the library" is not a great reason to accept embedded copies in the archive.  why are those changes not integrated upstream?
[21:14] <slicer> slangasek: Because we use a LOT of the internal functions in speex.
[21:14] <slicer> slangasek: Things that you normally would never, ever want a end-developer to touch.
[21:14] <desertc> May I summarize (or someone more knowlegable do it) the results of this discussion on the bug page?  I think it will bring the future people in this discussion up to speed faster
[21:15] <ScottK2> Which is not a recipe for long term success.
[21:15] <slangasek> slicer: fine; why does *your* app warrant special treatment? :)
[21:15] <slicer> slangasek: Because you currently do not have the code we include?
[21:15] <slangasek> i.e., if everyone else should be at arm's length from these internals, why should Mumble be allowed to be different?
[21:15] <slicer> slangasek: Ah.
[21:15] <ScottK2> slicer: FYI, in case you didn't know ^^^ is the Ubuntu release manager
[21:16] <slangasek> meh, why can't I ever just be an anonymous IRC person? :)
[21:16] <slicer> slangasek: We basically had a choice. Cut&paste most of the functions we need into our own code, or keep the "library" separate.
[21:17] <slicer> slangasek: Since keeping it separate allows us to get the functionality updates much cleaner, we went with that route.
[21:18] <slangasek> slicer: hmm, maybe I should rephrase. You've made local changes to libspeex.  have those changes been pushed upstream, and are they on track for inclusion?  If not, why not?
[21:19] <slicer> slangasek: Most of the "globally interesting" changes have been applied upstream a long time ago. What remains is exposure of internal data structures.
[21:19] <slangasek> and why is your app special in needing those data structures exposed?
[21:20] <slicer> slangasek: We expose the audioframe analysis. Without this, we'd have to duplicate all the code for the statistics and automatic tuning in the GUI.
[21:20] <slangasek> (that's not something that would block inclusion in an Ubuntu release in universe, but it does lead me to think that some piece of code in this puzzle is not yet as mature as it ought to be)
[21:20] <slicer> slangasek: Which would mean doing the entire analysis *TWICE* (once in libspeexdsp, and once in our app), and we'd be back with a large chunk of code being cloned from libspeexdsp.
[21:20] <slangasek> slicer: right; so why would it be wrong to expose that as part of the API?
[21:22] <slicer> slangasek: Well. First of all, the data structures are highly platform dependant. Which fields are available, and their type, depend on the platform you're running on.
[21:22] <ScottK2> slicer: I'm also curious about your proprietary VOIP protocol.  Is it free for others to implement?  What's proprietary about it.
[21:22] <slicer> ScottK2: Absolutely free.
[21:23] <slicer> ScottK2: Well. "BSD-licensed" to be exact.
[21:23] <ScottK2> The package description describes it as proprietary.
[21:23] <ScottK2> That probably ought to be changed then.
[21:23] <dcordero> hi
[21:24] <ScottK2> desertc: ^^^ Comment for you on the packaging.
[21:24] <ScottK2> hi dcordero
[21:24] <slicer> ScottK2: Hm. Probably true. Thing is, it's not H323 or SIP, so what's a good word?
[21:24] <ScottK2> Unique
[21:24] <ScottK2> slicer: Is it patented?
[21:24] <slicer> ScottK2: Nope.
[21:25] <slicer> ScottK2: Only patent issue I'm aware of is the one for the crypt; but that's been openly licensed to any and all opensource projects.
[21:25] <desertc> scottK2: right.
[21:25] <slangasek> mm, "crypt"?
[21:25] <ScottK2> slicer: You might look at http://www.openpatents.org/ then.
[21:25] <slicer> ScottK2: It's not my patent :) I'm strongly opposed to patents.
[21:25] <slangasek> slicer: "non-standard" would be better
[21:26] <slangasek> (maybe not "good", but "better")
[21:26] <ScottK2> slicer: openpatent doesn't require you have one.
[21:26]  * ScottK2 likes non-standard.
[21:26] <slicer> slangasek: We encrypt all the voice communication. Some gamers are paranoid.
[21:26] <StevenK> Some?
[21:27] <DarWin_vcch> all :)
[21:27] <slangasek> slicer: and you're not just depending on one of the opensource crypto libraries for this? (gnutls, openssl)
[21:27] <paas> Hi, Could someone please review my package http://revu.tauware.de/details.py?package=libtuxcap, thanks!
[21:28] <slicer> slangasek: No. It's mostly usefull for stateless protocols, and I found no opensource implementation. See http://www.cs.ucdavis.edu/~rogaway/ocb/grant.htm for the GPL-exception grant.
[21:30] <slangasek> well, ok - I guess I don't know if gnutls or openssl implement anything suitable for udp
[21:30] <slicer> slangasek: Thing is, if you want both encryption and authentication, you can do the classic two-pass implementation (which is patent-free). However, it uses twice the space for the authentication header (more bandwidth) and a little more than twice the CPU.
[21:30] <slangasek> it's a deficiency if they don't though
[21:30] <slicer> slangasek: They implement crypt. But not "crypt+auth". It's an active field of research :)
[21:31] <slicer> slangasek: It's basically HMAC and OFB rolled into one.
[21:31] <slicer> slangasek: It's built around AES though, and I do use the AES128 implementation from openssl.
[21:36] <ScottK2> slangasek: On libdb4.6-ruby, everything except transactions works.  Those hang.
[21:36] <slangasek> slicer: DTLS is an RFC, and appears to be implemented in OpenSSL; and DTLS appears to inherit auth support from TLS.  But it's somehow unsuitable?
[21:37] <slangasek> ScottK2: mm, fun
[21:37] <vemon> what's this tarball.mk cdbs include?
[21:37] <slangasek> vemon: for handling tarball-in-tarball packaging; run as far away as you can
[21:38] <vemon> it seems to totally mess thing up
[21:38] <vemon> there's this package (jack-rack) i'm trying to upgrade to new upstream version and the original debian package uses tarball.mk
[21:40] <vemon> i had to remove the tarball.mk include from rules to get dpkg-buildpackage working. before the removal it seems the source wasnt unpacked to build-tree at all
[21:40] <ScottK2> slangasek: What do you think about NEWing the package as is and I'll file a bug on it that says don't use this with transactions.?
[21:40] <vemon> i wonder how the package even worked before
[21:40] <slangasek> ScottK2: could probably do that, yes
[21:41] <LaserJock> oh man, compscibuntu
[21:41] <slangasek> LaserJock: ?
[21:41] <slicer> slangasek: We do the key exchange over the secured TLS link, we also don't need any retransmission, and we have lower overhead.
[21:41] <LaserJock> slangasek: just found a new "derivative"
[21:41] <LaserJock> first there was scibuntu, now we get compscibuntu
[21:42] <ScottK2> slicer: Are you going to be around to help out with a patch if a CVE comes up on this package?
[21:43] <slicer> ScottK2: Absolutely.
[21:43] <desertc> slicer scottk2 slangasek : I brought in isforinsects who represents the Speex project.  He has deployed the protocols in the OLPC project and OGG/Theora+Speex.  He is also doing the documentation.
[21:44] <slicer> ScottK2: Well, barring physical injury, world war 3 or something similar at least.
[21:44] <isforinsects> Hello
[21:44] <ScottK2> Hello
[21:44]  * slangasek waves
[21:44] <desertc> I know you weren't asking for them, but I thought he might want to listen in on the discussion.
[21:45] <slicer> Hello.
[21:46] <isforinsects> So someone mind catching me up?
[21:46] <desertc> I can provide you some links in a PM
[21:46] <vemon> is running pdebuild any different from first creating the source package and then building it using (sudo) pbuilder build?
[21:46] <ScottK2> The biggest question that touches your area of interest is that mumble ships it's own copy of speex.  We'd like to avoid ducplicate copies of libs in the archive.
[21:47] <dcordero> where can you found icons for a package without icons in his .desktop files?
[21:48] <RainCT> dcordero: project homepage, google (but check licensing)..
[21:48] <RainCT> dcordero: or ask someone to create on..
[21:48] <RainCT> s/on/one
[21:49] <vemon> if you create one then you should probably also send it upstream then
[21:49] <dcordero> ok
[21:49] <dcordero> and another question :)
[21:50] <dcordero> imagine that the same package has 2 different versions on debian and ubuntu
[21:50] <dcordero> for example package-1.0-5 and package-1.0ubuntu8 in ubuntu
[21:51] <dcordero> if a bug appear on launchpad for package-1.0ubuntu8 for a bug solved on package-1.0-3 in debian...
[21:51] <dcordero> how can you solve it?
[21:51] <dcordero> the are a merge protocol or something?
[21:51] <slangasek> dcordero: I think one of your version numbers is missing something
[21:52] <isforinsects> Hrrm, let me find out *why* he's requiring it.
[21:52] <slangasek> do you mean 1.0-0ubuntu8? 1.0-1ubuntu8? 1.0-5ubuntu8?
[21:52] <desertc> slicer: So, if I understand this correctly, one change required in the packaging on the VOIP protocol needs to have the Mumble description changed from using the word 'Proprietary' to 'Non-Standard'.
[21:53] <ScottK2> desertc: Yes, although personally, I'm still in the air about the library duplication.
[21:53] <ScottK2> Others may feel differently.
[21:53] <desertc> slicer and slangasek : Do you feel the issue of the TLS is resolved?
[21:54] <sistpoty> hm... maybe we should take a look at the security history of the duplicated lib
[21:54] <slangasek> desertc: well, I don't feel it's /resolved/ on my end, but I don't have time to get into a long discussion about why the statement "we don't need any retransmission" is either incorrect or a big warning bell, and I don't think the crypto would necessarily be a blocker for letting it into the archive
[21:55] <desertc> slicer: So, indeed, the library duplication remains a stumbling block here.  Sounds like slangasek is not convinced the TLS protocol needs to be duplicated, either.
[21:55] <slicer> desertc: But I'm not duplicating TLS.
[21:56] <slicer> desertc: It's an entirely different protocol.
[21:56] <slangasek> well, I'm not asking that the protocol be changed as a condition of including it in Ubuntu ;)
[21:57] <slicer> sistpoty: As far as I know, there hasn't been any vulnerabilities reported in speex.
[21:57] <desertc> isforinsects: Do you have any insight into the issue from what you've read so far?
[21:57] <dcordero> i mean for example a program named dcordero-1.0. Named dcordero-1.0-8 in debian and dcordero-1.0-3ubuntu4 in ubuntu. In the same case
[21:57] <desertc> isforinsects: of course, when we talk about duplicated libraries, we are talking about Speex and the different functionalities of different Speex versions
[21:57] <sistpoty> slicer: (haven't followed closely)... so mumble duplicates libspeex, right?
[21:58] <isforinsects> 1.2beta2 seems to be universally preferred over the 'stable' release.  It's quality issue more than a vulnerability issue.
[21:58] <slangasek> dcordero: thanks, that makes it clearer.  Yes, generally we handle those by way of merging
[21:58] <vemon> is there an easy way to clean up the debian/ dir after running dpkg-buildpackage? there seems to be some new (probably temp) files after the build but i can't tell for sure what they are
[21:58] <Coper> rexbron: I check dh_install and create a console-freecell.install file in debian/ and put usr/games in it but that didn't work.
[21:58] <slicer> sistpoty: It includes a slightly changed version.
[21:58] <sistpoty> vemon: there shouldn't be (maybe a missing dh_clean call?)
[21:59] <slicer> somerville32: Or, to be exact, it exports a lot more functions and data structures than the original library does.
[21:59] <slicer> somerville32 sistpoty: Er, tab-expansion bug.
[22:00] <vemon> sistpoty, ok well it can be a result of an unclean build then. the source doesn't build yet so maybe dh_clean doesn't get to run properly
[22:01] <Toadstool> good evening everybody!
[22:01] <sistpoty> vemon: then you can of course just call dh_clean in the top src directory
[22:01] <sistpoty> hey Toadstool
[22:01] <Toadstool> hi sistpoty
[22:01] <sistpoty> slicer: to a quick search, I've found no CVE's, so I wouldn't say it's an absolute blocker, but it'd be much better to not have duplicated code in the archives though
[22:01] <vemon> sistpoty, thanks! it worked :)
[22:02] <blueyed> http://xkcd.com/378/
[22:04] <Coper> ahh my ears... the are using singstar and singing Basshunter - Boten Anna.
[22:05] <slicer> sistpoty: Well, if you update the libspeex and libspeexdsp (which is new) in Hardy to 1.2b3, and I make my package use that, it would break horribly when you update to 1.2 final.
[22:05] <rexbron> Coper: link to the package?
[22:05] <slicer> sistpoty: As 1.2.0 will have API incompabilities with 1.2b3.
[22:06] <Coper> http://revu.ubuntuwire.com/details.py?package=console-freecell
[22:07] <sistpoty> slicer: well... I just wanted to write that it were an absolute blocker for inclusion if libspeex did have a track of vulnerabilities so far. It's not nice to not use the one from the archive, but there may be reasons to do so, which will hopefully get resolved sometime ;)
[22:09] <slicer> Well, that would be the absolute authority on all things speex :)
[22:09] <desertc> I invited Jean-Marc to the discussion, jmspeex , who is the lead developer of Speex.  He is curious why the latest version is not the desirable solution here.
[22:11] <jmspeex> hi
[22:11] <slicer> jmspeex: Hi :)
[22:11] <slangasek> slicer: and any updates to a new, ABI/API-incompatible version of libspeex should be accompanied by some sort of transition plan, as we would have to work out already to move from 1.1.12 to 1.2~beta3...
[22:11] <jmspeex> Any reasons Ubuntu wouldn't ship 1.2beta3 instead of 1.1.12?
[22:12] <slangasek> jmspeex: I'm not sure anyone here has the expertise to answer that question, honestly.  The version currently in hardy comes unmodified from Debian, where it's maintained by the Debian VoIP team
[22:12] <jmspeex> slangasek: The codec part of the API has not changed since 1.0 (except for stuff that got added)
[22:12] <slicer> jmspeex: It breaks API compatibility with anything using the libspeexdsp functions.
[22:13] <jmspeex> The new features in the unstable branch have had minor changes to the API, including the library split.
[22:13] <jmspeex> slicer: big deal, it's just a matter of adding a library. Not many packages use that.
[22:14] <slicer> jmspeex: Mine does, and it uses the 1.2b3 (or rather, svn) ones. Which is the source of this discussion.
[22:14] <jmspeex> slicer: what features are you using?
[22:14] <slicer> jmspeex: Preprocessor (AGC, noise filtering), AEC.
[22:15] <slicer> jmspeex: And the jitter buffer..
[22:15] <slicer> jmspeex: And the resampler.
[22:15] <slicer> jmspeex: Hm. All of them, I think.
[22:15] <jmspeex> hmm, all those were OK in beta2 except for the resampler, which was badly broken (and didn't exist at all in beta1)
[22:15] <slangasek> jmspeex: are you in communication with any of the Debian folks maintaining that package currently?
[22:15] <vemon> are patches in debian/patches dir only meant to be source code patches or is it ok to patch anything outside the debian directory using those patches?
[22:16] <jmspeex> slangasek: I've had a few exchanges with the VoIP team about 1.2beta3
[22:17] <slicer> jmspeex: I also peek directly at SpeexEchoState and SpeexPreprocessorState to visualize the noise floor and current echo path; which means I've exposed those as well from libspeex.
[22:17] <sistpoty> vemon: it's ok to patch anything oustide of debian as long as you don't also add a patch system with patches in debian/patches
[22:17] <sistpoty> vemon: as in either use a patch system, or don't, but don't mix these ;)
[22:17] <slangasek> jmspeex: and, did they say they have any plans to update soon?  It's always nice when we can avoid having to do double-duty on packages
[22:17] <jmspeex> slicer: You mean you break the abstraction of those? That's bad! Really bad!
[22:18] <slicer> jmspeex: .. which is one of the many reasons I bundle a complete library.
[22:19] <slicer> jmspeex: Or rather, "a floating-point subset" version of it.
[22:19] <vemon> sistpoty, patching without a patch system means just modifying the files and building the source package?
[22:19] <sistpoty> vemon: right
[22:19] <vemon> actually i didn't even know that was possible :)
[22:20] <jmspeex> They were fine with upgrading, though they haven't done so yet
[22:20] <sistpoty> vemon: then everything you modified (incording the added debian-dir) will end up in .diff.gz
[22:20] <jmspeex> The only issue that was left to resolve was what to do with the development packages that share one of the includes. But it was a minor point anyway.
[22:20] <slicer> jmspeex: Without peeking, there is no way to get st->noise[] and st->ps[], meaning I'd have to duplicate the entire code.
[22:20] <vemon> sistpoty, ah.. a moment of enlightenment :D
[22:20] <jmspeex> slicer: define "a floating point subset"
[22:21] <jmspeex> slicer: why do you need st->noise and st->ps directly?
[22:21] <slicer> jmspeex: I only included the files I actually use for compilation + the COPYING etc.
[22:22] <slicer> jmspeex: To visualize the preprocessor. It's very helpfull when people are wondering what's up with their audio; if they have a high noise around the 50hz area, it's time to get a grounded power supply.
[22:23] <slicer> jmspeex: And similarily for the echo, my end users love the ability to see the echo paths. One of them found that closing the door really helped his echo, something which would not be possible by simple trial and error.
[22:25] <jmspeex> slicer: there *may* be a way to export those cleanly through the ctl() interface. The reason it's bad to peek is that I keep changing the content of that struct (and that's why I made it opaque to the user).
[22:26] <jmspeex> slangasek: I really suggest moving to 1.2beta3. It's not wasted effort because 1.2-final will be quite similar.
[22:26] <slicer> jmspeex: I know. I have a script which syncs my speex-svn with my own header, and presents both as unified diffs just to be damn sure.
[22:26] <slicer> jmspeex: No more API changes? (re: the TODO file which says "For 1.2: Stabilise all APIs")
[22:28] <jmspeex> slicer: No more library split, but I might make some minor changes to the API, mostly on the AEC side (speex_echo_capture and speex_echo_playback)
[22:28] <slicer> jmspeex: BTW, thanks for an excellent library!
[22:28] <jmspeex> codec API is frozen, I don't expect to change the resampler API, jitter buffer *might* change, but not that likely.
[22:28] <slicer> .. again?
[22:29] <slicer> Ah well, I'll live :)
[22:29] <jmspeex> were the last changes that bad?
[22:29] <slicer> No, they were good, but they broke my code :)
[22:29] <jmspeex> Is the new jitter buffer working better?
[22:29] <jmspeex> It's been nearly completely rewritten
[22:29] <slicer> But, "better libspeex" is more important than "my discomfort".
[22:30] <slicer> jmspeex: I've done some really compelling tests with 20% packet loss and +/- 40ms latency.
[22:30] <slicer> jmspeex: That test-feature wasn't there while the old buffer code was there though.
[22:30] <jmspeex> you mean +/- 40 ms jitter?
[22:30] <slicer> jmspeex: It *does* seem to handle DTX much, much better.
[22:30] <slicer> jmspeex: Yes :)
[22:31] <jmspeex> Cool. I'm always interested in that kind of data.
[22:31] <ScottK2> slangasek: libdb4.5-ruby would have the same threading problem in transactions, so I guess I'll just work on fixing 4.6
[22:31] <slicer> jmspeex: I have a "server network simulator", where you can basically set the packet loss and latency range :)
[22:31] <jmspeex> The only thing it's still missing compared to the old jitter buffer is the early detection of condition changes
[22:32] <slicer> jmspeex: I cut transmissions hard when there's end-of-voice, and the old one had some problems coping when transmissions continued several seconds later.
[22:33] <jmspeex> yeah, it's tough to do both re-syncing and preventing junk packets to corrupt your state
[22:34] <jmspeex> what's your project again?
[22:34] <slicer> jmspeex: Speaking of which, is there some way to tell it that "I know this isn't junk"? All the packets are encrypted and hashed, so they're guaranteed to be intact.
[22:34] <slicer> jmspeex: Mumble :)
[22:34] <jmspeex> slicer: why would you want to tell it that? Does it do anything silly.
[22:35] <jmspeex> BTW, "junk" also includes horribly delayed packets and bugs on the sender side
[22:36] <yamal> MOTUs, http://revu.tauware.de/details.py?package=sabnzbdplus is in need of reviewing; package should be in pretty good shape - thanks
[22:37] <slicer> jmspeex: It doesn't do anything silly that I've detected :)
[22:38] <slicer> jmspeex: I.. er.. you're not going to like this. I actually also use it for the AGC on Linux. Since "buffer is full" notification is asynchronous, I can't guarantee I'll be able to read the speaker-input at the same time as mic-input. But stuffing speaker-input in a jitter buffer and fetching it when doing cancellation in mic-input works really, really well.
[22:38] <slicer> jmspeex: And when I say AGC, I mean AEC.
[22:40] <dcordero> i have a dude with a bug. Bug #84589
[22:40] <ubotu> Launchpad bug 84589 in feisty-gdm-themes "[needs-packaging] High contrast GDM theme" [Wishlist,In progress] https://launchpad.net/bugs/84589
[22:40] <RainCT> good night :)
[22:40] <slicer> RainCT: Good night.
[22:41] <ScottK2> dcordero: Is there a question?
[22:41] <dcordero> I dont know if it's good thing add this themes to feisty-gdm-themes. I think that i am nobody for include a theme in the default themes
[22:41] <persia> dcordero: According to rmadison, feisty-gdm-themes is in the repo.  That bug looks like it needs someone to review the changes from the branch, and prepare a debdiff.
[22:41] <ScottK2> Although I suspect feisty-... isn't where we'd want it.
[22:42] <slicer> Anyway, back to "getting Mumble into Hardy". To avoid shipping our own version of speex, we'd need for libspeexdsp to add ctl()s for the data we need (I can write a patch), we'd need a source release of speex with this functionality, that release to be packaged into debian/ubuntu and a new version of Mumble uploaded to REVU. I consider it "somewhat unlikely" that this will happen in the next 14 days.
[22:43] <persia> dcordero: Once the work is done, you would submit the patch, but you might want to check the ubuntu-gdm-themes package or the gdm-themes package first.  Might be best to just drop feisty-gdm-themes, as it is not required for either of the supported upgrade paths to hardy.
[22:43] <dcordero> but feisty-gdm-themes if for default themes :/ I think that this new themes should be included in a new package
[22:43] <persia> dcordero: No.  ubuntu-gdm-themes is the default themes.
[22:43] <slicer> jmspeex: Oh, yes, I belive I've requested this before, but could you pretty please add a '#define SPEEX_VERSION 0x020000' or something similar to the headers? At the moment it's impossible to detect at compile time which version of the APIs to use.
[22:44] <ScottK2> slicer: If that was going to happen in a certain timeline, we could add the package with the bundled lib and then unbundle it when the time comes.
[22:44] <dcordero> W: Unable to locate package ubuntu-gdm-themes
[22:45] <crimsun> it's only in hardy.
[22:45] <slicer> ScottK2: I have no narcisstic need to bundle my own version, so if the Ubuntu-shipped one suddenly has all the functionality I need, it would be just silly of me to bundle it :)
[22:45] <dcordero> i see
[22:47] <ScottK2> slicer: Sure.  I'm just saying that if you and jmspeex could agree to get this done, we could proceed on reviewing your package on the assumption that it'll happen.
[22:48] <dcordero> but the people here use hardy? :)
[22:48] <ScottK2> Some do, some don't.
[22:48] <persia> dcordero: Some people use hardy (some use Dapper).  Most have at least a hardy chroot for testing.
[22:48] <dcordero> i am all the time in package.ubuntu.com checking hardy package, all the time, allll
[22:48] <persia> dcordero: rmadison will be your new best freind
[22:48] <LaserJock> package.ubuntu.com isn't the best place for hardy
[22:49] <LaserJock> it can be decently out of date at times for the development release
[22:49]  * ScottK2 needs to go play Daddy for several hours.  See you all later.
[22:49] <LaserJock> rmadison is very nice
[22:49] <slicer> ScottK2: But would acceptance into Hardy be blocked until the unbundling was done?
[22:49] <LaserJock> ScottK2: good luck with that :-)
[22:49] <nxvl_work> persia: congratulations! finally found you :P
[22:49] <slicer> ScottK2: Enjoy ;)
[22:50] <ScottK2> slicer: I'd say no.  I'd say an agreement to work it out would likely be adequate, but I certainly am not the final word.
[22:50] <dcordero> :/ i'll search about rmadison
[22:50] <persia> dcordero: Try running @rmadison ubuntu-gdm-themes` at a shell prompt.
[22:50] <persia> s/@/`/ (me wants mind-controlled shift keys)
[22:51] <dcordero> nothing
[22:51] <dcordero> dont tell me anything
[22:51] <dcordero> :/
[22:52] <dcordero> dcordero@vaio:~$ rmadison ubuntu-gdm-themes
[22:52] <dcordero> dcordero@vaio:~$
[22:53] <LaserJock> dcordero: you might need to install devscripts
[22:53] <persia> Odd.  It ought report something.  Try `rmadison -u ubuntu ubuntu-gdm-themes`.
[22:53] <slicer> jmspeex: Does adding the necarry ctls seem acceptable to you? I can write a patch and have it sent to speex-dev by tomorrow afternoon.
[22:53] <StevenK> If it's Gutsy, you need -u ubuntu
[22:53] <persia> LaserJock: Wouldn't that generate a command-not-found error though?
[22:54] <StevenK> In Gutsy, it defaults to Debian
[22:54] <LaserJock> persia: well, depends on his version
[22:54] <dcordero> ok -u was the problem ;)
[22:54] <persia> StevenK: Right.  Thanks.
[22:54] <LaserJock> StevenK: really? I thought it worked fine for me. Maybe I was looking up a bunch of debian stuff
[22:54] <dcordero> -u ubuntu -s hardy interesting utility
[22:55] <StevenK> LaserJock: It will list Debian stuff by default in Gutsy.
[22:55] <StevenK> LaserJock: ubuntu-gdm-themes isn't in Debian, for obvious reasons.
[22:58] <desertc> slicer: jmspeex is connecting from work, so he may have been pulled away for a moment.
[23:02] <Coper> hmm when I try to change bin dir from /usr/bin to /usr/games it result to /usr/games/bin
[23:05] <jmspeex> desertc: no, I'm from home and handling two kids...
[23:06] <desertc> jmspeex: That sounds like work to me!  ;)
[23:06] <jmspeex> slicer: Can you make the ctl() call expose something more useful and less algo-specific
[23:07] <jmspeex> desertc: haha
[23:08] <desertc> Just FYI, no one has touched the Debian package of "speex" since Dec 27, 2006... (hey, my birthday!)
[23:08] <slicer> jmspeex: I was thinking of adding SPEEX_PREPROCESS_GET_POWER, _GET_NOISE(_FLOOR?), _GET_SNR. The first two would SPEEX_COPY the relevant data.
[23:09] <persia> Coper: Pastebin the makefile?
[23:10] <desertc> slicer: Is it your opinion that a newer version of speex will need to be included with Ubuntu for the Mumble package?
[23:11] <LaserJock> goobsoft: if you've got questions about MOTU feel free to ask
[23:12] <slicer> jmspeex: For the echo, .. hmm. SPEEX_ECHO_GET_MODULUS, which does a sqrt(real*real+imag*imag) of st->W[]. I'd also need a SPEEX_ECHO_GET_WINDOW_SIZE.
[23:13] <slicer> jmspeex: I currently have visualizations for the phase of st->W as well, but users are just confused by it so I can remove that.
[23:14] <goobsoft> Ok, I will once I've made another stab at my package for my ppa
[23:15] <slicer> desertc: For the unbundling, we'd need a newer-than-currently-exists version in Ubuntu. As long as it can stay embedded it's not an issue.
[23:15] <jmspeex> slicer: keep in mind that 1) the length of the spectra is implementation-dependent and 2)the data needs to be in int32
[23:18] <slicer> jmspeex: Er, I thought it was pretty fixed in libspeexdsp?
[23:19] <jmspeex> slicer: that what was fixed?
[23:19] <slicer> jmspeex: The sizes of st->W (echo) and st->ps/echo for preprocessor?
[23:19] <tzafrir_home> hi
[23:20] <slicer> jmspeex: Anyway, that can be addressed by adding suitable _GET_SIZE calls.
[23:20] <jmspeex> no, they at least depend on the frame size, but also on implementation details
[23:20] <Coper> Do anyone know how to move /usr/bin/package to /usr/games/package ?
[23:21] <desertc> I invited tzafrir_home to the discussion, he is a maintainer of the Debian VOIP packages which includes Speex
[23:21] <sistpoty> Coper: either patch the upstream build system or do a mv in debian/rules
[23:21] <tzafrir_home> I'm one of the maintainers in the pkg-voip team
[23:21] <slicer> jmspeex: Frame size I knew; but I thought beyond that it was fixed in the current implementation. Ok, a proper _GET_SIZE it is then.
[23:21] <desertc> tzafrir_home: you were saying we might consider the experimental version ?
[23:22] <tzafrir_home> Generally there's a version of speex in experimental that uses 1.2
[23:22] <jmspeex> tzafrir_home: what do you call 1.2?
[23:22] <ScottK2> It might be reasonable to provide a new speex1.2 package.
[23:23] <jmspeex> (note that 1.2beta1 is just 1.1.13)
[23:23] <tzafrir_home> speex v. 1.2
[23:23] <jmspeex> ScottK: no, it's the same lib
[23:23] <jmspeex> tzafrir_home: then 1.1.x should have been labeled that way
[23:24] <tzafrir_home> It's 1.2  beta, not 1.1, IIRC
[23:24] <jmspeex> norging special happened between 1.1.12 ans 1.2beta1
[23:24] <ScottK2> jmspeex: Understand, but if there are API differences and we can't migrate all the packages, then some will still need the current speex.
[23:24] <ScottK2> OK
[23:24] <tzafrir_home> checking list archives...
[23:24] <ScottK2> So we've already crossed the rubicon.
[23:24] <desertc> fyi: http://packages.debian.org/unstable/sound/speex
[23:24] <jmspeex> I'm using the Linux naming, so 1.1.x was just the devel branch for 1.2
[23:25] <desertc> and: http://packages.debian.org/experimental/speex
[23:25] <jmspeex> and 1.2 is fully compatible with 1.0
[23:26] <goobsoft> Does launchpad PPA support building and hosting packages for debian?
[23:26] <goobsoft> Or is it limited to ubuntu?
[23:26] <tzafrir_home> The unstable package is 1.1 . The 1.2beta package is in experimental
[23:27] <jmspeex> the split in library only affects apps that were using *unstable* features in 1.1.x, not 1.0
[23:27] <Coper> when I make mv on the file in usr/bin I get a warning in lintian that packare-contains-empty-directory usr/bin/
[23:27] <ScottK2> The 1.2 package has a soname bump so at the very least packages will have to be rebuilt.
[23:27] <jmspeex> really, there's no reason to keep two versions at all
[23:28] <ScottK2> Coper: remove the dir then.
[23:28] <ScottK2> OK.
[23:29] <tzafrir_home> I see that SONAME was bumped - libspeex2 vs. libspeex1
[23:30] <jmspeex> no, this is *not* libspeex2!!!
[23:30] <tzafrir_home> The last thread about it was a few monthes ago:
[23:30] <ScottK2> jmspeex: That's Debian library numbering
[23:30] <jmspeex> basically, I added to the API, but never removed anything compared to 1.0.x
[23:31] <jmspeex> 1.2 is a drop-in replacement for 1.0
[23:31] <ScottK2> jmspeex: Next time the soname gets bumped it'll be libspeex3.  Independent of the upstream version number
[23:31] <jmspeex> the soname bump was an error
[23:31] <tzafrir_home> http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2007-October/thread.html#9796
[23:32] <tzafrir_home> but there is an ABI change vs. 1.1
[23:32] <jmspeex> tzafrir_home: 1.1 was a development version!
[23:33] <tzafrir_home> ubuntu has shipped 1.1.2 for quite some time, so it is 1.1.2 vs. the new beta
[23:33] <tzafrir_home> jmspeex, this is the current version in ubuntu
[23:34] <tzafrir_home> From what I recall, when we asked Jean-Marc Valin at around 2005 what version should be used, he recommended 1.1.2
[23:34] <jmspeex> if you had to bump the soname every time I broke the ABI/API in 1.1, it would be libspeex15
[23:34] <jmspeex> tzafrir_home: I *am* Jean-Marc Valin
[23:34] <tzafrir_home> oops
[23:34]  * slangasek grins
[23:35] <slangasek> in that case, since speex 1.1.2 is packaged, the package name needs to be changed from libspeex1 even if the soname is not
[23:35] <slangasek> (packaged, and shipped in various releases)
[23:35] <tzafrir_home> I now see that even Debian Sarge got an 1.1.x package
[23:36] <jmspeex> slangasek: debian broke the libspeex API for every 1.1.x version it shipped.
[23:36] <tzafrir_home> 1.1.12, not 1.1.2 .
[23:36] <jmspeex> But then again that's only for *experimental* features that weren't in 1.0.x
[23:36] <LaserJock> goobsoft: ubuntu only at this time
[23:36] <jmspeex> If you look at the codec API (libspeex), it's still the same and never got changed.
[23:36] <tzafrir_home> IIRC there were also some useful bug fixes and such
[23:36] <jmspeex> The only sane thing to do is call this libspeex1
[23:37] <slangasek> jmspeex: uhm, experimental or not, if it breaks the library ABI, we have a duty as distributors to not break packages that are in the wild using those ABIs
[23:37] <jmspeex> All the apps using the 1.1.x experimental stuff were using their own copy anyway because of API changes
[23:37]  * slicer whistles innocently.
[23:38] <jmspeex> slangasek: how many times do you think gtk broke their API in the development that led to (e.g.) 2.0?
[23:38] <slangasek> jmspeex: that's irrelevant to my point
[23:38] <slangasek> which is, that Debian and Ubuntu have shipped libspeex1 with a particular ABI
[23:38] <goobsoft> thanks, I'm reading through the ubuntu packaging documentation and the debian packaging documentation and I'm trying to figure out what the algorithm is to determine if a version is more recent than another.  Since there are characters in the version like "ubuntu0" it can't be strictly numeric, but it doesn't make sense to me that it be strictly string based either.  Can anyone point me in the right direction?
[23:38] <slangasek> so even if the soname remains the same upstream, we should still change the package name
[23:38] <jmspeex> 1.1.x was worth tracking instead of 1.0.x because the codec was better (with the same API). I always made it clear that the experiemntal stuff could not be relied on.
[23:39] <jmspeex> Then you should call it libspeex9 (or libspeex15) to reflect the fact that the API got broken more than just once.
[23:39] <jmspeex> bbl
[23:40] <tzafrir_home> jmspeex, not every app with a private speex copy managed to keep it when packaged in Debian
[23:40] <slangasek> jmspeex: um, that's argumentum ad absurdum.  The reason we care is because *libspeex1 is a released package in the wild*.  That's the only thing we need to avoid incorrectly claiming compatibility with, not every other version of the ABI ever
[23:41] <sistpoty> goobsoft: debian package version is comprised of upstream version and debian version (e.g. 1.0-1).. the debian version is after the -
[23:41] <slangasek> goobsoft: I believe it's documented in Debian policy. dpkg --compare-versions also lets you test out particular comparisons to help your understanding
[23:41] <sistpoty> goobsoft: if ubuntu modifies that very package, and ubuntu1 is added to the version
[23:42] <slangasek> jmspeex: the natural package rename here, if you aren't planning to bump the soname upstream, would be to 'libspeex1debian1' or the like
[23:42] <sistpoty> goobsoft: and the last number is increased for every new version ubuntu ships as long as debian doesn't ship a new version
[23:42] <sistpoty> goobsoft: if debian ships a new version, that would be 1.0-2 (and then ubuntu could modify it as 1.0-2ubuntu1, 1.0-2ubuntu2 etc. again)
[23:43] <sistpoty> slangasek: with bumping the soname locally for debian, or just renaming the binary package?
[23:43] <goobsoft> ok, If I'm making a ubuntu package for software that has no debian equiv, should I bother with the "ubuntu1" part?
[23:43] <slangasek> sistpoty: just renaming the binary package
[23:43] <ScottK> goobsoft: Then it's -0ubuntu1
[23:44] <goobsoft> ah ok
[23:44] <sistpoty> goobsoft: then (because debian might package it some day), you'd start with -0ubuntu1 (which would always be lower then the initial debian versoin -1)
[23:44] <sistpoty> slangasek: ah, thanks
[23:44] <slangasek> sistpoty: bumping the soname locally would mean being incompatible with upstream's soname for the remaining life of libspeex.so.1, which is often a greater evil
[23:44] <vemon> i just updated a package to new upstream version. what files should i attach to the launchpad bug requesting the update?
[23:44] <Coper> Can someone review my new package http://revu.ubuntuwire.com/details.py?package=console-freecell
[23:44] <goobsoft> that makes sense
[23:44] <ScottK> slangasek: Looks like Debian already bumped it in Experimental.
[23:44] <vemon> i've seen debdiffs used there but are they only for ubuntu revision changes and not upstream version changes?
[23:45] <sistpoty> slangasek: yes, this was one of the things I wasn't too sure at the library packaging sessoin (part 2) ;)
[23:45] <ScottK> vemon: For a new upstream attach the .diff.gz for your new package.
[23:45] <sistpoty> heh
[23:45] <slangasek> ScottK: mm, doh
[23:45] <slangasek> tzafrir_home: well, per the above I think it's a bad idea to name a package "libspeex2" if upstream hasn't bumped their soname to libspeex.so.2
[23:46] <vemon> ScottK, isn't the .orig.tar.gz also needed?
[23:46] <slangasek> tzafrir_home: I'd advise that you treat the libspeex<k> namespace as reserved for upstream use, and if you can't come to an agreement that the soname should be bumped upstream for the 1.2 release, to use a name such as libspeex1debian1 instead
[23:47] <sistpoty> vemon: no... either you provide a watch file, or a get-orig-source rule, or the sponsor will grab it via the address listed in debian/copyright
[23:47] <desertc> tzafrir_home slicer: But getting back to the Mumble functionality... If I am understanding this correctly, Mumble and Ubuntu can use the Debian Experimental Speex package as a dependency, in order to get the 1.2 Speex library functionality.  Is this about correct?
[23:48] <slicer> desertc: I still need the additional data, which currently is not exposed.
[23:48] <vemon> sistpoty, ok. luckily i started the update by creating the watch file :)
[23:49] <sistpoty> slicer: btw.: I just advocated the package, as I believe that the library issue will either get fixed in time for hardy, or you'll take care for the local copy (in case there would be problems with it)
[23:50] <desertc> slicer: other than that data you need exposed for echo cancelation, would you expect the Debian Experimental Speex to handle the functions in Mumble?
[23:50] <slicer> desertc: Yes.
[23:50] <desertc> So it really comes down to that one function that can be improved later, just want to make sure there's not anything else you expect will be problematic.
[23:50] <slicer> sistpoty: Thanks :)
[23:51] <sistpoty> slicer: thanks for your great application :)
[23:53] <tzafrir_home> jmspeex, have you any idea when the final 1.2 is expected?
[23:54] <desertc> unfortunately, jmspeex did a "be back later" -- hopefully he is back soon
[23:55] <slangasek> tzafrir_home: note that from the standpoint of the Ubuntu release cycle, having 1.2~beta in would be beneficial, as we're at feature freeze for hardy in 2 weeks
[23:56] <slangasek> and all testimony indicates that 1.2~beta is an improvement over 1.1.2
[23:57] <tzafrir_home> This is what I also read
[23:57] <tzafrir_home> I wonder if breaking it to libspeex and libspeexdsp would reduce the problem
[23:57]  * sistpoty is off to bed now
[23:57] <tzafrir_home> The core libspeex is very unlikely to change till the final version
[23:57] <sistpoty> gn8 everyone
[23:58] <slangasek> tzafrir_home: that would help some to split the packages, yes
[23:58] <vemon> ok. i uploaded the diff. anyone care to take a look at new version of jack-rack?: https://bugs.launchpad.net/ubuntu/+source/jack-rack/+bug/187190
[23:58] <ubotu> Launchpad bug 187190 in jack-rack "[update] jack-rack" [Undecided,In progress]
[23:59] <isforinsects> Much of this conversation is well above my knowledge of speex.  But if it's any consolation I'm having plenty of issues getting speex into the OLPC distro's.  And getting MIME types etc.