=== freeflying_away is now known as freeflying === zoktar_ is now known as zoktar === cjohnston_ is now known as cjohnston === cmagina_ is now known as cmagina === xnox_ is now known as xnox === freeflying__ is now known as freeflying === ValicekB_ is now known as ValicekB === Pici is now known as Guest56659 === jamesh__ is now known as jamesh === King is now known as Guest15270 === cr3_ is now known as cr3 === cr3 is now known as Guest7788 === ejv_ is now known as ejv === Logan__ is now known as Guest74751 === Zic_ is now known as Guest20290 === Guest74751 is now known as Logan_ === Logan_ is now known as Guest96987 === Guest96987 is now known as Logan_ === Zic is now known as Guest47791 === TheLordOfTime is now known as teward === Logan_- is now known as Logan_ === wcchandl1r is now known as wcchandler === wgrant is now known as Guest34733 === Guest7788 is now known as cr3 === cr3 is now known as Guest98044 === dobey_ is now known as dobey === Guest98044 is now known as cr3 === cr3 is now known as Guest18723 [05:27] Good morning [05:33] pitti: Yo yo! [05:34] pitti: Hey, what does error() do in vala? [05:34] RAOF: that's g_error() in C (from glib), i. e. print that message to stderr and abort() [05:35] Ah, right. Yeah, that's what I though. [05:35] Ok, valac just fails at code flow analysis. [05:35] RAOF: Vala pretty much uses the GLib API without those prefixes, and with proper class.method() notation instead of g_class_method() in C [05:35] heh, it might not consider error() as a definitive "ends here" [05:35] "proper". [05:36] Indeed it does not consider error() to abort the function. [05:36] RAOF: I'm not sure whether you can make error() not abort, but I don't think you can [05:36] RAOF: warning() and critical() can abort() if one wants, but don't by default [05:36] Anyway, initialising the string to "" silences the “You might use this unassigned!” error. [05:37] that's just a warning, no? [05:37] (but fixing warnings is appreciated) === timrc is now known as timrc-afk [05:42] It's apparently a fatal error. [05:42] Oh, and it's not control-flow failure! It's failure to understand scanf("%ms", &str) [05:47] pitti: Enjoy your new pull request. === Guest18723 is now known as cr3 === cr3 is now known as Guest74606 [05:52] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Mirv [05:52] \o/ === stub` is now known as stub === Guest34733 is now known as wgrant [06:06] RAOF: hah, thanks [06:41] cjwatson: I'd like to seed xorg-lts-transitional as we need it in trusty (only) for upgrading from 12.04.[1-9] [06:42] cjwatson: is there a clever trick to say "seed all binaries from this source except for these three (the geode driver is in universe), or do we need to manually seed all 253 binary packages? [06:42] cjwatson: I'd put them into platform/desktop-common, and comment that they should be removed again in trusty+1; does that place sound ok? [06:44] pitti: A combination of %source and !binary might work, but I'm not sure if germinate is smart enough to reconcile that conflict. [06:45] infinity: *nod* [06:46] pitti: Not like it's hard to add the 253 binaries. Just looks a bit messy. We'll delete it in 14.10 anyway. [06:46] cjwatson: ah no, desktop-common gets installed; perhaps supported-hardware-desktop? [06:46] pitti: supported-hardware-desktop sounds sane. [06:47] infinity: no, it'd be easy, I was just curious whether %xorg-lts-transitional and !xserver-xorg-video-geode-lts-quantal (and -raring/-saucy) would work [06:47] pitti: Or just supported, where I already have a 'Transitional packages:' section. [06:47] infinity: but I guess I could just add it there and see what http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has to say about it [06:47] infinity: ah, even better [06:47] infinity: that's not in platform.trusty then, but in ubuntu.trusty? [06:47] That section is likely incomplete, I only add things when I notice the oops. [06:47] pitti: ubuntu.trusty, yeah. [06:50] infinity: ok, committed; I'll check c-m in a bit [06:50] thanks [06:50] pitti: I suspect that won't work, but I guess you'll find out. === Guest74606 is now known as cr3 === cr3 is now known as Guest36779 [07:01] infinity: oh, I think it actually worked [07:01] it seems I need to ! three more packages which were in main in precise but went to universe in trusty [07:04] oh, that looks like bad NEWing [07:04] their original versions were in precise/universe, but the LTS backports went to precise/main === mwhudson is now known as zz_mwhudson [07:32] RAOF: oha, look what we've got: https://jenkins.qa.ubuntu.com/job/trusty-adt-fsharp/1/? [07:32] here's to uninstallability === Guest47791 is now known as Zic === Lutin_ is now known as Lutin === Guest36779 is now known as cr3 === cr3 is now known as Guest81216 [08:01] good morning [08:06] Good morning [08:15] Hello, world! [08:20] hey mlankhorst, good morning [08:29] mlankhorst: so which package in precise sets up that protocol-precise.txt diversion? [08:29] the lts-* packages [08:30] I mean, a particular one? xorg-common or something? [08:30] I guess the preinst for the dummy lts packages need to remove the diversions [08:30] xserver-common [08:30] right, xo xserver-common-lts-{q,r,s}? [08:30] s/xo/so/ [08:30] yeah so I'll make the dummy package remove it. I'm still interested in whether opengl will work afterwards though [08:31] mlankhorst: would a glxinfo be enough? [08:31] (even though it's just using the dummy driver, i. e. software rendering?) [08:31] mlankhorst: i. e. glxinfo | grep [08:31] ldd glxinfo would be enough [08:32] and ensure that it doesn't contain "not found"? [08:32] mlankhorst: btw, we do ensure that lightdm and X start up after the upgrade already [08:33] yeah I guess if glxinfo runs that's fine [08:33] exit code should b e0 [08:33] and maybe dump the glxinfo.txt for future inspection [08:33] *nod* [08:42] mlankhorst: ah bummer, mesa-utils is in universe; so we can't test it on the "main only" upgrade tests (i. e. most of them) [08:44] as long as it happens at some point :-) [08:45] or stuff it in a ppa [08:45] do we have anything in main which tests that? [08:45] erm probably [08:46] the unity-check-if-i-am-ok-something thingy? [08:46] yeah that would be a good way to test opengl [08:47] /usr/lib/gnome-session/gnome-session-check-accelerated-helper maybe? [08:47] there's something similar for unity, if only I could remember its name [08:48] pitti: yeah can't find if it still exists [08:48] the thing that creates /tmp/unity_support_test.0 [08:48] /usr/lib/nux/unity_support_test [08:48] ah right :p [08:48] but I think gnome-session uses that check anyway [08:49] oh and please unset LIBGL_ALWAYS_SOFTWARE LIBGL_ALWAYS_INDIRECT before testing [08:50] hm I guess we are in software mode, just unset LIBGL_ALWAYS_INDIRECT [08:50] $ DISPLAY=:0 /usr/lib/nux/unity_support_test -p [08:50] No protocol specified [08:50] Error: unable to open display [08:50] hmm [08:50] that's with the dummy driver [08:50] shrug [08:50] making sure something find sthe correct libgl is enough I guess [08:50] well, I'll keep that in mind, I'm currently looking at other bugs [08:52] so ldd someGLthing should return /usr/libs/*/mesa/libGL.so.1 === Guest81216 is now known as cr3 === cr3 is now known as Guest47825 === lan3y is now known as Laney === Laney is now known as Guest89008 === Guest89008 is now known as Laney === zz_mwhudson is now known as mwhudson [09:15] hi, my first patch pilot day. could some co-pilot with me a bit, and suggest what's the best way to go forward when I can't upload myself? I tested bug #907640 now and I think it would be ready for an upload. [09:15] bug 907640 in unity-2d (Ubuntu Precise) "alt-backtick doesn't work properly" [Medium,Triaged] https://launchpad.net/bugs/907640 [09:41] can somebody britney override the libreoffice autopkgtest failure? [09:42] seb128: Looking. [09:43] infinity, thanks [09:44] seb128: Done. [09:45] infinity, thanks [09:47] * infinity decides to get some sleep. [09:48] night! [09:53] RAOF: reviewed === MacSlow_ is now known as MacSlow === Guest47825 is now known as cr3 === cr3 is now known as Guest4601 [09:59] tkamppeter_: Hi. It'd be nice to have a new release of cups-filters with the upstart fix so that we could fix the PATH_MAX issue. [09:59] mlankhorst: are you working on the diversion cleanup, or shall I look into that? [10:02] pitti: sure I'll do it [10:03] dpkg-divert --remove --package xserver-common-lts-raring --rename --divert /usr/lib/xorg/protocol-precise.txt /usr/lib/xorg/protocol.txt [10:04] mlankhorst: so something like ^ in the postinst should do [10:04] mlankhorst: preinst is too early I think, as at that point the diverted protocol.txt still exists [10:04] i. e. the precise lts-raring package is still installed [10:05] yeah [10:05] slangasek: Can you please remove force-badtest dh-python/1.20131021-1ubuntu2 from your hints? It has been fixed with my last merge. === highvolt1ge is now known as highvoltage === mwhudson is now known as zz_mwhudson === mirco is now known as MacSlow [10:30] pitti: http://paste.debian.net/81836/ seems to work [10:31] oops :P [10:31] nm i need to fix that [10:31] mlankhorst: lt-nl for robustness? [10:31] yeah [10:31] mlankhorst: sh -e is redundant with set -e [10:32] mlankhorst: why the postrm? [10:32] yeah that's the bug [10:32] and please add a bug ref (LP: #1279424) [10:32] Launchpad bug 1279424 in xorg-lts-transitional (Ubuntu) "Needs to clean up /usr/lib/xorg/protocol-precise.txt" [Undecided,Triaged] https://launchpad.net/bugs/1279424 [10:35] hm seems to break :P === tkamppeter_ is now known as tkamppeter [10:37] Mirv: hi! I'm looking at bug 1264674 for teward (to avoid any duplicate work). [10:37] bug 1264674 in nginx (Ubuntu Saucy) "[SRU] nginx segfault when adding add_header in configuration" [Undecided,Triaged] https://launchpad.net/bugs/1264674 [10:37] Mirv: to answer your question: I usually wait for another pilot to appear, then jump in :) [10:39] pitti: No such clever trick; the best I can offer is that maybe you can express it more briefly as a regex seed [10:39] cjwatson: hey [10:39] cjwatson: it's actually all good now, % and ! work fine [10:39] (You may have got there already, I'm buried in scrollback) [10:39] rbasak_: thanks, I had that tab open but I found myself more likely to be able to review xubuntu-docs next, on my first patch pilot turn :) [10:40] pitti: Hmm, ! is a scarily big hammer, I don't promise that that won't result in weirdness in the future [10:40] But OK, I guess we can leave well alone for now ... [10:41] cjwatson: well, both that seed and the entire xorg-lts-transitional package will be killed at the first day of opening u [10:41] cjwatson: yeah, if it causes trouble I'm fine with expanding it all out, it'll just be ginormous [10:43] * cjwatson nods [10:43] OdyX, I am adding features for on-demand starting of cups-browsed (for mobile), after that, today or tomorrow, I will release 1.0.45 which contains the PATH_MAX fix. [10:44] OdyX, what do you mean with the "upstart fix"? === rbasak_ is now known as rbasak [10:47] pitti: hm even more fun is if xserver-common-* is installed previously and you upgraded to a different one, then try to install the old xserver-common-lts* after transitioning [10:47] still finds the old version :P [10:48] the old version of what? [10:48] (and yes, downgrades in these scenarios are very likely to blow up) [10:49] tkamppeter: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups-filters.git;a=commitdiff;h=54a2ef368311a1f56e0b6cc17d52c8244ceb8cb7 <- that should be in upstream; you requested that I'd include that in the debian packaging. [10:49] if i install xserver-common-lts-raring before upgrading to xserver-common-lts-saucy, and then switch to lts-saucy and install xserver-common-lts-raring after 'upgrading' to trusty [10:49] bleh I'll skip the version check and query dpkg-divert directly [10:56] pkg=$(dpkg-divert --listpackage /usr/lib/xorg/protocol.txt) [10:56] if [ -n "${pkg}" ]; then [10:56] dpkg-divert --remove --package ${pkg} --rename \ [10:56] --divert /usr/lib/xorg/protocol-precise.txt \ [10:56] /usr/lib/xorg/protocol.txt [10:56] fi === Guest4601 is now known as cr3 === cr3 is now known as Guest47646 [10:59] pitti: http://mblankhorst.nl/etc/xorg-lts-transitional_4.tar.gz -- done [11:01] mlankhorst: ah, thanks! but shouldn't that still be wrapped in [ "$1" = "configure" ] ? === ikonia_ is now known as ikonia [11:03] jdstrand: would the security team object to this patch being in pinentry? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=0b3a8568e14b994a8d1f4c1cb42aed4959dfc811 [11:07] pitti: naw [11:07] doesn't realy matter [11:07] mlankhorst: ah, I guess so; in postinst there's no way back anyway [11:07] mlankhorst: thanks! uploaded === Lutin is now known as Guest25707 [11:47] I'd have two patch pilot uploads ready for someone who has upload rights https://code.launchpad.net/~timo-jyrinki/metacity/ubuntu_fix_lp907640/+merge/206124 + https://code.launchpad.net/~timo-jyrinki/ubuntu/trusty/xubuntu-docs/14.04.0/+merge/206156 [11:50] dholbach: ^ if you (or anyone else) has time. [11:50] also, any tips on how to handle patch piloting better welcome for the newbie [11:55] barry: ^ or you, a co-pilot according to calendar, if you'd have time to help regardless of whether you're doing your turn otherwise today or not :) === Guest47646 is now known as cr3 === cr3 is now known as Guest30002 [12:05] Mirv, I need to rush out for a bit now - let me know if they're still unresolved when I get back [12:07] sure [12:10] hum [12:11] update_excuses still has [12:11] libreoffice (1:4.2.0~rc4-0ubuntu1 to 1:4.2.0-0ubuntu1) [12:11] autopkgtest for libreoffice 1:4.2.0-0ubuntu1: FAIL (Jenkins: public, private) [12:11] Not considered [12:11] infinity, your override didn't work I guess? (and you are probably sleeping now) [12:11] [12:11] could anyone hint over that issue? [12:12] the version needs updating [12:12] * Laney does it [12:12] Laney, thanks [12:12] why don't we delete this test? [12:12] Sweetshark, is the issue with those tests in libreoffice/the tests or in the setup running those? [12:13] Laney, ^ [12:13] Laney, my understanding was that the tests are ok but they keep eating setup limits on disk space and such [12:14] it seems they time out on copying [12:14] jibel bumped that timeout but not enough it seems [12:15] I still don't understand why a filesystem copy needs a timeout at all [12:16] mlankhorst: I can reproduce the xorg-server/ppc64el build failure, if you need to test a fix === zequence_ is now known as zequence [12:18] for (j = i; j < (kdNumInputFds - 1); j++) [12:18] kdInputFds[j] = kdInputFds[j + 1]; [12:19] for (i = 0; i < kdNumInputFds; i++) { [12:20] kdInputFds[j < kdNumInputFds - 1] = kdInputFds[j <= kdNumInputFds - 1]; -- which seems correct to me:P [12:20] Maybe assert(kdNumInputFds <= KD_MAX_INPUT_FDS) would help? [12:21] Oh, it's probably only happening on ppc64el because ppc64el just switched to -O3 [12:21] So I bet you can reproduce this with -O3 on x86 [12:22] hm I don't see the error though :P [12:22] With -O3? [12:22] I mean from static analysis [12:23] I'm guessing it can't prove that kdNumInputFds is within bounds? [12:23] That's why I'm suggesting an assert === doko_ is now known as doko [12:23] I'm guessing though [12:24] yeah but that should already break on the initial check then [12:24] Which initial check? [12:25] Oh ISWYM [12:25] Oh, but kdNumInputFds is decremented just above the j loop [12:26] ... but that should make it even more sure to be in bounds [12:27] Confusing because http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/36021 was supposed to fix this but we have that [12:28] I dunno, I definitely suggest trying with -O3 on x86 to see if that shows it as well === MacSlow is now known as MacSlow|lunch [12:35] doko, around [12:35] ? [12:37] cjwatson: yeah :/ [12:43] cjwatson: seems like a compiler error though? O3 on x86 works [12:46] Riddell: I'm not sure about prior art-- let me ask mdeslaur [12:47] mdeslaur: Riddell asked if we would object to http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=0b3a8568e14b994a8d1f4c1cb42aed4959dfc811 [12:47] * mdeslaur looks [12:48] mdeslaur: this seems like what the gtk pinentry already does based on the description alone [12:48] jdstrand, Riddell: I wouldn't object at all...the user is choosing to paste a password [12:49] mlankhorst: :( https://jenkins.qa.ubuntu.com/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/15/artifact/results/bootstrap.log [12:49] mlankhorst: at the very bottom === _salem is now known as salem_ [12:50] mlankhorst: it does get upgraded after xserver-common [12:52] mlankhorst: I don't know then, sorry [12:52] mdeslaur: cool, thanks. seemed like what we have in the gtk version, but I've not looked at it before [12:52] mlankhorst: Do you need access to a porter box to experiment? [12:52] pitti: huh? weird? [12:53] cjwatson: is the same compiler used for x86 as ppc64el? [12:53] mlankhorst: The same base, but I think there are IBM patches applied conditionally for ppc64el. doko would know more [12:53] mlankhorst: well, the new xorg-common already installs a protocol.txt, maybe that somehow conflicts with that one? [12:54] pitti: it gets diverted to protocol-precise.txt [12:56] thanks mdeslaur, jdstrand === Guest30002 is now known as cr3 === cr3 is now known as Guest60091 [13:00] pitti: no, that's what dpkg-divert is for [13:01] besides, the package manager would complain if protocol.txt was overwritten, that's the whole point of the diversion. :P [13:01] Hmm... trying to overwrite '/var/lib/xkb/README.compiled', which is also in package xserver-common-lts-raring 2:1.13.3-0ubuntu6~precise3 [13:02] mlankhorst: right, I just got the same [13:02] pitti: why did you add --force then? [13:02] mlankhorst: update-manager does that [13:02] ok, well that's a bug at least [13:02] and it tries several times [13:03] well, we've got a lot of these, so I guess that's update-manager's way to get you out of the swap instead of giving up [13:03] mlankhorst, yes, same compiler [13:03] xserver-common should have a replaces on xserver-common-lts-* [13:03] or Conflicts, more likely [13:03] mlankhorst: Breaks:/Replaces: on (<< 3), yes [13:04] err, << 3: [13:04] nah Conflicts is enough, I think [13:04] no, please not [13:04] ok [13:04] that'll only make apt hold back packages [13:04] Breaks:/Replaces: is the standard declaration for replacing files [13:05] Indeed, Conflicts is wrong and policy explicitly advises against it for moving files between packages [13:06] (with a rationale) [13:06] well I guess it can only be done 1 way here, original lts-stack had conflicts/replaces/provides because you had to switch both ways [13:08] Mirv, I uploaded xubuntu-docs - maybe somebody from the desktop team can upload metacity? [13:08] conflicts/replaces/provides has different semantics, that's for whole packages [13:12] pitti: I give up and I'll add it as postinst job for xserver-common as well. :P [13:12] should work with breaks/replaces [13:12] it doesn't get configured until the broken xserver-commons are gone [13:12] mlankhorst: why would xserver-common need to clean up the -lts-* diversion? [13:13] I don't see why the current way would break, unless the --force broke stuff [13:15] dholbach: thanks! [13:23] didrocks: ^ I see you've done a metacity upload as recently as two years ago, I wonder if you could upload https://code.launchpad.net/~timo-jyrinki/metacity/ubuntu_fix_lp907640/+merge/206124 [13:24] I can also just mark it as 'ready for upload' in my report [13:24] Mirv: you did test the patch, you just need sponsoring? [13:24] didrocks: yes, tested in gnome fallback and seems to fix the issue without any regressions I could find [13:25] Mirv: ok, sponsoring then :) [13:25] thanks! :) [13:26] yay, I beat wine1.4 to build at last, after only 10 attempts [13:26] Mirv: yw (and done!) [13:31] bah, ABI incompatible untested libssh upload [13:35] Riddell, http://launchpadlibrarian.net/166034580/libssh_0.6.1-0ubuntu1_0.6.1-0ubuntu2.diff.gz is this the right thing to do, and not changing the soname/package name? [13:36] doko: is was never compiled with gssapi so those symbols were next in the package, I just happaned to have gssapi installed on my local system when I updated the package === MacSlow|lunch is now known as MacSlow [13:40] Riddell, ahh, thanks for the explanation [13:41] s/next/never/ === timrc-afk is now known as timrc === Guest60091 is now known as cr3 === cr3 is now known as Guest33354 === freeflying is now known as freeflying_away [14:05] mlankhorst: have enough people bothered you about xorg ppc64el build blocking mir ? :) if so...i'll leave you alone [14:08] Bump on https://bugs.launchpad.net/bugs/1060543 attached an example file a while ago. [14:08] Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress] [14:11] Mirv: i'll try, but i am also working on some critical bugs today :( [14:12] barry: thanks, but I now already got d_holbach for the xubuntu-docs and d_idrocks for the metacity [14:12] Mirv: excellent. === Guest33354 is now known as cr3 [14:28] mlankhorst: I think it might be worth just appending -O2 to CFLAGS if you can't track down the root cause of this quickly [14:36] cjwatson: yeah I'll just try this fix, lets see if it works [14:37] mlankhorst, please open an issue in any case, for 4.8 and the package in question [14:43] hum [14:43] xorg builds failed with libmirclient-dev : Depends: libmirclient7 (= 0.1.5+14.04.20140212-0ubuntu1) but it is not installable [14:44] I guess the binaries got copied to universe? [14:44] * seb128 promotes [14:45] same for libmirserver15 [14:45] mlankhorst, ^ [14:46] should I retry? :P [14:46] need to be retried once the promotion is reflected on the archive [14:46] no, check with rmadison to see when they are promoted [14:46] I guess next publish run, so ~45 min [14:47] That would be pretty near the worst case [14:48] Though you did *just* miss the start of a publisher run so I suppose that's possible [14:48] yeah, I don't know the publisher run times nowadays, I sticked to "run every half an hour and take less than half an hour" [14:49] It tries to run every five minutes and typically takes either ~5min or ~20min depending on whether it needs to publish the devel release pocket or not [14:49] nice ;-) [14:49] With occasional spikes when it needs to publish something enormous like libreoffice [14:50] (Since the writes to the pool are still in-band) [14:50] cjwatson, mlankhorst: on the good news, ppc64el built [14:50] https://launchpad.net/ubuntu/trusty/+source/xorg-server/2:1.15.0-1ubuntu6 [14:51] cool [15:04] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:04] almost forgot [15:26] infinity: Any problems with the libv8 stuff when you built all platforms? (including PPC) [15:27] seb128: in addition to apturl not working, flash install seems to be broken too? [15:28] shadeslayer, I've no idea about that, ask chrisccoulson maybe [15:29] chrisccoulson: ^^ [15:29] seb128: any news on the apturl front? [15:30] shadeslayer, chrisccoulson doesn't like using the other directory, he said that's wrong and that we should fix firefox mimetype handling instead [15:30] yeah, it needs somebody to fix the external protocol handling in firefox [15:30] I've the feeling nobody is going to have slots for that though [15:30] *nod* I saw that part [15:30] so I might end up abusing the wrong dir [15:30] then start hiding from chrisccoulson :p [15:30] ^^ [15:31] I'd have taken a shot at it, but I have no clue how the external plugin thing works [15:31] mlankhorst: looks like libgcrypt20 is going to need to go to main for xorg-server, which will involve duplication because a bunch of stuff currently uses libgcrypt11; are you looking at upgrading other things to match? [15:32] mlankhorst: and/or whether this all syncs with Debian I guess [15:32] cjwatson, is it? [15:32] i know how it works, but my available time is < 0 at the moment ;) [15:32] is it what? [15:32] cjwatson, the manual upload should pick back 11 [15:32] huh, really? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt thinks it's 20 [15:32] cjwatson, the CI builds pick happily in universe [15:32] so I guess the copied version picked 20 [15:32] and the manual upload is going to go back at resolving the main provides [15:32] which is 11 [15:33] we had the issue last week already :/ [15:33] oh, maybe it's just lagged because some arches were blocked on libmirclient or whatever [15:33] btw builds can me retried it seem [15:33] s [15:33] 2:1.15.0-1ubuntu5_i386 has libgcrypt20 [15:33] right [15:34] 5 is the pocket copied version? [15:34] chrisccoulson: what are the chances that it'll be fixed post Feature Freeze [15:34] er dunno, check the publishinghistory [15:34] $ dpkg -I xserver-xorg-core_1.15.0-1ubuntu6_i386.deb | grep libgcry [15:34] ... [15:34] libgcrypt11 (>= 1.5.1), [15:34] shadeslayer, by me, slim. but maybe somebody will step up who knows how the code works. or maybe upstream will fix it [15:34] mhmm [15:35] right, ubuntu5 was copied from CI [15:35] cjwatson, so yeah, xorg Build-Depends on libgcrypt-dev [15:35] yeah, the CI builds get the universe provider [15:35] and 11 and 20 provides that [15:35] and the CI has universe enabled and that leads to pick the wrong one [15:35] if it matters somebody should fix the B-D then [15:35] archive upload pick the only available one in main and end up on 11 [15:35] right [15:35] mlankhorst, ^ [15:35] * shadeslayer goes back to figuring how to make plugin installation work for Kubuntu [15:35] I guess it only matters as far as components ... [15:36] If a Unix program handles SIGINT and exits, should it return a code of just non-zero (eg. 1), or SIGINT + 2^7? [15:36] (so that WIFSIGNALED etc work) [15:36] chrisccoulson, what's the side effect off installing the apturl config where you don't want it to be? [15:38] seb128, it only fixes apturl. it's broken for all external protocols [15:38] and hardcoding apt: URI's to apturl is wrong anyway [15:38] the default handler is software-centre [15:39] chrisccoulson, do you have an example of other external protocols? clicking on an email: seems to work? [15:40] it's likely that's stored somewhere in your profile from a previous use [15:40] i've been told itms: and mms: are broken [15:41] and all the weird protocols that totem is meant to handle too [15:42] mitya57: dh-python hint dropped, thanks [15:43] Thanks! === roaksoax_ is now known as roaksoax === rickspencer3_ is now known as rickspencer3 [15:49] pitti: hey can you recheck with after the latest xorg-server goes into -proposed? [15:52] cjwatson: ok, that wasn't too bad... I cut out the fs create/check/copy commands from parted_server, linked it against the new libparted, removed the copy operation from the menu, fixed swap formatting to always use mkswap isntead of only as a fallback if parted_server fails... what's the next step? file bugs with patches to the partman components? get parted3 uploaded to experimental? [15:53] file bugs with patches in Debian, and let's see how it looks [15:53] ok [15:54] testing it though will require parted3, so should that be in experimental? [15:54] honestly I'd rather get the patches into partman and then put parted 3 in unstable [15:55] the partman patches should surely still work against parted 2 [15:55] the one snag with that is that I had to change the linker flags for parted_server and that won't be backwards compatible with the current libparted [15:55] well, let's see the patches for that [15:56] BenC: yesterday you mentioned using schroot's - I've been reading up on this as I haven't used them before. Two things. If I do schroot, I end up in an environment without 'git'. However, my real question is: can I do 'development' in a non schroot environment? (provided I don't need to install packages) [15:56] ok... it was pretty simple... just had to add a -lparted-fs-resize.. and that apparently required -luuid === jono is now known as Guest53088 [15:57] why isn't that done with pkg-config? [15:57] and we could conditionalise that I'm sure [15:57] there doesn't seem to be a .pc file for the fs resize library [15:58] I mean, I get that we'd need to reupload partman-base against parted 3 eventually [15:58] but I wasn't talking about that bit - I was talking about landing the removal of fs-creation-dependent code first [15:58] yea... you could do that... just the linker flag would need switched [15:58] sure, that's easily done later :) [15:59] yea [15:59] I didn't test hfs, but fat resize seemed to work fine [15:59] but let's start landing what we can do noninvasively now; it always helps to prune down the problem [16:15] hey stgraber what are the limits to the number of LXC containers that can reliably operate on a single host? [16:16] chiluk: depends on the host, 700-800 system containers (running wordpress as that's apparently the usual test) seem to be the usual limit for a reasonably powerful server these days [16:17] chiluk: well, with our default config, that'd be 254 because we only have a /24 for the default network, but that can be changed :) [16:18] stgraber, thanks. === Guest38617 is now known as Claudinux === Claudinux is now known as Guest43087 === Guest43087 is now known as Claudinux_ [16:48] alow: If you don't need packages installed, you're good. If you do an schroot, though, you can ask me to install git in it :) [16:58] BenC: What's your preference. It doesn't look like I need any packages. [16:59] alow: It's functionally no different. The schroot just provides us a way of installing packages specific to each user [16:59] BenC: k - got it. [17:01] cjwatson, mlankhorst: good, mir migrated [17:02] excellent [17:02] kgunn: ^- [17:02] cjwatson: thanks guys [17:13] alow: Nope, all looked good, and for bonus points, it does work on POWER5 as well. [17:13] huzzah [17:14] infinity: Great. I'm about to head off on vacation, nice to know it's sorted out [17:14] alow: Ahh, and got your response to my followup. Lovely. I'll bounce that to the archive right now, then. [17:15] alow: And guessing from backscroll that BenC's give you shell on an e500 machine that doesn't suck? [17:18] infinity: Indeed [17:18] BenC: Awesome, thanks. [17:18] BenC: Can I talk you into an SRU kernel rebase while you're being helpful? :) [17:19] infinity: Sure, why not. [17:19] * BenC needs first coffee though [17:19] BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1276013 [17:19] Launchpad bug 1276013 in Kernel SRU Workflow "linux-ppc: -proposed tracker" [Medium,In progress] [17:24] infinity: How long to EOL on saucy kernel? [17:25] 13.10 + 9mo. So, 13.19! [17:25]