[07:01] <dholbach> good morning
[08:16] <iulian> Morning dholbach.
[08:16] <dholbach> hi iulian
[08:29] <dupondje> Could somebody try to create a chroot with pbuilder-dist? It fails here all the time :(
[08:37] <jtaylor> can someone set 791318 to triaged please
[08:40] <iulian> Done.
[08:44] <jtaylor> thx
[08:55] <nigelb> How do I do a += for Cmake's configuration file?
[08:58] <jtaylor> list(APPEND VAR VALUE)
[09:00] <nigelb> I did the CFLAGS change, but I just made it a LIB enry instad of adding it to an existing lib entry
[09:15] <nigelb> bah, doing an append didn't fix it :/
[09:17] <nigelb> This is the CmakeList.txt file http://dpaste.com/563212 and http://dpaste.com/563213 is my patch
[09:17] <nigelb> what am I doing wrong?
[09:25] <jtaylor> shouldn't it go in target_link_libraries?
[09:25] <nigelb> oh.
[09:25] <nigelb> that I didn't know
[09:27] <dupondje> W: Failure trying to run: chroot /var/cache/pbuilder/build/22485/. dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-0ubuntu13_amd64.deb
[09:27] <dupondje> E: debootstrap failed
[09:28] <dupondje> can't even seem to create a natty pbuilder-dist env :(
[09:28] <nigelb> (maybe a dumb question), is your OS is i386 or amd64
[09:28] <nigelb> -is
[09:29] <jtaylor> <amd64
[09:54] <nigelb> This build failure has other problems.
[09:54] <nigelb> I fixed one library call.
[09:54] <nigelb> Seems like more needs fixing
[10:01] <tumbleweed> dupondje: I can create a oneiric pbuilder just fine (on oneiric). What are you running?
[10:08] <nigelb> tumbleweed: heya, you work on ubuntu-dev-tools right?
[10:09] <tumbleweed> nigelb: yip
[10:10] <nigelb> tumbleweed: want to quickly talk about it (5 minutes) during Ubuntu Developer Week lighting talks?
[10:10] <nigelb> (Its mostly project lightning talks, so any interesting package/project gets good visibility)
[10:12] <tumbleweed> nigelb: sure, can do
[10:13] <sagaci> packaging-dev sounds good too
[10:13] <nigelb> tumbleweed: awesome, its at friday 15th at 2000 UTC
[10:14] <nigelb> well, some time between 2000 and 2100 UTC :D
[10:14] <tumbleweed> we are trying to get the interesting bits *out* of ubuntu-dev-tools where possible, but that's no reason not to talk about it :)
[10:14] <nigelb> tumbleweed: heh, was it you that told at the session about someone filing a bug against ubuntu dev tools for a tool that was already in it?
[10:14] <nigelb> *UDs session
[10:14] <nigelb> argh! *UDS
[10:15] <tumbleweed> yeah, this happens :)
[10:15] <nigelb> heh
[10:15] <tumbleweed> (don't know if that was me, though)
[10:15] <nigelb> It was either you or benjamin
[10:16] <nigelb> This is my CMakeList.txt file http://dpaste.com/563236/ (patched), some libs are still not linked, most notably dbus. How do I go about doing that?
[10:18] <nigelb> Do I add openssl and dbus-1 after the ldap entry in TARGET_LINK_LIBRARIES?
[10:22] <tumbleweed> nigelb: don't know what package you rae working on (and I haven't messed with this stuff in cmake), but libldap isn't linked to openssl or dbus
[10:23] <nigelb> tumbleweed: its pathfinder, and I should have been more clearer.
[10:23] <nigelb> One of the .o files depend on libldap, openssl and dbus
[10:23] <nigelb> I got the ldap bit works now after I added it in line 107, but I 'm trying to figure out how to add openssl and dbus
[10:24] <tumbleweed> I don't think order will matter here
[10:24] <nigelb> not order, just what to put there
[10:24] <nigelb> I tried openssl, it failed just now
[10:25] <nigelb> I tried putting ${OPENSSL_LIBDIR} which failed too
[10:25] <tumbleweed> try libcrypto rather than openssl. it's a separate .pc file
[10:26] <nigelb> ah
[10:27] <dupondje> tumbleweed: pbuilder-dist and pbuilder, both are broken here :s
[10:27] <dupondje> debootstrap is mounting /proc in the chroot, but doesn't seem to umount it.
[10:28] <tumbleweed> yeah, I saw you saying that. What Ubuntu release areyou on?
[10:28] <dupondje> Oneiric
[10:28]  * tumbleweed is wondering why I'm not seeing this
[10:29] <dupondje> tried making a oneiric chroot on natty, and that works fine also (other computer)
[10:29] <dupondje> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631087 btw
[10:29] <dupondje> some people in debian have same issue
[10:29] <dupondje> wonder why
[10:30] <tumbleweed> ah well, at least you have a workaround, and we can wait for someone else to get to the bottom of it :)
[10:31] <tumbleweed> nigelb: hrm, the libcrypto.pc is just a subset of openssl. Dunno if that'll help then
[10:32] <nigelb> tumbleweed: I think I'm doing something wrong with linking. I'm just not sure enough
[10:32] <dupondje> well yea :) but can't access the other pc all the time :)
[10:33] <tumbleweed> dupondje: you can copy the base.tgz across, you only need to build it once
[10:34] <dupondje> ah true
[10:35] <dupondje> could do that indeed
[10:35] <dupondje> best thing would be getting it fixed ofc :D
[10:35] <dupondje> but debootstrap got like no debug option :(
[10:37] <jtaylor> please set 803204  to triaged
[10:38] <tumbleweed> thanks
[10:39] <nigelb> tumbleweed: nope, didn't work :)
[10:39] <nigelb> I'm trying some stuff with INCLUDE_DIR
[10:39] <nigelb> It said it can't find that lib the last time
[10:40] <nigelb> the openssl and dbus ones
[10:42] <nigelb> aha
[10:42] <nigelb> How do I fix "/usr/bin/ld: cannot find -lopenssl"?
[10:43] <tumbleweed> that's wrong. It's not called libopenssl
[10:44] <nigelb> so, when I link from the commandline, I do -llibopenssl?
[10:44] <jtaylor> no  -lssl
[10:44] <nigelb> ah
[10:44] <tumbleweed> thanks jtaylor, *not* called libopenssl :)
[10:44] <nigelb> Its probably called libopenssl but not linked that way
[10:45] <nigelb> what's the easiest way to figure that out without installing and doing a dpkg -S?
[10:45] <jtaylor> apt-file
[10:46] <nigelb> thanks jtaylor!
[10:46] <Laney> you have to install it to test build anyway?
[10:46] <nigelb> that's inside the pbuilder
[10:46] <nigelb> I should install the pbuilder hhoks
[10:47] <dupondje> ah well
[10:47] <dupondje> https://bugs.launchpad.net/debian/+source/debootstrap/+bug/805886
[10:47] <dupondje> :)
[10:47] <Laney> I usually log in for non-final builds
[10:47] <Laney> to the chroot
[10:48] <tumbleweed> pbuilder + the C10shell hook is nice for debugging failures
[10:50] <tumbleweed> nigelb: no, it's called libssl (and there's also libcrypto, which is what this build failed on, on the buildd) If a package has a .pc file, you can find out a lot of useful information in it, look at /usr/lib/pkgconfig/openssl.pc
[10:50] <nigelb> tumbleweed: I should have known that. This CMake fle is usint the .pc files
[10:51] <tumbleweed> you sure? I swear I sawe some PKGCONFIG things in the file you pasted
[10:51] <nigelb> tumbleweed: erm *is* using
[11:09] <nigelb> ok, I give up. I thought I fixed this by adding ssl, but that didn't fix it either :/
[11:16] <jtaylor> please set to triaged: 803191
[11:17] <tumbleweed> jtaylor: done. (you can assume I'll notice bugs I filed)
[11:34] <nigelb> Ah, I got confused because this failure is not just an --as-needed failure because of library ordering
[11:35] <nigelb> there is some problem with indiin
[11:35] <nigelb> er, indirect linking
[11:36] <nigelb> oh, well, its the same
[11:43] <nigelb> Ah, quilt. is there a way to un-"add" a file?
[11:45] <tumbleweed> nigelb: that's not something you should need to do. adding a file just means quilt will notice changes when you quilt refresh
[11:45] <tumbleweed> if you haven't made any changes, there's nothing for it to notice
[11:46] <nigelb> tumbleweed: I made a mess, but now undone :P
[11:48] <tumbleweed> well, that's easy, refresh and pop the patch, then edit the patch to remove the changes you don't want and push it again
[11:48] <Laney> there's quilt revert
[11:48] <nigelb> After one scary day playing with the patches themselves, I tend to not edit it directly
[11:48] <nigelb> I forced a push
[11:49] <nigelb> s/push/pop
[11:49] <nigelb> then undid my change
[11:49] <tumbleweed> Laney: ah, even easier
[11:49] <nigelb> forced a push, forced a pop and refreshed
[11:49] <nigelb> Laney: I er accidentally made a change, then added, undid my change and refreshed
[11:50] <nigelb> causing a change opposite of what I wanted to happen
[11:50] <tumbleweed> recountdiff is handy if one does invasive patch etids
[11:51] <nigelb> bah, this still doesn't work :/
[11:51] <Laney> ipatch too for patch editing
[11:51] <nigelb> I did a include <ssl.h> and did -lss
[11:51] <nigelb> *-lssl
[11:51] <nigelb> it is indeed failing at ssl related functions
[11:52] <tumbleweed> Laney: err never heard of that. googling it turns up some OSX thing
[11:53] <tumbleweed> nigelb: if I'm reading it correctly, the failure in the build log from the test rebuild is a missing libcrypto not libssl
[11:54] <tumbleweed> ah, but the cmake file was linking to ssl too. nm
[11:54] <nigelb> isn't crypto provided by ssl?
[11:54] <tumbleweed> yes, but they are separate libraries, dpkg -L libssl1.0.0
[11:55] <Laney> http://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html
[11:55] <nigelb> what does Libs.private mean in the .pc file?
[11:56] <jtaylor> libraries only needed for static builds
[11:56] <jtaylor> no symbols of these libraries are exported
[11:56] <tumbleweed> Laney: oh right, I remember seeing that
[11:56] <nigelb> Now, I'm confused whether to swap -ssl with -crypto because its listed as Libs.private
[11:56] <Laney> useful to have around
[11:57] <tumbleweed> nigelb: Libs.private is not relevant to this problem
[11:57] <nigelb> tumbleweed: oh. swapping.
[12:04] <nigelb> tumbleweed: exact same failure :(
[12:04] <tumbleweed> nigelb: you probably want to turn up the verbosity so you can see what the gcc arguments are
[12:05] <nigelb> Is that a CMake setting?
[12:06] <nigelb> ah, yes
[12:11] <nigelb> My linking is working apparently http://dpaste.com/563276/
[12:12] <nigelb> wait a minute, there are some libs there, where did they come from :|
[12:13] <tumbleweed> nigelb: wrong order, -ssl should be before -crypto
[12:13] <nigelb> tumbleweed: ah
[12:13] <nigelb> tumbleweed: aaaaah, bit by the bug I'm trying to fix. The irony
[12:19] <nigelb> tumbleweed: similar failure again
[12:19] <nigelb> (On another note, I've jut built this package 15 times today now :D)
[12:19] <nigelb> *tried to build
[12:21] <jtaylor> tumbleweed: delay merging gps, I made a typo
[12:25] <jtaylor> stupit bzr ._.
[12:36] <jtaylor> so now its ready
[12:44] <tumbleweed> jtaylor: thanks
[12:54] <nigelb> tumbleweed: I figured out what the problem is and I haev a hacky fix.
[12:54] <nigelb> The CFLAGS are loading a few -l calls.
[12:54] <nigelb> My hacky fix would be to just copy paste them over
[12:54] <nigelb> I don't see an easier solution
[13:05] <tumbleweed> nigelb: can you not fix it to not use CFLAGS for libraries?
[13:06] <nigelb> tumbleweed: I'm not sure how.
[13:08] <tumbleweed> nigelb: debdiff so far?
[13:08] <nigelb> tumbleweed: sec
[13:10] <nigelb> tumbleweed: http://dpaste.com/563289/
[13:30] <jtaylor> gna another libtool package making problems -.-
[13:30] <jtaylor> how I hate that thing
[13:34] <jtaylor> is this wrong? libc_urg_la_LDADD = -lm
[14:00] <debfx> ScottK: could you please ack bug #805962
[14:01] <ScottK> debfx: Done.
[14:01] <debfx> thanks!
[14:06] <jtaylor> while your at it, how about bug 798191?
[14:06] <micahg> jtaylor: that has a lot of rdepends
[14:08] <micahg> jtaylor: http://paste.ubuntu.com/638440/
[14:10] <jtaylor> to my knowledge no package needed changing when it transitioned in debian
[14:10] <micahg> jtaylor: yes, but a requirements for backports is that all rdepends get tested
[14:11] <jtaylor> hm, ok then its hopeless
[14:11] <micahg> jtaylor: why?  there aren't that many on the list...
[14:12] <jtaylor> ~140 rdeps not many?
[14:12] <micahg> jtaylor: there are a lot of dupes in that list :)
[14:12] <jtaylor> I don't care so much for that package that I will test them all ..
[14:12] <micahg> maybe the other person who commented in the request would be willing to
[14:13] <Laney> I do wonder if that requirement is too stringent
[14:14] <Laney> that's no way what happens when updating to a new revision in a developent release, for eample
[14:14] <Laney> (testing all rdeps)
[14:16] <micahg> Laney: yes, but with the dev release, there's an assumption that bugs will be caught, in stable the rules are more stringent, we don't want to break systems
[14:17] <Laney> I know why it's there
[14:34]  * micahg will update the matplotlib backport request
[14:58] <tumbleweed> nigelb: http://code.google.com/p/pathfinder-pki/issues/detail?id=28
[15:07] <jtaylor> that patch will probably not work due to as-needed
[15:07] <tumbleweed> ah, that's true, I only looked on sid
[15:08] <tumbleweed> I gave up trying to understand the right way to solve the problem, their cmake use seems rather icky
[15:08] <jtaylor> hm I'll have a look
[15:10] <tumbleweed> I think I taught myself how to drive cmake, but I started getting semi-colons between gcc parameters (when pkg-config returned two include paths, due to multiarch)
[15:15] <jtaylor> strange it does not want to register the ssl DT_NEEDED entry
[15:16] <nigelb> I just grepped, I rebuild it 40 times today
[15:16] <jtaylor> ah no it needs nss :/
[15:16] <nigelb> but not everywhere
[15:17] <nigelb> I think moving LINK_FLAGS into TARGET_LINK_LIBRARIES might fix --as-needed-linking
[15:18] <nigelb> or something of that effect
[15:18] <jtaylor> so got it to compile
[15:18] <jtaylor> without cmake ^^
[15:18] <nigelb> jtaylor: are you picking this up?
[15:20] <jtaylor> I'll have a look at it if you like
[15:21] <nigelb> jtaylor: I'm trying to figure out how to get things out correctly.
[15:21] <jtaylor> I just quickly compiled it on the command line you need to explicitly link libpathfinder with nss and link nsstest with -lssl3
[15:28] <hrw> why pbuilder needs to be so awkard...
[15:29] <nigelb> pbuilder-dist is slightly more friendlier
[15:29] <Laney> sbuild is love
[15:29] <Laney> (with an apt cacher)
[15:29] <tumbleweed> (or even better, a mirror)
[15:30] <tumbleweed> sbuild doesn't make it quite as easy to dive in and fix problems, though
[15:30] <hrw> Laney: I cant work without apt-cacher-ng ;D
[15:30] <tumbleweed> and doesn't use distcc by default, which can be rather handy when debugging
[15:30] <hrw> --login --save-after-login != --save-after-login --login != --login --save-after-login true
[15:30] <hrw> argh
[15:31] <nigelb> heh
[15:32] <Laney> i just log in, get-build-deps and win
[15:32] <Laney> no need for this fancy hook stuff :P
[15:33]  * tumbleweed tends to fire up a build, then resume the failed session, but that requires copying and pasting, and then working without my preferences (sbuild user doesn't have my rc files)
[15:34] <Laney> ah, that stuff happens in a separate terminal
[15:34] <Laney> the schroot session is just for looping dpkg-buildpackage really
[15:36] <hrw> schroot... I always forget to learn how to use it from other develoeprs at sprints/udses
[15:39] <hrw> ~curse bug 802985 and broken chroots due to this
[15:42] <Laney> heh
[15:42] <Laney> debootsrap should have learned to use multiple suites long ago
[15:43] <hrw> I looked at code of it today - many changes would it take
[15:44] <jtaylor> nigelb: need more help with pathfinder?
[15:45] <nigelb> jtaylor: If you have time, yes!
[15:45] <dupondje> Could somebody take a look at https://bugs.launchpad.net/debian/+source/debootstrap/+bug/805886 ?
[15:46] <nigelb> jtaylor: I think my headache has something to do with cmake's formatting of TARGET_LINK_LIBRARIES
[15:46] <jtaylor> nigelb: this patch builds, but its ugly and it uses ssl and ssl3 which may give conflicts http://paste.ubuntu.com/638463/
[15:47] <nigelb> jtaylor: that's the path I was going through, but it didn't build
[15:47] <jtaylor> did you patch libpathfinder/CMakeLists.txt?
[15:48] <nigelb> jtaylor: yeah, but when I took a similar step, it didn't work for me
[15:48] <nigelb> the $ variables didn't expand for me
[15:48] <jtaylor> strange
[15:49] <nigelb> yup
[16:04] <hrw> I have a package which builds in lucid pbuilder (amd64), lucid chroot but fails on launchpad
[16:05] <tumbleweed> the most common reason for that is internet access
[16:06] <tumbleweed> that and differinc build-dependancy resolution algorithms
[16:07] <Laney> occasionally pkgbinarymangler/pkgstriptranslations too if you don't run those
[16:12] <hrw> anyway time to compile fake-uname.so and get lucid to think that 2.6.32 is kernel
[16:18] <dilruk> Anybody know how i can configure ALPS touchpad correctly?
[16:21] <hrw> dilruk: you run maverick at least?
[16:21] <hrw> ah. no.. it was eten with problem
[16:21] <dilruk> hrw: im on natty...I can get the edge scrolling to work
[16:22] <dilruk> I cant i mean
[16:22] <Pici> dilruk: This isn't a support channel. Please use #ubuntu
[16:23] <dilruk> I tried....but no one seem to care :(
[16:23] <Pici> dilruk: You asked once. Be patient, and repeat your question if no one responds after a few minutes.
[16:24] <dilruk> ok will do that. thank you
[16:25] <hrw> dilruk: it worked in past? is it old laptop or new? tried two-fingers-scrolling?
[16:26] <dilruk> hrw: it never worked...its a VAIO VPCEB intel i3. No special options are working
[16:30] <hrw> dilruk: ouch...
[16:33] <hrw> how to recreate EXACT rootfs used by launchpad while building ppa packages?
[16:39] <Ampelbein> hrw: what for?
[16:40] <tsimpson> just use pbuilder, it's not _exactly_ what LP uses, but it's basically the same
[16:42] <dupondje> bleh, cdebootstrap doesn't even know Oneiric :(
[16:42]  * dupondje sad
[16:42] <hrw> but package builds in pbuilder but not on launchpad
[16:43] <geser> hrw: where does it fail?
[16:43] <hrw> https://launchpadlibrarian.net/74590308/buildlog_ubuntu-lucid-i386.gcc-4.4_4.4.6-3ubuntu1~ppa2_FAILEDTOBUILD.txt.gz
[16:43] <geser> hrw: LP uses a hacked version of sbuild, and you can download the chroot LP uses for building
[16:43] <hrw> geser: url?
[16:44] <geser> hrw: let me search it
[16:45] <hrw> thanks
[16:45] <dupondje> sbuild is better then pbuilder ?
[16:46] <Ampelbein> dupondje: it's different
[16:47] <dupondje> cause pbuilder broke here :(
[16:50] <geser> hrw: you might need to ask wgrant for the magic url which shows you the librarian url for the build chroot
[16:51] <hrw> ok
[16:52] <hrw> +6h - will catch him tomorrow if will not solve
[16:52] <hrw> and time to end work now
[16:52] <hrw> have a nice rest of day
[17:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/courier/+bug/803176 => I attached a fix
[18:32] <tumbleweed> hrw: I know I've found them before by googling
[18:35] <tumbleweed> right: https://launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url
[19:10] <dupondje> ifneq ($(wildcard /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`/libcrypt.*),)
[19:10] <dupondje> this should work right ?
[19:18] <tumbleweed> dupondje: I think you'd need to use $(shell ) rather than ``
[19:18]  * micahg is curious as to the use case for the above statement
[19:18] <tumbleweed> yeah, that too :)
[19:19] <dupondje> ifneq ($(wildcard /usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)/libcrypt.*),)
[19:19] <dupondje> that should do ?
[19:20] <jtaylor> whats the point of that?
[19:20] <jtaylor> its always false
[19:20] <jtaylor> or true
[19:21] <dupondje> https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/749176
[19:22] <jtaylor> that bug is pending in debian
[19:22] <jtaylor> maybe ask the maintainer for a patch
[19:23] <dupondje> It just has the following now:
[19:23] <dupondje> ifneq ($(wildcard /usr/lib/libcrypt.*),)
[19:23] <dupondje> LIBCRYPT=-lcrypt
[19:23] <dupondje> endif
[19:23] <dupondje> So by adding the one above, it fixes the ftbfs
[19:23] <dupondje> and uses the same way it was done already in the code
[19:23] <dupondje> :)
[19:23]  * micahg wonders why the ifneg is necessary in the first place
[19:23] <jtaylor> just drop the if end endif
[19:24] <dupondje> yea would be the good way indeed ...
[19:25] <dupondje> but just wanted to do it the same way it was done already in the Makefile ...
[19:27]  * micahg would think upstream should switch to a configure flag based detection instead of that
[19:27] <dupondje> well its not a clean way
[19:27] <dupondje> but that shouldnt be changed in a FTBFS patch I think
[19:29] <micahg> well, either way, it's not suitable for upstream, so IMHO I think removing the check is cleaner in this case
[19:30] <micahg> as long as the library in question is in the build-deps
[19:30] <dupondje> libc6-dev is build-dep
[19:30] <dupondje> so yea :)
[19:30] <dupondje> both work.
[19:32] <dupondje> so go for the check removal ? :)
[19:32] <jtaylor> yes
[19:35] <dupondje> https://bugs.launchpad.net/ubuntu/+source/dnprogs/+bug/749176
[19:35] <dupondje> fix uploaded