[00:37] * Move laptop-detect from /usr/sbin to /usr/bin - Wed, 08 Mar 2017 00:59:54 +0100 [01:03] Debian #894481 [01:03] Debian bug 894481 in numlockx "numlockx: `laptop-detect` has moved from /usr/sbin to /usr/bin" [Normal,Open] http://bugs.debian.org/894481 [04:00] https://packages.qa.debian.org/g/gtk-theme-config/news/20180331T035526Z.html [07:55] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: tumbler 0.2.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-tumbler-0-2-1-released-tp50878.html (by Ali Abdallah-4) [08:22] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: tumbler 0.1.33 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-tumbler-0-1-33-released-tp50879.html (by Ali Abdallah-4) [09:27] if I didn't know that our iso was suffering from this bluetooth issue - I would just assume that I can't install xubuntu and would go looking for something that worked :( [09:36] willem: thanks :) [10:52] flocculant, ?? I don't think I complained about bluetooth lately; but then again I'm old and may have forgotten I did... [11:34] hmm, i did: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1490349, but that was quite some time back [11:34] Launchpad bug 1490349 in bluez (Ubuntu) "15:10 and 16.04: bluetoothd "Failed to start discovery: org.bluez.Error.NotReady" after bluetoothd restarted" [High,Invalid] [11:43] willem: we have one at the moment that leads to a 75s timeout in I assume anything with no bluetooth [11:47] I read about that one [11:47] I think I did report the slow boot after first install [12:08] willem: also - the thanks were for the reply to the testing soon e-mail ;) [12:09] ah, right! I didn't realize that. [12:09] I only just did when I read you again :p [12:09] All I saw was your line about bluetooth and thanking me [12:11] I hope my e-mail helps, though. [12:15] yep - always useful to get comments like that from 'normal' testers :) [12:16] Never been called normal before [12:16] :D [12:16] makes a change I guess ;-) [12:17] I've not talked to you for quite long enough to tar you with the 'crazy people who test things' brush yet lol [12:18] if you're still putting up with us mid- Cantankerous Cicada cycle - I'll call you crazy :) [12:24] I'll try to live up to your expectations, then [12:28] :) [12:42] funnily enough i read that bug yesterday [12:43] apparently it is not a bug [13:34] flocculant: i wish to complain [13:34] the iso tracker tests ask me to verify that "The slideshow is entirely in your language" [13:35] but the xubuntu slideshow has that slide with "hello" written in all different languages [13:35] therefore i have to fail it :) [13:39] ali1234, :-) I was tempted to do the same first time I came across that slide ;-) [13:56] Anyone know of a better channel to catch hold of devs that understand the light-locker<>lightdm interactions ? [15:03] TJ-: #lightdm would probably be best. The maintainer of light-locker comes and goes at #xfce-dev [15:03] thanks. [15:04] I'm sticking in some gs_debug() now to try to trace the lid-closed suspend/resume path [16:14] Looks like the lid-closed>suspend>resume>blank-user-session-vt is a timing issue; with a few debug options and light-locker --debug >/tmp/log I cannot reproduce it [16:41] Getting more interesting. Even without --debug enabled, my local build of light-locker (with embedded gs_debug() statements) will not fail, but the system's version will. So I've got 3 possible diffs: 1) my 5 gs_debug() statements 2) my binary isn't stripped 3) pssobitl different build options [16:43] And just found another data-point that is a workaround. When the blank user VT is present, connecting charger (PM not set to suspend when lid-closed on AC) and then closing and re-opening lid, the VT is active and visible again [19:30] good news: tumblerd's exif orientation code is not broken, it's my images :) [19:31] and also imagemagick is partly to blame === GridCube_ is now known as GridCube