[04:36] <caldwell_> in both breezy linux kernel-amd64 image packages, my amd64 system won't boot because the initrd img doesn't have libc.so.6 in the correct directory
[04:36] <caldwell_> is this a known issue?
[04:37] <caldwell_> it happens in both 2.6.11 and 2.6.12 breezy packages
[06:43] <fabbione> morning
[10:42] <doko> fabbione: can the amd64 kernels handle >= 4GB machines?
[10:42] <fabbione> doko: no
[10:43] <fabbione> none of our kernels are compiled with > 4GB support
[10:43] <doko> would it be penalty for machines with <4GB?
[10:47] <fabbione> yes
[10:47] <fabbione> it introduces an extra layer in the mm
[11:03] <doko> and with 4GB, you can only use 3,7GB or something like that. You don't have plans for >4GB support, don't you?
[11:03] <fabbione> dunno.. never used linux with more than 2GB
[11:05] <Mithrandir> well, with 4GB, it's faster to use the <4GB model than the >4GB model in most cases.
[11:06] <Mithrandir> since PAE is stinking shit.
[11:06] <doko> ok
[02:03] <zul> heylo
[02:03] <fabbione> hey zul
[02:03] <zul> hey fabbione good weekend?
[02:03] <fabbione> zul: yeaish.. you?
[02:04] <zul> yeah went to see the 40 year old virgin
[02:04] <zul> pretty funny
[02:04] <fabbione> what's that?
[02:04] <zul> its a movie that just opened up
[02:04] <fabbione> ah ok
[02:05] <zul> mainly bigoraphical with some people i use to work with :)
[02:07] <zul> thats a bad joke..
[02:08] <fabbione> was it a joke?
[02:08] <zul> meh...too early
[02:08] <fabbione> zul: https://wiki.ubuntu.com/UbuntuBelowZero <-
[02:08] <zul> sweet!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[02:09] <fabbione> you live in montreal, don't you?
[02:09] <zul> no im about 2 hours away
[02:09] <zul> happy happy joy joy
[03:01] <fabbione> hey BenC_
[03:02] <zul> its not that cold in canada in november anyways
[03:02] <fabbione> zul: like if we need to care :)
[03:02] <fabbione> we will be so busy that we won't get a chance to go out anyway
[03:02] <zul> true
[03:05] <chmj> we have one sunday off
[03:05] <fabbione> chmj: not distro
[03:05] <fabbione> only LP
[03:06] <fabbione> distro will be flying back on sunday
[03:06] <chmj> bah!
[03:07] <chmj> heh, true
[03:20] <Mithrandir> fabbione: it doesn't say that on the plan, it just says "day off" and I at least intend to take that in .ca.
[03:23] <fabbione> Mithrandir: i am sure you will have to pay for the hotel if you want to stay longer
[03:24] <chmj> fabbione: quick question
[03:25] <fabbione> chmj: just ask...
[03:25] <chmj> fabbione: issin't $ getconf LFS_CFLAGS suppose to return "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" instead of "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
[03:26] <fabbione> chmj: no idea
[03:26] <chmj> fabbione: becouse the second one still doesn't enable LFS support, first one does
[03:27] <chmj> doko: ping ?
[03:27] <doko> chmj: pong
[03:28] <chmj> doko: --------^ any idea
[03:29] <doko> ENOCLUE
[03:30] <chmj> ok
[03:35] <chmj> doko: I figured `getconf LFS_CFLAGS` should return ...
[03:35] <chmj> #define _LARGEFILE64_SOURCE
[03:35] <chmj> #define _FILE_OFFSET_BITS 64
[03:48] <Mithrandir> fabbione: I won. :-)
[03:49] <fabbione> Mithrandir: better you than me this time :)
[03:49] <Mithrandir> yup
[04:06] <fabbione> hey Ben
[04:06] <BenC> hey
[04:06] <fabbione> did you have a nice weekend?
[04:07] <BenC> normally I'd say yes, but no :)
[04:07] <fabbione> you need to get a better inet connection :)
[04:07] <BenC> my connection seems to be fine
[04:07] <BenC> my ssh sessions don't timeout
[04:07] <BenC> just IRC
[04:07] <fabbione> you keep pinging out
[04:07] <fabbione> ah ok
[04:08] <fabbione> BenC: can i reassing all the kernel bugs to you?
[04:08] <BenC> yeah, let me have it
[04:08] <fabbione> BenC: eheh i will do it tomorrow :)
[04:08] <fabbione> there is no rush ;)
[04:08] <fabbione> i remember there is a trick to do that in crapzilla...
[04:09] <BenC> fabbione: is there really a mac_hid module that is needed for ppc users to use apple mice?
[04:09] <BenC> I thought normal hid would work
[04:10] <fabbione> BenC: i guess you are talking about James bug, aren't you?
[04:10] <BenC> 13787
[04:10] <fabbione> that module is available on ppc32 only
[04:11] <fabbione> it's not even in the PPC64 Kconfig tree
[04:11] <BenC> what types of apple mice need that module?
[04:11] <fabbione> no clue.. i don't have a ppc at all
[04:11] <fabbione> anyway 13787 is sort of duplicate of 13826
[04:12] <BenC> it's not a driver at all
[04:13] <BenC> it's a 2+3 mouse button emulator for apple mice
[04:13] <BenC> well, not a driver in the sense that it is needed to use the mouse
[04:13] <fabbione> get ready for a 270 mails of spam from crapzilla
[04:14] <fabbione> should be done :)
[04:16] <fabbione> hmm nobody did close the bugs from 7.11???
[04:18] <ivoks> hi
[04:19] <zul> spaam spam spam
[04:19] <ivoks> :>
[04:20] <zul> hey...you changed some of my bugs as well..
[04:20] <ivoks> who?
[04:21] <fabbione> zul: i did it in a batch...
[04:21] <fabbione> sorry.. take them back and coordinate with BenC
[04:22] <zul> ok..
[04:24] <BenC> fabbione: I closed 13787, can 13826 be closed you think? I can't see how he enabled ADB in the PPC64 config anyway, since it seems it shouldn't be able to do so
[04:24] <BenC> maybe he used a PPC .config or something
[04:24] <fabbione> BenC: i am not sure how he managed to get there...
[04:24] <fabbione> but elmo definetely has CONFIG_PPC64
[04:25] <fabbione> no idea if he forced it there
[04:25] <BenC> oh, that's J Troup's bug?
[04:25] <BenC> should be closed by default then :)
[04:25] <fabbione> ahhaha
[04:25] <fabbione> PEBAK KTHXBYE
[04:25] <fabbione> :P
[04:27] <BenC> fabbione: weird, if I do "make menuconfig ARCH=ppc64" it let's me choose ADB and ADBHID options
[04:36] <fabbione> yeah.. but the mac stuff in that dir is not for ppc64 afaik
[04:36] <fabbione> it doesn't build at all
[04:36] <fabbione> nothing in that dir does
[04:37] <BenC> there are a couple of G5 things in there
[04:37] <BenC> SMU and         tristate "Support for thermal management on PowerMac G5"
[04:37] <fabbione> hmm we do build SMU
[04:37] <BenC> mostly it's ADB stuff
[04:37] <fabbione> it's mandatory for ppc64
[04:38] <BenC> yeah, IMO it should be "default y" and depend PPC_PMAC64
[04:38] <fabbione> possibly.. my ppc64 knowledge is quite limited to what benh tells me
[04:40] <BenC> looks like the email flood stopped
[04:41] <fabbione> yeah
[04:41] <fabbione> we need to check other pkgs/status too
[04:41] <fabbione> like PENDINGUPLOAD
[04:41] <fabbione> i don't think the search i did got them
[04:42] <fabbione> oh teh one assigned to kernel-package
[04:44] <fabbione> I HATE CRAPZILLA
[04:47] <fabbione> little more spam.. 10 mails.. no more
[04:50] <fabbione> hey jammcq
[04:50] <jammcq> fabbione: just got the bugzilla email
[04:50] <jammcq> thanks for adding FUSE to the kernel
[04:50] <fabbione> oh that was done a long ago...
[04:50] <jammcq> will make LOTS of ltsp folks happy
[04:50] <fabbione> i noticed only now because the bug was against kernel-package
[04:50] <fabbione> whilst it should have been linux :)
[04:50] <fabbione> but it has been in the kernel for while
[04:50] <jammcq> oh
[04:50] <jammcq> cool
[04:51] <fabbione> i think it was done the kernel immediatly after you asked for it in irc..
[04:51] <jammcq> that's what I like... I ask for things, and they happen :)
[04:52] <fabbione> jammcq: i am glad it will be helpful :)
[04:52] <fabbione> jammcq: don't ask for money or sex.. i am running out myself ;)
[04:52] <jammcq> damn
[04:52] <BenC> jammcq: you work with ltsp?
[04:52] <fabbione> jammcq: of course fuse will cost you a beer ;:P
[04:52] <jammcq> ok, i'll think of something else
[04:52] <jammcq> BenC: yeah, it's my project
[04:52] <fabbione> BenC meet jammcq, jammcq meet BenC
[04:52] <jammcq> hello benc
[04:53] <fabbione> jammcq: BenC is the new kernel maintainer as of today .)
[04:53] <jammcq> ah, cool
[04:53] <BenC> jammcq: do you know if matt's changes to use bindfs overcame the problems with unionfs being broken in the latest kernel?
[04:53] <jammcq> fabbione: where are you going?
[04:53] <zul> im still a flunky
[04:53] <fabbione> BenC: yes. he doesn't use unionfs anymore.. hence my proposal to kill it from the kernel
[04:53] <fabbione> jammcq: back to userland...
[04:53] <BenC> fabbione: gladly
[04:53] <jammcq> BenC: hmm, dunno.  matt's methods are different from standard LTSP.  But, once the bugz are worked out, we'll prolly adopts the ubuntu way
[04:54] <jammcq> fabbione: Ubuntu-userland?
[04:56] <fabbione> jammcq: yup :)
[04:58] <jammcq> cool. I look forward to see all you guys at the next ubuntu mtg.  Looks like we'll have a bunch of ltsp guys there this time
[04:59] <fabbione> jammcq: https://wiki.ubuntu.com/UbuntuBelowZero <-
[05:00] <desrt> woh.  score
[05:00] <desrt> that's a long conf.
[05:01] <desrt> BenC; blame fabbio :)
[05:01] <fabbione> i bleam GTK
[05:01] <fabbione> blame
[05:01] <desrt> you always blame GTK
[05:01] <desrt> you need something new
[05:02] <fabbione> i blame desrt and all the stupid lusers that buy broken hw
[05:02] <desrt> i did a build-dep for the restricted modules source the other day and it installed qt.... i think you should blame qt
[05:02] <desrt> *glare*
[05:02] <chmj> rather blame glibc
[05:03] <desrt> mm.  glibc is a nice easy target
[05:03] <jammcq> fabbione: ah, nice to see a webpage for UBZ. I guess that means its official. Montreal is easy for us to get to.
[05:03] <fabbione> jammcq: it will be official soon
[05:03] <fabbione> don't rely on that info 100% yet
[05:04] <jammcq> k
[05:04] <fabbione> iirc the announcment will be done today or tomorrow...
[05:14] <zul> its not that cold in noevember
[05:14] <zul> just buy some long underwear
[05:14] <zul> but it is a culture shock coming from south africa to canada in winter
[05:15] <zul> been there...done that
[05:32] <jammcq> jbailey: hey, just the guy I need to talk to
[05:33] <jbailey> jammcq: I'm lagging a bit, I'm just on the phone.
[05:33] <jammcq> ok, when you get a chance, I've got some questions about the initramfs image for the ubuntu/ltsp kernels.  Like... is it using busybox?
[05:34] <jbailey> It is.
[05:34] <jbailey> Feel free to /msg me a series of questions and I'll get them as I have brain space in this call.
[05:34] <jammcq> k
[05:37] <zul> BenC: do you want to divy up the x86 bugs?
[05:37] <zul> hey jeff
[05:39] <BenC> zul: you can feel free to attack whatever bugs you feel you can
[05:39] <BenC> it'll be awhile before I can even go through them all and see which are still valid
[05:39] <zul> ok cool...
[07:19] <BenC> mjg59: ping
[07:20] <mjg59> BenC: Hi
[07:20] <BenC> mjg59: hey, have you seen bug 13786 yet?
[07:21] <BenC> I'm inclined to assign it to you and usplash
[07:21] <mjg59> Yeah
[07:21] <mjg59> Uh
[07:21] <mjg59> It's not a usplash issue
[07:21] <mjg59> The framebuffer doesn't work in the installer, either
[07:21] <BenC> thing is, vga16fb is known not to work on all hardware, especially laptop/lcd situations
[07:21] <BenC> well, true
[07:22] <mjg59> The issue is that the installer doesn't communicate that to the installed system
[07:22] <BenC> problem is that he removed splash and added vga=normal to the grub conf, and it still loaded vga16fb
[07:22] <BenC> atleast that's what the reporter claims
[07:22] <mjg59> Yes, that's initramfs
[07:23] <mjg59> if you include modules, they get autoloaded
[07:23] <mjg59> I need to check if jeff's fixed that yet
[07:23] <jbailey> mjg59: Hmm?
[07:23] <jbailey> It depends on how you include them.
[07:23] <jbailey> Anything in modules.d gets auto loaded.
[07:23] <mjg59> jbailey: Ah. I don't think I've had a chance to look at it since you provided an alternative mechanism
[07:23] <jbailey> You can do things conditionally with hook scripts now at build time.
[07:23] <mjg59> Ok
[07:24] <jbailey> Take a look at /usr/share/initramfs-tools/hooks/
[07:24] <mjg59> So yeah, there's a multitude of bugs here:
[07:24] <BenC> so remove modules.d/usplash
[07:24] <mjg59> 1) vga16fb is broken on some hardware and probably shouldn't be
[07:24] <jbailey> The two interesting functions are "manual_add_modules" which adds the module to the initramfs but doesn't load it.
[07:24] <mjg59> 2) the installer doesn't usefully tell the system that the framebuffer is broken
[07:24] <jbailey> and force_load which adds the modules to the initramfs and does load it.
[07:24] <mjg59> 3) usplash is including modules the wrong way
[07:25] <BenC> how can the installer know that the framebuffer is broken?
[07:25] <BenC> if they disable it from the command line?
[07:25] <mjg59> Yes
[07:26] <BenC> what's the name of the installer package?
[07:27] <mjg59> debian-installer
[07:27] <BenC> how does "splash" get added to grub.conf?
[07:27] <jbailey> It seems to have been there for ages.
[07:27] <mjg59> It's put there by default
[07:27] <BenC> ok
[07:27] <mjg59> Either d-i or grub, I guess
[07:28] <jbailey> Yeah, it's there even in Hoary.
[07:30] <BenC> ok, filed a bug for debian-installer
[07:30] <BenC> even if it's a grub default, the installer should be responsible for overriding it, IMO
[07:31] <BenC> mjg59: you have a bug for the module loading problem?
[07:31] <BenC> in usplash
[07:34] <mjg59> BenC: Not filed
[07:34] <BenC> want me to file one?
[07:35] <mjg59> Plesae
[07:39] <BenC> filed as 13980
[09:50] <zul> #7948 is more of a alsa/gnome problem me thinks
[09:55] <zul> hey BenC gotta a question for you
[09:55] <zul> #7948 is more of a user space problem rather than a kernel problem isnt it?


