| cjwatson | sarnold: not the same situation, but there are multiple causes, I guess | 00:05 |
|---|---|---|
| === wedgwood is now known as wedgwood_away | ||
| hallyn | Daviey: around? | 01:21 |
| infinity | Uhm. What just spawned Ubuntu Core Installer from its postinst? :P | 01:55 |
| sarnold | infinity: funny, cjwa tson and dob ey were mentioning it earlier.. | 01:57 |
| infinity | Yeah, I'm going to fix this with fire right now. | 01:57 |
| * sarnold gets his ovegloves out | 01:58 | |
| hallyn | jamespage: is there a way to have the server seed depend on 'qemu-system-$arch' ? (new qemu will have separate qemu-system-x86, qemu-system-ppc, qemu-system-arm, etc; qemu-kvm depends on qemu-common which will depend on all of them) | 02:09 |
| infinity | hallyn: Sure. | 02:09 |
| hallyn | infinity: I'm still ironing out the details on the new qemu merge from debian, but when I push that qemu-system-x86 will be a new package containing only files from qemu-system (which is in main) - will it be hard to get into main? | 02:12 |
| infinity | No, splits don't need an MIR. | 02:12 |
| hallyn | phew | 02:12 |
| infinity | And you'd want seeds something like this (adjusted for whatever the actual truth is): | 02:12 |
| infinity | * qemu-system-ppc [powerpc ppc64] | 02:12 |
| infinity | * qemu-system-arm [armel armhf arm64] | 02:12 |
| hallyn | ah cool | 02:13 |
| infinity | * qemu-system-x86 [i386 amd64 x32] | 02:13 |
| hallyn | so just like you do in a debian/control :) | 02:13 |
| infinity | Pretty much. | 02:13 |
| hallyn | thx | 02:13 |
| infinity | Plenty of examples of this in the seeds currenty. | 02:13 |
| hallyn | that should reduce the size of the server seed a bit, | 02:13 |
| hallyn | but theni still need to figure out why oh why qemu-system is depending on libgl1-mesa-glx | libgl1 all of a sudden | 02:13 |
| infinity | spice? | 02:13 |
| infinity | Or is this pre-spice-enabling? | 02:14 |
| hallyn | pre-spice | 02:14 |
| infinity | Oh, indeed. | 02:14 |
| hallyn | feh, i do hope spice won't add that, that could suck | 02:14 |
| infinity | Every single qemu-system-* has a libgl dep. | 02:16 |
| infinity | And given our aggressive use of --as-needed, that probably means they actually use symbols from it. | 02:16 |
| infinity | Unless there's some gross hand-made linking going on. | 02:16 |
| hallyn | is that libglib-2.0.so.0 ? | 02:17 |
| infinity | Oh, my grep might be bad. :P | 02:17 |
| hallyn | right i don't actually see a 'libgl' as such, or any *mesa* or *qxl | 02:17 |
| infinity | /usr/bin/qemu-system-lm32 is the only one. | 02:18 |
| infinity | (base)adconrad@cthulhu:~$ for i in `dpkg -L qemu-system` ; do if ldd $i 2>/dev/null| grep -q libGL; then echo $i; fi; done | 02:18 |
| infinity | /usr/bin/qemu-system-lm32 | 02:18 |
| infinity | (base)adconrad@cthulhu:~$ | 02:18 |
| infinity | I always forget it's uppercase GL. | 02:18 |
| hallyn | <scowl> | 02:18 |
| infinity | That's sort of a self-solving problem after the split. | 02:19 |
| infinity | Assuming lm32 isn't one you care about. :P | 02:19 |
| infinity | Whatever it is... | 02:19 |
| hallyn | right it's not :) | 02:19 |
| hallyn | but libGL comes from nvidia for me | 02:20 |
| infinity | lm32-uclinux lm32 platform for uClinux and u-boot by Theobroma Systems | 02:20 |
| infinity | lm32-evr LatticeMico32 EVR32 eval system (default) | 02:20 |
| infinity | milkymist Milkymist One | 02:20 |
| vibhav | libxcb test cases completed \o/ | 02:20 |
| infinity | Well, yes. Your libGL comes from nvidia cause you have the nvidia drivers installed, so? | 02:20 |
| vibhav | pitti: ^^ | 02:20 |
| hallyn | infinity: I'm still just trying to figure out what libgl1-mesa-glx is | 02:21 |
| infinity | hallyn: It's libGL. | 02:21 |
| hallyn | all right | 02:21 |
| * hallyn checks where lm32 falls in the split - hopefully qemu-system-misc | 02:21 | |
| infinity | hallyn: Your dep is "libgl1-mesa-glx | libgl1", and binary drivers all provide the latter and use alternatives. | 02:21 |
| vibhav | pitti: I will request a branch merge after I come from school, the bus is here | 02:22 |
| hallyn | infinity: ah, i see | 02:22 |
| hallyn | infinity: phew, yeah, it's in -misc, so that may solve that | 02:22 |
| infinity | hallyn: Unless spice uses GL. ;) | 02:22 |
| infinity | hallyn: Well, spice would be its own package too, I'm guessing, a second build of x86? | 02:23 |
| infinity | hallyn: Or is Debian just building it in? | 02:23 |
| infinity | Hrm, guessing spice is just built in to x86. | 02:23 |
| === zz_Jacky_ is now known as jackyalcine | ||
| * infinity looks at how that pans out. | 02:24 | |
| hallyn | yeah i guess we should b eable to tell by looking at the debian-experimental packages | 02:24 |
| infinity | Which I just did. | 02:25 |
| infinity | And I guess it's not a big deal. | 02:25 |
| === jackyalcine is now known as Jacky_ | ||
| infinity | I was going to bitch about how spice would pull in all those useless X11 deps. But qemu-system does that ANYWAY. | 02:25 |
| hallyn | right, qemu-kvm shoudl always have done that too, bc it built in sdl | 02:25 |
| infinity | Because it's such a wonderfully modular design, so well-suited to masquerading as a lightweight hypervisor. | 02:25 |
| infinity | </sarcasm> | 02:25 |
| hallyn | and sdl never works right anyway | 02:26 |
| === Jacky_ is now known as zz_Jacky_ | ||
| hallyn | maybe we can add a qemu-kvm-barebones | 02:26 |
| hallyn | infinity: ok, so spice in debian doesn't add libGL? | 02:26 |
| hallyn | infinity: (bc it is a big deal due to bug 1118407) | 02:26 |
| ubottu | bug 1118407 in qemu (Ubuntu Raring) "qemu-kvm/system has a large number of dependencies" [High,Triaged] https://launchpad.net/bugs/1118407 | 02:26 |
| infinity | Isn't what qemu-kvm *was* before we decided to just use system? | 02:26 |
| hallyn | rephrase? | 02:27 |
| infinity | Oh, no, kvm built with sdl too. | 02:27 |
| infinity | Nevermind. | 02:27 |
| hallyn | right | 02:27 |
| hallyn | gah. biab | 02:27 |
| infinity | So, yeah. It would be nice to have something targetted at servers. | 02:27 |
| infinity | It would be so much better if it had a modular/plugin system. :/ | 02:28 |
| infinity | So you could have the base installed and then say "actually, I'd like some X graphics with that, too... Or spicy acceleration... Or sound... Or whatever) | 02:29 |
| infinity | Though, I guess all anyone really needs is the "nothing but barebones kvm/paravirt with no GUI and sound stuff" and "the kitchen sink". | 02:29 |
| === zz_Jacky_ is now known as jackyalcine | ||
| === jackyalcine is now known as Jacky_ | ||
| infinity | hallyn: Oh, speaking of qemu, IS needs a patch in your next upload. | 02:31 |
| infinity | hallyn: https://launchpadlibrarian.net/93501920/qemu-linaro-921078.patch got dropped when the great merge happened. | 02:32 |
| infinity | hallyn: Given that 2.6.32 is the baseline for experimental's glibc as well, it may pay to just push this to Debian. Or we can carry it locally. Whichever. | 02:33 |
| infinity | hallyn: So, when that patch got dropped and they rolled out a new backport, all the ARM PPAs broke. Well done. | 02:33 |
| RAOF | Hm. Library versioning question: if liba takes some symbols and puts them in liba-private, with liba depending on liba-private (so the the union of symbols in the new liba + liba-private is a strict superset of the symbols in the previous liba), does this break ABI? My guess is yes, but it seems empirically to not break ABI. | 02:35 |
| infinity | RAOF: Nope. | 02:35 |
| infinity | RAOF: Not on GNU/Linux anyway. It all resolves sanely and it's like nothing happened. | 02:36 |
| infinity | RAOF: Of course, that also means liba-private isn't private. | 02:36 |
| infinity | RAOF: If its symbols are exported and accessible through linking liba. | 02:36 |
| infinity | win 301 | 02:36 |
| RAOF | Yeah. A better name for it could be "liba-minus-the-glib-bits" | 02:36 |
| infinity | Heh. | 02:37 |
| RAOF | infinity: Ta. The obvious case is "it works", but I wasn't sure if there were some funky dlopen options you could wrangle to only see symbols directly from the library you're dlopening. | 02:37 |
| infinity | But if liba depends on liba-glib-bits, why bother with the split? | 02:37 |
| infinity | If you dlopen() liba and it links liba-whatever, you'll get whatever with it. | 02:37 |
| RAOF | Because other things can depend on liba-minus-glib-bits, I think. | 02:38 |
| infinity | Note that I said dlopen() intentionally there. There are non-dlopen dlopen-alike implementations that screw this up. But glibc doesn't. | 02:38 |
| infinity | (be wary of ctypes) | 02:38 |
| infinity | Anything using glibc's linkers (dlopen() or ld.so via direct linking) will be fine. | 02:39 |
| infinity | And anyone else is doing it wrong. | 02:39 |
| infinity | QED. | 02:39 |
| RAOF | Eh. This has an accompanying gir; I don't think anyone sane will be ctypesing it. | 02:39 |
| hallyn | infinity: oh, never heard of that patch. oh i see it wasn't in qemu-kvm... | 02:52 |
| hallyn | infinity: should that only be for arm targets? | 02:52 |
| infinity | hallyn: The same misfeature applies to all qemu-user-static builds, it's hard an ARM issue. | 02:52 |
| infinity | hallyn: Without declaring a uname at build time, it just passes through the system's uname. | 02:53 |
| hallyn | oh. i see. which'll be 2.6.23 or something for hardy :) | 02:53 |
| infinity | hallyn: Which is a blatant lie (the syscall emulation doesn't relate at all to the system kernel), and is also rather problematic in some cases. | 02:53 |
| infinity | 2.6.24 | 02:53 |
| hallyn | i was close! | 02:53 |
| infinity | But same problem in the other direction. The syscall emulation isn't ever up to date with linux mainline, so 3.8.0 is just as much a lie. | 02:53 |
| infinity | And 3.8.0 is what my raring system will say running uname under qemu-user-whatever. | 02:54 |
| hallyn | ok, i'm getting clsoe to pushing, lemme toss taht patch backin tehre realy quick | 02:54 |
| === pcarrier_ is now known as pcarrier | ||
| hallyn | trying to tell if that flag is safe for system builds | 03:02 |
| === jono is now known as Guest51 | ||
| === jbicha is now known as Guest80174 | ||
| === StevenK is now known as Guest40324 | ||
| === Guest80174 is now known as jbicha_ | ||
| === emma is now known as em | ||
| hallyn | Daviey: jamespage: infinity: mjt: ok, the qemu built from https://github.com/hallyn/qemu/tree/de.jan28.ubuntu2.nixdoc seems to do all the right things for me. In the morning i'll try a quantal->raring upgrade with it, then probably push it to raring. | 04:44 |
| hallyn | (should fix the two bugs jamespage filed today) | 04:45 |
| * hallyn out | 04:45 | |
| * shuduo is away: auto-away | 04:58 | |
| * shuduo is back (gone 00:07:21) | 05:05 | |
| === Jacky_ is now known as zz_Jacky_ | ||
| === zz_Jacky_ is now known as jackyalcine | ||
| === jackyalcine is now known as Jacky_ | ||
| pitti | Good morning | 05:27 |
| pitti | vibhav: awesome! | 05:27 |
| * shuduo is away: auto-away | 05:38 | |
| === Jacky_ is now known as zz_Jacky_ | ||
| === zz_Jacky_ is now known as jackyalcine | ||
| LantzR | Hiya | 05:49 |
| * shuduo is back (gone 00:17:53) | 05:56 | |
| === Guest40324 is now known as StevenK | ||
| === amitk is now known as amitk-afk | ||
| dholbach | good morning | 07:27 |
| === jackyalcine is now known as zz_jackyalcine | ||
| === chiluk is now known as chiluk_away | ||
| dholbach | highvoltage, happy birthday! :) | 08:18 |
| highvoltage | thanks, dholbach! | 08:23 |
| dholbach | :) | 08:23 |
| mitya57 | highvoltage: happy birthday and congrats with becoming a gnome-panel maintainer! :) | 08:24 |
| === yofel_ is now known as yofel | ||
| === amitk-afk is now known as amitk | ||
| seb128 | dholbach, hey, udd question ... will those uploads you did lead to the udd merge request to autoclose if you just dput and didn't bzr merge & push? or should they be set to merged manually? | 08:51 |
| dholbach | I think they won't close | 08:52 |
| dholbach | I was just waiting for them to be merged | 08:53 |
| seb128 | dholbach, ok, works for me, I usually set them as merged when I dput so I don't forget but I was wondering if I was overlooking some autoclosing magic on the udd side ;-) | 08:53 |
| dholbach | ok | 08:54 |
| seb128 | dholbach, when is Logan's application going to be reviewed for MOTU btw? ;-) | 08:54 |
| dholbach | seb128, according to https://lists.ubuntu.com/archives/devel-permissions/2013-February/000445.html it's on 25 Feb | 08:54 |
| seb128 | great | 08:55 |
| seb128 | dholbach, danke! | 08:55 |
| dholbach | I feel good now, I just translated a page on https://translations.launchpad.net/ubuntu-packaging-guide/trunk and reviewed 2 pages of translations suggestions | 08:56 |
| === henrix_` is now known as henrix | ||
| vibhav | pitti: ping | 09:52 |
| pitti | hey vibhav | 09:53 |
| vibhav | After compilation, how do I run Xvfb and the test together? | 09:53 |
| pitti | vibhav: xvfb-run yourtestprogram | 09:54 |
| vibhav | Can xvfb run in the background? | 09:54 |
| pitti | xvfb-run does all that for you | 09:56 |
| vibhav | pitti: What about the parameters to Xvfb? | 09:56 |
| pitti | you don't usually need parameters | 09:56 |
| vibhav | Perfect | 09:56 |
| vibhav | So screen is :0 , right | 09:56 |
| pitti | vibhav: no, xvfb-run will use :99 by default | 09:58 |
| pitti | but it sets $DISPLAY | 09:58 |
| pitti | so you can do "xvfb-run xeyes" and everything will work | 09:59 |
| vibhav | Ah | 09:59 |
| lifeless | Just Work in fact | 09:59 |
| vibhav | Good | 09:59 |
| vibhav | So I refine it and then request a merge | 10:00 |
| vibhav | I will* | 10:00 |
| Gwaihir | hello, got a question about a Python bug, https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1119195 fixed upstream, what is the process to get it included in 12.04? | 10:03 |
| ubottu | Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New] | 10:03 |
| vibhav | !sru | Gwaihir | 10:04 |
| ubottu | Gwaihir: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 10:04 |
| Gwaihir | thanks vibhav | 10:06 |
| vibhav | No problems | 10:06 |
| jrp | Hi, Im compiling some software and Im curious. Why arent ubuntu packages compiled with -fPIC? | 10:25 |
| jrp | examples include: libssl.a, libc.a, and libz.a | 10:25 |
| mjt | because you've libssl.so, libc.so, libz.so etc | 10:27 |
| mjt | if you compile your prog dynamically, use these. if you compile it statically, use libz.a etc but in this case you don't need -fPIC. | 10:27 |
| jrp | Im trying to create a shared lib thats statically linked if that makes sense, in which case I do need -fPIC | 10:28 |
| mjt | static lib compiled with -fPIC makes sence if you include that static libs into shared libs | 10:28 |
| mjt | heh | 10:28 |
| jrp | yeeeep. | 10:28 |
| mjt | as i said, do not do it, use real shared libs. | 10:28 |
| xnox | jrp: that's not supported on debian/ubuntu. | 10:29 |
| xnox | jrp: you can recompile libraries in question and then you can do it. | 10:29 |
| xnox | aka in a ppa. | 10:29 |
| jrp | is there anyway I can create a staticly linked library out of shared libraries? | 10:29 |
| jrp | xnox: yeah, im recompiling glibc now :\ | 10:29 |
| mjt | static libs are already very questionable things, but it really is sometimes necessary to build static apps sometimes. | 10:30 |
| xnox | jrp: do not use it, unless all the test-suites pass. | 10:30 |
| cjwatson | statically linking glibc is very unwise. | 10:30 |
| mjt | but embedding a static lib (especially such common ones like glibc(!!) and libz) is really insane. | 10:30 |
| cjwatson | and we went to serious effort to hunt-and-destroy instances of static linking of libz a security vulnerability or two ago. | 10:31 |
| jrp | Im very far down a rabit hole, I really just need a shared library with statically linked libcurl | 10:31 |
| mjt | hahaha | 10:31 |
| mjt | http://curl.haxx.se/docs/adv_20130206.html -- fresh curl security hole for you | 10:32 |
| jrp | i saw | 10:32 |
| jrp | would it improve things at all if i said it was a research project PoC and not for a production system? I understand why statically linking things is such a horrible idea from a security perspective | 10:33 |
| mjt | it is really a bad taste to help to do such a bad thing. | 10:33 |
| cjwatson | jrp: it's not going to persuade us to offer the facility widely, I'm afraid, because it's just too tempting to misuse | 10:33 |
| mjt | and it always starts from research/PoC thing, and spreads from there... | 10:33 |
| cjwatson | jrp: that said, you'll find some -pic variants of libraries, which exist for special purposes - for example libc6-pic | 10:33 |
| mjt | cjwatson: what purposes are these? | 10:34 |
| jrp | cjwatson: thats incredibly helpful | 10:34 |
| cjwatson | mjt: installer | 10:34 |
| mjt | ubuntu uses its own installer? | 10:34 |
| cjwatson | scary library reduction thing which really ought to be replaced now that we have sane udeb shlibdeps, but ... | 10:34 |
| cjwatson | mjt: no, d-di | 10:34 |
| cjwatson | *d-i | 10:34 |
| cjwatson | mjt: libc6-pic is in Debian too | 10:35 |
| mjt | yeah, d-i and reduction. i remember now. | 10:35 |
| jrp | I mean, if youd like Id happily explain my project briefly and if theses a better way to do it Ill happily switch to it. Im very much stumbling through things as I go | 10:35 |
| cjwatson | we wouldn't have introduced it ourselves | 10:35 |
| mjt | d-i is an evil thing anyway :) | 10:35 |
| cjwatson | nah, it's lovely and fluffy | 10:35 |
| cjwatson | admittedly there is a core of complex evil | 10:35 |
| * mjt , being one of the d-i team, hides and runs away | 10:35 | |
| cjwatson | well, likewise :) | 10:36 |
| mjt | but i don't do much there, only busybox | 10:36 |
| mjt | (maybe it's time to stop caring about lib size reduction, -- we use DVDs with much larger size and alot more packages these days, so the difference in size between reduced and regular libc.so makes no sence at all) | 10:38 |
| jrp | well, thank you guys very much for the help, i appreciate it | 10:39 |
| cjwatson | jrp: In general the better way is just to use ordinary dynamic linking and have dependencies to ensure that the proper shared libraries are present ... | 10:40 |
| jrp | cjwatson: Im building something which will be executed through LD_PRELOAD (which I know is also evil) | 10:40 |
| cjwatson | I wasn't aware that LD_PRELOAD disregarded indirect linkage? | 10:40 |
| mjt | wow. linking libc statically into LD_PRELOADed object may have... interesting effects. | 10:40 |
| mjt | ;) | 10:40 |
| cjwatson | Quite, you'll probably end up with a sea of symbol conflicts and consequent segfaults | 10:41 |
| jrp | ok, backing up some more. Im hooking connect() using LD_PRELOAD, then trying to use libcurl to send data off | 10:41 |
| cjwatson | http://stackoverflow.com/questions/4385155/setting-my-lib-for-ld-preload-makes-some-processes-produce-loader-errors implies that dynamically-linking a preloaded library works fine | 10:42 |
| jrp | Im concerned that libcurl will see my not-real-connect, as opposed to real connect | 10:42 |
| jrp | does that make any sense? | 10:43 |
| cjwatson | I think what you want is to build a shared libcurl without -Bsymbolic-functions | 10:44 |
| mjt | you'll have to implement all read/recvfrom/etc stuff too | 10:44 |
| cjwatson | Let me check what our curl is built with | 10:44 |
| mjt | (or just fork a child process linked with curl, and return a real socket fd from socketpair) | 10:45 |
| mjt | that might be a ton easier and safer | 10:45 |
| jrp | Im trying to avoid forking, I have it working now in a fashion via fork/exec | 10:45 |
| cjwatson | Yeah, our curl's linked with -Bsymbolic-functions, so you'd need to undo that in order to be able to override symbols therein using LD_PRELOAD. Or mjt's solution would work too. | 10:46 |
| jrp | but id like to avoi the process overhead | 10:46 |
| cjwatson | A bit of a hassle but almost certainly less painful than static linking. | 10:46 |
| jrp | Uh, so Im sure were on the same page. I -want- curl to use the system's connect() | 10:46 |
| cjwatson | Oh, ISWYM | 10:47 |
| jrp | so Im trying to statically link curl so it -wont- hit my connect/getaddrinfo/gethostbyname | 10:47 |
| cjwatson | Ah, no, -Bsymbolic-functions doesn't apply because connect isn't within the library | 10:47 |
| cjwatson | jrp: Sounds like sledgehammer and nut ... | 10:47 |
| jrp | cjwatson: As I said, Im stumbling through it, down a rabit hole. Im 100% open to smaller hammers | 10:48 |
| mjt | write a small daemon that does your curl work and connect to it from ld_preload | 10:48 |
| mjt | to avoid forking overhead | 10:48 |
| jrp | hm, thats a very good idea | 10:49 |
| mjt | tons of possibilities, embedding stuff into ld_preload seems like one of the worst solutions | 10:49 |
| jrp | when all you have is a hammer... I dont know why I didnt think of a daemon | 10:50 |
| * cjwatson tries to remember details of symbol resolution rules | 10:50 | |
| jrp | it makes me feel marginally better that all this isnt super obvious | 10:51 |
| cjwatson | jrp: Here's another possibility (probably at the very least glibc-specific and possibly Linux-specific): http://paste.ubuntu.com/1623988/ | 11:17 |
| cjwatson | jrp: (Actually, make the "int (*connect_real)" line "static int ..." instead for efficiency, I missed that bit) | 11:18 |
| jrp | ...wow. seriously, thank you so much. | 11:19 |
| cjwatson | bar.c here is of course a stub taking the place of libcurl | 11:20 |
| jrp | yeah | 11:20 |
| pitti | tjaalton: could you please have a quick look at https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-gtk-/129/artifact/gtk+.log ? that's a very recent failure, does that ring a bell? | 11:23 |
| pitti | tjaalton: it still worked on Feb 6, failed on Feb 7 | 11:23 |
| pitti | https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-mutter/101/artifact/mutter.log fails in the same way | 11:24 |
| pitti | error: conflicting types for 'BarrierEventID' | 11:24 |
| tjaalton | pitti: needs a rebuild, I've uploaded a new libxi last night | 11:25 |
| pitti | tjaalton: oh, is that 2:1.6.99.1-0ubuntu2 | 11:25 |
| tjaalton | yes | 11:25 |
| pitti | tjaalton: thanks, sorry for the noise | 11:25 |
| tjaalton | sorry for pushing the original one to raring and not the staging ppa ;) | 11:25 |
| pitti | can't escape Jenkins :) | 11:26 |
| tjaalton | :) | 11:26 |
| cjwatson | jrp: ... and no problem, it was an excuse to try to remember this stuff | 11:27 |
| jrp | cjwatson: is theres a source youd recommend for understanding what -Bsymbolic-functions does? | 11:29 |
| cjwatson | When creating a shared library, bind references to global function | 11:30 |
| cjwatson | symbols to the definition within the shared library, if any. | 11:30 |
| cjwatson | is what 'info ld' says | 11:30 |
| cjwatson | In other words: normally something earlier in the link (the main program, a library loaded earlier, or an LD_PRELOAD) gets to override symbols in any libraries linked later | 11:31 |
| cjwatson | So if you have a "malloc" symbol in your program then that also overrides malloc for any libraries it loads | 11:31 |
| cjwatson | Actually, sorry, that's misleading | 11:32 |
| cjwatson | Let's say you have a curl_getenv symbol in your main program - that would ordinarily override the one in libcurl | 11:33 |
| cjwatson | But if libcurl is linked with -Bsymbolic-functions, the linker looks for any internal function calls within the library (that is, calls from one function in the library to another) and rather than leaving those symbols to be resolved when the whole program is loaded, it resolves them all in advance in libcurl.so | 11:35 |
| cjwatson | This has the downside that you can't then override those symbols with LD_PRELOAD (so we don't use -Bsymbolic-functions for libraries like libc where you commonly want to preload their symbols), but it has the advantage that the dynamic linker has to do many fewer relocations when loading a program, so it makes program execution more efficient, especially for programs involving many libraries such as you find on the desktop | 11:37 |
| cjwatson | Does that help? | 11:37 |
| jrp | yes, very much | 11:37 |
| jrp | ok, Im trying to make sure I understand this. main calls connect, which gets sent off to libfoo.so. libfoo passes it to inner connect in libbar, which actually sends it back to libfoo. But because the inner val is different, we now execute real connect, flip inner back, and return | 11:40 |
| cjwatson | Right, and because inner is static its value is saved across invocations | 11:41 |
| jrp | yep | 11:41 |
| Gwaihir | hi, can anybody give an update on this bug? https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1077153 there's a comment for precise, but I cannot find an updated package with that fix... | 11:42 |
| cjwatson | So the preloaded connect gets to communicate with recursive calls to itself | 11:42 |
| ubottu | Ubuntu bug 1077153 in python2.7 (Ubuntu Precise) "Backport request: http://bugs.python.org/issue14308" [Undecided,Triaged] | 11:42 |
| cjwatson | The RTLD_NEXT trick is the glibc-specific bit, I believe | 11:42 |
| jrp | yeah, it is | 11:42 |
| cjwatson | Hence #define _GNU_SOURCE | 11:42 |
| jrp | yep | 11:42 |
| jrp | if youre going to do that btw | 11:42 |
| jrp | well, i gues you couldnt matke it static then | 11:43 |
| cjwatson | make which static? | 11:43 |
| jrp | but typeof(connect) connect_real | 11:43 |
| cjwatson | oh, yeah | 11:43 |
| jrp | makes the function pointer syntax less obnoxious | 11:43 |
| cjwatson | I figured it didn't really matter since we already need to know the type for the wrapper function | 11:43 |
| jrp | yeah | 11:43 |
| cjwatson | But feel free to polish further :) | 11:43 |
| jrp | ok, so Im still missing something here I think | 11:44 |
| jrp | lets say bar.c is our program which uses libcurl. wont it still hit connect in libfoo? | 11:44 |
| cjwatson | Is libcurl being used in the main program as well as in the preloaded wrapper? | 11:45 |
| jrp | possibly | 11:45 |
| jrp | well, yes, it will be | 11:45 |
| jrp | in some cases | 11:45 |
| cjwatson | You'll have to figure out when you want your wrapper to take effect and when you don't | 11:45 |
| cjwatson | But you should have enough flexibility this way to vary the policy | 11:45 |
| cjwatson | If all else fails you could wrap curl functions just for the purpose of noticing that you'd entered them ... | 11:46 |
| cjwatson | (You'd need a file-scope static variable then) | 11:46 |
| jrp | yeah, ok | 11:46 |
| jrp | that makes sense | 11:46 |
| jrp | heh, christ what a PITA :) | 11:46 |
| xnox | Gwaihir: well precise has 2.7.3 not sure which patchlevel. Do you have a link to the commit on 2.7 branch handy? There should be 2.7.4 soon, is that patch included? | 11:47 |
| Gwaihir | xnox, upstream commit link is this one: http://hg.python.org/cpython/rev/ab9d6c4907e7 | 11:48 |
| Gwaihir | xnox, as far as I know it should be in upstream 2.7.4, but is 2.7.4 going to be available in precise too? | 11:49 |
| jrp | cjwatson: hm, I think the easiest way is just going to be to wrap the curl_execute functions with something like your inner var | 11:52 |
| jrp | cjwatson: because all my functions call their real versions | 11:53 |
| pitti | vibhav: meh, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-ncurses/1/ARCH=i386,label=adt/ fails | 11:53 |
| jrp | cjwatson: and return the same results, they just perform some db operations along the way | 11:53 |
| pitti | vibhav: that may be because the test doesn't actually have a stdout/stderr? | 11:53 |
| xnox | Gwaihir: well we are currently packaging the tip of 2.7 branch in raring. And I don't see past history of uploading python micro-releases. But since 2.7 is the last one..... | 11:59 |
| xnox | Gwaihir: i think it's safer to cherry pick that one patch as an SRU. Please follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template on the bug report. with pointers upstream and then we can SRU that. | 12:00 |
| cjwatson | jrp: *nod* makes sense | 12:00 |
| Gwaihir | xnox, ack | 12:01 |
| xnox | pitti: did any body write UDisks2 template for dbus-mock yet? | 12:02 |
| pitti | xnox: not that I know of | 12:02 |
| xnox | pitti: ok. I ported usb-creator to UDisks2, but I don't trust it. Looked into porting the test-suite and it seems like dbus-mock would be more extensive and easier to use. Considering that I also want to test our own (usbcreator) helper as well. | 12:03 |
| pitti | xnox: yeah, and might be useful for other tests, too | 12:04 |
| pitti | xnox: "trust" in which sense? fails in tests? or just a gut feeling? | 12:05 |
| pitti | (fails in manual test, I mean) | 12:05 |
| xnox | pitti: it now doesn't fail in manual tests, but I did have round-trips of "i fix here, now it's broken there again where I just fixed it" | 12:05 |
| xnox | I guess my pitfall was being inconsistent in passing sometimes dbus object path '/org/freedesktop/UDisks2/block_devices/sdb1' and sometimes device file names '/dev/sdb1' | 12:06 |
| xnox | manual tests are ok, apart from failure conditions not that well tested (what if it's unplugged at various points of progress) | 12:07 |
| jrp | cjwatson: thanks again, its past time for me to pass out. i owe you a sixpack | 12:10 |
| jrp | cjwatson: feel free to collect if youre ever in Oregon | 12:10 |
| === _salem is now known as salem_ | ||
| Gwaihir | xnox, will something like this https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1119195 work for an SRU? | 12:30 |
| ubottu | Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New] | 12:30 |
| tjaalton | grr, could someone remove xserver-xorg-video-s3 and -qxl from raring-proposed? | 12:30 |
| tjaalton | mistakenly uploaded there | 12:30 |
| tjaalton | someone as in archive admin.. | 12:31 |
| Laney | tjaalton: they shouldn't be there at all or you're going to fix in a subsequent upload? | 12:31 |
| tjaalton | Laney: not at all, should be in canonical-x/x-staging | 12:31 |
| Laney | seb128: didrocks: ^^^ | 12:31 |
| tjaalton | nothing critical there, it's basically just a rebuild | 12:32 |
| tjaalton | but would save yet-another upload :) | 12:32 |
| xnox | Gwaihir: looks good. I'm confused why you filed it as a new bug, instead of updating the existing one =) | 12:33 |
| didrocks | Laney: hum, I think you need more than an archive admin to change something in the published repo :) (or I've never done that more exactly and https://wiki.ubuntu.com/ArchiveAdministration doesn't mention it) | 12:33 |
| didrocks | tjaalton: ^ | 12:33 |
| Gwaihir | xnox, the old one was marked as Fix Released... | 12:33 |
| seb128 | didrocks, I think you can just delete from proposed (as you would delete a source from the archive), but I never tried | 12:34 |
| xnox | Gwaihir: bugs can have tasks. Precise task was not "Fix Released" | 12:34 |
| xnox | Gwaihir: e.g. we track bugs per-series =) | 12:34 |
| tjaalton | right, it's still pending, so should be doable | 12:34 |
| didrocks | seb128: same, I think that the manual removals enable that, but I prefer people knowing to do it first :) | 12:34 |
| Gwaihir | xnox, yep... right... my bad, I can update the other one | 12:34 |
| xnox | Gwaihir: don't worry. Let me sort it out. | 12:35 |
| Gwaihir | xnox, thanks | 12:35 |
| xnox | Gwaihir: now, that's better. Note that it will have to wait until after 12.04.2 is released. | 12:36 |
| xnox | bug 1077153 | 12:36 |
| ubottu | bug 1077153 in python2.7 (Ubuntu Precise) "_DummyThread' object has no attribute '_Thread__block" [Medium,Triaged] https://launchpad.net/bugs/1077153 | 12:36 |
| seb128 | tjaalton, Laney, didrocks: trying "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3" | 12:36 |
| Gwaihir | xnox, ok, thanks again | 12:36 |
| xnox | Gwaihir: in the mean time you can just catch and ignore that attribute error ;-) | 12:36 |
| tjaalton | seb128: same for -qxl? | 12:37 |
| seb128 | trying | 12:37 |
| tjaalton | thanks :) | 12:38 |
| tjaalton | lp shows it as published in the proposed pocket now | 12:38 |
| tjaalton | *them | 12:38 |
| Laney | let me block them to be safe | 12:38 |
| seb128 | yeah, command doesn't work for atm | 12:40 |
| seb128 | items = gnomekeyring.find_network_password_sync(username, service) | 12:40 |
| seb128 | gnomekeyring.IOError | 12:40 |
| Laney | hoho | 12:40 |
| Laney | you might want https://rbtcollins.wordpress.com/2013/01/24/launchpadlib-without-gnome-keyring/ | 12:40 |
| seb128 | didrocks, does "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3" work for you? | 12:41 |
| didrocks | let me try | 12:41 |
| seb128 | my session is screwed, compiz froze again | 12:41 |
| seb128 | and I didn't want to restart | 12:41 |
| seb128 | I ran it from a vt, which restored UI but broken env | 12:41 |
| Gwaihir | xnox, wish I could do that, I would have to patch another library not under my control, anyway, is that targeted for 12.04.2 or .3? | 12:41 |
| didrocks | seb128: Laney: tjaalton: flushed | 12:42 |
| seb128 | didrocks, same for qlx please ;-) | 12:42 |
| Laney | qcl | 12:42 |
| Laney | qxl | 12:42 |
| seb128 | ups | 12:42 |
| didrocks | yep, looking first at what's happening in launchpad for -s3 | 12:42 |
| seb128 | I need to report that compiz issue | 12:42 |
| tjaalton | didrocks, seb128, Laney: great, thanks! | 12:42 |
| seb128 | it's frozen every second time I come from a guest session since I started using a second monitor | 12:42 |
| didrocks | ok, seems that -raring still have a package :) | 12:43 |
| seb128 | didrocks, that command is what https://wiki.ubuntu.com/ArchiveAdministration recommends to remove buggy SRUs | 12:43 |
| Laney | seems like it worked | 12:43 |
| tjaalton | didrocks: do the same for -qxl too | 12:43 |
| seb128 | didrocks, so I figured it would be similars ;-) | 12:43 |
| didrocks | -qxl done :) | 12:43 |
| tjaalton | ah, echo | 12:43 |
| tjaalton | :) | 12:43 |
| Laney | so be aware that you can't reuse that version next time | 12:43 |
| tjaalton | oh | 12:44 |
| didrocks | seb128: yeah, I feel more confortable when seeing it's what is done for SRUs ;) | 12:44 |
| tjaalton | well this was a useless excercise then :) | 12:44 |
| didrocks | tjaalton: tsss tsss, let's say it was for exercising our fingers at least! | 12:44 |
| didrocks | not completely useless ;) | 12:44 |
| tjaalton | heh, ok | 12:44 |
| didrocks | tjaalton: thanks for checking my health :) | 12:45 |
| * didrocks hugs tjaalton | 12:45 | |
| tjaalton | didrocks: :) | 12:54 |
| === zz_jackyalcine is now known as jackyalcine | ||
| === jackyalcine is now known as Jacky_ | ||
| === Jacky_ is now known as zz_jackyalcine | ||
| xnox | Gwaihir: .3, we are frozen for .2 | 13:26 |
| ogra_ | xnox, cjwatson, i'll roll back ac100-tarball-installer so we have installable images over the weekend (and i have a little more time to find some fixrtc like workaround) | 13:40 |
| === wedgwood_away is now known as wedgwood | ||
| xnox | ogra_: all the way to using -m or simply without warning stanza? | 13:41 |
| ogra_ | all the way to the last known working setup | 13:41 |
| * xnox ponders if all the default no-warning should be listed as well on the command line. | 13:42 | |
| ogra_ | i dont want to block QA so we need a quick fix for now | 13:42 |
| ogra_ | since we dont have milestone images anymore we could point people to for a last known good install ... | 13:43 |
| ogra_ | and uploaded ... | 13:51 |
| * ogra_ will trigger a manual image build later, once the cron build is done | 13:51 | |
| xnox | infinity: anything else I have missed? http://paste.ubuntu.com/1624731/ | 14:01 |
| xnox | ogra_: i wonder if it's a red-herring though | 14:12 |
| xnox | ogra_: i just did simg2img on the last nexus7 image I have -> copied the tarball. Did tar xvf on it and it reported same error | 14:12 |
| xnox | tar: Skipping to next header | 14:13 |
| xnox | tar: Exiting with failure status due to previous errors | 14:13 |
| xnox | with exit code 2 | 14:13 |
| === Ursinha is now known as Ursinha-afk | ||
| === tkamppeter_ is now known as tkamppeter | ||
| ogra_ | xnox, hmm | 14:33 |
| xnox | ogra_: the error is from zcat not from tar | 14:34 |
| xnox | ogra_: http://paste.ubuntu.com/1624936/ | 14:34 |
| xnox | looking at logs on ~ubuntu-archive/* i can't seem to find the bit where compression was invoked to see if that had errors. | 14:34 |
| ogra_ | you need the live-build log | 14:35 |
| === zz_jackyalcine is now known as jackyalcine | ||
| ogra_ | wow | 14:37 |
| ogra_ | new acii art on nusakan | 14:37 |
| xnox | ogra_: pastebinit =) i don't have access there. | 14:38 |
| ogra_ | hmm, there isnt any tzar output in the livefs build logs either | 14:39 |
| ogra_ | *tar | 14:39 |
| === henrix is now known as henrix_ | ||
| ogra_ | http://paste.ubuntu.com/1624983/ | 14:39 |
| xnox | ogra_: that is very cool | 14:40 |
| ogra_ | yup | 14:40 |
| ogra_ | we regulary get new shiny login graphics :) | 14:40 |
| ogra_ | hmm, so we dont actually roll the tarball form our own function but use live-build's | 14:41 |
| xnox | too bad they don't make it to OMGubuntu for everybody to comment how thin the stokes are and imperfect the perspective is. | 14:41 |
| xnox | well the error is from zcat, I'd expect to see some warnings at gzip step =) if any, for example I/O fail etc... | 14:42 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Guest65450 | ||
| ogra_ | right, but there arent any errors | 14:43 |
| ogra_ | P: Begin mounting /sys... | 14:45 |
| ogra_ | [2013-02-08 14:40:49] lb_binary_iso | 14:45 |
| ogra_ | [2013-02-08 14:40:49] lb_binary_netboot | 14:45 |
| ogra_ | [2013-02-08 14:40:50] lb_binary_tar | 14:45 |
| ogra_ | [2013-02-08 14:40:50] lb_binary_hdd | 14:45 |
| ogra_ | lb_binary_tar should have the errors if any | 14:45 |
| xnox | ogra_: add a zcat | tar -t > /dev/null there and if it fails abort the build =) | 14:46 |
| xnox | cause it's annoying to build/publish/download/flash/boot to find out there is a tarball decompress error. | 14:47 |
| ogra_ | nthe build already takes over 90min .... | 14:47 |
| xnox | *sigh* | 14:47 |
| ogra_ | i cant really add something that takes another 30 | 14:47 |
| ogra_ | we were planning to switch to xz anyway | 14:48 |
| xnox | well there is only read IO and no write + CPU | 14:48 |
| ogra_ | we didnt have issues before though | 14:48 |
| xnox | true. | 14:48 |
| xnox | gzip upgraded recently? | 14:48 |
| ogra_ | not that i know of | 14:48 |
| ogra_ | at least not on -changes ... did debian upgrade ? | 14:48 |
| * xnox is recompressing the tarball to recreate the image and check if that fails. | 14:48 | |
| ogra_ | so that we have pulled something in by accident | 14:49 |
| xnox | nah last gzip update is from before starting nexus7 images =) | 14:50 |
| ogra_ | tar cf binary-tar.tar binary | 14:50 |
| ogra_ | gzip ${GZIP_OPTIONS} binary-tar.tar | 14:50 |
| ogra_ | thats the code in lb | 14:50 |
| ogra_ | GZIP_OPTIONS="${GZIP_OPTIONS:---best}" | 14:51 |
| ogra_ | if gzip --help | grep -qs "\-\-rsyncable" | 14:51 |
| ogra_ | then | 14:51 |
| ogra_ | GZIP_OPTIONS="$(echo ${GZIP_OPTIONS} | sed -e 's|--rsyncable||') --rsyncable" | 14:51 |
| ogra_ | fi | 14:51 |
| ogra_ | and that seems to be the default | 14:52 |
| ogra_ | nothing special in it (and i dont really belive it is gzip) | 14:53 |
| === kentb-out is now known as kentb | ||
| xnox | make_ext4fs corrupting files? =/ | 14:54 |
| ogra_ | nah, it didnt before | 14:55 |
| ogra_ | the only actual change was that we dropped -m and that infinity switched to long options | 14:56 |
| ogra_ | and i doubt the long options cause it :) | 14:56 |
| xnox | it was working fine when -m was dropped. | 14:58 |
| xnox | I reported that it prints "timestamp too far in the future" for every file on flashing, but it did finish flashing and booted into oem-config | 14:58 |
| ogra_ | oh | 14:58 |
| xnox | It didn't work after --warning=no-timestamp got uploaded | 14:58 |
| ogra_ | i dont see a --best option in our gzip manpage | 14:58 |
| xnox | (and it's ~ same image I have now) | 14:59 |
| xnox | --best == -9 | 14:59 |
| Laney | I installed it after that warning was disabled | 14:59 |
| Laney | s/installed/flashed/ | 14:59 |
| ogra_ | xnox, yes, but its not documented | 14:59 |
| ogra_ | Laney, and it worked ? | 14:59 |
| xnox | -# --fast --best in man gzip | 14:59 |
| Laney | yeah | 14:59 |
| Laney | something borked and I had to go back to android first though | 14:59 |
| ogra_ | xnox, bah, need to train my search abilities :P | 15:00 |
| * ogra_ scratches his head | 15:00 | |
| xnox | ogra_: technically it's the -9 that isn't documented ;-))))) -# is | 15:00 |
| ogra_ | xnox, do we log the output of fastboot when flashing with usb-creator ? | 15:01 |
| ogra_ | i wonder if there were any issues when flashing for the people seeing no installer | 15:01 |
| * xnox wonders did people start using usb-creator suddently? (considering that it doesn't do ungzip) | 15:04 | |
| xnox | there are some logs.... | 15:04 |
| ogra_ | oh, it doesnt work yet ? | 15:04 |
| xnox | it does work, it's just the download is .img.gz & usb-creator expects .img | 15:05 |
| stgraber | I'm mostly killing it whenever it shows up (and it does that a lot) | 15:05 |
| xnox | one needs to decompress =) | 15:05 |
| pitti | xnox: I used it yesterday, yes | 15:05 |
| pitti | but for .iso | 15:05 |
| ogra_ | xnox, well, we should include the decompressing somwhow | 15:05 |
| xnox | stgraber: yeah, sorry about that. Infinity hit it on the head. | 15:05 |
| xnox | stgraber: http://paste.ubuntu.com/1624731/ can you think of any other times it popped up & you didn't want it to? | 15:05 |
| ogra_ | stgraber, it wants to tell you something about the priority of working on mobile i guess ;) | 15:06 |
| stgraber | ogra_: well, considering it did that every time I wanted to test some packages for mobile, it did a pretty sucky job at motivating me to continue ;) | 15:06 |
| ogra_ | lol | 15:07 |
| cjwatson | +[ x"$XAUTHORITY" == x"" ] && exit 0 | 15:08 |
| cjwatson | +[ x"$user" == x"lightdm" ] && exit 0 | 15:08 |
| cjwatson | xnox: those are bashisms | 15:08 |
| cjwatson | s/==/=/ | 15:08 |
| cjwatson | $ [ "" == "" ] | 15:08 |
| cjwatson | dash: 1: [: unexpected operator | 15:08 |
| ogra_ | well, we just need to make upstart use a full bash implementation ... see ... fixed :) | 15:10 |
| stgraber | wow, I'm really glad we're getting upstart user sessions soon, that kind of upstart job really shouldn't exist ;) | 15:10 |
| barry | cjwatson: that sure looks familiar | 15:10 |
| ogra_ | stgraber, ++ | 15:10 |
| xnox | shadeslayer: yes. | 15:10 |
| ogra_ | stgraber, in the beginning it actually fired on every USB plug event :) | 15:11 |
| ogra_ | it already improved a lot | 15:11 |
| stgraber | ogra_: ah, that might have been my problem then, considering I'm working on phone support and plug/unplug USB phones every 30s or so ;) | 15:11 |
| ogra_ | but ... that doesnt fix our tar/gzip issues | 15:11 |
| * ogra_ sighs | 15:11 | |
| * ogra_ suspects he has to do a fresh install himself to dig deeper | 15:12 | |
| stgraber | xnox: there, your new upstart job, which will only work on my laptop ;) http://paste.ubuntu.com/1625157/ | 15:12 |
| * xnox wants a shell that doesn't support bashism, yet has bash-completion & history scrollback and colors | 15:13 | |
| xnox | stgraber: I know. I can't wait for user sessions. | 15:13 |
| xnox | with less bash now http://paste.ubuntu.com/1625172/ | 15:14 |
| ogra_ | s/test/\[/ | 15:15 |
| ogra_ | ? | 15:15 |
| cjwatson | doesn't matter | 15:15 |
| xnox | consistent with previous calls to test | 15:15 |
| ogra_ | well, i like it better :) | 15:15 |
| ogra_ | technically it doesnt matter indeed | 15:15 |
| stgraber | hehe, was about to mention that I tend to prefer '[ ... ]' to 'test ...' but it's the same statement, so I don't really care, especially as the job will get a lot shorter pretty soon and all that will go away ;) | 15:16 |
| ogra_ | yeah | 15:16 |
| xnox | or I can not upload this and wait for user sessions =) | 15:19 |
| shadeslayer | xnox: whut o_o | 15:20 |
| xnox | shadeslayer: upstart user sessions - the bit where upstart will start gnome-session and can manage long running processes for the user. | 15:21 |
| xnox | shadeslayer: see the blueprint and massive spec on the wiki and discussions about it on ubuntu-devel & upstart-devel | 15:21 |
| shadeslayer | no no | 15:22 |
| stgraber | xnox: well, I think it's safe to assume we'll land user sessions before feature freeze but we still need a bit of work to get the whole logout/shutdown/restart working and the environment stuff I mentioned | 15:22 |
| shadeslayer | <xnox> shadeslayer: yes. | 15:22 |
| shadeslayer | what was that about? :D | 15:22 |
| ogra_ | shadeslayer, he meant stgraber ... tab completion error | 15:22 |
| shadeslayer | ahh | 15:22 |
| === henrix_ is now known as henrix | ||
| shadeslayer | should have guessed it | 15:22 |
| mterry | seb128, your pyatspi sync is causing bug 1119426 | 15:31 |
| ubottu | bug 1119426 in pyatspi (Ubuntu) "package python3-pyatspi (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python3/dist-packages/pyatspi/editabletext.py', which is also in package python3-pyatspi2 2.7.2+dfsg-0ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1119426 | 15:31 |
| === Ursinha_ is now known as Ursinha | ||
| === jbicha_ is now known as jbicha | ||
| seb128 | mterry, oh ok, will look into it, thanks for pointing that | 15:56 |
| jdstrand | cr3: hey, you asked about MSRs on bug #1031090. I don't know-- the description was updated for the SRU. maybe ask smb? | 15:57 |
| ubottu | bug 1031090 in linux (Ubuntu Precise) "kvm_intel not loadable in a quantal guest" [High,Fix released] https://launchpad.net/bugs/1031090 | 15:57 |
| * smb does not see any MSR related question in that bug... | 15:59 | |
| jdstrand | smb: "Fix: Just add the required flag to the MSRs passed to guests. This change is picked from the patch that enabled the feature but does not enable anything beyond. It has been reviewed upstream and sent to upstream stable." | 16:00 |
| jdstrand | smb: cr3 was asking about that statement yesterday | 16:01 |
| smb | Ah ok. Well what I tried to say was that some of those contain capability flags. Which the kvm module checked to load | 16:02 |
| cr3 | jdstrand: hi there, thanks for following up! I just managed to get a quantal kvm working on precise, it must've been a problem with my script that generates the libvirt.xml file | 16:02 |
| jdstrand | cool | 16:02 |
| === sil2100_ is now known as sil2100 | ||
| cr3 | jdstrand: I was curious how unity would work under kvm but it works like a charm, cpu usage is low, all is well. now, raring ringtail! | 16:04 |
| jdstrand | wow, that has not been my experience on quantal | 16:04 |
| cr3 | jdstrand: really, what did you observe? | 16:05 |
| jdstrand | very slow due to llvmpipe | 16:05 |
| jdstrand | precise and earlier could use unity-2d and that was fine | 16:05 |
| jdstrand | cr3: mdeslaur discovered how to disable fades and animations in gsettings that made it tolerable | 16:06 |
| jdstrand | but still slower than unity-2d | 16:06 |
| cr3 | jdstrand: I haven't used it much yet in a vm, but when it's idle the cpu usage is also quite idle | 16:06 |
| jdstrand | yes, that isn't so bad | 16:07 |
| jdstrand | but menu fade-ins and application launches are pretty bad | 16:07 |
| cr3 | mdeslaur: ^^^ do you have a link for your tweaks? | 16:07 |
| jdstrand | once the application is running, it is generally ok | 16:07 |
| jdstrand | cr3 (mdeslaur): I'm getting it | 16:07 |
| cr3 | jdstrand: exactly, I was expecting worse so I'm actually pleasantly surprised considering | 16:07 |
| mdeslaur | http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/revision/967 | 16:08 |
| ubottu | Ubuntu bug 967 in gnomebaker (Ubuntu) "Should burn multiple CDs in a row if the first fills up" [Wishlist,Confirmed] | 16:08 |
| mdeslaur | cr3: ^ | 16:08 |
| jdstrand | thanks ubottu - very apropos | 16:09 |
| jdstrand | mdeslaur: actually, I forgot to try the Dash. did you see any improvement there? | 16:09 |
| mdeslaur | well, it doesn't fade in anymore, so it's better | 16:10 |
| jdstrand | cool | 16:10 |
| jdstrand | oh yes, that is considerably better | 16:10 |
| jdstrand | slow, but better | 16:11 |
| cr3 | mdeslaur: if I understand the changes you made to ubuntu-qa-tools correctly, these are all persistent; once applied, they persist across reboots. right? | 16:33 |
| mdeslaur | yeah | 16:35 |
| cr3 | mdeslaur: all good then, thanks! | 16:35 |
| mdeslaur | it's basically just disabling two compiz modules for the user | 16:35 |
| === and`_ is now known as and` | ||
| === deryck is now known as deryck[lunch] | ||
| === _abbe is now known as abbe | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === zequence_ is now known as zequence | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === jackyalcine is now known as zz_jackyalcine | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| infinity | xnox: That user = lightdm test seems silly, and sort of highlights to futility of trying to do this as a system job. | 18:18 |
| infinity | xnox: (The best approximation of what you're trying to do would probably be a check if UID << 1000, so other DMs also work, but it really seems wrong to be doing it this way at all) | 18:19 |
| infinity | xnox: Not to mention the general wrongness with assuming what you're assuming: If I'm logged in, have those packages installed, and plug in my Nexus, that means I want to re-flash it? | 18:20 |
| xnox | infinity: and it's in fastboot mode. | 18:20 |
| ogra_ | infinity, its obsolete as soon as the upstart session stuff is there | 18:21 |
| xnox | which it wouldn't unless you boot it with power button + volume down. | 18:21 |
| infinity | xnox: Ahh, that helps. I missed that bit in your revision. | 18:21 |
| ogra_ | and what xnox said, the nexus has a special ID in that mode | 18:21 |
| xnox | infinity: fastboot devices only prints devices which are in fastboot mode & ready to cooperate with flashing =) | 18:22 |
| xnox | it's all very consensual. | 18:22 |
| mdeslaur | uhm, what are we talking about here? I hope we're not trying to launch stuff as a system daemon on plug events... | 18:22 |
| ogra_ | mdeslaur, well, we pop up usb-creator if a nexus7 in flash mode is attached | 18:30 |
| ogra_ | mdeslaur, the code above is not supposed to stay, it will be a user session service in the end | 18:31 |
| xnox | mdeslaur: we are talking about launching a user app on plug event. | 18:32 |
| mdeslaur | ogra_, xnox: it's not safe to do with with a system daemon. It needs to be done in the user's session. | 18:34 |
| ogra_ | yes, thats the plan | 18:34 |
| ogra_ | we're just waiting for the new upstart :) | 18:35 |
| xnox | mdeslaur: ha =) so why does power-management has functions to do so? =) | 18:35 |
| mdeslaur | using sudo in this way is likely to facilitate a root escalation via tty hijacking, etc. | 18:36 |
| mdeslaur | xnox: huh? where? | 18:36 |
| ogra_ | mdeslaur, yeah, its ugly but its an interim | 18:36 |
| ogra_ | its not like we are pushing that into a stable release or so | 18:38 |
| mdeslaur | ok | 18:38 |
| kirkland | jamesh: howdy! is it possible to fork 3 different daemons within a single upstart configuration? | 18:42 |
| kirkland | jamesh: or would it be better to write 4 different upstart jobs (one wrapper, and one for each of the 3 daemons)? | 18:42 |
| xnox | jodh ^ | 18:43 |
| xnox | kirkland: use instances. | 18:43 |
| kirkland | xnox: can you point me to an existing service/example, and I can probably take it from there... | 18:44 |
| xnox | kirkland: see for example /etc/init/network-interface.conf which is one conf file but starts/tracks each unique network interface. | 18:44 |
| JanC | instances might not be the right solution to run *different* daemons | 18:44 |
| xnox | one can easily use that pagadim to track e.g. N workers. | 18:44 |
| kirkland | xnox: okay -- so I want to launch my binary 3 times, each with a different argument to listen on a different port | 18:46 |
| kirkland | xnox: where do I iterate over those 3 ports? | 18:46 |
| kirkland | xnox: emit a signal in the prestart? | 18:46 |
| kirkland | xnox: that's how I'm reading that network-interface.conf | 18:46 |
| mjt | kirkland: why, oh why you left qemu? :) | 18:47 |
| xnox | 1 master job that does: start myfoo 146; start myfoo 147; start myfoo 148. | 18:47 |
| kirkland | mjt: howdy :-) it's been a *long* time since I contributed anything meaningful to #qemu :-) | 18:48 |
| xnox | kirkland: sorry it's key-value, so one would have: start myfoo INSTANCEPORT=147 for example | 18:48 |
| kirkland | xnox: perfect -- that'll work | 18:48 |
| kirkland | thanks! | 18:48 |
| xnox | kirkland: network-interface listens on unique events, but one can emit events from another job file or do explicit start from another job file. | 18:48 |
| kirkland | ^ xnox | 18:48 |
| mjt | kirkland: now watch all your stuff is being replaced by debian qemu, as a penalty to you! :) | 18:48 |
| * mjt hides | 18:49 | |
| kirkland | mjt: as it should be :-) I'm very, very supportive of hallyn's work ;-) | 18:49 |
| mjt | actually.. so as me ;) | 18:49 |
| kirkland | mjt: my excuse was that, at the time (2008-2010), qemu-kvm was so essential to what I was trying to do for Canonical with Ubuntu, I simply had to fork the packaging to keep up (couldn't wait on Debian) :-) | 18:50 |
| kirkland | mjt: and I can't apologize for that :-) | 18:50 |
| kirkland | mjt: all that said, things are so much more stable now, it's definitely time to resync back with Debian on qemu | 18:50 |
| mjt | kirkland: thank you! ;) | 19:04 |
| mjt | kirkland: it was actually the same thing for me when i started working with kvm :) | 19:04 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === Ursinha is now known as Ursinha-afk | ||
| xnox | ogra_: after all the chit chat we had, did you respin the nexus images after the revert? | 20:10 |
| cjwatson | tyhicks: are you likely to get bug 1026852 sorted out today? I have a chain of stuff blocked on it involving eglibc and arm64-cross-toolchain-base; if that could involve just retrying builds rather than new source uploads with patches it would be nice | 20:18 |
| ubottu | bug 1026852 in audit (Ubuntu) "[MIR] audit (pulls in libprelude)" [Undecided,In progress] https://launchpad.net/bugs/1026852 | 20:18 |
| tyhicks | cjwatson: Yes, it should be sorted out today. There are tons of compiler warnings but I got a nice head start on it last night. | 20:19 |
| cjwatson | tyhicks: if not I expect I could at least sort out the compiler warnings tonight, which the bug trail indicates should be enough to promote it to main | 20:19 |
| cjwatson | tyhicks: ah, good | 20:19 |
| infinity | cjwatson: Yeah, I've been working with them on it, it's all good. :) | 20:34 |
| infinity | cjwatson: Oh, and I had all of *-cross-toolchain-base sitting here on my machine waiting to upload too. Oh well. | 20:35 |
| cjwatson | infinity: hah | 20:36 |
| cjwatson | infinity: um, well, I was about to do armel and powerpc ... | 20:36 |
| cjwatson | infinity: if you have them ready feel free, but maybe we want to keep the exact patches in sync | 20:36 |
| infinity | cjwatson: Go ahead. I'd only done arm64 and armhf so far. :P | 20:36 |
| cjwatson | heh. sorry, should've asked. was trying to unblock wookey | 20:36 |
| infinity | cjwatson: When I said "all", I meant "I had been working on it, which was why the latest glibc upload fixed arm64 cross". | 20:37 |
| infinity | But yeah. Go ahead and sync them all, now that you started. :P | 20:37 |
| infinity | The mess builds fast enough, I wonder if maybe we should just do them all from one source package and be done with it. | 20:37 |
| infinity | Adding proper parallel= handling to it would probably make up the difference. | 20:38 |
| infinity | cjwatson: Oh, the ppc one needed another change to it to undo an unnecessary hack. I'll fix. | 21:11 |
| cjwatson | infinity: ah, thanks, I was about to look at that | 21:12 |
| cjwatson | You can tell I got bored of test-building these locally | 21:12 |
| infinity | Heh. Yeah, that should be the shlibs hack that's no longer needed with my new glibc patches. I think. But I'll double-check and test-build. | 21:14 |
| === Ursinha-afk is now known as Ursinha | ||
| dobey | barry: hey. is there something specific in the new oauthlib that your changes to ubuntu-sso-client needs? do the other branches also need it? | 21:38 |
| barry | dobey: my branches really just change the code to use the different api in oauthlib. other than that, it shouldn't change anything functional. when you say other branches, do you mean the u1-client and u1-storage-protocol branches? | 21:39 |
| dobey | barry: yeah | 21:40 |
| dobey | barry: i'm asking because on the sso branch you mentioned needing to wait for the new version of oauthlib in raring | 21:40 |
| barry | dobey: they basically do the same thing, just updated to use the oauthlib apis | 21:40 |
| dobey | barry: so i was wondering if there was a specific reason for it | 21:40 |
| barry | dobey: ah, yes. it was the ability to pass the timestamp into the ctor | 21:40 |
| barry | that was missing, but required by the tests | 21:41 |
| barry | so i asked upstream to add it, which they did :) | 21:41 |
| dobey | barry: do the other branches need that as well, or just the sso one? | 21:41 |
| barry | dobey: hmm. not sure, but unless you're backporting, it's moot, since we have the right version in raring now | 21:42 |
| dobey | barry: we build nightlies as far back as oneiric | 21:42 |
| barry | (the other useful new api was better handling of unicodes by passing in an encoding parameter and letting the library encode to bytes. so that part is probably necessary now as well) | 21:42 |
| barry | dobey: in that case, the current oauthlib will probably be necessary, due to the new encoding api | 21:43 |
| barry | dobey: or at least, very helpful (you can work around that part of it) | 21:43 |
| barry | dobey: by doing the encoding in the u1 branches, which i'd originally done, but removed when oauthlib 0.3.5 was released | 21:43 |
| dobey | also, we shop on windows and osx :) | 21:44 |
| dobey | err, ship | 21:44 |
| barry | dobey: is it a problem to backport the oauthlib? | 21:44 |
| dobey | barry: hopefuilly not (i haven't tried yet) | 21:45 |
| dobey | barry: i was just seeking clarification on it | 21:45 |
| barry | dobey: cool. please do let me know if you run into any problems | 21:45 |
| barry | dobey: upstream claims support back to py26, so that should be fine | 21:45 |
| dobey | great. hopefully it just works on win/osx too :) | 21:46 |
| * barry nods | 21:46 | |
| dobey | but given it's not just a python lib, that might be a problem :-/ | 21:47 |
| barry | dobey: i can probably help with various flavors of osx and if i suppress the gag reflex, windows 7 too | 21:47 |
| dobey | barry: we still support xp too (xp, 7, and 8) | 21:47 |
| barry | dobey: sounds like fun | 21:47 |
| dobey | oh, it is all python? | 21:48 |
| barry | dobey: yep | 21:48 |
| dobey | oh, probably fine then | 21:48 |
| dobey | i thought it had C too | 21:49 |
| barry | nope. it does dep on pycrypto though, i guess to do the signatures | 21:50 |
| dobey | is that not in stdlib? | 21:50 |
| barry | nope, but reading the docs, it's just a soft dependency, to support RSA-SHA1 signatures. i don't think u1 uses those though | 21:51 |
| dobey | hmm | 21:51 |
| barry | iirc, just hmac-sha1 and plaintext | 21:51 |
| dobey | we do use hmac | 21:52 |
| dobey | well, python-oauth doesn't support rsa-sha1 either | 21:52 |
| barry | yeah, so you're probably fine w/o it | 21:52 |
| dobey | yeah | 21:52 |
| barry | dobey: yep, looking at github upstream, Crypto is only imported in sign_rsa_sha1() and verify_rsa_sha1() | 21:55 |
| dobey | cool, thanks | 21:55 |
| dobey | barry: ugh, looks like i have to backport python-crypto and python-nose as well, at least for our nightlies builds (as the package build runs tests and needs newer versions) | 22:15 |
| === salem_ is now known as _salem | ||
| barry | dobey: urg. i guess you can't or don't want to disable those tests | 22:17 |
| dobey | well i can. would prefer not to though | 22:17 |
| dobey | tests are nice to have, when they work :) | 22:17 |
| barry | :) | 22:18 |
| * dobey glares at squid and glibc 2.17 | 22:18 | |
| === Tonio_aw is now known as Tonio__ | ||
| === emma is now known as em | ||
| === Tonio__ is now known as Tonio_aw | ||
| === Quintasan_ is now known as Quintasan | ||
| === zz_jackyalcine is now known as jackyalcine | ||
| === jackyalcine is now known as Jacky_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!