[00:04] <xnox> desrt: or like fix the tests to not assert, or allow error margins on floating point results, since there will be errors.
[00:35] <desrt> xnox: i mentioned before... this is not about having a testcase produce any particular result
[00:36] <desrt> i don't care what the result is
[00:36] <desrt> i only care that if i do the calculation twice, i get the same result both times
[00:36] <desrt> that doesn't seem like too much to ask :)
[00:41] <Fudgey> hi, wondering if anyone can suggest how to elaborate on this, think it is a Compiz problem, Bug #1272131
[00:41] <ubot2`> Launchpad bug 1272131 in compiz (Ubuntu) "Totem regains focus on a window when it is not supposed to." [Undecided,New] https://launchpad.net/bugs/1272131
[05:49] <pitti> Good morning
[08:28] <xnox> desrt: it is too much to ask, all floating point calculation are unstable and will not get same results. http://software.intel.com/sites/default/files/article/164389/fp-consistency-122712_1.pdf is a fun read.
[08:31] <RAOF> pitti: That's not technically true - there *is* a concept of equality for real numbers in mathematics. It's just uncomputable.
[08:32] <pitti> RAOF: well, that depends on which definition of real numbers you want
[08:33] <pitti> RAOF: some are merely uncomputable, some are not even defined
[08:33] <RAOF> Or, rather, a real number is generally defined as an equivalence class.
[08:33] <pitti> RAOF: but I guess  either way, uncomputable already rules out the possibility of using that in a programming language :)
[08:33] <RAOF> Indeed :)
[08:33] <RAOF> If you're talking about decimal expansions, then you've already lost :)
[08:33] <pitti> RAOF: you can't even write down an equivalence class, only some representatives (and then you again can't compare them)
[08:34] <RAOF> Oh, absolutely.
[08:34] <RAOF> There's a legitimate argument in mathematics as to whether real numbers are a well-formed concept.
[08:34] <pitti> I'm a computer scientist, so I refuse AC
[08:35] <RAOF> But if you accept the _existence_ of real numbers, then they've got a well-defined equality. It's just that you can never write down a real number.
[08:35] <pitti> any object which doesn't fit into our universe and requires infinite amounts of energy, information, decisions, and space to write down is not real to me :)
[08:35] <RAOF> Oooh, a hardcore finitist!
[08:36] <pitti> people have done fairly well with finite approximations so far :)
[08:36] <RAOF> Except you can't do any calculus with them.
[08:37] <RAOF> (This is really, really terrible)
[08:37] <pitti> why, we do, without ever having to write down a singlel real number
[08:37] <RAOF> Right, but calculus is defined only for real numbers.
[08:38] <RAOF> Otherwise you find rather awkward things, like the integral of all functions being 0.
[08:39] <RAOF> pitti: You know what's hilarious? My unit tests die with SIGHUP in umockdev_testbed_teardown() when built with gcc, but not with clang.
[08:39] <pitti> you can easily get derivatives of rational functions just purely algebraically
[08:40] <pitti> I don't know how to do the integration algebraically, but ISTR that I've once seen a clever way to do it
[08:40] <pitti> RAOF: oha, which one is that?
[08:40] <pitti> HUP??
[08:40] <pitti> what a strange signal to die with
[08:40] <RAOF> It's “someone's closed your pty”
[08:40] <pitti> ah
[08:41] <RAOF> Which is totally true, apart from the bit where I don't have any fds to the child end of the pty open.
[08:41] <RAOF> Also, it's rather hard to algebraically differentiate such unimportant trancendental functions as, say, sin(x) ☺
[08:43] <pitti> yes, of course, as they are not algebraic in the first place
[08:43] <pitti> but we can only approximately calculate them anyway, so any integration etc. is necessarily also approximate
[08:44] <pitti> except for the usual school book special cases of course
[08:44] <RAOF> Mathematicians are rather unhappy with the whole “just approximate it” schtick :)
[08:44] <RAOF> And you can't approximately derive those special cases.
[08:45] <seb128> good morning desktopers, happy friday!
[08:45] <RAOF> (It's not entirely clear how you'd do a non-infinitesimal integration, and how you'd show that it's the area under the curve. I guess there's always numerical integration, but that's not interesting to mathematicians :P)
[08:45] <RAOF> seb128: Yo!
[08:46] <seb128> RAOF, hey! how are you?
[08:46] <RAOF> I'm good.
[08:46] <pitti> hey seb128
[08:46] <RAOF> I'm wondering what precisely causes gcc to generate code that dies when clang doesn't :)
[08:47] <pitti> RAOF: some race condition perhaps?
[08:47] <RAOF> Ah.
[08:47] <pitti> RAOF: did you strace in both cases? do you actually see the sighup?
[08:47] <RAOF> No.
[08:47] <RAOF> (I added a sighup handler, and it is indeed called)
[08:47] <pitti> perhaps in one case the sighup arrives a tad later when the destructor is already done or so
[08:48] <RAOF> I think there might be a umockdev bugfix release in the near future. It seems that, rather than the difference being clang/gcc, the difference might be umockdev 0.6 vs 0.7.
[08:48] <seb128> pitti, hey, wie gehts?
[08:49] <RAOF>  !!!
[08:49] <RAOF> No, that's not it either?
[08:52] <pitti> seb128: gut, danke! und Dir?
[08:52] <seb128> pitti, auch gut, danke!
[08:54] <pitti> RAOF: you mean it's not related to 0.6 vs. 0.7?
[08:54] <pitti> RAOF: or do you perhaps still have some local clang-built umockdev around? could that be the difference?
[08:54] <RAOF> pitti: Yeah. I've just rebuilt the tests with clang again and... it receives SIGHUP
[08:55] <pitti> RAOF: so it's not clang and it's not the umockdev version?
[08:55] <pitti> just a nice classic nasty race condition?
[08:55] <RAOF> Indeed.
[08:55] <pitti> RAOF: it doesn't try to compare real numbers in the condition to send SIGHUP, does it? :-)
[08:55] <RAOF> For added giggles, it doesn't show up if you *only* run the tests that use umockdev.
[08:56] <RAOF> :P
[08:56] <pitti> RAOF: of course, as that would make debugging easier; can't be
[08:57] <RAOF> What this means is that it's time to fix all of the (many) fd leaks in the unit-tests and see which one unbreaks it.
[09:02] <pitti> RAOF: hm, you think you have some old PTY fds which perhaps time out, and the SIGHUP on those spills over to the next test?
[09:03] <RAOF> Possibly something like that.
[09:03] <pitti> RAOF: you can also try running just that one test in a loop and doing some load in the background (find / > /dev/null, cat /dev/urandom > /dev/null or similar)
[09:06] <Laney> hey
[09:06] <Laney> happy friday
[09:08] <seb128> Laney, hey, you too! how are you?
[09:08] <pitti> hey Laney
[09:12] <Laney> hey seb128, pitti
[09:12] <Laney> I'm doing good thanks!
[09:12] <Laney> and you?
[10:01] <tsdgeos> anyone knows how/where i file against the mesa drivers crashing?
[10:02] <tsdgeos> ah
[10:02] <tsdgeos> found it
[10:02] <tsdgeos> launchpad is such a confusing thing
[10:04] <seb128> tsdgeos, if you need somebody to have a look you can try pining mlankhorst
[10:06] <tsdgeos> mlankhorst: i've got crashes in i965_dri.so in trusty i was not having a few days, filed https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1289243 tell me if you need something else or want me to try anything
[10:06] <ubot2`> Launchpad bug 1289243 in mesa (Ubuntu) "Regression in trusty, i965_dri.so crashes" [Undecided,New]
[10:13] <mlankhorst> tsdgeos: can you try to downgrade mesa to rc1?
[10:15] <tsdgeos> mlankhorst: do you know the exact package name by heart? i mean is it 10.1.0~rc1-0ubuntu1 ?
[10:16] <mlankhorst> ought to be
[10:17] <mlankhorst> 10.1.0~rc1-1ubuntu3
[10:23] <tsdgeos> mlankhorst: hmmm, i guess i'll ahve to build the packages myself? trying to apt-get that version tells me it doesn't exist
[10:25] <mlankhorst> old versions are removed, but still available on launchpad
[10:25] <mlankhorst> https://launchpad.net/ubuntu/+source/mesa/10.1.0~rc1-1ubuntu3
[10:28] <tsdgeos> mlankhorst: ah, cool thanks
[11:14] <tsdgeos> mlankhorst: do i need to restart X?
[11:15] <tsdgeos> Trevinho: ping
[11:19] <mlankhorst> tsdgeos: probably not if the crash is in compiz, but might need to restart opengl applications
[11:20] <tsdgeos> mlankhorst: not in compiz, in a separate app
[11:20] <tsdgeos> mlankhorst: so just starting the app should be ok, no?
[11:31] <mlankhorst> yeah
[11:37] <tsdgeos> mlankhorst: then it still crashes :_
[11:37] <tsdgeos> :/
[11:38] <mlankhorst> can you try 10.0.1-1ubuntu2 ? :P
[11:43] <mlankhorst> afk, can you post the result if it occurs there on that bug, and then ask in #intel-gfx ?
[11:46] <tsdgeos> i guess i can try
[12:00] <tsdgeos> mlankhorst: same thing, that is weird, may it be a kernel regression or something?
[12:00] <tsdgeos> i'll try jumping into  #intel-gfx anyway
[12:01] <tsdgeos> but next week, need to get some work work done
[12:01] <seb128> pitti, so, another trusty regression is that if you have "do nothing on lid close when on power" selected and close the lid docked, the laptop suspends... do you have any debug hint?
[12:03] <pitti> seb128: hm, run gnome-settings-daemon with G_MESSAGES_DEBUG=power (not sure if that works, use "all" if not)?
[12:03] <seb128> pitti, is g-s-d supposed to put a logind inhibit? how do I list those?
[12:03] <pitti> seb128: it coudl either be that gsd doesn't properly evaluate that config option and suspends anyway, or doesn't configure the logind suspend inhibitor properly
[12:04] <pitti> seb128: yes, it is; if there's no g-s-d running (i. e. just text consoles), lid close will be handled by logind
[12:06] <pitti> seb128: hm, I don't quickly find a loginctl command to show inhibitors, but there's a d-bus call; hang on
[12:06] <seb128> pitti, I found that in my tomboy old notes
[12:06] <seb128> gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors
[12:07] <pitti> right, that very
[12:07] <seb128> pitti, http://paste.ubuntu.com/7049587/
[12:07] <pitti>  I get the same here
[12:08] <seb128> same issue on power cord without dock
[12:09] <seb128> so it's not dock specific
[12:09] <pitti> where 5105 ought to be your g-s-d pid
[12:09] <pitti> for me it's unity-settings-daemon, so that seems right
[12:10] <seb128> indeed, that's u-s-d
[12:14] <pitti> seb128: btw, I suggest creating a script which does exit 1 in /usr/lib/pm-utils/sleep.d/00break
[12:14] <pitti> so that it doesn't actually suspend (might ease debugging)
[12:14] <pitti> (needs to be executable)
[12:15] <seb128> pitti, thanks!
[12:23] <desrt> xnox: c99 disagrees with you :p
[12:23] <desrt> as does ieee754
[12:24] <seb128> desrt, good morning, happy friday!
[12:24] <desrt> hi.
[12:25] <xnox> desrt: i'm a human, not a walking set of standards =)
[12:26] <desrt> "damnit jim! ..."
[12:26] <seb128> mhr3_, hey, please fix https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1274669
[12:26] <ubot2`> Launchpad bug 1274669 in libunity (Ubuntu) "scope-runner-dbus.py crashed with signal 5 in g_variant_new_va()" [Medium,Confirmed]
[12:27] <seb128> mhr3_, I just got is with the same steps as the bug description (typed "disk" and ran gdu in dash)
[12:30] <mhr3_> seb128, sounds like a bug in manpages scope
[12:30] <seb128> mhr3_, who maintains that? ;-)
[12:30] <mhr3_> i wonder the same thing
[12:30] <mhr3_> seb128, plus it's python, just remove it :P
[12:31] <seb128> wfm
[12:31] <seb128> mhr3_, https://errors.ubuntu.com/?package=libunity&period=year ... man, your code is buggy!
[13:14] <Laney> pitti: Hm, php5-gearman-dbgsym in ddebs.u.c has no Description: which makes update-apt-xapian-index segfault here
[13:14] <Laney> do you know how that could have happened?
[13:18] <seb128> oh
[13:18] <Laney> bug #1220013
[13:18] <ubot2`> Launchpad bug 1220013 in apt-xapian-index (Ubuntu) "update-apt-xapian-index crashed with SIGSEGV in File()" [High,Confirmed] https://launchpad.net/bugs/1220013
[13:19] <seb128> Laney, thanks for debugging that ;-)
[13:19] <Laney> yeah I got lost in the code for ages
[13:19] <Laney> but it's too hard
[13:19] <Laney> I'm going to brain dump
[13:19] <seb128> I've moved /bin/true over apt-xapian-index earlier in the cycle
[13:19] <seb128> I was tired to get apport prompting me every morning
[13:19] <Laney> yeah me too
[13:19] <seb128> I though it was only me
[13:19] <Laney> so I decided to debug it :P
[13:19] <seb128> I tried to debug for a bit but failed
[13:19] <seb128> well, to be honest I went "ok, that's not trivial, I can't be bothered spending a morning on it"
[13:20] <Laney> yeah that's why I pinged about the origin of the problem
[13:20] <Laney> it violates policy to not have a description there
[13:20] <Laney> fixing that would make the problem go away for ddebs users anyway afaict
[13:21] <seb128> that might not be a code fix but that would already be a good step toward less annoyance for us ;-)
[13:22] <Laney> yeah
[13:22] <Laney> hopefully mvo or don will see the problem
[13:23] <pitti> Laney: not off-hand; it doesn't look any special to me
[13:24] <Laney> It seems correct in the main archive
[13:24]  * pitti builds php-gearman locally in sbuild with ddebs
[13:28] <pitti> Laney: indeed sbuild -d trusty php-gearman_1.1.2-1build1.dsc reproduces that
[13:28] <Laney> ah
[13:28] <Laney> it has some substvar magic
[13:53] <Laney> pitti: http://paste.ubuntu.com/7050008/ ?
[13:55] <Laney> lunch, will look to upload that when I get back if you think it's ok
[13:56] <pitti> Laney: could certainly do with a test case, but if that fixes it, fine for me
[13:56] <pitti> aah, Description: ${phppear:summary}
[14:42] <seb128> bregma, Trevinho: can you please fix the compiz reduce windows by their decoration height before we start on putting a landing ask for the lockscreen?
[14:42] <seb128> bregma, Trevinho:it's creating test issues, it's driving people crazy, it's annoying everyone, that should be an high priority to fix, before new features
[14:49] <pitti> oh, is that related to terminal windows and the keyring dialog now being too small?
[14:50] <mdeslaur_> yeah
[14:50] <Trevinho> seb128: ok, I move to that now
[14:51] <seb128> Trevinho, thanks
[14:51] <mdeslaur_> it's driving me crazy too
[14:51] <Trevinho> that's why at the beinning i accepted windows to go below bottom side :P
[14:51] <mdeslaur_> heh
[14:52] <seb128> Trevinho, well, you should have let it that way until you could fix it properly I guess ;-)
[14:53] <Trevinho> seb128: probably... but I didn't notice at the beginning :P
[14:53] <Sweetshark> seb128: so, I would like to do one more LO/LO-l10n upload for trusty: To get bumped to upstream 4.2.2, to fix bug 1200277 and bug 1288378. Im still collecting random bits and pieces. Can we do that even after next week?
[14:53] <ubot2`> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Medium,Fix committed] https://launchpad.net/bugs/1200277
[14:53] <ubot2`> Launchpad bug 1288378 in libreoffice-l10n (Ubuntu) "libreoffice-help-en-us no longer built" [Undecided,New] https://launchpad.net/bugs/1288378
[14:53] <Sweetshark> seb128: (random bits and pieces include: fixing the autopkgtests for example)
[14:53] <seb128> Sweetshark, https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[14:54] <seb128> Sweetshark, you have some weeks for bug fixes, etc
[14:54] <mdeslaur_> seb128: no! the bottom side bug was driving me insane too! :)
[14:54]  * mdeslaur_ 's sanity only typically hangs with a thread
[14:55] <Sweetshark> seb128: yep, looked at that already. Im aiming for UI freeze, so that Ill make it for ~DocString Freeze ;)
[14:56] <seb128> Sweetshark, sounds fine to me
[14:57] <seb128> mdeslaur_, we should get lightdm on the session bus, that would give enough things to think about and you would stop focussing on those compiz issues ;-)
[14:57] <mdeslaur_> AAAARRRRGH! :)
[14:57] <seb128> ;-)
[14:57]  * mdeslaur_ demotes seb128 to universe
[14:57] <seb128> :-(
[14:58] <seb128> mdeslaur_, be nice of we might claim chrisccoulson back!
[14:58] <seb128> of->or
[14:58] <mdeslaur_> hehehe
[15:08] <Sweetshark> mdeslaur_: dont be nice
[15:09] <Sweetshark> we want chrisccoulson back anyway.
[15:09] <mdeslaur_> hahahaha
[15:09] <mdeslaur_> Sweetshark: he's high maintenance, you should see the beer and steak bills
[15:10] <Sweetshark> mdeslaur_: yeah, he makes me stand out less.
[15:23] <Laney> pitti: I'll see what I can do about a test
[15:23] <Laney> is there a vcs or just the archive?
[15:24] <pitti> Laney: I just use the UDD branch
[15:24] <pitti> i. e. with actual committing, not just auto-importing
[15:24] <Laney> nod
[15:44] <seb128> pitti, hum, turned out my lid close/suspend issue was local screwup in the config (just as a status update)
[15:44] <pitti> seb128: in your gsettings you mean?
[15:45] <pitti> seb128: good to hear
[15:45] <seb128> yes
[15:45] <seb128> pitti, my ipod is still showing the wrong icon though :p
[15:45] <seb128> if you ever get some free slot to debug that
[15:45] <seb128> (I might in fact have a look to it now, good eow debugging I guess)
[15:46] <pitti> ah, I'm just doing some sponsoring now, so let's have a look
[15:49] <pitti> seb128: so it looks like a normal USB drive, right?
[15:50] <pitti> seb128: sorry, I'm afraid I forgot all context
[15:50] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=725390
[15:50] <ubot2`> Gnome bug 725390 in daemon "ipod displayed with an usb key icon" [Normal,Unconfirmed]
[15:50] <pitti> it's an old-style mass storage USB player
[15:50] <seb128> pitti, that has the gvfs-mount output
[15:50] <seb128> but yeah
[15:50] <seb128>   themed icons: [drive-removable-media-usb] [drive-removable-media]
[15:52] <seb128> pitti, http://launchpadlibrarian.net/118396495/gvfs_1.14.0-0ubuntu2_1.14.0-0ubuntu3.diff.gz was the fix you did by then
[15:52] <seb128> pitti, but I guess that "set x-content/audio-player" hack stopped working
[15:53] <pitti> seb128: does your device have ID_MEDIA_PLAYER?
[15:53] <seb128> iirc yes, let me check
[15:54] <pitti> that was supposed to be fixed in https://git.gnome.org/browse/gvfs/commit/?id=4d39b17547648a
[15:55] <seb128> pitti,
[15:55] <seb128> E: ID_MEDIA_PLAYER=apple_video-ipod
[15:55] <seb128> E: ID_MODEL=iPod
[15:55] <seb128> E: ID_MODEL_ENC=iPod
[15:57] <seb128> pitti, hum, https://git.gnome.org/browse/gvfs/log/monitor/udisks2/gvfsudisks2mount.c ... that file didn't change much since
[15:57] <pitti> yes, the code is still there
[15:57] <pitti> seb128: what's the gvfs-mount -i output while the device is mounted?
[15:58] <seb128> pitti, what's in the bugzilla I pointed you, or do you need more?
[15:58] <pitti> seb128: sorry, -li
[15:58] <pitti> seb128: ah right, sorry
[15:58] <pitti> seb128: hm, no, I want hte mount
[15:58] <pitti> or the volume, not the drive
[15:59] <seb128> pitti, http://paste.ubuntu.com/7050647/
[15:59] <pitti> symbolic themed icons:  [drive-removable-media-usb-symbolic]  [
[16:01] <pitti> ok, so no music player
[16:01] <pitti> actually, what's that "media"?
[16:01] <seb128> pitti, https://git.gnome.org/browse/gvfs/commit/monitor/udisks2?id=dff2d84d15b7a62a162031f2da3015e989c0eadc
[16:01] <pitti> as in "USB medium", or as in "music/video"?
[16:02] <seb128> well I guess that doesn't apply here
[16:02] <pitti> seb128: ah, so it gets the icon straight from udisks
[16:02] <pitti> ?
[16:02] <pitti> right, we have a drive
[16:02] <seb128> pitti, well, for symbolic icons, yes
[16:02] <seb128> https://git.gnome.org/browse/gvfs/commit/monitor/udisks2?id=d2273d404cb3e895ba67052dde4a3e85b1c084ba
[16:02] <seb128> that commit doesn't change the non-symbolic codepath though
[16:04] <pitti> seb128: do you have anything "Icon"ish in udisksctl dump?
[16:05] <pitti> (which could override the detection)
[16:05] <pitti> sorry, it's too long ago that I looked at all this stuff, I don't remember the details any more
[16:05] <pitti> so this needs some deeper debugging
[16:05] <seb128>     HintIconName:
[16:05] <seb128> no
[16:05] <seb128> pitti, no worry, I guess I can debug myself, I thouh maybe you would know offhand where to look
[16:52] <bregma> seb128, I have a couple of client-track BPs for UDS that need approval, would you like to do the honours?
[16:53] <seb128> bregma, sure
[16:53] <bregma> do you need a link or is there a magic queue somewhere?
[16:53] <seb128> urls please
[16:54] <bregma> https://blueprints.launchpad.net/ubuntu/+spec/client-1403-unity7-defaults-and-settings
[16:54] <bregma> https://blueprints.launchpad.net/ubuntu/+spec/client-1403-unity8-desktop-session
[16:54] <bregma> c'est ca
[16:57] <seb128> bregma, hum, I can add them, but the first one seems not so much content for a session (I'm also not sure a session is the right venue to decide on defaults, everybody is going to have an opinion but there is no way to determine who is right)
[16:57] <seb128> bregma, the second one, it seems a bit late in the cycle to discuss plans that still apply to this cycle?
[17:00] <bregma> seb128, the second one is more for discussing plans for what will land after release to trusty, since the Touch work does not follow Ubuntu release cycles per se
[17:00] <seb128> bregma, ok, unity8 one approved
[17:03] <bregma> seb128, as to the first one, I would think a public community discussion of the defaults and settings is entirely appropriate, although yes the content may be a bit thin ... it's up to you to approve or reject, I'm completely fine with either one
[17:04] <bregma> really.
[17:04] <seb128> bregma, I'm approving it, the schedule as space, but by experience that doesn't seem like an useful session ;-)
[17:04] <seb128> (it's like the "default apps" sessions we stopped to have)
[17:04] <seb128> you are going to have people who tell you why they hate the integrated menus
[17:04] <seb128> and some who tell you why they hate the local menus
[17:05] <seb128> and that's going to be an argument for the length of the session
[17:05] <seb128> with an akward "so, what do we do"
[17:05] <mitya57> seb128: Hi, can you please look again at my nautilus MP? That blocks moving Flashback to u-s-d, which blocks new g-s-d upload darkxst wants to do.
[17:05] <bregma> yes, I anticipate Fun
[17:06] <seb128> mitya57, hey, I can try have a look when I'm done with what I'm doing, though it's getting late so it might be on monday
[17:06] <seb128> mitya57, I still don't understand why we have that classic .desktop and why those sessions are different from unity in how they start nautilus
[17:08] <mitya57> darkxst: ^ Any idea?
[17:08] <ara_> seb128, I would like to see the unity7 one approved (and attend), as those are very important features for our customers, so it would be a good way to know what's there and what's not
[17:09] <ara_> (high dpi, not local menus)
[17:09] <mitya57> The AutostartCondition is "GSettings org.gnome.desktop.background show-desktop-icons", so that shouldn't be an issue.
[17:11] <seb128> ara_, I don't see what there is to discuss on hi-dpi, the factor should scale with the dpi value, the level is probably better determined by user testing than by a discussion
[17:11] <seb128> bregma, ara_: anyway, approved, let's see how useful that turns out to be
[17:13] <seb128> ara_, I would expect e.g oems to define their default scale value for a particular model and tweak that by model
[17:14] <ara_> seb128, yes, but I would like to know more what's going to happen with gtk apps, and with browsers. currently they don't scale with unity
[17:15] <seb128> ara_, yeah, that one is a good point to discuss, though the GTK factor is an int, so the best we can do is probably to round the value of our factor and apply the gtk value the closest
[17:20] <ara_> seb128, yes, I guess that's the best we can have, but yes, some open discussion during UDS seems like a good thing to have
[17:20] <seb128> ara_, yeah, let's see, doesn't hurt to have a session, even if it's a short one
[18:03] <Laney> ok, got to get a train
[18:03] <Laney> happy weekend!
[18:08] <didrocks> Laney: needing a silo? (kidding :p)
[18:08] <didrocks> happy weekend Laney!
[19:22] <attente> bschaefer: does ibus' candidate window pop up for you?
[19:23] <bschaefer> attente, i dont seem to have ibus running atm :)
[19:23]  * bschaefer stats it up
[19:23] <attente> heh
[19:24] <bschaefer> attente, nope, i also dont get the preedit window :(
[19:25] <bschaefer> let me update though, its been a few days
[19:49] <bschaefer> attente, soo preedit window back, but no candidate window
[19:49] <bschaefer> the candidate window is the little pop up box that show you possibly languages to switch to? (Somewhat like a language switcher?)
[19:52] <attente> bschaefer: candidate window shows the list of characters that match the current preedit text
[19:52] <attente> also called the lookup table in ibus' api
[19:52] <bschaefer> attente, sound like the preedit pop up window to me :), i might be mistaken
[19:52] <bschaefer> i have it though
[19:53] <attente> bschaefer: do you know what you did to get it back?
[19:53]  * bschaefer doesn't really know the correct names for things in ibus haha
[19:53] <attente> i'm fully updated
[19:53] <bschaefer> attente, i just updated
[19:53] <bschaefer> hmm
[19:53] <bschaefer> attente, and killed the daemon
[19:53] <bschaefer> and restarted it
[19:53] <bschaefer> killall ibus-daemon; ibus-setup (which restart it for you with a message)
[19:54] <attente> bschaefer: thanks, that worked
[19:54] <bschaefer> attente, yay!
[19:55] <attente> bschaefer: quite strange though...
[19:55] <bschaefer> attente, hopefully...thats not needed every login though
[19:56] <attente> bschaefer: could be an indicator-keyboard bug
[19:56] <bschaefer> attente, hopefully not...was your system fully updated on the last login?
[19:57]  * bschaefer hopes your daemon was just out of date :)
[19:57] <attente> bschaefer: yes, it was
[19:57] <bschaefer> shoot, it could also be one of the settings possibly attached to the daemon when started
[19:57] <attente> bschaefer: so it's working for you now, right
[19:58] <attente> bschaefer: can you do killall indicator-keyboard-service?
[19:58] <attente> then try again?
[19:59] <bschaefer> yeah
[19:59] <bschaefer> attente, back to preedit window broken :(
[19:59] <bschaefer> or candidate window broken :(
[20:00] <bschaefer> thats not goo
[20:00] <bschaefer> d
[20:01] <attente> bschaefer: ok, at least i know where the problem is thanks to you :)
[20:01] <bschaefer> attente, np! Good luck!


[05:13] <Kilos> hi bduk mazal and others
[05:13] <Kilos> more nuvolari
[05:23] <bduk> More almal
[05:29] <mazal> Môre oom
[05:50] <Symmetria> hrm
[05:50] <Symmetria> morning
[05:50] <Symmetria> dont suppose anyone here happens to be sitting behind the tenet backbone and can do a traceroute for me?
[05:57] <Squirm> bushtech_: thanks
[05:58] <Squirm> Symmetria: I can
[05:58] <Squirm> wait, no... I used to be with ESN
[05:58] <Squirm> and I dont think I was linked to the backbone :P
[05:58] <Squirm> nevermind
[05:58] <Symmetria> squirm heh, even on ESN
[05:58] <Symmetria> it might still use TENET
[05:59] <Symmetria> heh do a trace and see if it uses TENET at all or uses some other route :)
[05:59] <Squirm> we're now with mweb
[05:59] <Symmetria> am trying to see if they are returning traffic to me at NAP or at JINX, Im hoping its NAP else Im gonna screw our JINX connection horribly with a 16 terabyte transfer
[05:59] <Symmetria> ;p
[06:00] <Squirm> I don't know who would have access to that
[06:00] <Squirm> morning Kilos
[06:00] <Kilos> hi Squirm
[06:00] <Kilos> something buggy here
[06:00] <Squirm> Symmetria: do you not have a little shell account hidden away somewhere?
[06:01] <Kilos> one gmail account doesnt work from evolution but shows a popup that there should be a mail received
[06:06] <Kilos> sjoe net sick somewhere
[06:06] <Kilos> download rate 460 B/s
[06:07] <Kilos> eish now 230 B/s
[06:07] <Squirm> blame Symmetria
[06:08] <Kilos> Symmetria, what have you broken now
[06:09]  * Kilos changes repos
[06:09] <Squirm> http://www.speedtest.net/my-result/3629915755
[06:11] <Kilos> http://www.speedtest.net/my-result/3629918145
[06:12] <Squirm> that's not bad then
[06:12] <Kilos> how come my upload speed is faster than yours
[06:12] <Squirm> I don't know
[06:14] <Squirm> but I'm happy with a decent download speed
[06:14] <Kilos> yeah that one is great
[06:18] <Kilos> thats better. using ftp.sun.co.za now
[06:20]  * superfly pokes Kilos
[06:20] <Kilos> ohi superfly
[06:21] <Squirm> hello superfly
[06:21] <superfly> hi Kilos, Squirm
[06:21] <nuvolari> o/ oh hi oom Kilos, Squirm, superfly
[06:22] <Squirm> hey nuvolari
[06:24] <Kilos> gone up Squirm http://www.speedtest.net/my-result/3629933176
[06:24] <Squirm> nice
[06:25] <Kilos> not bad for 3g
[06:25] <Squirm> and to get our speeds, we have bonded 4x4mb lines
[06:25] <Kilos> but i want it faster
[06:25] <Squirm> happens when you live in the sticks
[06:26] <Kilos> you guys should have ftth thing
[06:31] <Symmetria> Squirm as a matter of interest, what do you get from the speedtest server in kenya at liquid?
[06:32] <Symmetria> http://www.speedtest.net/my-result/3629943405 <[06:35] <Kilos> oh wow Symmetria
[06:35] <Kilos> so where is the fast ubuntu mirror?
[06:35] <Symmetria> kilos heh, its installed and running, waiting for canonical to sort out the DNS
[06:35] <Symmetria> ubuntu-archive.mirror.liquidtelecom.com
[06:36] <Symmetria> waiting for them to add me to the TLD mirror dns :(
[06:36] <Kilos> rev them
[06:36] <Kilos> our local mirrors are very unstable lately
[06:36] <Symmetria> last I checked my ticket was #30 in the queue ;p
[06:37] <Kilos> when was that?
[06:40] <Symmetria> yesterday :)
[06:40] <Kilos> ah
[06:53] <nuvolari> whut? did we have the splits?
[06:54] <Kilos> not that i can see nuvolari
[06:59] <Kilos> only peer got bushtech
[07:00] <Kilos> his peer is vodaflop
[07:04] <nuvolari> what was my message oom Kilos ?
[07:04] <Kilos> nuvolari> whut? did we have the splits?
[07:09] <mazal> nuvolari has quit (Ping timeout: 240 seconds)
[07:09] <mazal> nuvolari, ^
[07:09] <Kilos> oh up there, sorry
[07:10] <Kilos> only affectred 4 peeps
[07:10] <nuvolari> :O I didn't quit! pfft,
[07:10] <Kilos> Tonberry has quit (Ping timeout: 260 seconds)
[07:10] <Kilos> * nuvolari has quit (Ping timeout: 240 seconds)
[07:10] <Kilos> * ThatGraemeGuy has quit (Ping timeout: 240 seconds)
[07:10] <Kilos> * georgl has quit (Ping timeout: 240 seconds)
[07:15] <Kilos> hi Spekko , which one are you now
[07:15] <Kilos> the one by jabberwocky or the old one
[07:17] <inetpro> goeie more
[07:17] <Kilos> more inetpro
[07:20] <nuvolari> think the server we connected to pinged out
[07:20] <nuvolari> môre inetpro
[07:20] <charl> good morning Kilos, inetpro, nuvolari, mazal
[07:20] <charl> and Symmetria :)
[07:20] <Kilos> hi charl
[07:21] <mazal> Morning charl
[07:21] <charl> Maaz: coffee on
[07:22]  * Maaz flips the salt-timer
[07:22] <nuvolari> oh hi charl
[07:22] <nuvolari> Maaz: espresso please
[07:22] <Maaz> nuvolari: *blink*
[07:22] <nuvolari> not here Maaz
[07:22] <charl> afk i'm drinking a double espresso right now actually
[07:22] <charl> haha nuvolari
[07:22] <nuvolari> Maaz: coffee please
[07:22] <Maaz> nuvolari: Done
[07:23] <charl> i knew there was something going on between the two of you :P
[07:25] <Squirm> Symmetria: http://www.speedtest.net/my-result/3630009256
[07:25] <Squirm> Maaz: coffee please
[07:25] <Maaz> Squirm: Sure
[07:25] <Squirm> largest
[07:25] <Squirm> Maaz: largest
[07:25] <Maaz> Whew do you want a bath full Squirm?
[07:25] <Squirm> mwhahahahaha
[07:26] <Maaz> Coffee's ready for charl, nuvolari and Squirm!
[07:26] <nuvolari> thank you Maaz
[07:26] <nuvolari> Maaz: Thanks
[07:26] <Maaz> nuvolari: Okay :-)
[07:28] <Squirm> Maaz: botsnack
[07:28] <Maaz> Thank you thank you, munch munch chomp chomp
[07:33] <charl> Maaz: thanks
[07:33] <Maaz> charl: Okay :-)
[07:34] <Symmetria> FPD upgrade in progress. Max timeout remaining 84 min.
[07:34]  * Symmetria snores at his routers
[07:37] <charl> field programmable device ?
[07:37] <charl> Symmetria: ^^
[07:44] <Symmetria> yeah
[07:44] <Symmetria> someone remind me of the vi search and replace syntax to replace the first instance found on every line
[07:46] <nuvolari> :%s/search/replace/
[07:46] <nuvolari> I think
[07:46] <nuvolari> :P
[07:46] <nuvolari> Symmetria: ^^
[07:46] <charl> yes % is for every line (not just the current) and if you leave the g off at the end it will only do the first occurrance
[07:47] <charl> just tested it, it works
[07:47] <Symmetria> thanks
[07:47] <Symmetria> that worked
[07:47] <charl> :)
[09:49] <ThatGraemeGuy> moo
[09:50] <Kilos> haha hi ThatGraemeGuy
[09:50] <ThatGraemeGuy> how's things? :)
[09:50] <Kilos> you been on the grass again
[09:50] <ThatGraemeGuy> oi if only
[09:50] <Kilos> ok ty and you?
[09:50] <ThatGraemeGuy> busybusybusy
[09:50] <ThatGraemeGuy> taking a breather
[09:50] <Kilos> yeah looks like
[09:50] <ThatGraemeGuy> check up on my electrical grid in minetest
[09:51] <Kilos> i used your grinder last night and stole 8 marble blocks
[09:51] <ThatGraemeGuy> haha ok
[09:51] <Kilos> i dont know how you did it all, where did you get rubber from
[09:52] <ThatGraemeGuy> you building a hydro generator?
[09:52] <Kilos> i made some things but they need a network
[09:52] <Kilos> i tried a few things
[09:52] <ThatGraemeGuy> you build a thing called a tree tap, then you hit rubber trees with it
[09:52] <ThatGraemeGuy> to extract raw latex
[09:52] <Kilos> must the hydro one be near water?
[09:52] <ThatGraemeGuy> you see when you punch the tree the texture changes
[09:53] <ThatGraemeGuy> then you can cook raw latex to make rubber
[09:53] <ThatGraemeGuy> in a furnace, you get 1 rubber for 1 raw latex
[09:53] <Kilos> any tree?
[09:53] <ThatGraemeGuy> but if you use an extractor you get 3 rubber per raw latex
[09:53] <ThatGraemeGuy> no, rubber tree
[09:53] <ThatGraemeGuy> i planted 2 close to your house
[09:53] <Kilos> where are they?
[09:53] <Kilos> oh my goodness ty will look into that
[09:54] <ThatGraemeGuy> its a huge tree you can't miss it
[09:54] <ThatGraemeGuy> and as always, if you search for rubber in the craft guide you can figure out how to obtain it
[09:54] <Kilos> didnt get data yet so can only look tonight
[09:54] <Kilos> your stuff works kiff
[09:54] <ThatGraemeGuy> and yes, i'm going to mention the craft guide every time, until you remember :P
[09:54] <ThatGraemeGuy> yeah
[09:54] <ThatGraemeGuy> you should see the 2 "tool workshop" boxes
[09:55] <Kilos> man i use the guide but there is always something i dont have
[09:55] <ThatGraemeGuy> you can place any worn tools in it and they regenerate
[09:55] <ThatGraemeGuy> pickaxe, axe, shovel, etc
[09:55] <Kilos> wow
[09:55] <ThatGraemeGuy> and i wouldn't worry with the hydro generator btw, just start making solar panels
[09:55] <ThatGraemeGuy> much better
[09:56] <ThatGraemeGuy> a basic circuit must have these things:
[09:56] <Kilos> ok i think i put it on my floor to make space in inventory
[09:56] <ThatGraemeGuy> something that generates electricity, e.g. solar panel or solar array
[09:56] <ThatGraemeGuy> a switch box
[09:56] <ThatGraemeGuy> a battery
[09:56] <ThatGraemeGuy> something that uses power
[09:56] <Kilos> there are things in the solar panels i still have to find or procure
[09:57] <ThatGraemeGuy> it gets more complicated with high, medium and low voltage, but that's the basic thing
[09:58] <ThatGraemeGuy> you can check out my setup if you want, but that might be confusing since i already have high, medium and low voltage networks set up
[09:58] <Kilos> but your place is looking good. i like the goodies on the chests to show what is inside
[09:58] <superfly> oooo, hydro? I wanna do that
[09:58] <ThatGraemeGuy> it's LV-only, as far as i can tell its meant to be a cheaper option to get started
[09:58] <Kilos> my house was getting too small so i had to put chests in the wall
[09:59] <ThatGraemeGuy> and doesn't burn coal like the fuel-powered lv generator
[10:04] <Kilos> we can put a hydro one at the dams waterfall. water with that kind of drop should power a genny that can supply the world
[10:04] <superfly> ThatGraemeGuy: where's the crafting guide?
[10:05] <ThatGraemeGuy> :-o
[10:05] <ThatGraemeGuy> for reals?
[10:05] <ThatGraemeGuy> press I
[10:05] <ThatGraemeGuy> click on a thing
[10:05] <ThatGraemeGuy> in the right side
[10:05] <ThatGraemeGuy> or search for it and then click
[10:05] <superfly> That doesn't work for me
[10:05] <ThatGraemeGuy> then on the left you see if its an ingredient or a result
[10:05] <superfly> when I click I get 99 of that item...
[10:05] <Kilos> aw
[10:06] <ThatGraemeGuy> then /set cheater_mode off
[10:06] <ThatGraemeGuy> :P
[10:06] <superfly> (probably because I'm server admin)
[10:06] <ThatGraemeGuy> ok i dont know why that happens it should only do that in creative mode
[10:06] <superfly> it's annoying when you want to know how to craft stuff
[10:06] <ThatGraemeGuy> maybe there should be a separate admin account that isn't the one you use for general play
[10:06] <ThatGraemeGuy> dunno how else to get around that
[10:07] <Kilos> the new guide shows lots but everything needs 3 or more other things you have to go find first
[10:07] <superfly> remove my name from the minetest.conf file
[10:08] <ThatGraemeGuy> hang on
[10:09] <mazal> superfly, it's the creative permissions
[10:09] <mazal> Admin should just /revoke yourname creative
[10:10] <mazal> I had the same problem
[10:11] <superfly> OK, I'll try that
[10:13] <ThatGraemeGuy> ok you are no longer the server admin
[10:13] <ThatGraemeGuy> i created a "superadmin" user
[10:14] <superfly> OK, cool
[10:18] <charl> good afternoon foolks
[10:18] <charl> *folks
[10:18] <charl> what a mess of a morning - problems problems problems here
[10:19] <mazal> Hi charl
[10:20] <Kilos> hi charl
[10:23] <Kilos> forget problems man, just find solutions
[10:23] <charl> lol
[12:59] <Squirm> Kilos: Rectron is a little cheapr
[12:59] <Squirm> so... I'm getting a new PC :D
[13:00] <Kilos> cook
[13:00] <Squirm> cook indeed
[13:01] <Squirm> and then maybe
[13:01] <Squirm> just maybe...
[13:01] <Squirm> I might get myself an SSD next month
[13:07] <Squirm> only be ready for collection on Monday though
[13:13] <Kilos> lol cool man
[13:13] <Kilos> do you have a pricelist from them Squirm
[13:15] <Kilos> i want to get a 1tB drive end of this month. then everything in this pc is newly aquired
[13:15] <Kilos> then saving starts for an i5 cpu
[13:37] <Kilos> i heard somewhere that an i7 is only 10% faster than an i3, is that true
[13:37] <Kilos> not twice as fast with the extra threads?
[13:40] <Squirm> I don't know
[13:41] <Squirm> so, I got a quote for that PC I want
[13:41] <Squirm> then I thought to hell with it
[13:41] <Squirm> and spent more :/
[13:41] <Kilos> lol
[13:41] <Squirm> so I'm getting myself a 120Gb SSD and 6Gb of RAM instead of 4
[13:41] <Squirm> s/6Gb/8Gb
[13:41]  * Squirm grumbles
[13:42] <Squirm> it'll keep me happy for a while
[13:42] <Kilos> that should make a big diffs then
[13:42] <Squirm> for the first time
[13:42] <Squirm> ever
[13:42] <Squirm> I have a pretty good PC
[13:42] <Kilos> haha like my i used old discard pcs till i bought this one
[13:42] <Kilos> like me
[13:43] <Squirm> I have 3 full 1Tb HDD's, with about 100Gb free in total. One of them is dying
[13:43] <Squirm> I hoard movies/series
[13:43] <Squirm> and can't afford another HDD
[13:43] <Squirm> so I now have to get rid of 1Tb of... stuff
[13:43] <Kilos> eish
[13:44] <Kilos> if you got uncapped put it in the clouds somewhere
[13:44] <Squirm> we have a media NFS at work :P
[13:44] <Kilos> NFS?
[13:45] <Squirm> umm
[13:45] <Squirm> NAS
[13:45] <Kilos> lol NAS?
[13:45] <Squirm> Network Attached Storage
[13:45] <Kilos> aha
[13:45] <Kilos> thats lekker
[13:45] <Squirm> it's a server, with 6Tb of space
[13:45] <Squirm> well, more of a small box
[13:45] <Squirm> and all it does is store data :P
[13:45] <Squirm> well, media, for the staff
[13:46] <Kilos> one day ill build myself a nice system and server
[13:46] <Squirm> 68% Full at the moment
[13:46] <Kilos> but you got space to plug in another drive havent you
[13:47] <Kilos> on the nas that is
[13:47] <Squirm> no, it has 4x2Tb drives. In Raid 5
[13:47] <Kilos> ai!
[13:47] <Squirm> which means you lose the space of 1 of the drives. but if one drive fails, you don't lose any data
[13:48] <Kilos> raid is when the drives carry data so if one crashes the data isnt lost right?
[13:48] <Kilos> lol myou too fast
[13:48] <Squirm> it depends on the array
[13:48] <Squirm> with raid 5, your server will carry on running, except it'll be very slow
[13:49] <Kilos> ok
[13:49] <Squirm> and we have hot-swappable drives. so if one dies, you just pull it out and plug a new one back in and it rebuilds itself
[13:49] <Kilos> cool
[13:49] <Squirm> one of our main server drives died the other day. We never had any down time, it was just painfully slow. took about 24 hours to rebuild the drive
[13:50] <Kilos> networking is interesting
[13:50] <Squirm> and that's not even a very large drive... I don't want to know what data centres go through
[13:50] <Kilos> ask andrew
[13:50] <Squirm> speaking of which. I have to go and connect up this point... I'll be back in a bit
[13:50] <Kilos> ok
[13:51] <Squirm> Symmetria: what's the rebuild time on a 4Tb+ drive
[13:51] <Squirm> ?
[13:55] <Spekko> Hey Kilos only see your message nauw O.o
[13:55] <Spekko> Was quite busy at work
[13:55] <Spekko> I'm the original one and only spekko
[13:55] <Spekko> howcome?
[13:57] <Kilos> that other guy there by wocky came on as you first then changed his nick
[13:57] <Kilos> they said you left
[14:04] <Spekko> I left the company wocky is working at
[14:04] <Spekko> So I'm still that same Spekko
[14:05] <Spekko> That company is shite...   It is better to stay a representative for the values that have been garnered over the years
[19:49] <Kilos> lol
[19:49] <Kilos> you starting to sound like a ballie
[19:49] <Gremble> :P
[19:51] <Kilos> question tumbleweed , has ibid stopped growing?
[19:52] <Kilos> uh oh
[19:52] <Kilos> that didnt last long
[19:53] <thebearnado> I don't like gremble_ so one is Gremble and the other thebearnado :P
[19:53] <Kilos> values fell by the wayside
[19:53] <Kilos> ah for disconnects
[19:53] <thebearnado> Logged in on the same nick with 2 machines
[19:54] <Kilos> make one grumble then they at least close
[20:07] <superfly> Kilos: ping
[20:08] <Kilos> superfly, pong
[21:22] <nuvolari> hrr.
[21:23] <nuvolari> any HR experts around?
[21:30] <charl> nuvolari: human resources?
[21:30] <nuvolari> charl: yeah
[21:31] <charl> nope sorry
[21:31] <charl> i'm off to bed
[21:31] <charl> nn
[21:31] <nuvolari> good night
[21:39] <Kilos> ai! nuvolari jy moet gaan slaap man
[21:41] <Kilos> Maaz, tell ThatGraemeGuy your server isnt letting anyone connect
[21:41] <Maaz> Kilos: Got it, I'll tell ThatGraemeGuy on freenode
[22:28] <Kilos> night all. sleep tight


[01:28] <mondeq> gandang umaga!
[01:29] <mondeq> pwede bang magtanong regarding sa skype...kasi palagi na lang kailangan kong copy past sa terminal ko para ma-activate yung video call
[02:00] <mondeq> ???
[02:00] <mondeq> wala po bang pwede pagtanungan dito?
[10:52] <ubuntu-ph> weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
[10:52] <ubuntu-ph> weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee


[06:52] <dholbach> good morning
[15:36] <bkerensa> popey: so I might be coming to London if you want to grab a beer :) the BBC invited me to come give a talk
[15:36] <popey> heh, when?
[15:37] <bkerensa> popey: Don't have a date they just invited me a few hours ago :)
[15:37] <popey> coolio
[15:38] <popey> let us know, I'll arrange to be in the office
[16:39] <dholbach> all right my friends - I call it a day - have a great weekend everyone
[16:39] <dholbach> Germany is off of work tomorrow :)
[16:42] <dholbach> *wave*
[22:43] <hggdh> pleia2: there?
[22:44] <hggdh> or, actually, anyone from the CC... I an preparing the request for candidates for the IRCC, to cover two open slots (IdleOne, that resigned last year, and AlanBell, that just announced to us his intention to leave).
[22:46] <hggdh> I wanted to know up to when I should set the application deadline
[22:47] <belkinsa> hggdh, e-mail the CC?
[22:47]  * silverlion would be interested to learn the necessary items to apply
[22:49] <hggdh> belkinsa: I will copy the CC, then. But I wanted to send it out ASAP -- so I will leave the deadlne to be decided later.
[22:49] <belkinsa> Ah, I see.
[22:50] <hggdh> silverlion: the email will be sent to the IRC team, the News team, and the CC. A link to the wiki, and a summary of requirements will be available in the email
[22:50] <silverlion> hggdh : thank you!
[22:50] <hggdh> belkinsa: one of the reasons for sending it out now is to try to accelerate the process a bit
[22:50]  * silverlion is thinking to apply for a slot
[22:51] <hggdh> er. What is the CC email address?
[22:51] <hggdh> silverlion: we are open-minded :-)
[22:51] <silverlion> hggdh sorry?
[22:51] <belkinsa> hggdh, checking...
[22:51] <belkinsa> ....
[22:52] <hggdh> silverlion: there is no requirement to be an experienced IRC ops
[22:52] <silverlion> great. but as I am online every evening I feel that I could help there too
[22:52] <silverlion> but == and
[22:52] <hggdh> cool
[22:53] <belkinsa> hggdh<EMAIL_ADDRESS>[22:53] <hggdh> belkinsa: thank you very much
[22:53] <belkinsa> You have the news team address from the mebership board e-mail  that I sent
[22:53] <belkinsa> NP
[22:55] <silverlion> gn8
[22:55] <belkinsa> slaapwel, silverlion
[23:15] <hggdh> OK, email sent.
[23:31] <pleia2> hggdh: home now :) thanks
[23:32] <pleia2> I'll follow up with other CC-ers as to the deadline
[23:57] <hggdh> pleia2: thank you


[14:46] <qwebirc29292> Error message: Could not connect to the master backed server.  Is the IP address set for it in mythtv-setup.  One box has front end and backed both pointing to the boxes ip <IP_ADDRESS>.  Any ideas?
[20:32] <KjetilK> Hmmm, seems like the kernel-based lirc isn't using the  ~/.lirc/mythtv config, as most of the keys of the remote isn't working
[20:32] <KjetilK> can anyone shed any light?


[02:42] <tsimonq2> under "What do you need help with?" on https://wiki.ubuntu.com/Kernel/GettingInvolved , it shows an outdated link and I don't know where the real link would be.
[03:59] <dsmythies> tsimonq2, I fixed the link. Try it now.
[08:29] <apw> dsmythies, it is a consequence of CONFIG_ZONE_DEVICE turning off CONFIG_ZONE_DMA yes
[09:06] <apw> dsmythies, not convinced the constraints are reasonable, at least for x86_64 where you don't have HIGHMEM so i think there is room for both though the config constraints prevent that
[09:06] <apw> dsmythies, is that card used for something we are going to notice, like qemu ?
[11:38] <tsimonq2> thanks dsmythies
[13:26] <rtg> caribou: could you have a look at bug #1528101 and tell me if kexec is functioning as designed ?
[13:27] <caribou> rtg: sure
[13:28] <apw> caribou, not sure if we have any sane way generically to know which options are good to keep and which are not for a kdump kernel, i wonder if we almost want a separate directory of overrides for kdump.
[13:29] <caribou> apw: I've been running tests to try to come up with some sensible rules for the definition of crashkernel
[13:30] <caribou> but there are so many variables that come into play that it is kinda hard
[13:30] <caribou> for instance, I've been testing on VM with up to 22Gb : the default 128M works fine
[13:31] <apw> so we might just say that this one is a speicifc override to be osmething sane like 1%
[13:31] <apw> and be happy
[13:31] <caribou> apw: but when I test on real hardware with 128G of memory, crashkernel=128M comes short not because of the memory but because of the fact that initrd is bigger and it OOMs
[13:32] <apw> caribou, ok, even with your magic smaller one ?
[13:33] <apw> so an =dep initrd is still too big for 128M /
[13:33] <apw> ?
[13:33] <caribou> apw: that was on trusty so the change was not there; I went on to rebuild with MODULES=dep & got bitten by the initramfs-tools bug that I fixed
[13:33] <caribou> apw: it works now with a smaller initrd
[13:33] <apw>  ahh ok
[13:34] <apw> of course this bug might be moot with that fix too, hrm
[13:34] <caribou> apw: but in this case, the boot sequence fails before kdump even comes into play
[13:34] <caribou> apw: partly, on system with SSDs, the kernel hook would fail when building the smaller initrd file
[13:35] <apw> which we should fix i assume
[13:36] <apw> for this bug, they are setting min_free somewhere, presumably in /etc/sysctl.d.conf and we really should not be honouring that in the constrained environment
[13:36] <apw> its not clear how one would know that though programatically
[13:36] <caribou> apw: LP: #1532146 is waiting for a sponsor if you have a minute ;-)
[13:37] <apw> caribou, yeah its on my todo list :)  i have another initramfs-tools bodge to ram in, just updateing aufs for a nasty hang bug
[13:37] <caribou> apw: that's fine, as long as it is queued to be fixed somewhere
[13:38] <caribou> apw: in that case (LP: #1532146), it doesn't even make it to kdump & fails before
[13:38] <caribou> apw: so you're right, we should find a way to boot the kexec kernel w/o using any tailored sysctl values
[13:39] <caribou> oups, wrong bug : bug #1528101
[13:39] <caribou> rtg: so for your question : kexec doesn't even get activated so yes, works as designed ;-)
[13:41] <rtg> caribou: since I don't really understand the fine points of the discussion, I'll bug apw and make him explain it.
[13:43] <caribou> apw: everything in /etc/sysctl.conf + /etc/sysctl.conf.d should not be honoured when the kexec kernel boots
[13:44] <apw> caribou, should not as in you think they are not, or you think they are and shouldn't ?
[13:45] <caribou> apw: looks like they are (if indeed they hare changing vm.min_free_kbytes with sysctl)
[13:46] <caribou> apw: so when the kexec kernel boots post-panic, the kernel should boot w/o implementing what's in sysctl.conf[.d] if possible
[13:47] <caribou> apw: the kexec kernel is only there to allow for the capture of the kernel dump
[13:47] <caribou> apw: so there is no reason to apply any user-define customization there
[13:47] <caribou> am I being clear ?
[13:48] <rtg> caribou: that makes sense to me
[13:49] <caribou> apw: rtg: it should be trivial to add a check in /etc/init.d/procps to verify if we have booted in the kexec kernel & not apply the changes
[13:49] <rtg> caribouhow would you preserve the original sysctl values ?
[13:50] <rtg> nm, the new kernel would have them as part of its image.
[13:51] <caribou> apw: rtg: /proc/vmcore is only present if we are booted on the kexec kernel post-panic. This is how kdump-config knows that it has to capture the content
[13:51] <rtg> caribou: what agent applies sysctl values to the kexec kernel ? kdump ? the initrd ?
[13:52] <tseliot> rtg: I've just fixed fglrx in xenial. It was pretty easy this time
[13:52] <caribou> rtg: /usr/sbin/procps apparently
[13:52] <caribou> rtg: no, /etc/init.d/procps
[13:52] <rtg> tseliot, thanks, it was the primary show stopper for a 4.4 kernel in xenial
[13:52] <tseliot> good :)
[13:55] <ricotz> rtg, tseliot, nice :)
[14:00] <apw> caribou, yeah, that sounds like a sensible option, i might suggest it ought ti possibly have a kdump.conf.d or osmething which is applies instead, just in case there is something you need
[14:01] <caribou> apw: make sense; the override would only apply kdump.conf if it exists
[14:02] <apw> caribou, then in the unlikley event there is something you need in both you link the ifle into both .d's and be happy
[14:03] <caribou> apw: though, it does nothing for this bug as I doubt that touching something as central as procps would qualify for SRU
[14:03] <apw> caribou, there is nothing to say you can't change things like that, we might need to make it opt in or something
[14:03] <apw> caribou, so like if there is a kdump.conf we use that _rather_ than the normal ones, and they can make it empty
[14:04] <apw> sysctl-kdump.conf
[14:04] <apw> so that the default doesn't change perhaps, something like that
[14:05] <apw> you are our dump expert, and if you say its wrong that kinda makes it wrong and wrong things can be fixed in sru's
[14:05] <caribou> apw: well the argument that it only applies in the context of the kexec post-panic kernel an never in a normal user context migth be sufficient
[14:05] <caribou> apw: am I ???? :-D
[14:05] <apw> caribou, clearly :)
[14:06] <caribou> ok, let me run with that  & see what I can propose; I'll also comment in the bug
[14:06] <caribou> apw: ^
[14:06] <rtg> caribou: would you like me to take a stab at the patch and run it by you ?
[14:07] <apw> rtg, or you could sponsor it for him
[14:07] <rtg> apw, that to
[14:07] <rtg> too*
[14:07] <apw> sweet sorted
[14:07] <caribou> rtg: let me try it, then I'll run it by you guys
[14:07] <rtg> ack
[14:14] <caribou> apw: rtg: is it possible to force vm.min_free_kbytes as a boot parameter (for a temporary workaround) ?
[14:18] <apw> caribou, it is possible yes
[14:18] <apw> i can't say for cirtain without looking though
[14:20]  * rtg does not see anything promising in Documentation/kernel-parameters.txt
[14:20] <caribou> apw: don't bother, I'll look it up; thought you might know it off the top of your head
[14:21] <apw> ak
[14:21] <apw> ack
[14:25] <caribou> apw: fedora fixed it a while ago : https://lists.fedoraproject.org/pipermail/kexec/2014-November/001478.html
[14:25] <caribou> apw: not too found of how they fixed it though
[14:27] <apw> caribou, no, but then there is precident, perhaps we can do that in SRUs and something cleverer in the new releases
[14:28] <caribou> apw: indeed
[14:28] <apw> cirtainly i'd not want to hard code it like that, ugg
[14:29] <apw> and that only fixes it if it is in /etc/sysctl.conf at that, not sysctl.d ... hrm
[14:29] <rtg> eeew!
[14:30] <caribou> tbh, I'm not sure if the fix went in but it was reported
[14:32] <caribou> rtg: apw: here is a question for you : does the kernel rely on sysctl settings to boot correctly (i.e. do we use that mechanism to fix some behaviors) ?
[14:33] <apw> caribou, well as they are applied in root, they cannot be used to fix root disk related behavious
[14:33] <rtg> caribou: there might be a lot more console noise
[14:34] <caribou> rtg: I also see some hardening things in there we might want to keep
[14:34] <rtg> caribou: doesn't kexec immediately reboot ?
[14:35] <rtg> after acquiring the dump
[14:35] <caribou> rtg: yes
[14:35] <rtg> in which case hardening might not be so important
[14:39] <apw> caribou, and we don't bring up things like networking do we
[14:39] <caribou> apw: yes, especially if we want to do remote dumps
[14:40] <caribou> apw: but it is not even dependent on remote dumps : network comes up systematically
[14:40] <caribou> made my life soo much easier when I developped remote dumps
[14:42] <apw> caribou, then there are options there which may be necessary, hrm
[14:43] <apw> caribou, how about then having an sysctl-kdump.conf which is loaded _after_ all the others, which can set things "back"
[14:44] <caribou> apw: interesting; the only thing is to know _what_ to set "back"
[14:44] <apw> caribou, well we literally only know of one thing which should not be set, so it could start with that
[14:45] <apw> (if we know what a sane value is)
[14:46] <caribou> apw: in worst case scenario, it would be the sysadmin responsability to add to this file in case of problem; at least the mechanism is there
[14:46] <apw> caribou, yeah, something like that
[14:46] <caribou> apw: & we override the values for things we know would cause problems
[14:46] <apw> the only issue really is knowing what to put in that one
[14:48] <rtg> perhaps just vm.mmap_min_addr for now (which we _know_ is causing problems)
[14:48] <caribou> rtg: that's my idea for a starte
[14:48] <caribou> starter
[14:49] <caribou> rtg: apw: as I don't think we have an easy way to identify what was the original value in the kernel's namelist before sysctl changed it
[14:49] <apw> caribou, yeah, and its magic essentially
[14:49] <apw> asses
[14:50] <caribou> apw: ok let start with that
[14:50] <rtg> if it is never set after kexec boots, then it is by default set to the kernel value, right ?
[14:50] <rtg> which ought to be OK
[14:51] <caribou> rtg: the kexec kernel will apply the sysctl changes just like the regular kernel
[14:51] <caribou> rtg: just trying to find a way to avoid disabling sysctl alltogether
[14:51] <rtg> caribou: except that you are going to modify procps to do something different (I thought)
[14:51] <apw> caribou, of course we know how much memeory we have, it is 128M so a fixed value for that is "ok"
[14:54] <caribou> apw: let me run a first pass at it & see what I can come up with
[14:54] <apw> rtg, the point here is that sysctls can be requried for networking and the like
[14:54] <apw> rtg, and knowing whihc are ok and which not is hard
[14:54] <rtg> understood
[14:55] <apw> caribou, i assume what happens now is we copy these into the initrd, apply them all there, and then again once we mount root (for non kdump boots)
[14:55] <apw> caribou, which is why eliding them by name works for the fedora case
[14:56] <caribou> apw: no, apparently the sysctl stuff is taken from thre real root & not the initrd
[14:57] <apw> caribou, well that code is copying them into the initrd and they elide the problem one at that point
[14:57] <apw> anyhow have a go and see what happens
[14:58] <caribou> apw: sure
[15:00] <dsmythies> apw: I do not actually have the sound card (Creative Labs SB Audigy) and came here on behalf of someone else, after helping them isolate the issue (at least to the point where I needed help here). Yes, his AlsaMxer program isn't working,as the card isn't being detected. I also wonder if some of those other sound card differences in the kernel configuration file are for the same reason (ref:  http://paste.ubuntu.com/14481736/ )
[15:01] <apw> dsmythies, oddness, the delta i was shown was just the one card
[15:01] <apw> rtg, ^ ?
[15:01] <apw> rtg, did we investigate whether we could remove that config snippet for CONFIG_ZONE_DEVICE ?
[15:03] <tjaalton> 4.4 doesn't see my nvme drive.. boot fails because of that
[15:08] <tjaalton> mainlines at least
[15:08] <tjaalton> are the soon-to-hit xenial packages somewhere?
[15:09] <apw> tjaalton, ckt unstable ppa
[15:09] <rtg> apw, I have not.
[15:09] <tjaalton> apw: thx
[15:11] <apw> rtg, i think we need to resolve what we are donig about that one before we release 4.4 as well
[15:11] <rtg> apw, maybe have a diff setting for lowlatency ?
[15:13] <apw> rtg, well whether we can in fact turn on both for the case we care about, amd64
[15:13] <dsmythies> apw, rtg: Thiss issue is on both lowlatency and generic, but yes amd64.
[15:14] <apw> rtg, obbvoiusly the config constraints don't let us, but i think on amd64 we have no HIGHMEM so we have one more spare bit, and if we do then we can have zone_dma and zone_device together
[15:14] <apw> that means i386 can't have both, but we're not caring about those
[15:15] <rtg> apw, yeah, I'm not too concerned about NVDIMM on 32 bit
[15:16] <dsmythies> tjaalton: Have a look at this: http://askubuntu.com/questions/709794/dell-xps-13-9350-compatibility/719947#719947 I do not know if it is true or not that CONFIG_BLK_DEV_NVME=y is needed.
[15:18] <manjo> I have been modifying debian/rules.d/2-binary-arch.mk to skip modules signing if the private key is not available .. is there a way to tell builds in LP not to fail of if private key is not available? or what is the correct way of building it ?
[15:20] <manjo> apw, ^ ?
[15:22] <apw> manjo, we generate the private key during the build ?
[15:23] <tjaalton> dsmythies: sounds like initramfs fail to me
[15:23] <manjo> install-%: MODSECKEY=$(builddir)/build-$*/certs/signing_key.pem
[15:23] <manjo> apw, ^ looks like it expects the key to be there
[15:24] <manjo> apw, May be I am missing something .. I have been doing if [[ -f "$(MODSECKEY)" ]] ; then \ round the signing code ... which I don't think it the right thing to do
[15:25] <apw> manjo, right, it expects it to be there because it makes it
[15:25] <apw> manjo, so it should be making it, why is yours not
[15:25] <manjo> apw, ppisati ran into the same issue with arm builds (many months ago)
[15:25] <apw> maybe so, if so he may remmber what he was doing wrong
[15:25] <apw> manjo, but i say again, the build makes that key
[15:26] <manjo> apw, ok let me build in PPA and get it to fail... that will give me and idea what is going on ..
[15:27] <apw> manjo, see certs/Makefile
[15:27] <apw>         @echo "### Now generating an X.509 key pair to be used for signing modules."
[15:27] <apw> it is that key which we then use to _resign_ the modules after stripping them
[15:28] <manjo> apw, I have been blindly carrying this patch is my PPA builds and May be it is not needed anymore ... let me build without it and see if the keys are generated
[15:29] <apw> manjo, we have always built our kernles in PPAs and never needed such a thing
[15:29] <rtg> manjo, there is this patch for newer kernels: 'UBUNTU: [Debian] Update to new signing key type and location'
[15:30] <manjo> rtg, ok so that must have fixed it for me .. I will drop this mod to skip signing
[15:30] <tjaalton> dsmythies: 4.4.0-0 finds the drive, but cryptsetup fails with "lvm is not available"
[15:31] <caribou> apw: rtg: back to the vm.min_free_kbytes
[15:31] <rtg> hmm
[15:32] <apw> tjaalton, you'd think we would have noticed that lvm wasn't available in initrd ?
[15:32] <apw> caribou, ?
[15:32] <caribou> apw: rtg: how about I add an option to kdump-config that would re-apply values as found in /etc/default/kdump-tools ?
[15:33] <caribou> apw: rtg: this option would be called by /etc/init.d/procps if /proc/vmcore is found
[15:33] <apw> /etc/default/kdump-tools is in shell format right?  waht would you proposed to encode in tehre ?
[15:34] <rtg> caribou: what would be the packaged defaults in /etc/default/kdump-tools ? Anything ?
[15:35] <caribou> apw: yes, I would add SYSCTL=vm.min_free_kbytes=blah and loop through each SYSCTL varible found
[15:35] <caribou> rtg: we can put anything we know can cause problems & sysadmin can add to it'
[15:35] <rtg> seems reasonable
[15:35] <apw> caribou, or perhaps SYSCTL_UPDATES=/etc/sysctl-kdump.conf or something and use that file
[15:35] <caribou> this way I restrict modifications outside of the kdump-tools realm to a minimum
[15:36] <apw> caribou, but i like the idea of passing the problem to kdump-config in procps
[15:36] <caribou> apw: the advantage of looping through the existing /etc/default/kdump-tools file is that I don't need an extra file
[15:37] <apw> i think making that file overly complex is a mistake because things like systemd read them for you and convert them to environment variables and the like
[15:38] <apw> caribou, well mangling existing defaults which are there are difficult especially with that new non-standard format
[15:38] <apw> by making that a differnt sort of entry you make it hard to migrate configs later etc
[15:38] <apw> caribou, also why do we even need to change procps if you do it via kdump-tools
[15:39] <caribou> apw: true; especially since kdump-config sources the default file at the begininng. I'll use your option
[15:39] <caribou> apw: because, like in that specific bug, we don't get as far as running kdump-config, it fails before that
[15:39] <caribou> I can reproduce it btw
[15:39] <caribou> apw: that was my initial idea, but it has to happen right when procps runs
[15:40] <apw> caribou, but can we just get in before it, by being earlier
[15:40] <apw> kdump-config is running in initramfs or in real root when it runs
[15:40] <apw> ?
[15:40] <caribou> apw: real root, so is procps
[15:41] <caribou> apw: so the procps modification is only to run sysctl -p /etc/kdump-config.conf if /proc/vmcore exists
[15:44] <apw> caribou, i presume the issue then is that the act of setting it to a large value ooms the box immediadly
[15:44] <apw> caribou, so you can't then set it back, you already ooms
[15:44] <caribou> apw: exactly
[15:45] <dsmythies> apw, rtg: For my own curiousity, could you point me to "the config snippet for CONFIG_ZONE_DEVICE". So far, I haven't been able to find it.
[15:45] <rtg> mm/Kconfig:config ZONE_DEVICE
[15:45] <apw> config ZONE_DEVICE
[15:45] <apw>         bool "Device memory (pmem, etc...) hotplug support" if EXPERT
[15:45] <apw>         default !ZONE_DMA
[15:45] <apw>         depends on !ZONE_DMA
[15:46] <apw> we might also need to fix the ZONE_SHIFT calculation, but, i can't see why this won't work
[15:46] <tjaalton> apw: I'll check the diff between 4.3 & 4.4 initrd's and see what's going on there
[15:47] <apw> tjaalton, lack of -extras perhaps ?
[15:47] <apw> in your testing ?
[15:47] <tjaalton> well this same thing is with mainline builds
[15:47] <apw> caribou, so are you proposing to only apply that one file if you find it, and let kdump-ocnfig generate it or ?
[15:47] <tjaalton> -extra is installed
[15:47] <apw> caribou, as we cannot apply the real changes and then apply this one back over the top, as that will likely oom us in the middle
[15:48] <caribou> apw: looks like it (I'm testing it at the same time)
[15:48] <caribou> apw: I was thinking of applying the content of /etc/kdump-config.conf over the existing
[15:49] <apw> i think you'll find the first will blammo on you
[15:49] <caribou> apw: looks like the simple fact of applying vm.min_free_kbytes triggers the OOM
[15:49] <apw> which makse sense when you look at the kernel code, it forfully empties memeory to make the boundary
[15:50] <caribou> apw: then no matter what, we need to avoid this change to even happen
[15:51] <apw> ugg
[15:52] <apw> caribou, does the kernel know it is in kdump mode ?
[15:52] <caribou> apw: yes, as it exposes /proc/vmcore
[15:53] <caribou> apw: but isn't changing the kernel because one silly setup triggers OOM a bit of an overkill
[15:53] <caribou> ?
[15:53] <rtg> apw, fix this in the kernel by ignoring vm.min_free_kbyte if kexec'ed ?
[15:54] <apw> rtg, i am thinking about it, yes
[15:54] <apw> if /proc/vmcore is valid in fact, but yes
[15:54] <rtg> hmm
[15:54] <apw> as kexecing is a valid way to reboot too
[15:54] <apw> and in the normal case we don't care, but if we are exposing a dump file to uspace then we coudl ignore uspace
[15:55] <apw> caribou, rtg, though there is a separate way of looking at this
[15:55] <caribou> userland is changing a kernel setup in a limited memory context, I would rather avoid changing this value if we very well know that we're in a limited contgext
[15:55] <apw> that the request for memory can _never_ succeed, the request for reserve is large than total ram
[15:55] <caribou> limited memory context
[15:55] <apw> returning -ENOWAY instead vbecaus the request is rediculous might be sane
[15:56] <caribou> apw: true
[15:56] <rtg> instead of OOM'ing
[15:56] <apw> right ooming is rarely useful
[15:57] <rtg> apw, doing it that way means we don't have to care if /proc/vmcore is valid
[16:00] <apw> rtg, so the code as it stands divides the limit you specify between all the non-highmem zones you have
[16:00] <apw> so if you say 1000 pages and you have 10 in DMA and 90 in NORMAL
[16:00] <apw> it will demand 100 in DMA and 900 in NORMAL even though that is patently nuts
[16:02] <rtg> apw, seems like refusing the sysctl is a reasonable action
[16:03] <apw> rtg, though even if i make it say you need enough memory in your zones to cope there are likely to be combinations which are just numerically valid and not viable
[16:03] <apw> rtg, and telling those appart is tricky at best
[16:08] <apw> caribou, eliding specific entries in userspace falls to procps, to sysctl itself detecting /proc/vmcore and ignoreing some names textually (me thinks) which is a little vile, but no vialer than doing so in the kernel
[16:09] <tjaalton> apw: weird, 4.2.0-16 doesn't have sbin/lvm either, but it still works
[16:09] <caribou> apw: ok, I'm looking into that
[16:10] <caribou> apw: and at the same time, asking for the kernel to keep a minimum of 312M free and setting crashkernel=128M makes no sense, they should just increase crashkernel
[16:11] <apw> caribou, well they claim to be using 768M for crashkernel i think, but either way its bonkers
[16:13] <tjaalton> apw: oh, nvme.ko is not shipped with 4.4 initrd, because the module location changed
[16:14] <apw> tjaalton, i thought initramfs-tools looked at those by module name only ?
[16:15] <tjaalton> dunno, but it should be in kernel/drivers/nvme/host/nvme.ko now
[16:15] <apw> oh perhaps it is shipping all "block/*" or something
[16:15] <tjaalton> instead of kernel/drivers/block/nvme.ko
[16:15] <apw> tjaalton, can you file me a bug against initramfs-tools for that please
[16:16] <rtg> tjaalton, that means I should fix debian.master/control.d/generic.inclusion-list:drivers/block/nvme.ko
[16:16] <apw> and give me the # and i'll batch that up with the other two critical fixes
[16:16] <apw> rtg, needs fixing there too yes
[16:16] <rtg> apw, I'll take care of it
[16:16] <tjaalton> rtg: you'll file the bug too?
[16:17] <rtg> tjaalton, nope, its  dev kernel. I'll just fix it
[16:17] <apw> i think he is saying he will fix the kernel bit, but i would love a bug for initramgs-tools for that bit
[16:17] <tjaalton> right but initramfs-tools needs fixing too
[16:17] <tjaalton> yeah I'll file that bit
[16:18] <apw>                         copy_modules_dir kernel/drivers/block
[16:18] <apw> yeah it copies on all block devices, and that just moved out of there
[16:18] <tjaalton> fixed in debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807000
[16:21] <apw> tjaalton, not sure that that fix makes a whole heap of sense in the face of the change the kernel is making, long term, but hey
[16:25] <tjaalton> apw: what do you mean? cryptsetup works again with that, just tested
[16:28] <tjaalton> apw: heh, two bugs already filed about this
[16:29] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1524879 https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1532146
[16:30] <tjaalton> the first already properly assigned :P
[16:32]  * xnox thought apw was going to sponsor that cherrypick
[16:32] <xnox> as asked on irc some friday back.
[16:34] <rtg> ppisati, I forgot to mention that Ubuntu-4.4.0-1000.6 works well with your image
[16:34] <apw> xnox, then i am already doing it indeed :)
[16:35] <ppisati> rtg: good to know
[16:35] <dsmythies> apw, rtg: I am not understanding the config dependency trail, or what to change in order to be able to compile a test kernel. Do I just delete that ZONE_DEVICE snippet?
[16:35] <rtg> ppisati, hopefully it will work with Snappy as well
[16:36] <apw> dsmythies, no, we want to test building with the config requirement for !ZONE_DMA removed and that turned back on
[16:36] <ppisati> rtg: it will
[16:36] <apw> and see if tht builds on amd64
[16:37] <ppisati> rtg: though i might have found a problem with xenial/arm64
[16:37] <ppisati> rtg: so, no matter if i cross or native compile
[16:37] <rtg> ppisati, the module load problem ?
[16:37] <ppisati> rtg: right
[16:37] <ppisati> rtg: if i compile under wily is fine
[16:37] <rtg> ppisati, I noticed that it seems to be a toolchain issue
[16:37] <ppisati> rtg: while it blows in a xenial chroot
[16:38] <rtg> dannf found that one, right ?
[16:38] <ppisati> rtg: it happens if i crosscompile (xenial/amd64 -> arm64) or native (my arm64 ppa)
[16:38] <ppisati> rtg: i found it, and dannf confimed he sees that too in xenial 4.3
[16:38] <ppisati> dannf: ^
[16:38] <rtg> ppisati, what is Linaro using ?
[16:39] <dsmythies> apw: O.K. so delete this line: "depends on !ZONE_DMA" then. (sorry for being a bit think on thick on this one).
[16:39] <ppisati> rtg: no idea
[16:39] <ppisati> rtg: you mean the toolchain
[16:39] <rtg> yeah, maybe Salvetti has some thoughts
[16:40] <dannf> ppisati, rtg: my next step was to rebuild gcc w/o linaro patches to see if that fixes it
[16:40] <dannf> (otp, sorry for lag)
[16:41] <rtg> dannf, are there patches in gcc specific to that arm64 errata ?
[16:44] <dsmythies> I meant to say "sorry for being a bit thick on this one".
[16:44] <apw> dsmythies, yes, then readd CONFIG_ZONE_DMA=y to the config and run fakeroot debian/rules updateconfigs
[16:44] <apw> and then see if the build builds any more, i suspect it may not
[16:44] <apw> but it may be resolvable
[16:44] <apw> (on amd64)
[16:46] <dannf> rtg: yeah
[16:47] <dsmythies> apw: I will report back, but it might be awhile (like hours).
[17:31] <jmux> How can I build a kernel containing a ddeb package? I just have a linux-lts-trusty-tools ddeb as an output of my build.
[17:32] <apw> jmux, how are you building them ?
[17:32] <jmux> My problem is actually http://ddebs.ubuntu.com/pool/main/l/linux-lts-trusty/, which doesn't contain debug symbols for the range from 15-Jul-2014  to 10-Nov-2015
[17:33] <arges> jmux: depending on the version it may be archived in launchpad
[17:34] <jmux> apw: sbuild -A -s -d tramp --arch=i386 --add-depends=pkg-create-dbgsym linux-lts-trusty_3.13.0-34.60~precise1.dsc
[17:34] <apw> right, we moved ddebs into the librarian around that time, though i would expect them to be in there
[17:35] <apw> jmux, if you arn't on a real builder it will optimise away the .ddebs because they take an hour to package
[17:36] <jmux> apw: I get the ddeb for the linux-lts-trusty-tools. I even set AUTOBUILD=1
[17:36] <arges> apw: they are gone: https://launchpad.net/ubuntu/+source/linux-lts-trusty/3.13.0-34.60~precise1
[17:36] <apw> you need something like full_build=true passed to debian/rules
[17:37] <arges> this is how i've done it: http://chrisarges.net/2015/10/02/building-ubuntu-kernels-with-debug-symbols.html
[17:38] <apw> arges, full_build=true is the approved incantation there, though the effect is similar
[17:38] <arges> apw:noted
[17:41] <jmux> Hmm missed full_build in debian/rules.d/0-common-vars.mk
[17:45] <apw> jmux, it isn't something that one expects (like the spanish inquisition)
[17:45] <jmux> Probably an other problem "man xz: Multithreaded compression and decompression are not implemented yet, so this option has no effect for now."
[17:46] <jmux> So even if the build finishes in 10 minutes, the compression will take ages, I guess
[17:46] <apw> it takes ages for sure, like 10 on our massivly fast boxes, hours on others
[17:47] <apw> they make one cry in the main, whihc is why they get turned of by default for local builds
[17:47] <apw> did you look and see if the one you needed was in the librarian though ?
[17:48] <jmux> Is there a way to query librarian directly? The ddebs are in the build log…
[17:49] <apw> i'd say from the .changes from the buildd that the .ddebs were collected under the old system
[17:49] <apw> arges, does sts still keep history on those?
[17:49] <arges> apw: i don't think so
[17:49] <arges> i didn't find in the librarian so best bet it to regenerate them.
[17:53]  * jmux is not sure the debug symbols will actually help with MCE like http://paste.debian.net/365584/
[17:54] <apw> jmux, nope, did you try what it suggests ?
[17:54] <jmux> Yup - but didn't help me
[17:55] <jmux> http://paste.debian.net/365586/
[17:56] <apw> jmux, what are you hoping it will tell you?  that says that when we were handling a page fault the internal state of the CPU was found to be wrong and unfixable
[17:56] <jmux> But these machines were working flawlessly on lucid for years. No idea, why they stop working on precise with trusty stack
[17:57] <apw> well they may be throwing errors all the time which the old kernel doesn't understand at all (which being lucid it would not)
[17:59] <apw> those newer kernels almost cirtainly have the ability to read MCEs at all whereas the older ones did not i suspect
[18:00] <jmux> apw: might be. I've just started collecting information. Not sure if a backtrace contains info about the origin of the page fault.
[18:00] <apw> jmux, if that EIP is accurate (and it implies it is not but hey) that is the very first byte of the exception handler
[18:01] <apw> jmux, and is this a 32 bit kernel ?
[18:01] <jmux> it might be a really unnoticed HW bug - no idea yet
[18:02] <jmux> Yup 32bit
[18:04] <apw> if the things is occuring often and reproducibly you could try rmeoving the MCE handler (if it is a module) and see
[18:04] <apw> if the machine is symptomless afterwards
[18:04] <apw> as it was on lucid, it may be just be that they are bogus, given it never exploded before
[18:06] <jmux> Problem is I really don't know what triggers it. I got the exact HW of a known problematic box and it took 12 hours to trigger.
[18:06] <apw> jmux, it is possible nomce on the kernel command line will shut it off for that purpose
[18:06] <apw> of course if it is real, all bets are off in that case
[18:06] <jmux> This happens for random people
[18:07] <jmux> About once in a week
[18:18] <jmux> Support has actually played with Intel C states in BIOS which fixed it for some people
[18:18] <apw> oh lovely
[18:20] <jmux> That's why I still hope it can be a kernel bug, I'll also update the kernel. But for that random bugs without a real trigger…
[18:22] <jmux> I had the crazy idea of the new kernel using more power, probably because of new features… instable system… all I know is Lucid worked for years and problem started with the precise updates
[18:23]  * jmux hopes that shipping truisty with xenial stack will help, but that's half a year away
[18:36] <apw> jmux, they likley would have simply not been detected before in lucid
[18:37] <apw> even if they were happening
[18:38] <jmux> And something like "MCA: Internal unclassified error: 402" doesn't help
[18:39] <jmux> I'll also try latest microcode updates
[18:40] <jmux> If I get the same error tomorrow, I have probably at least one vaid data point. And there are BIOS updates.
[18:41]  * jmux shivers thinking about BIOS updating a few thousand machines…
[18:43] <apw> jmux, a job for life ... literally
[18:43] <jmux> Oh - and I just got the MCE error via serial null modem connection
[18:46] <apw> jmux, a google of the specific error shows people sending their CPUs back for replacement to good effect o.O
[18:47] <apw> (which if it was true would make upgrading the BIOSen look like a fun game)
[18:50] <jmux> apw: hmm If all machine would show this MCE, but currently they just have a blank screen. Without the null modem, I wouldn't have seen this.
[18:51] <apw> jmux, yeah the "kms will guanretee you can see panics" promise, not so much
[18:51] <jmux> Probably disableing DPMS for known machines would help here
[18:56] <jmux> Probably installing mcelog will also help
[18:56] <apw> good luck
[18:58] <jmux> Everything linux wise I can deploy automatically. mcelog definitly makes sense, as this would probably allow to catch the MCE errors
[19:01] <jmux> Hmm https://access.redhat.com/solutions/1161573 has the same HW. Guess I'll have to contact some server guys tomorrow
[19:01] <jmux> "Following MCE logs were collected from serial consle."
[19:03] <jmux> It's not page_fault but intel_idle, but otherwise…
[19:03] <apw> jmux, i note it talks about using "nomodeset" which if you find a box which reproduces regularly is worth a shot
[19:06] <jmux> The "reproduces regularly" is the problem. So actually a kernel update might help, or the solution will just state "get a new CPU"
[19:06] <jmux> I hope my local crash will happen again in the next 12 hours
[19:07]  * jmux hopes for a software solution
[19:08] <jmux> apw: thanks for your support. /me will leave for the cinema in a few minutes
[22:08] <dsmythies> apw: The build failed, and for the reason you predicted, ZONES_SHIFT, which cascades into a bunch of other errors.
[22:09] <dsmythies> apw: #error ZONES_SHIFT -- too many zones configured adjust calculation
[22:18] <apw> dsmythies, yep thanks, will have a look at it perhaps in the morning -- if the other plates stay up


[16:22] <blackboxsw> aciba: I think I got your comments on PR 1572
[16:36] <aciba> blackboxsw: approved, thanks!
[17:56] <blackboxsw> https://github.com/canonical/cloud-init/pull/1574 merged.  holmanb is https://github.com/canonical/cloud-init/pull/1585 ready for review?
[18:00] <holmanb> @blackboxsw: yes I believe so. Unit test coverage now includes package install, command used, and additionally the get_package function coverage per requests. Integration tests planned to be a separate PR.
[18:01] <blackboxsw> thanks holmanb: on it and that works for me. integration tests there will be significantly "bigger". Also, will there by time to review https://github.com/canonical/cloud-init/pull/1581 today? If we have closure on that from cloud-init it'll unblock the subiquity-related PR that'll stuff a run-parts script in that directory.
[18:01] <falcojr> blackboxsw holmanb : I can review that one too
[18:01] <blackboxsw> what's holding up the subiquity-part is just confirmation about whether we think /etc/cloud/clean.d is the directory we want to use for this. (or somewhere else)
[18:02] <falcojr> blackboxsw: I just commented on your other subiquity PR to
[18:02] <blackboxsw> falcojr: thanks on 1592 as well. looks like we'll wrap that up next week
[18:03] <holmanb> @blackboxsw: yep, I'll prioritize that
[18:03] <holmanb> to be clear: prioritize #1581
[18:04] <blackboxsw> holmanb: great. looks like Dan is good from subiquity side for the related PR to 1581 https://github.com/canonical/subiquity/pull/1347#issuecomment-1185757100
[18:05] <blackboxsw> I'll manually drive integration test of both (painful.... takes about 45 mins for me)
[18:06] <blackboxsw> falcojr: which PR?
[18:06] <falcojr> blackboxsw: autoinstall, 1572
[18:06]  * blackboxsw checks github emails as the PRs themselves aren't showing me comments in the UI
[18:07] <blackboxsw> ahh cloud-init repo not subiquity repo PRs
[18:07] <falcojr> ahh, sorry
[18:11] <blackboxsw> @falcojr think it's worth augmenting an integration test for passing opaque autoinstall and ensuring the snap is installed?
[18:11] <blackboxsw> just so the live logic of the cc_ubuntu_autoinstall module is exercised (even though it basically noops beyond schema validation)
[18:12] <falcojr> blackboxsw: sure, couldn't hurt
[18:16] <blackboxsw> a bit of extra time. maybe we'd hit snap install timeout issues... but looks like we aready snap install hello-world in test_combined. I'll just add subiquity/autoinstall checks there too
[18:16] <falcojr> sounds good
[18:48] <blackboxsw> falcojr: integration test up. I can't add it to test_combined.py because that is a test_common tests are broad than ubuntu.... so I don't want to dump ubuntu_autoinstall tests into that too.  I'm waiting on integration test results in azure now
[18:49] <blackboxsw> to make sure I don't have to rework the test assertions
[18:54] <blackboxsw> test needs a snap install subiquity --classic
[19:09] <falcojr> sounds good, I'll take a look
[19:18] <falcojr> blackboxsw: test looks good. Did you see my question about frequency though?
[19:27] <blackboxsw> falcojr: twas missed, thx fixed/pushed.
[19:36] <blackboxsw> falcojr: going through https://github.com/canonical/cloud-init/pull/1590/files now nice use of features. that'll make things simpler for downstream pkging
[19:42] <blackboxsw> holmanb: +1 on https://github.com/canonical/cloud-init/pull/1585 for you with or without that nit integration test suggestion. I tested both lvm and btrfs storage_backends and both don't fail. But since you are working a specific integration test separately, maybe no need to touch 1585. You're call to merge or update/merge
[20:08] <blackboxsw> falcojr: does #1592 really have to land before 1590?
[20:09] <blackboxsw> they don't seem strictly dependent
[20:33] <falcojr> blackboxsw: no, I suppose not...but I thought I could use 1590 to fix whatever else might need to be fixed if 1592 doesn't work
[20:35] <blackboxsw> falcojr: makes sense, content/behavior looks good to me  on 1590. I was wondering if it's worth moving forward on 1590 and sorting any missing issues in 1592 or whatever needs to follow if the hashed_passwd approach doesn't resolve things.
[20:49] <falcojr> blackboxsw: sure, I think that's fine