=== PaulW2U_ is now known as G4MBY [00:23] Now here's a descriptive changelog entry for you: "Bugger off cdbs, may it burn in hell." [00:24] lol [00:24] <\sh> a good one ;) === cpg is now known as cpg|away [00:25] Closes: all the bugs, without a doubt === cpg|away is now known as cpg [00:40] anyone know how to disable make check in dh7? [00:41] I’d try “override_dh_auto_test:” first. [00:42] yes [00:42] if you want it disabled at the package level [00:42] if you want to disable it temporarily for a local build, DEB_BUILD_OPTIONS=nocheck [00:42] thanks [00:42] but why are you disabling tests? :) [00:43] slangasek, libsecret tests aren't running for some reason when building with debuild, but do work fine when using local build [00:43] missing build dep? [00:43] no, this is building locally in both cases (one using bzr-buildpacakge, one in git) [00:44] and I think at least one test required $DISPLAY [00:44] ah [00:45] ideally 'xvfb-run make test' then [00:45] er, check [00:45] but too many things are blocking on it now, so really need to get it working [00:45] * slangasek nods [00:45] * slangasek reads about libsecret. Why is upstream replacing gnome-keyring? :P [00:46] it's a rewrite and it's no longer gnome specific [00:46] same authors [00:46] hmm [00:46] same interfaces? :) [00:46] nope [00:46] bleh [00:46] I think it's an opportunity to learn from past mistakes [00:46] well, I guess the set of revdeps is manageable anyway === cpg is now known as cpg|away [00:47] You might also need dbus-test-runner, which someone should get to Debian, too. [00:47] btw, does anyone know the correct way to make GIR files install into /usr/lib/girepository-1.0 when the libraries are multi-arch? Or should gir files be multiarch too> [00:47] ? [00:48] ideally they should be in the multiarch dir [00:48] since they are arch-specific and you may want them for more than one arch at a time [00:49] slangasek, does that work? There don't seem to be any other packages doing that [00:49] robert_ancell: there's precisely one package doing this currently: gir1.2-guestfs-1.0 [00:49] dunno if it works [00:49] most don't because of the gir bits being from a different, non-multiarched source package from the C lib [01:26] is quantal archive frozen or anything? [02:06] roaksoax: Not officially. We're trying to collect a stack of packages to accept all at once for scalability testing. see cjwatson's mail on freezing to Ubuntu devel. [02:50] benc: BTW, I uploaded the PowerPC fixes for lightning to our staging PPA, I'm waiting on the branch that quantal is using to upload that one [02:51] micahg: I saw it built successfully, glad I could help [02:51] benc: thank you, that means we get coverage across the board 6 weeks early [02:51] well, except for the broken neon on arm*... === cpg|away is now known as cpg [03:08] micahg: Which broken neon on arm? [03:09] ScottK: We're not trying to get a stack of packages to do at once, just to do lots of different packages via the CLI tool to see if anything explodes or times out. [03:09] infinity: the thing you fixed in quantal [03:09] just having it enabled at build time [03:09] micahg: Well, sure, but I fixed it, so I was curious about the "still broken" bit. [03:10] infinity: If we aren't we should. When I had trouble with the web UI, it was mostly with multiple accepts. Very rarely was it a single package. [03:10] (Well, "fixed"... With a bit of a large hammer) [03:10] infinity: well, I meant in the stable releases it'll be broken unless we need a respin [03:10] or until th next train [03:10] ScottK: If you have to slim down to a single package here and there, such is life. At least that's trivial with the CLI (queue info | mangle output | xargs queue accept) [03:11] ScottK: The concern is that there could be single packages that will end our world. [03:11] but otherwise, we have all archs back (well, except for sparc/ia64, but who's running a lucid desktop on that these days anyways) [03:12] infinity: Yes, but it varies. If you can accept them in large stacks, the odds you get screwed by one go down as the only times I ever had problems with specific individual packages were also times I was constrained by the number it would do before timeout. [03:12] ScottK: *shrug* [03:12] And doing them one at a time you never know if you tried one of the 'harder' ones or not. [03:12] ScottK: I'm literally just blindly batch-accepting what's in unapproved occasionally. [03:12] OK. [03:14] * ScottK is trying to kill off Debian RC bugs tonight. Got 5 so far today. === cpg is now known as cpg|away [03:30] infinity: How do orphaned packages get dropped from the archive? [03:30] e.g. kde-runtime no longer creates kde-runtime-dev, but it's still a valid package (although uninstallable) [03:31] at least one thing build-deps on it (plasma-mobile), but of course, it can't be built now (I'm planning on fixing the build-deps after I verify it) [03:36] Good morning [03:40] BenC: I've been waiting on the last merger of plasma-mobile to package up a new upstream snapshot that makes it sane and buildable again. [03:40] BenC: We drop NBS packages when nothing is left depending on them. [03:41] infinity: Ok, then I'll leave plasma-mobile till then [03:41] BenC: Yeah, changing build-deps won't be enough, already been there. ;) [03:42] BenC: Have you met http://people.canonical.com/~ubuntu-archive/nbs.html ? [03:43] No, but thanks [03:43] More lengthy than I would have guessed [03:43] It'll start shrinking rapidly, now that Debian autosyncs are off. [03:46] * micahg wonders when we'll get our first rebuild [03:46] doko wanted to do one late last week. He must have forgotten in the excitement of kayaking and bodysurfing. [03:48] great, I'm curious to see what havoc gcc-4.7 and the various new upstream imported have wreaked on the rest of the archive [03:49] gcc-4.7 shouldn't be too bad, in that rebuilds were done already and bugs filed. [03:49] But I'm sure some where missed. [03:49] I think getting the NBS list down before a rebuild is sane anyway. [03:50] Since lots of stuff is FTBFS right now with broken or out-of-date build-deps. [03:50] well, we have --as-needed by default :) [03:50] although, that's old news [03:50] I've not noticed any weird interactions between 4.7 and as-needed... Have you? [03:50] Seems to be business as usual. [03:50] no, not really, which means it's about time for me to go to sleep :) [03:50] Toodles. === cpg|away is now known as cpg === cpg is now known as cpg|away [05:07] cjwatson: just accepted two pacakges from quantal/unapproved using the local queue tool; great work on this! === cpg|away is now known as cpg === cpg is now known as cpg|away === cpg|away is now known as cpg [06:59] rbelem: Did anything ever come of the plan to update plasma-mobile in quantal with a newer version? === philipballew__ is now known as philballew [07:15] ScottK,infinity: Lots of packages at once will definitely not be a problem with the API client. The timeout is applied per request, and acceptFromQueue is a method on individual PackageUpload objects, so the client always (has to) accept one at a time regardless of how many you give it on the command line. [07:16] ScottK: I know skaet occasionally reported problems with even accepting a single package using the web UI. [07:17] But it's true that lots at once greatly increased the odds. [07:19] pitti, weird - now booting without 'quiet splash' seems to have worked *shrug* [07:20] dholbach: yeah, it always works for me as well [07:20] something weird with the plymouth integration of encrypted swap devices or so [07:20] but it got stuck 3 times before [07:20] maybe it's just intermittent [08:16] hi, http://paste.ubuntu.com/1096244/ ^^ === cpg is now known as cpg|away [10:27] cjwatson, hey, do you know if that ubiquity issue is know,being worked? (that's one of the most reported issues on errors.ubuntu.com)? [10:27] https://errors.ubuntu.com/bucket/?id=/usr/lib/ubiquity/bin/ubiquity:ValueError:watch_debconf_fd_helper:process_input:wait:cleanup:preseed:%3Clambda%3E:command [10:28] cjwatson, I find some similar looking bugs in launchpad bug I'm not sure they are exact matches [10:32] cjwatson, like the title on bug #986804 matches but the bug has hardly any detail [10:32] Launchpad bug 986804 in ubiquity (Ubuntu) "ubiquity crashed with ValueError in command(): I/O operation on closed file" [Undecided,New] https://launchpad.net/bugs/986804 === jibel_ is now known as jibel [10:45] seb128: do you know what's the yellow bits on http://people.canonical.com/~ubuntu-archive/pending-sru.html ? [10:45] that seems to be new, and not documented in the header [10:46] bdmurray explained in #-release [10:46] it means "new comments since v-done" IIRC [10:47] pitti, I was wondering the same thing today [10:47] oh, I see the commit [10:47] " sru-report: as a first draft change the bug color to yellow if it's date_last_message is later than the publishing date of the package [10:47] " [10:47] sru-report: as a first draft change the bug color to yellow if it's date_last_message is later than the publishing date of the package [10:47] snap :p [10:48] I like that they are sorted by time in proposed btw [10:48] hm, why would that need date of last message? if someone flips it to v-done, it'd still be yellow? [10:48] pitti, no, v-done are green [10:48] ah, so that means "a bug which should be inspected by the SRU team" [10:48] perhaps as a replacement for reading bug mail [10:48] pitti, it's to see which ones might need an update, i.e are still verification-needed but got comments [10:49] it might be that a commenter verified or reported a regression but didn't know to tg [10:49] tag [10:49] pitti, I guess so [11:22] Laney: I'm getting a curious build error when compiling against libxml2 [11:22] http://paste.kde.org/518930/ [11:22] Laney: if I rebuild libxml2 it goes away [11:23] do you recon it would work if I just rebuilt it in the archive? [11:23] erm [11:23] did zlib break abi? === MacSlow is now known as MacSlow|lunch [11:26] Laney: it has had multiarch things going on [11:29] hmm [11:29] libxml2 was uploaded after zlib [11:34] Riddell: is your chroot fully updated? [11:36] Laney: should be but let me try again [11:38] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673297 [11:38] Debian bug 673297 in libxml2 "mipsel: /usr/lib/mipsel-linux-gnu/libxml2.so.2: undefined reference to `gzopen64@ZLIB_1.2.3.3'" [Critical,Open] [12:38] Laney: that fixes it, thanks :) [12:38] ;-) [12:41] pitti, pingaling [12:41] pitti, i'm testing ac100 images atm, while running "ubuntu-drivers list" gets me the proper return value (nvidiy-tegra), i dont get anything in the drivers gui [12:41] ogra_: pongedidong [12:42] any hint where i should look ? [12:42] ogra_: we don't have a drivers guy yet, it's still in a branch of didrocks'/cyphermox' [12:42] oh, so what i see it the old jockey [12:42] yes, that'll go away [12:42] k, that explains also why it works on the pandaboard :) [12:43] ogra_: "drivers guy" argh, "driver GUI" [12:43] (we didnt have a jockey hook for ac100, but for omap4) [12:43] pitti, thanks a lot [12:43] I'm currently working on the backend API, then didrocks will have it finished in no time, I'm sure [12:43] I hope we can land it for a3 [12:43] yeah, yesterday ... [12:43] he is did*ROCKS* after all :) [12:44] +1 [12:44] ogra_: pitti is doing all the hard work, don't trust this free ad ;) [12:45] didrocks, verbally bluching wont help, you still rock ;) [12:45] *blushing [12:45] heh :-) [12:45] didrocks: system_device_drivers() just pushed; feel free to use from git (just set PYTHONPATH) if you want to play with it already [12:46] pitti: \o/ thanks a lot! [12:46] * didrocks pulls [12:46] didrocks: I'll add a new mode to ubuntu-drivers ("by-device") so that you can use it in textual form [12:46] pitti: that will be really handy :) [12:47] btw, since i just built a new machine here and added two graphics adapters ... if someone would be insane enough to add radeon and nvidia cards at the same time to the same machine, can we finally handle that case ? [12:48] (iirc there were issues with the GL libs, i was wondering if multiarch saves us from that) [12:48] ogra_: /usr/share/ubuntu-drivers-common/fake-devices-wrapper (e. g. ubuntu-drivers or didrocks' GUI), and you'll have both of them :) [12:48] well, would they also *run* ? [12:48] but yes, nvidia still replaces the system's GL libray; I woudl have thought that tseliot's alternatives handling might save us here, though [12:49] ah, yeah [12:49] you can't run them both at the same time, I'd guess [12:49] but at least switch between the two without changing packages [12:49] yup [12:52] pitti: ah, http://paste.ubuntu.com/1096566/ using the wrapper [12:52] didrocks: in case you pulled already, please pull -f [12:53] didrocks: yup, that's what I just fixed, sorry about that [12:53] no worry :) [12:53] didrocks: fglrx isn't being tested in the test suite, bad me :/ [12:53] pitti: you rewrote history, how dare you! (j/k) [12:53] didrocks: but presumably I just did the very thing you tried [12:53] heh, seems so :) === _salem is now known as salem_ [12:53] yeah, I prefer consistent commits, as long as the previous push hasn't been too long ago [12:53] pitti: was just kidding :) [12:54] * pitti hugs didrocks [12:54] * didrocks hugs pitti. Thanks for your good work! [12:58] pitti: looks perfect to me, but yeah, some case in the wrapper where you create a fake "manual_install" one will be good. Will fake that into the my system answer for now === MacSlow|lunch is now known as MacSlow [13:08] didrocks: any suggestions? http://paste.ubuntu.com/1096582/ [13:12] pitti: you don't have an example from not comming from distro as far as I can see (but this is linked to the manual_install discussion we had I guess). Otherwise, the needed info seems there! Great :) [13:12] pitti: no ascii orders for attributes? [13:12] right, no support for the manual flag yet [13:12] didrocks: sorry, ascii orders? [13:13] pitti: like "builtin distro free" instead of "distro free builtin" [13:14] didrocks: it's a pretty arbitrary order, but I can change it around if you want; but it's just a debugging tool anyway [13:15] pitti: right, I was wondering if later we want to do some platform tests using it [13:15] didrocks: oh, it's a predictable (i. e. stable) order [13:15] so you can string-match it if you want [13:16] ok, as long as we have examples on the order, that's fine :) [13:19] why is user /usr/bin/python still pointing to 2.7 in quantal? i thought that was fixed? [13:19] ogra_, pitti: you can do that as long as you use open drivers for both cards ;) [13:20] brendand: fixed how? "python" will always be python 2.x [13:20] python3 is 3.x [13:20] tseliot, lol, well, then i wouldnt use ubuntu-drivers i guess [13:21] pitti - ok. maybe a different issue then. but apport-cli points to python so is not running on quantal [13:22] brendand: oh, bug [13:23] pitti, right. so the approach is that the applications need to change their shebang, rather than point /usr/bin/python at 3.2? [13:23] yes, as soon as they got ported to py3 [13:23] brendand: I made a note to fix the shebang of apport-cli [13:26] stgraber: FYI, the partman-target piece of Bug #992241 is done (in -updates) and I copied the pending Ubiquity SRU as well, so the path is clear to do the Ubiquity part of that one. [13:26] Launchpad bug 992241 in ubiquity (Ubuntu Precise) "Upgrading using the live cd wipes /var/lib/mythtv/*" [High,Triaged] https://launchpad.net/bugs/992241 === zyga is now known as zyga-afk [13:39] ScottK: thanks. I'll prepare an ubiquity upload today. [13:47] dholbach: sponsors-queue crashes on my system with: lazr.restfulclient.errors.ServerError: HTTP Error 503: Service Unavailable [13:47] dholbach: does it work on your system? [13:48] let me see [13:52] bdrung, still running [13:56] bdrung, it works [13:57] hi, I am trying to develop some graphics app, and somehow I get errors when trying to open a window with GLFW and GLUT... GLFW tells me nothing, but GLUT says something about a framebuffer missing [14:03] dholbach: it's reproducable here: http://paste.debian.net/179474/ [14:03] bdrung, I won't have the time to look into it, I'm afraid [14:29] LambdaDusk: It seems #ubuntu-app-devel might be a better place to ask. === zyga-afk is now known as zyga [15:13] Laney: Any idea when ghc-7.4.2 is coming? [15:13] 17/07 12:28:02 oh, ok. will do. [15:13] 17/07 12:28:37 maybe not today, bit busy. should be over the next couple of days. [15:13] It appears to fix a test suite failure in cryptocipher on ppc [15:14] Ok, thanks [15:30] any idea or bug # when theming aka square radio buttons will be fixed? [15:30] seb128: or somebody else? ^^^ [15:31] xnox, no idea, I didn't even know they were broken [15:31] kenvandine, ^ [15:31] seb128: are you using quantal? =))) [15:31] they are a little ugly, not sure if there is a bug filed for it [15:31] xnox, no, I'm on the 12.04.1 team [15:31] sladen, you have some unpushed changes in ubuntu-mono. Is trunk OK to push to quantal? (I have a imagemagick4->5 transition that I wanted to push) [15:32] the theme needs quite a bit of love, which hopefully will happen real soon [15:32] xnox, wouldn't hurt to file a bug [15:32] * ogra_ has seen this being discussed here several times [15:32] would be surprising if there wasnt a bug already [15:33] kenvandine: it looks as if, it's the fallout from theming brake upstream [15:33] xnox, yeah [15:33] ogra_: kenvandine: it's just I want to subscribe to know when it will be fixed "for real" [15:33] there are quite a few things broken because of upstream changes and our theme not keeping up [15:33] yeah, highvoltage mentioned it once and mpt tracked it down to a gtk regression IIRC, I seem to remember an LP bug being mentioned [15:34] iz gtk boog [15:34] stgraber: was it something like "invalid network-manager & ubiquity, fix-release light-themes?" [15:34] mpt: lolz =) [15:34] mpt: do you have a bug number on a square post-it note at your desk by any chance? =) [15:34] xnox, if anyone knows, it's Cimi [15:35] I just asked him and he waved his hand jedi-like and said "everything will be fixed" [15:35] xnox ftw [ funny ] [15:35] bug 1015497 [15:35] Launchpad bug 1015497 in gtk+3.0 (Ubuntu Quantal) "Cannot select gtk dropdown list value in multiple applications: ubiquity, landscape client" [High,Triaged] https://launchpad.net/bugs/1015497 [15:36] is the closest I can find [15:37] kenvandine, can you sort out https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/762167 [15:37] Launchpad bug 762167 in light-themes (Ubuntu) "missing dependency on gtk2-engines-pixbuf" [Low,Triaged] [15:37] mterry: to the best of my knowledge, yes [15:37] bug 1024099 [15:37] Launchpad bug 1024099 in light-themes (Ubuntu) "Widgets look square" [Undecided,In progress] https://launchpad.net/bugs/1024099 [15:37] sladen, cool, thanks [15:37] mterry: try it and see, and if not, poke me again and I'll do some more investigation about what it/was [15:38] smoser, again... [15:38] :) [15:39] smoser, yes.,.. i will [15:39] kenvandine, i dont think you ever uploaded. i pinged you once after you uploaded without the fix, but i'm sure it just got lost in the hussle. [15:39] its partially my fault for not just doing an upload, but pushing to lp:ubuntu/ branch [15:39] smoser, no i am sure i did upload it [15:40] hm.. [15:40] ah. [15:40] then the bug is just probalby in the wrong state. [15:40] but the packaging branch got moved around a couple times [15:40] (i see it just got moved from fix released to triaged) [15:40] so it might have gotten accidentally reverted [15:42] smoser, oh... we fixed it by not needing it [15:42] - Remove the need for gtk2-engines-pixbuf in the gtk2 theme, [15:42] saves some CD space [15:47] smoser, so if it is still actually needed, it is a bug in the theme [15:48] kenvandine, ok. good enough. then i think the users of that bug are generally just confused. [15:48] so do you believe this to be fixed in precise? [15:48] yes [15:48] that version was in april [15:48] if so, can you please comment on that in the bug. [15:48] i just did [15:48] great. thank you sir. [15:48] np [15:48] sorry for the fire drill [15:48] no worries [15:48] :) [15:49] if it is still printing the warnings then the theme needs fixing === dendrobates is now known as dendro-afk [15:56] jodh: any plans to add seccomp-bpf to upstart? :) [16:06] can an archive admin review python-cliff, python-django-compressor, python-django-appconf, and python-tablib please === beuno is now known as beuno-lunch [16:14] kees: no plans this cycle. I wasn't even aware of this feature: although the kernel supports it, the include files and man pages don't appear to cover it yet. === beuno-lunch is now known as beuno [16:17] jodh: it's in 12.04 via a backport. it's all in 3.5. === jbicha is now known as Guest50245 [16:53] Good evening [17:05] didrocks, hi, I am having a look at your project session-migration. Is there a way to try that out in Ubuntu 12.04? [17:06] didrocks, I guess I could compile it and package it? [17:06] nandersson: just retake the same packaging, it should work [17:07] didrocks, Ok, thanks! [17:07] yw :) [17:09] i tried to import totem source code to eclipse but i get an error message: [17:09] make: *** No rule to make target `all'. Stop. [17:09] the message appears after building in eclipse === shadeslayer_ is now known as evilshadeslayer === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan [17:28] I'm off and on, I sent you an email 8) [17:32] ogra_: hey ogra_, so you're officially ogra underscore now? :) [17:37] highvoltage, i'm ogra underscore since hmm, three years now ... [17:37] * highvoltage takes long to adjust to these things [17:37] since i started using a proxy and got to lazy to fight with nickserv [17:49] ogra_: Three year is some serious lazy. [17:49] ogra_: Maybe you should just fix it? :) [17:51] how do you add a ppa to a chroot build phase with livecd-rootfs? [17:52] infinity, i will if i switch to a better proxy :) [17:54] @pilot in === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry === cpg|away is now known as cpg === Guest50245 is now known as jbicha === jbicha is now known as Guest72435 === Guest72435 is now known as jbicha_ === kentb-out is now known as kentb [18:22] indirect linking isn't working for me with multiarch cross-building http://paste.debian.net/179495/ [18:23] scientes: kytokabinet is underlinked, either link it correctly or disable as-needed [18:23] oh ok [18:24] why does it work natively then? [18:24] is kyotocabinet also not linked against lzma natively? [18:24] it is [18:24] i mean, it is linked against lzma [18:25] although ldd doesn't work cause the binary is foreign [18:25] you need to do the same for the cross build [18:25] That's easily fixable. [18:25] but i copied it to a armel host, and ldd worked [18:25] yeah it seemed like something that the multi-arch stuf should handle [18:25] infinity, what is easily fixable? [18:26] scientes: The ldd thing is on my TODO. I had hoped to sort it for wheezy (and maybe I'll still try to squeeze it in) [18:26] do i just need to link against everything, even that which is indirect? [18:26] ok, and when ldd gets fixed it should work? [18:26] scientes: As for your linking issue, it shouldn't relate to the ldd thing, no. [18:26] scientes: you also need to disable as-needed [18:26] scientes: Could just be that the cross toolchain is lacking sane -Ls? [18:27] infinity, is that in LDFLAGS, cause if tou see the paste i tried adding those [18:29] scientes: I see a shocking lack of whitespace in -D_KC_APPLIBS="\"-L/usr/lib/arm-linux-gnueabi [18:29] In fact, I'm not sure what that's meant to do. :P [18:30] Oh, I see. That's a big long list with the -lfoo as well. [18:30] I'm misreading that bit. [18:30] that first one works [18:30] Misreading it as something that makes sense to pass to a compiler. [18:30] Which that doesn't. [18:30] its when its indirectly linked it doesn't [18:31] thats because it isn't, kyto is not linked against lzma [18:31] jtaylor, but it IS [18:31] oh [18:31] i copied to a a armel host and checked with ldd [18:32] scientes: Does the exact same command line also work on armel? [18:32] I misunderstood you before then [18:32] infinity, good question [18:32] ldd -r shows no undefined references? [18:33] http://paste.debian.net/179516/ [18:34] infinity, yes it does work on arm, and creates the kcutiltest binary, which works [18:36] Curious. [18:36] I'm inclined to blame the crosss toolchain, but not entirely sure what to blame it for doing off the top of my head. [18:36] with g++-4.7 too [18:37] i had this problem with the emdebian squeeze g++-4.4 [18:37] then compiled it according to instructions here: http://gsoc.sitedethib.com/posts/apt-get_install_gcc-4.7-arm-linux-gnueabihf/ [18:37] and had the exact same problem [18:37] At least it's consistent. ;) [18:37] and i subbed armel and eabi, for armhf stuff [18:38] Is this a source package I can test? I suppose I could just do a minimal testcase, but that sounds like effort. [18:40] if you do DEB_BUILD_OPTIONS=nocheck the kyotocabinet from unstable/quntal will work [18:40] but it doesn't even get that far, so it doesn't really matter [18:40] have you tried without as-needed? [18:49] Steve Langasek on #multiarch on OFTC says its a known bug with ld [18:49] Mmkay. [18:50] https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingMultiArch, search on "DEB_LDFLAGS_APPEND" [18:50] in particular, -Wl,-rpath-link=/usr/lib/arm-linux-gnueabi:/lib/arm-linux-gnueabi:/usr/lib is used to work around this wrong default in the cross-binutils package [18:51] This seems easily fixable in the cross toolchain... [18:51] nothing ever seems easily fixable in the cross toolchain, AFAICT :) [19:28] SpamapS, around? [19:29] /etc/init/cloud-init-local.conf is: start on mounted MOUNTPOINT=/ [19:29] is that guaranteed to have /run or /dev/shm? access? [19:29] no [19:30] smoser: virtual-filesystems would guarantee that, I think. [19:30] but does not block [19:30] virtual-filesystems definitely would guarantee that. [19:30] I haven't looked in a while when MOUNTPOINT=/ is emitted [19:31] i think its not guaranteed. === AlanChicken is now known as AlanBell === zyga is now known as zyga-afk === jbicha_ is now known as jbicha [20:10] Would someone who understands something about Java look at Bug 937710? It appears that the SRU we just copied to -updates might not have fully resolved the bug. [20:10] Launchpad bug 937710 in visualvm (Ubuntu Precise) "[SRU] VisualVM does not start with openjdk 7" [Undecided,Fix released] https://launchpad.net/bugs/937710 === lfaraone_ is now known as lfaraone [21:26] Thanks for the detailed code review, barry! I'll be able to jump into that later this week, I hope :) Mpt filed a bug report about the height of the updates list earlier today: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1025674 [21:26] Launchpad bug 1025674 in update-manager (Ubuntu) "List of updates is much too short by default" [Undecided,New] [21:26] Fixing it should be pretty painless. Just needs different defaults in dconf to start with. (Though some fancier design-related updates might lead to good places, too). [21:28] dylan-m: sure thing! thanks very much for the branch. since there's a separate bug on the details height, don't feel obligated to fix that in your branch. i.e. it could be fixed in a separate branch, but if the fix is easy and you want to include it in your updated branch, feel free to do so! please do link your branch to that bug if you do though. [21:28] dylan-m: and feel free to ping me if you have any questions or just disagree with me. :) === salem_ is now known as _salem [22:50] Is there a way to get the slightly older firefox 13 source packages off launchpad anywhere? I want to put them in a PPA [22:51] YokoZar, debian has esr releases in wheezy, you could just rebuild those [22:51] which is firefox 10 [22:51] otherwise you shouldn't run older versions of firefox, except for regression testing [22:52] *bisecting [22:52] scientes: right, that's what I want to do [22:52] YokoZar: why ,that's not recommended [22:52] YokoZar, just use mozregressions [22:52] its super awesome and downloads the daily builds from ftp.mozilla.org [22:52] micahg: I have an environment where we have to do a good chunk of manual work to support each new firefox release [22:52] and they have them back for years [22:53] YokoZar: you want the ESR then [22:53] micahg: the proper solution to this is to grab packages from our own repository and update it when firefox updates [22:53] ^^^^^^^^^^^^^+1 for esr [22:53] YokoZar: aside from whether it's a good idea or not, https://launchpad.net/ubuntu/+source//+publishinghistory for any source package has everything [22:53] YokoZar, precise runs firefox esr [22:53] cjwatson: ahh yes I was hoping for that :) [22:53] AFAIK [22:53] scientes: hrm? we just pushed out 14 [22:53] oh yah [22:53] whoops [22:53] though it might time out for a big package like firefox. you can use https://launchpad.net/ubuntu/+source// directly [22:53] micahg, you should also package esr [22:54] well s/big/old/ I guess [22:54] oh wow, you push out ff14 to even lucid [22:54] YokoZar: as long as you're updating your own packaging to the latest release, or staying on the ESR, you're fine, otherwise, you're open to security issues (and even the ESR might have some, but hopefully not critical ones) [22:55] scientes: have you read http://www.chriscoulson.me.uk/blog/?p=111 [22:56] micahg, so that is the real reaon you do not build libxul as a shared library anymore? [22:56]