[00:05] sarnold: not the same situation, but there are multiple causes, I guess === wedgwood is now known as wedgwood_away [01:21] Daviey: around? [01:55] Uhm. What just spawned Ubuntu Core Installer from its postinst? :P [01:57] infinity: funny, cjwa tson and dob ey were mentioning it earlier.. [01:57] Yeah, I'm going to fix this with fire right now. [01:58] * sarnold gets his ovegloves out [02:09] 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] hallyn: Sure. [02:12] 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] No, splits don't need an MIR. [02:12] phew [02:12] And you'd want seeds something like this (adjusted for whatever the actual truth is): [02:12] * qemu-system-ppc [powerpc ppc64] [02:12] * qemu-system-arm [armel armhf arm64] [02:13] ah cool [02:13] * qemu-system-x86 [i386 amd64 x32] [02:13] so just like you do in a debian/control :) [02:13] Pretty much. [02:13] thx [02:13] Plenty of examples of this in the seeds currenty. [02:13] that should reduce the size of the server seed a bit, [02:13] 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] spice? [02:14] Or is this pre-spice-enabling? [02:14] pre-spice [02:14] Oh, indeed. [02:14] feh, i do hope spice won't add that, that could suck [02:16] Every single qemu-system-* has a libgl dep. [02:16] And given our aggressive use of --as-needed, that probably means they actually use symbols from it. [02:16] Unless there's some gross hand-made linking going on. [02:17] is that libglib-2.0.so.0 ? [02:17] Oh, my grep might be bad. :P [02:17] right i don't actually see a 'libgl' as such, or any *mesa* or *qxl [02:18] /usr/bin/qemu-system-lm32 is the only one. [02:18] (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] /usr/bin/qemu-system-lm32 [02:18] (base)adconrad@cthulhu:~$ [02:18] I always forget it's uppercase GL. [02:18] [02:19] That's sort of a self-solving problem after the split. [02:19] Assuming lm32 isn't one you care about. :P [02:19] Whatever it is... [02:19] right it's not :) [02:20] but libGL comes from nvidia for me [02:20] lm32-uclinux lm32 platform for uClinux and u-boot by Theobroma Systems [02:20] lm32-evr LatticeMico32 EVR32 eval system (default) [02:20] milkymist Milkymist One [02:20] libxcb test cases completed \o/ [02:20] Well, yes. Your libGL comes from nvidia cause you have the nvidia drivers installed, so? [02:20] pitti: ^^ [02:21] infinity: I'm still just trying to figure out what libgl1-mesa-glx is [02:21] hallyn: It's libGL. [02:21] all right [02:21] * hallyn checks where lm32 falls in the split - hopefully qemu-system-misc [02:21] hallyn: Your dep is "libgl1-mesa-glx | libgl1", and binary drivers all provide the latter and use alternatives. [02:22] pitti: I will request a branch merge after I come from school, the bus is here [02:22] infinity: ah, i see [02:22] infinity: phew, yeah, it's in -misc, so that may solve that [02:22] hallyn: Unless spice uses GL. ;) [02:23] hallyn: Well, spice would be its own package too, I'm guessing, a second build of x86? [02:23] hallyn: Or is Debian just building it in? [02:23] Hrm, guessing spice is just built in to x86. === zz_Jacky_ is now known as jackyalcine [02:24] * infinity looks at how that pans out. [02:24] yeah i guess we should b eable to tell by looking at the debian-experimental packages [02:25] Which I just did. [02:25] And I guess it's not a big deal. === jackyalcine is now known as Jacky_ [02:25] I was going to bitch about how spice would pull in all those useless X11 deps. But qemu-system does that ANYWAY. [02:25] right, qemu-kvm shoudl always have done that too, bc it built in sdl [02:25] Because it's such a wonderfully modular design, so well-suited to masquerading as a lightweight hypervisor. [02:25] [02:26] and sdl never works right anyway === Jacky_ is now known as zz_Jacky_ [02:26] maybe we can add a qemu-kvm-barebones [02:26] infinity: ok, so spice in debian doesn't add libGL? [02:26] infinity: (bc it is a big deal due to bug 1118407) [02:26] bug 1118407 in qemu (Ubuntu Raring) "qemu-kvm/system has a large number of dependencies" [High,Triaged] https://launchpad.net/bugs/1118407 [02:26] Isn't what qemu-kvm *was* before we decided to just use system? [02:27] rephrase? [02:27] Oh, no, kvm built with sdl too. [02:27] Nevermind. [02:27] right [02:27] gah. biab [02:27] So, yeah. It would be nice to have something targetted at servers. [02:28] It would be so much better if it had a modular/plugin system. :/ [02:29] 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] Though, I guess all anyone really needs is the "nothing but barebones kvm/paravirt with no GUI and sound stuff" and "the kitchen sink". === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ [02:31] hallyn: Oh, speaking of qemu, IS needs a patch in your next upload. [02:32] hallyn: https://launchpadlibrarian.net/93501920/qemu-linaro-921078.patch got dropped when the great merge happened. [02:33] 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] hallyn: So, when that patch got dropped and they rolled out a new backport, all the ARM PPAs broke. Well done. [02:35] 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] RAOF: Nope. [02:36] RAOF: Not on GNU/Linux anyway. It all resolves sanely and it's like nothing happened. [02:36] RAOF: Of course, that also means liba-private isn't private. [02:36] RAOF: If its symbols are exported and accessible through linking liba. [02:36] win 301 [02:36] Yeah. A better name for it could be "liba-minus-the-glib-bits" [02:37] Heh. [02:37] 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] But if liba depends on liba-glib-bits, why bother with the split? [02:37] If you dlopen() liba and it links liba-whatever, you'll get whatever with it. [02:38] Because other things can depend on liba-minus-glib-bits, I think. [02:38] Note that I said dlopen() intentionally there. There are non-dlopen dlopen-alike implementations that screw this up. But glibc doesn't. [02:38] (be wary of ctypes) [02:39] Anything using glibc's linkers (dlopen() or ld.so via direct linking) will be fine. [02:39] And anyone else is doing it wrong. [02:39] QED. [02:39] Eh. This has an accompanying gir; I don't think anyone sane will be ctypesing it. [02:52] infinity: oh, never heard of that patch. oh i see it wasn't in qemu-kvm... [02:52] infinity: should that only be for arm targets? [02:52] hallyn: The same misfeature applies to all qemu-user-static builds, it's hard an ARM issue. [02:53] hallyn: Without declaring a uname at build time, it just passes through the system's uname. [02:53] oh. i see. which'll be 2.6.23 or something for hardy :) [02:53] 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] 2.6.24 [02:53] i was close! [02:53] 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:54] And 3.8.0 is what my raring system will say running uname under qemu-user-whatever. [02:54] ok, i'm getting clsoe to pushing, lemme toss taht patch backin tehre realy quick === pcarrier_ is now known as pcarrier [03:02] trying to tell if that flag is safe for system builds === 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 [04:44] 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:45] (should fix the two bugs jamespage filed today) [04:45] * hallyn out [04:58] * shuduo is away: auto-away [05:05] * shuduo is back (gone 00:07:21) === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ [05:27] Good morning [05:27] vibhav: awesome! [05:38] * shuduo is away: auto-away === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine [05:49] Hiya [05:56] * shuduo is back (gone 00:17:53) === Guest40324 is now known as StevenK === amitk is now known as amitk-afk [07:27] good morning === jackyalcine is now known as zz_jackyalcine === chiluk is now known as chiluk_away [08:18] highvoltage, happy birthday! :) [08:23] thanks, dholbach! [08:23] :) [08:24] highvoltage: happy birthday and congrats with becoming a gnome-panel maintainer! :) === yofel_ is now known as yofel === amitk-afk is now known as amitk [08:51] 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:52] I think they won't close [08:53] I was just waiting for them to be merged [08:53] 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:54] ok [08:54] dholbach, when is Logan's application going to be reviewed for MOTU btw? ;-) [08:54] seb128, according to https://lists.ubuntu.com/archives/devel-permissions/2013-February/000445.html it's on 25 Feb [08:55] great [08:55] dholbach, danke! [08:56] 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 === henrix_` is now known as henrix [09:52] pitti: ping [09:53] hey vibhav [09:53] After compilation, how do I run Xvfb and the test together? [09:54] vibhav: xvfb-run yourtestprogram [09:54] Can xvfb run in the background? [09:56] xvfb-run does all that for you [09:56] pitti: What about the parameters to Xvfb? [09:56] you don't usually need parameters [09:56] Perfect [09:56] So screen is :0 , right [09:58] vibhav: no, xvfb-run will use :99 by default [09:58] but it sets $DISPLAY [09:59] so you can do "xvfb-run xeyes" and everything will work [09:59] Ah [09:59] Just Work in fact [09:59] Good [10:00] So I refine it and then request a merge [10:00] I will* [10:03] 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] Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New] [10:04] !sru | Gwaihir [10:04] Gwaihir: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [10:06] thanks vibhav [10:06] No problems [10:25] Hi, Im compiling some software and Im curious. Why arent ubuntu packages compiled with -fPIC? [10:25] examples include: libssl.a, libc.a, and libz.a [10:27] because you've libssl.so, libc.so, libz.so etc [10:27] 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:28] Im trying to create a shared lib thats statically linked if that makes sense, in which case I do need -fPIC [10:28] static lib compiled with -fPIC makes sence if you include that static libs into shared libs [10:28] heh [10:28] yeeeep. [10:28] as i said, do not do it, use real shared libs. [10:29] jrp: that's not supported on debian/ubuntu. [10:29] jrp: you can recompile libraries in question and then you can do it. [10:29] aka in a ppa. [10:29] is there anyway I can create a staticly linked library out of shared libraries? [10:29] xnox: yeah, im recompiling glibc now :\ [10:30] static libs are already very questionable things, but it really is sometimes necessary to build static apps sometimes. [10:30] jrp: do not use it, unless all the test-suites pass. [10:30] statically linking glibc is very unwise. [10:30] but embedding a static lib (especially such common ones like glibc(!!) and libz) is really insane. [10:31] and we went to serious effort to hunt-and-destroy instances of static linking of libz a security vulnerability or two ago. [10:31] Im very far down a rabit hole, I really just need a shared library with statically linked libcurl [10:31] hahaha [10:32] http://curl.haxx.se/docs/adv_20130206.html -- fresh curl security hole for you [10:32] i saw [10:33] 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] it is really a bad taste to help to do such a bad thing. [10:33] 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] and it always starts from research/PoC thing, and spreads from there... [10:33] jrp: that said, you'll find some -pic variants of libraries, which exist for special purposes - for example libc6-pic [10:34] cjwatson: what purposes are these? [10:34] cjwatson: thats incredibly helpful [10:34] mjt: installer [10:34] ubuntu uses its own installer? [10:34] scary library reduction thing which really ought to be replaced now that we have sane udeb shlibdeps, but ... [10:34] mjt: no, d-di [10:34] *d-i [10:35] mjt: libc6-pic is in Debian too [10:35] yeah, d-i and reduction. i remember now. [10:35] 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] we wouldn't have introduced it ourselves [10:35] d-i is an evil thing anyway :) [10:35] nah, it's lovely and fluffy [10:35] admittedly there is a core of complex evil [10:35] * mjt , being one of the d-i team, hides and runs away [10:36] well, likewise :) [10:36] but i don't do much there, only busybox [10:38] (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:39] well, thank you guys very much for the help, i appreciate it [10:40] 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] cjwatson: Im building something which will be executed through LD_PRELOAD (which I know is also evil) [10:40] I wasn't aware that LD_PRELOAD disregarded indirect linkage? [10:40] wow. linking libc statically into LD_PRELOADed object may have... interesting effects. [10:40] ;) [10:41] Quite, you'll probably end up with a sea of symbol conflicts and consequent segfaults [10:41] ok, backing up some more. Im hooking connect() using LD_PRELOAD, then trying to use libcurl to send data off [10:42] 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] Im concerned that libcurl will see my not-real-connect, as opposed to real connect [10:43] does that make any sense? [10:44] I think what you want is to build a shared libcurl without -Bsymbolic-functions [10:44] you'll have to implement all read/recvfrom/etc stuff too [10:44] Let me check what our curl is built with [10:45] (or just fork a child process linked with curl, and return a real socket fd from socketpair) [10:45] that might be a ton easier and safer [10:45] Im trying to avoid forking, I have it working now in a fashion via fork/exec [10:46] 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] but id like to avoi the process overhead [10:46] A bit of a hassle but almost certainly less painful than static linking. [10:46] Uh, so Im sure were on the same page. I -want- curl to use the system's connect() [10:47] Oh, ISWYM [10:47] so Im trying to statically link curl so it -wont- hit my connect/getaddrinfo/gethostbyname [10:47] Ah, no, -Bsymbolic-functions doesn't apply because connect isn't within the library [10:47] jrp: Sounds like sledgehammer and nut ... [10:48] cjwatson: As I said, Im stumbling through it, down a rabit hole. Im 100% open to smaller hammers [10:48] write a small daemon that does your curl work and connect to it from ld_preload [10:48] to avoid forking overhead [10:49] hm, thats a very good idea [10:49] tons of possibilities, embedding stuff into ld_preload seems like one of the worst solutions [10:50] 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:51] it makes me feel marginally better that all this isnt super obvious [11:17] jrp: Here's another possibility (probably at the very least glibc-specific and possibly Linux-specific): http://paste.ubuntu.com/1623988/ [11:18] jrp: (Actually, make the "int (*connect_real)" line "static int ..." instead for efficiency, I missed that bit) [11:19] ...wow. seriously, thank you so much. [11:20] bar.c here is of course a stub taking the place of libcurl [11:20] yeah [11:23] 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] tjaalton: it still worked on Feb 6, failed on Feb 7 [11:24] 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] error: conflicting types for 'BarrierEventID' [11:25] pitti: needs a rebuild, I've uploaded a new libxi last night [11:25] tjaalton: oh, is that 2:1.6.99.1-0ubuntu2 [11:25] yes [11:25] tjaalton: thanks, sorry for the noise [11:25] sorry for pushing the original one to raring and not the staging ppa ;) [11:26] can't escape Jenkins :) [11:26] :) [11:27] jrp: ... and no problem, it was an excuse to try to remember this stuff [11:29] cjwatson: is theres a source youd recommend for understanding what -Bsymbolic-functions does? [11:30] When creating a shared library, bind references to global function [11:30] symbols to the definition within the shared library, if any. [11:30] is what 'info ld' says [11:31] 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] So if you have a "malloc" symbol in your program then that also overrides malloc for any libraries it loads [11:32] Actually, sorry, that's misleading [11:33] Let's say you have a curl_getenv symbol in your main program - that would ordinarily override the one in libcurl [11:35] 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:37] 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] Does that help? [11:37] yes, very much [11:40] 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:41] Right, and because inner is static its value is saved across invocations [11:41] yep [11:42] 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] So the preloaded connect gets to communicate with recursive calls to itself [11:42] Ubuntu bug 1077153 in python2.7 (Ubuntu Precise) "Backport request: http://bugs.python.org/issue14308" [Undecided,Triaged] [11:42] The RTLD_NEXT trick is the glibc-specific bit, I believe [11:42] yeah, it is [11:42] Hence #define _GNU_SOURCE [11:42] yep [11:42] if youre going to do that btw [11:43] well, i gues you couldnt matke it static then [11:43] make which static? [11:43] but typeof(connect) connect_real [11:43] oh, yeah [11:43] makes the function pointer syntax less obnoxious [11:43] I figured it didn't really matter since we already need to know the type for the wrapper function [11:43] yeah [11:43] But feel free to polish further :) [11:44] ok, so Im still missing something here I think [11:44] lets say bar.c is our program which uses libcurl. wont it still hit connect in libfoo? [11:45] Is libcurl being used in the main program as well as in the preloaded wrapper? [11:45] possibly [11:45] well, yes, it will be [11:45] in some cases [11:45] You'll have to figure out when you want your wrapper to take effect and when you don't [11:45] But you should have enough flexibility this way to vary the policy [11:46] If all else fails you could wrap curl functions just for the purpose of noticing that you'd entered them ... [11:46] (You'd need a file-scope static variable then) [11:46] yeah, ok [11:46] that makes sense [11:46] heh, christ what a PITA :) [11:47] 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:48] xnox, upstream commit link is this one: http://hg.python.org/cpython/rev/ab9d6c4907e7 [11:49] 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:52] 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:53] cjwatson: because all my functions call their real versions [11:53] vibhav: meh, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-ncurses/1/ARCH=i386,label=adt/ fails [11:53] cjwatson: and return the same results, they just perform some db operations along the way [11:53] vibhav: that may be because the test doesn't actually have a stdout/stderr? [11:59] 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..... [12:00] 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] jrp: *nod* makes sense [12:01] xnox, ack [12:02] pitti: did any body write UDisks2 template for dbus-mock yet? [12:02] xnox: not that I know of [12:03] 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:04] xnox: yeah, and might be useful for other tests, too [12:05] xnox: "trust" in which sense? fails in tests? or just a gut feeling? [12:05] (fails in manual test, I mean) [12:05] 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:06] 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:07] manual tests are ok, apart from failure conditions not that well tested (what if it's unplugged at various points of progress) [12:10] cjwatson: thanks again, its past time for me to pass out. i owe you a sixpack [12:10] cjwatson: feel free to collect if youre ever in Oregon === _salem is now known as salem_ [12:30] xnox, will something like this https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1119195 work for an SRU? [12:30] Ubuntu bug 1119195 in python2.7 (Ubuntu) "_DummyThread' object has no attribute '_Thread__block" [Undecided,New] [12:30] grr, could someone remove xserver-xorg-video-s3 and -qxl from raring-proposed? [12:30] mistakenly uploaded there [12:31] someone as in archive admin.. [12:31] tjaalton: they shouldn't be there at all or you're going to fix in a subsequent upload? [12:31] Laney: not at all, should be in canonical-x/x-staging [12:31] seb128: didrocks: ^^^ [12:32] nothing critical there, it's basically just a rebuild [12:32] but would save yet-another upload :) [12:33] Gwaihir: looks good. I'm confused why you filed it as a new bug, instead of updating the existing one =) [12:33] 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] tjaalton: ^ [12:33] xnox, the old one was marked as Fix Released... [12:34] didrocks, I think you can just delete from proposed (as you would delete a source from the archive), but I never tried [12:34] Gwaihir: bugs can have tasks. Precise task was not "Fix Released" [12:34] Gwaihir: e.g. we track bugs per-series =) [12:34] right, it's still pending, so should be doable [12:34] seb128: same, I think that the manual removals enable that, but I prefer people knowing to do it first :) [12:34] xnox, yep... right... my bad, I can update the other one [12:35] Gwaihir: don't worry. Let me sort it out. [12:35] xnox, thanks [12:36] Gwaihir: now, that's better. Note that it will have to wait until after 12.04.2 is released. [12:36] bug 1077153 [12:36] bug 1077153 in python2.7 (Ubuntu Precise) "_DummyThread' object has no attribute '_Thread__block" [Medium,Triaged] https://launchpad.net/bugs/1077153 [12:36] tjaalton, Laney, didrocks: trying "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3" [12:36] xnox, ok, thanks again [12:36] Gwaihir: in the mean time you can just catch and ignore that attribute error ;-) [12:37] seb128: same for -qxl? [12:37] trying [12:38] thanks :) [12:38] lp shows it as published in the proposed pocket now [12:38] *them [12:38] let me block them to be safe [12:40] yeah, command doesn't work for atm [12:40] items = gnomekeyring.find_network_password_sync(username, service) [12:40] gnomekeyring.IOError [12:40] hoho [12:40] you might want https://rbtcollins.wordpress.com/2013/01/24/launchpadlib-without-gnome-keyring/ [12:41] didrocks, does "./remove-package -m "uploaded by error" -s raring-proposed xserver-xorg-video-s3" work for you? [12:41] let me try [12:41] my session is screwed, compiz froze again [12:41] and I didn't want to restart [12:41] I ran it from a vt, which restored UI but broken env [12:41] 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:42] seb128: Laney: tjaalton: flushed [12:42] didrocks, same for qlx please ;-) [12:42] qcl [12:42] qxl [12:42] ups [12:42] yep, looking first at what's happening in launchpad for -s3 [12:42] I need to report that compiz issue [12:42] didrocks, seb128, Laney: great, thanks! [12:42] it's frozen every second time I come from a guest session since I started using a second monitor [12:43] ok, seems that -raring still have a package :) [12:43] didrocks, that command is what https://wiki.ubuntu.com/ArchiveAdministration recommends to remove buggy SRUs [12:43] seems like it worked [12:43] didrocks: do the same for -qxl too [12:43] didrocks, so I figured it would be similars ;-) [12:43] -qxl done :) [12:43] ah, echo [12:43] :) [12:43] so be aware that you can't reuse that version next time [12:44] oh [12:44] seb128: yeah, I feel more confortable when seeing it's what is done for SRUs ;) [12:44] well this was a useless excercise then :) [12:44] tjaalton: tsss tsss, let's say it was for exercising our fingers at least! [12:44] not completely useless ;) [12:44] heh, ok [12:45] tjaalton: thanks for checking my health :) [12:45] * didrocks hugs tjaalton [12:54] didrocks: :) === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_jackyalcine [13:26] Gwaihir: .3, we are frozen for .2 [13:40] 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) === wedgwood_away is now known as wedgwood [13:41] ogra_: all the way to using -m or simply without warning stanza? [13:41] all the way to the last known working setup [13:42] * xnox ponders if all the default no-warning should be listed as well on the command line. [13:42] i dont want to block QA so we need a quick fix for now [13:43] since we dont have milestone images anymore we could point people to for a last known good install ... [13:51] and uploaded ... [13:51] * ogra_ will trigger a manual image build later, once the cron build is done [14:01]