[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/<IP_ADDRESS>-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_<IP_ADDRESS>-5_<IP_ADDRESS>-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?   :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


[00:29] <tedg> So, the synaptics driver has this feature where it's supposed to read changes do the xorg.conf file.
[00:30] <tedg> How does that work?  Can all the drivers work that way?  Do they?
[00:30] <tedg> Does xorg.conf get parsed for every driver?
[00:30] <bryce> tjaalton: apparently bdmurray was planning on scheduling a bug hug day for xorg next week, but between our efforts, our untriaged bug count dropped too low.  heh.
[00:32] <bryce> tedg: that might be a Q for mjg
[00:32] <bryce> that may be the hack he did during Gutsy to get the touchpad configuration stuff working nicely
[00:34] <tedg> I was more curious from the perspective of, can I put it on the TODO list to have the wacom driver do it ;)
[00:34] <tedg> I'd really like plug'n'play tablet support.
[00:37] <bryce> tedg: I believe that's in the pipeline, if it's not available already in hardy
[00:48] <tedg> It didn't work for me in Hardy if it's supposed to.
[00:48] <tedg> The only thing I had to do is comment some xorg.conf options though.
[00:48] <tedg> Now it works really well.  I unplugged my mouse.
[01:09] <bryce> ohh, I think I recall seeing a bug about interference between mouse and synaptics
[02:11] <ubotu> New bug: #181914 in xorg (main) "default X configuration assumes wacom hardware" [Undecided,New] https://launchpad.net/bugs/181914
[03:42] <pwnguin> ^ doesn't hardy drop xorg.conf by default?
[05:45] <ubotu> New bug: #181935 in linux-restricted-modules-2.6.24 (restricted) "package xorg-driver-fglrx 8.443.1-1 failed to install/upgrade: intentando sobreescribir `/usr/bin/amdcccle', que está también en el paquete fglrx-amdcccle" [Undecided,New] https://launchpad.net/bugs/181935
[07:15] <ubotu> New bug: #181943 in xorg (main) "[Gutsy] X11 random crash," [Undecided,New] https://launchpad.net/bugs/181943
[07:20] <tjaalton> bryce: hehe
[07:20] <tjaalton> pwnguin: no
[07:26] <tjaalton> oh I love those "random crash" bugs
[07:39] <pwnguin> well my crash is clearly repeatable
[07:55] <bryce> "Hey, I'm having a random crash, can you fix? kthxbye"
[07:56] <pwnguin> well, at least you're paying attention
[07:56] <pwnguin> i havent been able to get any results from filing a bug upstream
[08:00] <tjaalton> pwnguin: ah the xkbLeds bug?
[08:00] <tjaalton> *LED
[08:02] <pwnguin> yea
[08:04] <pwnguin> im not sure how to fix the code, as where it appears is dead simple, but i have no idea where all the code that produced the null pointer is called from
[08:18] <tjaalton> pwnguin: you might have better luck with #xorg-devel :)
[13:39] <tjaalton> mvo: there was this strange upgrade failure where xserver-xorg-core.list got strangely corrupted (with data which looks like from Packages file).. is it something that warrants further investigation?
[13:40] <tjaalton> bug 181530
[13:40] <ubotu> Launchpad bug 181530 in xkbset "package xkbset None [modified: /var/lib/dpkg/info/xkbset.list] failed to install/upgrade: il file con la lista dei file del pacchetto `xserver-xorg-core' contiene un filename vuoto" [Undecided,Incomplete] https://launchpad.net/bugs/181530
[13:40] <ubotu> New bug: #182003 in linux-restricted-modules-2.6.24 (restricted) "nvidia driver unable to load on clean 7.10 install" [Undecided,New] https://launchpad.net/bugs/182003
[13:40] <tjaalton> reinstalling xserver-xorg-core helped there
[13:40] <mvo> tjaalton: if its a isolated thing, then its likely that its some HW issue on the machine, most corruptions on the dpkg level seems to be caused by bad ram
[13:41] <mvo> tjaalton: (this is the dpkg level)
[13:41] <tjaalton> ok, I'll close it then, and ask the reporter to run memtest
[13:42] <mvo> thanks
[13:42] <tjaalton> thanks
[13:42] <tjaalton> :)
[13:46] <mvo> tjaalton: just to confirm, we will not get a new xserver for hardy that support redirected direct rendering? that means under compiz we have all the nice glx artifacts ?
[13:47] <tjaalton> right
[13:47] <tjaalton> it would touch too many pkaces
[13:47] <mvo> meh, ok. thanks. that means the compiz team needs to think about some stragegy to deal with it
[13:47] <tjaalton> places
[13:48] <tjaalton> I think this was discussed at UDS
[14:43] <Ng> I just upgraded my gutsy laptop to hardy and I've noticed X is using EXA by default now (intel driver, 855gm chipset), but some things feel a lot slower
[14:43] <Ng> scrolling specifically
[14:43] <tjaalton> yep'
[14:43] <tjaalton> see bug 177492 :)
[14:43] <ubotu> Launchpad bug 177492 in xserver-xorg-video-intel "EXA is balls-achingly slow" [High,Confirmed] https://launchpad.net/bugs/177492
[14:45] <Ng> haha, nice subject
[14:46] <tjaalton> so, put 'Option "AccelMethod" "XAA"' to the driver section for now
[14:47] <Ng> now I have to write a driver section! ;)
[14:47] <Ng> but ta. shame that the fix won't be able to be in hardy, but nevermind
[14:47] <Ng> I noticed a comment on that bug about losing video with XAA - do they mean Xv?
[14:48] <Ng> that used to work ok in gutsy with XAA
[14:48] <jcristau> with compiz?
[14:48] <Ng> well ;)
[14:48] <tjaalton> it's the other way around, and only with 965 I think
[14:48] <Ng> actually it did kind of work with compiz, but it was entirely black&white for some reason
[14:48] <Ng> I never really dug into that one
[14:48] <jcristau> (i guess compiz on i855 would probably be balls-achingly slow anyway)
[14:48] <tjaalton> oh, I don't know what keybuk refers to
[14:49] <tjaalton> ah
[14:49] <Ng> jcristau: not so much
[14:49] <Ng> jcristau: sure the thing isn't going to be playing quake3 any time soon, but a sane selection of compiz plugins is actually pretty speedy, mostly because it's only doing 1024x768 I suspect
[14:49] <jcristau> ok, cool
[15:02] <Ng> yeah much faster back in XAA, but Xv is entirely broken now
[15:03] <tjaalton> ok, so it's not just 965 :/
[15:03] <Ng> gstreamer-properties died from a BadAlloc error when I ran the test
[15:04] <tjaalton> nice..
[15:13] <Ng> much as I like xv, I have a tiny screen that I almost never use for video anyway, and I scroll an awful lot
[15:13] <Ng> so scrolling wins ;)
[15:13] <tjaalton> does video work without Xv
[15:13] <tjaalton> ?
[15:17] <Ng> yep
[15:18] <tjaalton> cool
[15:18] <Ng> I'll try and remember to flip back to EXA quickly to make sure that video works there too
[17:35] <tjaalton> right, at least cirrus doesn't start in the new world order
[17:35] <tjaalton> "Mode pool is empty"
[17:45] <ubotu> New bug: #182062 in xmodmap "IBM Thinkpad T61 key slash/question doenst works in Gutsy" [Undecided,New] https://launchpad.net/bugs/182062
[17:49] <tjaalton> it needs modelines, which seems a bit odd
[17:55] <tjaalton> modelines, defaultdepth and Modes, duh
[21:06] <pwnguin> well crap, xorg-devel is like half ubuntu devs
[21:10] <bryce> heh
[21:10] <bryce> you say that like it's a bad thing...?  ;-)
[21:11] <pwnguin> also bryce, i read your blog
[21:12] <pwnguin> on the subject of library versions and fixes, why not use branches?
[21:12] <pwnguin> you've already migrated to bzr
[21:12] <pwnguin> for inkscape
[21:13] <bryce> no we still use svn
[21:13] <bryce> we only migrated the bug tracker
[21:13] <pwnguin> oh
[21:13] <bryce> we have used branches in the past, but find they grow stale and don't get adequate testing.
[21:13] <pwnguin> well, it still has "very cheap branching"
[21:13] <pwnguin> ;)
[21:14] <pwnguin> well, that'd sorta be the point
[21:14] <bryce> to not get adequate testing?
[21:14] <pwnguin> dev branch updates the libraries
[21:14] <pwnguin> the other branches would attempt to pull in fixes without touching version dependencies
[21:15] <pwnguin> the other branches would naturally die off as people prefer to simply update lib dependencies
[21:17] <pwnguin> it'd be easier to do with bazaar, if it lets you track distro patches
[21:20] <bryce> could be
[21:20] <bryce> I suspect it's more likely we'd move to git than bzr, but currently it sounds like most developers favor staying with the status quo,
[21:21] <bryce> we've set up svn->bzr and svn->git interfaces, so those passionate about git and bzr are fairly happy, and those who wish to stick with svn are happy
[21:21] <bryce> I would expect changing at this point would result in some becoming unhappy, and few becoming more happy than they already are
[21:22] <monkee_of_evil> Allo
[21:23] <monkee_of_evil> Has anyone had any luck here getting a triple monitor setup working with Ubuntu?
[21:23] <bryce> I'd like to see us move to bzr, but don't really have a strong preference; I've not gathered sufficient convincing arguments to make me want to push for it yet
[21:23] <bryce> monkee_of_evil: I have had some limited successes
[21:24] <monkee_of_evil> I've got these 2 widescreen acer monitors and a single Sceptre monitor ( none-widescreen )
[21:24] <pwnguin> i suppose it just makes more sense in the general perspective; if you have bzr/git and binary distros using your stuff -- you can keep lib version ifdefs out of the tree
[21:24] <bryce> monkee_of_evil: If you're using Feisty or earlier Ubuntu, you can use Xinerama to do it
[21:24] <monkee_of_evil> I'm on Gutsy
[21:24] <bryce> monkee_of_evil: however from Gutsy forward, most drivers have switched to xrandr, which does not handle multiple graphics cards so well
[21:24] <monkee_of_evil> damn
[21:24] <bryce> it won't be 'til Hardy+1 that the issue is straightened out
[21:24] <pwnguin> i havent really used either bzr or git
[21:24] <tjaalton> well, ati and intel
[21:25] <tjaalton> and experimental mga
[21:25] <pwnguin> matrox?
[21:25] <tjaalton> rigt
[21:25] <tjaalton> +h
[21:25] <bryce> tjaalton: and nv since g80
[21:25] <tjaalton> yep
[21:25] <monkee_of_evil> Yeah... I've got an older ATI dualy & an onboard intel chipset
[21:25] <tjaalton> but nvidia binary can do silly stuff
[21:25] <bryce> monkee_of_evil: I have gotten triple screen working with non-merged displays
[21:25] <bryce> so like you have :0.0 and :0.1
[21:26] <bryce> that was on -ati, and I found it too buggy to actually use (mouse would get stuck, etc.)
[21:26] <monkee_of_evil> hmm
[21:26] <bryce> that was on Gutsy with -ati 195 iirc; it might have gotten better since
[21:26] <tjaalton> ati upstream supports zaphod mode again
[21:26] <monkee_of_evil> It will automatically do it's thing and clone my desktop to the two widescreens in Gutsy
[21:27] <tjaalton> so it should work on current hardy
[21:27] <monkee_of_evil> What sucks for me is that I've got that RV700 or some crap for my ATI card, so the official binaries don't work
[21:27] <bryce> http://bryceharrington.org/Photos/X/
[21:29] <monkee_of_evil> I tried configuring X to get it going and the only thing i can make it do is show a black screen for 2/3 of the screen on my center monitor ( the one plugged into the intel card ) then for the rest of the screen you see these multi-color stripes
[21:29] <monkee_of_evil> and you can see this blurr where the mouse moves
[21:29] <monkee_of_evil> then on the wide screens both of them are blank except for the top left where it shows the part numbers of the monitor
[21:29] <monkee_of_evil> It's the weirdest thing
[21:30] <monkee_of_evil> can't wait for better monitor support
[21:31] <monkee_of_evil> Bryce: nice screenshots
[21:31] <monkee_of_evil> err
[21:31] <monkee_of_evil> pictures actually
[21:31] <monkee_of_evil> but w/e
[21:32] <bryce> w/e ?
[21:33] <pwnguin> w/e is often "whatever"
[21:33]  * bryce shrugs
[21:33] <monkee_of_evil> pwnguin got it
[21:33] <pwnguin> more importantly, that's gnome+konsole
[21:34] <pwnguin> and.. xmms?
[21:36] <bryce> pwnguin: if you're trying to give me a hard time, won't work ;-)
[21:37] <monkee_of_evil> I like xmms
[21:37] <pwnguin> i think if you try harder, you could put in an enlightenment app too ;)
[21:37] <monkee_of_evil> Fluxbox ftw
[21:37] <monkee_of_evil> :)
[21:38] <pwnguin> xmms is like the worst of all worlds. terrible UI that mimics winamp. horrible playlist UI, weak playlist tools...
[21:38] <tjaalton> and yet something that actually worked all these years :)
[21:39] <pwnguin> thats about all it has =(
[21:39] <tjaalton> heh
[21:39] <bryce> if you must know, I used to use KDE, and wrote scripts to automate konsole placement using dcop.  I've since rewritten the code for gnome-term, but those photos were taken before that.
[21:40] <pwnguin> interesting. is the placemnt script a matter of which screen?
[21:40] <bryce> I've tried both KDE and GNOME music apps and generally find them inadequate
[21:40] <monkee_of_evil> yeah.. I fucking hate Rythmbox
[21:40] <monkee_of_evil> Listen isn't much better
[21:40] <bryce> I put in a bunch of bugs on rhythmbox before giving up on it
[21:41] <monkee_of_evil> Too bad foobar doesn't run natively
[21:41] <monkee_of_evil> although it runs decently under wine
[21:41] <tjaalton> I used KDE in -98 when I installed linux (SuSE 5.3) for the first time
[21:42] <bryce> pwnguin: no, my set up has a virtual screen so I just specify the x,y coordinates that'd put them on the right screen
[21:42] <bryce> it's pretty trial-and-error, and different for KDE and GNOME
[21:42] <pwnguin> anyways, i didnt mean to start an involved flamewar, just poking some fun ;)
[21:42] <bryce> :-P
[21:43] <tjaalton> I use rb happily at work, but it's far from perfect
[21:43] <bryce> I'm just irritable due to all the UME stuff at the moment, don't mind me
[21:43] <tjaalton> hehe
[21:43] <pwnguin> tjaalton: i wish it would let me choose a different playlist to default to on startup
[21:43] <pwnguin> i filed a wishlist bug in LP and someone appears to have run with it, we'll see where that goes
[21:44] <tjaalton> ah, I just plug in my iPod and let it play random
[21:44] <pwnguin> i dont own one of those
[21:44] <pwnguin> but its nice to be able to filter by rating etc
[21:44] <tjaalton> I got it just because it's the only brand that has any sort of gadgets for cars
[21:45] <tjaalton> http://www.last.fm/user/tepsipakki
[21:45] <pwnguin> i actually used rhythmbox to come up with a playlist for my crappy car stereo to put on CD
[21:45] <pwnguin> 700 megs of mp3s at bitrate 300 or less sorted by rating
[21:46] <tjaalton> now I use banshee to sync the iPod, and the next version should finally fix the UI so I can choose by genre
[22:21] <bryce> dah, LP is going offline
[22:24] <jcristau> tjaalton: will you report the bug about i810preinit not setting depth to 16 to bugzilla, or shall i?
[22:26] <tjaalton> jcristau: you can do it, it was your idea anyway :)
[22:27] <tjaalton> jbarnes knows about it already though
[22:27] <jcristau> yeah i've read that
[22:28] <tjaalton> right, he'd prefer to have the patch on b.fd.o
[22:28] <jcristau> a bz report is safer than a mention on irc :)
[22:28] <tjaalton> of course, and you can't track bugs outside bz
[22:28] <tjaalton> er, patches
[22:28] <tjaalton> or both actually
[22:29] <tjaalton> ffs, launchpad maintenance break
[22:40] <jcristau> tjaalton: what's your bz email again?
[22:40] <tjaalton> tjaalton+freedeskto at cc.hut.fi
[22:40] <tjaalton> freedesktoP
[22:43] <jcristau> thx
[22:44] <jcristau> there. #14032
[22:44] <tjaalton> thanks
[22:44] <jcristau> np
[22:45] <tjaalton> so you tried it as well?
[22:45] <jcristau> didn't have time to test the patch yet, no
[22:45] <tjaalton> well, it works
[22:46] <jcristau> but i don't see why it wouldn't work when X -depth 16 does
[22:47] <jcristau> pretty busy at work this week, plus my debian time was taken by other stuff...
[22:48] <tjaalton> don't worry, a couple of guys already proved it working :)
[22:49] <jcristau> cool
[22:56] <tjaalton> woohoo, at least one bug fixed by switching to openchrome, bug 180841
[22:57] <ubotu> Launchpad bug 180841 in mesa "glXDestroyContext causes segmentation fault with Via Unichrome graphics" [Undecided,Incomplete] https://launchpad.net/bugs/180841
[23:08] <bryce> nice
[23:09] <tjaalton> although it was quite unclear which version he was using before, and I think via/openchrome both share the same mesa driver
[23:59] <ubotu> New bug: #182100 in linux-restricted-modules-2.6.24 (restricted) "ATI Catalyst 7.12 conflict with Screen Resolution" [Undecided,Incomplete] https://launchpad.net/bugs/182100
[23:59] <tjaalton> sigh


