bkerensaNeeds Sponsor Love: https://code.launchpad.net/~bkerensa/ubuntu/raring/ubuntu-docs/13.04/+merge/15905801:37
ScottKkirkland: 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.gz04:55
ScottKor two04:55
=== security is now known as megha
pittiGood morning06:04
dholbachgood morning06:24
=== tkamppeter_ is now known as tkamppeter
jibeldoko_, 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
jibeldoko_, TestWhich.test_non_matching_mode fails because adt-run executes it as root and the file is always writable.07:51
jibeldoko_, 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
pittior not running the tests as root perhaps?07:56
pittiit currently specifies "Restrictions: needs-root"07:56
=== ckpringle_ is now known as ckpringle
smartboyhwkirkland, ping08:36
smartboyhwroaksoax, ^08:37
=== dupondje_ is now known as dupondje
xnoxsmartboyhw: what's up?08:53
seb128is there a way to ask for a retry for udd imports?08:56
smartboyhwxnox, about Testdrive:)08:57
xnoxseb128: I supposedly have access to trigger that =)08:58
seb128xnox, can you try? ;-)08:58
xnoxseb128: well, it will not work.... as "$ pull-debian-source accountsservice 0.6.21-4" fails as well. That upload is clearly bogus =)09:00
xnoxas dpkg-source cannot unpack that upload.09:00
seb128xnox, it's not really buggy09:00
seb128it has a sources and a sources.ubuntu09:00
=== amitk-afk is now known as amitk
seb128that works fine with quilt09:00
seb128but not with dpkg source v309:00
=== doko_ is now known as doko
seb128xnox, or, yes, that upload is buggy on Ubuntu in some way, the debian maintainer didn't make the ubuntu patches to apply09:01
dokopitti, but then, how would I turn off apport without running as root?09:01
seb128xnox, it would unpack fine on debian09:01
pittidoko: ah right, for that09:02
pittidoko: the test could run "su -c 'python ...' nobody" if that helps for that permission test?09:02
xnoxseb128: arghhhh..... DEB_VENDOR and ./debian/patches/ubuntu.series strikes again...... sigh.09:02
seb128xnox, right...09:02
xnoxseb128: 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
dokopitti: yes, but another patch requires writeable locations ...09:03
seb128xnox, ok, don't bother, I didn't realize we needed to un pack the debian source to have the ubuntu vcs09:04
xnoxseb128: bug 91149609:04
ubottubug 911496 in Ubuntu Distributed Development "Needs to set DEB_VENDOR when unpacking source packages" [Undecided,Confirmed] https://launchpad.net/bugs/91149609:04
xnoxseb128: yeah, udd tries to do complete history with proper recollection that ubuntu packages are usually have lp:debian/package as ancestor.09:04
pittijibel: 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
cjwatsonxnox: 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 rewrite09:05
pittijibel: that module is in linux-..-extra, but I don't see that being treated in any special way in the scripts09:05
xnoxcjwatson: thanks for pointer where to steal code for UDD =)09:06
cjwatsonOnly if you're very lucky :)09:06
cjwatsonAh, heh, I pointed that out to James according to that bug09:06
* cjwatson reads Max's comment. Messy :-(09:06
pittijibel: unping, pebcak09:09
xnoxcjwatson: 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
jibelpitti, ack : )09:09
xnox(when unpacked the second time for the ubuntu branch)09:09
xnoxseb128: 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
cjwatsonxnox: Actually in the case at hand it crashed MoM09:16
cjwatsonxnox: So I cared a little more than that :)09:16
cjwatsonMoM fails if dpkg-source exits non-zero09:17
xnoxhmm... true that is sensible.09:17
xnoxcjwatson: should it fallback to unpacking ./debian/patches/series at all?09:17
cjwatsonxnox: MoM or UDD?09:17
xnoxcjwatson: either/both?09:17
cjwatsonMoM's current behaviour is fine I think09: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
cjwatsonI certainly don't think MoM should be peering at debian/patches/series* by hand (except in the generate-dpatches bit)09:19
cjwatsonyes, 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 similar09:19
=== ckpringle_ is now known as ckpringle
xnoxdoko: 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
cjwatsondoko: 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 chain10:55
cjwatsonBut I don't know Ada at all, really10:55
dokoxnox, see the FIXME in sysconfig._get_default_scheme ...11:00
dokocjwatson, heh, you did learn haskell too =)11:00
dokoI'll look11:01
cjwatsondoko: one exotic language per month, is my rule ;-)11:01
dokoxnox, $ python -c "import sysconfig; print(sysconfig.get_paths(scheme='deb_system'))"11:02
xnoxdoko: ack, thanks.11:04
xnoxcjwatson: is MQL4 on your list of exotic language to learn?11:06
cjwatsonnot least because I've never heard of it :)11:07
dokojibel, did you see these? http://paste.ubuntu.com/5712858/11:07
xnoxcjwatson: it's to automatically script algorithmic forex trading. windows/wine only.11:09
cjwatsonxnox: yeah, not exactly in my interest zone :)11:11
=== MacSlow is now known as MacSlow|lunch
jibeldoko, yes and this too http://paste.ubuntu.com/5712878/11:25
pitticjwatson: I have some larger autopkgtest additions/changes for network-manager; I guess they are still ok at this time of the freeze?11:34
pittii. e. debian/tests/* is not regarded as "features", as they don't impact the installed system11:35
cjwatsonpitti: yes, should be fine11:36
dokojibel, http://bugs.python.org/issue17750 should now have all the depending issues11:41
mdeslaur@pilot in11: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_
dokobarry, ahh, you did find the installed testsuite issues ;)13:16
barrydoko: no, but i just wanted to follow it.  i see other test suite failures building from the hg branches on 13.0413:17
barrydoko: have you run the default or 3.3 branch test suite from hg source recently?13:22
dokobarry, yes. well, this is 3.3.1, won't update anymore before the release13:23
barrydoko: the ubuntu buildbots are red for 3.3 and 3.4 unfortunately.13:29
dokobarry, well they are offline ...13:31
barrydoko: i doubt they'd be green if they were online :)13:32
=== wedgwood_away is now known as wedgwood
mdeslaur@pilot out13: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:
tseliotpitti: do you still have the python script to reproduce bug #804662 ?13:56
ubottubug 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/80466213:56
=== kentb-afk is now known as kentb
pittitseliot: no, sorry; should have attached it14:01
tseliotpitti: too bad. I'll try to figure it out from the bug report14:02
pittitseliot: I guess it just called a few functions from NvidiaDetector and printed its results14:04
tseliotpitti: 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 arguments14:07
=== cmagina_away is now known as cmagina
=== Snow-Man_ is now known as Snow-Man
gQuigsis recommending 64 bit (on website) only going to change for a LTS release?14:58
smartboyhwgQuigs, what do you mean?15:00
gQuigsguess I'm wondering if this [1] has been revisited for Raring15:00
gQuigs[1] https://lists.ubuntu.com/archives/ubuntu-devel/2012-April/035054.html15:00
gQuigs64 bit desktop by default15:00
smartboyhwgQuigs, well I think it would be changing for everybody...15:01
gQuigseverybody means both 12.04 and Raring?15:03
cjwatsonFairly sure we're not changing that quite yet15:03
cjwatsonThough it still needs to happen at some point15:04
cjwatsonIt's not necessarily tied to the LTS cycle, though, no15:04
gQuigsthanks cjwatson15:05
gQuigsdo we know what is currently blocking it?15:05
ogra_a TB decision i would guess15:06
ogra_(or was there one ?)15:06
cjwatsonEr, no15:06
cjwatsonIIRC last we checked the resource consumption of 64-bit systems wasn't favourable15:07
xnoxgQuigs: 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
xnoxbut to still keep 32-bit as the default option for raring.15:09
gQuigsxnox: right partly due to EUFI I'm guessing15:12
gQuigsthe 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 way15:13
xnoxhaving 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
bdmurraympt: 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
gQuigsI 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
jdstrandslangasek: 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
jdstrandDaviey: ^15:26
mptbdmurray, 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
jdstrandDaviey: and hi to you too :)15:26
slangasekjdstrand: hmm, not intentional on my part; looking15:26
slangasekjdstrand: I did put 'at' in the server-ship seed, which I thought was correct15:28
slangasekjdstrand: perhaps it was meant to be in 'server' rather than 'server-ship'15:28
jdstrandslangasek: hmm, it doesn't end up installed though15:28
jdstrandslangasek: you did that some time ago, right? my server install is from 2013041015:29
bdmurraympt: great, thanks!15:29
cjwatsonIf you want it installed by default on server it'd need to be in the server seed15:29
psusiubiquity 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
xnoxpsusi: not supposed to, but it currently does for me when trying to install '/' on a fakeraid device.15:36
xnoxpsusi: bug 116736615:37
ubottubug 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/116736615:37
psusixnox: 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 hd15:38
xnoxpsusi: 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
xnoxpsusi: "everything works fine" when booting in UEFI mode though. Try that, if possible on the target machines.15:40
=== pete-woods1 is now known as pete-woods
psusinot 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 order15:41
psusiand I thought ubiquity supposedly handled that15:42
=== mbarnett` is now known as mbarnett
xnoxpsusi: 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 | gQuigs15:53
ubottugQuigs: 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
cjwatsonslangasek might have the most context on this ^-15:54
cjwatsonor cking15:54
stokachubdmurray: do i need to set verified-done and remove -done-{precise,quantal} from bug 101379815:57
ubottubug 1013798 in libgcrypt11 (Ubuntu Oneiric) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,In progress] https://launchpad.net/bugs/101379815:57
stokachunow that both series are verified15:57
bdmurraystokachu: if you look at the pending SRU report you'll see that the bug is green so no it doesn't look like it15:59
stokachubdmurray: ok cool16:00
dokojibel, python3.3 now waiting for approval16:07
=== iulian is now known as Guest6437
jibeldoko, good. there'll be another issue with autopkgtest and python3.3dm because it outputs ref counts to stderr16:24
=== mhall119 is now known as mhall119|lunch
dokojibel, honestly this seems to be a bad assumption in autopkgtest16:26
smbinfinity, Has tomorrow still a chance to be today or will it be today's tomorrow? 3:)16:45
kirklandsmartboyhw: howdy17:10
kirklandsmartboyhw: here now, what's up?17:10
=== mhall119|lunch is now known as mhall119
=== james_ is now known as Guest69845
infinitysmb: That was a convoluted sentence, but I think today is tomorrow.17:41
evmpt: all the difference an order of magnitude makes. I think I found the bug. http://paste.ubuntu.com/5713799/17:47
evgoing to do some more testing though17:47
evmpt: false alarm18:19
=== Guest6437 is now known as iulian
xnoxjibel: we could add a "stderr-no-fail" constraint.....18:36
slangasekjdstrand: 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
=== salem_ is now known as _salem
jdstrandslangasek: right, I gathered that after I read your and colin's comments. are you adjusting the seed or shall I?19:09
slangasekgQuigs: 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 website19:29
gQuigsslangasek: thanks...  are the current numbers public?19:34
slangasekgQuigs: 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 wild19:35
jdstrandslangasek: ok, r2131 does it, so cool. thanks :)19:36
slangasekgQuigs: 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 sources19:37
slangasekjdstrand: ok, great19:37
slangasekjdstrand: so you're the one user of at, eh? :)19:37
infinityI use it...19:38
infinityIt's handy.19:39
jdstrandhoestly, I haven't used it for years, but that doesn't mean that other server admins don't :)19:39
infinityDepends on how far out my needs are.19:39
infinityIf 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
mcantorIs there a channel devoted to developing *ON* Ubuntu?19:40
jdstrandimo, a server is a place where you expect to have certain things like at19:40
gQuigsslangasek: 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
infinitymcantor: The topic claims #ubuntu-app-devel19:41
gQuigsguess I should just ping ubuntu friendly?19:42
mcantorinfinity: Haha, thanks; I saw "Devel of Ubuntu (not support or app devel)" and stopped reading... <.<19:42
infinitygQuigs: 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
slangasekgQuigs: 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 machines19:42
infinitygQuigs: Actual derivatives (like Mint, for instance) wouldn't be counted in any stats we keep.19:42
mcantorHmm. You guys might be able to help me out here anyway.19:43
mcantorWhen 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
gQuigsinfinity: right, sorry I misspoke (typed..)19:43
slangasekmcantor: what exactly is the gcc command you're running?19:44
infinityIt'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
gQuigsslangasek: but wouldn't Ubuntu Friendly have included information from lubuntu/xubuntu ?19:44
infinityNot that they'll go up, but you know what I mean.  They could go drastically down if that wasn't the default ISO. :P19:45
slangasekgQuigs: yes, but it wouldn't call it out separately19:45
infinityIf this is purely about actual hardware stats (cpuinfo, etc), ignore me.19:45
slangasekinfinity: no, the stats we're looking at for this is whether the machines *support* 64-bit.19:45
infinityBut we have a lot less of those.19:45
infinityslangasek: Right, see above.19:45
mcantorslangasek: /usr/bin/c++ [my object files] -m32 `/opt/pym32/python-config --ldflags` -lboost_system -lboost_python -llog4cplus -lfreetype -o executable19:46
slangasekmcantor: and where are you seeing /usr/lib/x86_64-gnu-linux?19:47
mcantorslangasek: 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 line19:47
mcantorslangasek: 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 line19:47
mcantorslangasek: 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
infinitymcantor: But your command line is lacking '-ldl'19:48
mcantorinfinity: Sorry--"-ldl" is in the output of `/opt/pym32/bin/python-config --ldflags`.19:48
mcantorinfinity: 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
jtayloris that after the object files? libraries before them are dropped due to ubuntus use of ld --as-needed19:50
jtayloralso if you get that message you should not rely on getting ldl form python-config19:51
infinityjtaylor: According to his paste, it is.19:51
jtayloras you need it directly19:51
mcantorjtaylor: Pasting the output of python-config directly into my Makefile has the same results19:51
mcantorjtaylor: 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
mcantorjtaylor: It is after the object files, though.19:52
jtaylorhm it might need to be after boost19:54
jtaylorI recall some weirdness with boost_system19:54
jtaylortry adding a -ldl after the -lboost_system19:54
mcantorjtaylor: I've heard furtive whisperings and conspiracies that the linker is very sensitive to the order of link flags... I'll give that a shot19:54
jtaylorit is19:54
=== _salem is now known as salem_
mcantorjtaylor: No dice19:57
slangasekmcantor: and you have the g++-multilib package installed?19:58
mcantorjtaylor: infinity: Here's the exact error I'm getting: http://pastebin.com/ZgBj4fUi19:58
mcantorslangasek: Indeed.19:58
jtayloroh static libpython19:59
mcantorslangasek: Should I specifically *NOT* have ia32-libs installed?19:59
jtaylorthen --ldflags output is wrong19:59
jtaylorthe -ldl must be behind the -lpython2.719:59
mcantorjtaylor: You're kidding--python-config itself is giving me bad output?19:59
jtaylorseems so19:59
mcantorjtaylor: I'll try it, but fwiw, adding /usr/lib/i386-gnu-linux/libdl.so to the *END* of the command line worked before20:00
jtaylorthat should work, but the linker works in mysterious ways20:00
mcantorjtaylor: wait a tick... -ldl is already before -lpython2.720:01
jtaylorbehind lpython2.720:01
jtaylorworst case add -Wl,--add-nedded20:01
jtaylorthat will shut this warning up20:02
mlankhorstisn't it -Wl,-as-needed?20:02
mcantorjtaylor: By "behind" do you mean "after"?20:02
jtaylorthis 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 Work20:02
jtaylor-lpython2.7 -ldl20:02
mcantortrying that now20:03
mcantorPerhaps I should file a bug with Python since it is providing a bad command line20:03
GunnarHjslangasek: 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
mcantorI'll be damned. It worked.20:03
jtaylorits only bad with static python20:03
jtaylorif libpython is shared it works in wrong order too20:03
jtaylorbut yes file a bug please20:04
slangasekif libpython is shared, the -ldl is unnecessary and redundant on Linux20:04
mcantorjtaylor: 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
jtaylorif you don't need it directly yourself20:04
jtaylorits a side effect of ld --as-needed20:04
jtaylorit sees libdl, nothing needs it, it forgets about it20:05
mlankhorstit matters mostly for static libs20:05
jtaylorthen it seens libpython, its needed and now you are screwed20:05
mcantorahhhh, ok20:05
slangasekGunnarHj: 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 skype20:05
jtaylorits a ubuntu/mandriva specific problem20:06
jtaylorother distributions don't enable as-needed by default20:06
GunnarHjslangasek: Ok, thanks for letting me know.20:06
mcantorjtaylor: I see, thanks so much for the explanation and help!20:07
cjwatsonand opensuse20:07
jtaylorreally? I think I haven't seen it on 12.120:07
cjwatsonwell, so said http://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries anyway20:07
jtayloron the other hand my makefiles are all well behaved ;)20:08
mcantorjtaylor: so why does this behavior screw up with a static library? can ld "not see" the required symbols?20:09
jtaylorld goes through them from left to right, it can't go back to elements it has already checked20:09
jtaylor(unless you tell it to with -start-group)20:10
mlankhorsteven that screws up, though20:10
mcantorjtaylor: wouldn't it have the same problem if python was a dynamic library, though?20:10
mcantorat the time it saw -ldl, it would still think "Nope, I have nothing that needs this"20:10
jtaylorthat somehow works different, don't ask me why :)20:10
mcantorhahaha, ok, that's what I was specifically wondering about. XD20:10
jtaylorI never udnerstood why order on the commandline matters20:10
mlankhorstbecause computers are dumb20:11
jtaylorbut I'm sure there are good reasons20:11
jtaylormakes it slow on old Z3 machines or so :)20:11
mcantorgreat reasons, of course20:11
slangasekmcantor: 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 against20:16
mcantorslangasek: Ah, that makes sense. It just goes and finds it at runtime like usual.20:16
cjwatsonthe 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 used20:18
cjwatson--as-needed is more efficient at runtime and makes library transitions less complex in cases of indirect linkage20:20
cjwatson(--no-copy-dt-needed-entries also contributes to this)20:20
jtaylorits 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
jtaylorI could guess memory issues?20:21
cjwatsonwell, order-dependent is the traditional Unix behaviour, and indeed there are cases where linker memory use is a serious problem20:21
cjwatsonI'm not certain that a cleaning phase could be implemented correctly, but I'm also not a linker expert :)20:22
mcantorI filed a bug with python here btw, for any interested http://bugs.python.org/issue1776920:22
mcantorcjwatson: 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
cjwatsonWell, sure20:24
cjwatsonI agree python-config --ldflags looks backwards20:26
jtaylorit also shouldn'T be ldflags :/20:26
mcantorjtaylor: Why not..?20:27
jtaylorthen people put it into autotools LDFLAGS and you have the same problem for your own object files20:27
mcantorah, I don't know autotools20:27
jtaylorautotools LDFLAGS is placed before your object files, so it forgets all the libraries listed in them20:27
cjwatsonFWIW, 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
jtaylorthe right variable is LIBS20:27
mcantorjtaylor: python-config has a --libs flag, too, but the output is different20:27
cjwatsonI 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
mcantorcjwatson: that makes sense.20:27
cjwatsonjtaylor: It's not just autotools; make's implicit rules treat LDFLAGS and LDLIBS separately in much the same way20:28
mcantorI didn't know LDLIBS was another automatic variable used by Make20:28
cjwatson(CC) $(LDFLAGS) N.o $(LOADLIBES) $(LDLIBS)20:29
cjwatsonwith a $ at the start too20:30
jtayloralso LDADD and LIBADD, for libtool based autotools ._.20:30
mcantorWhat is LOADLIBS?20:31
cjwatsonLDADD is automake20:31
cjwatsonmcantor: thread starting https://lists.gnu.org/archive/html/help-make/2005-01/msg00062.html20:32
cjwatson(LOADLIBES is not a typo, or at least if it is it's not mine ...)20:32
mcantorOh. Hahaha20: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-phoneHew: thnx22:05
=== kentb is now known as kentb-out
=== davidm` is now known as davidm
csederWow! What a user count for a developers group!22:15
csederActive community for sure.22:15
csederGuess 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
cjwatsoncseder: welcome :-)  https://wiki.ubuntu.com/ContributeToUbuntu if you haven't seen it22:22
csederSo I'll be doing some development on my spare time...22:23
csederI guess I'll just SVN the source tree?22:24
csederOr maybe just read the Wiki first… ;-)22:25
cjwatsonThere isn't a single source tree22:25
csederthe source tree for my parts of interest was what I meant.22:26
cjwatsonAh, yeah22:26
cjwatsonIf you already have an idea what you want to work on, then sure22:26
csederWell, I've done a bit of this and that, so I'll just check out what's needed and pick from that22:27
csederMainly C, C++ and C#, but a tiny bit of Python also22:28
csederMost administrative scripts in Python, so I won't do that in the first round...22:28
csederHaha… Now my Ubuntu installer just crashed. Maybe start there! ;-) kidding22:29
* infinity is still trying to find someone to talk into porting apport from Python to C/C++.22:31
csederProbably a good idea22:32
csederI'm not very fond of using python for main programming tasks. It's ok as a glue.22:32
csederBut I guess Ubuntu uses a lot of Python…22:34
cjwatsonYou can find lots of almost any language you care to name, really22:36
dokojibel, 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
cjwatsonMost 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
csedercjwatson: guess it depends on the variations of Ubuntu as well… kUbuntu xUbuntu and the ilkes22:39
csederThat's what I'll miss from FreeBSD. One distribution. But then again there are other things I won't miss...22:41
cjwatsonIt's still all one archive22:42
cjwatsonAt a technical level, Kubuntu and Xubuntu are essentially just different sets of packages (and associated images) within the Ubuntu archive22:43

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!