[00:00] <ajmitch> not enough people use some of these packages or hit the appropriate code paths to trigger the bug yet, I guess
[00:00] <ScottK> No doubt.
[00:00] <ScottK> Sounds like SRU material at this point in any case.
[00:01] <ajmitch> probably, but a patch needs to be found before we can even consider that
[00:01] <ajmitch> RC is tomorrow, isn't it?
[00:01] <zooko> Does anyone know what patch in Python changed the behavior of the __doc__ property?
[00:02] <directhex> okay, i give up. is it actually possible to change timezone on karmic? changing it in Administration/Time and Date doesn't help - it'll always be shown as blank next time you run it
[00:02] <lifeless> zooko: how was it changed?
[00:03] <ajmitch> zooko: the impression I got was that it's an upstream change, I haven't looked for it though
[00:03] <ScottK> ajmitch: Yes.  Tomorrow.
[00:04]  * ScottK keeps filing removal bugs ...
[00:05] <zooko> lifeless: https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 claims that Python 2.6.3 (upstream) changed the behavior of the __doc__ property compared to Python 2.6.2.
[00:05] <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/457688)
[00:05] <zooko> Since the Python upstream folks are currently working on putting out a 2.6.4 whose raison d'etre is to undo regressions that were introduced in Python 2.6.3, I thought they should know.
[00:06] <ajmitch> closest I can find in 2.6.3 release notes is http://bugs.python.org/issue5890
[00:06] <lifeless> zooko: ugh
[00:11] <ajmitch> lifeless: I heard you'll be visiting chch for pycon soon?
[00:12] <zooko> ajmitch: thanks
[00:14] <lifeless> ajmitch: yup
[00:15] <ajmitch> it should be a good weekend, even sold out ahead of deadline
=== milli` is now known as milli
[00:55] <zooko> Okay Barry Warsaw says he thinks this isn't a regression in Python, as in its instead a bug in Boost.
[01:36] <ajmitch> zooko: thanks, useful to know :)
=== freeflyi3g is now known as freeflying
=== nxvl_ is now known as nxvl
=== milli is now known as milli`
=== RoAk is now known as RoAkSoAx
=== ripps_ is now known as ripps
=== ara_ is now known as ara
[07:48] <wrapster> geser: please look at this issue.. its the same thing that i've put up yday.. but now i actually tried adding the -L/usr/lib/amd64 to SunOS5.11_i86pc.mk file(it does exist) but still no changes.. I cannot see it in the cmd line.. is there a way you can tell me where I need to look for it?
[07:51] <wrapster> geser: my mistake.. didnt read it welll.
[07:51] <wrapster> sorry
[08:40] <secret901> Why is Songbird not installable via Synaptic?
=== quadrispro1 is now known as quadrispro
[08:48] <wrapster> the -L option in gcc is used to tell where the libs are going to be placed right? -L/usr/lib , implies that all the generated libs will be placed in the /usr/lib dir?
[08:51] <soren> wrapster: No.
[08:51] <wrapster> then?
[08:51] <soren> wrapster: gcc is just the compiler. It doesn't install anything anywhere.
[08:54] <wrapster> oh yeah... sorry about that...
[08:54] <wrapster> got confused.
=== proppy1 is now known as proppy
[10:39] <Hew> Hi MOTU's. Nexuiz 2.5.2-1 has just been packaged by Debian. This is a major change over 2.4.2-1 which has been in Ubuntu since Intrepid. It's unfortunate that this has happened so late in the cycle, but I just wanted to check if there is still any chance in getting a sync to Ubuntu. Bug 355854.
[10:39] <ubottu> Launchpad bug 355854 in nexuiz "Please upgrade to nexuiz 2.5.2" [Wishlist,In progress] https://launchpad.net/bugs/355854
[10:41] <Laney> Hew: apparently we are easy with FFes for games
[10:42] <Laney> subscribe the release team
[10:43] <Hew> Laney, that is excellent news! I will do a FFe and subscribe them now, thanks.
[10:43] <Laney> Hew: it doesn't look like the data has been packaged though
[10:44] <Laney> # nexuiz/i386 unsatisfiable Depends: nexuiz-data (>= 2.5.2)
[10:44] <Hew> hmm ok, I guess I'll keep watching out for that one
[10:45] <Laney> you can ask the debian games team if you like
[10:50] <Hew> sebner, do you know what the situation is with nexuiz-data, and what the chances are of getting Nexuiz 2.5.2 into Karmic?
[11:27] <geser> Hew: see bug #457522
[11:27] <ubottu> Launchpad bug 457522 in nexuiz-data "[FFe] Please sync nexuiz-data 2.5.2-1 from Debian(Unstable)" [Wishlist,New] https://launchpad.net/bugs/457522
[11:27] <geser> and bug #457525
[11:28] <ubottu> Launchpad bug 457525 in nexuiz "[FFe] Please sync nexuiz 2.5.2-1 from Debian(Unstable)" [Wishlist,New] https://launchpad.net/bugs/457525
[11:28] <Laney> that exists?
[11:28] <Laney> pts must be lagging then
[11:35] <Lazy> sorry to bother you guys but is there a chance to get bug #372040 fixed before final?
[11:35] <ubottu> Launchpad bug 372040 in electricsheep "Request Package of electricsheep 2.7 due to 2.6 EOL" [Medium,Confirmed] https://launchpad.net/bugs/372040
[11:35] <Lazy> it should be simple sync from debian
[11:42] <siretart`> Hew: nexuiz has not been even ACCEPTED yet in debian
[11:42] <siretart`> (the uploader is sitting behind me...)
[11:43] <Laney> what did sebner build?!
[12:07] <amarillion> Is there documentation somewhere on packaging & mime type registration?
[12:07] <amarillion> Or: how do I let my package register a mime-type?
[12:34] <hyperair> amarillion: apt-get source something which registers a mime type?
[12:34] <hyperair> http://www.debian.org/doc/packaging-manuals/mime-policy/ch2.html
=== Zhenech_ is now known as Zhenech
[12:50] <amarillion> hyperair, ok thanks, but that page basically refers to "man update-mime", and that man page is really very terse
[12:50] <hyperair> right
[12:50] <amarillion> I guess there isn't a nice document with examples anywhere
[12:50] <hyperair> take a look in /usr/lib/mime/packages/
[12:52] <amarillion> Ok, that helps too. I'll give it a try
[13:26] <sebner> Laney: hmm?
[13:26] <Laney> sup
[13:27] <sebner> Laney: <Laney> -what did sebner build?!
[13:27] <Laney> oh, that data package which hasn't been uploaded yet
[13:27] <Laney> well *now* it has ;)
[13:28]  * sebner lives in the future :P
[13:29] <sebner> Laney: I used the orig tarball and the debian folder from svn trunk (which is the same folder as the regular package upload. no changes would have been made so I used that)
[13:30] <Laney> kk
[13:32] <sebner> Laney: -data should have appeared yesterday though but 967MB is not something you can upload in some minutes ^^
[13:32] <Laney> poor mirrors :(
[13:35] <sebner> heh
[13:44] <Teddy_> Security bug #551907 needs some love.  A patch exists. (It is fixed upstream and is waiting for a sponsor in Debian.)
[13:44] <ubottu> Error: Launchpad bug 551907 could not be found
[13:45] <Teddy_> Dang
[13:45] <Teddy_> Security bug #457709  needs some love.  A patch exists. (It is fixed upstream and is waiting for a sponsor in Debian.)
[13:45] <ubottu> Launchpad bug 457709 in mandos "mandos-client adds unnecessary files to initrd" [Undecided,Fix committed] https://launchpad.net/bugs/457709
[13:45] <james_w> debian bug 551907
[13:45] <ubottu> Debian bug 551907 in mandos-client "mandos-client adds unnecessary files to initrd" [Critical,Open] http://bugs.debian.org/551907
=== MTecknology is now known as MTeck-ricer
=== ghostcube_ is now known as ghostcube
[16:04] <rhpot1991> siretart: ping, I hate to bother you about ffmpeg again but there seems to be a pretty big issue where it fails to encode mp3 as well
[16:04] <rhpot1991> https://bugs.launchpad.net/ubuntu/+source/lame/+bug/401406
[16:04] <ubottu> Launchpad bug 401406 in lame "[Karmic] libmp3lame fails in converting audio" [Undecided,Confirmed]
[16:04] <rhpot1991> https://bugs.launchpad.net/ubuntu/+source/lame/+bug/439083
[16:04] <ubottu> Launchpad bug 439083 in lame "MP3 audio encoding fails with "output buffer too small" using ffmpeg (dup-of: 401406)" [Undecided,New]
[16:14] <wrapster> geser: http://pastie.org/665167 i still get that issue..
[16:15] <wrapster> geser: could you please look at the cmd line .. i tried with -L/usr/lib/amd64
[16:15] <wrapster> geser: yet the same issue.. pls help
[16:17] <jfcgauss_> hi. on ubuntu 9.04 having apache2-worker installed, please check out the output of
[16:17] <jfcgauss_> ldd -r -u /usr/lib/apache2/modules/mod_* 2>&1 | grep -v 'undefined symbol:\|lookup error:\|direct dependencies:\|^$'
[16:18] <jfcgauss_> there are some unnecassary dependencies of apache2 modules
[16:28] <TheOpenSourcerer> Am I completely daft to want to try and package FreePBX for Ubuntu?
[16:29] <TheOpenSourcerer> There are some instructions for building debs here: http://www.freepbx.org/v2/wiki/DebPackages but I wonder why no-one has done it before.
[16:30] <zul> jfcgauss_, please open a bug in launchpad thanks
[16:41] <geser> wrapster: this is from the 32bit build or from the 64bit build?
[16:41] <wrapster> from the 64bit build.
[16:41] <wrapster> geser: one moment i'll paste the rules file.
[16:43] <geser> wrapster: I wonder about the "i386 output" at the end of the line. I've no experience with cross-building but it looks like it wants to build an i386 lib instead of a amd64 lib
[16:43] <wrapster> geser: http://pastie.org/665203
[16:44] <jfcgauss_> im logged in, but somehow failed to find "File new bug" link on https://bugs.launchpad.net/, not my 1st bug report. did something change :?
[16:44] <wrapster> could that be an issue with the flags being set.. I mean originally they were for 32 so flags set appropriately..
[16:44] <geser> wrapster: have you managed to build the 64bit lib by hand? just take the source, do what's needed to get it build and don't look at packaging yet
[16:45] <wrapster> geser: no..
[16:45] <wrapster> i have not done that yet...
[16:45] <wrapster> i have the sources though.
[16:45] <geser> once you know how to get it build successfully you can think about how to package it
[16:46] <wrapster> so shall i just yank everything out for 32bit and only do the 64bit ones. first
[16:47] <geser> wrapster: yes, but you don't need to touch the packaging for it at all, just take a copy of the source and call make (with the needed variables, etc.) on it
[16:47] <jmarsden> jfcgauss_: Yes, things changed.  See https://help.ubuntu.com/community/ReportingBugs
[16:47] <wrapster> ok..
[16:47] <wrapster> make in the sense how?
[16:47] <wrapster> should i go into each dir and run make
[16:48] <geser> important is only that you know that you can successfully build a 64bit lib
[16:48] <wrapster> or make -f debian/rules
[16:48] <wrapster> something like that?
[16:49] <geser> just take the make call from your rules files (make -C mozilla/security/nss nss_build_all MOZILLA_CLIENT=1 ...)
[16:50] <wrapster> ok
[16:51] <geser> like you would build it without packaging (for installing it in /usr/local), but just the compiling
[16:51] <geser> once you know how you can build it you can start thinking what you need to put into debian/rules
[16:54] <quidnunc> Is there a way to get a list of all the packages that have a given package depends on?
[16:54] <quidnunc> Sorry, I mean to say:
[16:55] <quidnunc> Is there a way to get a list of all the packages that have a given package as a dependency?
[16:55] <geser> apt-cache rdepende $pkgname
[16:55] <geser> rdepends
[16:56] <quidnunc> thanks
[16:56] <jfcgauss_> just filed https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/458274
[16:56] <ubottu> Launchpad bug 458274 in apache2 "unnecassary dependencies of apache2 modules" [Undecided,New]
[16:56] <wrapster> geser: interesting..
[16:56] <jfcgauss_> thx
[17:04] <jpds> highvoltage: -meeting? :)
[17:10] <bddebian> Heya gang
[17:11] <bddebian> sistpoty|work, av`, ScottK, iulian: Thanks for lordsawar!
[17:11] <sistpoty|work> hi bddebian, and thanks to you for it :)
[17:11] <ScottK> bddebian: No.  Thank you for your contribution to Ubuntu.
[17:12] <Laney> wicked
[17:12] <Laney> you sexy beast bddebian!
[17:12] <bddebian> Heh, heya Laney
[17:13] <Laney> alreet
=== milli` is now known as milli
[17:50] <imbrandon> morn folks
[18:11] <av`> bddebian, np ;)
[18:15] <wrapster> geser: thanks for your help i was able to narrow down much further...http://pastie.org/665359
[18:15] <wrapster> geser: i still have errors though
[18:16] <wrapster> geser: i dont quite understand what that means.. is it unablet to use the plc4 libraray? for 64bit or something?
[18:18] <geser> wrapster: yes, it wants to try to link your 64bit .o files to 32bit libs, this won't work. You need a 64bit variant of plc4 and use the correct values for -L as I assume /lib/ and /usr/lib holds the 32bit libs
[18:18] <wrapster> ok will look for it in /usr/lib/amd64 one moment
[18:19] <wrapster> there is no plc4 version of it.
[18:19] <geser> so you need to first build a 64bit variant of libpcl4 before you can continue here
[18:20] <geser> the same applies for libplds4, libnspr4, libthread, libnsl, libsocket, libposix4, libdl and libc
[18:21] <wrapster> yeah apparenlty dpkg -S libplc4 ---> nspr4,nspr4-0d so i guess i need the 64bit variants.
[18:22] <wrapster> geser: i cant find this pkg on http://packages.ubuntu.com/ (hardy) weird
=== jono is now known as crimsun
=== crimsun is now known as jono
[18:24] <geser> wrapster: it's there: http://packages.ubuntu.com/hardy/libnspr4-0d
[18:24] <wrapster> also could you tell me the difference between libnspr4 and libnspr4-0d
[18:24] <wrapster> what does that 0d and 1d mean?
[18:25] <geser> it's the library version
[18:26] <wrapster> ok but how do i know if its the 64bit or the 32 one.. coz i have nspr4/4-0d/4-dev installed
[18:26] <wrapster> yet this is cribbing.
[18:27] <geser> you can ask "file" what it thinks about a file, but unless you (or someone else) made a 64bit variant of this package, I assume it's 32bit only
[18:27] <wrapster> hmm
[18:28] <wrapster> ok so i need to compile the 64bit ones for all these.. OMG
[18:28] <micahg> wrapster: are you trying to install flash?
[18:28] <wrapster> no
[18:29] <micahg> ok
[18:29] <geser> wrapster: yes, you need them all to build libnss in 64bit (I didn't check how many different source packages that are)
[18:30] <wrapster> geser: ok i'll do it.
[18:31] <geser> wrapster: do you have a libc alread in /usr/lib/amd64?
[18:31] <wrapster> yeah
[18:31] <wrapster> libc.so / .so.1
[18:32] <geser> at least something
[18:33] <wrapster> anything i can do?
[18:33] <frandieguez> Sorry for the noise... but when karmic rc will be released?
[18:33] <joaopinto> frandieguez, support for karmic is on #ubuntu+1 :P
[18:33] <geser> wrapster: repeat your work for nspr
[18:34] <geser> wrapster: the needed libs come from nspr and the libc package (I hope if you have a libc.so.1 in 64bit that you have also the other libs from it in 64bit)
[18:35] <wrapster> yeah libc.so.1 is there.. i'll first start with nspr now..
[18:35] <wrapster> hope it compiles cleanly!!
[18:53] <wrapster> -I/usr/lib/amd64 to include the libs right...
[18:56] <geser> -L but yes
[18:59] <wrapster> geser: yeah thats the only issue i guess. coz it came upto dpkg_shlibdeps: then failed as it cannot locate libc.so.1(64bit)
[19:04] <MTeck-ricer> I'm trying to remember the name of an app that shows all processes in rc in a table type display so you can enable/disable them - any ideas what that's calls?
[19:06] <geser> wrapster: check if there is an option to tell dpkg_shlibdeps also into other dirs for libs
[19:13] <wrapster> geser: snip from  man dh_shlibdeps
=== rmcbride_ is now known as rmcbride
[19:13] <wrapster> -ldirectory[:directory:directory:..]  With recent versions of dpkg-shlibdeps, this option is generally not needed. Before dpkg-shlibdeps is run, LD_LIBRARY_PATH will have added to it the specified directory (or directories --   separate with colons). With recent versions of dpkg-shlibdeps, this is mostly only useful for packages that      build multiple flavors of the same library, or other situations where the library is installed into a direc-    
[19:13] <wrapster> so i did dh_shlibdeps -a -l/usr/lib/amd64 -->still fails
[19:15] <geser> hmm
[19:15] <wrapster> i think i should probally look at LDFLAGS and see where -L is coming from and add this tehre..
[19:15] <wrapster> but thats a daunting task ...
[19:16] <wrapster> btw im just curious to know one thing.. are these pkgs that insignificat that there are no 64bit versions of it?
[19:16] <wrapster> beg to differ :)
[19:18] <soren> wrapster: Which packages?
[19:18] <wrapster> libnspr
[19:19] <wrapster> libnss
[19:19] <soren> I've told you already. there are 64 bit versions of them.
[19:20] <geser> soren: he is building for nexenta
[19:20] <geser> and tries to generate a package with i386 and amd64 libs
[19:20] <soren> In the same package?
[19:21] <geser> yes, cross-compiling on i386
[19:21] <geser> similar to what we do it some amd64 package (e.g. libz) but the other way around
[19:21] <soren> Sounds like... uh... "fun".
[19:22] <wrapster> soren: thanks
[19:22]  * soren know next to nothing about nexenta, but..
[19:22] <soren> Does all packages need to build this way?
[19:22] <wrapster> geser: if i do finish this up.. im going to throw a virtual party exclusively to you... you only
[19:23] <wrapster> soren: no.. a few of them thats all...
[19:23]  * jdong is curious how virtual parties are supposed to work :)
[19:23] <wrapster> jdong: i dont know :P
[19:23] <soren> wrapster: Why is that? Why does nss need to?
[19:23] <wrapster> geser: but till then pls stick around and help me!!!!
[19:24] <wrapster> soren: nss (which i want in 64bit) had a dep on .so thats generated out of nspr.
[19:24] <wrapster> so nspr need to be built with 64 first to get that version of .so
[19:24] <wrapster> then i can use it
[19:25] <soren> But why do those two need to be built this special way?
[19:31] <wrapster> coz i dont have the 64bit flavors of em
[19:31] <geser> what you need them for?
[19:32] <geser> or more precisely the libnss one
[19:47] <wrapster> geser: this seems to never end... i managed to get over libc.so.1 now it says libgcc_s.so.1 is not availble...
[19:48] <geser> wrapster: who said that cross-compiling is easy?
[19:48] <wrapster> its interesting as its neither in /usr/lib nor in /usr/lib/amd64
[19:49] <soren> wrapster: Why do you (and only you) need 64 bit versions of libnss (and its dependencies) (and not every single other library and application)?
[19:52] <wrapster> soren: its not that way.. apparently there are a few things that we need to replace as we are using 3rd party stuff and nss/nspr fit the bill...
[19:52] <wrapster> i know its very very vague but thats all i can discuss.. Im sorry.
[19:59] <wrapster> geser: ok nspr was successfully built.. but with some external hacking..
=== sbasuita_ is now known as sbasuita
[19:59] <wrapster> I needed to set the LD_LIBRARY_FLAGS=/usr/lib/amd64:/lib/amd64
[19:59] <wrapster> but unable to find it within the pkg and see where I need to actually put it...
=== asac_ is now known as asac
[20:21] <siretart> rhpot1991: pong. please elaborate
=== funkyHat is now known as funkyHatHat
[20:25] <rhpot1991> siretart: if you look at the bugs I pasted they pretty much sum it up, trying to encode with libmp3lame causes a failure
[20:25] <rhpot1991> if you attempt to encode a video, it will encode the video itself, but then fail to encode the audio leaving you with corrupted videos
[20:26] <siretart> rhpot1991: comment #2 and #3 indicate that the issue is rather cosmetic
[20:27] <rhpot1991> siretart: thats not the case when I comes to video, I'm not sure if you are only doing audio
[20:27] <rhpot1991> s/I/it/
[20:27] <siretart> I see, but you say that installing the jaunty package in karmic fixes the issue, right?
[20:28] <rhpot1991> siretart: I have not tried that yet, wanted to ping you first to get an opinion
=== funkyHatHat is now known as funkyHat
[20:33] <rhpot1991> siretart: installing and testing now
[20:51] <siretart> rhpot1991: seems that marillat has some patches that might be worth trying out
[21:04] <ScottK> TheMuso: PowerPC seems to be doing reasonably well.  We have a Power PC live CD for Kubuntu right now.
[21:05] <sebner> ScottK: thanks for the ACKs :)
[21:05] <ScottK> sebner: No problem.  Thanks for working on it.
[21:05] <ScottK> Plenty of room for more FTBFS fixes everyone....
[21:17] <ximion> hi! I have a short question about library packaging:
[21:17] <ximion> I created a package project-core which contains a shared library and an essential binary, which is used by other tools of this project and uses the library itself. The lib is used in nearly every part of the project I package, but it can also be used by other tools. Now I get the lintian warning to rename project-core to match the library name. It is a bad idea to package a lib with data like images. Is it allowed to package a shared
[21:17] <ximion> lib with binary programs?
[21:41] <geser> don't know if it's allowed, but it's a bad idea. what will you do if the API/ABI of the lib changes?
[21:42] <rhpot1991> siretart: that would be great, is that something you can get together and I can test for you, or what is the course of action?
[21:43] <siretart> rhpot1991: please test http://wiki.tauware.de/~siretart/upload-queue/libmp3lame0_3.98.2%2bdebian-0ubuntu2_i386.deb
[21:43] <siretart> rhpot1991: and report back to the bug, I can upload tomorrow then
[21:43] <siretart> need some sleep now, good night
[21:43] <rhpot1991> siretart: any chance you have an amd64 build?
[21:43] <rhpot1991> if not its ok I'll get this dev box ready to go
[21:44] <siretart> I've placed the source package in the same directory, you can build it yourself
[21:44] <rhpot1991> ok thanks
[21:44] <siretart> http://wiki.tauware.de/~siretart/upload-queue/lame_3.98.2%2bdebian-0ubuntu2.dsc
[21:44] <xzachtmx> Hi guys i think this is the place to ask a question i have... I am interested in contributing to ubuntu.  I have been using ubuntu for a while now and i have experience with programming with things such as python and c++ to make little applications as well as web applications.  So i think i can call myself technical.  Is debian packaging a good place to start?
[21:44] <rhpot1991> good night, and thanks for looking into it
[21:44] <siretart> xzachtmx: see the channel topic
[21:45] <xzachtmx> Ok
[22:10] <ximion> geser: Thanks, I will make separate packages
[22:27] <TheMuso> ScottK: Right, although ubiquity is currently broken due to some weird toolchain stuff. Colin/myself have fixes lined up to go into final, that will make things work.
=== tag_ is now known as tag
[22:55] <ScottK> TheMuso: Great to hear.  It seems like the power pc port is looking up the last few cycles.
[22:57] <TheMuso> ScottK: Yeah, which is a good thing.
=== goshawk_ is now known as goshawk
[23:10] <Kmos>  3