| bkerensa | Needs Sponsor Love: https://code.launchpad.net/~bkerensa/ubuntu/raring/ubuntu-docs/13.04/+merge/159058 | 01:37 |
|---|---|---|
| ScottK | kirkland: Looks like you last testdrive upload lost a debian/changelog entry. Please reupload - http://launchpadlibrarian.net/137515417/testdrive_3.17-0ubuntu3_3.18-0ubuntu1.diff.gz | 04:55 |
| ScottK | or two | 04:55 |
| === security is now known as megha | ||
| pitti | Good morning | 06:04 |
| dholbach | good morning | 06:24 |
| === tkamppeter_ is now known as tkamppeter | ||
| jibel | doko_, test_shutil only fails when run under adt-run. The 3 others (code_module and subprocess tests ) fail even when run directly. | 07:06 |
| === amitk is now known as amitk-afk | ||
| jibel | doko_, TestWhich.test_non_matching_mode fails because adt-run executes it as root and the file is always writable. | 07:51 |
| jibel | doko_, Possible solutions could be to search for a file with execute bit set instead of writable, or set the file immutable or skip the test if executed as root. | 07:51 |
| pitti | or not running the tests as root perhaps? | 07:56 |
| pitti | it currently specifies "Restrictions: needs-root" | 07:56 |
| === ckpringle_ is now known as ckpringle | ||
| smartboyhw | kirkland, ping | 08:36 |
| smartboyhw | roaksoax, ^ | 08:37 |
| === dupondje_ is now known as dupondje | ||
| xnox | smartboyhw: what's up? | 08:53 |
| seb128 | http://package-import.ubuntu.com/status/accountsservice.html | 08:56 |
| seb128 | is there a way to ask for a retry for udd imports? | 08:56 |
| smartboyhw | xnox, about Testdrive:) | 08:57 |
| xnox | seb128: I supposedly have access to trigger that =) | 08:58 |
| seb128 | xnox, can you try? ;-) | 08:58 |
| xnox | seb128: well, it will not work.... as "$ pull-debian-source accountsservice 0.6.21-4" fails as well. That upload is clearly bogus =) | 09:00 |
| xnox | as dpkg-source cannot unpack that upload. | 09:00 |
| seb128 | xnox, it's not really buggy | 09:00 |
| seb128 | it has a sources and a sources.ubuntu | 09:00 |
| === amitk-afk is now known as amitk | ||
| seb128 | that works fine with quilt | 09:00 |
| seb128 | but not with dpkg source v3 | 09:00 |
| === doko_ is now known as doko | ||
| seb128 | xnox, or, yes, that upload is buggy on Ubuntu in some way, the debian maintainer didn't make the ubuntu patches to apply | 09:01 |
| doko | pitti, but then, how would I turn off apport without running as root? | 09:01 |
| seb128 | xnox, it would unpack fine on debian | 09:01 |
| pitti | doko: ah right, for that | 09:02 |
| pitti | doko: the test could run "su -c 'python ...' nobody" if that helps for that permission test? | 09:02 |
| xnox | seb128: arghhhh..... DEB_VENDOR and ./debian/patches/ubuntu.series strikes again...... sigh. | 09:02 |
| seb128 | xnox, right... | 09:02 |
| xnox | seb128: I don't know what is the correct way to solve this. I notice something similar with another package long time ago and proposed to unpack lp:debian/package with DEB_VENDOR=Debian, but that means rewritting history. | 09:03 |
| doko | pitti: yes, but another patch requires writeable locations ... | 09:03 |
| seb128 | xnox, ok, don't bother, I didn't realize we needed to un pack the debian source to have the ubuntu vcs | 09:04 |
| xnox | seb128: bug 911496 | 09:04 |
| ubottu | bug 911496 in Ubuntu Distributed Development "Needs to set DEB_VENDOR when unpacking source packages" [Undecided,Confirmed] https://launchpad.net/bugs/911496 | 09:04 |
| xnox | seb128: yeah, udd tries to do complete history with proper recollection that ubuntu packages are usually have lp:debian/package as ancestor. | 09:04 |
| pitti | jibel: would you know why in "run-adt-test -sl" "modprobe mac80211_hwsim" works fine, but it fails with run-adt-test -s network-manager"? | 09:05 |
| cjwatson | xnox: merge-o-matic takes care to unpack Ubuntu packages with DEB_VENDOR=ubuntu and Debian packages with DEB_VENDOR=debian - udd probably needs to do the same. And yeah, it'd be a history rewrite | 09:05 |
| pitti | jibel: that module is in linux-..-extra, but I don't see that being treated in any special way in the scripts | 09:05 |
| xnox | cjwatson: thanks for pointer where to steal code for UDD =) | 09:06 |
| cjwatson | Only if you're very lucky :) | 09:06 |
| cjwatson | Ah, heh, I pointed that out to James according to that bug | 09:06 |
| * cjwatson reads Max's comment. Messy :-( | 09:06 | |
| pitti | jibel: unping, pebcak | 09:09 |
| xnox | cjwatson: and well, MoM simply gives a tarball on errors, here the "ubuntu" series patches were not refreshed and hence it would fail to unpack.... | 09:09 |
| jibel | pitti, ack : ) | 09:09 |
| xnox | (when unpacked the second time for the ubuntu branch) | 09:09 |
| xnox | seb128: my recommendation is to start ~ubuntu-desktop-team or ~ubuntu-core-devs branch where bzr import-dsc is used or such like on packages that are known to work. | 09:12 |
| cjwatson | xnox: Actually in the case at hand it crashed MoM | 09:16 |
| cjwatson | xnox: So I cared a little more than that :) | 09:16 |
| xnox | ouch. | 09:17 |
| xnox | =))))) | 09:17 |
| cjwatson | MoM fails if dpkg-source exits non-zero | 09:17 |
| xnox | hmm... true that is sensible. | 09:17 |
| xnox | cjwatson: should it fallback to unpacking ./debian/patches/series at all? | 09:17 |
| cjwatson | xnox: MoM or UDD? | 09:17 |
| xnox | cjwatson: either/both? | 09:17 |
| cjwatson | MoM's current behaviour is fine I think | 09:18 |
| * xnox really dislikes split personality source package, where it may or may not unpack depending on which $derivative one is using and whether the patches for refreshed or not. | 09:18 | |
| cjwatson | I certainly don't think MoM should be peering at debian/patches/series* by hand (except in the generate-dpatches bit) | 09:19 |
| cjwatson | yes, I'm not a fan either. I think it's normally more sensible, if you really need conditional behaviour, to have patches that make the behaviour be built conditional on a configure flag or environment variable or similar | 09:19 |
| === ckpringle_ is now known as ckpringle | ||
| xnox | doko: http://paste.ubuntu.com/5712837/ is python2.7's sysconfig a bit confused, or am I not passing correct optional args to it? It's reporting that everything is in /usr/local/* | 10:54 |
| cjwatson | doko: any chance you could look at the polyorb build failure at some point? It sort of looks like -lgnarl isn't being added, which I *think* is meant to be done automatically by something in the gnatmake/gnatlink chain | 10:55 |
| cjwatson | But I don't know Ada at all, really | 10:55 |
| doko | xnox, see the FIXME in sysconfig._get_default_scheme ... | 11:00 |
| doko | cjwatson, heh, you did learn haskell too =) | 11:00 |
| doko | I'll look | 11:01 |
| cjwatson | doko: one exotic language per month, is my rule ;-) | 11:01 |
| cjwatson | thanks | 11:01 |
| doko | xnox, $ python -c "import sysconfig; print(sysconfig.get_paths(scheme='deb_system'))" | 11:02 |
| xnox | doko: ack, thanks. | 11:04 |
| xnox | cjwatson: is MQL4 on your list of exotic language to learn? | 11:06 |
| cjwatson | no | 11:07 |
| cjwatson | not least because I've never heard of it :) | 11:07 |
| doko | jibel, did you see these? http://paste.ubuntu.com/5712858/ | 11:07 |
| xnox | cjwatson: it's to automatically script algorithmic forex trading. windows/wine only. | 11:09 |
| cjwatson | xnox: yeah, not exactly in my interest zone :) | 11:11 |
| === MacSlow is now known as MacSlow|lunch | ||
| jibel | doko, yes and this too http://paste.ubuntu.com/5712878/ | 11:25 |
| pitti | cjwatson: I have some larger autopkgtest additions/changes for network-manager; I guess they are still ok at this time of the freeze? | 11:34 |
| pitti | i. e. debian/tests/* is not regarded as "features", as they don't impact the installed system | 11:35 |
| cjwatson | pitti: yes, should be fine | 11:36 |
| doko | jibel, http://bugs.python.org/issue17750 should now have all the depending issues | 11:41 |
| mdeslaur | @pilot in | 11:56 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === sil2100_ is now known as sil2100 | ||
| === _salem is now known as salem_ | ||
| doko | barry, ahh, you did find the installed testsuite issues ;) | 13:16 |
| barry | doko: no, but i just wanted to follow it. i see other test suite failures building from the hg branches on 13.04 | 13:17 |
| barry | doko: have you run the default or 3.3 branch test suite from hg source recently? | 13:22 |
| doko | barry, yes. well, this is 3.3.1, won't update anymore before the release | 13:23 |
| barry | doko: the ubuntu buildbots are red for 3.3 and 3.4 unfortunately. | 13:29 |
| doko | barry, well they are offline ... | 13:31 |
| barry | doko: i doubt they'd be green if they were online :) | 13:32 |
| === wedgwood_away is now known as wedgwood | ||
| mdeslaur | @pilot out | 13:56 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Frozen for Final Release | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| tseliot | pitti: do you still have the python script to reproduce bug #804662 ? | 13:56 |
| ubottu | bug 804662 in nvidia-common (Ubuntu Precise) "jockey-gtk crashed with TypeError in _execute_child(): execv() arg 2 must contain only strings" [High,Triaged] https://launchpad.net/bugs/804662 | 13:56 |
| === kentb-afk is now known as kentb | ||
| pitti | tseliot: no, sorry; should have attached it | 14:01 |
| tseliot | pitti: too bad. I'll try to figure it out from the bug report | 14:02 |
| pitti | tseliot: I guess it just called a few functions from NvidiaDetector and printed its results | 14:04 |
| tseliot | pitti: yes, I can see that the script printed something about an NvidiaDetector.alternatives.Alternatives object, the question is why this proved that the library is passing the wrong arguments | 14:07 |
| === cmagina_away is now known as cmagina | ||
| === Snow-Man_ is now known as Snow-Man | ||
| gQuigs | is recommending 64 bit (on website) only going to change for a LTS release? | 14:58 |
| smartboyhw | gQuigs, what do you mean? | 15:00 |
| gQuigs | guess I'm wondering if this [1] has been revisited for Raring | 15:00 |
| gQuigs | [1] https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035054.html | 15:00 |
| gQuigs | 64 bit desktop by default | 15:00 |
| smartboyhw | gQuigs, well I think it would be changing for everybody... | 15:01 |
| gQuigs | everybody means both 12.04 and Raring? | 15:03 |
| cjwatson | Fairly sure we're not changing that quite yet | 15:03 |
| cjwatson | Though it still needs to happen at some point | 15:04 |
| cjwatson | It's not necessarily tied to the LTS cycle, though, no | 15:04 |
| gQuigs | thanks cjwatson | 15:05 |
| gQuigs | do we know what is currently blocking it? | 15:05 |
| ogra_ | a TB decision i would guess | 15:06 |
| ogra_ | (or was there one ?) | 15:06 |
| cjwatson | Er, no | 15:06 |
| cjwatson | IIRC last we checked the resource consumption of 64-bit systems wasn't favourable | 15:07 |
| xnox | gQuigs: cjwatson: the website team is thinking to add a label to the 64-bit to say "(recommended for newer machines)" or something along the lines. | 15:09 |
| xnox | but to still keep 32-bit as the default option for raring. | 15:09 |
| gQuigs | xnox: right partly due to EUFI I'm guessing | 15:12 |
| gQuigs | the big reason it didn't go forward with 12.04 (from Ubuntu-devel) was because a significant number of people submit to ubuntu friendly with 32 bit only machines, with EUFI that might start going the other way | 15:13 |
| xnox | having 64-bit UEFI-only machines & significantly more than 4GB by default, even on budget machines will help to towards making 64-bit image by default. | 15:13 |
| bdmurray | mpt: now that update-manager tells you to reboot after installing updates do you think that update-notifier still should? (It doesn't it most cases because the update-notifier tray is hidden.) | 15:17 |
| gQuigs | I guess what I'm really asking is how can I push 64 bit along :) I can redo the power/memory tests to see what kind of impact it has... or will it just come about when UEFI machines outnumber 32 bit only machines? | 15:19 |
| jdstrand | slangasek: hi! it seems that atd is no longer on the server cd. my interpretation of the list was that we still wanted it. was this intentional? | 15:26 |
| jdstrand | Daviey: ^ | 15:26 |
| mpt | bdmurray, no, I don't think it ever should have. The first paragraph of <https://wiki.ubuntu.com/SoftwareUpdates#alert> goes into a bit more detail. :-) | 15:26 |
| jdstrand | Daviey: and hi to you too :) | 15:26 |
| slangasek | jdstrand: hmm, not intentional on my part; looking | 15:26 |
| slangasek | jdstrand: I did put 'at' in the server-ship seed, which I thought was correct | 15:28 |
| slangasek | jdstrand: perhaps it was meant to be in 'server' rather than 'server-ship' | 15:28 |
| jdstrand | slangasek: hmm, it doesn't end up installed though | 15:28 |
| jdstrand | slangasek: you did that some time ago, right? my server install is from 20130410 | 15:29 |
| bdmurray | mpt: great, thanks! | 15:29 |
| cjwatson | If you want it installed by default on server it'd need to be in the server seed | 15:29 |
| jdstrand | s/install/iso/ | 15:29 |
| jdstrand | ah | 15:30 |
| psusi | ubiquity is not supposed to let you install grub to the usb flash drive you are booting from right? even if it is detected as sda? | 15:32 |
| xnox | psusi: not supposed to, but it currently does for me when trying to install '/' on a fakeraid device. | 15:36 |
| xnox | psusi: bug 1167366 | 15:37 |
| ubottu | bug 1167366 in grub-installer (Ubuntu) "Precise/Raring does not detect proper device (/dev/mapper/isw_<something>_Volume0p1) during preseed install" [High,Confirmed] https://launchpad.net/bugs/1167366 | 15:37 |
| psusi | xnox: that's where it wants to install to an individual disk instead of the raid array isn't it? I'm talking /dev/sda happens to come up as the usb flash drive you are installing from, and /dev/sdb is the hd | 15:38 |
| xnox | psusi: well, I'm booting installer off usb-disk /dev/sda and grub-installer puts the bootloader on to /dev/sda instead of the target device. So my situation is closer to yours, apart from instead of /dev/sdb it's /dev/dm-0. | 15:39 |
| xnox | psusi: "everything works fine" when booting in UEFI mode though. Try that, if possible on the target machines. | 15:40 |
| psusi | ahh | 15:40 |
| === pete-woods1 is now known as pete-woods | ||
| psusi | not happening to me, just triaged a bug report of install failure that looked to be caused by trying to install grub to the flash drive instead of the hd because they were detected in the reverse order | 15:41 |
| psusi | and I thought ubiquity supposedly handled that | 15:42 |
| === mbarnett` is now known as mbarnett | ||
| xnox | psusi: it does handle it mostly correct, but not always. | 15:42 |
| === francisco is now known as Guest86369 | ||
| === security is now known as megha | ||
| gQuigs | (my last question, repeated from above): will 64 bit by default just come about when UEFI machines outnumber 32 bit only machines? or should I redo power/memory tests to see if it has less impact now? | 15:53 |
| smartboyhw | !patience | gQuigs | 15:53 |
| ubottu | gQuigs: Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com/ or http://ubuntuforums.org/ or http://askubuntu.com/ | 15:53 |
| cjwatson | slangasek might have the most context on this ^- | 15:54 |
| cjwatson | or cking | 15:54 |
| stokachu | bdmurray: do i need to set verified-done and remove -done-{precise,quantal} from bug 1013798 | 15:57 |
| ubottu | bug 1013798 in libgcrypt11 (Ubuntu Oneiric) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/1013798 | 15:57 |
| stokachu | now that both series are verified | 15:57 |
| bdmurray | stokachu: if you look at the pending SRU report you'll see that the bug is green so no it doesn't look like it | 15:59 |
| stokachu | bdmurray: ok cool | 16:00 |
| stokachu | thanks | 16:00 |
| doko | jibel, python3.3 now waiting for approval | 16:07 |
| === iulian is now known as Guest6437 | ||
| jibel | doko, good. there'll be another issue with autopkgtest and python3.3dm because it outputs ref counts to stderr | 16:24 |
| === mhall119 is now known as mhall119|lunch | ||
| doko | jibel, honestly this seems to be a bad assumption in autopkgtest | 16:26 |
| smb | infinity, Has tomorrow still a chance to be today or will it be today's tomorrow? 3:) | 16:45 |
| kirkland | smartboyhw: howdy | 17:10 |
| kirkland | smartboyhw: here now, what's up? | 17:10 |
| === mhall119|lunch is now known as mhall119 | ||
| === james_ is now known as Guest69845 | ||
| infinity | smb: That was a convoluted sentence, but I think today is tomorrow. | 17:41 |
| ev | mpt: all the difference an order of magnitude makes. I think I found the bug. http://paste.ubuntu.com/5713799/ | 17:47 |
| ev | going to do some more testing though | 17:47 |
| ev | mpt: false alarm | 18:19 |
| === Guest6437 is now known as iulian | ||
| xnox | jibel: we could add a "stderr-no-fail" constraint..... | 18:36 |
| slangasek | jdstrand: yes, I adjusted the server seed at the same time that I adjusted the base seed; sorry, my point was that I think I put it in the *wrong* seed and that it should have been in server, not server-ship - I think you'll find it's still on the server *CD*, but not installed by default. | 18:46 |
| Daviey | aaaaa | 18:53 |
| === salem_ is now known as _salem | ||
| jdstrand | slangasek: right, I gathered that after I read your and colin's comments. are you adjusting the seed or shall I? | 19:09 |
| slangasek | gQuigs: there shouldn't be any need to rerun the power/memory tests as there's unlikely to be much change there; it now mostly comes down to the numbers of users that are going to find each of the two options incompatible with their hardware. With the UEFI question now, 64-bit will certainly figure more prominently on the website | 19:29 |
| gQuigs | slangasek: thanks... are the current numbers public? | 19:34 |
| slangasek | gQuigs: hmm, I don't think so; I've had to ask various people with access to run queries to get information about the range of user systems we've seen in the wild | 19:35 |
| jdstrand | slangasek: ok, r2131 does it, so cool. thanks :) | 19:36 |
| slangasek | gQuigs: I mean, "the numbers" they came up with were posted to the discussion on ubuntu-devel last time we looked, which was a year ago; but sourcing new numbers requires access to data sources | 19:37 |
| slangasek | jdstrand: ok, great | 19:37 |
| slangasek | jdstrand: so you're the one user of at, eh? :) | 19:37 |
| infinity | I use it... | 19:38 |
| slangasek | weirdos | 19:38 |
| infinity | It's handy. | 19:39 |
| jdstrand | hoestly, I haven't used it for years, but that doesn't mean that other server admins don't :) | 19:39 |
| infinity | Depends on how far out my needs are. | 19:39 |
| infinity | If I want to do something in an hour, I just sleep 3600 and keep a session open, but if I want to do something sometime tomorrow, at makes more sense. | 19:40 |
| jdstrand | yeah | 19:40 |
| mcantor | Is there a channel devoted to developing *ON* Ubuntu? | 19:40 |
| jdstrand | imo, a server is a place where you expect to have certain things like at | 19:40 |
| gQuigs | slangasek: right, but that wouldn't have many UEFI hits and I was also curious if those numbers included derivatives (lubuntu/xubuntu likely would want to keep 32 bit more prominent for longer) | 19:41 |
| infinity | mcantor: The topic claims #ubuntu-app-devel | 19:41 |
| gQuigs | guess I should just ping ubuntu friendly? | 19:42 |
| mcantor | infinity: Haha, thanks; I saw "Devel of Ubuntu (not support or app devel)" and stopped reading... <.< | 19:42 |
| infinity | gQuigs: lubuntu/xubuntu aren't derivatives, they're flavours (which matters in this case, since we're probably talking about archive and/or whoopsie statistics) | 19:42 |
| slangasek | gQuigs: well, we were only considering the question for www.ubuntu.com, not for flavors; and while it's true there wouldn't have been many UEFI hits yet at that point, it at least gives info on the ratio of 64-bit to 32-bit-only machines | 19:42 |
| infinity | gQuigs: Actual derivatives (like Mint, for instance) wouldn't be counted in any stats we keep. | 19:42 |
| mcantor | Hmm. You guys might be able to help me out here anyway. | 19:43 |
| mcantor | When I link my application with -m32 and run gcc with -v, I see that /usr/lib/x86_64-gnu-linux is still the first directory in the LIBRARY_PATH. Am I doing something wrong? | 19:43 |
| gQuigs | infinity: right, sorry I misspoke (typed..) | 19:43 |
| slangasek | mcantor: what exactly is the gcc command you're running? | 19:44 |
| infinity | It's a bit of a chicken and egg, of course. The longer we promote i386 as the default image, the higher our i386 stats on package downloads and whoopsie reports will be. | 19:44 |
| gQuigs | slangasek: but wouldn't Ubuntu Friendly have included information from lubuntu/xubuntu ? | 19:44 |
| infinity | Not that they'll go up, but you know what I mean. They could go drastically down if that wasn't the default ISO. :P | 19:45 |
| slangasek | gQuigs: yes, but it wouldn't call it out separately | 19:45 |
| infinity | If this is purely about actual hardware stats (cpuinfo, etc), ignore me. | 19:45 |
| slangasek | infinity: no, the stats we're looking at for this is whether the machines *support* 64-bit. | 19:45 |
| infinity | But we have a lot less of those. | 19:45 |
| infinity | slangasek: Right, see above. | 19:45 |
| mcantor | slangasek: /usr/bin/c++ [my object files] -m32 `/opt/pym32/python-config --ldflags` -lboost_system -lboost_python -llog4cplus -lfreetype -o executable | 19:46 |
| slangasek | mcantor: and where are you seeing /usr/lib/x86_64-gnu-linux? | 19:47 |
| mcantor | slangasek: It complains that it cannot find the symbol 'dlopen@@GLIBC_2.1', but tells me that it is defined in DSO /usr/lib/i386-gnu-linux, and I should add it to my compiler command line | 19:47 |
| mcantor | slangasek: when I add /usr/lib/i386-gnu-linux/libdl.so to the command line, it works fine. I see /usr/lib/x86_64-gnu-linux when I add "-v" to the prior command line | 19:47 |
| mcantor | slangasek: it's the first directory in LIBRARY_PATH, which seems wrong to me, and I have a hunch that it's why the linker is complaining... perhaps it's finding the 64-bit libdl.so first. | 19:48 |
| infinity | mcantor: But your command line is lacking '-ldl' | 19:48 |
| mcantor | infinity: Sorry--"-ldl" is in the output of `/opt/pym32/bin/python-config --ldflags`. | 19:48 |
| mcantor | infinity: the full output of that command is '-L/opt/pym32/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic'. | 19:49 |
| jtaylor | is that after the object files? libraries before them are dropped due to ubuntus use of ld --as-needed | 19:50 |
| jtaylor | also if you get that message you should not rely on getting ldl form python-config | 19:51 |
| infinity | jtaylor: According to his paste, it is. | 19:51 |
| jtaylor | as you need it directly | 19:51 |
| mcantor | jtaylor: Pasting the output of python-config directly into my Makefile has the same results | 19:51 |
| mcantor | jtaylor: I don't see why it would be different, to be honest--Make tends to complete a subshell and insert its output just to avoid that kind of weirdness. | 19:52 |
| mcantor | jtaylor: It is after the object files, though. | 19:52 |
| jtaylor | hm it might need to be after boost | 19:54 |
| jtaylor | I recall some weirdness with boost_system | 19:54 |
| jtaylor | try adding a -ldl after the -lboost_system | 19:54 |
| mcantor | jtaylor: I've heard furtive whisperings and conspiracies that the linker is very sensitive to the order of link flags... I'll give that a shot | 19:54 |
| jtaylor | it is | 19:54 |
| === _salem is now known as salem_ | ||
| mcantor | jtaylor: No dice | 19:57 |
| slangasek | mcantor: and you have the g++-multilib package installed? | 19:58 |
| mcantor | jtaylor: infinity: Here's the exact error I'm getting: http://pastebin.com/ZgBj4fUi | 19:58 |
| mcantor | slangasek: Indeed. | 19:58 |
| jtaylor | oh static libpython | 19:59 |
| mcantor | slangasek: Should I specifically *NOT* have ia32-libs installed? | 19:59 |
| jtaylor | then --ldflags output is wrong | 19:59 |
| jtaylor | the -ldl must be behind the -lpython2.7 | 19:59 |
| mcantor | jtaylor: You're kidding--python-config itself is giving me bad output? | 19:59 |
| jtaylor | seems so | 19:59 |
| mcantor | jtaylor: I'll try it, but fwiw, adding /usr/lib/i386-gnu-linux/libdl.so to the *END* of the command line worked before | 20:00 |
| jtaylor | that should work, but the linker works in mysterious ways | 20:00 |
| mcantor | jtaylor: wait a tick... -ldl is already before -lpython2.7 | 20:01 |
| jtaylor | behind lpython2.7 | 20:01 |
| jtaylor | worst case add -Wl,--add-nedded | 20:01 |
| jtaylor | that will shut this warning up | 20:02 |
| mlankhorst | isn't it -Wl,-as-needed? | 20:02 |
| mcantor | jtaylor: By "behind" do you mean "after"? | 20:02 |
| slangasek | yes | 20:02 |
| jtaylor | this warning is ld --no-copy-dt-needed (or --no-add-needed) | 20:02 |
| slangasek | -ldl needs to be listed after libpython2.7 on the commandline; you shouldn't have to specify it as /usr/lib/i386-gnu-linux/libdl.so, -ldl should Just Work | 20:02 |
| jtaylor | -lpython2.7 -ldl | 20:02 |
| mcantor | trying that now | 20:03 |
| mcantor | Perhaps I should file a bug with Python since it is providing a bad command line | 20:03 |
| GunnarHj | slangasek: Sorry to be a pain, but you didn't change your mind about the Skype thing, did you? Suppose it's not directly related to the ISO builds, but I think sooner is better than later. ;-) | 20:03 |
| mcantor | I'll be damned. It worked. | 20:03 |
| jtaylor | its only bad with static python | 20:03 |
| jtaylor | if libpython is shared it works in wrong order too | 20:03 |
| jtaylor | but yes file a bug please | 20:04 |
| slangasek | if libpython is shared, the -ldl is unnecessary and redundant on Linux | 20:04 |
| mcantor | jtaylor: slangasek: why is the order significant? (I recognize that this is likely a Tip of the Iceberg question, but if you can direct me to further reading other than man gcc, I'd be delighted) | 20:04 |
| jtaylor | if you don't need it directly yourself | 20:04 |
| jtaylor | its a side effect of ld --as-needed | 20:04 |
| jtaylor | it sees libdl, nothing needs it, it forgets about it | 20:05 |
| mlankhorst | it matters mostly for static libs | 20:05 |
| jtaylor | then it seens libpython, its needed and now you are screwed | 20:05 |
| jtaylor | libpython.a | 20:05 |
| mcantor | ahhhh, ok | 20:05 |
| slangasek | GunnarHj: haven't changed my mind, but I did decide I want to do a local test to see if I can get a better backtrace proving the problem is with QtWebkit, not skype | 20:05 |
| jtaylor | its a ubuntu/mandriva specific problem | 20:06 |
| jtaylor | other distributions don't enable as-needed by default | 20:06 |
| GunnarHj | slangasek: Ok, thanks for letting me know. | 20:06 |
| mcantor | jtaylor: I see, thanks so much for the explanation and help! | 20:07 |
| cjwatson | and opensuse | 20:07 |
| jtaylor | really? I think I haven't seen it on 12.1 | 20:07 |
| cjwatson | well, so said http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries anyway | 20:07 |
| jtaylor | on the other hand my makefiles are all well behaved ;) | 20:08 |
| mcantor | jtaylor: so why does this behavior screw up with a static library? can ld "not see" the required symbols? | 20:09 |
| jtaylor | ld goes through them from left to right, it can't go back to elements it has already checked | 20:09 |
| jtaylor | (unless you tell it to with -start-group) | 20:10 |
| mlankhorst | even that screws up, though | 20:10 |
| mcantor | jtaylor: wouldn't it have the same problem if python was a dynamic library, though? | 20:10 |
| mcantor | at the time it saw -ldl, it would still think "Nope, I have nothing that needs this" | 20:10 |
| jtaylor | that somehow works different, don't ask me why :) | 20:10 |
| mcantor | hahaha, ok, that's what I was specifically wondering about. XD | 20:10 |
| jtaylor | I never udnerstood why order on the commandline matters | 20:10 |
| mlankhorst | because computers are dumb | 20:11 |
| jtaylor | but I'm sure there are good reasons | 20:11 |
| jtaylor | makes it slow on old Z3 machines or so :) | 20:11 |
| mcantor | hahahaha | 20:11 |
| mcantor | great reasons, of course | 20:11 |
| slangasek | mcantor: with a shared library, there's nothing that needs relinking against libdl; you don't need to tell ld about a library that libpython is already linked against | 20:16 |
| mcantor | slangasek: Ah, that makes sense. It just goes and finds it at runtime like usual. | 20:16 |
| cjwatson | the order-insensitive behaviour of --no-as-needed also causes objects to end up with extra linkage that they don't need, because the linker doesn't go through at the end and trim out the ones that turned out not to be used | 20:18 |
| cjwatson | --as-needed is more efficient at runtime and makes library transitions less complex in cases of indirect linkage | 20:20 |
| cjwatson | (--no-copy-dt-needed-entries also contributes to this) | 20:20 |
| jtaylor | its clear the flag is good, but why does it make it order dependent instead of just adding a cleaning phase when it checked everything? | 20:21 |
| jtaylor | I could guess memory issues? | 20:21 |
| cjwatson | well, order-dependent is the traditional Unix behaviour, and indeed there are cases where linker memory use is a serious problem | 20:21 |
| cjwatson | I'm not certain that a cleaning phase could be implemented correctly, but I'm also not a linker expert :) | 20:22 |
| mcantor | I filed a bug with python here btw, for any interested http://bugs.python.org/issue17769 | 20:22 |
| mcantor | cjwatson: The order-dependence does make more sense given slangasek's point. It's apples and oranges when it comes to being concerned with symbol usage. | 20:23 |
| cjwatson | Well, sure | 20:24 |
| cjwatson | I agree python-config --ldflags looks backwards | 20:26 |
| jtaylor | it also shouldn'T be ldflags :/ | 20:26 |
| mcantor | jtaylor: Why not..? | 20:27 |
| jtaylor | then people put it into autotools LDFLAGS and you have the same problem for your own object files | 20:27 |
| mcantor | ah, I don't know autotools | 20:27 |
| jtaylor | autotools LDFLAGS is placed before your object files, so it forgets all the libraries listed in them | 20:27 |
| cjwatson | FWIW, all traditional Unix linkers have the behaviour where later entries on the link line supply symbols used by earlier entries. It's just that some linkers are more permissive and people have incorrectly got used to that behaviour. | 20:27 |
| jtaylor | the right variable is LIBS | 20:27 |
| mcantor | jtaylor: python-config has a --libs flag, too, but the output is different | 20:27 |
| cjwatson | I believe the NT linker is the other way round, and AIX is similar. | 20:27 |
| cjwatson | (As in, AIX is the other way round too.) | 20:27 |
| mcantor | cjwatson: that makes sense. | 20:27 |
| cjwatson | jtaylor: It's not just autotools; make's implicit rules treat LDFLAGS and LDLIBS separately in much the same way | 20:28 |
| mcantor | I didn't know LDLIBS was another automatic variable used by Make | 20:28 |
| cjwatson | (CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS) | 20:29 |
| cjwatson | with a $ at the start too | 20:30 |
| jtaylor | also LDADD and LIBADD, for libtool based autotools ._. | 20:30 |
| mcantor | What is LOADLIBS? | 20:31 |
| cjwatson | LDADD is automake | 20:31 |
| cjwatson | mcantor: thread starting https://lists.gnu.org/archive/html/help-make/2005-01/msg00062.html | 20:32 |
| mcantor | thanks | 20:32 |
| cjwatson | (LOADLIBES is not a typo, or at least if it is it's not mine ...) | 20:32 |
| mcantor | Oh. Hahaha | 20:32 |
| cjwatson | (tl;dr: ignore it and just use LDLIBS) | 20:33 |
| === NCommander is now known as Guest64348 | ||
| === salem_ is now known as _salem | ||
| zyga-phone | Hew: thnx | 22:05 |
| zyga-phone | Dzięki | 22:05 |
| zyga-phone | Grr | 22:05 |
| === kentb is now known as kentb-out | ||
| === davidm` is now known as davidm | ||
| cseder | Wow! What a user count for a developers group! | 22:15 |
| cseder | Active community for sure. | 22:15 |
| cseder | Guess I should introduce myself… I work as a full-time developer, but I've used Linux for about ten years, and Ubuntu since its first release. So now I thought I should maybe contribute something back. | 22:17 |
| cjwatson | cseder: welcome :-) https://wiki.ubuntu.com/ContributeToUbuntu if you haven't seen it | 22:22 |
| cseder | So I'll be doing some development on my spare time... | 22:23 |
| cseder | I guess I'll just SVN the source tree? | 22:24 |
| cseder | Or maybe just read the Wiki first… ;-) | 22:25 |
| cjwatson | There isn't a single source tree | 22:25 |
| cseder | the source tree for my parts of interest was what I meant. | 22:26 |
| cjwatson | Ah, yeah | 22:26 |
| cjwatson | If you already have an idea what you want to work on, then sure | 22:26 |
| cseder | Well, I've done a bit of this and that, so I'll just check out what's needed and pick from that | 22:27 |
| cseder | Mainly C, C++ and C#, but a tiny bit of Python also | 22:28 |
| cseder | Most administrative scripts in Python, so I won't do that in the first round... | 22:28 |
| cseder | Haha… Now my Ubuntu installer just crashed. Maybe start there! ;-) kidding | 22:29 |
| cseder | Apport! | 22:30 |
| * infinity is still trying to find someone to talk into porting apport from Python to C/C++. | 22:31 | |
| cseder | Probably a good idea | 22:32 |
| cseder | I'm not very fond of using python for main programming tasks. It's ok as a glue. | 22:32 |
| cseder | But I guess Ubuntu uses a lot of Python… | 22:34 |
| cjwatson | You can find lots of almost any language you care to name, really | 22:36 |
| doko | jibel, so for printing the reference counts in the debug interpreter. so why specify a filter in the control file, which filters these out to clear your stderr log file? | 22:37 |
| cjwatson | Most low-level system code is C or C++; a considerable amount of glue code is Python (especially that written specifically for Ubuntu) or Perl; GUI code is C/GObject, Vala, C++/Qt, etc. | 22:37 |
| cseder | cjwatson: guess it depends on the variations of Ubuntu as well… kUbuntu xUbuntu and the ilkes | 22:39 |
| cseder | That's what I'll miss from FreeBSD. One distribution. But then again there are other things I won't miss... | 22:41 |
| cjwatson | It's still all one archive | 22:42 |
| cjwatson | At a technical level, Kubuntu and Xubuntu are essentially just different sets of packages (and associated images) within the Ubuntu archive | 22:43 |
| cseder | aha. | 22:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!