[00:01] <savvas> 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:02] <savvas> 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] <Laney> savvas: mail control@b.d.o
[00:07] <Laney> tags xxx + patch
[00:09] <savvas> ok, thanks Laney, I'll try once more
[01:22] <mib_va78gba9> hello
[01:23] <Steck> Hi
[01:28] <mib_va78gba9> anyone willing to give a little help rebuilding squid3?
[01:44] <kolby> I upload md4sum to revu but I don't wee the package at the website
[01:46] <kolby> 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] <keefe007> why does debuild unapply patches?
[02:03] <nhandler> kolby: You can pass the -i option to lintian to get more information about the warnings
[02:07] <Hobbsee> keefe007: at the end?  To give you a cleaned source for next time (so things build the same way each time)
[02:07] <kolby> nhandler: thank you
[02:08] <keefe007> Thanks.
[02:08] <keefe007> I'm trying to rebuild squid3 and it fails during debuild.  Looks like the Makefiles don't get recreated for some reason.
[02:09] <Hobbsee> the makefiles probably get removed in the clean rule.
[02:10] <Hobbsee> presumably they should be getting created in the configure rule, when you build it?  (which is before it tries bulding the package?)
[02:11] <jmarsden> 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] <keefe007> Hobbsee: This is what I end up with when running debuild: http://pastebin.com/m15b54def
[02:15] <Hobbsee> hrm.
[02:15] <ryanakca> Why should I install my .desktop file in /usr/share/applications instead of /usr/share/games/applications/ ?
[02:42] <chillywilly> keefe007: I got it to build :)
[02:42] <chillywilly> keefe007: you are epic fail ;)
[06:43] <pwnguin> jdong: http://people.cis.ksu.edu/~jld5445/jaunty-20090130-4.png
[07:45] <Limitt> hey
[07:46] <Limitt> someone referred me here just wondering if it would be the right place to ask something
[07:47] <slytherin> Limitt: it depends on what you are going to ask. :-)
[08:09] <itachi> hello
[08:09] <itachi> my name is itachi
[08:42] <nellery_> /msg nellery test
[10:05] <AndrewGee> 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
[10:45] <Piratenaapje> Am I supposed to provide a watch file if I get the source from svn?
[10:46] <Piratenaapje> I don't think the source is available anywhere else
[10:48] <geser> no, but do you have a get-orig-source rule in your debian/rules to generate the .orig.tar.gz?
[10:48] <slytherin> Piratenaapje: no, but a get-orig-source target is a must in that case
[10:49] <Piratenaapje> Ok I'll provide that then, thanks
[11:01] <slytherin> what is preferred way to handle upstream tarball containing debian/ directory?
[11:02] <DktrKranz> slytherin, try to ask upstream to remove it, if they do not agree, repack upstream tarball without it
[11:02] <Hobbsee> What do I do with an .orig.tar.gz that already includes a debian/ dir?
[11:02] <Hobbsee> 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] <Hobbsee> https://help.ubuntu.com/ubuntu/packagingguide/C/basic-mistakes.html apparently
[11:03] <Hobbsee> i'm not sure if that's up to date, though
[11:04] <directhex> patch it and put a patch in debia... oh, wait
[11:05]  * Hobbsee giggles
[11:05] <Hobbsee> yeah, that ;)
[11:05]  * directhex has filed his first bug for the day
[11:06] <Hobbsee> reverse-5-a-day?
[11:06] <directhex> Hobbsee, someone's got to keep the 5-a-day people in business!
[11:06] <Hobbsee> haha
[11:06] <slytherin> 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] <Hobbsee> this is true, but i don't think they'll be out of business in a while!
[11:07] <directhex> Hobbsee, it's just an ickle merge bug for a mono 2.0 transitioned package... but it's one in main
[11:07] <Hobbsee> ahhh
[11:07] <Hobbsee> an ickle merge bug, hey...
[11:08] <directhex> thees bug ees only waffer-theen!
[11:12] <geser> slytherin: I'd say that's acceptable as it makes it easier to verify the .orig.tar.gz
[11:12] <geser> slytherin: how good or bad is the packaging done by upstream?
[11:13] <slytherin> haven't yet reviewed fully but there are quite a few unneeded files
[11:13] <slytherin> there are many example files (.ex) and even some emacsen related files when the package has nothing to do with emacs
[11:19] <slytherin> one major difference is that Debian packaging uses cdbs whereas upstream packaging uses debhelper
[11:21] <directhex> cool kids use dh7!
[12:34] <maxb> 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] <hyperair> maxb: delete files in debian/?
[12:50] <hyperair> maxb: meaning that upstream has added a debian/ directory?
[12:50] <hyperair> maxb: you only need to delete it if it makes your diff.gz too large
[12:51] <maxb> Yup, that's what I was saying
[12:52] <Laney> I thought deleted files didn't show up in the diff
[12:53] <geser> no, they don't
[12:54] <maxb> (The double space in "Grab a  merge" was annoying me)
[12:56] <jpds> Next meeting is... yesterday?
[12:58] <pochu> jpds: there was one, yes
[12:58] <pochu> meetings have been sent to the ml
[12:58] <pochu> err, minutes
[12:58] <jpds> pochu: Yeah, but the /topic is wrong thne.
[12:59] <maxb> so is wiki.u.c/MOTU
[13:04] <pochu> that looks better :)
[13:04] <iulian> Yay, do we really need to mention about the next meeting?
[13:05] <RainCT> please do, I usually forget them :P
[13:05] <RainCT> (about the last one, I remembered it but couldn't be at home at that time :P)
[13:06] <Laney> afternoon chaps
[13:06] <Laney> Who knows libraries, and wants to help me? http://paste.ubuntu.com/109083/ <- is this serious? How would I go about fixing?
[13:46] <maxb> 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] <hefe_bia> 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] <persia> hefe_bia, Completely.  I'll upload now.  Thanks.
[14:21] <hefe_bia> persia: Great! Thank you! My first package making it into Ubuntu ... :)) (And thanks of course to all the other reviewers!)
[14:24] <persia> hefe_bia, No, thanks to you.  I'm guessing this sigificantly improves GPS support for Kubuntu.
[15:05] <piratenaapje> fta: ping
[15:18] <postalchris> Any MOTU available to look at http://revu.ubuntuwire.com/details.py?package=cvc3 ?
[15:20] <hyperair> DktrKranz: thanks for the advocate, though it's in debian already. i knew i should have archived it or something
[15:21] <hyperair> DktrKranz: it hasn't gotten out of the queue or something yet though
[15:21] <DktrKranz> hyperair, oh... I've just uploaded it to NEW
[15:21] <Laney> that's ok
[15:21] <Laney> Debian NEW is really slow atm
[15:21] <DktrKranz> ah, still in Debian NEW?
[15:21] <hyperair> Laney: so i heard. meebey said it was what, 3 weeks?
[15:21] <Laney> (it is the same package, right?)
[15:21] <hyperair> DktrKranz: yeah
[15:21] <hyperair> Laney: yes
[15:22] <hyperair> Laney: bansheelyricsplugin
[15:22] <DktrKranz> well, it's not that bad then
[15:22] <hyperair> hahah
[15:22] <Laney> hyperair: I mean the same thing that got uploaded to debian
[15:22] <hyperair> well i'll just file a sync request afterwards
[15:22] <Laney> as in, all your new changes
[15:22]  * DktrKranz has two packages in Debian NEW
[15:22] <Laney> DktrKranz: Hope your debian/copyright is spotless!
[15:22] <Laney> none of that pesky extra whitespace
[15:22] <hyperair> Laney: extra whitespace?
[15:22] <DktrKranz> Laney, already had a reject ;)
[15:23] <Laney> some package apparently got rejected for having unnecessary whitespace
[15:23] <DktrKranz> we reuploaded it shortafter, but I've lost priority :P
[15:24] <Laney> heh
[15:26] <hyperair> what extra whitespace, though?
[15:26] <hyperair> as in extra lines or what?
[15:26] <Laney> 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] <hyperair> __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] <hyperair> __Ali__: no, you as the packager have to use a whole bunch of debian/*.install files
[15:31] <hyperair> __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] <hyperair> __Ali__: no, debhelper parses them. what dyou mean generated by debhelper anyway?
[15:32] <hyperair> you mean dh_make?
[15:32] <hyperair> dh_make only gives you a very very general template
[15:32] <__Ali__> yes dh_make :)
[15:32] <hyperair> and i generally use cdbs
[15:33] <hyperair> my suggestion is to go dig up some library sources
[15:33] <hyperair> and look at how they're packaged
[15:33] <hyperair> pick one that's most similar to the one you're packaging
[15:33] <hyperair> 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] <hyperair> __Ali__: my suggestion: learn how to package properly before using OBS
[15:37] <hyperair> the list only contains very general-purpose files
[15:37] <hyperair> 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] <hyperair> __Ali__: they're not packaging libraries are they
[15:40] <hyperair> __Ali__: when you package libraries, you often need several pacakges
[15:40] <hyperair> -dev, binary package, -doc
[15:40] <__Ali__> hyperair, they package eveything
[15:40] <hyperair> .install is to make sure the files go into the appropriate packages
[15:40] <Laney> you can do it all in rules
[15:40] <hyperair> ah yes that too
[15:40] <hyperair> but it's a pita
[15:40] <__Ali__> Laney, where in rules?
[15:40] <Laney> dh_install takes arguments
[15:40] <Laney> but why would you do it like that?
[15:41] <Laney> use a .install file, much easier!
[15:41] <__Ali__> ok, I try uploading a .install file
[15:41] <hyperair> 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] <hyperair> for the love of god go read the damn library packaging guide
[15:41] <Laney> but seriously __Ali__, you should understand what you're doing
[15:41] <Laney> 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] <hyperair> __Ali__: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[15:43] <hyperair> 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] <hyperair> 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] <hyperair> __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] <Laney> I don't think we stress hard enough that creating new packages is a fairly advanced thing to do
[15:46] <hyperair> 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] <hyperair> Laney: well sudo checkinstall does a basic job =p
[15:46] <Laney> depending on what you want ;(
[15:46] <hyperair> __Ali__: nope the instructions in debian are to use debuild -S as well
[15:46] <Laney> does that do much over the basic cdbs/dh7 rules style?
[15:47] <hyperair> Laney: eh waht?
[15:47] <Laney> checkinstall
[15:47] <Laney> Does it do more than ./configure; make; make instakk?
[15:47] <Laney> ll*
[15:47] <__Ali__> hyperair, i cannot find '.install' string in that bible
[15:48] <Laney> __Ali__: Look at the manual page for dh_install
[15:48] <hyperair> __Ali__: ah that's because that bible doesn't teach you about debhelper.
[15:48] <hyperair> __Ali__: that bible assumes you already know how to package OTHER stuff
[15:48] <hyperair> if you don't know how to package other stuff then go back to ubuntu's packaging guide
[15:49] <hyperair> 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] <hyperair> __Ali__: eh no, programming has nothing to do with packaging. well not as much as you would think
[15:50] <Laney> the Debian new maintainer's guide is good
[15:51] <hyperair> yeah i personally think debian's guides are better than ubuntu's when it comes to packaging
[15:51] <Laney> well ours are more tutorials
[15:51] <hyperair> yeah
[15:51] <hyperair> tiny tutorials that don't show much
[15:51] <hyperair> __Ali__: and trust me it's not "more or less the same thing"
[15:52] <hyperair> __Ali__: debhelper has it's place, and cdbs is just a layer on top of debhelper
[15:52] <hyperair> __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] <hyperair> __Ali__: it's spaghetti because you don't know where to start learning
[15:53] <oojah> The "problem", imo, is that you have to learn an awful amount of stuff all at once.
[15:53] <hyperair> oojah: yeah that too
[15:53] <hyperair> i mostly learnt from dh_make's documentation in the .ex files
[15:53] <__Ali__> bumpy learning curve
[15:53] <hyperair> nobody said packaging was easy
[15:53] <hyperair> if you want easy packaging shoo go to archlinux
[15:54] <__Ali__> so, is cdbs an alternative for dh_make or what?
[15:55] <hyperair> nope
[15:55] <__Ali__> even dh_make is not that functional, run dh_make -e twice and u'r screwed :)
[15:55] <hyperair> dh_make asks you if you want to create a single binary, multiple binary, library, or cdbs package
[15:55] <hyperair> choose cdbs
[15:55] <__Ali__> i see
[15:55] <hyperair> __Ali__: dh_make is supposed to only be called once, because it creates a template for you to do packaging
[15:55] <hyperair> 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] <hyperair> __Ali__: oh you'll need cdbs installed in your system first
[15:58] <hyperair> __Ali__: and cdbs is multipurpose so yeah it can create single binary
[16:07] <postalchris> 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] <hyperair> postalchris: you should get upstream to give you a SOVERSION
[16:11] <hyperair> i'm not sure how to handle it downstream
[16:12] <stdin> you can rename files in the .install I believe
[16:12] <stdin> usr/lib/name.so usr/lib/name.so.X
[16:12] <hyperair> yeah of course, but you'll have to come up with a debian specific soname
[16:13] <Laney> ScottK: Transition is done (re: your m-c mail)
[16:13] <stdin> sure, it needs fixing upstream. but that's a workaround
[16:13] <Laney> as far as I'm aware, at least
[16:19] <Laney> it just required some no-change rebuilds and a few rounds of syncs
[16:22] <Laney> I didn't mean to steal it from quadrispro, but it seems to have turned out that way
[16:22] <Laney> (sorry :()
[16:33] <postalchris> stdin: Is there an environment variable I can use in .install to get the right version?
[16:48] <gaspa> 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] <gaspa> 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] <a|wen> 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] <gaspa> i see.
[16:52] <a|wen> gaspa: my debdiff is attached to bug 320915 if you want to update it with a removed postinst
[16:54] <gaspa> a|wen: ok, not right now.... if you are in a hurry, please upload your diff.
[16:56] <a|wen> 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] <a|wen> gaspa: sounds like it ... is there a bug about that it btw?
[16:59] <gaspa> I don't really know,
[17:01] <gaspa> seems not
[17:02] <a|wen> okay ... i'll take a look at it tomorrow probably
[17:02] <rockstar> 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] <a|wen> thx, for having a look at it :)
[17:05] <pochu> rockstar: dunno if there are, but if you ask your question directly, maybe somebody can help
[17:05] <rockstar> pochu, well, I'm not exactly sure what question to ask.
[17:05] <pochu> then I don't think I can help you :)
[17:05] <rockstar> pochu, so, I've backported the C libs and the python C-bindings for clutter.
[17:06] <slytherin> Can I use pkg-config directly in a makefile to retrieve cflags for a particular library? If yes, what would be suntax?
[17:07] <rockstar> 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] <hyperair> $(shell pkg-config --cflags bla)
[17:07] <rockstar> pochu, I bet it's something in the python-support stuff that's a little over my head.
[17:07] <hyperair> slytherin: ^
[17:07] <pochu> rockstar: backported from Jaunty to what release?
[17:07] <rockstar> pochu, intrepid.
[17:08] <slytherin> hyperair: ok. wasn't sure about shell part
[17:08] <pochu> rockstar: does it give an ImportError when importing them in a python shell? If so, can you pastebin it?
[17:08] <slytherin> thanks
[17:08] <hyperair> slytherin: np
[17:08] <rockstar> I can go into the dir with the _clutter.so file and import _clutter from the python terminal (with '.' in the PYTHONPATH)
[17:09] <rockstar> pochu, http://pastebin.ubuntu.com/112155/  The ImportError isn't very helpful.
[17:10] <pochu> rockstar: where is _clutter.so? Does `python -c "import _clutter"` work?
[17:11] <rockstar> 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] <pochu> rockstar: does this work? python -c "from clutter import _clutter"
[17:13] <rockstar> pochu, nope.
[17:14] <pochu> weird
[17:14] <rockstar> pochu, I wonder if there's a pth file missing somewhere.
[17:16] <pochu> 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] <pochu> __Ali__: context?
[17:17] <piratenaapje> fta: ping
[17:18] <fta> piratenaapje, ?
[17:18] <pochu> __Ali__: /usr/lib/libfoo0.so instead of /usr/lib/libfoo.so, you mean?
[17:18] <piratenaapje> fta: I'm trying to package openkomodo based on the part you have already done
[17:18] <slytherin> 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] <rockstar> pochu, http://pastebin.ubuntu.com/112159/
[17:18] <piratenaapje> 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] <fta> 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] <piratenaapje> fta: Ah thanks, didn't have that installed
[17:20] <fta> piratenaapje, are you affiliated to o-m in any way? (just curious)
[17:20] <fta> o-k i meant
[17:20] <piratenaapje> fta: So basicly all that needs to be done is remove the pre-compiled python packages and some minor fixes?
[17:20] <piratenaapje> fta: No, I just use it as my ide
[17:21] <fta> piratenaapje, ok
[17:21] <pochu> 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] <fta> piratenaapje, i want to make it work with our system python, without siloing it (it's silly for us)
[17:21] <rockstar> pochu, no joy
[17:22] <piratenaapje> fta: I've looked at the build.py script, doesn't look too hard to do
[17:22] <pochu> __Ali__: yes, so that you can have multiple development versions co-installed
[17:22] <ScottK> Laney: Thanks.
[17:22] <pochu> rockstar: no idea then
[17:22] <Laney> no problem
[17:22] <piratenaapje> fta: But I'm a newbie, so don't know if I will succeed :p
[17:22] <fta> piratenaapje, so the next step is to make "bk confirgure" work with that
[17:22] <fta> -r
[17:23] <rockstar> pochu, :(
[17:24] <pochu> rockstar: did you check if it works in jaunty? ;)
[17:24] <fta> 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] <rockstar> pochu, no Jaunty system here.
[17:25] <piratenaapje> fta: Alright, I'll try
[17:25] <piratenaapje> fta: It's building now, so have to wait a bit
[17:25] <fta> 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] <fta> +a
[17:26] <piratenaapje> fta: Yeah, the debian/rules file is pretty complicated, and there's a ton of patches :S
[17:29] <fta> 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] <DktrKranz> 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] <ScottK> DktrKranz: Thanks.
[17:30] <Laney> bah
[17:30] <Laney> my apologies for missing things
[17:31] <DktrKranz> Laney, not your fault, I spotted things with uncommon methods
[17:31] <ScottK> DktrKranz, Laney, or whoever notices, please give me a ping when it's done.
[17:31] <DktrKranz> ScottK, are there minutes about release meeting you attended?
[17:31] <Laney> DktrKranz: What were they? And have you told Debian?
[17:32] <ScottK> 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] <DktrKranz> Laney, Debian is safe, they've binNMUed everything
[17:32] <J-_> I have a software suggestion for the repos.
[17:32] <Laney> okey dokes
[17:33] <slytherin> J-_: which software?
[17:33] <J-_> http://www.les-stooges.org/pascal/pencil/index.php?id=Home
[17:33] <J-_> Used it once very vaguely, seemed to work awesome.
[17:34] <J-_> That is all :)
[17:34] <pochu> __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] <J-_> Oh yes, if someone does package it into the repos, could you include a Hardy version, too? :>
[17:35] <pochu> __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] <DktrKranz> 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] <pochu> __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] <pochu> ah, that explains it
[17:36] <Laney> DktrKranz: that's exciting!
[17:36] <Laney> I just tried some grep-available magic
[17:37] <Laney> evidently didn't work :(
[17:37] <DktrKranz> edos rox
[17:37] <__Ali__> pochu, how can i set LD_LIBRARY_PATH in cdbs to usr/lib/MyLib?
[17:37] <pochu> __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] <pochu> __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] <pochu> oh
[17:39] <pochu> __Ali__: maybe if you set it, it will put the right RPATH in the library... otherwise you're screwed I think
[17:39] <pochu> __Ali__: so maybe do this in debian/rules: "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:debian/usr/lib/MyLib"
[17:39] <pochu> or something like that
[17:39] <__Ali__> pochu, i wasnt screwed when i didnt use cdbs, it was fine before that
[17:40] <pochu> __Ali__: I don't what you were doing :)
[17:40] <pochu> __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] <pochu> ok
[17:41] <__Ali__> they'r not private, they'r just too many :)
[17:41] <pochu> err
[17:42] <pochu> __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] <pochu> __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] <pochu> (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] <pochu> __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] <pochu> slytherin: no, they will do that when reviewing the package and the license
[17:58] <pochu> __Ali__: not that I know of
[17:58] <pochu> __Ali__: just install the file into /etc (you can use debian/libfoo.install)
[17:59] <slytherin> pochu: Ok. It is actually dependency on msttcore-fonts that will put the package in multiverse.
[17:59] <__Ali__> pochu,  thanks!
[18:00] <pochu> slytherin: then it will be there when they accept it (or they will put it there), so don't worry
[18:00] <slytherin> ok
[18:24] <pochu> RainCT___: ouch at your english book!
[18:24] <RainCT___> hehe
[18:26]  * RainCT seems to be an expert in leaving multiple irssi instances running :P
[18:26] <RainCT> pochu: btw, we have no pending work right now, or? (just to be sure that I didn't oversee some mail)
[18:31] <pochu> RainCT: no, nothing right now
[18:32] <postalchris> Anybody free to look at http://revu.ubuntuwire.com/details.py?package=cvc3 ?
[18:33] <pochu> postalchris: what is it?
[18:34] <postalchris> pochu: CVC3 theorem prover
[18:35] <postalchris> pochu: http://www.cs.nyu.edu/acsys/cvc3/
[18:37] <pochu> postalchris: I'm busy now, but I may have a look at it later
[18:37] <pochu> I guess it's lintian clean ;)
[18:38] <postalchris> pochu: Thanks
[18:38]  * slytherin is glad libjdic-java merge is ready finally. :-)
[18:41] <sistpoty> hi folks
[18:42] <RainCT> hey sistpoty :)
[18:42] <sistpoty> hi RainCT
[18:43] <Laney> ahoy hoy
[18:43] <sistpoty> hi Laney
[18:44]  * sistpoty is open for reviews... anyone?
[18:44] <RainCT> sistpoty:  < postalchris> Anybody free to look at
[18:44] <RainCT>                      http://revu.ubuntuwire.com/details.py?package=cvc3 ?
[18:44]  * sistpoty looks
[18:44] <sistpoty> thanks RainCT
[18:44] <nhandler> slytherin: Did you figure it out?
[18:45] <RainCT> np
[18:46]  * Laney trolls for sponsors
[18:46] <slytherin> nhandler: not yet. I am working on the package but doing some additional changes
[18:46] <nhandler> The java changes you mentioned?
[18:46] <slytherin> nhandler: it seems the guy was changing .desktop file in .orig.tar.gz as well. So it differs from upstream tarball
[18:46] <nhandler> Laney: What do you need sponsored
[18:47] <Laney> nhandler: MOTU application :P, I wasn't being serious
[18:47] <nhandler> slytherin: IIRC, he is upstream, so that won't be difficult to get fixed
[18:48] <slytherin> 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] <nhandler> 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] <Laney> That's the minimum, but there's no harm in mentioning anything else of note
[18:51] <nhandler> 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] <sistpoty> nhandler: as a rule of thumb, anything that's unexpect should be mentioned there (e.g. repacking the upstream tarball)
[18:54] <sistpoty> unexpected even
[18:54] <slytherin> nhandler: The package works without msttcorefonts
[18:54] <nhandler> slytherin: Glad to hear that.
[18:54] <piratenaapje1> 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] <nhandler> piratenaapje1: I'll take a look
[18:55] <piratenaapje1> nhandler: thanks :)
[18:55] <ScottK> nhandler: I think it's good practice to document any patches or other divergence from upstream.
[18:56] <nhandler> ScottK: That is the main thing I thought
[18:57] <mehdid> hi motus
[18:57] <slytherin> nhandler: so where do I put dh_desktop call?
[18:57] <mehdid> concerning the last sync of the package scala...
[18:58] <mehdid> it fails to build on lpia just because lpia is not listed
[18:58] <mehdid> actually it builds fine but dpkg-gencontrol fails
[18:58] <mehdid> as you can see here http://launchpadlibrarian.net/21853748/buildlog_ubuntu-jaunty-lpia.scala_2.7.3-2_FAILEDTOBUILD.txt.gz
[18:58] <mehdid> is there a way to fix that? Should I fill a bug against that?
[18:59] <nhandler> slytherin: For monajat?
[18:59] <slytherin> mehdid: change the value of architecture field (debian/control.in) to any, if that is the only thing required
[18:59] <slytherin> nhandler: yes
[19:00] <nhandler> slytherin: I put it in the binary-indep section
[19:00] <mehdid> I'm not motu (i'd love to ... but not yet)
[19:00] <mehdid> :)
[19:01] <mehdid> slytherin: so what can I do ?
[19:01] <slytherin> nhandler: but where exactly? I mean before dh_install or after?
[19:01] <ScottK> 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] <slytherin> mehdid: create a patch try to build it. if successful then file a bug and attach the patch
[19:02] <nhandler> slytherin: I put mine around the dh_installdocs and dh_installchangelog stuff. But I don't think it is a huge deal
[19:03] <mehdid> ScottK: slytherin: I'll file a bug and attach a patch
[19:03] <mehdid> ScottK: slytherin: thanks
[19:03] <ScottK> mehdid: Subscribe ubuntu-universe-sponsors to the bug after you attach the patch.
[19:05] <slytherin> 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] <mehdid> slytherin: yes it should be but it fails to build on arm hppa and alpha because of some missing dependencies
[19:08] <slytherin> mehdid: what dependencies?
[19:08] <mehdid> in older versions, we used to build scala with gcj which is missing on those archs
[19:09] <mehdid> so now we changed to that to openjdk and it was an upload to test the package and see how it builds
[19:09] <slytherin> mehdid: AFAIK, gcj is present on all arch. In any case arch:all packages are built only in i386
[19:09] <mehdid> gcj is not present on arm hppa alpha
[19:10] <slytherin> mehdid: while you are at it, can you please change 'Architecture' of scala and scala-library to 'all' ?
[19:11] <mehdid> 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] <mehdid> yes ... I'll just wait for the buildd to see how it builds
[19:11] <slytherin> mehdid: This is a java app we are talking about. It does not need to be built on all architectures.
[19:11] <mehdid> and then I'll make a trivial patch
[19:12] <mehdid> from an application point of view, yes
[19:12] <mehdid> from a packaging point of view, anyone should be able to re-build the package on any arch specified by debian/control
[19:15] <slytherin> 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] <mehdid> slytherin: because it fails to build on arm alpha and hppa where gcj wasn't present
[19:17] <slytherin> mehdid: I am not asking you to change build dependencies am I?
[19:18] <nhandler> RainCT: Why are you deleting them?
[19:18] <RainCT> 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] <mehdid> slytherin: oh I misunderstood ... yes, it should be fine with openjdk. 2.7.3-3 was only a testing upload
[19:19] <slytherin> 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] <mehdid> slytherin: the next upload should fix this issue
[19:20] <nhandler> RainCT: Ok, I thought you were talking about source *packages* on REVU ;)
[19:20] <slytherin> mehdid: cool, thanks. And make sure you change architecture to all. :-)
[19:20] <RainCT> nhandler: nah, although that would be funny :P
[19:21] <nhandler> RainCT: if(package.language != perl) package.removeSelfFromREVU();
[19:21] <RainCT> nhandler: change that != to and == and I'm happy with running it :D
[19:23] <slytherin> mehdid: by the way, ideally you should be using default-jdk as build dependency. And also modify JAVA_HOME in debian/rules accordingly.
[19:27] <mehdid> slytherin: the only reason that lets me choose openjdk over other solutions is that it builds much more faster with openjdk :)
[19:27] <slytherin> mehdid: right, I forgot debian still had gcj as default-jdk
[19:30] <RainCT> and another file removed (and details.py needs 2 SQL queries less now :D)
[19:31] <piratenaapje1> fakeroot keeps giving me '/usr/bin/fakeroot: line 164: debian/rules: Permission denied' and I can't figure out why. debian/rules has 644 permissions and I'm the owner
[19:32] <geser> chmod +x debian/rules
[19:32] <piratenaapje1> I'm an idiot
[19:32] <geser> debian/rules has to be executable
[19:32] <piratenaapje1> thanks
[19:38] <loic-m> I'm creating a .desktop file for a package who's missing one. At the same time, I'd like to fix the folder where the icon is put
[19:38] <loic-m> Atm, it goes to /usr/share/package/ , shouldn't it be /usr/share/pixmaps (btw it's a game, tuxtype)
[19:39] <RainCT> loic-m: yep
[19:39] <RainCT> loic-m: and it should be 48x48 if it's a PNG or 32x32 if it's an XPm
[19:39] <loic-m> So i can just fix the cp in the rules section, or use dh_install ?
[19:39] <loic-m> RainCT: so PNG would look better...
[19:40] <RainCT> loic-m: Indeed it does. Is everything working fine if you remove it from /usr/share?
[19:40] <RainCT> loic-m: if not, then just create a symlink instead of moving the file
[19:41] <RainCT> loic-m: also note (in case you didn't know) that Exec= and Icon= should just be the filename (without a path, the menu is wise enough to figure it out by itself)
[19:41] <loic-m> RainCT: I'll test it, but since it's in debian/ it should be only used for that, not by the program, no?
[19:41] <loic-m> RainCT: indeed; that's what made me notice it when I was doing the .desktop file
[19:42] <RainCT> loic-m: ah, then probably you're save
[19:42] <loic-m> RainCT: The icon is actually a 32x32 xpm
[19:42] <loic-m> RainCT: thanks RainCT
[19:42] <RainCT> loic-m: if you replace it with a PNG, note that you'll have to uuencode it (https://wiki.ubuntu.com/PackagingGuide/Howtos/BinaryFilesInDiff)
[19:43] <loic-m> RainCT: I'll probably keep it as an .xpm (simpler than tracking the license of a new icon, since there's not much point converting the xpm to PNG...
[19:44] <loic-m> RainCT: just to make sure, is dh_install the recommended method for icons?
[19:45] <RainCT> loic-m: yes, afaik
[19:45] <sistpoty> postalchris: cvc3 reviewed, please see the comments
[19:45]  * iulian prefers debian/install.
[19:45] <loic-m> RainCT thx a lot
[19:45] <RainCT> iulian: that is dh_install :P
[19:46] <loic-m> iulian: is that possible when not using CDBS?
[19:46] <RainCT> loic-m: sure
[19:47] <loic-m> I've got to learn how to do that (even though I'll make as less changes as possible for this pkg) for future use
[19:47] <iulian> RainCT: Yes but I usually just call dh_install and have an install file in debian dir.
[19:47] <RainCT> loic-m: just call dh_install without arguments in debian/rules and write the stuff in debian/install
[19:47] <loic-m> I just create an install file like for CDBS, then it's automatic?
[19:47] <loic-m> RainCT: thx
[19:47] <RainCT> loic-m: if you're calling dh_install, yes
[19:48] <RainCT> iulian: yep, me too
[19:48] <loic-m> I'll remember that way to do it...
[19:53] <dooooomi> if there's a MOTU around looking for something to review: http://revu.ubuntuwire.com/details.py?package=pyliblo
[19:57] <postalchris>  sistpoty: Thanks for the review. Working on it.
[19:58] <sistpoty> postalchris: you're welcome ;)
[19:58] <loic-m> in rules, what's the best target to run dh_desktop, and what's the best target to install the icon and the .desktop file?
[19:58] <postalchris> A stupid small thing: lintian complains about non-ubuntu Maintainer. Is there a way to avoid that, or should I just ignore for now?
[19:59] <nhandler> Maintainer: Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[19:59] <nhandler> You can set yourself as the XSBC-Original-Maintainer
[19:59] <nhandler> postalchris: ^^^
[20:00] <postalchris> nhandler: Thanks
[20:00] <nhandler> postalchris: You're welcome
[20:01] <loic-m> Anybody knows if it's ok to put dh_desktop & install icon+desktop file in the install target?
[20:02] <piratenaapje1> nhandler: Everything should be fixed now
[20:04] <sistpoty> loic-m: that would be the place, yes
[20:04] <nhandler> piratenaapje1: I'm looking at it now
[20:05] <jacob> what day is feature freeze? for whatever reason i can't get the wiki to load
[20:05] <piratenaapje1> jacob: 19th feb
[20:06] <jacob> piratenaapje1: thanks
[20:06] <loic-m> sistpoty: thanks. On another package i worked on (e-uae) it's in binary-arch, is there a policy against that?
[20:06] <sistpoty> loic-m: none that I know of (assuming that the package is not arch:all)
[20:08] <loic-m> sistpoty: thanks. I couldn't find anything in the Debian policy manual (and arch=any)
[20:09] <sistpoty> loic-m: actually, where you put it is just convenience, as long as it ends up in the package... e.g. it makes sense to have an install target besides a build target, so that you can reuse the prebuilt sources if only install gets wrong
[20:10] <sistpoty> (ok, of course binary-indep and binary-arch are to be considered, since these are called for arch:all and arch:any packages respectively)
[20:10] <loic-m> sistpoty: thanks. btw, tuxtype is Maintainer: Ubuntu Core Developers, is there a reason for that?
[20:11] <jacob> if anyone here has free time, could you take a look at gens on revu? i still can't quite figure out what to do with the wave.c source copyrighted by microsoft but without a license. http://revu.ubuntuwire.com/details.py?upid=4683
[20:11] <sistpoty> loic-m: yes, it's in main
[20:12] <sistpoty> loic-m: apt-cache show tuxtype | grep Directory
[20:12] <loic-m> sistpoty: ok
[20:12] <sistpoty> loic-m: I assume it's in main for edubuntu, but no guarantees on that ;)
[20:13] <loic-m> sistpoty: that's a good explanation. Gotta teach teh kids to p0wn at mario kart
[20:13] <sistpoty> haha
[20:17]  * sebner winks sistpoty =)
[20:18] <sistpoty> hey sebner
[20:18] <sistpoty> sebner: how's the army?
[20:19] <sebner> sistpoty: horrible :\
[20:19] <jpds> Hey sebner.
[20:19] <pochu> hi folks!
[20:19] <pochu> sebner: are you in the army?
[20:19] <sebner> pochu: for the next 5 months, unfortunately yes
[20:19] <nhandler> sebner: What army?
[20:19] <sebner> hiya jpds
[20:19] <sebner> nhandler: Austrian army  ^ ^
[20:20] <jpds> pochu: Austrian constitution military service.
[20:29] <geser> sebner: even if it's horrible it's an experience for life :)
[20:31] <geser> sebner: use the next 5 months well so we get you back fresh and full of energy for Ubuntu development
[20:34] <sistpoty> sebner: if you ever feel that army is bad, take my experience... I had to deal with a lot of shit, literally, as I served civil service instead in an home for the aged
[20:35] <sistpoty> (otoh my gf is proud that I can change diapers *g*)
[20:38] <sistpoty> dooooomi: /me reviews pyliblo
[20:40] <piratenaapje1> nhandler: Did you got a notice I uploaded a new version?
[20:40]  * Laney paws at sebner
[20:51] <slytherin> nhandler: just realised. monajat upstream tarball does not have a LICENSE or COPYING file
[20:52] <nhandler> slytherin: Really? I could have sworn that it had one
[20:53] <slytherin> nhandler: it does not even have license headers in the source files.
[20:57] <sebner> geser: heh well, I'm not sure if I want this experience :P Ah yes, After that I'll concentrate on ubuntu dev but for now I'm only at home on weekends with not really time for anything :(
[20:57] <nhandler> piratenaapje1: What license are you trying to distribute grnotify under?
[20:57] <sebner> sistpoty: ehehe, well, If I could choose I'd take civil service now. Maybe not in a home for aged but something else ...
[20:58] <sistpoty> e
[20:58] <sistpoty> hehe
[20:58] <sebner> Laney: hmm?
[20:58] <piratenaapje1> it's supposed to be gpl-2
[20:58] <Laney> I need your kind words sebner
[20:59] <nhandler> piratenaapje1: Take a look at http://revu.ubuntuwire.com/report.py/legal?upid=4825. You are missing copyright/license headers in 2 files, and GoogleReader.py has a header saying GPL-3
[20:59] <sebner> Laney: finally wrote something about yourself? :P
[20:59] <Laney> sure did
[20:59] <Laney> it was most painful
[20:59] <sebner> heh
[20:59] <sebner> Laney: sure, I'll write something within the next hour
[20:59] <piratenaapje1> nhandler: Do those files really need a copyright header? They're just small installers
[20:59] <Laney> you star
[21:00]  * Laney emails sebner some baileys
[21:00] <nhandler> piratenaapje1: It isn't 100% necessary, but it is nice to have
[21:00] <nhandler> And since you need to fix GoogleReader.py anyway, you might as well do it
[21:01] <sistpoty> dooooomi: found only one thing: python-liblo should not have a hard-coded depends on "liblo0dlbl" but deterimine that via shlibs:Depends
[21:01] <sebner> Laney: sebner is more up to ice tee :P
[21:01] <piratenaapje1> nhandler: Ok, sure
[21:01] <sistpoty> dooooomi: others than that it looks fine for me (though I'm by far no python packaging expert)
[21:03] <sebner> Laney: ahaha! finally I can copy the structure from daniels comment \o/
[21:03] <Laney> haha
[21:03] <Laney> I want to be the first person through the new process
[21:03] <sebner> Laney: so keep pushing your sponsors to write comments ^^
[21:04] <Laney> first I have to find some.....
[21:04] <nhandler> Laney: Hopefully, you will not have to wait a month to get through the process
[21:04] <Laney> nhandler: That's the good thing about this new procedure, there's a set time for voting
[21:04] <Laney> (in an IRC meeting)
[21:05] <AndrewGee> Hi all. Any MOTUs available to review osm-gps-map - the GTK widget to embed openstreetmap? Fixed the issues that mok0 flagged up to me. Thanks :) http://revu.ubuntuwire.com/details.py?package=osm-gps-map
[21:05] <nhandler> Laney: I know. I like that. I just hope that MOTUs not listed as sponsors provide feedback still
[21:05] <Laney> yeah
[21:05] <dooooomi> sistpoty: thanks, i'll remove the dependency
[21:06] <sistpoty> dooooomi: please make sure that it indeed is still there in the resulting .deb's ;)
[21:06] <sistpoty> (via the shlibs mechanism)
[21:06] <sebner> Laney: done
[21:06] <Laney> woot
[21:07] <Laney> sebner: heh erm
[21:07] <Laney> you should have put your thing above dholbachs - as it is you chopped his stuff in half
[21:07] <Laney> but thanks \o/
[21:07] <sistpoty> AndrewGee: if you give me a few minutes to reboot (new kernel, new kde, new everything... so I guess I'll have to fiddle a bit) then I'm up for your review ;)
[21:08]  * sistpoty reboots... cya hopefully later
[21:08] <AndrewGee> sistpoty: Thanks.
[21:08] <nhandler> Laney: Do you have a link to the page where you are collecting feedback?
[21:08] <Laney> nhandler: https://wiki.ubuntu.com/IainLane/MOTUApplication
[21:08] <nhandler> Thanks
[21:10] <sebner> Laney: bah :P your work
[21:10] <Laney> I should probably update my main wiki page too
[21:10] <Laney> isn't it just amazing sebner?
[21:11] <sebner> Laney: hmm?
[21:11] <Laney> my work!
[21:11] <Laney> Bug #1 - Closed by Laney
[21:11] <sebner> lol
[21:12] <__Ali__> i used: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:debian/usr/lib/MyLib in rules, and now at the end of the build i get this:
[21:12] <__Ali__> test -x debian/rules
[21:12] <__Ali__> ERROR: ld.so: object 'libfakeroot-tcp.so' from LD_PRELOAD cannot be preloaded: ignored., dh_testroot
[21:12] <__Ali__> ERROR: ld.so: object 'libfakeroot-tcp.so' from LD_PRELOAD cannot be preloaded: ignored.
[21:12] <__Ali__> dh_testroot: You must run this as root (or use fakeroot).
[21:13] <__Ali__> i did _append_  LD_LIBRARY_PATH, what could be wrong?
[21:14] <Laney> Off to the pub, have a good evening all
[21:15] <sebner> Laney: hf
[21:15] <pochu> sebner: I think you screwed up dholbach's comment to Laney's application ;)
[21:16] <sebner> pochu: gnah :P I don't see anything =)
[21:17] <__Ali__> pochu, following your advice,  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:debian/usr/lib/MyLib, didnt help
[21:17] <pochu> sebner: "Specific Experiences of working together" and "Areas of Improvement" are part of Daniel's comment ;)
[21:17] <pochu> __Ali__: I have no clue then, sorry
[21:18] <pochu> __Ali__: maybe turn back to debhelper ;)
[21:19] <sebner> pochu: ahaha! fixed. at least I could say they belonged to my comment :P
[21:20] <pochu> hehe
[21:31] <postalchris> I'm really not understanding how to get CDBS to go from libfoo.so with SONAME=X, in the upstream build, to libfoo.so.X and libfoo.so -> libfoo.so.X, after install.
[21:31] <postalchris> I'm getting LD_LIBRARY_PATH errors from dpkg-shlibdeps, I think because of the renaming
[21:31] <pochu> what are you renaming?
[21:32] <sistpoty> who is roderick greening? how do I fix kvirc? :P
[21:33] <JontheEchidna> sistpoty: rgreening in #kubuntu-devel
[21:33] <sistpoty> thanks, JontheEchidna
[21:34] <jpds> Or in here.
[21:34] <JontheEchidna> oh, he is
[21:34] <postalchris> pochu: I mean libfoo.so to libfoo.so.X
[21:34] <ScottK> sistpoty: He's rgreening.  What's up?
[21:34] <sistpoty> rgreening: how do I fix kvirc? :P (just upgraded to the kde4 version, and all things are changed *g*)
[21:34] <sebner> sistpoty: howto fix kde :P
[21:35] <ScottK> sistpoty: It's KDE4, of course it's changed.
[21:35] <sistpoty> ScottK: all my settings are lost... and I don't recall what I did in the first place (e.g. I've got channels on the left side now in contrast to tabs with channels)
[21:35] <sistpoty> ScottK: and I recall that it was a pain to find out in the first place how to change it *g*
[21:35] <ScottK> Urgh.
[21:36] <sistpoty> ScottK: but the good news is, that its still working :)
[21:36] <ScottK> Not sure what to tell you.  Both of us tested the package before upload, but aren't either of us regular kvirc users.
[21:36] <postalchris> Error is "couldn't find library libfoo.so.X" when I've built debian/usr/lib/libfoo.so with SONAME=X and then used ${shlibs:Depends} on an executable
[21:36] <ScottK> sistpoty: If you were interested in looking after it, that would be highly useful.
[21:37] <ScottK> sistpoty: Also since they are pre- their 4.0 release, this'd be a great time to wring it out and file bugs ...
[21:37] <sistpoty> ScottK: I think it's due to the config being changed in quite some ways... not too sure if I actually do manage to track it down (kvirc's config is pretty complex)
[21:37] <dooooomi> sistpoty: the pyliblo package works fine with just the shlibs:Depends, i did a new upload
[21:37] <sistpoty> ScottK: got an (upstream) url=
[21:37] <sistpoty> s/=/?)
[21:38] <ScottK> sistpoty: Yeah, that's why we didn't seriously pursue it as a default IRC client for Kubuntu.  Far too much complexit.
[21:38] <ScottK> y
[21:38] <sistpoty> dooooomi: does the .deb have a dependency on liblio0dbl?
[21:38] <sistpoty> dooooomi: because the .so in there needs it?
[21:39] <dooooomi> sistpoty: yup, works perfectly
[21:39]  * ScottK tosses http://www.kvirc.net/ to sistpoty.
[21:39] <sistpoty> ScottK: thanks!
[21:39] <sistpoty> dooooomi: but does it have the dependency?
[21:40] <dooooomi> sistpoty: that's what i meant :) the dependency is there
[21:40] <sistpoty> dooooomi: ah... excellent!
[21:43] <ScottK> sistpoty: Feel like looking into some FTBFS?
[21:44] <sistpoty> ScottK: maybe.. but I promised a review beforehand, and am asking on #kvirc for bug-reports ;)
[21:44] <pochu> postalchris: you don't rename things, upstream build system should create the library and the symlinks
[21:46] <ScottK> sistpoty: OK.  Well I see an identical failure on PPC and lpia.  If you get a chance ... https://launchpad.net/ubuntu/+source/mesa/7.3-1ubuntu1/+build/854236/+files/buildlog_ubuntu-jaunty-powerpc.mesa_7.3-1ubuntu1_FAILEDTOBUILD.txt.gz
[21:46] <postalchris> pochu: Oh, I see. Well, it doesn't.
[21:46] <ScottK> sistpoty: I'm hoping to get KDE to build on ports and that's the current blocker.
[21:48] <sharperguy> Hi, I'm trying to build a package (python3.0) but pbuilder (aptitude) complains that it can't download libgpm2_1.20.4-3ubuntu1_i386.deb. I have tried updating my repos and even changing server. It seems to still use the old server, but when I aptitude install something else, it uses the new one...
[21:48] <sistpoty> ../../../include/GL/internal/dri_interface.h:45:17: error: drm.h: No such file or directory
[21:48] <sharperguy> The file it should be going for is libgpm2_1.20.4-3.1ubuntu1_i386.deb:
[21:48] <sistpoty> ScottK: that looks like the cause ^^
[21:49] <ScottK> sistpoty: OK.  Thanks.
[21:49] <sistpoty> ScottK: np
[21:50] <ScottK> sistpoty: If you were to get motivated to use your core-dev powers to fix that up, I'd owe you a beer ...
[21:55] <sistpoty> ScottK: not too sure If I can fix that... on what arches does it cause problems?
[21:56] <ScottK> sistpoty: I can explain the problem, but not how to fix it...
[21:56] <ScottK> The issue is that the libdrm headers moved into the kernel starting with (someversion).
[21:56] <sistpoty> ScottK: go ahead... I'd need every info that I can get ;)
[21:57] <ScottK> Only i386, amd64, and armel have a sufficient version.
[21:58] <ScottK> So a new libdrm just got uploaded that dropped a (I can't remember which, check debian/changelog) depends so libdrm-dev would be installable on these other archs.
[21:58] <ScottK> So the next step is to get mesa to build.
[21:58] <loic-m> When refering to the icon in debian/menu, can I just use the app name (and no path) as in the app.desktop file (since the icon is installed in /usr/share/pixmaps) ?
[21:59] <ScottK> The problem (I'm guessing) is that mesa needs either a new build-dep for these archs or to look somewhere else for the drm.h
[21:59] <ScottK> sistpoty: ^^ So that's my rough understanding of it.
[22:00]  * sistpoty tries to find more clues... after a smoke *g*
[22:00] <pochu> loic-m: don't think so
[22:00] <pochu> loic-m: grep icon /usr/share/menu/*
[22:00] <ScottK> So the answer to your specific question is it has or will FTBFS on anything that's not armel, amd64, or i386.
[22:00] <ScottK> sistpoty: Thanks.
[22:00] <loic-m> pochu: I don't understand the grep line purpose
[22:01] <loic-m> pochu: ok
[22:01] <pochu> do you now? :)
[22:01] <loic-m> they all have hardcoded path
[22:01] <loic-m> so i should do the same
[22:02] <pochu> yeah
[22:02] <pochu> there's a menu policy, you can check that too
[22:02] <loic-m> actually one doesn't : /usr/share/menu/qemulator:	icon="qemulator.xpm"
[22:02] <loic-m> I'll have a look
[22:02] <loic-m> in debian policy manual?
[22:03] <RainCT> oh, nice. OO.o has presentation templates with the ubuntu logo
[22:03] <loic-m> pochu: or is that a freedesktop thing?
[22:04] <pochu> loic-m: no, debian specific
[22:04] <pochu> loic-m: file:///usr/share/doc/menu/html/ch3.html#s3.7
[22:04] <loic-m> RainCT: and maybe someday the word "Ubuntu" will be added to the default dictionnaries...
[22:05] <nhandler> RainCT: You just gave me a great idea
[22:05] <RainCT> nhandler: and that is?
[22:06] <loic-m> pochu: they don't say we need to use a path in the link you gave me, just where icons are usually stored
[22:06] <mok0> RainCT, nhandler, did you guys come up with something?
[22:06] <nhandler> RainCT: I should create a presentation for the GBJ
[22:06] <pochu> loic-m: right, but every other package has the path...
[22:06] <RainCT> nhandler: what's that? :P
[22:06] <pochu> loic-m: so the safest would be to have the full path ;)
[22:06] <nhandler> RainCT: What is the GBJ?
[22:06] <loic-m> pochu: indeed
[22:06] <RainCT> nhandler: yep
[22:07] <nhandler> RainCT: Global Bug Jam
[22:07] <RainCT> ahhh
[22:07] <loic-m> pochu: are we using the menu file in Ubuntu, or is it just in Debian?
[22:08] <jpds> nhandler: There is one on the GBJ page if you want a base.
[22:10] <pochu> loic-m: there's something in Ubuntu that uses it, can't remember what it is though
[22:11] <nhandler> jpds: I'll take a look at it. The presentation there is about triaging. I still need to decide what I want to create my presentation about
[22:11] <jpds> nhandler: I might make one too for the uk one, at some point.
[22:12] <loic-m> pochu: is it like exotic desktop manager, like wmaker and others?
[22:13] <nhandler> jpds: Since I haven't been to a loco event yet, I need to talk with the team to see what they would like it to cover
[22:13] <pochu> loic-m: yeah I think that was it
[22:13] <jpds> nhandler: Which LoCo are you in?
[22:14] <loic-m> I really liked wmaker back when I wasn't using Ubuntu, then when I switched nothing in Ubuntu was integrated in it (no apps available by right clicking on the desktop)...
[22:14] <nhandler> jpds: ubuntu-chicago. I've spent time in the IRC channel, I just haven't been to a meeting
[22:33] <RainCT> uhm.. stupid question, but how can I create a sublist in OO.o? (as clicking the list button disables the already present one)
[22:33] <jpds> RainCT: Tab?
[22:36] <bdrung> vorian: the manpage of esperanza looks wrong formated
[22:37] <jpds> RainCT: Oh, use LaTeX.
[22:37] <jpds> Or*
[22:37]  * jpds ducks.
[22:43] <RainCT> jpds: heh yes, perhaps at the end it will come out that LaTeX is easier to use than OOo :P
[22:56] <__Ali__> pochu, isn't it enough to just have .install files for cdbs to actually include the binaries in the deb?
[22:57] <pochu> __Ali__: as long as you include something that calls dh_install, yes
[22:57] <sistpoty> ok, sorry for the delay... who wanted a review back then?
[22:58] <__Ali__> pochu, the log says: dh_install -plibfoo, isnt that enough? the deb is still empty
[22:59] <sistpoty> rgreening: I'm not fond of your kvirc upload btw. :P
[22:59] <sistpoty> (due to personal inconveniences rather *g*)
[22:59] <pochu> that should be ok if you didn't make mistakes :)
[22:59] <__Ali__> pochu, libfoo.instal has this line: usr/lib/MyLib/lib*.so.*
[22:59] <__Ali__> (libfoo.install)
[22:59] <pochu> __Ali__: try with debian/tmp/usr/lib/MyLib/...
[22:59] <pochu> (append debian/tmp)
[22:59] <__Ali__> ok
[23:19] <AndrewGee> Hi. Anyone available to look at giving the second advocation to osm-gps-map - A GTK widget to embed openstreetmap? http://revu.ubuntuwire.com/details.py?package=osm-gps-map