[00:01] Anyone that knows how to change tags in debian bug reports? I can't add the "patch" tag to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473781 [00:01] Debian bug 473781 in flumotion "flumotion: new upstream release" [Wishlist,Open] [00:02] ScottK: I tried setting the patch tag with bts, I know the email was sent (cc'ed myself), but didn't get any reply from debian bugs [00:07] savvas: mail control@b.d.o [00:07] tags xxx + patch [00:09] ok, thanks Laney, I'll try once more === _neversfelde is now known as neversfelde [01:22] hello [01:23] Hi [01:28] anyone willing to give a little help rebuilding squid3? === mib_va78gba9 is now known as keefe === keefe is now known as keefe007 [01:44] I upload md4sum to revu but I don't wee the package at the website [01:46] my package had 5 lintain warnings. I looked at them and didn't know how to solve them. They looked simple, but I'm new to packaging. [02:01] why does debuild unapply patches? [02:03] kolby: You can pass the -i option to lintian to get more information about the warnings [02:07] keefe007: at the end? To give you a cleaned source for next time (so things build the same way each time) [02:07] nhandler: thank you [02:08] Thanks. [02:08] I'm trying to rebuild squid3 and it fails during debuild. Looks like the Makefiles don't get recreated for some reason. [02:09] the makefiles probably get removed in the clean rule. [02:10] presumably they should be getting created in the configure rule, when you build it? (which is before it tries bulding the package?) [02:11] Any MOTUs who can review http://revu.ubuntuwire.com/details.py?package=webgui for me please? It's a GPLed Perl-based CMS. [02:11] Hobbsee: This is what I end up with when running debuild: http://pastebin.com/m15b54def [02:15] hrm. [02:15] Why should I install my .desktop file in /usr/share/applications instead of /usr/share/games/applications/ ? [02:42] keefe007: I got it to build :) [02:42] keefe007: you are epic fail ;) === nschembr is now known as nschembr-sleep [06:43] jdong: http://people.cis.ksu.edu/~jld5445/jaunty-20090130-4.png [07:45] hey [07:46] someone referred me here just wondering if it would be the right place to ask something [07:47] Limitt: it depends on what you are going to ask. :-) === ZehRique is now known as ZehRique[Sleepin [08:09] hello [08:09] my name is itachi [08:42] /msg nellery test [10:05] Any MOTUs available to review my package, with the issues fixed that were pointed out by mok01 in my package? Thanks :) http://revu.ubuntuwire.com/details.py?package=osm-gps-map === thekorn_ is now known as thekorn [10:45] Am I supposed to provide a watch file if I get the source from svn? [10:46] I don't think the source is available anywhere else [10:48] no, but do you have a get-orig-source rule in your debian/rules to generate the .orig.tar.gz? [10:48] Piratenaapje: no, but a get-orig-source target is a must in that case [10:49] Ok I'll provide that then, thanks === LucidFox is now known as Euphoria [11:01] what is preferred way to handle upstream tarball containing debian/ directory? [11:02] slytherin, try to ask upstream to remove it, if they do not agree, repack upstream tarball without it [11:02] What do I do with an .orig.tar.gz that already includes a debian/ dir? [11:02] Do not repackage it. You can ask the author(s) to delete the debian/ dir and provide a diff.gz instead. This makes it easier to review their work, and it separates packaging from program source. [11:02] https://help.ubuntu.com/ubuntu/packagingguide/C/basic-mistakes.html apparently [11:03] i'm not sure if that's up to date, though [11:04] patch it and put a patch in debia... oh, wait [11:05] * Hobbsee giggles [11:05] yeah, that ;) [11:05] * directhex has filed his first bug for the day [11:06] reverse-5-a-day? [11:06] Hobbsee, someone's got to keep the 5-a-day people in business! [11:06] haha [11:06] I don't understand. If I do not repackage it then the diff between upstream debian/ dir and Ubuntu's debian/ dir will wne up in .diff.gz. Is that acceptable? [11:06] this is true, but i don't think they'll be out of business in a while! [11:07] Hobbsee, it's just an ickle merge bug for a mono 2.0 transitioned package... but it's one in main [11:07] ahhh [11:07] an ickle merge bug, hey... [11:08] thees bug ees only waffer-theen! [11:12] slytherin: I'd say that's acceptable as it makes it easier to verify the .orig.tar.gz [11:12] slytherin: how good or bad is the packaging done by upstream? [11:13] haven't yet reviewed fully but there are quite a few unneeded files [11:13] there are many example files (.ex) and even some emacsen related files when the package has nothing to do with emacs [11:19] one major difference is that Debian packaging uses cdbs whereas upstream packaging uses debhelper [11:21] cool kids use dh7! === Euphoria is now known as LucidFox [12:34] I think it says somewhere on wiki.ubuntu.com to repackage if you need to delete files in debian/, but not otherwise? [12:36] * maxb fails at finding the referenccce [12:49] maxb: delete files in debian/? [12:50] maxb: meaning that upstream has added a debian/ directory? [12:50] maxb: you only need to delete it if it makes your diff.gz too large [12:51] Yup, that's what I was saying [12:52] I thought deleted files didn't show up in the diff [12:53] no, they don't === maxb changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :) | next MOTU Meeting: Fri, Jan 30 12.00 UTC [12:54] (The double space in "Grab a merge" was annoying me) [12:56] Next meeting is... yesterday? [12:58] jpds: there was one, yes [12:58] meetings have been sent to the ml [12:58] err, minutes [12:58] pochu: Yeah, but the /topic is wrong thne. [12:59] so is wiki.u.c/MOTU === pochu changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :) | next MOTU Meeting: void === pochu changed the topic of #ubuntu-motu to: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | http://revu.ubuntuwire.com - Go review! :) | next MOTU Meeting: TBD [13:04] that looks better :) [13:04] Yay, do we really need to mention about the next meeting? [13:05] please do, I usually forget them :P [13:05] (about the last one, I remembered it but couldn't be at home at that time :P) [13:06] afternoon chaps [13:06] Who knows libraries, and wants to help me? http://paste.ubuntu.com/109083/ <- is this serious? How would I go about fixing? [13:46] Laney: IIUC, it's architecture-dependent how severe it is. I suppose the non-PIC code must be coming in from libac, since all the directly used .o files are apparently compiled with -fPIC? But that confuses me too, since its .libs/libac.a, with the .libs hinting that libtool magic is in force, which I *though* was supposed to arrange for compiling PIC and non-PIC versions and using the correct one as necessary [13:46] persia: Hi! I don't know if this is sufficient, but I have tested gebabbel (http://revu.ubuntuwire.com/details.py?package=gebabbel) on a clean VMWare install of Jaunty. (You were 2nd advocate) [13:48] hefe_bia, Completely. I'll upload now. Thanks. === ogra_ is now known as ogra [14:21] persia: Great! Thank you! My first package making it into Ubuntu ... :)) (And thanks of course to all the other reviewers!) [14:24] hefe_bia, No, thanks to you. I'm guessing this sigificantly improves GPS support for Kubuntu. [15:05] fta: ping [15:18] Any MOTU available to look at http://revu.ubuntuwire.com/details.py?package=cvc3 ? [15:20] DktrKranz: thanks for the advocate, though it's in debian already. i knew i should have archived it or something [15:21] DktrKranz: it hasn't gotten out of the queue or something yet though [15:21] hyperair, oh... I've just uploaded it to NEW [15:21] that's ok [15:21] Debian NEW is really slow atm [15:21] ah, still in Debian NEW? [15:21] Laney: so i heard. meebey said it was what, 3 weeks? [15:21] (it is the same package, right?) [15:21] DktrKranz: yeah [15:21] Laney: yes [15:22] Laney: bansheelyricsplugin [15:22] well, it's not that bad then [15:22] hahah [15:22] hyperair: I mean the same thing that got uploaded to debian [15:22] well i'll just file a sync request afterwards [15:22] as in, all your new changes [15:22] * DktrKranz has two packages in Debian NEW [15:22] DktrKranz: Hope your debian/copyright is spotless! [15:22] none of that pesky extra whitespace [15:22] Laney: extra whitespace? [15:22] Laney, already had a reject ;) [15:23] some package apparently got rejected for having unnecessary whitespace [15:23] we reuploaded it shortafter, but I've lost priority :P [15:24] heh [15:26] what extra whitespace, though? [15:26] as in extra lines or what? [15:26] dunno [15:27] <__Ali__> i'm trying to package a library, but the output debian only contains /usr/share, /usr/share/doc, ... there is no /usr/lib and the shared objects [15:27] <__Ali__> i use the default debhelper generated template for rules [15:28] __Ali__: do you have .install files? [15:30] <__Ali__> hyperair, it uses cmake, i guess .install files are generaed by cmake? i can see a long log of: -- Installing foo to /usr/lib/foo ... [15:30] <__Ali__> but the actual deb file does not include them [15:31] __Ali__: no, you as the packager have to use a whole bunch of debian/*.install files [15:31] __Ali__:have you read debian's library packaging guide? [15:31] <__Ali__> hyperair, seems I missed that .install part [15:32] <__Ali__> hyperair, they are not generated by debhelper? [15:32] __Ali__: no, debhelper parses them. what dyou mean generated by debhelper anyway? [15:32] you mean dh_make? [15:32] dh_make only gives you a very very general template [15:32] <__Ali__> yes dh_make :) [15:32] and i generally use cdbs [15:33] my suggestion is to go dig up some library sources [15:33] and look at how they're packaged [15:33] pick one that's most similar to the one you're packaging [15:33] and make sure you read through the debian library packaging guide, carefully [15:34] <__Ali__> hyperair, I use opensuse build system, the guide says it only needs these 4 files for building debians on their server: changelog, control, rules and dsc [15:35] <__Ali__> (of course orig and diff are also required) [15:35] <__Ali__> so, people make full debs on their server without .install? [15:36] * hyperair can't figure out how to use OBS [15:36] <__Ali__> hyperair, here it is: http://en.opensuse.org/Build_Service/Deb_builds [15:36] __Ali__: my suggestion: learn how to package properly before using OBS [15:37] the list only contains very general-purpose files [15:37] you'll definitely need more than that for packaging a library [15:37] <__Ali__> hyperair, the other people use the same list to make debs? without the use of .install? [15:39] __Ali__: they're not packaging libraries are they [15:40] __Ali__: when you package libraries, you often need several pacakges [15:40] -dev, binary package, -doc [15:40] <__Ali__> hyperair, they package eveything [15:40] .install is to make sure the files go into the appropriate packages [15:40] you can do it all in rules [15:40] ah yes that too [15:40] but it's a pita [15:40] <__Ali__> Laney, where in rules? [15:40] dh_install takes arguments [15:40] but why would you do it like that? [15:41] use a .install file, much easier! [15:41] <__Ali__> ok, I try uploading a .install file [15:41] Laney: he wants to use OBS, and he refuses to use a .install file because OBS doesn't explicitly say it's required, that's why [15:41] <__Ali__> just to see if it works [15:41] for the love of god go read the damn library packaging guide [15:41] but seriously __Ali__, you should understand what you're doing [15:41] go read read read [15:41] * hyperair walks away before he loses his temper [15:42] <__Ali__> Laney, seriously i missed that part [15:42] <__Ali__> look at this: https://wiki.ubuntu.com/PackagingGuide/Complete [15:43] <__Ali__> .install files are only introduced for 'packaging with cdbs' [15:43] <__Ali__> it implies that it's cdbs specific [15:43] __Ali__: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [15:43] this is the bible of packaging libraries [15:43] <__Ali__> ok thanks [15:44] <__Ali__> hyperair, not everything applied to debian is applied to ubuntu? [15:44] when packaging is concerned, almost everything applies [15:44] <__Ali__> like that _ in foo_1.0.0 instead of foo-1.0.0, am i right? [15:45] __Ali__: the only thing that doesn't apply is one lintian warning: debian-changelog-is-a-symlink, and that your Maintainer field in Ubuntu should not be you, but ubuntu motu developers. you may leave your name in XSBC-Original-Maintainer [15:45] I don't think we stress hard enough that creating new packages is a fairly advanced thing to do [15:46] Laney: agreed [15:46] <__Ali__> i followed the instructions for debian to make a .dsc file by dpkg-souce, it didnt do it and i had to use debuild [15:46] Laney: well sudo checkinstall does a basic job =p [15:46] depending on what you want ;( [15:46] __Ali__: nope the instructions in debian are to use debuild -S as well [15:46] does that do much over the basic cdbs/dh7 rules style? [15:47] Laney: eh waht? [15:47] checkinstall [15:47] Does it do more than ./configure; make; make instakk? [15:47] ll* [15:47] <__Ali__> hyperair, i cannot find '.install' string in that bible [15:48] __Ali__: Look at the manual page for dh_install [15:48] __Ali__: ah that's because that bible doesn't teach you about debhelper. [15:48] __Ali__: that bible assumes you already know how to package OTHER stuff [15:48] if you don't know how to package other stuff then go back to ubuntu's packaging guide [15:49] oh and open the debian policy manual [15:49] <__Ali__> i dont really think the confusing thing about packaging is its complexity, if you're a programmer, it should be straightforward for you, the confusing thing is that there are 1 million tools that do more or less the same thing, and there is no good start point [15:50] __Ali__: eh no, programming has nothing to do with packaging. well not as much as you would think [15:50] the Debian new maintainer's guide is good [15:51] yeah i personally think debian's guides are better than ubuntu's when it comes to packaging [15:51] well ours are more tutorials [15:51] yeah [15:51] tiny tutorials that don't show much [15:51] __Ali__: and trust me it's not "more or less the same thing" [15:52] __Ali__: debhelper has it's place, and cdbs is just a layer on top of debhelper [15:52] __Ali__: although it can function without debhelper [15:52] <__Ali__> well it shouldnt be more difficult than understanding quantum physics, it's just a bunch of binaries and scripts, the problem is that it's a spaghetti [15:53] __Ali__: it's spaghetti because you don't know where to start learning [15:53] The "problem", imo, is that you have to learn an awful amount of stuff all at once. [15:53] oojah: yeah that too [15:53] i mostly learnt from dh_make's documentation in the .ex files [15:53] <__Ali__> bumpy learning curve [15:53] nobody said packaging was easy [15:53] if you want easy packaging shoo go to archlinux [15:54] <__Ali__> so, is cdbs an alternative for dh_make or what? [15:55] nope [15:55] <__Ali__> even dh_make is not that functional, run dh_make -e twice and u'r screwed :) [15:55] dh_make asks you if you want to create a single binary, multiple binary, library, or cdbs package [15:55] choose cdbs [15:55] <__Ali__> i see [15:55] __Ali__: dh_make is supposed to only be called once, because it creates a template for you to do packaging [15:55] if you want to run dh_make the second time, then delete debian/ [15:55] <__Ali__> i guess i have to start over, since i choosed single binary [15:57] <__Ali__> hyperair, single binary, multiple binary and libraries, how can they be compared to cdbs? [15:57] <__Ali__> cdbs can also create a single binary? [15:58] __Ali__: oh you'll need cdbs installed in your system first [15:58] __Ali__: and cdbs is multipurpose so yeah it can create single binary [16:07] The upstream build in my package creates libfoo.so. Is there a way to make dh_install or dh_link rename it to libfoo.so.VERSION? [16:11] postalchris: you should get upstream to give you a SOVERSION [16:11] i'm not sure how to handle it downstream [16:12] you can rename files in the .install I believe [16:12] usr/lib/name.so usr/lib/name.so.X [16:12] yeah of course, but you'll have to come up with a debian specific soname [16:13] ScottK: Transition is done (re: your m-c mail) [16:13] sure, it needs fixing upstream. but that's a workaround [16:13] as far as I'm aware, at least [16:19] it just required some no-change rebuilds and a few rounds of syncs [16:22] I didn't mean to steal it from quadrispro, but it seems to have turned out that way [16:22] (sorry :() === DrKranz is now known as DktrKranz [16:33] stdin: Is there an environment variable I can use in .install to get the right version? [16:48] a|wen: Hi, I looked at zapping, seems it exit normally if /dev/video* doesn't exist (i.e: it show an error box and exits) ... so, postinst could be dropped, IMHO [16:48] however, I saw another thing: the error box is displayed bad and show no text. Has something to do with your pending diff? [16:50] gaspa: okay, that is worth considering then ... my debdiff is only about removing arts-support (arts is being removed completely from the archive) [16:50] i see. [16:52] gaspa: my debdiff is attached to bug 320915 if you want to update it with a removed postinst [16:52] Launchpad bug 320915 in libsdl "Remove aRts from the archive - rebuild all dependencies" [Undecided,In progress] https://launchpad.net/bugs/320915 [16:54] a|wen: ok, not right now.... if you are in a hurry, please upload your diff. [16:56] gaspa: it's sitting there waiting for a sponsor (together with ~10 other debdiff's) so no hurry at all :) [16:56] * gaspa thinks that is worth taking a look to the message box too... [16:58] gaspa: sounds like it ... is there a bug about that it btw? [16:59] I don't really know, [17:01] seems not [17:02] okay ... i'll take a look at it tomorrow probably [17:02] Hey folks. I seem to be stumped backporting some jaunty packages to intrepid. Are there any python c-binding gurus around that could help? [17:02] thx, for having a look at it :) [17:05] rockstar: dunno if there are, but if you ask your question directly, maybe somebody can help [17:05] pochu, well, I'm not exactly sure what question to ask. [17:05] then I don't think I can help you :) [17:05] pochu, so, I've backported the C libs and the python C-bindings for clutter. [17:06] Can I use pkg-config directly in a makefile to retrieve cflags for a particular library? If yes, what would be suntax? [17:07] pochu, the libs built fine and are working (as far as I can tell), but the python bindings don't seem to be able to import the _clutter bindings. [17:07] $(shell pkg-config --cflags bla) [17:07] pochu, I bet it's something in the python-support stuff that's a little over my head. [17:07] slytherin: ^ [17:07] rockstar: backported from Jaunty to what release? [17:07] pochu, intrepid. [17:08] hyperair: ok. wasn't sure about shell part [17:08] rockstar: does it give an ImportError when importing them in a python shell? If so, can you pastebin it? [17:08] thanks [17:08] slytherin: np [17:08] I can go into the dir with the _clutter.so file and import _clutter from the python terminal (with '.' in the PYTHONPATH) [17:09] pochu, http://pastebin.ubuntu.com/112155/ The ImportError isn't very helpful. [17:10] rockstar: where is _clutter.so? Does `python -c "import _clutter"` work? [17:11] pochu, only when I'm in the dir for with _clutter.so (which is /usr/lib/python-support/python-clutter/python2.5/clutter/) [17:13] rockstar: does this work? python -c "from clutter import _clutter" [17:13] pochu, nope. [17:14] weird [17:14] pochu, I wonder if there's a pth file missing somewhere. [17:16] rockstar: does this dir exist, and what does it contain? /var/lib/python-support/python2.5/clutter/ [17:17] <__Ali__> why libfoo0 and not libfoo? [17:17] __Ali__: context? [17:17] fta: ping [17:18] piratenaapje, ? [17:18] __Ali__: /usr/lib/libfoo0.so instead of /usr/lib/libfoo.so, you mean? [17:18] fta: I'm trying to package openkomodo based on the part you have already done [17:18] nhandler: what is appropriate location for dh_desktop call? is it install target in rules file? [17:18] <__Ali__> pochu, what's the point of that zero for some library package naming? [17:18] pochu, http://pastebin.ubuntu.com/112159/ [17:18] fta: But it doesn't seem to get the xulrunner source anywhere in your rule file? [17:19] <__Ali__> pochu, example: http://www.google.com/codesearch/p?hl=en#jN7x4wWAGeU/debian/liblasi0.install&q=include%20/usr/share/cdbs/1/class/cmake.mk [17:19] piratenaapje, it does, debian/rules get-current-source (you need to have mozilla-devscripts installed 1st) [17:19] <__Ali__> is that simply a version number? [17:20] fta: Ah thanks, didn't have that installed [17:20] piratenaapje, are you affiliated to o-m in any way? (just curious) [17:20] o-k i meant [17:20] fta: So basicly all that needs to be done is remove the pre-compiled python packages and some minor fixes? [17:20] fta: No, I just use it as my ide [17:21] piratenaapje, ok [17:21] rockstar: looks fine... I'm not sure, but you could try this: `update-python-modules python-clutter`, then try to import _clutter or from clutter import _clutter again [17:21] piratenaapje, i want to make it work with our system python, without siloing it (it's silly for us) [17:21] pochu, no joy [17:22] fta: I've looked at the build.py script, doesn't look too hard to do [17:22] __Ali__: yes, so that you can have multiple development versions co-installed [17:22] Laney: Thanks. [17:22] rockstar: no idea then [17:22] no problem [17:22] fta: But I'm a newbie, so don't know if I will succeed :p [17:22] piratenaapje, so the next step is to make "bk confirgure" work with that [17:22] -r [17:23] pochu, :( [17:24] rockstar: did you check if it works in jaunty? ;) [17:24] piratenaapje, just try to go to the failure in the openkomodo-configure rule, you have to get xul right first, the package should already be fine for that. [17:25] pochu, no Jaunty system here. [17:25] fta: Alright, I'll try [17:25] fta: It's building now, so have to wait a bit [17:25] piratenaapje, but i have to warn you this is tough package for newbies, so don't worry if you don't understand everything, just ask, i'll help [17:26] +a [17:26] fta: Yeah, the debian/rules file is pretty complicated, and there's a ton of patches :S [17:29] piratenaapje, most mozilla based packages are like that. you can move the discussion to #ubuntu-mozillateam, that where we work on all mozilla stuff. [17:29] <__Ali__> why do i get this error with cdbs: couldn't find library libxxx.so.3.11 needed by debian/libfoo/usr/lib/MyLib/libYYY.so.3.11.0 (its RPATH is '') [17:29] ScottK, Laney: re ghc6 transition, we missed some bits but I just uploaded three packages and confirmed bug 323413 back (which doesn't seem to be processed correctly). Once built, we've finished. [17:29] Launchpad bug 323413 in missingpy "Please sync missingpy 0.10.0.2 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/323413 [17:29] DktrKranz: Thanks. [17:30] bah [17:30] my apologies for missing things [17:31] Laney, not your fault, I spotted things with uncommon methods [17:31] DktrKranz, Laney, or whoever notices, please give me a ping when it's done. [17:31] ScottK, are there minutes about release meeting you attended? [17:31] DktrKranz: What were they? And have you told Debian? [17:32] DktrKranz: Not that I know of (yet), but it was in #ubuntu-meeting, so there arelogs. [17:32] * DktrKranz would like to partecipate sometimes [17:32] Laney, Debian is safe, they've binNMUed everything [17:32] I have a software suggestion for the repos. [17:32] okey dokes [17:33] J-_: which software? [17:33] http://www.les-stooges.org/pascal/pencil/index.php?id=Home [17:33] Used it once very vaguely, seemed to work awesome. [17:34] That is all :) [17:34] __Ali__: I think it means libYYY.so links to libxxx.so, but it can't find libxxx.so in /usr/lib/ or in ld.conf paths or LD_LIBRARY_PATH [17:35] Oh yes, if someone does package it into the repos, could you include a Hardy version, too? :> [17:35] __Ali__: you can check if it links to it with `ldd /path/to/libary.so`, and then try to see where that library is installed [17:35] <__Ali__> pochu, it's because libxxx.so is in debian/libfoo/usr/lib/MyLib and not in /debian/libfoo/usr/lib? [17:36] Laney, anyway, packages affected are listed here: http://hattory.no-ip.info/issues/edos/jaunty/universe/amd64/edos.results.raw (just search ghc6) [17:36] __Ali__: I think it's the other way round [17:36] <__Ali__> pochoall of the libs are in usr/lib/MyLib both libxxx.so and libYYY.so [17:36] ah, that explains it [17:36] DktrKranz: that's exciting! [17:36] I just tried some grep-available magic [17:37] evidently didn't work :( [17:37] edos rox [17:37] <__Ali__> pochu, how can i set LD_LIBRARY_PATH in cdbs to usr/lib/MyLib? [17:37] __Ali__: so either libYYY.so needs an RPATH to /usr/lib/MyLib/libxxx.so, or you need to put /usr/lib/MyLib in a file in /etc/ld.so.conf.d/ [17:37] __Ali__: LD_LIBRARY_PATH is a runtime hack, you probably don't want that approach [17:38] <__Ali__> pochu, dh_shlibdeps gives me this: Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. [17:38] <__Ali__> To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. [17:38] oh [17:39] __Ali__: maybe if you set it, it will put the right RPATH in the library... otherwise you're screwed I think [17:39] __Ali__: so maybe do this in debian/rules: "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:debian/usr/lib/MyLib" [17:39] or something like that [17:39] <__Ali__> pochu, i wasnt screwed when i didnt use cdbs, it was fine before that [17:40] __Ali__: I don't what you were doing :) [17:40] __Ali__: the question is if you want them in /usr/lib/MyLib... are they private libraries? [17:41] <__Ali__> pochu, the upstream installation is this way, i dont want to change it [17:41] ok [17:41] <__Ali__> they'r not private, they'r just too many :) [17:41] err [17:42] __Ali__: are they meant to be used by everybody? [17:42] <__Ali__> pochu, sure, i'm trying to pack itk (www.itk.org) [17:42] __Ali__: then you need to add the path to a file in /etc/ld.so.conf.d/, so that the linker can find them [17:43] (if you're not doing it yet) [17:43] <__Ali__> and based on that wrapitk (http://wrapitk.googlecode.com) which will have a few hundered so's [17:43] <__Ali__> pochu, yes, thanks for the tip [17:44] <__Ali__> pochu, but i didnt have this problem with dh_make generated template when i selected single binary [17:44] <__Ali__> i dont know what's different in cdbs [17:45] __Ali__: this is a good read btw: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [17:50] <__Ali__> pochu, is it enough to set LD_LIBRARY_PATH to debian/usr/lib/InsightToolkit, or should it be $(CURDIR)/debian/usr/lib/InsightToolkit? [17:58] slytherin: no, they will do that when reviewing the package and the license [17:58] __Ali__: not that I know of [17:58] __Ali__: just install the file into /etc (you can use debian/libfoo.install) [17:59] pochu: Ok. It is actually dependency on msttcore-fonts that will put the package in multiverse. [17:59] <__Ali__> pochu, thanks! [18:00] slytherin: then it will be there when they accept it (or they will put it there), so don't worry [18:00] ok [18:24] RainCT___: ouch at your english book! [18:24] hehe === RainCT___ is now known as RainCT [18:26] * RainCT seems to be an expert in leaving multiple irssi instances running :P [18:26] pochu: btw, we have no pending work right now, or? (just to be sure that I didn't oversee some mail) [18:31] RainCT: no, nothing right now [18:32] Anybody free to look at http://revu.ubuntuwire.com/details.py?package=cvc3 ? [18:33] postalchris: what is it? === spitfire__ is now known as spitfire_ === spitfire_ is now known as spitfire [18:34] pochu: CVC3 theorem prover [18:35] pochu: http://www.cs.nyu.edu/acsys/cvc3/ [18:37] postalchris: I'm busy now, but I may have a look at it later [18:37] I guess it's lintian clean ;) [18:38] pochu: Thanks [18:38] * slytherin is glad libjdic-java merge is ready finally. :-) [18:41] hi folks [18:42] hey sistpoty :) [18:42] hi RainCT [18:43] ahoy hoy [18:43] hi Laney [18:44] * sistpoty is open for reviews... anyone? [18:44] sistpoty: < postalchris> Anybody free to look at [18:44] http://revu.ubuntuwire.com/details.py?package=cvc3 ? [18:44] * sistpoty looks [18:44] thanks RainCT [18:44] slytherin: Did you figure it out? [18:45] np [18:46] * Laney trolls for sponsors [18:46] nhandler: not yet. I am working on the package but doing some additional changes [18:46] The java changes you mentioned? [18:46] nhandler: it seems the guy was changing .desktop file in .orig.tar.gz as well. So it differs from upstream tarball [18:46] Laney: What do you need sponsored [18:47] nhandler: MOTU application :P, I wasn't being serious [18:47] slytherin: IIRC, he is upstream, so that won't be difficult to get fixed [18:48] nhandler: Right. Also I am trying if the package works without msttcore-fonts. I had suggested him to patch the source to use font family names instead of a font face "Arial". [18:49] What things are we currently documenting in the changelog entry for new packages? I thought we were only mentioning that it was an initial release (close needs-packaging bug) and any changes to the upstream source such as repackaging or patching it [18:50] That's the minimum, but there's no harm in mentioning anything else of note [18:51] Laney: I realize that there is no harm in including other stuff in the changelog entry, but I'm just trying to see if there is anything else that is "required" [18:54] nhandler: as a rule of thumb, anything that's unexpect should be mentioned there (e.g. repacking the upstream tarball) [18:54] unexpected even [18:54] nhandler: The package works without msttcorefonts [18:54] slytherin: Glad to hear that. [18:54] If any MOTU is available: http://revu.ubuntuwire.com/details.py?package=grnotify needs 1 more advocate. It's a google reader notifier. [18:55] piratenaapje1: I'll take a look [18:55] nhandler: thanks :) [18:55] nhandler: I think it's good practice to document any patches or other divergence from upstream. [18:56] ScottK: That is the main thing I thought [18:57] hi motus [18:57] nhandler: so where do I put dh_desktop call? [18:57] concerning the last sync of the package scala... [18:58] it fails to build on lpia just because lpia is not listed [18:58] actually it builds fine but dpkg-gencontrol fails [18:58] as you can see here http://launchpadlibrarian.net/21853748/buildlog_ubuntu-jaunty-lpia.scala_2.7.3-2_FAILEDTOBUILD.txt.gz [18:58] is there a way to fix that? Should I fill a bug against that? [18:59] slytherin: For monajat? [18:59] mehdid: change the value of architecture field (debian/control.in) to any, if that is the only thing required [18:59] nhandler: yes [19:00] slytherin: I put it in the binary-indep section [19:00] I'm not motu (i'd love to ... but not yet) [19:00] :) [19:01] slytherin: so what can I do ? [19:01] nhandler: but where exactly? I mean before dh_install or after? [19:01] mehdid: We don't need a bug to know about FTBFS. If you up with a fix, a bug with a patch would be much apreciated. [19:01] mehdid: create a patch try to build it. if successful then file a bug and attach the patch [19:02] slytherin: I put mine around the dh_installdocs and dh_installchangelog stuff. But I don't think it is a huge deal [19:03] ScottK: slytherin: I'll file a bug and attach a patch [19:03] ScottK: slytherin: thanks [19:03] mehdid: Subscribe ubuntu-universe-sponsors to the bug after you attach the patch. [19:05] why the heck scala is arch dependent package? Shouldn't it be arch:all package. It includes no native binaries/libraries [19:05] * slytherin takes a closer look [19:07] slytherin: yes it should be but it fails to build on arm hppa and alpha because of some missing dependencies [19:08] mehdid: what dependencies? [19:08] in older versions, we used to build scala with gcj which is missing on those archs [19:09] so now we changed to that to openjdk and it was an upload to test the package and see how it builds [19:09] mehdid: AFAIK, gcj is present on all arch. In any case arch:all packages are built only in i386 [19:09] gcj is not present on arm hppa alpha [19:10] mehdid: while you are at it, can you please change 'Architecture' of scala and scala-library to 'all' ? [19:11] and even if it's arch:all it should build on all arches (even if it's not necessary) and it fails on the three mentioned [19:11] yes ... I'll just wait for the buildd to see how it builds [19:11] mehdid: This is a java app we are talking about. It does not need to be built on all architectures. [19:11] and then I'll make a trivial patch [19:12] from an application point of view, yes [19:12] from a packaging point of view, anyone should be able to re-build the package on any arch specified by debian/control [19:15] mehdid: how is that going to be affected by making architecture 'all'? [19:15] * RainCT gets mad and deletes lots of source files from REVU *g* [19:16] slytherin: because it fails to build on arm alpha and hppa where gcj wasn't present [19:17] mehdid: I am not asking you to change build dependencies am I? [19:18] RainCT: Why are you deleting them? [19:18] nhandler: there were 4 old files which weren't used for anything, and I could get ride of 2 more by changing some code to use python-debian :) [19:19] slytherin: oh I misunderstood ... yes, it should be fine with openjdk. 2.7.3-3 was only a testing upload [19:19] mehdid: by the way, the current build dependencies are wrong. you don't need 2 java compilers. You either need java-gcj-compat-dev or openjdk-6-jdk. Same goes with runtime dependencies. [19:19] slytherin: the next upload should fix this issue [19:20]