[00:25] <almoxarife> I debified the current irssi, I was told to ask here if that is something that can be turned in
[00:26] <maxb> almoxarife: current irsii is already in lucid
[00:26] <maxb> (so no, there's nothing to do)
[00:27] <almoxarife> maxb: that's ver 14, I am talking about 15
[00:28] <maxb> huh, #irssi says it's not released yet
[00:28] <maxb> http://irssi.org/ agrees
[00:28] <maxb> almoxarife: Please try to state complete version numbers, it's confusing otherwise
[00:29] <almoxarife> leIrssi 0.8.15-rc1 released <-- that is what I am talking about
[00:30] <maxb> It's a release candidate version
[00:31] <maxb> gah
[00:32] <maxb> annoying parters
[00:32]  * ajmitch guesses that answer was not welcome
[01:14] <cnd_mini> I took a look at why the diagnostics package was failing to build, and it appears to need an updated version of libace-dev that's available in debian
[01:14] <cnd_mini> do I file a sync request for this?
[03:02] <nigelb> I'm trying to run pitivi inside chroot and I get this error http://paste.ubuntu.com/406640/ Any clues as to how to run the package in chroot and test it?
[04:49] <ScottK> cnd_mini: Yes.
[08:02] <dholbach> good morning
[08:11] <ara> morning dholbach
[08:14] <dholbach> hola ara! :)
[08:14] <\sh> hey dholbach
[08:14] <dholbach> hey \sh
[08:15] <dholbach> ¿como estas? how are you guys doing?
[08:15] <\sh> tweaking acire to use desktopcouch for snippets + adding snippets dialogs + trying to setup a couchdb on rooty for syncing acire snippets to the world ;)
[08:17] <\sh> in summary: trying to make jono even more happy then he already is ;)
[08:39] <tick-tock> hi all
[08:41] <tick-tock> I'm trying to update a package (following this guide https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate )
[08:42] <tick-tock> and have had a bunch of errors like this:
[08:42] <tick-tock> dpkg-source: warning: ignoring deletion of file ...
[08:42] <tick-tock> something to worry about? what does it mean?
[08:49] <geser> that some files got deleted (presumely on purpose) and that this can't be reflected in the .diff.gz
[09:01] <tick-tock> okay thanks.
[09:02] <tick-tock> just updated from my ppa and the package built and works fine, so I guess it's all good
[10:12] <dutchie> https://code.edge.launchpad.net/~jshholland/ubuntu/lucid/poppler/backport-anti-alias/+merge/22511 # do I really need to update Makefile.in as well? it builds fine for me...
[11:33] <Daviey> dutchie: your branch failed to build for me, at least
[11:33] <dutchie> Daviey: seb128 said he'd take care of the automake stuff
[11:38] <Daviey> dutchie: ok, cool.
[12:04] <pmcenery> Hello, is anyone working on bug #504224?
[12:21] <AnAnt> Hello, could someone sponsor http://revu.ubuntuwire.com/p/plymouth-theme-sabily, it already has been advocated by one person, and also granted FFe in LP #543679
[12:48] <asac> hey
[12:48] <asac> why is quake3 not in archive anymore?
[12:51] <sebner> asac: hrhr, quake3-data seems still present. I guess it got superseeded by openarena?!
[12:55] <siretart> asac: you mean, ioquake3?
[12:56] <siretart> sebner: I believe the quake3-data was a helping package for downloading the q3 point release from idsoftware.com and prepare things so that you can use the models from your quake3 cd
[12:57] <sebner> siretart: seems so :)
[12:57] <siretart> asac: any news on the libjs.so mess?
[13:03] <asac> siretart: mozjs?
[13:04] <asac> no. consider it non existent
[13:04] <siretart> asac: you mean I'm imagining #542506?
[13:04] <siretart> bug #542506
[13:13] <siretart> asac?
[15:39] <asac> siretart: is there a wrapper script?
[15:39] <asac> sarting gxine?
[15:39] <asac> starting
[15:51] <siretart> asac: there is no wrapper script. /usr/bin/gxine is an executable
[15:52] <siretart> asac: but you still haven't answered my question (see last comment in the bug)
[15:57]  * asac looks in bug
[16:01] <asac> siretart: answered
[16:05] <siretart> asac: so you believe that mozilla breaks API even in libmozjs.so? :-/
[16:05] <siretart> I'll discuss that with darren (gxine upstream)
[16:06] <AnAnt> I had to compile Debian's xulrunner package to get  libmozjs* packages
[16:07] <AnAnt> could someone sponsor http://revu.ubuntuwire.com/p/plymouth-theme-sabily, it already has been advocated by one person, and also granted FFe in LP #543679
[16:08] <asac> siretart: they explicitly said that
[16:08] <siretart> asac: what happened to the xulrunner package in lucid?
[16:08] <asac> siretart: yes, please go upstream and tell them that in the end libmozjs.so is nothing they can use
[16:08] <siretart> can't we build libmozjs from that?
[16:08] <asac> siretart: that was 1.8
[16:08] <asac> and has about 1000 security issues
[16:08] <asac> it was removed (and should have been removed 3 cycles ago)
[16:08] <siretart> and, and therefore it got revmoved?
[16:08] <siretart> hm bad
[16:09] <siretart> well, gxine needs an javascript interpreter
[16:09] <asac> so that it was there was just luck
[16:09] <asac> siretart: yes, its a bad situation
[16:09] <siretart> will the same happen in debian as well?
[16:09] <asac> i think the gnome js is the only one
[16:09] <siretart> what's about 'gnome js'?
[16:09] <asac> siretart: not sure. debian likes to fly without eyes
[16:09] <asac> apparently
[16:10] <AnAnt> gnome js ?
[16:10] <siretart> does gnome ship their own js interpreter?
[16:10] <asac> or mike things he can unbreak ABI/API which imo only two guys could do that are hired by moz
[16:10] <asac> siretart: it hink libseed or something
[16:10] <asac> so seems they use webkit
[16:11] <asac> that probably has other issues
[16:11] <AnAnt> is that SEE ?
[16:11] <asac> because webkit is not security maintainable ;)
[16:11] <siretart> asac: why not?
[16:11] <asac> but i dont care. so yeah. gong there is better than libmozjs that explicitly stated they dont want to
[16:11] <asac> siretart: talk to security team ;)
[16:11] <siretart> asac: I'm asking you
[16:12] <asac> siretart: they dont provide backported patches and its quite intransparent
[16:12] <asac> didnt look on my own. just what heard from security team
[16:12] <siretart> and how is that worse to mozilla?
[16:12] <asac> not worse.
[16:12] <asac> so yeah. go there
[16:13] <asac> in the end someone needs to write a js lib that is stable and slow
[16:13] <asac> (given that its understood that you cannot make a lib that keeps up with the current speed requirements that is fast)
[16:13] <asac> at least both moz and google say that
[16:13] <asac> so yes. i have no solution and it sucks
[16:13] <asac> the only thing i can tell folks is to stop adapting js
[16:13] <asac> use something else
[16:14] <AnAnt> asac: this xulrunner issue is getting on your nerves
[16:14] <asac> but not javascript if you want to ship your software seriously
[16:14] <asac> if you would ask me we should remove everything that uses it
[16:14] <siretart> well, it's pretty sad that gxine is in such a miserable state right now :/
[16:14] <asac> so upstreams finally notice that and complain on their own
[16:14] <asac> siretart: sure. but we fix it and noone will go and complain
[16:14] <asac> if you want to fix it use the LD_LIBRARY_PATH
[16:14] <asac> trick
[16:15] <siretart> asac: you broke, you fix ;-)
[16:15] <asac> thats the only way you can workaround all the walls we built to prevent folks using those libs
[16:15] <asac> i dont want the lib to be used
[16:15] <AnAnt> asac: I did another thing, I used rpath, is that bad ?
[16:15] <asac> AnAnt: yes, that doesnt work
[16:15] <asac> read the gxine bug wherei explained it
[16:15] <AnAnt> asac: it worked for elinks
[16:16] <asac> AnAnt: right. until we do a security update
[16:16] <AnAnt> but LD_LIBRARY_PATH might be a neater solution anyways
[16:16] <asac> then its dead
[16:16] <asac> AnAnt: dont use it
[16:17] <asac> otherwise it will break every other month
[16:17] <AnAnt> asac: yes, you are right
[16:17] <asac> AnAnt: i told you that rpath is not going to work
[16:17] <asac> ;)
[16:17] <asac> why did you still go for it?
[16:17] <asac> anyway in customer meeting
[16:17] <asac> will be back next week from this trip
[16:18] <AnAnt> asac: you did ? I must have left before I read your reply
[16:18] <AnAnt> asac: anyways, I gave up the whole thing, compiled Debian's xulrunner package to get libmozjs* packages, and compiled against those
[16:18] <asac> AnAnt: and then? this thing doesnt run on ubuntu ;)
[16:18] <AnAnt> asac: I find it crazy that elinks would have to depend on libxulrunner and all the libs that it depends on
[16:18] <soren> I have a package that from upstream is versioned as 1.0a5. I've changed that to 1.0~a5 in my package version so that a final 1.0 will supersede it, but uscan doesn't know this so it insists that 1.0a5 is newer. Does anyone have any tricks up their sleeve to work around this?
[16:19] <AnAnt> asac: it does
[16:19] <asac> siretart: i really tried a bunch of stuff and tried to fix the situation. without upstream complaining that they cannot be shipped in distros nothing will change
[16:19] <AnAnt> soren: mangle
[16:19] <AnAnt> opts=dversionmangle=s/~//
[16:20] <soren> AnAnt: Ah, neat. Thanks.
[16:21] <AnAnt> oh, finally I am a DM
[16:24] <siretart> asac: I rather meant the lack of information/coordination with libmozjs users. darren and I were pretty surprised about this move...
[16:25] <mr_pouit> (well, it's probably written in an obscure wiki page)
[16:27] <AnAnt> asac: by compiling Debian's xulrunner (1.9.1) on lucid, it would work
[16:27] <AnAnt> asac: but I can't ship the package on Ubuntu repos of course
[16:50] <ScottK> nixternal: Would you please give http://revu.ubuntuwire.com/p/plymouth-theme-sabily a review.  I'm glad to do the New for it, but really shouldn't if I was part of getting it sponsored.
[16:54] <nixternal> ScottK: looking at it now
[16:54] <ScottK> nixternal: Thanks.
[16:54] <ScottK> AnAnt: ^^^
[16:54] <AnAnt> thanks
[18:07] <asac> oops
[18:07] <asac> siretart: what would you suggest wrt coordination with libmozjs users?
[18:07] <jcastro> hyperair: woo, it's banshee 1.6 day!
[18:08] <asac> siretart: i tried to talk to all those that are currently in main
[18:08] <asac> siretart: feedback i got from those was usually - EDONTCARE because it works ;)
[18:08] <asac> like couchdb folks
[18:08] <asac> they say this problem will be resolved on its own and they dont care
[18:21] <siretart> asac: so couchdb links to libmozjs. so as well? What do they do? use LD_LIBRARY_PATH or rpath?
[18:22] <siretart> I've suggested darren now to ship a private copy of libmozjs
[18:27] <asac> siretart: LD_LIB
[18:27] <asac> couchdb
[18:27] <asac> siretart: if the js is not exposed to any remote content thats ok (e.g. ship your own js/ source tree and spin it)
[18:28] <AnAnt> asac: so you talked with Debian guys about libmozjs* ?
[18:29] <asac> AnAnt: i think i did it once. but not recently. no
[18:29] <asac> i have that on the list to raise with security team etc.
[18:30] <asac> should do that soon
[18:32] <AnAnt> ok
[18:33] <AnAnt> it would be great to reduce the diff between Debian's & Ubuntu's xulrunner package
[18:35] <AnAnt> nixternal: thanks, I added some info to extended description & re-uploaded
[18:36] <AnAnt> nixternal: could you upload now ?
[18:39] <ScottK> nixternal: If you would upload it, I can do the New processing.
[18:45] <nixternal> one sec
[18:46] <mok0> Riddell: I haven't reported a bug.
[18:47] <nixternal> AnAnt: between 'design.' and the next line, you need to add a ' .' to separate the lines
[18:47] <mok0> Riddell: (django on jaunty is totally outdated)
[18:48] <Riddell> mok0: then I have nothing to work on in deciding if I should let it in, I need to see the rationale, the testing and the backports team approval
[18:49] <mok0> Riddell: It works w/o problems for me, I've used it a couple of months
[18:49] <mok0> Riddell: you really want a bug, or can I answer here
[18:50] <ScottK> mok0: Do the bug.  The paper trail is good to have.
[18:50] <mok0> ScottK, oh, those are surprising words coming from you ;-)
[18:50] <ScottK> mok0: Yeah, but we've had problems with backports before, so it's good to be clear.
[18:54] <soren> I've created new package. lintian suggested I use this new-fangled 3.0 (quilt) format, so I did. The tarball from upstream is such that doing the clean makes a few changes to some of the files. In the past I could just happily ignore that and leave that delta in the diff.gz.
[18:54] <soren> ...but now I have to justify it by filling in all those patch tag field things.
[18:55] <soren> ...and I have no clue what to put.
[18:56] <soren> http://www.linux2go.dk/cloudservers/ for the actual stuff.
[18:56] <ScottK> You don't HAVE to.
[18:57] <soren> Well... No. But my trying to weasel out of it is so much more obvious this way :)
[18:59] <geser> soren: just looking at your control file: don't you need X(S|B)-Python-Version? or does it work now without it?
[18:59] <ScottK> If it's a Python package it should have those.
[19:00] <ScottK> There are defaults if they are missing, but better to be explicit.
[19:00] <soren> geser: It complained about them when they were there.
[19:00] <soren> It said that was deprecated.
[19:00] <soren> ...and that I should use pyversions if I wanted a specific version. I don't.
[19:00] <ScottK> soren: They aren't.  It's an odd situation.
[19:01] <ScottK> If you use pyversions it'll complain about that too.
[19:01] <soren> Yes, I noticed.
[19:01] <ScottK> X(S|B)-Python-Version is preferred since it's python helper independent.  pyversions is python support only.
[19:01] <soren> Alright.
[19:01]  * soren adds them back
[19:02] <soren> "/usr/share/cdbs/1/class/python-distutils.mk:68: WARNING:  Use of XS-Python-Version and XB-Python-Version fields in debian/control is deprecated with pysupport method; use debian/pyversions if you need to specify specific versions."
[19:02] <soren> ...is what I get.
[19:03] <soren> Is that wrong?
[19:03] <mok0> Riddell, ScottK: bug 552721
[19:04] <soren> ScottK: ^ Do you know? If it is, do you see any reason why I shouldn't fix cdbs to not warn about this?=
[19:05] <ScottK> soren: I think it's probably not worth additional diff from Debian, but other than that, no.
[19:06] <ScottK> Generally, I'd suggest just skipping CDBS and using DH7.
[19:06] <soren> I have a package that POX reviewed for me (a few months ago). It does not have XS-Python-Version.
[19:06] <soren> ScottK: I happen to like cdbs :)
[19:06] <soren> It does have XB-Python-Version, though.
[19:07] <geser> soren: btw I tried to build your package, it FTBFS: "dpkg-source: error: cannot represent change to python-cloudservers-1.0~a5/distribute-0.6.8-py2.6.egg: binary file contents changed", "dpkg-source: error: add distribute-0.6.8-py2.6.egg in debian/source/include-binaries if you want to store the modified binary in the debian tarball"
[19:08] <soren> geser: Yeah.
[19:09] <Riddell> mok0: accepted (I don't know if there are new binaries in there, if so they'll get stuck in new, feel free to poke me to accept them too)
[19:10] <mok0> Riddell: I didn't fiddle with the packages
[19:10] <mok0> Riddell: (binary packages that is)
[19:10] <mok0> Riddell: thanks
[19:14] <soren> geser: Uh...
[19:14] <merbit> Hello, is anyone willing to take over bug #538773 ? some packages still depend on python-gtkhtml2, which was dropped: http://changelogs.ubuntu.com/changelogs/pool/main/g/gnome-python-extras/gnome-python-extras_2.25.3-4.1ubuntu3/changelog
[19:14] <soren> geser: No, actually, I had /not/ seen that before. When do you see this?
[19:15] <geser> soren: inside my lucid pbuilder
[19:15] <soren> odd.
[19:16] <soren> I can both build binary and source. No problems.
[19:16] <geser> soren: http://paste.ubuntu.com/407188/
[19:16] <soren> (Not tried in a chroot, though)
[19:17] <geser> hmm, "Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.8.tar.gz
[19:17] <soren> Ah, right.
[19:17] <soren> This is still work in progress. I haven't enumerated all the dependencies yet.
[19:18] <soren> (There's a bunch!)
[19:19] <geser> you should at least add python-setuptools to Build-Depends(-Indep)
[19:19] <soren> Sure, sure.
[19:19] <soren> I was just stumped by the patch tagging thing. It's far from done yet.
[19:32] <AnAnt> nixternal: yes thanks, re-uploaded now
[19:35] <nigelb> can someone please sponsor bug 314885 before the beta freeze?
[19:36] <nigelb> oh wait, its in main now
[21:07] <IntuitiveNipple> I'm creating a new package and have questions about which copyrights from the source to include in debian/copyright. Many seem to relate to autotools/m4/libtools and other helper scripts included in the source. The grep result is at http://paste.ubuntu.com/407231/  ...can anyone assist?
[21:14] <sebner> IntuitiveNipple: you can ignore all of the non-source copyright (makefiles etc)
[21:18] <IntuitiveNipple> sebner: How about translations, and I note, the source includes gnulib/ ?
[21:19] <sebner> IntuitiveNipple: only source, *all* source of the tarball
[21:22] <IntuitiveNipple> sebner: OK, so that means include the FSF copyrights to gnulib. Thanks.