[05:27] <pitti> Good morning
[05:33] <RAOF> pitti: Yo yo!
[05:34] <RAOF> pitti: Hey, what does error() do in vala?
[05:34] <pitti> RAOF: that's g_error() in C (from glib), i. e. print that message to stderr and abort()
[05:35] <RAOF> Ah, right. Yeah, that's what I though.
[05:35] <RAOF> Ok, valac just fails at code flow analysis.
[05:35] <pitti> 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] <pitti> heh, it might not consider error() as a definitive "ends here"
[05:35] <infinity> "proper".
[05:36] <RAOF> Indeed it does not consider error() to abort the function.
[05:36] <pitti> RAOF: I'm not sure whether you can make error() not abort, but I don't think you can
[05:36] <pitti> RAOF: warning() and critical() can abort() if one wants, but don't by default
[05:36] <RAOF> Anyway, initialising the string to "" silences the “You might use this unassigned!” error.
[05:37] <pitti> that's just a warning, no?
[05:37] <pitti> (but fixing warnings is appreciated)
[05:42] <RAOF> It's apparently a fatal error.
[05:42] <RAOF> Oh, and it's not control-flow failure! It's failure to understand scanf("%ms", &str)
[05:47] <RAOF> pitti: Enjoy your new pull request.
[05:52] <Mirv> @pilot in
[05:52] <Mirv> \o/
[06:06] <pitti> RAOF: hah, thanks
[06:41] <pitti> 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] <pitti> 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] <pitti> 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] <infinity> 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] <pitti> infinity: *nod*
[06:46] <infinity> 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] <pitti> cjwatson: ah no, desktop-common gets installed; perhaps supported-hardware-desktop?
[06:46] <infinity> pitti: supported-hardware-desktop sounds sane.
[06:47] <pitti> 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] <infinity> pitti: Or just supported, where I already have a 'Transitional packages:' section.
[06:47] <pitti> 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] <pitti> infinity: ah, even better
[06:47] <pitti> infinity: that's not in platform.trusty then, but in ubuntu.trusty?
[06:47] <infinity> That section is likely incomplete, I only add things when I notice the oops.
[06:47] <infinity> pitti: ubuntu.trusty, yeah.
[06:50] <pitti> infinity: ok, committed; I'll check c-m in a bit
[06:50] <pitti> thanks
[06:50] <infinity> pitti: I suspect that won't work, but I guess you'll find out.
[07:01] <pitti> infinity: oh, I think it actually worked
[07:01] <pitti> it seems I need to ! three more packages which were in main in precise but went to universe in trusty
[07:04] <pitti> oh, that looks like bad NEWing
[07:04] <pitti> their original versions were in precise/universe, but the LTS backports went to precise/main
[07:32] <pitti> RAOF: oha, look what we've got: https://jenkins.qa.ubuntu.com/job/trusty-adt-fsharp/1/?
[07:32] <pitti> here's to uninstallability
[08:01] <dholbach> good morning
[08:06] <spineau> Good morning
[08:15] <mlankhorst> Hello, world!
[08:20] <pitti> hey mlankhorst, good morning
[08:29] <pitti> mlankhorst: so which package in precise sets up that protocol-precise.txt diversion?
[08:29] <mlankhorst> the lts-* packages
[08:30] <pitti> I mean, a particular one? xorg-common or something?
[08:30] <mlankhorst> I guess the preinst for the dummy lts packages need to remove the diversions
[08:30] <mlankhorst> xserver-common
[08:30] <pitti> right, xo xserver-common-lts-{q,r,s}?
[08:30] <pitti> s/xo/so/
[08:30] <mlankhorst> yeah so I'll make the dummy package remove it. I'm still interested in whether opengl will work afterwards though
[08:31] <pitti> mlankhorst: would a glxinfo be enough?
[08:31] <pitti> (even though it's just using the dummy driver, i. e. software rendering?)
[08:31] <pitti> mlankhorst: i. e. glxinfo | grep <somethign you expect>
[08:31] <mlankhorst> ldd glxinfo would be enough
[08:32] <pitti> and ensure that it doesn't contain "not found"?
[08:32] <pitti> mlankhorst: btw, we do ensure that lightdm and X start up after the upgrade already
[08:33] <mlankhorst> yeah I guess if glxinfo runs that's fine
[08:33] <mlankhorst> exit code should b e0
[08:33] <mlankhorst> and maybe dump the glxinfo.txt for future inspection
[08:33] <pitti> *nod*
[08:42] <pitti> 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] <mlankhorst> as long as it happens at some point :-)
[08:45] <mlankhorst> or stuff it in a ppa
[08:45] <pitti> do we have anything in main which tests that?
[08:45] <mlankhorst> erm probably
[08:46] <pitti> the unity-check-if-i-am-ok-something thingy?
[08:46] <mlankhorst> yeah that would be a good way to test opengl
[08:47] <mlankhorst>  /usr/lib/gnome-session/gnome-session-check-accelerated-helper maybe?
[08:47] <pitti> there's something similar for unity, if only I could remember its name
[08:48] <mlankhorst> pitti: yeah can't find if it still exists
[08:48] <pitti> the thing that creates /tmp/unity_support_test.0
[08:48] <pitti> /usr/lib/nux/unity_support_test
[08:48] <mlankhorst> ah right :p
[08:48] <mlankhorst> but I think gnome-session uses that check anyway
[08:49] <mlankhorst> oh and please unset LIBGL_ALWAYS_SOFTWARE LIBGL_ALWAYS_INDIRECT before testing
[08:50] <mlankhorst> hm I guess we are in software mode, just unset LIBGL_ALWAYS_INDIRECT
[08:50] <pitti> $ DISPLAY=:0 /usr/lib/nux/unity_support_test -p
[08:50] <pitti> No protocol specified
[08:50] <pitti> Error: unable to open display
[08:50] <pitti> hmm
[08:50] <pitti> that's with the dummy driver
[08:50] <mlankhorst> shrug
[08:50] <mlankhorst> making sure something find sthe correct libgl is enough I guess
[08:50] <pitti> well, I'll keep that in mind, I'm currently looking at other bugs
[08:52] <mlankhorst> so ldd someGLthing should return /usr/libs/*/mesa/libGL.so.1
[09:15] <Mirv> 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:41] <seb128> can somebody britney override the libreoffice autopkgtest failure?
[09:42] <infinity> seb128: Looking.
[09:43] <seb128> infinity, thanks
[09:44] <infinity> seb128: Done.
[09:45] <seb128> infinity, thanks
[09:47]  * infinity decides to get some sleep.
[09:48] <seb128> night!
[09:53] <pitti> RAOF: reviewed
[09:59] <OdyX> 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] <pitti> mlankhorst: are you working on the diversion cleanup, or shall I look into that?
[10:02] <mlankhorst> pitti: sure I'll do it
[10:03] <pitti> dpkg-divert --remove --package xserver-common-lts-raring --rename --divert /usr/lib/xorg/protocol-precise.txt /usr/lib/xorg/protocol.txt
[10:04] <pitti> mlankhorst: so something like ^ in the postinst should do
[10:04] <pitti> mlankhorst: preinst is too early I think, as at that point the diverted protocol.txt still exists
[10:04] <pitti> i. e. the precise lts-raring package is still installed
[10:05] <mlankhorst> yeah
[10:05] <mitya57> slangasek: Can you please remove force-badtest dh-python/1.20131021-1ubuntu2 from your hints? It has been fixed with my last merge.
[10:30] <mlankhorst> pitti: http://paste.debian.net/81836/ seems to work
[10:31] <mlankhorst> oops :P
[10:31] <mlankhorst> nm i need to fix that
[10:31] <pitti> mlankhorst: lt-nl for robustness?
[10:31] <mlankhorst> yeah
[10:31] <pitti> mlankhorst: sh -e is redundant with set -e
[10:32] <pitti> mlankhorst: why the postrm?
[10:32] <mlankhorst> yeah that's the bug
[10:32] <pitti> and please add a bug ref (LP: #1279424)
[10:35] <mlankhorst> hm seems to break :P
[10:37] <rbasak_> Mirv: hi! I'm looking at bug 1264674 for teward (to avoid any duplicate work).
[10:37] <rbasak_> Mirv: to answer your question: I usually wait for another pilot to appear, then jump in :)
[10:39] <cjwatson> 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] <pitti> cjwatson: hey
[10:39] <pitti> cjwatson: it's actually all good now, % and ! work fine
[10:39] <cjwatson> (You may have got there already, I'm buried in scrollback)
[10:39] <Mirv> 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] <cjwatson> pitti: Hmm, ! is a scarily big hammer, I don't promise that that won't result in weirdness in the future
[10:40] <cjwatson> But OK, I guess we can leave well alone for now ...
[10:41] <pitti> cjwatson: well, both that seed and the entire xorg-lts-transitional package will be killed at the first day of opening u
[10:41] <pitti> 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] <tkamppeter> 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] <tkamppeter> OdyX, what do you mean with the "upstart fix"?
[10:47] <mlankhorst> 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] <mlankhorst> still finds the old version :P
[10:48] <pitti> the old version of what?
[10:48] <pitti> (and yes, downgrades in these scenarios are very likely to blow up)
[10:49] <OdyX> 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] <mlankhorst> 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] <mlankhorst> bleh I'll skip the version check and query dpkg-divert directly
[10:56] <mlankhorst> pkg=$(dpkg-divert --listpackage /usr/lib/xorg/protocol.txt)
[10:56] <mlankhorst> if [ -n "${pkg}" ]; then
[10:56] <mlankhorst>     dpkg-divert --remove --package ${pkg} --rename \
[10:56] <mlankhorst>         --divert /usr/lib/xorg/protocol-precise.txt \
[10:56] <mlankhorst>         /usr/lib/xorg/protocol.txt
[10:56] <mlankhorst> fi
[10:59] <mlankhorst> pitti: http://mblankhorst.nl/etc/xorg-lts-transitional_4.tar.gz -- done
[11:01] <pitti> mlankhorst: ah, thanks! but shouldn't that still be wrapped in [ "$1" = "configure" ] ?
[11:03] <Riddell> 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] <mlankhorst> pitti: naw
[11:07] <mlankhorst> doesn't realy matter
[11:07] <pitti> mlankhorst: ah, I guess so; in postinst there's no way back anyway
[11:07] <pitti> mlankhorst: thanks! uploaded
[11:47] <Mirv> 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] <Mirv> dholbach: ^ if you (or anyone else) has time.
[11:50] <Mirv> also, any tips on how to handle patch piloting better welcome for the newbie
[11:55] <Mirv> 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 :)
[12:05] <dholbach> Mirv, I need to rush out for a bit now - let me know if they're still unresolved when I get back
[12:07] <Mirv> sure
[12:10] <seb128> hum
[12:11] <seb128> update_excuses still has
[12:11] <seb128> libreoffice (1:4.2.0~rc4-0ubuntu1 to 1:4.2.0-0ubuntu1)
[12:11] <seb128> autopkgtest for libreoffice 1:4.2.0-0ubuntu1: FAIL (Jenkins: public, private)
[12:11] <seb128> Not considered
[12:11] <seb128> infinity, your override didn't work I guess? (and you are probably sleeping now)
[12:11] <seb128>  
[12:11] <seb128> could anyone hint over that issue?
[12:12] <Laney> the version needs updating
[12:12]  * Laney does it
[12:12] <seb128> Laney, thanks
[12:12] <Laney> why don't we delete this test?
[12:12] <seb128> Sweetshark, is the issue with those tests in libreoffice/the tests or in the setup running those?
[12:13] <seb128> Laney, ^
[12:13] <seb128> Laney, my understanding was that the tests are ok but they keep eating setup limits on disk space and such
[12:14] <pitti> it seems they time out on copying
[12:14] <seb128> jibel bumped that timeout but not enough it seems
[12:15] <cjwatson> I still don't understand why a filesystem copy needs a timeout at all
[12:16] <cjwatson> mlankhorst: I can reproduce the xorg-server/ppc64el build failure, if you need to test a fix
[12:18] <mlankhorst>             for (j = i; j < (kdNumInputFds - 1); j++)
[12:18] <mlankhorst>                 kdInputFds[j] = kdInputFds[j + 1];
[12:19] <mlankhorst>     for (i = 0; i < kdNumInputFds; i++) {
[12:20] <mlankhorst> kdInputFds[j < kdNumInputFds - 1] = kdInputFds[j <= kdNumInputFds - 1]; -- which seems correct to me:P
[12:20] <cjwatson> Maybe assert(kdNumInputFds <= KD_MAX_INPUT_FDS) would help?
[12:21] <cjwatson> Oh, it's probably only happening on ppc64el because ppc64el just switched to -O3
[12:21] <cjwatson> So I bet you can reproduce this with -O3 on x86
[12:22] <mlankhorst> hm I don't see the error though :P
[12:22] <cjwatson> With -O3?
[12:22] <mlankhorst> I mean from static analysis
[12:23] <cjwatson> I'm guessing it can't prove that kdNumInputFds is within bounds?
[12:23] <cjwatson> That's why I'm suggesting an assert
[12:23] <cjwatson> I'm guessing though
[12:24] <mlankhorst> yeah but that should already break on the initial check then
[12:24] <cjwatson> Which initial check?
[12:25] <cjwatson> Oh ISWYM
[12:25] <cjwatson> Oh, but kdNumInputFds is decremented just above the j loop
[12:26] <cjwatson> ... but that should make it even more sure to be in bounds
[12:27] <cjwatson> Confusing because http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/36021 was supposed to fix this but we have that
[12:28] <cjwatson> I dunno, I definitely suggest trying with -O3 on x86 to see if that shows it as well
[12:35] <tvoss> doko, around
[12:35] <tvoss> ?
[12:37] <mlankhorst> cjwatson: yeah :/
[12:43] <mlankhorst> cjwatson: seems like a compiler error though? O3 on x86 works
[12:46] <jdstrand> Riddell: I'm not sure about prior art-- let me ask mdeslaur
[12:47] <jdstrand> 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] <jdstrand> mdeslaur: this seems like what the gtk pinentry already does based on the description alone
[12:48] <mdeslaur> jdstrand, Riddell: I wouldn't object at all...the user is choosing to paste a password
[12:49] <pitti> mlankhorst: :( https://jenkins.qa.ubuntu.com/job/upgrade-ubuntu-precise-trusty-desktop-lts-raring-i386/15/artifact/results/bootstrap.log
[12:49] <pitti> mlankhorst: at the very bottom
[12:50] <pitti> mlankhorst: it does get upgraded after xserver-common
[12:52] <cjwatson> mlankhorst: I don't know then, sorry
[12:52] <jdstrand> mdeslaur: cool, thanks. seemed like what we have in the gtk version, but I've not looked at it before
[12:52] <cjwatson> mlankhorst: Do you need access to a porter box to experiment?
[12:52] <mlankhorst> pitti: huh? weird?
[12:53] <mlankhorst> cjwatson: is the same compiler used for x86 as ppc64el?
[12:53] <cjwatson> mlankhorst: The same base, but I think there are IBM patches applied conditionally for ppc64el.  doko would know more
[12:53] <pitti> mlankhorst: well, the new xorg-common already installs a protocol.txt, maybe that somehow conflicts with that one?
[12:54] <mlankhorst> pitti: it gets diverted to protocol-precise.txt
[12:56] <Riddell> thanks mdeslaur, jdstrand
[13:00] <mlankhorst> pitti: no, that's what dpkg-divert is for
[13:01] <mlankhorst> besides, the package manager would complain if protocol.txt was overwritten, that's the whole point of the  diversion. :P
[13:01] <mlankhorst> 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] <pitti> mlankhorst: right, I just got the same
[13:02] <mlankhorst> pitti: why did you add --force then?
[13:02] <pitti> mlankhorst: update-manager does that
[13:02] <mlankhorst> ok, well that's a bug at least
[13:02] <pitti> and it tries several times
[13:03] <pitti> 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] <doko> mlankhorst, yes, same compiler
[13:03] <mlankhorst> xserver-common should have a replaces on xserver-common-lts-*
[13:03] <mlankhorst> or Conflicts, more likely
[13:03] <pitti> mlankhorst: Breaks:/Replaces: on (<< 3), yes
[13:04] <pitti> err, << 3:
[13:04] <mlankhorst> nah Conflicts is enough, I think
[13:04] <pitti> no, please not
[13:04] <mlankhorst> ok
[13:04] <pitti> that'll only make apt hold back packages
[13:04] <pitti> Breaks:/Replaces: is the standard declaration for replacing files
[13:05] <cjwatson> Indeed, Conflicts is wrong and policy explicitly advises against it for moving files between packages
[13:06] <cjwatson> (with a rationale)
[13:06] <mlankhorst> 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] <dholbach> Mirv, I uploaded xubuntu-docs - maybe somebody from the desktop team can upload metacity?
[13:08] <cjwatson> conflicts/replaces/provides has different semantics, that's for whole packages
[13:12] <mlankhorst> pitti: I give up and I'll add it as postinst job for xserver-common as well. :P
[13:12] <mlankhorst> should work with breaks/replaces
[13:12] <mlankhorst> it doesn't get configured until the broken xserver-commons are gone
[13:12] <pitti> mlankhorst: why would xserver-common need to clean up the -lts-* diversion?
[13:13] <mlankhorst> I don't see why the current way would break, unless the --force broke stuff
[13:15] <Mirv> dholbach: thanks!
[13:23] <Mirv> 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] <Mirv> I can also just mark it as 'ready for upload' in my report
[13:24] <didrocks> Mirv: you did test the patch, you just need sponsoring?
[13:24] <Mirv> didrocks: yes, tested in gnome fallback and seems to fix the issue without any regressions I could find
[13:25] <didrocks> Mirv: ok, sponsoring then :)
[13:25] <Mirv> thanks! :)
[13:26] <pitti> yay, I beat wine1.4 to build at last, after only 10 attempts
[13:26] <didrocks> Mirv: yw (and done!)
[13:31] <doko> bah, ABI incompatible untested libssh upload
[13:35] <doko> 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] <Riddell> 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
[13:40] <doko> Riddell, ahh, thanks for the explanation
[13:41] <Riddell> s/next/never/
[14:05] <kgunn> mlankhorst: have enough people bothered  you about xorg ppc64el build blocking mir ? :) if so...i'll leave you alone
[14:08] <Unit193> Bump on https://bugs.launchpad.net/bugs/1060543 attached an example file a while ago.
[14:11] <barry> Mirv: i'll try, but i am also working on some critical bugs today :(
[14:12] <Mirv> barry: thanks, but I now already got d_holbach for the xubuntu-docs and d_idrocks for the metacity
[14:12] <barry> Mirv: excellent.
[14:28] <cjwatson> 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] <mlankhorst> cjwatson: yeah I'll just try this fix, lets see if it works
[14:37] <doko> mlankhorst, please open an issue in any case, for 4.8 and the package in question
[14:43] <seb128> hum
[14:43] <seb128> xorg builds failed with  libmirclient-dev : Depends: libmirclient7 (= 0.1.5+14.04.20140212-0ubuntu1) but it is not installable
[14:44] <seb128> I guess the binaries got copied to universe?
[14:44]  * seb128 promotes
[14:45] <seb128> same for libmirserver15
[14:45] <seb128> mlankhorst, ^
[14:46] <mlankhorst> should I retry? :P
[14:46] <seb128> need to be retried once the promotion is reflected on the archive
[14:46] <seb128> no, check with rmadison to see when they are promoted
[14:46] <seb128> I guess next publish run, so ~45 min
[14:47] <cjwatson> That would be pretty near the worst case
[14:48] <cjwatson> Though you did *just* miss the start of a publisher run so I suppose that's possible
[14:48] <seb128> 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] <cjwatson> 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] <seb128> nice ;-)
[14:49] <cjwatson> With occasional spikes when it needs to publish something enormous like libreoffice
[14:50] <cjwatson> (Since the writes to the pool are still in-band)
[14:50] <seb128> cjwatson, mlankhorst: on the good news, ppc64el built
[14:50] <seb128> https://launchpad.net/ubuntu/trusty/+source/xorg-server/2:1.15.0-1ubuntu6
[14:51] <cjwatson> cool
[15:04] <Mirv> @pilot out
[15:04] <Mirv> almost forgot
[15:26] <alow> infinity: Any problems with the libv8 stuff when you built all platforms? (including PPC)
[15:27] <shadeslayer> seb128: in addition to apturl not working, flash install seems to be broken too?
[15:28] <seb128> shadeslayer, I've no idea about that, ask chrisccoulson maybe
[15:29] <shadeslayer> chrisccoulson: ^^
[15:29] <shadeslayer> seb128: any news on the apturl front?
[15:30] <seb128> 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] <chrisccoulson> yeah, it needs somebody to fix the external protocol handling in firefox
[15:30] <seb128> I've the feeling nobody is going to have slots for that though
[15:30] <shadeslayer> *nod* I saw that part
[15:30] <seb128> so I might end up abusing the wrong dir
[15:30] <seb128> then start hiding from chrisccoulson :p
[15:30] <shadeslayer> ^^
[15:31] <shadeslayer> I'd have taken a shot at it, but I have no clue how the external plugin thing works
[15:31] <cjwatson> 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] <cjwatson> mlankhorst: and/or whether this all syncs with Debian I guess
[15:32] <seb128> cjwatson, is it?
[15:32] <chrisccoulson> i know how it works, but my available time is < 0 at the moment ;)
[15:32] <cjwatson> is it what?
[15:32] <seb128> cjwatson, the manual upload should pick back 11
[15:32] <cjwatson> huh, really?  http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt thinks it's 20
[15:32] <seb128> cjwatson, the CI builds pick happily in universe
[15:32] <seb128> so I guess the copied version picked 20
[15:32] <seb128> and the manual upload is going to go back at resolving the main provides
[15:32] <seb128> which is 11
[15:33] <seb128> we had the issue last week already :/
[15:33] <cjwatson> oh, maybe it's just lagged because some arches were blocked on libmirclient or whatever
[15:33] <seb128> btw builds can me retried it seem
[15:33] <seb128> s
[15:33] <cjwatson> 2:1.15.0-1ubuntu5_i386 has libgcrypt20
[15:33] <seb128> right
[15:34] <seb128> 5 is the pocket copied version?
[15:34] <shadeslayer> chrisccoulson: what are the chances that it'll be fixed post Feature Freeze
[15:34] <cjwatson> er dunno, check the publishinghistory
[15:34] <seb128> $ dpkg -I xserver-xorg-core_1.15.0-1ubuntu6_i386.deb | grep libgcry
[15:34] <seb128> ...
[15:34] <seb128>  libgcrypt11 (>= 1.5.1),
[15:34] <chrisccoulson> shadeslayer, by me, slim. but maybe somebody will step up who knows how the code works. or maybe upstream will fix it
[15:34] <shadeslayer> mhmm
[15:35] <cjwatson> right, ubuntu5 was copied from CI
[15:35] <seb128> cjwatson, so yeah, xorg Build-Depends on libgcrypt-dev
[15:35] <Laney> yeah, the CI builds get the universe provider
[15:35] <seb128> and 11 and 20 provides that
[15:35] <seb128> and the CI has universe enabled and that leads to pick the wrong one
[15:35] <cjwatson> if it matters somebody should fix the B-D then
[15:35] <seb128> archive upload pick the only available one in main and end up on 11
[15:35] <seb128> right
[15:35] <seb128> mlankhorst, ^
[15:35]  * shadeslayer goes back to figuring how to make plugin installation work for Kubuntu
[15:35] <Laney> I guess it only matters as far as components ...
[15:36] <rbasak> 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] <rbasak> (so that WIFSIGNALED etc work)
[15:36] <seb128> chrisccoulson, what's the side effect off installing the apturl config where you don't want it to be?
[15:38] <chrisccoulson> seb128, it only fixes apturl. it's broken for all external protocols
[15:38] <chrisccoulson> and hardcoding apt: URI's to apturl is wrong anyway
[15:38] <chrisccoulson> the default handler is software-centre
[15:39] <seb128> chrisccoulson, do you have an example of other external protocols? clicking on an email: seems to work?
[15:40] <chrisccoulson> it's likely that's stored somewhere in your profile from a previous use
[15:40] <chrisccoulson> i've been told itms: and mms: are broken
[15:41] <chrisccoulson> and all the weird protocols that totem is meant to handle too
[15:42] <slangasek> mitya57: dh-python hint dropped, thanks
[15:43] <mitya57> Thanks!
[15:49] <mlankhorst> pitti: hey can you recheck with after the latest xorg-server goes into -proposed?
[15:52] <psusi> 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] <cjwatson> file bugs with patches in Debian, and let's see how it looks
[15:53] <psusi> ok
[15:54] <psusi> testing it though will require parted3, so should that be in experimental?
[15:54] <cjwatson> honestly I'd rather get the patches into partman and then put parted 3 in unstable
[15:55] <cjwatson> the partman patches should surely still work against parted 2
[15:55] <psusi> 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] <cjwatson> well, let's see the patches for that
[15:56] <alow> 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] <psusi> ok... it was pretty simple... just had to add a -lparted-fs-resize.. and that apparently required -luuid
[15:57] <cjwatson> why isn't that done with pkg-config?
[15:57] <cjwatson> and we could conditionalise that I'm sure
[15:57] <psusi> there doesn't seem to be a .pc file for the fs resize library
[15:58] <cjwatson> I mean, I get that we'd need to reupload partman-base against parted 3 eventually
[15:58] <cjwatson> but I wasn't talking about that bit - I was talking about landing the removal of fs-creation-dependent code first
[15:58] <psusi> yea... you could do that... just the linker flag would need switched
[15:58] <cjwatson> sure, that's easily done later :)
[15:59] <psusi> yea
[15:59] <psusi> I didn't test hfs, but fat resize seemed to work fine
[15:59] <cjwatson> but let's start landing what we can do noninvasively now; it always helps to prune down the problem
[16:15] <chiluk> hey stgraber what are the limits to the number of LXC containers that can reliably operate on a single host?
[16:16] <stgraber> 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] <stgraber> 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] <chiluk> stgraber, thanks.
[16:48] <BenC> 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] <alow> BenC: What's your preference. It doesn't look like I need any packages.
[16:59] <BenC> alow: It's functionally no different. The schroot just provides us a way of installing packages specific to each user
[16:59] <alow> BenC: k - got it.
[17:01] <seb128> cjwatson, mlankhorst: good, mir migrated
[17:02] <cjwatson> excellent
[17:02] <cjwatson> kgunn: ^-
[17:02] <kgunn> cjwatson: thanks guys
[17:13] <infinity> alow: Nope, all looked good, and for bonus points, it does work on POWER5 as well.
[17:13] <mlankhorst> huzzah
[17:14] <alow> infinity: Great. I'm about to head off on vacation, nice to know it's sorted out
[17:14] <infinity> alow: Ahh, and got your response to my followup.  Lovely.  I'll bounce that to the archive right now, then.
[17:15] <infinity> alow: And guessing from backscroll that BenC's give you shell on an e500 machine that doesn't suck?
[17:18] <BenC> infinity: Indeed
[17:18] <infinity> BenC: Awesome, thanks.
[17:18] <infinity> BenC: Can I talk you into an SRU kernel rebase while you're being helpful? :)
[17:19] <BenC> infinity: Sure, why not.
[17:19]  * BenC needs first coffee though
[17:19] <infinity> BenC: https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1276013
[17:24] <BenC> infinity: How long to EOL on saucy kernel?
[17:25] <infinity> 13.10 + 9mo.  So, 13.19!
[17:25] <infinity> (Or 14.07)
[17:28] <infinity> BenC: So, basically, a couple of SRU cadences after trusty releases, which seems like a sane buffer time to let customers upgrade anyway.
[17:30] <BenC> infinity: Excellent
[17:40] <alow> infinity: BenC - yes, that shell account on the e500 is nice. Going to be a bit for me to get the code working, it's non-trivial set of changes - but it's something I'd like to get working.
[17:41] <BenC> alow: Good to hear. Let me know if I can do anything wrt documentation
[17:41] <BenC> alow: Next step, I'll give you shell access to my t4240 (Freescale e6500 64-bit SoC, 12 cores, 24 threads) and see if that works :)
[17:42] <BenC> alow: The only thing I forsee there is it doesn't have an fsqrt function. We fudge it with mathemu in the kernel, but it's not as useful as it sounds
[17:46] <alow> BenC: the issue I ran into with the e500 machine I was looking at previously was the lack of FPU regs. (it has FPU instructions which re-use the GPRs)
[17:48] <alow> BenC: I wrote up details in the GitHub issue I've used to track things https://github.com/andrewlow/v8ppc/issues/100
[17:48] <BenC> alow: That's likely only in the e500v2 system...I'm pretty certain e500mc has fpu regs
[17:50] <infinity> alow: If you were following along at home, the libv8 upload is here: https://launchpad.net/ubuntu/+source/libv8-3.14/3.14.5.8-5ubuntu1
[17:50] <alow> BenC: guess I'm off to read some processor manuals
[17:51] <infinity> alow: And if you were curious about the packaging changes, to see if you did it "right" locally, the diff is http://launchpadlibrarian.net/166207132/libv8-3.14_3.14.5.8-5_3.14.5.8-5ubuntu1.diff.gz
[17:51] <alow> infinity: sweet. Thanks for your work here.
[17:52] <infinity> Now to convince ARM to give us an aarch64 port that isn't bleeding_edge...
[17:53] <alow> infinity: merging backwards in time is in theory the same work as dragging code forward. Mentally less satisfying however.
[17:54] <infinity> alow: I got a response from a guy at ARM that stated (regarding 3.14): "Most notably at that time V8 used to have hand crafted "slow" code path, today they are generated by the optimising compiler. So to backport, one would have to write all those slow path by hand ..."
[17:55] <infinity> alow: Is that something you ran into as being a problem?  Did you have some magic to work around that?  Is he full of it? :P
[17:55] <alow> infinity: yup. We started in 3.14 with the 'slow code' and have been removing some of it as we crawl upstream. However, re-working the upstream code that is 'new' is also work that he is ignoring.
[17:56] <alow> infinity: I think the motivation to move backwards in time is poor. MongoDb / Node 0.10 are the best motivators.
[17:57] <infinity> From a distro perspective, Mongo/Node are pretty much the only things we care about.  The only other place V8 is used heavily is embedded in Chrome, and I imagine there's a lot of porting needed to make Chrome happy on a new platform (plus, well, for people targetting server markets initially, who cares?)
[17:57] <alow> infinity: took about 2.5months effort to go from 3.14 to 3.22. So probably 3 months of work to push bleeding edge back to 3.14.
[17:58] <infinity> alow: Anyhow, thanks for all your work on this.  We'll see what we can do for that other platform you don't care about. ;)
[17:59] <alow> infinity: someone just needs to convince IBM to build an ARM server.. then I'm set
[17:59] <infinity> alow: Hah.  I had some hopes for that when I started seeing Rusty at Linaro Connect, but I'm definitely still not sure what IBM's interest is there, and I'm not sure anyone else knows either.
[17:59] <alow> BenC: hmm.. looking like that e500mc machine is different enough from the e500v2 that work on one won't help the other. Plus side is that e500mc might be 'easy' to get working
[18:00] <BenC> alow: I would susect the e500mc work to benefit e500v2 in some way, but I suspected as much.
[18:00] <alow> infinity: I think the hold-up is waiting for someone else to succeed in the space (arm servers)
[18:02] <infinity> alow: I think that's what everyone is waiting for.  A whole lot of eggs with no chickens.
[18:31] <psusi> cjwatson: I noticed there is check_basicfilesystems and check_swap that appear to still be trying to use libparted to check swap, fat16, fat32, and ext2 filesystems... but I don't see an option to actually use this checking on the menu in d-i... was this removed already and that code is just unused cruft?
[19:22] <alow> BenC: ick - problem #1 was data cache flush - we assume size of 128, when this CPU has 64. I really need to re-write that logic to test the actual hardware and make the size non-static
[19:23] <alow> BenC: but I've run into at least 1 more instruction not supported: fcfid - and I see a list of unsupported instructions in table 3-1 of http://cache.freescale.com/files/32bit/doc/ref_manual/E500MCRM.pdf
[19:25] <BenC> alow: We've seen similar problems getting JVM working well on this system
[20:02] <arges> bdmurray: hola
[20:03] <bdmurray> arges: hey
[20:10] <cjwatson> psusi: No, it's not cruft.  All the check.d scripts are run between partman's main display and the point where it asks to confirm changes
[20:10] <cjwatson> see the partman script in partman-base
[20:12] <psusi> cjwatson: hrm... it doesn't seem to be... otherwise I should be getting failures since there's no more FILESYSTEM_CHECK method in parted_server...
[20:13] <psusi> and why would it check all filesystems there?
[20:13] <cjwatson> Sure is.  You could try sticking set -x in scripts and watching it show up in syslog.
[20:13] <cjwatson> I'm sorry but I don't have time to explain it further now (childcare)
[20:13] <cjwatson> Please use set -x and such and trace things through for yourself :)
[20:14] <cjwatson> Also of course it'll only be checking things under certain conditions
[20:14] <cjwatson> Like for instance if the fs is being mounted somewhere and not formatted
[20:15] <psusi> ahhh
[20:16] <psusi> hrm....
[20:16] <psusi> well, I think we can do without check_swap, since there's really no such thing as fscking swap ;)
[20:18] <cjwatson> psusi: sure, I think we generally just reformat swap anyway
[20:19] <psusi> shouldn't... that would change the uuid
[20:19] <cjwatson> we handle that
[20:19] <cjwatson> look at the code
[20:19] <cjwatson> we dd the uuid out beforehand and then back in
[20:19] <cjwatson> it's by far the quickest way to get known-good swap
[20:20] <psusi> hah... not much else in there to be rewriting ;)
[20:20] <JanC> I suppose it might be necessary for encrypted swap?
[20:20] <psusi> no?
[20:21] <cjwatson> no, it's fine
[20:21] <cjwatson> encrypted swap => ordinary swap on top of encrypted lvm, in practice
[20:25] <psusi> cjwatson: there are log calls all over the partman code, but I don't see any of it in syslog... is there something you have to do to switch that on?
[20:26] <cjwatson> log () goes to /var/log/partman
[20:27] <cjwatson> see partman-base/lib/base.sh
[20:27] <cjwatson> right, really gone before children disassemble downstairs
[20:29] <psusi> hehe...
[21:02] <stgraber> xnox: didn't I bug you about libnih-dbus-dev not depending on libdbus-dev before?
[21:02] <xnox> stgraber: yeah, and i believe i have fixed it....
[21:02] <xnox> stgraber: maybe it's not in the archive...
[21:03] <stgraber> it sure isn't in the archive ;)
[21:03] <xnox> yeah, unreleased.
[21:03] <xnox> let me upload it.
[21:03] <stgraber> thanks
[21:10] <ogra_> stgraber, oh, so lennart just swallowed lxc into  systemd
[21:11] <stgraber> ogra_: nah, nspawn has been around for a while, it's just mostly useless :)
[21:11] <ogra_> ah, heh
[21:12] <stgraber> it's sort of ok as a thin application container, but Lennart comparing it with LXC is just ridiculous ;)
[21:12]  * ogra_ still waits for the day he announces that bash is now a systemd part :)
[21:13] <ogra_> well, just wait til he gets the right ideas ...
[21:29] <tkamppeter> OdyX, cups-filters 1.0.45 released.
[21:31] <infinity> stgraber: It doesn't matter if it's comparable to lxc, it'll become the new standard, and you'll like it or else.
[22:52] <bdmurray> hallyn: there are two uploads of libvirt to the saucy -proposed queue are they the same?
[22:52] <hallyn> bdmurray: no, the first one has the wrong pocket listed :)
[22:53] <bdmurray> hallyn: I'm pretty sure it doesn't matter as they'll go to -proposed anyway
[22:53] <hallyn> bdmurray: oh.  i thought -updates might break something