[02:43] <kgunn> Saviq: still rotating & still seeing apps launch as mobile mode with that silo rebuild
[08:39] <tsdgeos> cimi: please remember of https://code.launchpad.net/~aacid/unity8/dash_reset_instead_of_fatal/+merge/274363
[10:19] <Saviq> greyback__, hey, had to pull Alan's branch from the silo, it doesn't build
[10:20] <greyback__> Saviq: conflicts? or ftbfs?
[10:20] <Saviq> greyback__, the latter
[10:20] <greyback> ok
[10:20] <Saviq> ah, Alan's just pushed a commit, let's see what ci says
[10:21] <Saviq> greyback, ↑
[10:21] <greyback> ack
[10:24] <Saviq> greyback, I also had to add --fail-missing back to qtmir-gles, not happy about it but meh, we'd need a custom target to install just the qpa plugin
[10:25] <greyback> ok
[10:33]  * tsdgeos finds and interesting bug/behaviour regarding bindings and properties
[10:33] <tsdgeos> will put a test up for people to confirm i'm not seeing ghosts in a minute
[10:36] <tsdgeos> Can you guys try http://paste.ubuntu.com/12988339/ and confirm that rect2 width is evaluated on every resize
[10:36] <tsdgeos> but that if you change cardWidth from var to real it is not evaluated on every resize anymore?
[10:36] <tsdgeos> @unity: ↑
[10:38] <mzanetti> tsdgeos, confirmed
[10:38] <mzanetti> don't ask me why tho
[10:39] <tsdgeos> mzanetti: i guess the engine stores var as an object and every "set" is a different object which maens the object changed even if the inner value is the same
[10:39] <tsdgeos> random guess
[10:40] <tsdgeos> this is good since this fix makes lots of reevaluations on the dash go away
[10:41] <mzanetti> nice!
[10:41] <mzanetti> yes, it does sound like it can't do an optimization with var
[10:41] <mzanetti> and iirc I've read somewhere that using property var is said to be slow, likely for this reason
[10:53] <Saviq> tsdgeos, nice one
[10:56] <Saviq> greyback, ok, put the test harness back, ci liked it
[10:56] <greyback> thanks!
[10:57] <cimi> mmm am I missing something? I just reinstalled rc-proposed on my krillin, and cannot enable developer mode from the system settings
[10:58] <cimi> I tap enable, but if I close and reopen system settings is always off
[11:01] <Saviq> cimi, any interesting logs in ~/.cache/upstart/*settings* ?
[11:02] <cimi> Saviq, I am flashing with --developer-mode, impatient
[11:02] <Saviq> cimi, --developer-mode only enables adb-when-locked, really
[11:03] <cimi> ah
[11:03] <Saviq> so likely won't have any impact
[11:10] <cimi> Saviq, it actually enabled adb out of the box
[11:10] <cimi> yay \o/
[11:10] <Saviq> right
[11:19]  * Saviq loves adt-run
[11:19] <Saviq> adt-run unity8 -o vivid --setup-commands "apt install --yes software-properties-common; apt-add-repository --yes --enable-source ppa:ci-train-ppa-service/landing-021; apt update" --- schroot vivid-overlay-amd64-shm
[11:19] <Saviq> adt-run unity8 -o xenial --setup-commands "apt install --yes software-properties-common; apt-add-repository --yes --enable-source ppa:ci-train-ppa-service/landing-021; apt update" --- schroot xenial-amd64-shm
[11:19] <Saviq> lo and behold, qml tests results from a silo :)
[11:24] <Saviq> I only need moar memories
[11:33] <Saviq> cimi, om26er just reported adb issues on arale on the phone ML, maybe you can relate?
[11:37] <cimi> Saviq, ty
[11:49] <Saviq> dandrader, Josh's new-fix-upsidedown needs a re-review after resubmitting, but it seems it also introduces a regression - phone app forces external display to rotate
[11:49] <dandrader> Saviq, interesting..
[11:50] <Saviq> dandrader, could you please work on a test for this, so we don't miss it?
[11:51] <Saviq> or well, you can work on a fix, too, it's ~unity-team by now anyway
[11:51] <dandrader> Saviq, Will talk to Josh
[11:51] <Saviq> tx
[11:52] <Saviq> I'd rather not pull it out of the silo because it's become prereq for others by now
[11:52] <Saviq> but it might happen
[11:52] <Saviq> /away
[11:53] <dandrader> Saviq, ah, that explains it :)
[11:54] <cimi> Saviq, anything in particular to look in silo 21?
[11:55] <cimi> I've been testing it around lately, found minor things on my preview branches, but most likely better to fix later separately
[14:02] <attente> greyback_: hey, have you had a chance to look at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1417655
[14:16] <dandrader> attente, changes are needed in multiple places for that. for qtubuntu we have this https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-surface-apis/+merge/267228
[14:17] <greyback_> attente: hey, we have branches up which add basic support for that. But when I say basic, I mean basic. We need to add more advanced window management yet, which is next thing on my list
[14:21] <attente> ok, will it also fix it on the phone? because right now creating a second surface restarts the unity 8 session
[14:22] <dandrader> attente, there's https://code.launchpad.net/~dandrader/unity8/multiSurfaceApp/+merge/271613 for that
[14:22] <Saviq> cimi, well, any bugs/branches from https://requests.ci-train.ubuntu.com/#/ticket/564
[14:23] <Saviq> attente, "fix" in the sense that unity8 won't crash, yes, "supported", no
[14:23] <Saviq> attente, phone is supposed to be single surface per app, per design
[14:28] <attente> Saviq: i'm wondering how that's supposed to work with gtk apps which need to be able to pop up menus and dialogs
[14:32] <Saviq> attente, not really planned to be supported on the phone, again, per design
[14:35] <Saviq> attente, ultimately, when we have the window management code for desktop, we might allow some of that working on the phone, too, but that's definitely not a priority
[14:36] <Saviq> attente, apps on phone are meant to be confined to a single, full-screen window, so there's no real reason why they couldn't just render everything internally
[14:36] <attente> Saviq: ok, i guess we'll try to fake it then
[14:40] <Saviq> attente, toolkits, if they want to be cross-platform, need ultimately gain a single-surface mode, where they don't split the UI into multiple surfaces, it's not like we're the only mobile platform putting that requirement on apps
[14:41] <attente> Saviq: yeah, that's not unreasonable
[14:41] <attente> i'll try to make do
[14:53] <josharenson> greyback_: If you have a minute, can you take a look at the changes to ShellApplication.cpp in https://code.launchpad.net/~josharenson/unity8/slim_greeter_real_lightdm and let me know if you think that will present any multi monitor issues?
[14:54] <josharenson> greyback_: I know its a hack, but setting fullscreen wasn't working
[15:00] <greyback_> josharenson: am curious why fullscreen wouldn't just work
[15:00] <josharenson> greyback_: I suppose that is a better question...
[15:07] <kgunn> anyone else notice getting bt mouse to connect suddenly got wonky in latest image ?
[15:07] <kgunn> or just me
[15:08] <greyback_> josharenson: fullscreen should just be reading the geometry of the screen the window is on, and setting the window size to that geometry. As qtmir is the source of the screen geometry, it may have a problem. Can you investigate further?
[15:08] <josharenson> greyback_: sure
[15:15] <Saviq> mterry, there are DesktopStage failures in silo 21 http://pastebin.ubuntu.com/12990194/
[15:16] <Saviq> or mzanetti ↑?
[15:16] <mterry> hrm
[15:16] <mterry> might be good to determine which branch did that
[15:16] <kgunn> mzanetti: ltinkl ok, the no buttons issue is better...but then i got this (with silo21)
[15:16] <kgunn> http://www.youtube.com/watch?v=NQi33Jpv3oQ
[15:17] <mzanetti> mterry, hmm... thsoe are the ones I had after my merge
[15:17] <kgunn> might have been the rotation
[15:17] <mzanetti> hmm
[15:17] <mzanetti> kgunn, will look into it... as a temp workaround you probably want to wipe the windowstatestorage
[15:17] <mterry> mzanetti, oh shoot, I thought the test failure was in the test added by my merge, so that's all I checked after doing my rebasing
[15:18] <ltinkl> kgunn, looks like an issue with the spread
[15:18] <ltinkl> kgunn, can you alt-tab to it?
[15:18] <mzanetti> ltinkl, no... the spread is fine... the windows is located somewhere outside the screen
[15:18] <mzanetti> -s
[15:18] <ltinkl> mzanetti, aha, so the storage
[15:18] <mterry> Saviq, mzanetti: I will look at that test failure today.  I assume it isn't urgent?
[15:19] <kgunn> mzanetti: ltinkl where is the storage ? could i inspect ? and confirm it's offscreen ?
[15:19] <mzanetti> mterry, I thought those were were the ones you added :/ my bad I guess
[15:19] <mzanetti> kgunn, sqlite3 ~/.cache/unity8/windowstatestorage.sqlite
[15:20] <mzanetti> kgunn, call, ".tables" to see the available tables
[15:20] <mzanetti> and then "select * from <table>"
[15:20] <mzanetti> not sure what the name is... I think it's state
[15:20] <ltinkl> mzanetti, ew, why do we store the config in ~/.cache? :)
[15:20] <Saviq> mterry, well, getting a silo in a releasable state is generally urgent, yes ;)
[15:20]  * ltinkl was looking into ~/.config
[15:20] <mzanetti> ltinkl, because its not a config
[15:21] <ltinkl> right, you can erase it
[15:29] <Saviq> josharenson, dandrader, did you talk about the rotate-external-screen issue?
[15:29] <Saviq> kgunn, oh btw, I'm not sure what you meant by "still seeing apps launch as mobile mode"
[15:31] <dandrader> Saviq, not yet. think he just got online
[15:31] <kgunn> Saviq: well, they launch full screen, and they have no buttons present in the panel - but that seems fixed now
[15:31] <kgunn> in silo 21
[15:31] <josharenson> Saviq: no, but I was planning on looking into it today. I don't have a BT keyboard/mouse because the post office lost mine and was going to buy one today
[15:31] <Saviq> kgunn, right, that might've been due to missing qtmir rebuild
[15:32] <dandrader> Saviq, still fighting with my nexus 7. could not reproduce no a laptop with fake orientations
[15:32] <Saviq> ack
[15:33] <kgunn> Saviq: happy to consider that fixed...now just gotta stop that rotation :)
[15:34] <Saviq> ack
[15:40] <Saviq> hmm /me goes to xenial then
[15:40] <kgunn> mzanetti: actually it was 'geometry' and curious...
[15:40] <kgunn> should those values change as i click ?
[15:40] <mzanetti> kgunn, no, only when you close a window
[15:40] <kgunn> e.g. i can rerun select *
[15:41] <mzanetti> had a fight over it with daniel :D I wanted to save them all the time at first, but he didn't approve the branch :D
[15:41] <kgunn> mzanetti: fwiw dash showing geom of 0 0 0 0
[15:41] <Saviq> oups
[15:41] <mzanetti> yeah... there's something going on...
[15:41] <Saviq> wonder how that happened
[15:41] <mzanetti> kgunn, if you happen to find a way to reproduce, that'd be great
[15:41] <mzanetti> I'll dig into it
[15:41] <kgunn> k, will continue to break things
[16:18] <mterry> mzanetti, Saviq: looks like lp:~unity-team/unity8/lp1475678.surface-occlude is the branch that broke the DesktopStage tests
[16:18] <kgunn> mzanetti: yikes, i delete the windowstorage.sql and i still have no dash
[16:18] <kgunn> it's acting the same way
[16:18] <Saviq> dednick, ↑
[16:18] <Saviq> ↑↑rather
[16:21] <dednick> mterry: where is it broken? looking at the silo build
[16:22] <mterry> dednick, running xvfbtestDesktopStage
[16:23] <Saviq> @unity I think I saw someone mention broken kinetic scrolling
[16:23] <Saviq> who was that?
[16:23] <Saviq> in spread
[16:24] <kgunn> mzanetti: btw, this is odd... http://www.youtube.com/watch?v=yaSekyLd0bk
[16:24] <kgunn> i see scopes in the top left corner show up, if i kill dash when it's in this state
[16:25] <dandrader> Saviq, there's a bug about it
[16:25] <Saviq> dandrader, oh good
[16:25] <dandrader> Saviq, greyback_ is on it I think
[16:25] <Saviq> right
[16:26]  * Saviq thought the touch compression could do it, but doesn't seem like it
[16:26] <greyback_> nope, is something else
[16:26] <greyback_> dunno what yet
[16:26] <dandrader> Saviq, https://bugs.launchpad.net/qtmir/+bug/1510571
[16:26] <Saviq> dandrader, thanks
[16:30] <kgunn> ok, positive i deleted the windowstorage.sql twice now...on the second time/reboot i now have dash back
[16:33] <kgunn> hmmm...clock rotates the shell also
[16:33] <kgunn> silo21
[16:34] <Saviq> kgunn, likely same problem
[16:35] <dednick> mterry: eh. my branch passes tests, but i guess it's something in the merges
[16:36] <mterry> dednick, I just tried your branch all by itself and it failed tests
[16:36] <mzanetti> kgunn, right... is that how you reproduce it?
[16:36]  * mzanetti tries
[16:36] <Saviq> dednick, mterry, FWIW https://code.launchpad.net/~ci-train-bot/unity8/
[16:36] <mzanetti> that totally does look like it's positioning it into 0,0,0,0
[16:36] <mterry> dednick, try installing the other packages in the silo, they may be affecting you
[16:36] <Saviq> and `citrain host-upgrade 21` to get the dependencies (on vivid, or xenial)
[16:37] <mterry> Saviq, oh those pre-generated branches are nice
[16:37] <mterry> bookmarking
[16:38] <Saviq> courtesy of bug #1348531
[16:38] <greyback_> naice
[16:40] <mzanetti> Saviq, nope... The issue is happening not only in spread, also in the launcher for example... and I've tried reverting the touch compression thing too. no avail
[16:40] <mzanetti> it still seems to work for apps tho... so must be qtmir it seems
[16:40] <dednick> mterry: :/ the u8 tests shouldnt be dependent on other packages, but i'll give it a go
[16:41] <mterry> dednick, I don't know, I'm just trying to guess why it fails for me but not you
[16:41] <mterry> dednick, I'm also on xenial
[16:43] <Saviq> mzanetti, yeah indeed
[16:44] <dednick> oh. i'm on wily
[16:44] <mzanetti> good you found out :)
[16:44] <dednick> mterry: ^
[16:44] <dednick> Saviq: silos not building branches for wily?
[16:44] <mterry> dednick, I don't know if that's THE difference though.  Note that the silo builds on vivid and xenial, but not wily
[16:45] <Saviq> dednick, wily is done'n'dusted
[16:45] <dednick> sigh. i just upgraded to wily a few weeks ago!
[16:45] <mterry> dednick, what took you so long!
[16:45] <mzanetti> I'm still on v+o :)
[16:45]  * mterry shakes head
[16:45] <mzanetti> Saviq, how's xenial by now?
[16:46]  * Saviq just did `do-release-upgrade -d`, need to reboot
[16:46] <mterry> I haven't rebooted yet either  :)
[16:46] <mzanetti> ok, you guys reboot and I'll do the vivid dance
[16:47]  * Saviq does, will see you on the other side o/
[16:48] <dednick> *grumble* /me upgrades
[16:48] <Saviq> seems it didn't kill me
[16:49] <Saviq> dednick, wily was never really a target for us, just a means to not grow tech debt for when we rebase on 16.04
[16:51] <Saviq> aah my terminal has a custom byobu icon now...
[16:51] <dednick> well i guess i'll go eat something while this is happening. happy days
[16:56] <mterry> pmcgowan, I can confirm that silo 21 has odd shutdown dialog behavior.  I assume I'm the cause and am looking into it  :)
[17:15] <mterry> greyback_, QInputEvent timestamps on Mir seem... unreliable.  Looks like it's 0 for the power button press that turns off the screen.  And looks like it's overflowing easily
[17:16] <mterry> I know there's a mismatch between Mir's 64bits and Qt's ulong
[17:18] <greyback_> dandrader|bbl: that mean anything to you ^^
[17:19] <greyback_> mterry: can you noticed if the mir input event timestamps are good or not?
[17:19] <greyback_> just to identify if the qtmir workaround for the 32/64bit timestamp is broken or not
[17:19] <mterry> greyback_, I haven't checked the timestamps directly, but haven't noticed any odd behavior
[17:20] <mterry> greyback_, the workaround of dividing by 1000000?
[17:20] <greyback_> mterry: yeah
[17:21] <mterry> greyback_, Mir is in... nanoseconds?
[17:21] <greyback_> mterry: yeah
[17:21] <mterry> So if we are stuffing into 32 bit... we'd only overflow in 2032?
[17:21] <mterry> Because we use ms for Qt
[17:22] <mterry> greyback_, pressing the power button twice in a row gave me timestamps of 345,399,000 and 1,640,287,000
[17:23] <mterry> short delay between
[17:23] <mterry> (Qt timestamps) -- unless I'm reading qt timestamps wrong...
[17:23] <greyback_> yeah that's wrong
[17:23] <mterry> Let me double check my code that grabs the timestamp  :)
[17:24] <greyback_> mterry: can you set MIR_CLIENT_INPUT_RECEIVER_REPORT=log and compare the printed mir timestamps with qt's ones
[17:24] <greyback_> mterry: also set QT_LOGGING_RULES="qtmir.*.debug=true" to enable qtmir input event logging
[17:24] <mterry> k
[17:25]  * greyback_ loves category logging
[17:25] <mterry> agreed
[17:29] <mterry> greyback_, here's a log snippet:  this is me pressing the power button a few times, then holding it down: https://pastebin.canonical.com/142915/
[17:29] <mterry> greyback_, the MIKE logs are true/false if it's an autorepeat event, then the next number is the timestamp Qt shows
[17:29] <mterry> If my code isn't mucking it up
[17:30] <greyback_> mterry: looks wrong to me
[17:31] <mterry> greyback_, yeah, Qt and Mir aren't increasing at same rate
[17:31] <greyback_> timestamps should not be so huge
[17:31] <greyback_> I thought the qt timestamps are to start at 0 at program start too
[17:32] <mterry> greyback_, it seems to hit 0 multiple times for me
[17:33] <greyback_> mterry: which means we overflowed
[17:33] <mterry> greyback_, well it hits 0 back to back presses at the beginning
[17:33] <greyback_> mterry: what you testing on? pc?
[17:33] <mterry> greyback_, mako
[17:34] <mterry> greyback_, I'm not convinced my qt timestamp reporting isn't somehow bogus.  I'm using this code: https://code.launchpad.net/~mterry/unity8/shutdown-dialog-on-resume/+merge/275240
[17:35] <mterry> greyback_, is there an easy way to test this without using a modified u8?
[17:36] <greyback_> mterry: yes. If you can print the timestamps in qml, just create a simple qml file which does it. Then "stop unity8" and run that qml file instead of unity8 with MIR_SERVER_NAME=session-0 MIR_SOCKET=/run/mir_socket QT_QPA_PLATFORM=mirserver qmlscene yourQmlFile.qml
[17:37] <mterry> greyback_, the timestamp isn't exported to qml
[17:37] <mterry> That's why I had to export it myself in that branch
[17:38] <greyback_> ah boo
[17:39] <greyback_> well you can make a simple qml file that just imports that qml plugin
[17:47] <mterry> greyback_, well that doesn't solve my problem of trying to get my code changes out of the way  :)  It might be good if qtmir had a test that confirmed qt timestamps were being exported as expected
[17:48] <mterry> Just a future improvement maybe.  I'm going to see if I can workaround needing Qt timestamps for now
[17:48] <mterry> Else I'll have to dig deeper
[17:48] <greyback_> mterry: we have to fix that, please log qtmir bug
[17:49] <mterry> greyback_, oh for sure, if it's broken now, we have to fix it.  I'm just still trying to confirm it's actually broken
[17:49] <greyback_> mterry: the output you supplied has convinced me
[17:50] <mterry> Yeah but my reporting code could mess it up.  I want a nice tight cpp test or something, without so many layers.  But I can file bug while we investigate
[17:51] <greyback_> mterry: we have tests in qtmir for the compression. but something not right
[17:51]  * mterry has to run out for a sec, will file bug and look into cpp test when back
[18:43] <mterry> Ok am back
[18:47] <mterry> saviq, fyi my shutdown-dialog branch is problematic / unreliable.  If you're looking to keep silo in releasable state, might make sense to drop that for now.  I'm setting to WIP until I can root-cause it
[19:03] <Saviq> mterry, ac
[19:03] <Saviq> k
[19:18] <kgunn> Saviq: so i just caught (by sight) my n7 reboot
[19:19] <kgunn> what were some logs beside syslog to look at? or capture
[19:38] <Saviq> kgunn, logcat, but not sure how/if it's possible to find the right moment
[19:56] <mterry> greyback_, I think I found a source of timestamp confusion, and a possible fix.  Will file soon
[21:04] <Saviq> kgunn, btw, unity8 in silo21 rebuilt a few mins ago, should not rotate any more
[21:06] <kgunn> thank goodness
[21:06] <kgunn> super annoying
[22:32] <Saviq> kgunn, those "Browser" and "Scopes" strings are splash screen
[22:33] <Saviq> in a 0,0,0,0 window
[22:33] <Saviq> spinner, too, just a different version of the splash screen
[23:08] <kgunn> figured as much


[10:56] <wallyworld_> axw: hey, you seen this issue before? I'm trying to land dimiter's fix to unblock trunk
[10:56] <wallyworld_> Extant directories unknown:
[10:56] <wallyworld_>  labix.org/v2/mgo
[10:56] <axw> errm
[10:56] <axw> nope
[10:56] <wallyworld_> seems a bot scripting issue
[10:56] <axw> we shouldn't be using labix.org/v2/mgo anymore
[10:56] <wallyworld_> yup
[10:56] <axw> it's not snuck into dependencies.tsv is it?
[10:57] <wallyworld_> hmm, don't think so, i'll check
[10:57] <axw> nope
[10:57] <wallyworld_> i'll have to grep the release tools scripts, i think they print that message
[10:58] <wallyworld_> i really want to get our stuff landed, otherwise will need to make a feature branch, but if i do it off trunk now, local lxc will be broken until the fix lands
[21:14] <anastasiamac> menn0: waigani:ping
[21:32] <menn0> anastasiamac: pong
[21:57] <menn0> anastasiamac: pong (again)
[22:09] <menn0> waigani: just reviewed the FindId/RemoveId change.
[22:09] <waigani> menn0: thanks
[22:17] <anastasiamac> menn0: sorry - day off... kids running around... m missing ur answers :D
[22:17] <anastasiamac> menn0: do u know what tim changed in facade creation/calling?
[22:18] <anastasiamac> menn0: related bug 1414027
[22:18] <mup> Bug #1414027: Increment client facade or return agent version in login <juju-core:Triaged> <https://launchpad.net/bugs/1414027>
[22:18] <menn0> anastasiamac: not off the top of my head
[22:18] <anastasiamac> menn0: i think its smth in dependencies...
[22:18] <menn0> anastasiamac: but I can try and figure it out if it's urgent
[22:18] <anastasiamac> menn0: is tim not around today?
[22:18] <menn0> anastasiamac: he's back tomorrow
[22:19] <menn0> anastasiamac: has the day off today
[22:19] <anastasiamac> menn0: k. i'll ask tomorrow
[22:19] <anastasiamac> menn0: it's not urgent 4 me :D
[22:19] <menn0> anastasiamac: ok
[22:19] <anastasiamac> menn0: but hazmat has troubles calling all new clients
[22:20] <anastasiamac> menn0: he can see them but when he calls them he get errors
[22:20] <menn0> anastasiamac: ok. i'll try and have a look and see if this is related to Tim's changes
[22:20] <menn0> anastasiamac: stop working on your day off!
[22:20] <anastasiamac> menn0: m nt working :P m talking to u :D
[22:20] <menn0> anastasiamac: that's work :)
[22:20] <anastasiamac> menn0: just an fyi, all feature tests run fine
[22:21] <anastasiamac> menn0: they all work when u do a full go install ../... from juju root...
[22:21] <anastasiamac> menn0: only new facades are affected
[22:21] <anastasiamac> menn0: axw saw the same behaviour on his environment (i did too)
[22:21] <anastasiamac> menn0: and had to re-build from scratch...
[22:22] <anastasiamac> menn0: as per above :D
[22:23] <menn0> anastasiamac: ok. good to know.
[22:26] <anastasiamac> menn0: thnx! that's what at least 2 cases of scotch now?.. :D
[22:26] <menn0> anastasiamac: umm... I haven't done anything yet :)
[22:26] <menn0> anastasiamac: but yes please :-p
[22:28] <anastasiamac> menn0: 1 for CI blockers (well for unblocking them) and 2nd in anticipation :D
[22:29] <menn0> anastasiamac: i'll see what I can do. onyx is in crunch mode at the moment, trying to get MESS working before the mid-cycle sprint.
[22:30] <anastasiamac> menn0: understood... tanzanite's storage has a new client for sprint demo too...
[22:30] <anastasiamac> menn0: just making sure that there will b no hiccups for us either :D
[22:31] <menn0> anastasiamac: I will look at that bug later today
[22:31] <menn0> anastasiamac: I even just assigned to me and everythign
[22:33] <anastasiamac> menn0: thnx :D but really m happy to wait til tim and tomorrow
[22:34] <menn0> anastasiamac: well I'll see if I can figure it out but if it turns into an epic then Tim can look tomorrow.
[22:37] <anastasiamac> menn0: thnx :D
[22:57] <hazmat> menn0, dropped a note on 1414027
[22:59] <menn0> hazmat: just read it. I'm pretty sure that the idea is if the client knows about /environment/:uuid/api it should use that.
[22:59] <menn0> hazmat: I believe that much of the API available at the root is going to go away at some point
[22:59] <hazmat> menn0, you mean it should keep trying different endpoints till one works?
[23:00] <hazmat> ie. does a 1.20.x env respond to that?
[23:00] <menn0> hazmat: not sure. thumper has a clearer picture of how this is supposed to work.
[23:01]  * menn0 checks the code
[23:01] <hazmat> menn0, i'm writing an app/client that's autonegotiating from 1.18 to  1.23.. on facades that esasy
[23:01] <hazmat> changing the endpoint is something else
[23:04]  * hazmat waits up for the australian open to start
[23:11] <menn0> hazmat: ok, I'm not exactly sure what the plan is. thumper will know more and he's back tomorrow.
[23:12] <menn0> hazmat: AFAIK the existing env-specific functionality will continue to work from the root for some time (but probably only for the initial environment I guess)
[23:15] <menn0> hazmat: actually, thinking some more, the env functionality at root should work for any env, as long as you log in to that env.
[23:16] <hazmat> menn0, sure but without telling clients that they may talking to a multi-state server env, they don't know till they Info() on the env to get version.. it should go to the jenv so they know where to connect,  connecting to root only works for legacy envs (env 0) in multi-tenant state servers, and connecting to multiple state servers. juju should add some info to disambiguate that in the client side info it stores, and avoid apps having to hit multiple endp
[23:16] <hazmat> oints (legacy, multi-style) to discover the correct one.
[23:16] <hazmat> menn0, you login by username, password, not by env uuid
[23:16] <hazmat> on the root
[23:17] <menn0> hazmat: i'm also pretty sure you can specific the environment tag at login time
[23:17]  * menn0 checks
[23:18] <menn0> hazmat: actually, it's before login
[23:19] <menn0> hazmat: api.Info has a EnvironTag field. if you set that you get a connection for that envrionment
[23:19] <menn0> hazmat: if it's blank you get the initial / state server env
[23:21] <hazmat> re before login, was there it weaved together prior to login in the src?
[23:21] <menn0> never mind
[23:21] <menn0> i've just looked further
[23:22] <menn0> setting that field changed the endpoint URL used by the juju API client
[23:22] <menn0> it's not passed through
[23:22]  * menn0 goes to check what 1.20 does with that...
[23:23] <menn0> and 1.18 even
[23:23] <hazmat> s/was/where
[23:23] <hazmat> k
[23:25] <hazmat> menn0, so yeah.. client api compatibility across multiple versions is the question.. i think dropping it in the jenv is appropriate. a multi-tenant root would be useful, but there's no initial request outside of login which would be a fine place to pass as older clients would ignore, but its also keeping compatibility with the older endpoints
[23:26] <hazmat> which is nice, but given apps want to be compatible with both, also enshrines it as endpoint for a little while... and of course assuming it does take env-uuid as a param on login
[23:27] <hazmat> environ tag is already in the jenv
[23:27] <hazmat> at least for 1.23.. dunno how far back that goes.
[23:28] <menn0> still digging... code for 1.18 was in LP so it's a little harder to check
[23:28] <hazmat> i'm currently doing conditional on that.. but that's a rather subtle distinction which would be better explicit, given the variety of tooling around the api.
[23:31] <hazmat> ie. juju client compatibility is great but there are other api clients that need to do the same dance..  at least  js and multiple py clients wrt to common usage... so some explicit delineation and email/doc would be useful..
[23:34] <menn0> hazmat: i've almost got this figured out. bear with me.
[23:35] <menn0> hazmat: so environ-uuid has been in the .jenv since 1.20.0. 1.18 didn't have it.
[23:36] <menn0> hazmat: and if you have environ-uuid in the .jenv then you should be using a endpoint of /environment/:uuid/api
[23:36] <menn0> hazmat: otherwise you use the root
[23:37] <menn0> hazmat: basically, if the jenv includes environ-uuid then the server supports it
[23:38] <menn0> hazmat: thumper will probably have some more detail but the above is what I'm seeing from the code at various points in time
[23:38] <menn0> hazmat: agreed that this needs to be documented better
[23:38] <hazmat> menn0, cool, thanks.. although i'll note.. not all clients use jenv (landscape and gui both collect info via forms)
[23:40] <menn0> hazmat: ok. and that's been fine up until now because there's only been one env and if you connect at root you just get the initial env.
[23:40] <hazmat> for client-side py tools that should handle things, thanks again
[23:40] <menn0> hazmat: those forms are going to need to take the env uuid as well i guess
[23:41] <menn0> hazmat: i'll follow up with thumper tomorrow and confirm all this and get the docs updated


[00:36] <MrChrisDruif> Hello everyone, can someone help me acquire an Ubuntu IRC cloak? I've just become member, but already registered on launchpad: https://launchpad.net/~chrisdruif
[00:37] <dax> alanbell, topyli, funkyhat, Pici: ^^^^
[00:37] <dax> MrChrisDruif: looks like you're eligible, just need to wait for an IRC Council person to show up and confirm it :)
[00:37] <dax> (congrats, btw)
[00:37] <MrChrisDruif> dax; the usual suspects? ;-)
[00:37] <dax> ayup
[00:37] <MrChrisDruif> Thanks dax ^_^
[00:38] <dax> (they're also not around right now for > 1h, so we probably get to wait)
[00:39] <MrChrisDruif> I'm probably of to bed as well, it's already past my "bed-time"
[00:42] <dax> alrighty.  That is why we have cloaks and firewalls
[13:10] <Mkaysi> About firewalls, I haven't ever understood why UFW is disabled by default, but it probably belongs to another channel.
[13:14] <bobweaver> oh gezz I got honeypots and ipcop ect but ....
[13:15]  * Mkaysi misread ipcop as ircop :D
[13:16] <bobweaver> :D
[13:45] <JanC> Mkaysi: blocking people's incoming bittorrent connections and such by default is likely to result in lots of support questions from angry/frustrated users...   ;)
[13:46] <Mkaysi> But there could be GUFW and mentioning about firewall somewhere
[13:46] <JanC> gufw is a bad ufw frontend
[13:49] <JanC> it doesn't allow the user to use most ufw features and actually duplicates some functionality that is in ufw already, plus it's not really useful for "normal" users who don't know how a firewall works
[13:49] <topyli> i don't know why i would want a firewall, by default or otherwise
[13:57] <Mkaysi> Why to include a firewall if it's not used?
[13:57] <Myrtti> because it's impossible to remove iptables?
[13:58] <Myrtti> well, you could, but it makes no sense
[13:58] <Myrtti> and people to still ask for a firewall
[13:58] <topyli> ufw costs something like 60k on the installation, so it's not such a big deal. and it's probably better to include ufw than have people find their own 'solutions'
[13:59] <topyli> (no i don't actually know how big/small ufw is)
[14:00] <Mkaysi> !info ufw
[14:00]  * Mkaysi is talking about ufw, not iptables
[14:01] <Mkaysi> I would say 820kB :)
[15:14] <loppy> hello?
[15:14] <Fuchs> yes, hi
[15:20] <loppy> hey
[15:22] <loppy> is there any way i can get unbanned from the Xubuntu-offtopic?
[15:22] <ikonia> loppy: you need to stop talking and listen
[15:23] <Fuchs> speaking to the operators who banned you is usually working well
[15:23] <ikonia> loppy: you where being resolved in #ubuntu-ops, you chose to storm out, so until you stop and listen, you're not getting unbanned from anywhere.
[15:23] <ikonia> Clear ?
[15:23] <loppy> what do you mean Clear?
[15:23] <ikonia> loppy: "is that clear to you"
[15:23] <ikonia> "do you understand"
[15:24] <loppy> yeah.
[15:24] <ikonia> great - so stop asking in every other channel, leave them, and join #ubuntu-ops and listen to what the people who have the power to unban you are telling you
[16:59] <Mkaysi> Hi, whoever manages http://ubottu.com/supydocs/plugins/User.html, there is a mistake. The first command is "hostmask add" and not "addhostmask"
[17:02] <tsimpson> blame supybot, because I downloaded the doc from them
[17:04] <Mkaysi> I don't think so, because that doc is better than the Supybot one.
[17:04] <Mkaysi> You can find the Supybot one from source/doc or docs
[17:05] <tsimpson> no, I wget'd it before they took the site down
[17:05] <Mkaysi> Oh
[17:07] <tsimpson> I think those docs were created before they added the ability to create command sub-classes
[17:07] <tsimpson> but the doc is only really there because it's no longer available anywhere else
[17:08] <Mkaysi> Do you happen to have backup of the rest of supybot.com?
[17:08]  * Mkaysi has heard that they had nice plugin collection
[17:08] <tsimpson> sorry, I was only interested in the documentation
[17:09] <Mkaysi> :(
[17:21] <cnd> tsimpson, ping
[17:21] <tsimpson> cnd: hello
[17:22] <cnd> tsimpson, hi, I have +F on #ubuntu-touch now
[17:22] <cnd> what do I need to do to get ubottu?
[17:23] <tsimpson> cnd: hold on please
[17:23] <cnd> ok
[17:27] <tsimpson> cnd: I'm just going through the process, I'll get back to you soon
[17:27] <cnd> ok
[17:45] <AlanBell> cnd: hello
[17:45] <cnd> AlanBell, hi
[17:46] <AlanBell> you want a bot in #ubuntu-touch for bugs and factoids?
[17:47] <AlanBell> you now have lubotu3 there
[17:47] <cnd> thanks!
[17:51] <cnd> AlanBell, lubotu left :(
[17:51] <AlanBell> cnd: yeah, but ubot5 is there, I got the wrong one
[17:51] <cnd> ok
[17:51] <cnd> it's odd to think that there are different bots
[17:52] <cnd> like they have different personalities :)
[17:52] <AlanBell> you don't want to get on the wrong side of lubotu2
[17:53] <cnd> heh
[17:54] <jussi> haha
[17:57]  * Mkaysi probably wants to stay on same side as lubotu3
[18:06] <AlanBell> Unit193: hey we need to sort out a cloak!
[18:07] <Unit193> Yeah, I was waiting for knome, he said he was going to do something. :D
[18:18] <AlanBell> what kind of something?
[18:21] <Unit193> https://launchpad.net/~unit193 That be me.
[18:21] <Unit193> I'm sure you already know, but figured it'd still be asked for.
[18:21] <AlanBell> yeah, good to have it in the logs
[18:22] <AlanBell> staff can we get an ubuntu/member/unit193 cloak please
[18:22] <Fuchs> Unit193: you want that?
[18:22] <Unit193> Fuchs: Sure.
[18:22] <Fuchs> your cloak is now set, enjoy
[18:22] <AlanBell> thanks Fuchs
[18:22] <Unit193> Thanks
[18:22] <Fuchs> You're welcome, have a nice weekend
[18:23] <Fuchs> oh, and congratulations :)
[18:23] <Unit193> Heh, thanks for that as well.
[18:25] <pangolin> Unit193, Congrats :)
[18:26] <Unit193> Danke, pangolin.


[04:06] <veebers> thomi: hey, you have a moment?
[04:14] <thomi> veebers: depends
[04:16] <veebers> thomi: heh, was just going to ask, what do you know about NotImplemented? I thought it was a 'normal' exception, but it's not a callable (like ValueError for instance)
[04:17] <thomi> veebers: NotImplementedError is the callable
[04:18] <veebers> thomi: ugh, of course, thanks :-)


[00:31] <slangasek> ScottK: ah - for some reason, Kubuntu 13.04 installs with 'splash' not set on the kernel commandline :/
[00:31] <slangasek> ScottK: neither 'splash' nor 'quiet'
[01:11] <ScottK> slangasek: I assume that's bad.
[01:12] <slangasek> well, it's rather difficult to correct now that the release is out
[01:12] <slangasek> and it was reported in ISO testing... but the bug got filed against plymouth and I only had a chance to look at it now :/
[01:14] <ScottK> We can add it to the release notes.
[01:15]  * slangasek nods
[01:15] <slangasek> strangely, this is only one of three kubuntu-specific plymouth bugs that came in, all of them different
[01:15] <slangasek> (bug #1171099)
[01:15] <ubot2> Launchpad bug 1171099 in ubiquity (Ubuntu) "kubuntu - plymouth not shown" [High,Confirmed] https://launchpad.net/bugs/1171099
[01:15] <ScottK> Could you add some suitable text to the bug and give me a ping so I can make sure things are all updated?
[01:16] <slangasek> on the way out to dinner now; I can try to add something later
[01:17] <ScottK> Thanks.
[02:58] <SpamapS> \
[05:44] <cjwatson> infinity: What's blocking opening at this point?
[05:44] <cjwatson> I saw mention of a GCC bug in scrollback, though I couldn't find details; but there's been a gcc-4.8 upload since then
[05:44] <ScottK> I think that was it.
[05:45] <ScottK> Might be nice to sort component mismatches a bit first.
[05:55] <cjwatson> Mm.  Some of that is probably backed up on the boost transition finishing migrating.  But I think I'll let people with a firmer grasp of the saucy toolchain changes sort it out ...
[05:56]  * ScottK looks again
[05:56] <cjwatson> Is somebody sorting out kdepim, which is blocking boost-defaults?
[05:58] <ScottK> No.  To sort kdepim you end up having to sort all the KDE packages that use boost together.
[05:58] <ScottK> It's on xnox's list, so I'm leaving it to him.
[05:58] <ScottK> BTW, the boost-mpi-foo demotions are definitely correct.
[05:58] <ScottK> They should never have been in Main.
[05:59] <ScottK> He's got the whole thing scripted, so I don't want to step into the middle of it.
[05:59] <ScottK> I can fix up the obvious boost ones.
[06:09] <ScottK> The boost override changes I know are correct, are done.
[06:09] <ScottK> I wouldn't mess with the rest of the 1.53 demotions until the transition is done.
[06:10] <ScottK> As long as the first autosync doesn't happen before the next publisher run is finished, I think we're good.
[06:12] <cjwatson> OK.  I'm not going to do it now anyway since I'm about to be travelling
[06:14] <cjwatson> Happy to sort it out tomorrow once I'm in .ca.us if everything else is done by then, or else there's an obvious crontab line that anyone with access to ubuntu-archive@lillypilly can uncomment
[06:14] <cjwatson> (env setup + auto-sync --batch)
[08:10] <infinity> cjwatson: GCC is what we were waiting on, yes.  I'll open it this morning when doko send his "We're open for devel, here's how the new toolchain sucks and/or is awesome" mail.
[08:11] <infinity> s/send/send/
[08:11] <infinity> s/send/sends/
[08:11] <infinity> Typing hard.  Need breakfast.
[08:14] <stgraber> oh wow, the Swiss lounge in Zurich upgraded their Internet! last time I barely had 5Mbps, this time I'm getting a nice symmetric 75Mbps, now to find some unreasonably large package to upload ;)
[08:15] <stgraber> infinity, cjwatson: Now that we have the name of the release I think the topic deserves some updating ;) (can't do it, apparently I don't have the required ACL for this channel)
[08:20] <iulian> Why don't we just -t it?
[08:25] <stgraber> that works too
[09:25]  * infinity looks suspiciously at his d-i build failures.
[09:30] <Noskcaj> does anyone know why there are no testcases for saucy on the iso tracker? sorry to ask on two channels but i'm not sure which it should go on
[09:32] <infinity> Oh, I forgot to set the default suite.  Oops.
[22:56] <slangasek> ScottK: release notes suggestion added to bug #1171099.
[22:56] <ubot2> Launchpad bug 1171099 in ubiquity (Ubuntu) "kubuntu - plymouth not shown" [High,Confirmed] https://launchpad.net/bugs/1171099


[22:18] <Unit193> https://bugzilla.samba.org/show_bug.cgi?id=14570
[22:41] <Unit193> Now ubot3 is not affected by that issue.


[00:40] <fluvvell> tgm4883, is there plans to re-include it?
[01:02] <lwizardl> anyone here know much about configuring mythbuntu to work with the Hauppauge HVR-1600 ATSC/NTSC cards ?
[01:04] <patdk-lap> lwizardl, sure
[01:04] <patdk-lap> it just works :)
[01:05] <lwizardl> not for me
[01:05] <patdk-lap> strange
[01:06] <patdk-lap> using ubuntu 8.04?
[01:06] <patdk-lap> cause it should just work in 10.04
[01:06] <lwizardl> 11.04 mythbuntu amd64 disc
[01:06] <lwizardl> the ivtv config setup says fail
[01:07] <patdk-lap> dunno
[01:07] <patdk-lap> I personally don't see a point at all of using a non-lts release for myth
[01:07] <lwizardl> just redid the full install and doing the system updates now
[01:08] <lwizardl> does same even in 10.10 says fail
[01:08] <patdk-lap> there is a huge kernel change between 10.04 and 10.10
[01:09] <patdk-lap> but then, I haven't heard anyone else saying it doesn't work
[01:09] <patdk-lap> but I dunno if they used the 1600
[01:09] <patdk-lap> I do, and it works without issues, but I'm on 10.04
[01:09] <lwizardl> well grabbing 10.04 now
[01:10] <lwizardl> 7mins to download
[01:13] <patdk-lap> if you still have issues, maybe the card is bad
[01:13] <patdk-lap> or, atleast try a different pci slot
[01:13] <lwizardl> it detects under the analog and mjpeg sections
[01:13] <lwizardl> and also the dvb dtv
[01:13] <lwizardl> just the ivtv fails
[01:17] <lwizardl> installing the ivtv utis and v4l utils now
[01:20] <lwizardl> ok those are installed now waiting for the reboot to finish
[01:22] <lwizardl> amd burning the cd iso now
[01:37] <lwizardl> booting disc now
[01:43] <lwizardl> ok seems to have some graphics tearing going on but lets see what happens after install finishes
[01:54] <lwizardl> ok same thing in 10.04
[01:54] <lwizardl> card type ivtv mpeg-2 encoder
[01:54] <lwizardl> failed to open
[01:55] <patdk-lap> sure your card is good?
[01:56] <lwizardl> yes
[02:26] <lwizardl> so i don
[02:26] <lwizardl> t know what is wrong but it have to be an issue with mythtv and ubuntu
[11:42] <Dapsaille> Hi, i used the command "/usr/bin/mythfilldatabase --update --file 1 tvguide.xml" in 0.24 for getting the guide, it seems that the syntax differ with 0.25 and i cannot get it work, does someone can give me a hand ?
[11:43] <Dapsaille> !help
[11:43] <Zinn> !help For a  complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi  Other available commands: !status, !about, !bug [bug_number].
[11:44] <dekarl> Dapsaille: the command line parser changed in 0.25 but aunt google doesn't like me atm... Isn't there a grabber for your guide source you could simply use?
[11:45] <dekarl> hmm, _fr_kazer is not yet in the packages... :(
[11:46] <Dapsaille> i use kazer
[11:46] <Dapsaille> but i use the old commandline for mythfilldatabase
[11:48] <dekarl> found it in the source coue... --file "Must be used in combination with: --sourceid  --xmlfile"
[11:48] <dekarl> so might be "--file --sourceid 1 --xmlfile tvguide.xml", gtg
[11:49] <Dapsaille> seems to work " Unknown xmltv channel identifier: EUR2.kazer.org - Skipping channel." ^^
[11:52] <Dapsaille> perfect, thanks dekarl


[22:23] <lazyPower> hazmat: ping
[22:24] <hazmat> lazyPower, pong..
[22:25] <lazyPower> hazmat: i see that you've been hacking on charmhelpers. has the general workflow with charmhelpers changed in syntactic sugar?
[22:40] <hazmat> lazyPower, state of the art is  a yaml file for defining parts, and then using charm-sync-helper
[22:40] <hazmat> lazyPower, which will copy those bits into the charm
[22:41] <hazmat> lazyPower, most of the openstack charms use that technique, and several others as well
[22:41] <lazyPower> I did do that following along with the video tutorial. My hang up is the module importing and then referencing. I'm long-tailing my definition and I dont understand why I have to do that.
[22:41] <hazmat> lazyPower, did not parse that last sentence
[22:41] <lazyPower> yeah i dont know how to explain this - can i gist what i'm doing and ask for feedback?
[22:42] <lazyPower> https://gist.github.com/chuckbutler/9315090
[22:42] <hazmat> lazyPower, sure
[22:43] <hazmat> lazyPower, oh.. i try not to do that.. just mapping helpers to hooks/charmhelpers avoids that need
[22:43] <hazmat> re the sys.path manipulation
[22:43] <lazyPower> ok so move the lib dir to "charmhelpers" in hooks?
[22:44] <hazmat> lazyPower,  no.. move lib/charmhelpers to hooks/charmhelpers
[22:44] <lazyPower> ah ok
[22:45] <hazmat> lazyPower, then py hooks can just do import charmhelpers
[22:45] <lazyPower> hazmat: along that veign, my yaml would change to be:  destination: hooks
[22:45] <hazmat> lazyPower, typically python syntax to get access to a module
[22:45] <hazmat> lazyPower,  http://paste.ubuntu.com/7024543/
[22:45] <lazyPower> right on. Thank you!
[22:45] <hazmat> lazyPower, would be from charmhelpers.core import hookenv
[22:46] <lazyPower> this has hung me up for the last half hour, i was starting to get discouraged


[00:51] <wallyworld> kelvinliu_: no rush, off to get food, but here'sthat labels PR https://github.com/juju/juju/pull/12294
[00:53] <jam> kelvinliu_: poke
[00:54] <kelvinliu_> looking wallyworld
[01:17] <kelvinliu_> wallyworld: lgtm ty
[05:46] <wallyworld> hpidcock: i'm hoping this will solve ken's issue with rebooting microk8s and having it come up with a different ip https://github.com/juju/juju/pull/12297
[05:47] <hpidcock> wallyworld: looking
[05:55] <hpidcock> wallyworld: just one suggestion
[05:55] <wallyworld> righto, thanks
[05:55] <wallyworld> hpidcock: my troll worked :-D
[05:59] <hpidcock> wallyworld: what I'd like to see in the future for CAAS is a controller service per namespace. Then the controller publishes it's addresses into it
[05:59] <hpidcock> that way it works for microk8s clustered
[05:59] <wallyworld> yeah, the layering is wrong right now, but a fairly significant bit of work is needed to fix it
[05:59] <wallyworld> and state can't import provider or environ code so we're stuck with it for now
[06:00] <wallyworld> with having the string literal in state
[06:00] <hpidcock> state already imports provider/constants
[06:00] <wallyworld> i'd love to rework this for v3.0
[06:00] <wallyworld> sigh, ok
[06:01] <hpidcock> yeah infact state already imports caas/kubernetes/provider
[06:01] <wallyworld> double sigh
[06:01] <hpidcock> I was trying to move it to just the constants package when I did this work
[06:01] <hpidcock> hence why constants package exists now
[06:01] <wallyworld> let's fix it for 3
[06:01] <hpidcock> agreed
[07:11] <wallyworld> hpidcock: sorry, one more https://github.com/juju/juju/pull/12298
[07:24] <hpidcock> no problemo
[07:26] <hpidcock> getting close to PR #12345
[07:26] <mup> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> <https://launchpad.net/bugs/12345>
[10:18] <stickupkid> manadart, https://github.com/juju/juju/pull/12299
[10:23] <manadart> stickupkid: Looking.
[10:46] <stickupkid> manadart, also https://github.com/juju/juju/pull/12291


[06:12] <alkisg> vorlon: great, except that... then all shims need to add the distro name in the paths that they use, otherwise they end up in the same grub name. They don't currently do that, afaik.
[06:13] <alkisg> So it would be: UEFI > ubuntu shim > ubuntu grub > fedora shim > meh, ubuntu grub again, as the shimx64.efi name is hardcoded for all distros, with no distro name in their paths
[06:14] <alkisg> (same for dhcp/tftp too)
[06:25] <vorlon> alkisg: oboting ubuntu grub -> fedora shim means booting the fedora shim by its full path; and shim loads grub from the same directory
[06:25] <vorlon> booting
[06:26] <alkisg> vorlon: ah, thanks; I'll run some tests, as I think that many paths there were hardcoded, but I'm not sure if it was in the pxe or the local disk case. Merci!
[06:27] <voltagex> Hi, does anyone know what the performance impacts of ZFS on kernel  5.0 will be? Looks like a pretty major patch. I'm on an Atom 2758 box with 32TB of disks and I don't see another way of testing this short of running a full scrub (20 hours or so)
[07:03] <Skuggen> ahasenack: my_load_defaults should be there, but not load_defaults
[07:03] <Skuggen> The net-snmp package I tested with some time back was patched to add the my_
[10:17] <ahasenack> Skuggen: yeah, but it didn't find my_load_defaults. I wonder if it's related to the missing my_global.h header file
[10:18] <ahasenack> Skuggen: net-snmp upstream has basically an if/then/else now. It tries load_defaults, then my_load_defaults, and if neither exist, uses mysql_options()
[10:25] <ahasenack> Skuggen: line 450: https://sourceforge.net/p/net-snmp/code/ci/master/tree/apps/snmptrapd_sql.c
[10:25] <ahasenack> it calls mysql_options (if conditions are met) in line 565
[10:25] <ahasenack> I'm trying to backport that
[10:43] <Skuggen> ahasenack: my_global (and my_sys) have been removed from 8.0. Should only need mysql.h
[10:44] <ahasenack> Skuggen: and my_load_defaults? A grep for it in /usr/include -r doesn't find it
[10:47] <Skuggen> Hm, maybe I was wrong
[10:47] <ahasenack> it looks like mysql_options() can be used to load ~/.my.cnf
[10:48] <ahasenack> I'll keep on that path
[10:50] <Skuggen> Yeah, looks like that's the intended way now https://dev.mysql.com/doc/refman/8.0/en/mysql-options.html
[10:52] <ahasenack> k
[11:01] <Skuggen> Talked with devs. my_load_defaults was added back to the export list when we did the 5.7 transition in 16.04, but it was only meant to be a temporary measure :)
[11:04] <ahasenack> I see that kind of thing happening a lot
[11:05] <ahasenack> found a bug in mysql8 where another name, that had been removed, was added back by mistake (in the 8 series)
[11:05] <ahasenack> forgot what it was
[11:05] <ahasenack> so the bug was to remove it again, for good :)
[11:32] <rbasak> Has anyone successfully used "git ubuntu import-ppa" recently?
[11:50] <ahasenack> for cacti-spine: https://bugs.launchpad.net/ubuntu/+source/cacti-spine/+bug/1814526
[11:50] <ahasenack> rbasak: I didn't even know it existed
[11:50] <ahasenack> rbasak: do you have a tag for mysql8 ftbfs?
[11:56] <rbasak> ahasenack: I invented mysql-8.0-transition earlier. Perhaps use that and the ftbfs tag?
[11:57] <rbasak> Skuggen: FYI ^
[11:57] <Skuggen> ahasenack: I'm testing just putting my_bool back in now (it's a meaningless type, but at this stage it's better to patch mysql than the ~50 packages that use the type :))
[11:59] <Skuggen> Can use cacti-spine to verify the fix
[12:00] <ahasenack> ok
[12:01] <ahasenack> we could still use the bugs, though, to slowly migrate the packages away from my_bool then
[12:02] <Skuggen> Yeah. I sent in bug reports about this for all rdeps of libmysqlclient21 (or I thought I did, but maybe the commands I used to find them didn't list everything)
[12:03] <ahasenack> bugs in ubuntu?
[12:03] <ahasenack> any particular tag or pattern to search for?
[12:04] <Skuggen> "FTBFS with MySQL 8.0"
[12:04] <Skuggen> A few of them are for other things like my_sys.h and/or my_global.h, but the my_bool issue is the most common
[12:06] <ahasenack> I hit 4 in net-snmp
[12:06] <ahasenack> - my_bool
[12:06] <ahasenack> - my_load_defaults
[12:06] <ahasenack> - my_glpobal.h and my_sys.h
[12:06] <ahasenack> - something with my_init, MY_INIT, but that might have changed in a later 5.7 already
[12:06] <Skuggen> I got net-snmp to build by fixing the two headers and my_bool, I think
[12:06] <ahasenack> my_load_defaults is gone, that needs fixing
[12:07] <ahasenack> it's the last fix I need
[12:07] <Skuggen> But net-snmp can use mysql_options, can't it?
[12:07] <ahasenack> yes
[12:07] <ahasenack> that is the fix
[12:07] <ahasenack> it's just not in our package yet
[12:08] <ahasenack> about init, it was "there is mysql_init(), MY_INIT(), and my_init()"
[12:08] <ahasenack> if-defs all over the place
[12:09] <Skuggen> Maybe my_load_defaults was still in there in earlier 8.0 versions (it was an "unofficial" export in 5.7) and only removed recently.
[12:09] <Skuggen> https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mysql-8.0/+packages test of cacti-spine
[14:08]  * apw just did a dist-upgrade in disco ... and grub-efi-amd64-signed and shim-signed failed to install
[14:11] <apw> which seems to be stemming from grub-efi-amd64-signed complaining about 'db is empty' maybe
[14:24] <apw> /usr/share/grub/grub-check-signatures <-- seems it is this which is failing
[15:24] <apw> it seems this is because mokutil --export --db is saying db is empty; and this is fatal to bootloader installation
[15:53] <ahasenack> hi, does anybody know what this means: ERROR: erroneous package: rules extract failed with exit code 1
[15:53] <ahasenack> https://pastebin.ubuntu.com/p/JxJFfCVB24/ more context
[15:53] <ahasenack> it's an autopkgtest run in disco, for freeipa
[15:53] <ahasenack> freeipa is in disco-proposed
[15:53] <ahasenack> but apparently was removed from disco, is that it?
[15:54] <ahasenack> hm, looks like freeipa needs to be removed from disco-proposed then?
[15:54] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/dogtag-pki/+bug/1813155
[15:54] <ahasenack> tjaalton: ^ ?
[17:00] <tjaalton> ahasenack: I'll upload a client-only version soon
[17:01] <tjaalton> to debian first
[18:20] <LocutusOfBorg> tjaalton, hello, what is the rationale for this delta? https://launchpad.net/ubuntu/+source/httpcomponents-client/4.5.6-1ubuntu1 ? can it be syncd?
[18:21] <tjaalton> LocutusOfBorg: yep
[18:33] <LocutusOfBorg> tjaalton, can you please sync it, or should I do it?
[19:15] <tjaalton> LocutusOfBorg: done
[23:13] <jilocasin> evening all
[23:13] <jilocasin> anyone have any idea why *the* default installer for 18.04.1 LTS Server is a subiquity based cloud one?
[23:16] <rbasak> I answered you in #ubuntu-server.
[23:17] <rbasak> !crosspost
[23:17] <jilocasin> rbasak: thanks, I responded there as well.
[23:18] <jilocasin> rbasak: sorry, I was told in #ubuntu to ask in #ubuntu-devel, #ubuntu-discuss, snd #ubuntu-server
[23:21] <rbasak> Sorry you were misled. General consensus on Ubuntu IRC channels is what the bot says on that - please don't crosspost.
[23:26] <krytarik> They didn't indicate to post it in all of them at once though.


[01:06] <MartyrX> Why do i get this everytime i try to install Ubuntu it says that the CD can't mount, but i have tried creating several discs and still says the same thing.
[01:06] <MartyrX> However when i run my backtrack 4 disk it works just fine.
[01:08] <MartyrX> anyone here
[16:35] <kamusin> is there a problem with natty daily iso? cannot finish to boot my sistem, is waiting for battery state for a long time and never start X
[17:40] <davmor2> kamusin: is this from the live imagew?
[17:43] <kamusin> is from the daily image iso
[17:45] <davmor2> kamusin: as far as I'm aware the daily iso should work but the live image not.  I'm pretty sure thought that there are issues beyond that so it wouldn't surprise me to hear that it wasn't working
[17:57] <kamusin> hehe I see davmor2 , thanks you information
[17:57] <kamusin> you/for you/g


[00:03] <hggdh> OK, folks. How do I report an apport bug? apport is setting up a bad URL...
[00:03] <hggdh> to wit: file:///ubuntu/+source/linux/+filebug/bL8XpOeE8Z3YGQPbDR1tnjnNuPE
[00:05] <bdmurray> hggdh: How did you get that url?
[00:05] <bdmurray> I an see the bug https://bugs.edge.launchpad.net/ubuntu/+source/linux/+filebug-advanced/bL8XpOeE8Z3YGQPbDR1tnjnNuPE
[00:05] <Rocket2DMn> ive seen that behavior too
[00:05] <bdmurray> can!
[00:06] <hggdh> bdmurray, via apport-triggered report
[00:06] <bdmurray> hggdh: and your browser then had a page open w/ file:/// ?
[00:07] <hggdh> right now I replaced the file:// by  https://launchpad.net
[00:07] <hggdh> bdmurray, correct
[00:07] <hggdh> interesting, is it not?
[00:07] <Rocket2DMn> hggdh, when you file it post a link, ill confirm it
[00:07] <hggdh> OK. bug 317308 submitted correctly
[00:08] <bdmurray> I don't think its apport I heard someone having a problem with gnome-terminal and urls
[00:08] <Rocket2DMn> bdmurray, i had it appear in intrepid a number of times when X crashed and apport did its thing.  there was no gnome-terminal involved
[00:08] <hggdh> how would it involve gnome-terminal? It was all driven by apport
[00:08] <Rocket2DMn> s/intrepid/jaunty
[00:08] <hggdh> jaunty, correct
[00:09] <Rocket2DMn> wait here comes another one i bet
[00:09] <charlie-tca> yeah, done it to me in jaunty too
[00:09] <Rocket2DMn> ah its notgonna come up b.c i havent updated
[00:10]  * hggdh thinks its time to check & report if needed
[00:11] <bdmurray> it might be bug 314263
[00:12] <Rocket2DMn> if it is, its not limited to gnome
[00:12] <hggdh> sounds rather similar indeed
[00:15] <hggdh> yes, sounds like it. This is sort of bad, because we may miss a lot of bugs
[00:16] <bdmurray> hggdh: I agree
[00:18] <hggdh> hum. I cannot repeat the issue as reported on this bug.
[00:19] <hggdh> will have a quick go on the apport code...
[00:20] <bdmurray> I'm looking at it now and don't see anything
[00:28] <hggdh> in apport/ui.py
[00:29] <hggdh> @587-589
[00:33] <hggdh> jeez... meanwhile my Evo trunk has sigsegv-ed again :-(
[00:39] <Lupine> Can someone mark this as WishList: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/317192
[00:40] <Lupine> this reporter is basically stating that apport should automatically install debug symbols
[00:40] <pedro_> Lupine: done
[00:40] <Lupine> ty
[00:40] <pedro_> you're welcome
[00:41] <pedro_> Lupine: it looks similar to bug 304129
[00:43] <Lupine> ahhh, do we typically mark WishLists as duplicates?  if so I'll change it
[00:45] <pedro_> Lupine: yeah, if it's a duplicate feel free to mark it, it doesn't matter which importance the bug has, just make sure that the master bug has the same one
[00:46] <Lupine> will do
[00:46] <pedro_> thanks you
[00:46] <hggdh> but apport *does* install debug packages!
[00:46] <hggdh> sudo apport-retrace -o whatever /var/crash/_a_crash_file
[00:47] <hggdh> of course, it will also potentially hose your apt base by installing obsolete dbgsyms
[00:47] <hggdh> but that is another bug
[00:47] <Lupine> :)
[00:48] <Lupine> I guess for this (and other) reporters, the complaint is it is not user friendly enough
[00:48] <hggdh> this is actually how I update my dbgsyms
[00:48] <Lupine> sounded like a perfect candidate for a brainstorm
[00:48] <hggdh> well yes, I agree. But, on the other hand, if you do not know what to do here, you should not be doing it
[00:49] <hggdh> (and 'you' does not mean YOU, but is a generic placeholder for apport users)
[00:50] <hggdh> (and here does not mean HERE, but is a placeholder for apport)
[00:50] <hggdh> damm
[00:50] <Lupine> :)
[00:50] <hggdh> this got confusing
[02:06] <andresmujica> !time
[02:06] <andresmujica> !date
[03:46] <charlie-tca_> hggdh: Did you find a bug on apport?
[03:52] <hggdh> no, I did not, not about that.
[03:52] <hggdh> I will open one... do you experience it also?
[03:53] <hggdh> charlie-tca_, ^^
[03:55] <charlie-tca_> No, I thought is was, but the report filed normally
[03:56] <charlie-tca_> I lost the i386 report that messed up.
[03:56] <hggdh> but I just found a bug on it
[03:56] <hggdh> bug 315996
[03:56] <hggdh> dammit
[03:57] <hggdh> bug 315966
[03:58] <charlie-tca_> I'll write it down so I can add to it later.
[04:00] <hggdh> I just confirmed it
[04:02] <charlie-tca_> Thanks
[04:03] <hggdh> oy mey, I am still being plaged by Evo SIGSEGVs and kernel oops :-(
[04:06] <hggdh> s/mey/vey/... add to the plagues fat-fingering :-/
[04:08] <hggdh> heh. bug 317322
[04:09] <charlie-tca_> :-)
[04:09] <hggdh> translating: the screen has much/many "zum", and I do not know how to take it/them out
[04:09] <hggdh> whatever is zum
[04:10] <charlie-tca_> everything is too big?
[04:10] <hggdh> who knows? If we knew what "zum" was, we could answer...
[04:11] <hggdh> Brazilian portuguese, it seems
[04:11] <hggdh> and... with grammatical errors to boot
[04:12] <charlie-tca_> you mean I have to learn another language? I' m still stuck trying to figure out french
[04:12] <hggdh> :-)
[04:12] <charlie-tca_> heh heh
[04:45] <AbtZ> hey... so how do i help out with bugs? :)
[05:10] <hggdh> AbtZ, please see http://wiki.ubuntu.com/HelpingWithBugs
[07:39] <dholbach> good morning
[08:02] <thekorn> hiya dholbach
[08:03] <dholbach> hi thekorn
[11:10] <pedro_> folks don't forget that today is the network-manager hug day: https://wiki.ubuntu.com/UbuntuBugDay/20090115 ; feel free to triage any of the bugs there ;-)
[11:13] <james_w> hey pedro_
[11:14] <pedro_> hello james_w
[11:38] <bhuv1> hi! i'm new to bugsquad,how to triage bugs help me!
[11:40] <pedro_> bhuv1: are you interested in any package in particular?
[11:41] <pedro_> bhuv1: i recommend to start triaging bugs without a package, most of them are easy to triage
[11:41] <bhuv1> no,i wanted to help!i'm using ubuntu 8.04
[11:42] <pedro_> bhuv1: we have a list of easy tasks https://wiki.ubuntu.com/Bugs/EasyTasks for starting doing triage
[11:52] <bhuv1> h
[12:02] <pfarmer> hi, just getting started in bugsquad, I'm currently looking at bug 272591, its looks like its a openvz kernel issue, but when I select choose to select a openvz kernel package it doesn't find any for me to select
[12:08] <thekorn> pfarmer, it's a metapackage, so the target should be linux-meta
[12:09] <thekorn> pfarmer, one way to find this out is to go to packages.ubuntu.com, search for the package, and click on "bug reports"
[12:09] <thekorn> for example: http://packages.ubuntu.com/en/hardy/linux-openvz
[12:10] <pfarmer> thekorn: thanks
[12:13] <thekorn> you're welcome, thanks for helping!
[13:02] <itnet7> Bug #317294
[13:03] <itnet7> Can someone please mark this wishlist when you get the chance? Thanks!
[13:04] <itnet7> Actually have to leave for work now bbl
[13:26] <xteejx> hi guys
[13:27] <pedro_> hello xteejx
[13:28] <xteejx> can someone have a look at bug 316795 for me please? its a real hardware annoyance, and a regression from hardy through intrepid, i don't want my wifi not working again :(
[13:30] <xteejx> is there anything else i can put on the above?
[13:50] <pedro_> there's still a few bugs to squash, join the fun guys: https://wiki.ubuntu.com/UbuntuBugDay/20090115
[13:50] <pedro_> hello MrKanister
[13:50] <MrKanister> hi pedro_
[14:10] <pedro_> MrKanister: are you using 5-a-day ?
[14:10] <MrKanister> pedro_: No. I doing it without 5-a-day
[14:10] <MrKanister> pedro_: I am so lazy to use 5-a-day ;)
[14:11] <pedro_> MrKanister: why not add them to it ? ;-)
[14:11] <pedro_> hehe
[14:11] <MrKanister> pedro_: I think 5-a-day is a lot about motivation which I have already without :)
[14:12] <pedro_> MrKanister: i know ;-), but in the end we could know how many bugs we did during the hug day, having some stats is always good ;-)
[14:14] <MrKanister> pedro_: hm, that's a good reason...I will set up 5-a-day.
[14:14] <pedro_> MrKanister: you rock!
[14:14] <MrKanister> pedro_: hehe..thanks ^^
[14:14] <MrKanister> It's such a nice community around launchpad
[14:16] <charlie-tca> pedro_: bugcontrol membership is expiring. Do I send a message ?
[14:19] <pedro_> charlie-tca: no need to, i'll renew it for you
[14:21] <charlie-tca> What language is it? bug 317418
[14:22] <hggdh> dutch
[14:22] <charlie-tca> thanks
[14:22] <hggdh> but I do not understand it...
[14:23] <pedro_> charlie-tca: done
[14:23] <charlie-tca> thanks, pedro_
[14:23] <pedro_> you're welcome
[14:29] <javaJake> mark
[14:29] <javaJake> Oops.
[15:19] <pedro_> wow graphs are looking great: https://wiki.ubuntu.com/UbuntuBugDay/20090115
[15:41] <james_w> pedro_: that's cool
[15:41] <james_w> nice work everyone
[15:41] <james_w> especially MrKanister it seems :-)
[15:41]  * pedro_ hugs the bugsquad
[15:42] <MrKanister> james_w: Just doing my job ;)
[16:12] <javaJake> Wow, network-manager is a mess
[17:10] <MrKanister> Where to get infos about the driver being used? (This is needed for https://wiki.ubuntu.com/DebuggingNetworkManager#Driver%20Logs)
[17:10] <MrKanister> bug #307940
[17:14] <pedro_> MrKanister: Jan 15 16:41:57 toby-s kernel: [   21.264710] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
[17:14] <pedro_> MrKanister: iwl3945 is the one being used
[17:16] <MrKanister> pedro_: Oh, right. It's in the syslog. Thanks.
[17:16] <pedro_> MrKanister: you're welcome
[18:23] <thekorn_> wow, happy 1st-hugday-of-2009 everyone!
[18:23]  * thekorn_ hugs MrKanister and pedro_, nice work :)
[18:24] <MrKanister> thekorn_: Thank you :)
[18:28] <pedro_> thekorn_: MrKanister is the hero of the day ;-)
[18:28]  * pedro_ hugs MrKanister
[18:30] <MrKanister> hehe...it's my first bugday
[18:30]  * MrKanister hugs pedro_ back
[18:31] <thekorn_> right, I think we should ask dholbach about adding some hugday-hero bling to the hall of fame
[18:32] <pedro_> thekorn_: that'd be neat, we should definitely ask to him
[21:13] <LimCore> hi
[21:13] <LimCore> can anyone with 8.04 please verify bug https://bugs.launchpad.net/ubuntu/+source/pam/+bug/314222
[21:16] <LimCore> wow O_o  ls is crashing for me. Just wow.
[21:25] <LimCore> Wow. Program  ls  crashes ob my box, 100% reproduceable so far :]]]
[21:26] <BUGabundo> LimCore: package version?
[21:26] <BUGabundo> are you on a local filesystem?
[21:26] <BUGabundo> or remote/gvfs ?
[21:27] <LimCore> BUGabundo: just my local fs. One sec I will supply all information
[21:35] <LimCore> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/317650
[21:38] <BUGabundo> ahh tab complete!
[21:41] <LimCore> actually, it is enough to just press and hold it
[21:41] <LimCore> known problem?
[21:44] <james_w> err, you don't hit enter after typing ls?
[21:44] <LimCore> nope
[21:44] <james_w> that's a bash bug then
[21:45] <LimCore> ok actually the bug is very simple:  type any program, say  vim   and then press and hold TAB key in bash (so that bash keeps displaying you list of directories) after ~5 sec crash alwats
[21:45] <LimCore> yeap I was mistaken about the ls
[21:45] <james_w> it's a dupe I believe
[21:45] <james_w> check the bugs on bash
[21:45] <LimCore> can't find -dbgsym for bash (then in repo are outdates)
[22:38] <hggdh> hi LimCore
[22:39] <LimCore> hi hggdh
[22:39] <hggdh> LimCore, re. bug 317650 -- it does not seem to be ls, but bash
[22:39] <LimCore> hggdh: right my mistake
[22:39] <LimCore> sorry I got confused bash > gdb > bash > ls :P
[22:39] <hggdh> heh
[22:40] <LimCore> would be sure nice to fix it asap
[22:40] <hggdh> please install the dbgsyms for bash and bash-completion
[22:40] <hggdh> and give us a nice backtrace ;-)
[22:40] <LimCore> I cant install for bash, wrong versions
[22:40] <hggdh> ugh!
[22:40] <LimCore> others said there probably was such report / duplicate.   Im now at work
[22:40] <hggdh> k, thanks
[23:27] <Rocket2DMn> ok guys, bug 317647
[23:28] <Rocket2DMn> what package does that go under?  usermod isnt a package, it isnt coreutils, so thought passwd based on what dpkg -S says
[23:28] <Rocket2DMn> but there is no passwd package in LP
[23:32] <bdmurray> Rocket2DMn: try apt-cache show passwd then look for the source package
[23:33] <Rocket2DMn> cool, and it is passwd
[23:33] <Rocket2DMn> wait
[23:34] <Rocket2DMn> yeah...
[23:34] <Rocket2DMn> i was looking for the package that holds usermod
[23:35] <bdmurray> Rocket2DMn: right
[23:35] <bdmurray> so dpkg -S /usr/bin/usermod returns passwd
[23:35] <Rocket2DMn> and passwd is a valid ubuntu package, but when i go to place the bug under passw on lp, "passwd" is not an option in the search box
[23:35] <bdmurray> then 'apt-cache show passwd'
[23:36] <Rocket2DMn> /usr/sbin/usermod
[23:36] <bdmurray> returns Source: shadow
[23:36] <bdmurray> https://bugs.edge.launchpad.net/ubuntu/+source/shadow
[23:36] <Rocket2DMn> ah, thats a little confusing, b/c shadow isnt actually a package
[23:36] <Rocket2DMn> thanks bdmurray
[23:57] <Lupine> Is a feature request still a feature request, when it involves a Security vulnerability?
[23:57] <Lupine> I'm speaking of this bug report: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/296741
[23:57] <Lupine> oh and Happy Hug Day
[23:59] <Lupine> I feel that, even though this reporter presents a valid security issue, it still feels like a request not a bug


[14:04] <teward> can someone check #ubuntu and the jira_ person?  They seem to be ignoring that they are being offtopic
[14:04] <teward> (although i've called them out on it once already)
[14:04] <teward> it now reads as 'senseless banter' and useless questions but meh.
[14:06] <teward> jiri_ *  (system autocorrect is evil)
[14:07] <teward> IdleOne: thanks
[17:05] <phunyguy> Hey, hopefully this guy isn't smart enough to evade a ban of<EMAIL_ADDRESS>- should keep him at bay for a while  (the black_power fella).
 # Appears as BOLO
[23:16] <bazhang> ms comic chat!!1


[00:06] <minasota> TN SC game or Cubs... Man, life is good if this is my hardest choice :)
[08:46] <cyberanger> minasota: Cubs
[11:06] <Unit193> You mean Indians?
[20:39] <cyberanger> Unit193: Nope, I don't


[03:00] <jml> barry: hi
[03:00] <barry> jml: hi
[03:00] <barry> #startmeeting
[03:00] <MootBot> Meeting started at 21:02. The chair is barry.
[03:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[03:00] <barry> yay!
[03:01] <barry> welcome to this week's asiapac reviewer's meeting.  who's here today?
[03:01]  * jml is reminded to file a bug on Python
[03:01] <jml> barry: I am.
[03:01] <barry> thumper: ping?
[03:01] <barry> mwhudson: ping
[03:02]  * barry guesses thumper knows barry will rant at him about pqm :)
[03:02] <thumper> hi
[03:02] <thumper> barry: now why would you rant about pqm?
[03:03] <barry> thumper: i'd like it to vanish more of my branches please! :)
[03:03] <barry> [TOPIC] agenda
[03:03] <MootBot> New Topic:  agenda
[03:03] <thumper> barry: I could delete them for you?
[03:04] <barry> * Roll call
[03:04] <barry>  * Next meeting
[03:04] <barry>  * Action items
[03:04] <barry>  * Queue status
[03:04] <barry>  * Mentoring update
[03:04] <barry>  * Review process
[03:04] <barry>    * make pqm not broken
[03:04] <barry> thumper: then i could just stop working on branches too!  excellent
[03:04] <thumper> slacking FTW!
[03:04] <barry> [TOPIC]  * Next meeting
[03:04] <MootBot> New Topic:   * Next meeting
[03:04] <barry> everyone okay with today += week(1)
[03:05] <thumper> +1
[03:05] <barry> jml: i know you are too :)
[03:05] <jml> :)
[03:05] <barry> [TOPIC]  * Action items
[03:05] <MootBot> New Topic:   * Action items
[03:05] <barry> nothing on asiapac iirc
[03:05] <barry> [TOPIC]  * Queue status
[03:05] <MootBot> New Topic:   * Queue status
[03:06] <mwhudson> ah, as traditional, i missed the start of the meeting, sorry
[03:06]  * jml files http://bugs.python.org/issue3071
[03:06] <barry> mwhudson: no problem!  i was just about to assign all the GQ branches to you!
[03:06] <mwhudson> heh heh
[03:06] <barry> jml: cool
[03:07] <jml> barry: I've been griping about Python's default exception messages for ages now.
[03:07] <jml> barry: time to do so productively :)
[03:07] <barry> jml: especially with the first betas going out on wednesday! (perhaps)
[03:08] <barry> i don't have much on the queue status
[03:08] <barry> i'm going to assign the 4 GQ branches after this meeting, but other than that, things look okay
[03:08] <barry> i had test failures in the one adeuring branch i started today
[03:08] <mwhudson> oh hey, i got assigned a branch
[03:09] <sinzui> not from me
[03:09] <mwhudson> i totally didn't notice
[03:09] <barry> mwhudson: you should run bac's script!
[03:09] <mwhudson> barry: we should fix launchpad!
[03:09] <mwhudson> etc etc
[03:09] <barry> that too :)
[03:10]  * jml notices Python 2.5 actually does a lot better at error messages than 2.4.
[03:10] <barry> jml: 2.5 rocks.  we really need to switch to it
[03:10] <barry> anything on the queue from y'all?
[03:10] <jml> barry: damn straight. I want to use defgen :)
[03:11] <sinzui> mwhudson: hmm. I think I did make a mistake. that branch looks familiar. I think I meant to assign it to bigjools
[03:11]  * barry wants with statements!
[03:11] <thumper> FWIW abentley is working on the branch that will email the reviewer when nominated for a review
[03:11] <mwhudson> will the zope upgrade get us any close to being ready to use 2.5 ?
[03:11] <barry> thumper: how long before you think we'll be able to do all our reviews in lp?
[03:11] <sinzui> barry: start debugging the zope 3.4 branch. It works except for that giant hole I putting in importfacsist.
[03:12] <thumper> hacky ones in about 3 or 4 weeks
[03:12] <thumper> with shiney happy people, probably about 8
[03:12] <barry> sinzui: fred drake tells me they (zc) runs zope all the time on py2.5
[03:12] <barry> thumper: that will rock
[03:13] <mwhudson> sinzui: ok, are you going to move that branch out of my queue?
[03:13] <sinzui> barry: I bet. but importfascists and zope 3.4 conflict. I sacrificed the former for zope
[03:13] <sinzui> mwhudson: I will
[03:13] <mwhudson> sinzui: thanks
[03:13] <barry> sinzui: dang.  where's the branch?
[03:14] <barry> anyway.  moving on...
[03:14] <barry> [TOPIC]  * Mentoring update
[03:14] <MootBot> New Topic:   * Mentoring update
[03:14] <barry> skipped as usual...
[03:14] <mwhudson> n/a
[03:14] <barry> [TOPIC]  * Review process
[03:14] <MootBot> New Topic:   * Review process
[03:14] <barry>    * make pqm not broken
[03:15] <barry> so... thumper i'm told you're pqm-man now! :)
[03:15] <thumper> hah
[03:15] <jml> what's the PQM break?
[03:15] <jml> looks just fine to me.
[03:15] <jml> or at least as good as it's ever been :)
[03:15] <barry> there are several problems, but the most severe symptom is that branches are getting disappeared all the time
[03:16] <barry> they fail and nobody gets notified
[03:16] <jml> ahh ok.
[03:16] <jml> that *is* pretty bad.
[03:16] <sinzui> Isn't that directly cause by the make check change from 60 minutes to 15 minutes?
[03:16] <barry> jml: it's doubly bad because grepping through the logs is PAINFUL
[03:16] <barry> since the logs don't include branch information unless they succeed :(
[03:16] <thumper> barry: where are the logs?
[03:16] <barry> sinzui: yes, that's what flacoste thinks
[03:16] <mwhudson> this sounds like something that needs help from an OSA
[03:16] <jml> I see.
[03:16] <mwhudson> not us
[03:17] <barry> thumper: devpad
[03:17] <thumper> barry: where on devpad?
[03:17] <mwhudson> sinzui: i don't see the connection instantly
[03:17] <barry> thumper: /srv/lp-pqm-logs
[03:17] <thumper> barry: thanks
[03:17] <jml> barry: do we know that this is a bug in PQM itself?
[03:18] <barry> francis and i talked about a few things: first, if merges get killed, we should still see notifications, which i think today we don't
[03:18] <barry> jml: we don't, but that's the suspicion
[03:18] <barry> second issue is figuring out why sometimes you get no output for 15+ minutes
[03:18] <mwhudson> but the vicious killing after 15 minutes isn't anything to do with pqm
[03:19] <mwhudson> it's something test.py or shh.py or something does
[03:19] <barry> mwhudson: aren't the logs maintained and sent by pqm?
[03:19] <mwhudson> yes
[03:19] <jml> barry: has anyone tried to reproduce the issue?
[03:19] <mwhudson> but pqm doesn
[03:19] <barry> mwhudson: right.  but no one has reproduced the 15 minute hang on dev boxes
[03:19] <mwhudson> 't look at the logs
[03:20]  * jml meant the lack-of-notification issue.
[03:20] <barry> jml: not to my knowledge
[03:20] <jml> barry: ok.
[03:20] <barry> third problem was lack of branch information in the logs unless the merge succeeds
[03:21] <barry> but if pqm doesn't write the logs, i guess it can't do that
[03:22] <thumper> pqm does write a log file
[03:22] <thumper> several actually
[03:22] <barry> we need a plan though, 'cause it's killing productivity.  e.g. branches are getting stacked up beause parent branches aren't landing and then no one knows why
[03:22] <jml> in my ignorance, I'd say that PQM ought to keep a log of requests it receives and what it does with them.
[03:22] <thumper> jml: it does
[03:22] <thumper> barry: are the bugs filed against pqm?
[03:22] <jml> thumper: but not enough information to identify the branch?
[03:22] <mwhudson> i can't find any logs on devpad in the last 50 that seem to have been killed for lack of activity
[03:23] <mwhudson> but maybe i'm grepping for the wrong things
[03:23] <jml> thumper: well, the first issue isn't yet known to be an issue with PQM.
[03:23] <barry> thumper: i don't know.  i will talk with francis in the morning and get some bugs opened
[03:23] <jml> thumper: although it's a decent place to start, I guess.
[03:23] <thumper> pqm is still pretty fresh in my mind
[03:23] <thumper> so feel free to send them my way if urgent
[03:24] <barry> thumper: thanks.  i think the lack of notification is the most immediate concern.  devs could fix their branch problems if they knew why they bounced
[03:24] <barry> [ACTION] barry to talk with francis and get pqm bugs opened
[03:24] <MootBot> ACTION received:  barry to talk with francis and get pqm bugs opened
[03:25] <barry> that's all i've got.  does anybody have anything not on the agenda?
[03:26] <barry> nope?  okay, thanks everyone! see you next week
[03:26] <barry> #endmeeting
[03:26] <MootBot> Meeting finished at 21:28.
[03:26] <mwhudson> barry: why do you think that branches are getting killed for inactivity?
[03:36] <barry> mwhudson: we don't know.  it shouldn't be happening
[03:36] <mwhudson> barry: no, i mean
[03:37] <mwhudson> barry: what is it that makes you think the branches are being killed in this way?
[03:37] <mwhudson> barry: because i don't see much evidence for it myself
[03:37] <barry> mwhudson: we're just guessing.  it seems like branches are disappearing more now that we bumped that down, but it's just a guess
[03:38] <mwhudson> barry: are the branches disappearing to the extent of not producing logs on devpad?
[03:39] <barry> mwhudson: no, they are producing logs afaict.  mars found one of my disappeared branches in the logs after some clever sleuthing
[03:39] <mwhudson> barry: ok, because grepping logs suggests only two branches have been killed for hanging since the change to a 15 minute timeout
[03:40] <barry> mwhudson: interesting.  i think in my case, bzr actually complained (branch format problem because this was a loomed branch).  so i wonder if more of them are happening because bzr failures don't get notifications
[03:41] <mwhudson> it's possible


[08:12] <duflu> Why is the --host-socket option implemented in the evdev-input driver?
[08:12] <duflu> Oh it's just used