[02:50]  * FJKong fell asleep last night..
[04:30] <pitti> Good morning
[06:03] <didrocks> good morning
[06:10] <larsu> morning!
[06:12] <seb128> good morning desktopers!
[06:34]  * pitti waves to the desktoppers, guten Morgen!
[06:34] <didrocks> good morning pitti
[06:37] <seb128> hey pitti!
[07:53] <willcooke> morningla
[07:53] <willcooke> er
[07:53] <willcooke> morning all
[07:55] <didrocks> hey willcooke
[07:56] <seb128> hey willcooke
[08:03] <Laney> hup hup hup
[08:03] <didrocks> hup Laney too
[08:06] <Laney> hey didrocks
[08:06] <Laney> vat iz up
[08:08] <seb128> hey Laney
[08:08] <seb128> hoe gaat het?
[08:09] <Laney> alles goed!
[08:09] <Laney> en met jou?
[08:09] <seb128> goed, danku :-)
[08:10] <Laney> dutch high five!
[08:10] <seb128> :-)
[08:13]  * Laney screams at all iso builds failing
[08:13] <Laney> looks like debootstrap is busticated
[08:21] <Laney> woah
[08:21] <Laney> "Could not apply the stored configuration for monitors"
[08:21] <Laney> and it's in like 640x480
[08:22] <Laney> okay, 1024x768, but that's just as bad :P
[08:22] <Laney> "Unknown display"
[08:25] <seb128> Laney, when/how?
[08:26] <Laney> just now when I booted
[08:26] <Laney> could have been not quite plugged in correctly, works now after jiggling the cable
[08:26] <Laney> or re-detecting would have worked anyway
[08:26] <Laney> see if it happens again
[08:26] <seb128> 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] <Laney> it had a big error about not being able to query the EDID
[08:27] <Laney> so probably defaulted to some emergency/safe resolution
[08:40] <Laney> ah, pitti is fixing debootstrap already
[08:40] <Laney> that is the best news!
[08:40] <pitti> Laney: yeah, fixed now
[08:41] <pitti> 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] <Laney> I got 36 or so emails about isos failing to build :-)
[08:41] <pitti> 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] <seb128> pitti, are you looking at the shotwell autopkgtest issue? just asking to not dup work
[08:46] <Laney> oh weird, I was going to merge that one soon, was on my list
[08:51] <pitti> seb128: I'm not; I just had a quick look, and it's due to uninstallability (so not infrastructure)
[08:51] <seb128> pitti, k
[08:51] <seb128> Laney, that one = ?
[08:51] <Laney> shotwell
[08:52] <seb128> please do
[08:52] <seb128> I just mentioned it because I got emailed by jenkins
[08:52] <Laney> seems someone already did?
[08:52] <Laney> or was it 0ubuntu1?
[08:52] <Laney> ah yes
[08:53] <Laney> uninstallability> doesn't look like it - seems like an autopilot failure to me
[08:53] <seb128> shrug
[08:53] <seb128> robert_ancell updated it
[08:54] <Laney> let the uploader deal with it ;-)
[08:54] <seb128> yeah, I was unsure if those evdev warning were normal
[08:55] <Laney> seems you only get stdout if it fails, so can't confirm from a successful run
[08:56] <seb128> I'm going to beat robert_ancell with a stack for that update
[08:56] <seb128> well, after I try it :p
[09:01] <seb128> I emailed upstream with https://mail.gnome.org/archives/shotwell-list/2015-February/msg00000.html
[09:02] <seb128> unsure if robert_ancell did something about it
[09:03] <Laney> oh, it got a headerbar?
[09:03] <Laney> quite glad that he got to it first then :)
[09:04] <seb128> hehe
[09:07] <pitti> 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] <pitti> but that's fixed now indeed
[09:07] <Laney> nod, sorry, didn't look back at all
[09:07] <pitti> Laney: so I suppose the UI changed, and the autopilot test needs adjusting
[09:08] <seb128> don't fix it
[09:08] <seb128> the update is buggy
[09:08] <seb128> emailing rob
[09:09] <Laney> tag a bug "block-proposed" + assign
[09:09] <Laney> it looks okay to me though
[09:09] <Laney> where do you see a problem?
[09:10] <seb128> Laney, open the preferences dialog
[09:10] <seb128> or the export one
[09:10] <seb128> or the publish one
[09:10] <seb128> e.g any dialog
[09:10] <seb128> Laney, https://mail.gnome.org/archives/shotwell-list/2015-February/msg00002.html has details
[09:10] <Laney> oh just the dialogs, I see!
[09:12] <seb128> yeah
[09:12] <seb128> "just"
[09:12] <seb128> :-)
[09:13] <Laney> much better than it being the main UI
[09:13] <Laney> there's a property that you can watch for dialogs
[09:17] <seb128> I should have Cced you on that email to robert_ancell
[09:17] <seb128> want me to resend with you in Cc?
[09:22] <Laney> 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] <Laney> okay, shotwell is vala, but the idea is the same
[09:22] <seb128> Laney, thanks
[09:22] <Laney> other file-roller commits have more complex cases but it doesn't look like shotwell has those
[09:22] <Laney> e.g. custom items in the header, .ui files, etc
[09:23] <seb128> Laney, done
[09:23] <Laney> thx
[09:23] <seb128> thank *you* ;-)
[09:27] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1456965 as well
[09:33] <Laney> great
[10:38] <willcooke> upgraded my desktop-next machine and now all I have is a flashing caps-lock light
[10:38] <willcooke> :(
[10:38] <czajkowski> willcooke: oops
[10:39] <willcooke> One strange thing I noticed was that after the upgrade "reboot" and "shutdown" commands were seemingly missing
[11:50] <seb128> willcooke, kernel issue? did you try booting a previous one?
[11:50] <seb128> well at least the led is usually a kernel issue
[11:51] <willcooke> seb128, tbh I've screwed around with it so much I dont think there was a valid set up on there.
[11:51] <willcooke> I've resintalled and it's fine now
[11:51] <willcooke> Once I've got this demo sorted for the sales engineers I will see if I can break it again
[11:52] <seb128> 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] <seb128> didrocks, pitti, ^ right?
[11:52] <seb128> willcooke, k
[11:55] <didrocks> leds flashing generally means a kernel issue, indeed
[11:55] <pitti> seb128, willcooke: maybe your $PATH didn't include /sbin/
[11:55] <pitti> ?
[11:56] <pitti> seb128, willcooke: reboot and friends are in upstart-sysv or systemd-sysv, and you should have either installed
[11:57] <seb128> didrocks, pitti, seems like willcooke reinstalled so I guess we are not going to debug that...
[11:57] <pitti> yeah
[11:58] <pitti> although I just noticed that init depends on systemd-sysv | upstart
[11:58] <pitti> that needs to be | upstart-sysv
[11:58] <pitti> (fix uploaded)
[11:58] <pitti> but that only seems tangential
[11:58] <willcooke> don't sweat it, that machine has had so many strange hacks applied it's not a valid install
[12:02] <seb128> 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] <pitti> seb128: no, not at all -- session bits haven't changed at all
[12:05] <pitti> I have tons of logs in ~/.cache/upstart
[12:06] <seb128> pitti, I've only 6 non .gz logs in there and most of the things are missing
[12:07] <seb128> journalctl seems to have a mix of session things as well
[12:18] <larsu> I thought everything started from gnome-session logs into the journal these days?!
[12:21] <seb128> seems so
[12:22] <didrocks> popey: my eyes!
[12:22] <larsu> think of his eyes!
[12:22] <seb128> larsu, hey, that's a bit confusing still, need to get used to it I guess
[12:23] <seb128> the journalctl log is just not well formatted and not easy to read
[12:23] <larsu> 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] <larsu> seb128: use gnome-logs ;) (and read the journalctl man page, it's got some good stuff)
[12:24] <seb128> larsu, is gnome-logs packaged?
[12:24] <seb128> seems it is
[12:24] <larsu> seb128: yes, but I don't know which version tbh (you need the one with my patches *cough*)
[12:24] <seb128> I should perhaps try it (or we should perhaps ship it by default if it's good?)
[12:24] <seb128> 3.14.2 it seems
[12:24] <larsu> yes, it is and we should
[12:24] <larsu> I've been planning some more stuff for it, but didn't have time yet
[12:25] <larsu> I can add menubar etc. upstream if we decide to ship it
[12:26] <seb128> cool
[12:41] <mdeslaur> pitti: you're upower upstreeam, aren't you?
[12:41] <mdeslaur> pitti: think you could review my patch when you get a chance? https://bugs.freedesktop.org/show_bug.cgi?id=90222
[12:43] <popey> didrocks: :D
[12:44] <pitti> mdeslaur: oh, with a test case! ♥
[12:46] <mdeslaur> pitti: of course! :)
[12:46] <seb128> some other potential patches on https://launchpad.net/ubuntu/+source/upower/+patches ;-)
[12:47] <mdeslaur> seb128: hey, mine first :)
[12:47] <pitti> seb128: oh, I didn't know about +patches, nice!
[12:47] <seb128> pitti, https://launchpadlibrarian.net/206524480/0001-rules-support-Logitech-Unifying-in-Linux-3.19.patch seems like something useful
[12:47] <seb128> that's bug #1448834
[12:48] <mdeslaur> seb128: I think that's upstream already
[12:48]  * mdeslaur remembers seeing something similar
[12:48] <seb128> mdeslaur, right, that bug is a request to backport to vivid
[12:48] <pitti> mdeslaur: how is your test different from _add_bt_mouse()?
[12:48]  * pitti compares the code in more detail
[12:48] <mdeslaur> pitti: device is "hid" and there is an extra "input" subdirectory
[12:50] <mdeslaur> ("hid" instead of "bluetooth")
[13:08] <pitti> mdeslaur: applied
[13:08] <pitti> seb128: cleaned up
[13:12] <mdeslaur> pitti: sweet! thanks! :)
[13:12] <seb128> pitti, danke
[13:14] <willcooke> qengho, pingaling
[13:15] <willcooke> hrm, contextless pings.  Must stop doing that
[13:25] <seb128> kenvandine, hey
[13:25] <seb128> kenvandine, what's the status of approved u-s-s fixes and landing?
[13:26] <seb128> 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] <kenvandine> seb128, hey, i'm trying to land a few at a time
[13:28] <kenvandine> but it's slow going
[13:28] <kenvandine> i can't land to wily first
[13:29] <seb128> why not?
[13:29] <kenvandine> because of the adt failures from autopilot/uitk
[13:29] <kenvandine> it gets held in proposed
[13:29] <seb128> can't we just flush think to wily?
[13:29] <kenvandine> they are working on that
[13:29] <seb128> are those real failures?
[13:29] <seb128> or buggy tools?
[13:29] <kenvandine> tools
[13:29] <seb128> can't we just override the results?
[13:29] <kenvandine> autopilot stuff that needs upstart
[13:30] <kenvandine> they have a fix, just last i heard it wasn't landed yet
[13:33] <kenvandine> seb128, do you know where the setting to enable ntp gets stored on disk?
[13:33] <kenvandine> we need to add the path to the whitelist so it persists on the read-only image
[13:36] <seb128> kenvandine, hum, let me check
[13:52] <seb128> kenvandine, what settings are you talking about? how do you enable/disable ntp? using the set-ntp timedated flag?
[13:52] <kenvandine> yes
[13:52] <kenvandine> that
[13:52] <kenvandine> org.freedesktop.timedate1
[13:54] <seb128> kenvandine, it enable/disable the job, at least under systemd
[13:54] <kenvandine> yeah, i just need to know how that gets stored
[13:54] <kenvandine> it's only persisting over reboots if the device is writable
[13:54] <kenvandine> not on read-only
[13:54] <kenvandine> so we're missing a path in the writable whitelist
[13:55] <seb128> kenvandine, seems to rename /etc/network/if-up.d/ntpdate to /etc/network/if-up.d/ntpdate.disabled
[13:55] <kenvandine> oh...
[13:56] <kenvandine> thanks!
[13:56] <seb128> yw!
[13:57] <kenvandine> seb128, about the landings, they'll speed up once the autopilot issue gets resolved
[13:57] <kenvandine> which should be soon...
[13:57] <seb128> kenvandine, can't we just override the test to get it to migrate?
[13:58] <seb128> or keep it in proposed and do other landings
[13:58] <kenvandine> there are lots of things we could do :)
[13:58] <seb128> that "charge graph has a wrong initial value" bug is stupid, that fix shouldn't take that long to land
[13:58] <kenvandine> but the fix should have been quicker than this
[13:58] <seb128> it should land in vivid as well imho
[13:58] <seb128> graphs look wrong atm
[13:58] <tjaalton> evolution-source-registry takes 370MB RAM on my desktop.. can I disable it somehow?
[13:58] <kenvandine> yeah, agreed
[13:58] <seb128> tjaalton, rm? mv? apt-get remove?
[13:58] <kenvandine> it has to be on the ota4 milestone or qa isn't going to look at it
[13:59] <seb128> kenvandine, let me ping Pat
[13:59] <tjaalton> good idea
[13:59] <seb128> tjaalton, does it take as much if you restart it?
[13:59] <kenvandine> 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] <seb128> kenvandine, I would be happy to handle landing if you refresh my memory on what to do
[14:00] <kenvandine> seb128, this systemd-shim and persistance is on the ota4 milestone, so gotta get that done too
[14:00] <seb128> kenvandine, I know how to drive the system, I'm just not uptodate on "politics"
[14:00] <kenvandine> easier for wily :)
[14:00] <seb128> no qa needed there?
[14:00] <kenvandine> and i bet you could get away with more than 3 fixes per silo for wily :)
[14:01] <seb128> can we just flush the pending queue to wily?
[14:01] <kenvandine> afaik we aren't gating on qa for wily right now
[14:01] <seb128> great
[14:01] <tjaalton> seb128: the parent seems to be upstart --user, but initctl doesn't show it
[14:01] <kenvandine> which worries me... because then if they block a backport to vivid later we have to rework stuff
[14:01] <kenvandine> but... they don't have the resources to verify every fix for wily and vivid
[14:02] <seb128> kenvandine, confirmed the file rename on my bq rtm rw btw
[14:02] <kenvandine> yeah, i did too
[14:02] <kenvandine> thanks for that!~
[14:02] <seb128> yw!
[14:02] <kenvandine> now to figure out who to go to about fixing that in lxc-android-config now
[14:03] <Laney> ...
[14:03] <seb128> kenvandine, good luck, I think rename don't play along with the bind mount hack
[14:03] <Laney> renames are bad
[14:04] <seb128> kenvandine, you might need something along http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=10f312d34a39cb2c5738d48705498fdfec38e9f0
[14:04] <seb128> in systemd-shim
[14:05] <seb128> e.g make it rename /etc/writable/... rather than the normal file
[14:05] <seb128> I just did a hack like that for whoopsie yesterday
[14:07] <kenvandine> seb128, so you know how to fix something like this?
[14:08] <kenvandine> maybe you could do it :)
[14:08] <seb128> kenvandine, lol, nice try
[14:08] <kenvandine> i have the partial systemd-shim fix in silo 35
[14:08] <seb128> well, I'm unsure that's needed there
[14:09] <seb128> and I can't see I'm a fan of the change I submitted for whoopsie
[14:09] <seb128> waiting for somebody to review that one first before considering copying that somewhere else
[14:09] <kenvandine> rsalveti, i assume you're not the guy to go to for lxc-android-config anymore?
[14:09] <Laney> it feels disturbing to be sprinkling this around everywhere
[14:10] <seb128> Laney, well, less disturbing that having our phone buggy for users
[14:10] <Laney> ...
[14:10] <seb128> Laney, do you see any other option?
[14:10] <seb128> +doable
[14:11] <Laney> don't know, could try to think
[14:11] <Laney> not interested in a trolling argument
[14:11] <seb128> well, me neither
[14:11] <Laney> I'm not saying that not fixing it is better
[14:11] <seb128> I'm just saying that we didn't figure out a better way to do this
[14:11] <Laney> but also doing weird hacks is not good
[14:11] <seb128> I don't like it either
[14:11] <seb128> right, I think we agree
[14:11] <seb128> I just don't have anything better to propose
[14:12] <seb128> it's the less sucky option we have atm afaik
[14:17] <kenvandine> 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] <kenvandine> enabling/disabling ntp  renames between /etc/network/if-up.d/ntpdate and /etc/network/if-up.d/ntpdate.disabled
[14:18] <kenvandine> rsalveti, is that something we can handle?
[15:35] <rsalveti> kenvandine: got a minute now :-)
[15:35] <rsalveti> guess this is the conversation that is happening at phablet now
[15:38] <kenvandine> yeah
[15:45]  * Laney screams at jffi
[15:46]  * larsu calms down Laney with a cookie and some tea (with milk)
[15:46] <Laney> I have jelly and tea atm
[15:46]  * Laney transmits a picture
[15:46] <larsu> ooh nice
[15:46] <larsu> please do transmit
[15:47]  * larsu wonders why totem resets active-plugins gsettings key when starting
[15:48] <Laney> I wonder what sin I committed in a previous life to be having to try and compehend java build systems
[15:48] <larsu> :(
[15:51] <larsu> wow. totem writes that key thrice on startup
[15:51] <Laney> hadessssssssssssssssssssssss
[15:51]  * larsu shaves yet another yak
[15:51] <larsu> seems to be libpeas' fault though
[15:51] <Laney> you have to fix this for that bug?
[15:52] <larsu> nope, I don't have to
[15:52] <larsu> I guess you're telling me to get my priorities straight? >P
[15:52] <Laney> ah, one of those
[15:52] <Laney> :P
[15:52] <Laney> up to you
[15:52] <larsu> I mostly need it to work to test turning on/off plugins
[15:53] <larsu> because they insert menu items
[15:53] <larsu> and apparently some are not turn-aoofable
[15:53] <larsu> *turn-offable
[15:53] <seb128> Laney, kenvandine, pitti, any comment/opinion on http://paste.ubuntu.com/11246865/ to filter out locales which correspond to a separate language?
[15:56] <seb128> 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] <Laney> I think assuming that the country and the language are the same is a bad heuristic
[15:58] <Laney> fails for zh_CN for example
[15:58] <seb128> zh_CN has a dir with that name
[15:59] <Laney> It's just an example
[15:59] <seb128> it's to catch fr_FR having no fr_FR but only "fr" on disk
[15:59] <seb128> same for de_DE being de
[15:59] <Laney> I think that libicu has a facility for this if you are trying to keep the 'main' language
[15:59] <seb128> no, I don't want to keep the main language
[16:00] <seb128> because en_AU would give me "en" which is a dir on disk
[16:00] <seb128> but we don't want en_AU listed
[16:00] <Laney> what is this comparison doing in addition to looking at the directory?
[16:00] <seb128> making de_DE listed
[16:00] <seb128> because /usr/share/locale-langpack/de_DE doesn't exists
[16:01] <seb128> only /usr/share/locale-langpack/de
[16:01] <seb128> we would have no german listed at all without that bit
[16:01] <seb128> I assume that "xx_XX" is shortened to dir "xx"
[16:01] <seb128> but I might be wrong
[16:01] <Laney> the code already builds a list
[16:01] <Laney> so you can say 'give me the likely locale for "de"'
[16:01] <seb128> list of?
[16:02] <Laney> I think
[16:02] <Laney> or at least you could make it do that
[16:02] <seb128> hum
[16:02] <seb128> I'm not sure to understand what you mean "likely locale"
[16:02] <Laney> I remember attente adding some knowledge of this concept
[16:02] <Laney> he called it likely, it's what you're trying to do here I think
[16:02] <seb128>     // Should be true if locale is the default for its language.
[16:02] <seb128>     // e.g. 'en_US' is the likely locale for 'en', 'en_CA' is not.
[16:02] <seb128>     bool likely;
[16:02] <seb128> no
[16:03] <seb128> en_US has its own dir
[16:03] <seb128> I don't want that shortened
[16:03] <Laney> no
[16:03] <Laney> you could only do this lookup if you need to
[16:03] <seb128> that is reverse compared to what I want no?
[16:04] <Laney> so you have 'de', that's not a locale, so find out what the likely locale for 'de' is
[16:04] <seb128> well, I don't have "de"
[16:04] <seb128> I've the output of locale -a
[16:04] <seb128> de_CH.utf8
[16:04] <seb128> de_DE.utf8
[16:04] <seb128> de_LI.utf8
[16:04] <seb128> etc
[16:04] <seb128> and I want to filter out the ones with no translation installed in /usr/share/locale-langpacks
[16:05] <seb128> so my current way is to split .utf-8 and check if the remaining bit exists in the dir
[16:05] <desrt> pitti: hey... question...
[16:05] <seb128> that works for e.g en_US
[16:05] <seb128> or en_GB
[16:05] <Laney> so you want to list that directory, make sure they are all locales by doing this 'likely' lookup
[16:05] <desrt> pitti: is there some API i can use for apport to report an issue?
[16:05] <Laney> and then intersect this with the locale -a output
[16:06] <desrt> 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] <desrt> and i want apport to file a bug against the correct program, etc.
[16:06] <Laney> or do this step by step, whatever
[16:06] <larsu> desrt: yes, but please don't
[16:06] <seb128> Laney, sorry I don't understand :-(
[16:06] <larsu> desrt: instead, let's route all criticals to apport
[16:06] <desrt> larsu: that's sort of what i'm getting at...
[16:07] <larsu> desrt: ah, I thought you wanted to do that for the specific case we were discussing
[16:07] <desrt> well, that too
[16:07] <desrt> :)
[16:07] <seb128> 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] <larsu> desrt: well, don't. :)
[16:07] <desrt> (for those who were not watching our private conversation: we're talking about the dconf-writes-on-startup problem)
[16:07] <attente> u-s-s should already be converting en to en_US iirc
[16:08] <larsu> man, I wanted to keep the mystery alive
[16:08] <desrt> larsu: sorry.  not friday yet :)
[16:08] <attente> at least for the purpose of listing it as the first 'en' locale
[16:08] <seb128> attente, right, what I'm trying to do is reverse
[16:08] <seb128> from the locales list, filter out those which don't have translations in /usr/share/locale-langpacks
[16:09] <Laney> seb128: Indeed
[16:09] <attente> seb128: oh, so if only 'en' is installed, then 'en_US' should still work even if it doesn't exist?
[16:09] <seb128> no
[16:09] <seb128> en_US has its own dir
[16:09] <seb128> but e.g de_DE doesn't
[16:09] <Laney> use de instead of en
[16:10] <Laney> :P
[16:10] <seb128> I though that maybe xx_XX cases would short to "xx"
[16:10] <seb128> so I check for that
[16:10] <attente> oh. that doesn't work?
[16:10] <seb128> Laney is challenging it being the right thing to do
[16:10] <seb128> it does
[16:10] <attente> lol
[16:10] <larsu> desrt: ARGH this is even wrong in the docs: https://developer.gnome.org/libpeas/1.14/PeasEngine.html#PeasEngine--loaded-plugins
[16:10] <seb128> it's just that Laney think the likey thing is better
[16:10] <seb128> so I'm trying to wrap my head around that
[16:11] <attente> the likely thing is only going from 'en' -> 'en_US' though
[16:11] <seb128> it seems more complex to me so far, but maybe I'm going to be able to grasp it ;-)
[16:11] <attente> not in the other direction
[16:11] <seb128> yeah
[16:11] <Laney> you have en_US in the list of locales
[16:11] <attente> i'm not sure how to do the other direction other than just trim the suffix
[16:11] <seb128> I think Laney wants me to throw the dirnames to the likely() converter
[16:11] <Laney> yes
[16:11] <seb128> and use that list
[16:11] <seb128> that seems more work though
[16:11] <seb128> I'm trying to think if I agree it's a better way ;-)
[16:11] <Laney> doesn't the code have this list anyway?
[16:12] <Laney> or almost have it
[16:12] <seb128> not yet at the place I want to exclude locales
[16:13] <Laney> is there going to be a separate place for format locales?
[16:14] <seb128> not in the current design
[16:14] <seb128> but who knows in the futur
[16:15] <Laney> what about things which aren't translated via langpacks?
[16:16] <Laney> I suppose we don't include all locales currently
[16:16] <seb128> huum
[16:16] <seb128> no, the goal is to list things that have translations on the device
[16:16] <seb128> no point picking a language which is not installed
[16:17] <Laney> they're not all installed centrally though
[16:17] <seb128> if a language has no string in the langpack I guess we can claim it's not translated enough to be supported
[16:17] <Laney> not sure how click packages are translated
[16:17] <seb128> you mean?
[16:17] <Laney> but I would guess that they ship that themselves
[16:17] <Laney> or any universe app
[16:17] <seb128> right
[16:17] <Laney> can't select those languages
[16:18] <seb128> well, you don't want to advertise a language if the base OS has 0 translation for it
[16:18] <seb128> even if some click has some
[16:19] <seb128> it's like "oh, nice, esperanto is listed in the languages (because d_sert submitted and app and included some translations)
[16:19] <seb128> but then you select it and nothing displays in esperanto
[16:19] <seb128> -> disappointed
[16:20] <seb128> the langpack approximation is not perfect but I think it's good enough?
[16:20] <Laney> oh I translated my favourite app to my language becaue my english isn't very good but the system won't let me pick it :(
[16:21] <attente> oh. so this is a question of whether filtering by installed langpacks is the right thing to do to begin with
[16:21] <Laney> I moved it on a bit ;-)
[16:21] <Laney> that is also a problem with what we have atm
[16:22] <seb128> Laney, well, it's about setting expectations as well
[16:22] <seb128> anyway, I discussed it for over an hour yesterday with mpt
[16:22] <Laney> I could imagine "install additional languages" which downloads the langpack
[16:22] <Laney> and maybe shows you % translated if that's possible
[16:22] <seb128> we didn't find a good/robust way to flag valid languages
[16:23] <seb128> we need something that simply the current list even if not perfect
[16:23] <seb128> Laney, sure, I'm happy to revisit our code the day we have click langpacks
[16:23] <Laney> I'm not rejecting your solution
[16:23] <seb128> which is on the roadmap
[16:23] <seb128> but not being worked on yet
[16:23] <Laney> it's okay to suggest ways in which it could be better though
[16:23] <seb128> yes
[16:23] <seb128> I would like to land the first step though
[16:23] <seb128> then we can discuss futur
[16:24] <seb128> we sort of collide both topics now and I'm unsure which ones you would like to see fixed for the first landing
[16:24] <Laney> that's why I gave you feedback on the code first
[16:24] <Laney> and then started talking about the merts of the approach
[16:24] <seb128> yeah, just trying to recap what needs to be changed
[16:25] <seb128> so you would for the first landing do a dirList.likelyLocale() iteration to transform the list
[16:25] <seb128> then match on that?
[16:25] <Laney> one second, moving back upstairs
[16:25] <Laney> getting cold
[16:25] <seb128> why do you think it's better than the simple xx=XX check?
[16:25] <pitti> seb128: that won't work in some cases like sv_SE, or sr_RS@latin, but probably a good first heuristics
[16:26]  * pitti <- just a quick drive by; sorry, uber-busy today, and need to leave to sports
[16:26] <pitti> desrt: the python API is quite rich; for C, you basically need to drop a report file into /var/crash
[16:26] <seb128> pitti, ok, thanks
[16:26] <pitti> desrt: we have some helpers like /usr/share/apport/recoverable_problem which you can call with arguments
[16:27] <pitti> desrt: maybe you can already use that, maybe we need someting similar
[16:27]  * pitti waves, sorry
[16:27] <seb128> pitti, do you know of a better heuristic?
[16:27] <desrt> pitti: i'll take a look
[16:27] <desrt> thanks
[16:27] <seb128> pitti, have a good evening
[16:27] <seb128> pitti, let's chat tomorrow
[16:34] <Laney> seb128: I just installed all langpacks and there's 'xh' which corresponds to 'xh_ZA' and 'te' -> 'te_IN' for example
[16:35] <seb128> Laney, yeah, pitti mentioned sr_RS
[16:35] <Laney> ya
[16:36] <Laney> actually only en and zh have variants translated it seems
[16:38] <didrocks> have good evening guys
[16:38] <Laney> this guy quits too fast
[16:38] <desrt> +1
[16:43] <seb128> Laney, so you think maybe not listing variants out of en_XX zn_XX ones?
[16:45] <Laney> those are the ones we have now but I guess there could be more in future
[16:46] <Laney> I was mainly trying to support my original idea ;)
[16:46] <larsu> desrt: I need a hidden-when=action-missing-or-disabled
[16:46] <seb128> Laney, would your original idea work in all cases?
[16:46] <seb128> I'm trying to do that bug get some issues
[16:47] <Laney> if the likely information is right ...
[16:48] <seb128> qWarning() << "likely" << likelyLocaleForLanguage[language];
[16:48] <seb128> that always return "" for me
[16:48] <seb128> I'm probably doing something wrong
[16:48] <seb128> or that code doesn't work
[16:50] <seb128> shrug, the likely things works by calling "/usr/share/language-tools/language2locale"
[16:50] <seb128> which is some script hackery
[16:56] <Laney> ah that contains the mapping
[16:56] <Laney> would be better if that was dynamic, not sure if anywhere has this info
[16:57] <desrt> larsu: 'disabled' also hides actions when they're missing
[16:57] <desrt> since missing actions are always disabled...
[16:57] <larsu> oh that makes sense of course! thanks :)
[17:00] <seb128> Laney, thanks for the input, I think I'm going to think about this overnight
[17:00] <seb128> I don't like much that likely thing
[17:01] <seb128> calling some external shell script on every locale
[17:01] <seb128> that probably contribute to that panel being slow to open
[17:01] <seb128> I would like to remove that rather than stack more use to it
[17:01] <Laney> it's not going to make it be called any more times ...
[17:01] <seb128> so maybe just loading the file with the map list
[17:02] <seb128> right, but I want to remove those calls now that I saw them :p
[17:02] <Laney> I don't care for the specifics, it's the idea
[17:02] <seb128> thanks
[17:02] <Laney> it basically comes down to reading this main-countries file and some fallback cases
[17:03] <seb128> yeah
[17:03] <seb128> those locales things are more difficult that they should be :-/
[17:03] <seb128> on that note have a good evening everyone
[17:04] <seb128> Laney, thanks again for the feedback ;-)
[17:04] <Laney> seb128: you could make it accept multiple inputs and output them all, then you only have to call it once
[17:04] <Laney> instead of reimplementing it in C++ ;-)
[17:04] <Laney> no worries
[17:04] <Laney> bye from me too!
[17:05] <seb128> bye :-)
[17:05] <Laney> god damn jffi defeated me
[17:05] <Laney> i'll be back tomorrow to take it on again
[17:08]  * willcooke -> EOD
[17:09] <desrt> this guy quits too fast