[00:02] <verwilst> i have a line "$(INSTALL_FILE) debian/templates/zabbix_proxy.conf.in $(TMP_PROXY_PGSQL)/usr/share/doc/zabbix-proxy-pgsql/zabbix_proxy.conf"
[00:02] <verwilst> why does it save this as a .gz?
[00:02] <verwilst> i have the same line somewhere else ( just slightly different filename ) and it doesnt get a .gz appended
[00:03] <azeem> verwilst: things in /usr/share/doc get gzipped if they're bigger than a threshold
[00:03] <azeem> see man dh_compress for how to exclude that one
[00:04] <verwilst> otherwise dbconfig-common errors out with error: template infile /usr/share/doc/zabbix-proxy-mysql/zabbix_proxy.conf does not exist
[00:04] <azeem> things should never depend on stuff in /usr/share/doc
[00:04] <azeem> users should be able to purge the docs if they want
[00:05] <verwilst> hm
[00:06] <verwilst> ( it's an already existing deb that i'm upgrading
[00:06] <verwilst> so it's bad practice?
[00:06] <azeem> verwilst: didn't you or somebody else introduce those proxies recently?
[00:06] <azeem> or was that another package?
[00:06] <verwilst> euh
[00:06] <verwilst> or maybe it was me on this channel?
[00:07] <verwilst> i better hope so damned, all that work i spent already!
[00:07] <verwilst> ;)
[00:07] <azeem> so the other binary packages in there also use templates from /usr/share/doc?
[00:08] <verwilst> azeem: ah no it's not dbconfig
[00:08] <azeem> ?
[00:08] <verwilst> it's postinst
[00:08] <verwilst> dbc_generate_include_args="-U -o template_infile=/usr/share/doc/zabbix-proxy-mysql/zabbix_proxy.conf"
[00:10] <verwilst> hm, it is dbconfig.. :P don't know what dbconfig has to do with that file though
[00:15] <verwilst> ah, i do now
[00:18] <verwilst> azeem: i should put the config file examples in /usr/share/zabbix-proxy/?
[00:18] <azeem> config files belong under /etc
[00:18] <verwilst> myeah but it's a template
[00:19] <verwilst> with _DBC_xxx_ stuff in it and such
[00:20] <verwilst> actually zabbix-agent has ./usr/share/zabbix-agent/zabbix_agentd.conf but zabbix-server has./usr/share/doc/zabbix-server-mysql/zabbix_server.conf
[00:20] <verwilst> azeem: tell me where to put it and i'll make it so ;)
[00:21] <azeem> I don't know about web apps and their templates, sorry
[00:21] <verwilst> web apps?
[00:21] <verwilst> it could be the template of any app
[00:21] <verwilst> it's a c daemon..
[00:24] <verwilst> /usr/share/<app> seems better than /usr/share/doc/<app> though :)
[00:24] <verwilst> so i'll use that in the meantime
[00:54] <persia> verwilst: /usr/share/$(package) should contain anything that could be described as "software", /etc/$(package) should contain "configuration", and /usr/share/doc/$(package)/examples example data that the package doesn't actually use for anything, but which a user may wish to later inspect.
[00:56] <persia> dmoerner: I've moved the page to https://wiki.ubuntu.com/MOTU/School/PackagingWithoutCompiling, because scripts are code too :)
[00:56] <verwilst> persia: so what about config templates?
[00:56] <verwilst> with DBC macro's and such?
[00:58] <persia> verwilst: It very much depends on the need for them.
[00:58] <verwilst> how's that?
[00:58] <persia> If they are needed by the package at install time or run time, they belong in /etc/ or in /usr/share
[00:58] <persia> If they are only needed by the user, they belong in /usr/share/doc/examples
[00:59] <verwilst> well the DB params are configured through dbconfig
[00:59] <persia> In the first case, if they are expected to be changed by the user, they belong in /etc, and if they are never expected to be changed by the user, they belong in /usr/share
[01:00] <verwilst> they should be changed by the user, but the initial configure should happen through dbconfig
[01:00] <verwilst> :)
[01:00] <verwilst> if i dput a package
[01:00] <verwilst> can i see it on my ppa page right away?
[01:00] <persia> OK.  That which is expected to be changed by the user ought be a conffile, and ought be in /etc, so that changes by the user are preserved on package upgrade.
[01:01] <verwilst> ah yes i can :)
[01:01] <verwilst> hm ok
[01:01] <verwilst> and how do i handle dbconfig then?
[01:01] <persia> See, I don't see how the specific use of dbconfig in this case makes any difference.
[01:02] <verwilst> a /etc/zabbix/zabbix_proxy.conf.default or something?
[01:02] <verwilst> and when you do a dpkg-reconfigure, it copies the .default to zabbix_proxy.conf with _DBC_DBNAME_ and such replaced?
[01:02] <verwilst> or am i missing something here? ;)
[01:03] <persia> So the template isn't actually intended to be modified by the user?
[01:04] <verwilst> yeah it is
[01:04] <verwilst> dbconfig only deals with the db part of the config ( so that shouldnt be needing any modification afterwards
[01:05] <verwilst> but there are other options in that file too
[01:05] <persia> Doesn't really matter.
[01:05] <persia> Essentially, from what you've described, you have some file, and you use that file to generate a configuration file.
[01:06] <persia> The generated configuration file is what most users are likely to edit, no?
[01:06] <persia> So the source file wouldn't be edited by the users.
[01:06] <verwilst> idd
[01:08] <persia> Note that I suspect you may have an additional issue: specifically that you may not preserve user modification of the configuration file if they run dpkg-reconfigure
[01:08] <verwilst> yeah
[01:08] <persia> Of course, you may: I'm just guessing here.
[01:08] <verwilst> how is that normally handled?
[01:09] <persia> There are a few strategies.  If you flag it as a conffile, and ship a working default configuration each time, the user is notified if they have changed it, and can reconcile your changes.
[01:10] <persia> If you have part of the file that will always be changed, but most won't be changed, you might consider splitting that out into a separate file, so that you can change the base configuration, and only the user modifies the e.g. database connection configuration
[01:10] <verwilst> that only works if the config format allows including other files
[01:10] <verwilst> right?
[01:10] <persia> Some people like the ucf framework to help with this, and others have complex parsing scripts in the postinst
[01:10] <persia> Indeed.
[01:11] <verwilst> which isnt the case i'm afraid
[01:11] <verwilst> anyways, im sooo tired :) it's way too late
[01:11] <persia> You may just end up with something where the user needs to manually fix it on each upgrade, which is ugly, but better than wiping user config each time (especially because this violates the debconf-is-not-a-registry rule)
[01:12] <verwilst> my first ppa upload just built succesfully! jaj! :)
[01:12] <verwilst> persia: or reming dbconfig from zabbix?
[01:12] <verwilst> removing*
[01:13] <persia> I tend to prefer to comment things out rather than removing them, but that can cause another issue: after installation, software should work without further user tinkering.  It may not work ideally, but it should work.
[01:14] <verwilst> gm
[01:14] <verwilst> an issue for another day ;)
[01:14] <verwilst> goodnight!
[01:15] <verwilst> thanks for the info persia!
[06:07] <tuxmaniac> in a src tarball if one of the files is LGPL and the remaining GPL then in the debian/copyright. Can i specificy something like this. http://paste.ubuntu.com/42076/
[08:15] <Iulian> Good morning.
[08:32] <probono> hi all, can someone give a 2nd opinion on my package of a little python app, http://revu.ubuntuwire.com/details.py?package=liveusb please?
[10:20] <RainCT> morning
[10:20] <probono> morning
[10:24] <jpds> morning
[10:24] <probono> can i bribe RainCT or jpds into looking @ my package? ;-)
[10:25] <jpds> Sure, I have PayPal.
[10:25] <jpds> Joking, which package is it?
[10:25] <probono> liveusb :)
[10:26] <jpds> Ahhh, I was trying to put the Ubuntu intrepid daily on my USB with that yesterday.
[10:26] <probono> jpds: let me guess, it didn't work because 10,000 windows popped up
[10:27] <jpds> probono: No, it didn't let me say where the .iso file was.
[10:27]  * laga will offer 10 merges next cycle for the first two problems each found in http://revu.ubuntuwire.com/details.py?package=mythtv-theme-metallurgy-wide - 4 merges for every problem after that :)
[10:27] <probono> ah ok, it's designed to run _from_ the live cd
[10:27] <jpds> probono: I figured that out after running it ;-)
[10:27] <Iulian> laga: Hahah
[10:28] <laga> Iulian: getting desperate here ;)
[10:28]  * RainCT tries to find as many errors as possible in laga's package ;P
[10:28] <Iulian> Me too.
[10:28] <laga> that's the spirit.
[10:29] <laga> don't forget to ACK it ;)
[10:29] <Iulian> laga: Do you have a needs-packaging bug in LP?
[10:30] <Iulian> laga: If yes, close it in the changelog.
[10:30] <jpds> probono: I think having a LP: #### in changelog, will close that bug..
[10:30] <laga> Iulian: i don't have one.
[10:30] <probono> jpds: shouldn't it?
[10:30] <Iulian> laga: Well, file one then.
[10:31] <RainCT> laga: how do you want to get a FFe without bug? :P
[10:31] <jpds> probono: Ignore that, I was looking at the bzr diff.
[10:31] <RainCT> laga: and most probably the package will be rejected (by archive admins) if you don't mention the bug where the exception was granted in debian/changelog
[10:32] <jpds> probono: Upstream tarball has no COPYING/LICENSE file.
[10:32] <laga> alright, i'll get an exception granted then.
[10:33] <probono> jpds: does it need one as it's a native package?
[10:33] <jpds> probono: Yes.
[10:34] <RainCT> laga: the README isn't interesting
[10:34] <geser> laga: looking at your package: how comes that the themeinfo.xml says version 1.1 while the the changelog says 1.0?
[10:34] <jpds> probono: cp /usr/share/common-licenses/GPL-2 . - should do it.
[10:34] <geser> laga: please word-wrap the license text in debian/copyright
[10:35] <probono> thanks jpds
[10:35] <laga> RainCT: upstream README? it is interesting for those wanting additional colour schemes
[10:36] <Iulian> laga: Also please consider changing to ttf-dejavu as ttf-bitstream-vera is scheduled for removal in Debian.
[10:36] <laga> geser: i don't know. the upstream release is 1.0 and i doubt the theme version is used for anything interesting anyways, so that's not worth fixing
[10:36] <RainCT> laga, no, because the homepage should be in a Homepage: field in debian/control ;)
[10:37] <laga> RainCT: yeah, but people won't know if there is anything interesting on that homepage :)
[10:37] <RainCT> laga: they should look then :P
[10:37] <laga> pff.
[10:38] <laga> ;)
[10:38] <RainCT> (and most people won't look at the README file anyway. it's more likely that they go to the homepage first)
[10:38] <laga> that's not a reason not to install it
[10:38] <RainCT> (ah, and the README is supposed to have info about the package itself, not about others)
[10:38] <laga> i often look at the README file. it's not my fault new users don't know that /usr/share/doc/ exists :)
[10:39]  * laga gives up and removes the darn README
[10:39] <Iulian> laga: See debian bug #461308
[10:39] <geser> laga: do I understand it correctly that this package is for multiverse?
[10:39] <RainCT> laga: note that you can use * with dh_install
[10:39] <laga> geser: yes
[10:41] <laga> geser: it depends on mythtv-common which is in multiverse
[10:41] <RainCT> laga: unless I'm missing something, you don't need the dirs files
[10:43] <laga> i blame superm1, i based it on his package
[10:43] <geser> laga: IIRC you don't need XS- before Vcs-* anymore
[10:43] <laga> RainCT: you're correct, it looks like i don't need the *dirs files
[10:45] <RainCT> laga: the description is supposed to explain what the package containsm, not how to use it.. but well I don't know if it's policy for mythbuntu to have bad descriptions so feel free to ignore that :P
[10:47] <laga> that line won't kill anyone :)
[10:47] <laga> great, why did lintian start to throw warnings at me *now* about files being executable when they shouldn't be? i didn't change anything
[10:49] <laga> Iulian: is ttf-dejavu a drop-in replacement for ttf-bitstream-vera?
[10:49] <laga> or does the package need to be changed?
[10:52] <RainCT> jpds: how do I unencript that? XD
[10:52] <RainCT> jpds: ah, nvm
[10:52] <jpds> ...
[10:55] <probono> jpds, still looking at liveusb? or was that the only change necessary?
[10:55] <jpds> probono: I have to go out for a sec, brb.
[10:55] <probono> alright
[10:57] <Iulian> laga: ttf-dejavu is a replacement for ttf-bitstream-vera. Afaics that bug was reported a while ago and there has not been any activity in it recently.
[10:58] <Iulian> laga: I don't know if it's going to be removed from Ubuntu too.
[11:00] <laga> Iulian: okay, then i'll leave it in right now. if it ever gets removed from ubuntu, it should be an easy task if it's indeed a simple drop-in replacement
[11:00] <laga> i have no clue how the font subsystems work and i'm not exactly keen on finding out right now - lots of other stuff to do for intrepid.
[11:01] <Iulian> laga: Sure, your choice.
[11:02] <laga> hum. is there a nice tool to line-wrap documents? doing this manually is a bit annoying
[11:06] <wgrant> A word processor, LaTeX, or a web browser should work fine.
[11:07] <laga> i've used "reformat". worked reasonably well
[11:18] <persia> laga: There are also line-wrapping functions in many text editors, including both vim and emacs, which seem to carry most pathos.
[11:18] <laga> okay. 10 merges for the needs-packaging thing, 10 for the line wrapping in debian/copyright, 2 for the README file (because i don't agree with RainCT on that one ;)), 4 for the homepage field, and 4 for the X-VCS things
[11:19] <laga> 30 merges. i hate you guys.
[11:19] <persia> tuxmaniac: You ought identify the LGPL file, and document that it is LGPL, the (likely different) copyright holder and author, and include the LGPL excerpt indicating the license.
[11:19] <persia> laga: You did offer :)
[11:19] <laga> yeah ;)
[11:20] <persia> If you want to get a head start, the RCbugs page lists a number of things which may wish to be merged.
[11:20] <laga> it'll contribute towards my MOTU application, so i'm not complaining too much.
[11:20] <laga> persia: for intrepid?
[11:21] <persia> laga: Indeed.  Debian is near release now, and closing *lots* of release-critical bugs.  Some of these also affect Ubuntu packages, and represent changes that would not violate FeatureFreeze.  Fixing these is a good thing, else we release with RC bugs with known fixes, which doesn't look so good.
[11:22] <laga> hum. i might do some of these later today, but i've got a small patch for mythtv to finish first
[11:23] <sebner> persia: Is a FFe for *xneur worth it? What do you think?
[11:23] <persia> sebner: Absolutely no idea.  What bugs would it close?
[11:23] <laga> so, how do i exclude a README file when using CDBS? using DEB_DH_ALWAYS_EXCLUDE?
[11:24] <persia> laga: Or include a debian/docs file containing only that you want included.
[11:26] <sebner> persia: I have to make further investigation but it seems that it won't close anything
[11:27] <RainCT> laga: bah. if you do the 2 merges anyway, you can leave it there :P
[11:27] <persia> sebner: OK.  Why should it be upgraded?
[11:27] <sebner> persia: new features as well as bug fixes ^^ and we still have a svn version
[11:27] <laga> RainCT: alright ;)
[11:28]  * sebner --> lunch
[11:28] <persia> sebner: Right.  So, go investigate the bug fixes, and decide if any of them are important.
[11:33] <up_the_irons> is it me, or does the package 'weechat' have no binaries? (i'm on hardy)
[11:34] <RainCT> up_the_irons: right.. the package is empty o_O
[11:34] <directhex> /usr/bin/weechat-curses
[11:34] <directhex> Package: weechat
[11:34] <directhex> Depends: weechat-common (= 0.2.6-1), weechat-curses (>= 0.2.6-1)
[11:34] <up_the_irons> directhex: ah, thanks!
[11:34] <persia> up_the_irons: You need to select one of the front-ends.
[11:35] <laga> i'd like to point out that it's usually a good idea to bzr push before using rm -rf
[11:35]  * laga goes to re-do five revisions or so
[11:36] <up_the_irons> persia: gotcha
[12:07] <sebner> persia: homepage is in russian and Changelog in the tarball is pretty outdated :(
[12:08] <persia> sebner: Some of us (not me) do read Russian: perhaps you could get help from someone?
[12:09] <persia> Also, the Debian changelog likely references some bugs closed: those might be helpful in determining if it's worth updating.
[12:09] <sebner> persia: kk, thx :)
[12:11] <laga> RainCT, Iulian, geser: i've corrected the problems you mentioned. http://revu.ubuntuwire.com/details.py?upid=3598
[12:11] <laga> no, i won't offer more merges now
[12:17] <Iulian> I forgot to count, how many do you have until now?
[12:17] <laga> 30
[12:18] <Iulian> Bleah, that's nothing :)
[12:18] <laga> hah
[14:05] <RainCT> Bah, I hate #ubuntu. Every time I go there for help I end up answering questions instead of getting an answer to mine XDD
[14:05] <sebner> RainCT: xD xD xD
[14:12] <k0p> hehe
[14:12] <k0p> :)
[14:13] <persia> RainCT: Ask a question.  I've had *much* better answers in questions than on #ubuntu
[14:14] <RainCT> persia: you mean ask it here? If so:   I'm trying to setup polipo but it doesn't work on any computer beside that one where it is installed... http://paste.ubuntu.com/42152/plain/  Any idea what the problem could be?
[14:17] <persia> RainCT: No, I mean ask on answers.launchpad.net.  Check if it's a DNS issue.
[14:17] <albert23> RainCT: proxyAddress = "<IP_ADDRESS>" might help?
[14:18] <RainCT> persia: Ah OK. How could it be a problem with DNS if it's a IP?
[14:18] <RainCT> persia: err. just tried with google's IP, same problem.
[14:20] <RainCT> albert23: no, as Apache handles the request then
[14:21]  * RainCT files a question. persia, albert23: thanks
[14:23] <persia> RainCT: Although it's not the issue, if you happened not to have working DNS on that machine, it might not be able to pass the request properly.
[14:25] <RainCT> persia: Ah. Doesn't polipo have it's own DNS resolver?
[14:27] <persia> RainCT: I don't know, and I don't know how w3m interacts with a proxy, and I don't know if an issue with DNS would be with the polipo server or with the client.
[14:28] <persia> That said, it's always a good thing to check first when trying something with a name doesn't work :)
[14:30] <tuxmaniac> persia: i had done that. I wanted to verify whether the format pasted here -> http://paste.ubuntu.com/42076/ is correct before uploading to REVU
[14:31] <tuxmaniac> persia: oops
[14:31] <tuxmaniac> persia: now I realise why you gave that. :-) pasted wrong copyright file :P
[14:32] <tuxmaniac> persia: sorry for the trouble. here is updated link http://paste.ubuntu.com/42160/
[14:33] <persia> tuxmaniac: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[14:34] <persia> Alternately: http://wiki.debian.org/Proposals/CopyrightFormat
[14:34] <persia> Something in-between is not ideal.
[14:46] <laga> persia: i'm looking at rcbugs now
[14:47] <laga> persia: acl2 is fixed in debian (was FTBS), but it's also a new upstream version. should i request a sync/merge anyways?
[14:50] <persia> laga: Well, you'll have to figure that out, but I'll look at this one with you, and you can use the same methods for the rest.
[14:51] <persia> First, we ought look at Debian bug #494328 to make sure we understand the issue
[14:52] <persia> It appears that this was originally filed as a FTBFS bug, so we can check the build status of acl2.  I tend to look at http://qa.ubuntuwire.com/ftbfs for a quick overview of build failures.
[14:53] <persia> It doesn't appear there, so we can look at the launchpad page: https://launchpad.net/ubuntu/intrepid/+source/acl2/3.3-1.1
[14:53] <persia> As you can see, it built fine in Ubuntu, so maybe we don't have that issue.
[14:54] <laga> hum.
[14:55] <persia> Another good thing to check is the Debian changelog: I usually get it from pacakges.qa.debian.org: so we visit http://packages.qa.debian.org/a/acl2.html to see what else was fixed.
[14:56] <persia> This says that it also fixed Debian bug #482594 but I don't think we need to worry about that, as we're not enforcing the new source format for intrepid.
[14:56] <laga> yes, they've fixed another FTBS there
[14:56] <laga> so they fixed two FTBS which don't seem to affect intrepid. and the new upstream release can't happen because we're in feature freeze
[14:57] <persia> There's also an open bug in Ubuntu, but it's unrelated: you might check if that was fixed either in the current version or in the new upstream version while you're inspecting the package.
[14:58] <persia> Now, it's only 5 days old, and Debian is frozen, so we might look for a mail requesting a freeze exception, but first let's look at the upstream changelog to see what happened there.
[14:58] <persia> Upstream has a homepage at http://www.cs.utexas.edu/users/moore/acl2/
[14:58] <persia> There's a nice "Differences with 3.3" link.
[15:00] <persia> While my lisp is lousy, and I've never used ACL2, none of the described bugfixes look critical to me.
[15:00] <persia> Now, for the freeze exception request.
[15:01] <persia> The Debian Release team mailing list has an overview page at http://lists.debian.org/debian-release/
[15:01] <persia> Since the package upload is 5 days old, we want to look in the August 2008 archives.
[15:02] <laga> nothing.
[15:04] <persia> Right.  So that means that the fixes are two FTBFS bugs that don't affect Ubuntu, some stuff upstream, but nothing that seems to indicate it's exceedingly urgent according to upstream, and nothing that closes any Debian or Ubuntu bugs.
[15:04] <persia> It also means that the Debian Maintainer doesn't think this update is sufficiently essential it must be in Lenny.
[15:04] <persia> So, based on that, do you think it's worth a sync or a merge?
[15:04] <laga> no.
[15:05] <persia> That'd be my thought too.  So, comment why it's not important on the rcbugs page, and pick the next package.
[15:05] <laga> alright, thanks a lot. that was very helpful
[15:05] <persia> Any questions about the investigation process to understand how to get information necessary to make the decision?
[15:06] <laga> no, i think i can find my way around
[15:07] <persia> laga: Just one thing: sometimes a package isn't rebuilt for each release.  In this case, the intrepid version is different than the hardy version, so we know we built it in intrepid.
[15:07] <persia> If the hardy and intrepid versions are the same, and it's an FTBFS bug, it's worth building in a local chroot to verify that it didn't become FTBFS with the changes in the toolchain.
[15:07] <laga> persia: can you give me a quick (fake) example?
[15:07] <laga> ah.
[15:10] <persia> https://launchpad.net/ubuntu/+source/bing has never been updated or recompiled in Ubuntu since the first import.
[15:11] <persia> You can see that fairly clearly from the "Version history" report :)
[15:12] <laga> indeed ;)
[15:14] <persia> So, despite the fact that we have bing binaries built, we have no idea if bing builds today (although it was successful three weeks ago (because it's not listed at http://builder.ubuntuwire.com:9998/dist/intrepid/arch/i386/failed)
[15:31] <laga> i wonder if there are greasemonkeys scripts to make the ubuntu wiki more.. usable
[15:37] <persia> laga: How is it not usable?
[15:38] <laga> persia: i find it hard to navigate. mediawiki always has a menu on the left
[15:38] <laga> maybe some kind of menu tree would be nice
[15:39] <persia> Indeed, and implementing that *in* the wiki would be vastly better than using a greasemonkey script.
[15:39] <laga> haha :)
[15:39] <persia> Mind you, you probably want to talk about it on some mailing list (not sure which) beforehand.
[15:39] <laga> um, that'd probably qualify as a "long time goal"
[16:17] <tuxmaniac> it will be great if someone reviews the package http://revu.ubuntuwire.com/details.py?package=gresistor and givees their valuable comments. I am planning to rise a exception for the same.
[16:17] <tuxmaniac> reason for the delay is upstream just responded and updated the source tarball with the full copy of the license
[16:42] <Adri2000> zul: what happened to the fail2ban sru? it's hasn't even been accepted into -proposed it seems?
[16:46] <Adri2000> zul: or rather, have you uploaded it?
[16:50] <devfil> ScottK: ping
[18:59] <porthose> I am updating a package, I have a diff.gz of the new package do I just attache that to an update bug in launchpad and follow the FFE process?
[19:02] <dmoerner> porthose, if this is just a bug fix, make a debdiff. if it's an upstream update, then make an interdiff
[19:02] <dmoerner> https://wiki.ubuntu.com/MOTU/Contributing
[19:03] <porthose> dmoerner: thx :)
[19:04] <persia> porthose: dmoerner: That page is actually out of date (I'll fix it now).  For an upstream update, yes, please only attach the updated diff.gz
[19:05] <dmoerner> persia, thanks for the heads up
[19:05] <tuxmaniac> Any idea how to find whether a particular emacs mode is already packaged or not? pardon me if its really stupid.
[19:06] <azeem> tuxmaniac: maybe search for the filename?
[19:07] <tuxmaniac> azeem: apt-cache search does not yield the result. Checked in the -goodies package. Not there. But there are several other extras also.
[19:07] <tuxmaniac> azeem: check for the filename where?
[19:08] <azeem> packages.ubuntuc.om
[19:08] <azeem> eh, packages.ubuntu.com, or apt-file
[19:20] <tuxmaniac> anybody using emacs willing to give me some small test feedback? Please open emacs and check whether vhdl-mode is installed by default. thanks in advance.
[19:44] <NCommander> tuxmaniac, how can I check?
[19:44] <NCommander> (I have emacs installed, but I really don't know it)
[19:57] <tuxmaniac> NCommander: just press Alt + x
[19:57] <tuxmaniac> and type vhdl <press tab>
[19:57] <tuxmaniac> if it auto completes then it is installed
[19:58] <NCommander> It's installed by default on intrepid
[19:58] <tuxmaniac> hmm. then bug 258867 is invalid. :-)
[19:59] <NCommander> yay
[20:00] <tuxmaniac> NCommander: hehe it was me who rised it. and then realised it is already there today
[20:00] <tuxmaniac> but wanted another tester :-) thanks a lot
[20:01] <NCommander> heh
[20:01] <NCommander> No problem
[20:01] <NCommander> I used to play with VHDL back in the day
[20:01] <NCommander> I have a new embedded Coldfire board I'm playing with now
[20:01] <tuxmaniac> NCommander: the funny thing is someone in fedora actually packageed it *again* only to later find today that it is already in as part of emacs-common
[20:02] <tuxmaniac> I am the culprit there too. I rised the wishlist request there also
[20:02] <tuxmaniac> I am feeling bad for such low quality bug report from my side
[20:02]  * NCommander hits tuxmaniac with a blunt object
[20:02] <NCommander> :-)
[20:03] <NCommander> Don't worry, we all have our off days
[20:03] <NCommander> What embedded architectures do you work on tuxmaniac ?
[20:03] <tuxmaniac> my be OT on this channel. can we take it on pm?
[20:03] <NCommander> This channel goes OT all the time, but sure
[20:06] <james_w> hi NCommander, were you secretary for the motu-release meeting?
[20:06] <NCommander> I was, but I had to leave half way through
[20:06] <NCommander> d'oh, I said I was going to write notes
[20:07]  * NCommander gets right on that
[20:07] <james_w> thanks
[21:50] <jpds> james_w: Do you know much on how launchpadlib works?
[21:51] <james_w> jpds: a little
[21:51] <james_w> jpds: not so much the internals though
[21:51] <jpds> james_w: I don't know why, but I keep getting: "launchpadlib.errors.HTTPError: HTTP Error 401: Unauthorized", when I do: "user = launchpad.me"
[21:51] <james_w> you have set up the OAuth credentials correctly?
[21:52] <jpds> Yes, and written them to ~/.launchpadlib/ubuntu-dev-tools/credentials.txt
[21:52] <jpds> credentials.load(open(lpCredentials))
[21:52] <jpds> launchpad = Launchpad(credentials, EDGE_SERVICE_ROOT)
[21:53] <jpds> I don't understand how launchpad.me does not work with that.
[21:55] <jpds> I can do: launchpad.people["jpds"] - just fine tho.
[22:09] <james_w> jpds: I'm not sure, sorry, #launchpad might be able to help
[22:10] <jpds> james_w: Tried there, noone was around, but I guess it's !weekend.
[22:10] <james_w> jpds: I expect so
[22:14] <jpds> james_w: I'll try again tomorrow.
[22:26] <alex-weej> does anyone know if there's some way for me to install files to a system as if it was from a deb but without the deb?
[22:26] <toobaz3> what  do you mean for "as if"?!
[22:27] <alex-weej> i.e. so i can track the files and uninstall them as if it was a package
[22:27] <alex-weej> well i am thinking for things like Unreal Tournament from disc
[22:27] <alex-weej> i don't want to have to build an intermediate deb file that is 4 GB big
[22:27] <toobaz3> m
[22:27] <toobaz3> I see
[22:27] <directhex> yes
[22:27] <directhex> look at how flashplugin-nonfree works
[22:28] <directhex> or quake2-data from debian (AFAIK it's not in ubuntu)
[22:28] <alex-weej> flashplugin-nonfree does not track the files it downloads
[22:28] <toobaz3> alex-weej: sure?
[22:28] <toobaz3> I think it does remove the plugin if removed
[22:28] <alex-weej> yes but it does it itself as postinst prerm
[22:28] <toobaz3> right
[22:28] <alex-weej> so if you do a dpkg -S on any of the files
[22:29] <alex-weej> it won't work
[22:29] <alex-weej> it would be cool if flashplugin-nonfree did it the way i am suggesting instead
[22:29] <alex-weej> much like how Gentoo Ebuilds work
[22:30] <toobaz3> can it be done with the actual infrastructure?
[22:30] <toobaz3> maybe with a placeholder
[22:30] <alex-weej> with DPKG, that is what i am asking here
[22:30] <alex-weej> :)
[22:30] <toobaz3> actually
[22:30] <toobaz3> maybe
[22:30] <alex-weej> i wonder how alien does it...
[22:30] <toobaz3> you can, with a simple script
[22:30] <alex-weej> afaik it installs RPMs to the system as if it was a Deb
[22:30] <toobaz3> make a file hierarchy
[22:31] <toobaz3> but touch - instead of copying - every
[22:31] <toobaz3> file
[22:31] <toobaz3> and then add a "cp" for every file in the "install" target
[22:31] <alex-weej> doesn't the dpkg manifesto know, say, the hashes of the files it installs?
[22:31] <toobaz3> I don't think so
[22:32] <alex-weej> lame
[22:32] <toobaz3> files can be edited
[22:32] <toobaz3> (config files, i.e)
[22:32] <toobaz3> anyway
[22:32] <toobaz3> this would work, I think
[22:33] <alex-weej> well i am actually asking with view to writing a blueprint
[22:33] <toobaz3> but probably it's more work than just make a list of the files you  copy
[22:33] <alex-weej> so hacks, though interesting, aren't much use :)
[22:33] <toobaz3> and then remove every file on the list
[22:33] <toobaz3> exactly
[22:33] <toobaz3> well
[22:33] <toobaz3> it would be of use
[22:34] <toobaz3> if you plan to redistribute it to people already owning original files
[22:34] <alex-weej> i am thinking it would be possible to build some sort of hook into the process between the deb file extraction and the installation where more files can be added
[22:34] <toobaz3> frankly, I don't know
[22:34] <toobaz3> maybe in some pre-installation script
[22:34] <toobaz3> but I'm ignorant about it
[22:39] <toobaz3> hey, MOTUs, https://wiki.ubuntu.com/MOTU/Contributing says "Add the patch tag to the bug" if I post a patch... but can it be done from a normal user?!
[22:39] <james_w> toobaz3: it can
[22:39] <toobaz3> well... so I'm blind?
[22:39] <toobaz3> (yes, I am)
[22:39] <toobaz3> how?
[22:40] <james_w> if you click the "edit" link next to the title of the bug there will be a text entry for entering tags
[22:40] <toobaz3> wow
[22:41] <toobaz3> thanks
[23:14] <NCommander> ScottK, I take it you don't like the idea of having all packages in bzr?
[23:47] <toobaz3> tuxmaniac: finally had time to comment gperiodic (I do comment occasionally on REVU, but I have absolutely no authority, I'm not MOTU)


[02:47] <tvansteenburgh> rsynnest: ping
[02:54] <rsynnest> tvansteenburgh: hey!
[02:54] <rsynnest> was the github outdated?
[02:54] <tvansteenburgh> hey, see my email?
[02:54] <tvansteenburgh> yeah, updating now...
[02:55] <rsynnest> awesome, thanks man
[02:56] <tvansteenburgh> rsynnest: my pleasure! just pushed the changes if you wanna have another go
[03:14] <rsynnest> tvansteenburgh: no luck :/
[03:14] <rsynnest> would running in a python virtualenv have any effect on the charm?
[03:16] <rsynnest> like maybe python dependencies aren't accessible?
[03:19] <tvansteenburgh> rsynnest: same traceback?
[03:21] <rsynnest> not sure, I'll check. It did fail on install hook
[03:28] <tvansteenburgh> rsynnest: if it's the same, while you're in debug hooks, try running `add-apt-repository -y ppa:chris-lea/node.js`, since that appears to be where it failed the first time
[03:41] <rsynnest>  add-apt-repository: command not found
[03:41] <rsynnest> both software-properties-common and python-software-properties are installed
[03:42] <tvansteenburgh> wha...
[03:45] <tvansteenburgh> apt-get install apt-file -y
[03:45] <tvansteenburgh> apt-file search add-apt-repository
[03:47] <rsynnest> dope, i forgot the debug-hook runs on the unit's machine
[03:47] <tvansteenburgh> :)
[03:47] <rsynnest> i have add-apt-repo local but not on the machine
[03:50] <rsynnest> that did the trick
[03:51] <rsynnest> XD
[03:51] <rsynnest> thanks for the help!
[03:51] <tvansteenburgh> so what did you have to do?
[03:51] <tvansteenburgh> install add-apt-repo?
[03:51] <rsynnest> just installed software-properties-common to the meteor machine
[03:52] <tvansteenburgh> okay, cool, i'll get the charm updated
[03:53] <tvansteenburgh> thanks for helping make the charm better rsynnest!
[03:54] <rsynnest> np, thanks for being so responsive
[03:54] <rsynnest> errr hang on
[03:54] <rsynnest> next hook is failing lol
[03:55] <tvansteenburgh> k, paste me a trace when you have it
[03:55] <rsynnest> how did you know it was the add-apt that was causing the issue?
[03:55] <tvansteenburgh> saw it in your traceback in the email
[03:55] <rsynnest> http://paste.ubuntu.com/9484186/
[03:57] <tvansteenburgh> hrm, did you run the install hook again after installing those deps?
[03:57] <rsynnest> yeah
[03:58] <rsynnest> im still in the same debug-hook shell
[03:58] <tvansteenburgh> `which mrt`
[04:02] <tvansteenburgh> rsynnest: what's the output of `which mrt`
[04:02] <rsynnest> oh, it returns nothing
[04:03] <rsynnest> wasn't sure if that was you thinking you were in termie :)
[04:03] <rsynnest> ls
[04:03] <tvansteenburgh> ha
[04:05] <tvansteenburgh> i'm not sure how install succeeded if we don't have that
[04:11] <rsynnest> ahhhh sorry
[04:11] <rsynnest> i re-ran install and it does fail at the end, i missed it
[04:11] <rsynnest> Unusable architecture: armv7l
[04:11] <rsynnest> Meteor only supports i686 and x86_64 for now.
[04:11] <rsynnest> dang
[04:12] <tvansteenburgh> doh!
[04:12] <tvansteenburgh> bummer :)
[04:12] <rsynnest> well, if anyone asks now you know
[04:13] <rsynnest> sorry for the wild goose chase :P
[04:13] <tvansteenburgh> np at all, it was helpful
[04:14] <tvansteenburgh> hope you stick around juju anyway!
[04:14] <rsynnest> welp, time to go bug the meteor folks ( ͡° ͜ʖ ͡°)
[04:14] <tvansteenburgh> hehe
[04:15] <tvansteenburgh> time for me to call it a night, cya around rsynnest
[04:15] <rsynnest> peace man, thanks again for the help
[04:15] <tvansteenburgh> you bet!
[09:18] <Saviq> hey all, I seem to have my mysql unit stuck in "installed" (and now in "dying" after trying to destroy it), what could I do to debug?
[09:20] <Saviq> forced the machine out, trying again
[09:28] <Saviq> so yeah mysql permanently gets into "installed" state for me
[09:28] <Saviq> oh now it ran!
[09:28] <Saviq> ok /me shuts up
[14:25] <jcastro> hey everyone, we're a video game: http://www.jujuandpeyo.com/
[15:53] <lazyPower> Congrats tvansteenburgh on your first charm promulgation since becoming a ~charmer!
[15:53] <lazyPower> may the users of meteor rejoyce in happyness as you have delivered their nectar
[15:53] <tvansteenburgh> \o/
[15:54] <lazyPower> mbruzek, marcoceppi_, dpb1, niedbalski ^ :)
[15:55] <mbruzek> cheers tvansteenburgh
[15:55] <niedbalski> tvansteenburgh, congrats!
[15:56] <ejat> congrats
[16:04] <jose> congratulations, tvansteenburgh!
[16:05] <lazyPower> oo sorry about the miss jose ;D i thought you were at uni
[16:06] <jose> lazyPower: told ya, I'm on vacation until April
[16:06] <lazyPower> nice
[16:10] <ejat> jose : have u finish the limesurvey charm test ?
[16:10] <jose> ejat: I'm poking on some critical stuff right now, but I did take a peek yesterday. looks like it's more than just that dependency, but I'll see what I can do
[16:12] <ejat> ok thanks :)
[17:45] <jose> marcoceppi_: hey, your seafile tests will depend on a fix that I'm pushing for review now
[17:48] <jose> marcoceppi_: also, the revq is not deleting some of the old closed/deleted MPs/charms
[18:39] <thebozz> Hey guys, we're trying to install Juju + Openstack on top of MAAS. The auto-install fails with this error log: http://pastebin.com/EWAwCEuN ... what could be wrong? We can SSH into our nodes.
[19:06] <aisrael> sebas5384: what platform are you using sshuttle on?
[19:08] <sebas5384> aisrael: using redir or iptables because sshuttle is too slow :(
[19:09] <aisrael> sebas5384: I have a workaround for sshuttle, but I've only tested it with OS X/Vagrant
[20:11] <thebozz> Hey guys, we're trying to install OpenStack on top of MAAS using the ubuntu tutorial (http://www.ubuntu.com/download/cloud/install-ubuntu-openstack).  We're currently on step 4, but it keeps failing with this error: http://pastebin.com/EWAwCEuN
[20:38] <lazyPower> thebozz: interesting - seems like possibly the keys didn't make during the bootstrap - have you retried teh provisioning? and is it consistent?
[20:39] <thebozz> lazyPower: we haven't reprovisioned. Yes, the error is constant. Should we try with a reprovision?
[20:39] <lazyPower> thebozz: i would give that a go and see if its intermittant failure, or if there are larger issues at play here.
[20:40] <thebozz> lazyPower: wait, you mean the SSH keys you configure on MAAS? We can connect to each node using SSH using the ubuntu user, so if that's what you meant then it's working fine.
[20:40] <lazyPower> thebozz: thats what i was referring to
[20:41] <thebozz> Hmmm. Then the keys are fine. What else could cause this? What user does juju try to connect to the nodes as?
[21:10] <lazyPower> thebozz: the ubuntu user
[21:11] <thebozz> lazyPower: so the login itself shouldn't be an issue either. I'm completely stumped with this one.
[21:11] <lazyPower> this is troublesome to me, as juju loads its own set of ssh keys with maas that it then uses to connect to the nodes.
[21:11] <lazyPower> thebozz: i'm not 100% familiar with the new 'autopilot' installer however
[21:12] <lazyPower> teh last time I did this, it was still a mostly manual process until you got to juju being bootstrapped.
[21:12] <lazyPower> thebozz: I would recommend pinging in #maas as well, someone may have some insight as to what the problem might be - but i beleive its after hours for them, quite a few of them are UK based.
[21:12] <thebozz> Still worth a try, though. Thanks!
[23:28] <dannf> is there some kind of 2 minute timeout during an install hook - e.g. between lines of stdout? i have a git clone that always fails around then, but if i juju ssh in, i can clone just fine