[02:50] * FJKong fell asleep last night.. [04:30] Good morning [06:03] good morning [06:10] morning! [06:12] good morning desktopers! [06:34] * pitti waves to the desktoppers, guten Morgen! [06:34] good morning pitti [06:37] hey pitti! [07:53] morningla [07:53] er [07:53] morning all [07:55] hey willcooke [07:56] hey willcooke [08:03] hup hup hup [08:03] hup Laney too [08:06] hey didrocks [08:06] vat iz up [08:08] hey Laney [08:08] hoe gaat het? [08:09] alles goed! [08:09] en met jou? [08:09] goed, danku :-) [08:10] dutch high five! [08:10] :-) [08:13] * Laney screams at all iso builds failing [08:13] looks like debootstrap is busticated [08:21] woah [08:21] "Could not apply the stored configuration for monitors" [08:21] and it's in like 640x480 [08:22] okay, 1024x768, but that's just as bad :P [08:22] "Unknown display" [08:25] Laney, when/how? [08:26] just now when I booted [08:26] could have been not quite plugged in correctly, works now after jiggling the cable [08:26] or re-detecting would have worked anyway [08:26] see if it happens again [08:26] k, still weird :-/ if it can't apply the config it should default to whatever xorg is doing which should be the native resolution [08:27] it had a big error about not being able to query the EDID [08:27] so probably defaulted to some emergency/safe resolution [08:40] ah, pitti is fixing debootstrap already [08:40] that is the best news! [08:40] Laney: yeah, fixed now [08:41] Laney: yesterday evening's first attempt didn't work, so this morning I added some debugging to debootstrap (most importantly hte ability to use a local .deb), and fixed it for good [08:41] I got 36 or so emails about isos failing to build :-) [08:41] got accepted into wily some 20 mins ago (argh slow adt-nova argh), should hit archive.u.c. any minute now [08:41] * Laney retries ubuntu as a test [08:44] pitti, are you looking at the shotwell autopkgtest issue? just asking to not dup work [08:46] oh weird, I was going to merge that one soon, was on my list [08:51] seb128: I'm not; I just had a quick look, and it's due to uninstallability (so not infrastructure) [08:51] pitti, k [08:51] Laney, that one = ? [08:51] shotwell [08:52] please do [08:52] I just mentioned it because I got emailed by jenkins [08:52] seems someone already did? [08:52] or was it 0ubuntu1? [08:52] ah yes [08:53] uninstallability> doesn't look like it - seems like an autopilot failure to me [08:53] shrug [08:53] robert_ancell updated it [08:54] let the uploader deal with it ;-) [08:54] yeah, I was unsure if those evdev warning were normal [08:55] seems you only get stdout if it fails, so can't confirm from a successful run [08:56] I'm going to beat robert_ancell with a stack for that update [08:56] well, after I try it :p [09:01] I emailed upstream with https://mail.gnome.org/archives/shotwell-list/2015-February/msg00000.html [09:02] unsure if robert_ancell did something about it [09:03] oh, it got a headerbar? [09:03] quite glad that he got to it first then :) [09:04] hehe [09:07] Laney: ah, it is now; the previous run (#16) was uninstallability (http://d-jenkins.ubuntu-ci:8080/job/wily-adt-shotwell/16/ARCH=i386,label=adt/console) [09:07] but that's fixed now indeed [09:07] nod, sorry, didn't look back at all [09:07] Laney: so I suppose the UI changed, and the autopilot test needs adjusting [09:08] don't fix it [09:08] the update is buggy [09:08] emailing rob [09:09] tag a bug "block-proposed" + assign [09:09] it looks okay to me though [09:09] where do you see a problem? [09:10] Laney, open the preferences dialog [09:10] or the export one [09:10] or the publish one [09:10] e.g any dialog [09:10] Laney, https://mail.gnome.org/archives/shotwell-list/2015-February/msg00002.html has details [09:10] oh just the dialogs, I see! [09:12] yeah [09:12] "just" [09:12] :-) [09:13] much better than it being the main UI [09:13] there's a property that you can watch for dialogs [09:17] I should have Cced you on that email to robert_ancell [09:17] want me to resend with you in Cc? [09:22] seb128: you can just give a link to https://git.gnome.org/browse/file-roller/commit/?id=0f2dab08dc8c577a89a32aeaa1f2467dcaf8c949 which is one I did a while ago [09:22] okay, shotwell is vala, but the idea is the same [09:22] Laney, thanks [09:22] other file-roller commits have more complex cases but it doesn't look like shotwell has those [09:22] e.g. custom items in the header, .ui files, etc [09:23] Laney, done [09:23] thx [09:23] thank *you* ;-) [09:27] Laney, https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1456965 as well [09:27] Launchpad bug 1456965 in shotwell (Ubuntu) "Shouldn't use CSD under Unity" [Undecided,New] [09:33] great === dupondje_ is now known as dupondje [10:38] upgraded my desktop-next machine and now all I have is a flashing caps-lock light [10:38] :( [10:38] willcooke: oops [10:39] One strange thing I noticed was that after the upgrade "reboot" and "shutdown" commands were seemingly missing [11:50] willcooke, kernel issue? did you try booting a previous one? [11:50] well at least the led is usually a kernel issue [11:51] seb128, tbh I've screwed around with it so much I dont think there was a valid set up on there. [11:51] I've resintalled and it's fine now [11:51] Once I've got this demo sorted for the sales engineers I will see if I can break it again [11:52] or maybe your init got screwed, reboot should be there with systemd-sysv but I don't think that has to be there for the system to work [11:52] didrocks, pitti, ^ right? [11:52] willcooke, k [11:55] leds flashing generally means a kernel issue, indeed [11:55] seb128, willcooke: maybe your $PATH didn't include /sbin/ [11:55] ? [11:56] seb128, willcooke: reboot and friends are in upstart-sysv or systemd-sysv, and you should have either installed [11:57] didrocks, pitti, seems like willcooke reinstalled so I guess we are not going to debug that... [11:57] yeah [11:58] although I just noticed that init depends on systemd-sysv | upstart [11:58] that needs to be | upstart-sysv [11:58] (fix uploaded) [11:58] but that only seems tangential [11:58] don't sweat it, that machine has had so many strange hacks applied it's not a valid install [12:02] pitti, I guess that .cache/upstart logs being mostly empty/non existant is a feature and session logs are supposed to be in the journal nowadays? (even things started from gnome-session) [12:05] seb128: no, not at all -- session bits haven't changed at all [12:05] I have tons of logs in ~/.cache/upstart [12:06] pitti, I've only 6 non .gz logs in there and most of the things are missing [12:07] journalctl seems to have a mix of session things as well [12:18] I thought everything started from gnome-session logs into the journal these days?! [12:21] seems so === dbarth_ is now known as dbarth [12:22] popey: my eyes! [12:22] think of his eyes! [12:22] larsu, hey, that's a bit confusing still, need to get used to it I guess [12:23] the journalctl log is just not well formatted and not easy to read [12:23] seb128: yeah... it's definitely worse right now than what we had, since some things are in the journal and some aren't [12:23] seb128: use gnome-logs ;) (and read the journalctl man page, it's got some good stuff) [12:24] larsu, is gnome-logs packaged? [12:24] seems it is [12:24] seb128: yes, but I don't know which version tbh (you need the one with my patches *cough*) [12:24] I should perhaps try it (or we should perhaps ship it by default if it's good?) [12:24] 3.14.2 it seems [12:24] yes, it is and we should [12:24] I've been planning some more stuff for it, but didn't have time yet [12:25] I can add menubar etc. upstream if we decide to ship it [12:26] cool [12:41] pitti: you're upower upstreeam, aren't you? [12:41] pitti: think you could review my patch when you get a chance? https://bugs.freedesktop.org/show_bug.cgi?id=90222 [12:41] Freedesktop bug 90222 in general "Upower no longer handles bluetooth mice properly" [Normal,New] [12:43] didrocks: :D [12:44] mdeslaur: oh, with a test case! ♥ [12:46] pitti: of course! :) [12:46] some other potential patches on https://launchpad.net/ubuntu/+source/upower/+patches ;-) [12:47] seb128: hey, mine first :) [12:47] seb128: oh, I didn't know about +patches, nice! [12:47] pitti, https://launchpadlibrarian.net/206524480/0001-rules-support-Logitech-Unifying-in-Linux-3.19.patch seems like something useful [12:47] that's bug #1448834 [12:47] bug 1448834 in upower (Ubuntu) "mouse battery not shown after upgrade" [Medium,Confirmed] https://launchpad.net/bugs/1448834 [12:48] seb128: I think that's upstream already [12:48] * mdeslaur remembers seeing something similar [12:48] mdeslaur, right, that bug is a request to backport to vivid [12:48] mdeslaur: how is your test different from _add_bt_mouse()? [12:48] * pitti compares the code in more detail [12:48] pitti: device is "hid" and there is an extra "input" subdirectory [12:50] ("hid" instead of "bluetooth") [13:08] mdeslaur: applied [13:08] seb128: cleaned up [13:12] pitti: sweet! thanks! :) [13:12] pitti, danke [13:14] qengho, pingaling [13:15] hrm, contextless pings. Must stop doing that [13:25] kenvandine, hey [13:25] kenvandine, what's the status of approved u-s-s fixes and landing? [13:26] kenvandine, it's a bit ridiculous that trivial/obvious one liner fixes like https://code.launchpad.net/~seb128/ubuntu-system-settings/battery-correct-init-height/+merge/256115 don't land [13:28] seb128, hey, i'm trying to land a few at a time [13:28] but it's slow going [13:28] i can't land to wily first [13:29] why not? [13:29] because of the adt failures from autopilot/uitk [13:29] it gets held in proposed [13:29] can't we just flush think to wily? [13:29] they are working on that [13:29] are those real failures? [13:29] or buggy tools? [13:29] tools [13:29] can't we just override the results? [13:29] autopilot stuff that needs upstart [13:30] they have a fix, just last i heard it wasn't landed yet [13:33] seb128, do you know where the setting to enable ntp gets stored on disk? [13:33] we need to add the path to the whitelist so it persists on the read-only image [13:36] kenvandine, hum, let me check === vrruiz is now known as rvr [13:52] kenvandine, what settings are you talking about? how do you enable/disable ntp? using the set-ntp timedated flag? [13:52] yes [13:52] that [13:52] org.freedesktop.timedate1 [13:54] kenvandine, it enable/disable the job, at least under systemd [13:54] yeah, i just need to know how that gets stored [13:54] it's only persisting over reboots if the device is writable [13:54] not on read-only [13:54] so we're missing a path in the writable whitelist [13:55] kenvandine, seems to rename /etc/network/if-up.d/ntpdate to /etc/network/if-up.d/ntpdate.disabled [13:55] oh... [13:56] thanks! [13:56] yw! [13:57] seb128, about the landings, they'll speed up once the autopilot issue gets resolved [13:57] which should be soon... [13:57] kenvandine, can't we just override the test to get it to migrate? [13:58] or keep it in proposed and do other landings [13:58] there are lots of things we could do :) [13:58] that "charge graph has a wrong initial value" bug is stupid, that fix shouldn't take that long to land [13:58] but the fix should have been quicker than this [13:58] it should land in vivid as well imho [13:58] graphs look wrong atm [13:58] evolution-source-registry takes 370MB RAM on my desktop.. can I disable it somehow? [13:58] yeah, agreed [13:58] tjaalton, rm? mv? apt-get remove? [13:58] it has to be on the ota4 milestone or qa isn't going to look at it [13:59] kenvandine, let me ping Pat [13:59] good idea [13:59] tjaalton, does it take as much if you restart it? [13:59] seb128, and i'm quite busy on content-hub right now, so not much time to spin wheels on settings landings... i'd love some help getting landings in wily :) [14:00] kenvandine, I would be happy to handle landing if you refresh my memory on what to do [14:00] seb128, this systemd-shim and persistance is on the ota4 milestone, so gotta get that done too [14:00] kenvandine, I know how to drive the system, I'm just not uptodate on "politics" [14:00] easier for wily :) [14:00] no qa needed there? [14:00] and i bet you could get away with more than 3 fixes per silo for wily :) [14:01] can we just flush the pending queue to wily? [14:01] afaik we aren't gating on qa for wily right now [14:01] great [14:01] seb128: the parent seems to be upstart --user, but initctl doesn't show it [14:01] which worries me... because then if they block a backport to vivid later we have to rework stuff [14:01] but... they don't have the resources to verify every fix for wily and vivid [14:02] kenvandine, confirmed the file rename on my bq rtm rw btw [14:02] yeah, i did too [14:02] thanks for that!~ [14:02] yw! [14:02] now to figure out who to go to about fixing that in lxc-android-config now [14:03] ... [14:03] kenvandine, good luck, I think rename don't play along with the bind mount hack [14:03] renames are bad [14:04] kenvandine, you might need something along http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=10f312d34a39cb2c5738d48705498fdfec38e9f0 [14:04] in systemd-shim [14:05] e.g make it rename /etc/writable/... rather than the normal file [14:05] I just did a hack like that for whoopsie yesterday [14:07] seb128, so you know how to fix something like this? [14:08] maybe you could do it :) [14:08] kenvandine, lol, nice try [14:08] i have the partial systemd-shim fix in silo 35 [14:08] well, I'm unsure that's needed there [14:09] and I can't see I'm a fan of the change I submitted for whoopsie [14:09] waiting for somebody to review that one first before considering copying that somewhere else [14:09] rsalveti, i assume you're not the guy to go to for lxc-android-config anymore? [14:09] it feels disturbing to be sprinkling this around everywhere [14:10] Laney, well, less disturbing that having our phone buggy for users [14:10] ... [14:10] Laney, do you see any other option? [14:10] +doable [14:11] don't know, could try to think [14:11] not interested in a trolling argument [14:11] well, me neither [14:11] I'm not saying that not fixing it is better [14:11] I'm just saying that we didn't figure out a better way to do this [14:11] but also doing weird hacks is not good [14:11] I don't like it either [14:11] right, I think we agree [14:11] I just don't have anything better to propose [14:12] it's the less sucky option we have atm afaik [14:17] rsalveti, got a minute to look at a fix we'll need related to writable paths and lxc-android-config to let us know if it would work? [14:18] enabling/disabling ntp renames between /etc/network/if-up.d/ntpdate and /etc/network/if-up.d/ntpdate.disabled [14:18] rsalveti, is that something we can handle? [15:35] kenvandine: got a minute now :-) [15:35] guess this is the conversation that is happening at phablet now [15:38] yeah [15:45] * Laney screams at jffi [15:46] * larsu calms down Laney with a cookie and some tea (with milk) [15:46] I have jelly and tea atm [15:46] * Laney transmits a picture [15:46] ooh nice [15:46] please do transmit [15:47] * larsu wonders why totem resets active-plugins gsettings key when starting [15:48] I wonder what sin I committed in a previous life to be having to try and compehend java build systems [15:48] :( [15:51] wow. totem writes that key thrice on startup [15:51] hadessssssssssssssssssssssss [15:51] * larsu shaves yet another yak [15:51] seems to be libpeas' fault though [15:51] you have to fix this for that bug? [15:52] nope, I don't have to [15:52] I guess you're telling me to get my priorities straight? >P [15:52] ah, one of those [15:52] :P [15:52] up to you [15:52] I mostly need it to work to test turning on/off plugins [15:53] because they insert menu items [15:53] and apparently some are not turn-aoofable [15:53] *turn-offable [15:53] Laney, kenvandine, pitti, any comment/opinion on http://paste.ubuntu.com/11246865/ to filter out locales which correspond to a separate language? [15:56] Laney, kenvandine, pitti, basically list xx_YY.UTF-8 locales if xx=YY (to have e.g de_DE work, that's a "de" directory on disk) or if "xx_YY" exists in /usr/share/locale-langpacks [15:58] I think assuming that the country and the language are the same is a bad heuristic [15:58] fails for zh_CN for example [15:58] zh_CN has a dir with that name [15:59] It's just an example [15:59] it's to catch fr_FR having no fr_FR but only "fr" on disk [15:59] same for de_DE being de [15:59] I think that libicu has a facility for this if you are trying to keep the 'main' language [15:59] no, I don't want to keep the main language [16:00] because en_AU would give me "en" which is a dir on disk [16:00] but we don't want en_AU listed [16:00] what is this comparison doing in addition to looking at the directory? [16:00] making de_DE listed [16:00] because /usr/share/locale-langpack/de_DE doesn't exists [16:01] only /usr/share/locale-langpack/de [16:01] we would have no german listed at all without that bit [16:01] I assume that "xx_XX" is shortened to dir "xx" [16:01] but I might be wrong [16:01] the code already builds a list [16:01] so you can say 'give me the likely locale for "de"' [16:01] list of? [16:02] I think [16:02] or at least you could make it do that [16:02] hum [16:02] I'm not sure to understand what you mean "likely locale" [16:02] I remember attente adding some knowledge of this concept [16:02] he called it likely, it's what you're trying to do here I think [16:02] // Should be true if locale is the default for its language. [16:02] // e.g. 'en_US' is the likely locale for 'en', 'en_CA' is not. [16:02] bool likely; [16:02] no [16:03] en_US has its own dir [16:03] I don't want that shortened [16:03] no [16:03] you could only do this lookup if you need to [16:03] that is reverse compared to what I want no? [16:04] so you have 'de', that's not a locale, so find out what the likely locale for 'de' is [16:04] well, I don't have "de" [16:04] I've the output of locale -a [16:04] de_CH.utf8 [16:04] de_DE.utf8 [16:04] de_LI.utf8 [16:04] etc [16:04] and I want to filter out the ones with no translation installed in /usr/share/locale-langpacks [16:05] so my current way is to split .utf-8 and check if the remaining bit exists in the dir [16:05] pitti: hey... question... [16:05] that works for e.g en_US [16:05] or en_GB [16:05] so you want to list that directory, make sure they are all locales by doing this 'likely' lookup [16:05] pitti: is there some API i can use for apport to report an issue? [16:05] and then intersect this with the locale -a output [16:06] ie: i have a library that detects a critical problem, but can proceed anyway... and i don't want to bother the user [16:06] and i want apport to file a bug against the correct program, etc. [16:06] or do this step by step, whatever [16:06] desrt: yes, but please don't [16:06] Laney, sorry I don't understand :-( [16:06] desrt: instead, let's route all criticals to apport [16:06] larsu: that's sort of what i'm getting at... [16:07] desrt: ah, I thought you wanted to do that for the specific case we were discussing [16:07] well, that too [16:07] :) [16:07] Laney, what you described, the dir has "en", the locale list not, that wouldn't intersect ... or you would suggest to transform "en" to the likely locale, e.g "en_US"? [16:07] desrt: well, don't. :) [16:07] (for those who were not watching our private conversation: we're talking about the dconf-writes-on-startup problem) [16:07] u-s-s should already be converting en to en_US iirc [16:08] man, I wanted to keep the mystery alive [16:08] larsu: sorry. not friday yet :) [16:08] at least for the purpose of listing it as the first 'en' locale [16:08] attente, right, what I'm trying to do is reverse [16:08] from the locales list, filter out those which don't have translations in /usr/share/locale-langpacks [16:09] seb128: Indeed [16:09] seb128: oh, so if only 'en' is installed, then 'en_US' should still work even if it doesn't exist? [16:09] no [16:09] en_US has its own dir [16:09] but e.g de_DE doesn't [16:09] use de instead of en [16:10] :P [16:10] I though that maybe xx_XX cases would short to "xx" [16:10] so I check for that [16:10] oh. that doesn't work? [16:10] Laney is challenging it being the right thing to do [16:10] it does [16:10] lol [16:10] desrt: ARGH this is even wrong in the docs: https://developer.gnome.org/libpeas/1.14/PeasEngine.html#PeasEngine--loaded-plugins [16:10] it's just that Laney think the likey thing is better [16:10] so I'm trying to wrap my head around that [16:11] the likely thing is only going from 'en' -> 'en_US' though [16:11] it seems more complex to me so far, but maybe I'm going to be able to grasp it ;-) [16:11] not in the other direction [16:11] yeah [16:11] you have en_US in the list of locales [16:11] i'm not sure how to do the other direction other than just trim the suffix [16:11] I think Laney wants me to throw the dirnames to the likely() converter [16:11] yes [16:11] and use that list [16:11] that seems more work though [16:11] I'm trying to think if I agree it's a better way ;-) [16:11] doesn't the code have this list anyway? [16:12] or almost have it [16:12] not yet at the place I want to exclude locales [16:13] is there going to be a separate place for format locales? [16:14] not in the current design [16:14] but who knows in the futur [16:15] what about things which aren't translated via langpacks? [16:16] I suppose we don't include all locales currently [16:16] huum [16:16] no, the goal is to list things that have translations on the device [16:16] no point picking a language which is not installed [16:17] they're not all installed centrally though [16:17] if a language has no string in the langpack I guess we can claim it's not translated enough to be supported [16:17]