[00:25] I debified the current irssi, I was told to ask here if that is something that can be turned in [00:26] almoxarife: current irsii is already in lucid [00:26] (so no, there's nothing to do) [00:27] maxb: that's ver 14, I am talking about 15 [00:28] huh, #irssi says it's not released yet [00:28] http://irssi.org/ agrees [00:28] almoxarife: Please try to state complete version numbers, it's confusing otherwise [00:29] leIrssi 0.8.15-rc1 released <-- that is what I am talking about [00:30] It's a release candidate version [00:31] gah [00:32] annoying parters [00:32] * ajmitch guesses that answer was not welcome [01:14] 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] do I file a sync request for this? [03:02] 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? === rgreening_ is now known as rgreening [04:49] cnd_mini: Yes. [08:02] good morning [08:11] morning dholbach [08:14] hola ara! :) [08:14] <\sh> hey dholbach [08:14] hey \sh [08:15] ¿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] hi all [08:41] I'm trying to update a package (following this guide https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate ) [08:42] and have had a bunch of errors like this: [08:42] dpkg-source: warning: ignoring deletion of file ... [08:42] something to worry about? what does it mean? [08:49] that some files got deleted (presumely on purpose) and that this can't be reflected in the .diff.gz [09:01] okay thanks. [09:02] just updated from my ppa and the package built and works fine, so I guess it's all good [10:12] 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] dutchie: your branch failed to build for me, at least [11:33] Daviey: seb128 said he'd take care of the automake stuff [11:38] dutchie: ok, cool. === traveller_ is now known as traveller [12:04] Hello, is anyone working on bug #504224? [12:04] Launchpad bug 504224 in mountall "NFS mounts at boot time prevent boot or print spurious errors" [Medium,Confirmed] https://launchpad.net/bugs/504224 [12:21] 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:21] Launchpad bug 543679 in ubuntu "Add a plymouth theme for sabily" [Medium,Confirmed] https://launchpad.net/bugs/543679 [12:48] hey [12:48] why is quake3 not in archive anymore? [12:51] asac: hrhr, quake3-data seems still present. I guess it got superseeded by openarena?! [12:55] asac: you mean, ioquake3? [12:56] 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] siretart: seems so :) [12:57] asac: any news on the libjs.so mess? [13:03] siretart: mozjs? [13:04] no. consider it non existent [13:04] asac: you mean I'm imagining #542506? [13:04] bug #542506 [13:04] Launchpad bug 542506 in gxine "gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/542506 === rgreening_ is now known as rgreening [13:13] asac? [15:39] siretart: is there a wrapper script? [15:39] sarting gxine? [15:39] starting [15:51] asac: there is no wrapper script. /usr/bin/gxine is an executable [15:52] asac: but you still haven't answered my question (see last comment in the bug) [15:57] * asac looks in bug [16:01] siretart: answered [16:05] asac: so you believe that mozilla breaks API even in libmozjs.so? :-/ [16:05] I'll discuss that with darren (gxine upstream) [16:06] I had to compile Debian's xulrunner package to get libmozjs* packages [16:07] 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:07] Launchpad bug 543679 in ubuntu "Add a plymouth theme for sabily" [Medium,Confirmed] https://launchpad.net/bugs/543679 [16:08] siretart: they explicitly said that [16:08] asac: what happened to the xulrunner package in lucid? [16:08] siretart: yes, please go upstream and tell them that in the end libmozjs.so is nothing they can use [16:08] can't we build libmozjs from that? [16:08] siretart: that was 1.8 [16:08] and has about 1000 security issues [16:08] it was removed (and should have been removed 3 cycles ago) [16:08] and, and therefore it got revmoved? [16:08] hm bad [16:09] well, gxine needs an javascript interpreter [16:09] so that it was there was just luck [16:09] siretart: yes, its a bad situation [16:09] will the same happen in debian as well? [16:09] i think the gnome js is the only one [16:09] what's about 'gnome js'? [16:09] siretart: not sure. debian likes to fly without eyes [16:09] apparently [16:10] gnome js ? [16:10] does gnome ship their own js interpreter? [16:10] or mike things he can unbreak ABI/API which imo only two guys could do that are hired by moz [16:10] siretart: it hink libseed or something [16:10] so seems they use webkit [16:11] that probably has other issues [16:11] is that SEE ? [16:11] because webkit is not security maintainable ;) [16:11] asac: why not? [16:11] but i dont care. so yeah. gong there is better than libmozjs that explicitly stated they dont want to [16:11] siretart: talk to security team ;) [16:11] asac: I'm asking you [16:12] siretart: they dont provide backported patches and its quite intransparent [16:12] didnt look on my own. just what heard from security team [16:12] and how is that worse to mozilla? [16:12] not worse. [16:12] so yeah. go there [16:13] in the end someone needs to write a js lib that is stable and slow [16:13] (given that its understood that you cannot make a lib that keeps up with the current speed requirements that is fast) [16:13] at least both moz and google say that [16:13] so yes. i have no solution and it sucks [16:13] the only thing i can tell folks is to stop adapting js [16:13] use something else [16:14] asac: this xulrunner issue is getting on your nerves [16:14] but not javascript if you want to ship your software seriously [16:14] if you would ask me we should remove everything that uses it [16:14] well, it's pretty sad that gxine is in such a miserable state right now :/ [16:14] so upstreams finally notice that and complain on their own [16:14] siretart: sure. but we fix it and noone will go and complain [16:14] if you want to fix it use the LD_LIBRARY_PATH [16:14] trick [16:15] asac: you broke, you fix ;-) [16:15] thats the only way you can workaround all the walls we built to prevent folks using those libs [16:15] i dont want the lib to be used [16:15] asac: I did another thing, I used rpath, is that bad ? [16:15] AnAnt: yes, that doesnt work [16:15] read the gxine bug wherei explained it [16:15] asac: it worked for elinks [16:16] AnAnt: right. until we do a security update [16:16] but LD_LIBRARY_PATH might be a neater solution anyways [16:16] then its dead [16:16] AnAnt: dont use it [16:17] otherwise it will break every other month [16:17] asac: yes, you are right [16:17] AnAnt: i told you that rpath is not going to work [16:17] ;) [16:17] why did you still go for it? [16:17] anyway in customer meeting [16:17] will be back next week from this trip [16:18] asac: you did ? I must have left before I read your reply [16:18] asac: anyways, I gave up the whole thing, compiled Debian's xulrunner package to get libmozjs* packages, and compiled against those [16:18] AnAnt: and then? this thing doesnt run on ubuntu ;) [16:18] asac: I find it crazy that elinks would have to depend on libxulrunner and all the libs that it depends on [16:18] 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] asac: it does [16:19] 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] soren: mangle [16:19] opts=dversionmangle=s/~// [16:20] AnAnt: Ah, neat. Thanks. [16:21] oh, finally I am a DM [16:24] asac: I rather meant the lack of information/coordination with libmozjs users. darren and I were pretty surprised about this move... [16:25] (well, it's probably written in an obscure wiki page) [16:27] asac: by compiling Debian's xulrunner (1.9.1) on lucid, it would work [16:27] asac: but I can't ship the package on Ubuntu repos of course [16:50] 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] ScottK: looking at it now [16:54] nixternal: Thanks. [16:54] AnAnt: ^^^ [16:54] thanks === BlackZ_ is now known as BlackZ === yofel_ is now known as yofel [18:07] oops [18:07] siretart: what would you suggest wrt coordination with libmozjs users? [18:07] hyperair: woo, it's banshee 1.6 day! [18:08] siretart: i tried to talk to all those that are currently in main [18:08] siretart: feedback i got from those was usually - EDONTCARE because it works ;) [18:08] like couchdb folks [18:08] they say this problem will be resolved on its own and they dont care [18:21] asac: so couchdb links to libmozjs. so as well? What do they do? use LD_LIBRARY_PATH or rpath? [18:22] I've suggested darren now to ship a private copy of libmozjs [18:27] siretart: LD_LIB [18:27] couchdb [18:27] 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] asac: so you talked with Debian guys about libmozjs* ? [18:29] AnAnt: i think i did it once. but not recently. no [18:29] i have that on the list to raise with security team etc. [18:30] should do that soon [18:32] ok [18:33] it would be great to reduce the diff between Debian's & Ubuntu's xulrunner package [18:35] nixternal: thanks, I added some info to extended description & re-uploaded [18:36] nixternal: could you upload now ? [18:39] nixternal: If you would upload it, I can do the New processing. [18:45] one sec [18:46] Riddell: I haven't reported a bug. [18:47] AnAnt: between 'design.' and the next line, you need to add a ' .' to separate the lines [18:47] Riddell: (django on jaunty is totally outdated) [18:48] 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] Riddell: It works w/o problems for me, I've used it a couple of months [18:49] Riddell: you really want a bug, or can I answer here [18:50] mok0: Do the bug. The paper trail is good to have. [18:50] ScottK, oh, those are surprising words coming from you ;-) [18:50] mok0: Yeah, but we've had problems with backports before, so it's good to be clear. [18:54] 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] ...but now I have to justify it by filling in all those patch tag field things. [18:55] ...and I have no clue what to put. [18:56] http://www.linux2go.dk/cloudservers/ for the actual stuff. [18:56] You don't HAVE to. [18:57] Well... No. But my trying to weasel out of it is so much more obvious this way :) [18:59] 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] If it's a Python package it should have those. [19:00] There are defaults if they are missing, but better to be explicit. [19:00] geser: It complained about them when they were there. [19:00] It said that was deprecated. [19:00] ...and that I should use pyversions if I wanted a specific version. I don't. [19:00] soren: They aren't. It's an odd situation. [19:01] If you use pyversions it'll complain about that too. [19:01] Yes, I noticed. [19:01] X(S|B)-Python-Version is preferred since it's python helper independent. pyversions is python support only. [19:01] Alright. [19:01] * soren adds them back [19:02] "/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] ...is what I get. [19:03] Is that wrong? [19:03] Riddell, ScottK: bug 552721 [19:03] Launchpad bug 552721 in jaunty-backports "Please backport django_1.1.1 from karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/552721 [19:04] 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] soren: I think it's probably not worth additional diff from Debian, but other than that, no. [19:06] Generally, I'd suggest just skipping CDBS and using DH7. [19:06] I have a package that POX reviewed for me (a few months ago). It does not have XS-Python-Version. [19:06] ScottK: I happen to like cdbs :) [19:06] It does have XB-Python-Version, though. [19:07] 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] geser: Yeah. [19:09] 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] Riddell: I didn't fiddle with the packages [19:10] Riddell: (binary packages that is) [19:10] Riddell: thanks [19:14] geser: Uh... [19:14] 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] Launchpad bug 538773 in pida "Please remove python-gtkhtml2 from package dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/538773 [19:14] geser: No, actually, I had /not/ seen that before. When do you see this? [19:15] soren: inside my lucid pbuilder [19:15] odd. [19:16] I can both build binary and source. No problems. [19:16] soren: http://paste.ubuntu.com/407188/ [19:16] (Not tried in a chroot, though) [19:17] hmm, "Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.8.tar.gz [19:17] Ah, right. [19:17] This is still work in progress. I haven't enumerated all the dependencies yet. [19:18] (There's a bunch!) [19:19] you should at least add python-setuptools to Build-Depends(-Indep) [19:19] Sure, sure. [19:19] I was just stumped by the patch tagging thing. It's far from done yet. [19:32] nixternal: yes thanks, re-uploaded now [19:35] can someone please sponsor bug 314885 before the beta freeze? [19:35] Launchpad bug 314885 in pitivi "Don't show version number in titlebar" [Low,Triaged] https://launchpad.net/bugs/314885 [19:36] oh wait, its in main now [21:07] 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] IntuitiveNipple: you can ignore all of the non-source copyright (makefiles etc) [21:18] sebner: How about translations, and I note, the source includes gnulib/ ? [21:19] IntuitiveNipple: only source, *all* source of the tarball [21:22] sebner: OK, so that means include the FSF copyrights to gnulib. Thanks.