[04:56] <Mirv> morning
[05:21] <cyphermox> Mirv: morning
[05:21] <Mirv> cyphermox: hullo
[05:22] <cyphermox> so, so far I haven't been able to find out what's wrong with phonesim -- if I disable it though, the lab devices seem to work properly
[05:23] <cyphermox> so I think we'll need to involve pitti to look at what's up with phonesim or the related pieces
[05:25] <pitti> cyphermox: define "wrong"?
[05:25]  * Mirv switches computers to dedicate this one to test libunity
[05:25] <cyphermox> pitti: unclear, sadly
[05:26] <cyphermox> pitti: seems that now, the phones in the QA lab tend to get stuck with indicator-network/dbus/ofono in high CPU
[05:26] <cyphermox> it happens about 30% of the time, apparently
[05:27] <cyphermox> but you quickly notice indicator-network hiking up to 60%+ CPU for a while when phonesim gets restarted, and sometimes (that 30% I was telling about) on boot
[05:27] <pitti> cyphermox: oh, is that still the "NetworkManager crashes in a loop" problem?
[05:27] <cyphermox> I looked, but I can't make sense of the reason -- it's hard to figure out what's going on
[05:27] <pitti> bug 1231964 ?
[05:27] <ubot2> Launchpad bug 1231964 in network-manager (Ubuntu) "NetworkManager crashes in ofono plugin with phonesim [crashed with SIGSEGV in <unavailable> in ??()]" [High,Triaged] https://launchpad.net/bugs/1231964
[05:27] <cyphermox> pitti: NM doesn't seem to be crashed, but hold on
[05:27] <cyphermox> that could be it, maybe
[05:28] <pitti> I didn't notice this NM crash any more on my recent phone test runs, though
[05:28] <pitti> when I reported the bug, I had to kill NM to make it not go crazy
[05:28] <pitti> but I haven't done this any more for weeks
[05:28] <cyphermox> this isn't a new bug though, so yeah
[05:28] <pitti> but as NM didn't change, I guess we are missing something there
[05:28] <cyphermox> well
[05:28] <pitti> so I figure this only happens in some cases
[05:28] <cyphermox> NM did change -- we're getting 0.9.8.4 now in the images
[05:29] <pitti> cyphermox: oh, it's only happening since that update?
[05:29] <pitti> I haven't tried .4 on the phones yet indeed
[05:29] <cyphermox> but the ofono code certainly hasn't change between then and now
[05:29] <pitti> cyphermox: is that on the latest trusty image? flashing now
[05:29] <cyphermox> in theory yes
[05:30] <cyphermox> I don' think you'd see indicator-network in high CPU though, in that case
[05:30] <cyphermox> hold on, I can check if NM crashed on the mako used by psivaa as an example
[05:31] <cyphermox> hmm
[05:31] <cyphermox> no crash in /var/crash for NM
[05:31] <cyphermox> and no segfault apparent in /var/log/syslog.
[05:31] <pitti> ok, so it's not that then
[05:32] <cyphermox> pitti: if you want to play with this stuff, you can use adb  -s 01ade38b552014d4 shell
[05:32] <cyphermox> in the lab
[05:32] <pitti> so 9 hours ago we got https://code.launchpad.net/~boiko/dialer-app/fix_ap_1.4/+merge/194205/comments/447936 which apparently at least succeeded
[05:32] <cyphermox> ah?
[05:33] <cyphermox> pitti: didrocks mentioned it was happening since Tuesday.
[05:33] <pitti> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/3174/? has two crash reports, but they've always happened (and are known bugs)
[05:34] <cyphermox> yeah, looks consistent with what I have on the device right now
[05:37] <cyphermox> pitti: as one thing I noticed in recent proposed images was that I didn't have write access to /var/lib/dpkg even with a writable image, maybe this is breaking dbus in some way that upsets phonesim
[05:37] <cyphermox> or phonesim itself
[05:38] <cyphermox> nevermind, both are explicitly listed in mounts
[05:46] <cyphermox> pitti: so here's the full list of changes from 1105, which would be relevant for what we're looking at, possibly: http://people.canonical.com/~ogra/touch-image-stats/20131105.changes
[05:49]  * pitti taps foot waiting for flashing to finish
[05:50] <cyphermox> hehe
[05:54] <pitti> cyphermox: ok, flashed
[05:55] <pitti> cyphermox: so, do you already see this happening when merely starting phonesim, or just when the tests run?
[05:55] <cyphermox> yeah even just starting with-ofono-phonesim I see it happening
[05:55] <pitti> i. e. should I do "sudo apt-get install ofono-phonesim-autostart"?
[05:55] <pitti> ack
[05:55] <cyphermox> yup
[05:58] <pitti> 2394 B/s
[05:59] <pitti> oh c'mon, ports.u.c.!
[06:00] <pitti> cyphermox: so this image ("trusty" channel) still has NM 0.9.8.0-0ubuntu22
[06:01] <pitti> I wonder where ogra_ takes his image from :)
[06:01] <cyphermox> tursty-proposed :)
[06:01] <cyphermox> trusty, I mean
[06:01] <pitti> that's what I used
[06:01] <cyphermox> the proposed one?
[06:02] <pitti> cyphermox: started "sudo with-ofono-phonesim", indicator-network spins CPU at 70% indeed
[06:02] <cyphermox> well at least now we're confirmed without doubt that it's not NM
[06:02] <pitti> and on the phone, when I open it I see "Empty!"
[06:02] <cyphermox> but it makes it that much less clear what's wrong
[06:03] <pitti> strace says its spinning on a poll()/write() loop
[06:03] <cyphermox> yeah, I was seeing the same
[06:03] <abhishek_> I want to port Ubuntu Desktop on my Development board which is having Android
[06:03] <cyphermox> isn't write failing?
[06:03] <abhishek_> Can someone please helpme
[06:03] <pitti> fd 11 is anon_inode:[eventfd], whatever that is
[06:03] <cyphermox> or maybe it was a read what was failing with EAGAIN before
[06:04] <pitti> cyphermox: no, write succeeds, read() is EAGAIN
[06:04] <cyphermox> pitti: what process is that?
[06:04] <pitti> and there is a really fast poll which times out
[06:04] <pitti> cyphermox: indicator-network-service
[06:04] <cyphermox> yeah
[06:04] <cyphermox> ok
[06:05] <pitti> $ pkill -f indicator-network-service; /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service
[06:05] <pitti> ** (process:4256): ERROR **: network-menu.vala:202: Unable to get D-Bus bus name
[06:05] <pitti> meh, it respawns too fast
[06:05] <pitti> and that's why useful D-BUS services have a "--replace" option :)
[06:06] <cyphermox> so hey, I couldn't see the ofono-phonesim.conf dbus config file in /etc/ofono, that's because of the mount in with-ofono-phonesim, right/
[06:06] <abhishek_> ogra told me to create kernel zImage and initrd.img images ....and pack both these using abootimg utility .......I have created the zImage ....but I don't know how to create initrd.img. Please tell me how to create
[06:06] <pitti> cyphermox: right, it's an unshared tmpfs overlay, to avoid modifying the system
[06:07] <pitti> cyphermox: hm, I managed to start it in the foreground now, but its quiet now
[06:07] <cyphermox> abhishek_: phone?
[06:07] <abhishek_> I have IFC6410 development board which is having android
[06:08] <abhishek_> I have android BSP available to me
[06:08] <cyphermox> abhishek_: ogra_ should be around again soon, I'd think, you may want to ask him directly, and probably more in #ubuntu-touch if it's for touch
[06:08] <abhishek_> I want to run Ubuntu on this board
[06:08] <cyphermox> ok
[06:08] <abhishek_> It's for Desktop
[06:09] <abhishek_> cyphermox: Can you please give me some guidlines ....to create initrd.img ...
[06:10] <abhishek_> cyphermox: I am using Kernel source from Android source .....
[06:10] <cyphermox> abhishek_: that usually gets built along with teh zImage
[06:10] <abhishek_> cyphermox: Please give me some guidelines ...this will help me alot
[06:10] <pitti> cyphermox: got it to spin now in the foreground, but no output at all (except for a single "CRITICAL **: nm_device_get_iface: assertion 'NM_IS_DEVICE (device)' failed" which happened when I started phonesim)
[06:11] <cyphermox> hrm
[06:11] <cyphermox> pitti: spin as in do nothing useful?
[06:13] <pitti> cyphermox: do you see polkitd spinning as well? (and apport coming up often)
[06:13] <cyphermox> I had not noticed it, no
[06:13] <pitti> ERROR: apport (pid 8040) Thu Nov  7 07:13:38 2013: called for pid 8036, signal 5, core limit 0
[06:13] <pitti> ERROR: apport (pid 8040) Thu Nov  7 07:13:38 2013: executable: /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service (command line "/usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service")
[06:13] <pitti> every 2 seconds
[06:13] <cyphermox> let me look it up
[06:14] <cyphermox> hey, that would explain a lot
[06:14] <pitti> but that might be because I'm running it in the foreground now, and D-BUS activation repeatedly fails because the name is taken
[06:14] <pitti> /usr/share/upstart/sessions/indicator-network.conf
[06:14] <pitti> oh dear, why do we have to upstartify everything?
[06:14]  * pitti yells "D-BUS activation!"
[06:15] <abhishek_> cyphermox: I didn't found that .....I used update_initramfs to create initrd.img for my Laptop kernel (when I upgraded my laptop kernel) .......But, I don't know how to create the initrd.img for the kernel which is meant for some other board?
[06:15] <pitti> cyphermox: yep, that stopped the apport/polkit loop :)
[06:15] <pitti> cyphermox: ok, running under gdb in the foreground now
[06:16] <pitti> but now it's quiet, of course
[06:16] <cyphermox> abhishek_: I don't know. I think you should ask ogra_ directly
[06:16] <cyphermox> pitti: yeah :/
[06:16] <abhishek_> cyphermox: Ok ....thanks
[06:16] <pitti> cyphermox: ok, reboot, and attaching gdb directly when it happens
[06:17] <abhishek_> cyphermox: Is orgra around ?
[06:17] <pitti> unlikely at this hour
[06:17] <abhishek_> *ogra
[06:17] <pitti> give it another hour or two
[06:17] <abhishek_> ok
[06:17] <cyphermox> oh!
[06:18] <cyphermox> pitti: I got a g_source_destroy_internal() in gdb now
[06:19] <cyphermox> ah, I get all kinds of things if I'm lucky enough
[06:22] <pitti> yeah, all main loop/poll stuff
[06:22] <cyphermox> actually, not so much
[06:24] <pitti> aah
[06:24] <pitti> $ pkill -f indicator-network-service; G_DBUS_DEBUG=all G_MESSAGES_DEBUG=all /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service
[06:24] <cyphermox> for instance: http://paste.ubuntu.com/6374719/
[06:24] <pitti> cyphermox: ^ that's the magic
[06:24] <cyphermox> ah, wise!
[06:25] <cyphermox> I've exceeded my efficiency time for tonight :)
[06:25] <pitti> cyphermox: so you apparenlty can stop the spinning by merely killing the indicator, it'll respawn and behave
[06:25] <cyphermox> no
[06:26] <cyphermox> maybe sometimes it works but I did kill it a few times and got it back i nthe same state
[06:28] <pitti> cyphermox: http://people.canonical.com/~pitti/tmp/indicator-network-service.log.xz
[06:29] <cyphermox> liek http://paste.ubuntu.com/6374736/ ?
[06:29] <pitti> it loops in StartServiceByName()
[06:30] <pitti> cyphermox: yes
[06:30] <cyphermox> yeah
[06:30] <pitti> The name org.ofono was not provided by any .service files
[06:30] <pitti> !?
[06:32] <cyphermox> well eventually it does find it though
[06:34] <pitti> I let it spin for 20 seconds or so, ofono was well up and running at that time
[06:35] <cyphermox> http://paste.ubuntu.com/6374745/
[06:35] <cyphermox> yes, it was
[06:35] <cyphermox> something's wrong
[06:35] <cyphermox> ^ ofono is up, indicator talks to it
[06:36] <cyphermox> in the end it's still waiting for something though
[06:37] <cyphermox> urgh
[06:37] <cyphermox> http://paste.ubuntu.com/6374764/
[06:40] <pitti> cyphermox: do you see anything interesting there?
[06:41] <cyphermox> nevermind no
[06:44] <cyphermox> can I let you keep looking into it?
[06:45] <cyphermox> I really should get to bed by now, it's nearing up on 2am
[06:45] <pitti> cyphermox: yeah, better go to bed; I've got some other fires to put out, but I guess it's not that desperately urgent?
[06:46] <cyphermox> it's pretty crippling for the testing of the phone images, apparently
[06:46] <cyphermox> but I have really no way to tell how urgent, better ask didrocks about that
[06:51] <Mirv> cyphermox: would you be still up to pkg ack? http://pastebin.ubuntu.com/6374808/
[06:52] <cyphermox> sure
[06:52] <Mirv> (basically bzr 306 + 307 from https://code.launchpad.net/~unity-team/libunity/trunk)
[06:52] <Mirv> we need it to unblock unity + ap + everything, I've now tested it
[06:53] <cyphermox> yeah, it's fine. I just wish they made commit messages a bit more meaningful for changelogs than just "Make tracing easy"
[06:53] <pitti> test_extras_LDFLAGS = -static !?
[06:54] <pitti> the rest looks okay to me
[06:54] <pitti> Mirv: ^
[06:54] <Mirv> yes, I guess it's related to "Making tracing easy" but explanation would be nice
[06:54] <Mirv> I wonder if mhr3 would be up soon
[06:57] <Mirv> filed bug #1248840
[06:57] <ubot2> Launchpad bug 1248840 in libunity "Make libunity test extras not link static or add a comment" [High,New] https://launchpad.net/bugs/1248840
[06:59] <Mirv> pitti: does it hurt if it's in tests only, so not in published binary packages anywhere?
[06:59] <pitti> Mirv: not sure, but why would you want it in the first place?
[06:59] <pitti> it seems better to me to test the actual .so libs that you built
[07:00] <Mirv> pitti: beyond me, my only guess it's related to that tracing one way or another. but I filed the bug to get an explanation committed.
[07:02] <Mirv> pitti: it seems all the other tests already had the -static, this just adds it to the _extras too
[07:14] <Mirv> pitti: since it's just harmonizing the Makefile to what was already being used, do you think the bug report is enough for now? I'd like to release it, and all tests ran fine.
[07:14] <Mirv> it's blocking the autopilot 1.4 transition at the moment
[07:15] <pitti> Mirv: oh yes, I do; thanks for filing
[07:15] <Mirv> ok, thanks
[07:45] <Mirv> it happened again! drwx------ 2 root root  80 marra  7 08:46 pulse (in /run/user/1000)
[07:45] <Mirv> I wonder what's causing that, I need to chown it to make sound work again
[08:03] <mlankhorst> morning btw :P
[08:06] <Mirv> morning mlankhorst
[08:18] <Mirv> mornign sil2100
[08:26] <sil2100> Morning!
[08:27] <sil2100> Mirv: hmmm, strange, but stuff didn't leave proposed yet from what I see?
[08:27] <Mirv> sil2100: nothing strange about that, see landing plan
[08:28] <sil2100> Mirv: Ken checked in my evening and he said that the last missing link blocking  stuff was unity-autopilot
[08:28] <sil2100> Mirv: ah, libunity
[08:28] <sil2100> Mirv: this Ken didn't notice, oh well
[08:28] <Mirv> sil2100: yep, but it was not really
[08:29] <sil2100> Mirv: thanks for publishing that o/
[08:29] <Mirv> testing was hard, that's why it's already 3.5h since I started
[08:29] <Mirv> cu2d was of no use etc
[09:05] <didrocks> bonjour pitti! ça va?
[09:05] <pitti> bonjour didrocks ! ça va bien, et toi ?
[09:06] <didrocks> pitti: on fait aller :)
[09:06] <pitti> didrocks: c'est tard pour toi, c'est encore le jetlag ?
[09:06] <didrocks> pitti: cyphermox told me you are looking at what is causing the network indicator to become crazy in the QA lab after boot?
[09:06] <didrocks> pitti: oui, encore du jetlag :/
[09:06] <didrocks> pitti: like, it would be an ofono-phonesim issue?
[09:06] <pitti> didrocks: cyphermox and I took a stab at debugging this this morning, but we didn't yet get that far; have to put out some fires first
[09:07] <pitti> didrocks: it seems indicator-network-service is spinning on trying to contact ofono over D-BUS
[09:07] <didrocks> pitti: I'm still puzzled as http://people.canonical.com/~ogra/touch-image-stats/20131105.changes doesn't have any ofono/indicator changes
[09:08] <didrocks> (and as told in my email, we try to revert network-manager)
[09:08] <didrocks> pitti: do you think you'll have time to have a look later on? It's basically what is going to block us to publish some results
[09:08] <pitti> didrocks: not sure where ogra_ took his image from, but I flashed from the "trusty" channel this morning, that got me the old network-manager for example, so I guess it's an older image
[09:08] <pitti> didrocks: don't bother, it's not network-manager
[09:08] <didrocks> pitti: trusty-proposed
[09:09] <pitti> err, devel, devel-proposed, trusty, trusty-proposed..
[09:09] <pitti> didrocks: but as I said, it's nothing to do with http://people.canonical.com/~ogra/touch-image-stats/20131105.changes
[09:09] <pitti> didrocks: where do you see this?
[09:09] <didrocks> pitti: on the image containing those changes (in the QA lab only)
[09:09] <pitti> didrocks: we ran a phonesim dialer-app test just about 10 hours ago on mako and maguro which succeeded
[09:10] <didrocks> so image 12 and 13
[09:10] <pitti> didrocks: I mean, which test does now fail which didn't before?
[09:10] <didrocks> well, tests are impacted because indicator-network is taking > 63% of CPU
[09:10] <didrocks> so a lot of AP fails
[09:11] <didrocks> the system isn't idling
[09:11] <pitti> didrocks: do we run all autopilot tests at the same time now, i. e. does the recent addition of ofono-phonesim-autostart to the dialer-app/messaging-app tests now cause all the other autopilot tests to run with that as well?
[09:11] <pitti> didrocks: ah, we don't run the AP tests in separate runs, but all in one session?
[09:11] <didrocks> pitti: yeah, there is one boot
[09:11] <didrocks> and running all AP tests for this app
[09:11] <didrocks> pitti: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/13:20131105.1:20131031.1/4910/ubuntu-rssreader-app-autopilot/
[09:11] <pitti> didrocks: that sounds a lot like that D-BUS spinning has been there all the time, it just didn't get exposed until now because ofonod wasn't restarted
[09:11] <didrocks> for instance, you can see 3 AP failing
[09:12] <didrocks> pitti: look at multiple top snapshot at boot: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-ubuntu-rssreader-app-autopilot/16/artifact/clientlogs/top_before.log/*view*/
[09:12] <didrocks> 2197 phablet 20 0 253920 220080 3796 S 70.8 11.5 3:27.03 /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service
[09:12] <didrocks> (last run, 5 minutes after the phone booted up)
[09:12] <pitti> didrocks: I need some ~ 10 more minutes to finish fixing the flood of autopkgtest failures, then I can go back to this
[09:12] <didrocks> pitti: \o/ thanks a lot :)
[09:13] <didrocks> pitti: the additiona of ofono-phonesim-autostart to some tests can explain that
[09:13] <pitti> yes, as these restart ofono
[09:13] <pitti> which probably is the thing that breaks the network-indicator
[09:13] <didrocks> but once dialer-app tests are over
[09:13] <didrocks> we reboot the device
[09:13] <didrocks> wait… doing nothing
[09:13] <didrocks> for 5 minutes
[09:13] <didrocks> and then start rssreader tests
[09:13] <pitti> yes, but ofono-phonesim-autostart is still installed I guess
[09:13] <didrocks> will your mock influence?
[09:14] <didrocks> right
[09:14] <pitti> it's not a mock
[09:14] <pitti> it's an actual ofono driver
[09:14] <didrocks> ah ok ;)
[09:14] <didrocks> and so… it restarts ofono at each boot
[09:14] <pitti> so after boot, ofono will still restart, possibly after indicator-network
[09:14] <didrocks> so, depending in which order we do the tests
[09:15] <didrocks> as soon as we start one depending on ofono-phonesim-autostart and we install it, all the following tests are screwed
[09:15] <didrocks> at least it *starts* to make sense to me
[09:15]  * didrocks was soooo puzzled yesterday
[09:15] <didrocks> we tried to reflash, only rerun some tests…
[09:15] <pitti> I didn't see this kind of failure in the MPs
[09:15] <didrocks> something all went fine and suddenly, 100% strike
[09:16] <pitti> and trust me, mako/maguro ran these tests dozens of  times :)
[09:16] <pitti> but that was all in isolation, i. e. just the dialer or just the messaging tests
[09:16] <didrocks> pitti: yeah, it's weird you didn't get it in the upstream merger
[09:16] <didrocks> right
[09:16] <pitti> so those didn't exhibit the indicator going crazy
[09:16] <pitti> didrocks: well, possibly I did (even locally), but I didn't check top
[09:17] <pitti> didrocks: it's perfectly reproducible on my phone, too
[09:17] <didrocks> pitti: let me try to install it and confirm ;)
[09:17]  * didrocks hugs pitti. So happy to have a start of explanation
[09:17] <pitti> didrocks: install ofono-phonesim and xvfb, run "sudo start with-ofono-phonesim", wait a few secs
[09:17] <didrocks> was really depressing yesterday
[09:17]  * pitti hugs you back
[09:18] <pitti> didrocks: but yes, these tests also expose lots of Mir and other crashes :)
[09:18] <didrocks> pitti: nice stress test! ;)
[09:18] <didrocks> ok, I'll let you go on the autopkgtests, just ping me if you need access to anything
[09:18] <Laney> morning
[09:18] <pitti> (which is why it took me so long to land them in the first place -- Mir crashes caused the MP to get rejected)
[09:18] <didrocks> argh "fun" :)
[09:18] <pitti> didrocks: nope, can debug on my device
[09:19] <didrocks> pitti: ok, just keep us in touch. I think there is no real value that we run the tests before you get a fix
[09:19] <pitti> didrocks: just uploaded systemd, postponing gvfs autopkgtest, other tests are green again, so looking now
[09:19] <didrocks> \o/
[09:20] <seb128> good morning desktopers
[09:20] <didrocks> hey Laney, seb128
[09:20] <seb128> hey Laney pitti didrocks
[09:20] <pitti> bonjour seb128
[09:22] <pitti> didrocks: actually, much simpler than that
[09:22] <pitti> didrocks: "sudo stop ofono; sudo start ofono", that makes it go crazy
[09:22] <pitti> didrocks: which is actually a nice test, as it very much does need to cope with htat
[09:22] <pitti> didrocks: so, nothing to do with my 13117 unshare -m tricks or so :)
[09:22] <didrocks> pitti: confirmed!
[09:23] <pitti> didrocks: want me to file a bug, or is there one already?
[09:23] <didrocks> pitti: I don't think there is any
[09:23] <seb128> didrocks, did you manage to resolve the tests issue yesterday?
[09:23] <didrocks> pitti: hum, after a reboot, I can't get the indicator going crazy
[09:24] <didrocks> seb128: we are discussing about it, there is a lead already
[09:24] <seb128> didrocks, so it's not ido at the end?
[09:24] <didrocks> seb128: can you try "sudo stop ofono; sudo start ofono"
[09:24] <seb128> didrocks, on my desktop or on the device?
[09:24] <didrocks> seb128: device
[09:24] <seb128> sure, give me a min
[09:25] <didrocks> pitti: grrrr, it's not that easy, worked the first time, but now, can't retrigger it. Is it reliable for you?
[09:26] <seb128> didrocks, that seems to be fine ... but my device is not uptodate ... /me updates
[09:27]  * pitti files bug 1248880
[09:27] <ubot2> Launchpad bug 1248880 in indicator-network (Ubuntu) "spends lots of time spinning on D-BUS when ofono restarts" [Undecided,New] https://launchpad.net/bugs/1248880
[09:27] <pitti> didrocks: fairly, yes
[09:28] <pitti> didrocks: I'll add some extra information with d-bus debugging, hold on
[09:29] <didrocks> pitti: tried to reboot twice, can't reproduce :/
[09:31] <pitti> hm, I can reproduce it every time
[09:31] <didrocks> pitti: do you have ofono-phonesim installed?
[09:31] <pitti> didrocks: but sometimes it only lasts some 10 seconds until it reconnects, sometimes 3 minutes
[09:31] <pitti> didrocks: yes, but I didn't run it (and I don't have -autostart installed)
[09:32] <didrocks> still no luck :/
[09:32] <seb128> pitti, do you have a sim in the device? does that make a difference?
[09:32] <pitti> seb128: I do, and I don't know
[09:32] <seb128> didrocks, do you have one?
[09:33] <pitti> $ /usr/share/ofono/scripts/list-modems
[09:33] <pitti> [ /ril_0 ]
[09:33] <pitti>     Features = net sms gprs sim
[09:33] <pitti> without a SIM, it could indeed make a difference
[09:33] <pitti> that's perhaps why you see it better with phonesim
[09:33] <pitti> as that always exports a device
[09:35] <pitti> didrocks: updated the description accordingly
[09:36] <pitti> I now have a case where it has spun for > 1 minute already
[09:36] <didrocks> pitti: confirmed with popey
[09:36] <pitti> it seems it's rolling dice and has an 1% chance of reconnecting or so
[09:36] <didrocks> a SIM is needed
[09:36] <pitti> didrocks: or phonesim :)
[09:36] <pitti> didrocks: I updated the description to show how to reproduce without a SIM
[09:39] <didrocks> pitti: ah, will try after that meeting, thanks!
[09:43] <pitti> didrocks: also posted a link to the g_bus_watch_name() API docs which I suggest using
[09:44] <mfisch> seb128: that dbus api for adding launcher icons works great, but in some circumstances the tooltip says "waiting to install" which is odd
[09:45] <seb128> mfisch, seems like an unity bug, maybe check with bregma/Trevinho
[09:45] <mfisch> seb128: yeah I found an old one in LP that I'm looking at
[09:45] <pitti> didrocks: should I do anythign else with this bug? assign it to someone, etc?
[09:48] <didrocks> pitti: no, I'll hunt for people :)
[09:48] <didrocks> pitti: back from the meeting, let me try installing the various pieces
[09:49] <didrocks> pitti: confirmed that with-ofono-phonesim, the indicator goes crazy
[09:49] <didrocks> thanks a lot pitti!
[09:49] <didrocks> :)
[09:50]  * didrocks targets a victim now :)
[09:50]  * seb128 is happy to be off didrocks' enemy list
[09:50] <didrocks> seb128: until next time! :-)
[09:50]  * seb128 is also happy that didrocks let him land the ido segfault fix yesterday
[09:50] <seb128> didrocks, yeah ;-)
[09:50] <didrocks> seb128: in fact, it's why it was so puzzling
[09:51] <didrocks> seb128: depending on the test order
[09:51] <didrocks> you install that package earlier or later
[09:51] <didrocks> and then, the package stays installed
[09:51] <didrocks> when you run other tests
[09:51] <didrocks> that's why it was a "wth"
[09:51] <seb128> right, that's making for fun debugging
[09:51] <didrocks> and we didn't find any culpurit in the diff list
[09:51] <didrocks> right
[09:51] <pitti> seb128, didrocks: ido> oh yes, so am I, thanks for the fast fix!
[09:51] <pitti> this was so annoying
[09:52] <didrocks> pitti: well, thanks seb128 to fight for it :p
[09:52] <seb128> pitti, thanks to larsu ;-)
[09:52]  * seb128 hugs didrocks
[09:52]  * pitti donne une accolade à larsu
[09:52]  * didrocks hugs seb128
[09:52]  * pitti hugs seb128 and didrocks
[09:52] <seb128> group hug ;-)
[09:52]  * didrocks rehugs pitti
[09:54] <larsu> :)
[09:55] <pitti> didrocks: quick, assign larsu to the network indicator issue, too! he's good with gdbus!
[09:55]  * pitti runs
[09:56] <didrocks> larsu: I think you are the perfect target (the first to answer on IRC though)
[09:56] <didrocks> larsu: seriously, interested in a somewhat-really-critical indicator-network-gdbus issue? ;)
[09:56] <didrocks> it's a nice story, with a lot of praise for fixing it :)
[09:57] <larsu> erm...
[09:57] <larsu> no?!
[09:57]  * larsu is afraid
[09:57] <didrocks> larsu: bug #1248880, do you have any idea on how to debug it?
[09:57] <ubot2> Launchpad bug 1248880 in indicator-network (Ubuntu) "spends lots of time spinning on D-BUS when ofono restarts" [Critical,New] https://launchpad.net/bugs/1248880
[10:02] <larsu> (a) I always want pitti-level bug reports from now on
[10:03] <larsu> (b) this looks really interesting :)
[10:03]  * larsu goes for tea and has a more dtailed look later
[10:03] <seb128> larsu, would you describe pitti's bugs the equivalent of mpt bugs, just applied to technical issues? ;-)
[10:03] <didrocks> oh no, we spoiled larsu with high quality bug report :)
[10:03] <didrocks> seb128: quick, let's edit it :)
[10:05] <larsu> seb128: exactly
[10:05] <pitti> * description changed to: *
[10:05] <pitti> Itz broken! fix it!
[10:05] <larsu> haha
[10:05] <didrocks> ;)
[10:06]  * pitti removes reproducer, analysis, and pointer to "you should use this" too, way too little fun otherwise!
[10:06]  * larsu wonders how ServiceUnknown is send sometimes but then the service gets started sometimes
[10:07] <pitti> larsu: it spins on ServiceUnknown for 5 to 500 seconds and eventually seems to hit the sweet spot and reconnect
[10:08] <pitti> or these are just the 10 gazillion queued requests that it sends up in a tight loop
[10:08] <pitti> g_bus_watch_name()!!
[10:08] <larsu> ya, that sounds more like it
[10:08] <larsu> ted is known for "oh, didn't work, let's try again immediately"
[10:17] <larsu> so... indicator-network doesn't even build for me :-(
[10:21] <seb128> larsu, wrong vala version?
[10:21] <larsu> argh, I guess I need to be on trusty to get vala 0.22?
[10:22] <seb128> larsu, no
[10:22] <larsu> seb128: yes, they've just updated it in r312
[10:22] <larsu> _without_ bumping the vala dep
[10:22]  * larsu shakes fist at kenvandine!
[10:22] <seb128> larsu, install valac-0.22
[10:22] <seb128> larsu, then "update-alternatives --config valac"
[10:23] <larsu> no such package
[10:23] <seb128> larsu, that let you pick the default one
[10:23] <seb128> of course
[10:23] <seb128> larsu, https://launchpad.net/ubuntu/+source/vala-0.22/0.22.0-2/+build/5157282
[10:23] <seb128> get the debs from there and dpkg -i
[10:24] <seb128> they should install fine on saucy
[10:24] <larsu> makes sense, thanks
[10:24] <seb128> yw
[10:24] <larsu> I guess I should jjust update this week
[10:30] <larsu> also needs valac-0.22-vapi
[10:30] <larsu> *sigh*, vala
[10:32] <seb128> larsu, sorry
[10:32] <seb128> larsu:
[10:32] <seb128> https://launchpad.net/ubuntu/+source/vala-0.22/0.22.0-2/+build/5157285
[10:33] <seb128> larsu, ^ that has the arch all binaries
[10:33] <larsu> thanks :)
[10:33] <larsu> got it to build now
[10:33] <Laney> I'd have just added trusty to sources.list and installed it from there :P
[10:33] <seb128> I was going to suggest that next
[10:33] <Laney> then probably forgotten to remove it and accidently upgraded to trusty
[10:33]  * Laney did that at client sprint
[10:33] <larsu> haha
[10:33] <seb128> but that's usually more work that wget & dpkg in a deb
[10:33] <larsu> Laney: is it stable enough to run?
[10:34] <Laney> yeah
[10:34] <Laney> and you get click packages in the dash apparently
[10:34] <Laney> MADNESS
[10:34] <seb128> larsu, yeah, there was an annoying ido segfault but I got told it's fixed :p
[10:34]  * larsu whistles
[10:34] <Laney> infact it seems to prefer them over regular applications
[10:35] <Laney> actually wtf
[10:36] <Laney> I guess "Browser" is webbrowser-app which we recently seeded
[10:36] <larsu> `sudo restart ofono` gives me "restart: Unknown instance:"
[10:36] <pitti> oha, not running?
[10:36] <pitti> larsu: try stop ofono; start ofono?
[10:37] <Laney> I'm only getting new apps on the home lens now before typing anything
[10:37] <larsu> pitti: stopping gives me the same error
[10:37]  * larsu kills it
[10:37] <larsu> ah, that fixes it
[10:37] <larsu> apparently upstart didn't know ofono was running
[10:38] <seb128> I guess the running one was not upstart managed
[10:38] <seb128> upstart doesn't take ownership of random processes you run manually
[10:38] <larsu> that makes sense, but I wonder how that could have happened
[10:38] <seb128> is ofono dbus activated?
[10:38] <larsu> oh! Maybe it wasn't running before and indicator-network dbus-activated it
[10:38] <seb128> right
[10:38] <larsu> and upstart doesn't know about this
[10:38] <larsu> my favorite problem! :P
[10:39] <seb128> I was going to say :p
[10:40] <larsu> pitti: I must dissapoint you. I can't reproduce :-/
[10:40] <pitti> larsu: do you have a SIM card?
[10:41] <pitti> *cough* systemd! *cough*
[10:41] <pitti> sorry
[10:41] <pitti> larsu: if you don't have a SIM card, use the second reproducer in the description, which will fake one for yuou
[10:42] <larsu> pitti: yeah sorry I just read your description in full :)
[10:42] <Laney> jibel: did / can you forward your new autopkgtests to debian?
[10:42] <larsu> oh yeah here we go
[10:42] <pitti> Laney: oh, for what package?
[10:43] <Laney> paramiko python-jsonschema
[10:43] <Laney> are the two I see atm
[10:43] <Laney> maybe more
[10:43] <pitti> paramiko is collab-maint, happy to commit for you, jibel
[10:43] <pitti> jsonschema is "openstack", that needs a bug
[10:44] <Laney> oh, is that allowed?
[10:44] <pitti> well, it's called "collab-maint"..
[10:44] <pitti> I've been doing it many times, didn't get a complaint
[10:44] <Laney> Interesting, I wouldn't complain myself
[10:45] <larsu> hm, ofono doesn't even ship with a .service file
[10:45] <larsu> StartServiceByName is just plain wrong
[10:45] <pitti> and Debian's release team also annoucned that they want to enable autopkgtests, and provide quicker testing propagations for packages which have them, and encourage people to add them
[10:45] <pitti> larsu: yeah, it's only handled by upstart ATM
[10:46] <larsu> okay I'll remove that then
[10:46] <pitti> larsu: hence, watching for dbus names to STFU while it's not running
[10:46] <Laney> there's also https://bugs.launchpad.net/ubuntu/+source/python-dateutil/+bug/1247877 https://code.launchpad.net/~jibel/ubuntu/trusty/python-mock/lp1248066_enable_autopkgtest/+merge/193888 https://code.launchpad.net/~jibel/ubuntu/trusty/python-imaging/lp1248743_enable_autopkgtest/+merge/194249
[10:46] <ubot2> Launchpad bug 1247877 in python-dateutil (Ubuntu) "Enable autopkgtest" [Medium,Triaged]
[10:46] <Laney> -mock is DPMT, others are maintained by people (last one is doko)
[10:47] <didrocks> just a long time I haven't done propaganda, but Dart 1.0 is coming! :)
[11:23] <jibel> Laney, sure thing, will do.
[11:24] <Laney> rocking
[11:24] <jibel> Laney, is it preferable to submit to debian directly then request a sync or propose a patch in both distro?
[11:24] <Laney> jibel: as you wish
[11:25] <Laney> It might take a while for your patches to be uploaded
[11:29] <pitti> Laney, jibel: if I commit stuff to collab-maint for an otherwise ubuntu-unmodified package, I usually do a -2git1 upload to ubuntu; that keeps autosync, but immediately gets us the change
[11:29] <Laney> works for me
[11:35] <larsu> pitti, didrocks: I've put up a branch that should fix your issue for now. Please let me know if it works.
[11:35] <larsu> we'd need a lot more substantial fixes, but I don't feel comfortable making them right now
[11:35] <larsu> as I'm not the maintainer of that project and have never read the code before
[11:35] <didrocks> larsu: \o/
[11:36] <didrocks> larsu: do you have an url?
[11:36] <pitti> larsu: I don't see a branch on the bug?
[11:36] <larsu> pitti: ya I was waiting for the push to complete while typing
[11:36] <larsu> didrocks: https://code.launchpad.net/~larsu/indicator-network/dont-activate-ofono
[11:36] <larsu> it's the simplest-possible solution for now
[11:37] <larsu> Wellark promised to look into it more deeply
[11:37] <didrocks> larsu: do you think Wellark review that branch as well?
[11:37] <pitti> larsu: oh, that won't retry in a tight loop?
[11:37] <didrocks> to get it landed, image respin and so on?
[11:38] <pitti> larsu: or it will, and just make it less CPU intense?
[11:38] <larsu> pitti: it won't
[11:38] <larsu> well, it doesn't for me
[11:38] <pitti> nice
[11:38]  * pitti hugs larsu
[11:38] <seb128> larsu, yes, please, don't spend days fixing their codebase, just let that to them
[11:38] <larsu> let's see and wait if this actually works :)
[11:38] <larsu> seb128: ;)
[11:39] <pitti> in any case, this patch is obviously correct as we don't have a .service; as for whether it is sufficient, I don't know
[11:39] <larsu> didrocks: no need, this patch is definitely needed
[11:39] <didrocks> nice work larsu!
[11:39] <pitti> eventually it should still use g_bus_watch_name and connect/disconnect asynchronously without polling, but I guess that's for someone else to do :)
[11:40] <larsu> pitti: yes. I was starting out doing that, but it was getting complicated quickly
[11:41] <larsu> mr is here: https://code.launchpad.net/~larsu/indicator-network/dont-activate-ofono/+merge/194323
[11:47] <GunnarHj> Laney: Saw your question about seeding of ttf-wqy-microhei. Guess it depends on why it's seeded. As you know, we have pkg_depends in any case.
[11:47] <Laney> To have a chance of CJK working by default I guess
[11:48] <GunnarHj> Laney: How does pkg_depends not make CJK work by default?
[11:50] <Laney> You have to run l-s, right?
[11:50] <Laney> It's for everyone to have a CJK font all the time
[11:52] <GunnarHj> Laney: l-s is used for installing languages anyway. Not sure off-hand is you select a CJK language at installation, but have a feeling that the installer makes use of pgk_depends as well.
[11:53] <Laney> I wouldn't get them on my en_GB installation though, even if it did
[11:54] <GunnarHj> Laney: Aha, you mean when e.g. displaying a Chinese web page?
[11:54] <Laney> Something like that
[11:55] <Laney> Guessing as to why it's installed by default, it's obviously from way before my time
[11:56] <GunnarHj> Laney: Possibly we should then start seeding fonts-droid instead. But I suppose we'd better let some time go to evaluate fonts-droid before messing with the seed. happyaron indicated yesterday that there might be a problem with libreoffice...
[11:57] <Laney> And it's not in main, see my comment on the bug
[11:57] <Laney> Not sure what that means for pkg_depends.
[11:57] <Laney> It's probably alright, I bet other stuff there is in universe
[11:58] <Laney> Still means that Chinese users will have microhei installed, which might be bad for them, not sure
[11:58] <Laney> You can probably work with happyaron on this stuff now. Wasn't them most enjoyable project for me. :P
[11:58] <Laney> s/them/the/
[11:58] <GunnarHj> Laney: fonts-android is in main, and that source package carries fonts-droid nowadays.
[11:59] <Laney> GunnarHj: run this: rmadison -S -s trusty fonts-android
[12:02] <GunnarHj> Laney: Run it. :( Then, what does main mean at https://launchpad.net/ubuntu/+source/fonts-android? That it's in main in Debian?
[12:03] <Laney> Yeah
[12:03] <Laney> Look at the table below
[12:03] <Laney> Probably not so hard to get it MIRed, mind you
[12:04] <Laney> It's on touch and there's a plan to get all of that stuff in main eventually ...
[12:04] <GunnarHj> Laney: See it; my mistake.
[12:04] <Laney> So it'll happen at some point, but you could help make it happen sooner if you care to
[12:05] <GunnarHj> Laney: No, it shouldn't be hard to get it MIRed, especially since fonts-droid is pulled when you install u-s-s. ;-)
[12:05] <Laney> yeah, that's the touch thing
[12:05] <Laney> it builds from universe currently
[12:05] <GunnarHj> Laney: Will file a MIR application.
[12:05] <Laney> nice, thanks
[12:06] <happyaron> " Sorry, there was a problem connecting to the Launchpad server. "
[12:06] <Laney> f5 f5 f5
[12:12] <seb128> Sweetshark, can you tell me if my comment on https://bugs.launchpad.net/ubuntu/raring/+source/libreoffice/+bug/1204449 is correct (e.g no sponsoring needed, that got uploaded just without listing the bug in the changelog)?
[12:12] <ubot2> Launchpad bug 1204449 in libreoffice (Ubuntu Raring) "[SRU] LibreOffice 4.0.4 for Ubuntu 13.04 (raring)" [Low,Fix committed]
[12:13] <didrocks> larsu: confirmed to work for me! nice ;)
[12:14] <didrocks> thanks again
[12:15] <larsu> didrocks: pleasure. Wellark is on it to fix this more robustly
[12:15] <seb128> once again larsu is saving the day
[12:15] <didrocks> yep ;)
[12:25] <Sweetshark> seb128: checking
[12:27] <Sweetshark> seb128: yes, comment is correct. Seems to be still in proposed though, so not setting to 'fix released' ...
[12:29] <seb128> Sweetshark, right
[12:29] <seb128> speaking of SRU verification
[12:30] <seb128> Sweetshark, could you verify https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1207057? or should we ping jmp&co about it?
[12:30] <ubot2> Launchpad bug 1207057 in libreoffice (Ubuntu Precise) "presentation causes system to hang" [Undecided,Fix committed]
[12:31] <seb128> Sweetshark, the quantal SRU is waiting on 3 bugfix verifications as well
[12:32] <Sweetshark> seb128: On my machine that wasnt completely reproducable from the start. I got a delay, no hang. The bugfix reduced the delay.
[12:32] <seb128> Sweetshark, did we have anybody able to reproduce the hang?
[12:43] <seb128> dobey, hey, could you review/sponsor the precise patch for https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/926763 ?
[12:43] <ubot2> Launchpad bug 926763 in software-center (Ubuntu Precise) "Cannot install local packages (.deb files) without network connection (offline)" [Medium,Confirmed]
[12:49] <Sweetshark> seb128: bug 1246583 seems serious, but as per comment 9 seems to be not a LibreOffice issue. Any hints on whom to get involved?
[12:49] <ubot2> Launchpad bug 1246583 in libreoffice (Ubuntu) "All hotkeys of LibreOffice don't work in non-English keyboard layout [ubuntu 13.10]" [Medium,Confirmed] https://launchpad.net/bugs/1246583
[12:49] <seb128> Sweetshark, attente
[13:02] <seb128> hum
[13:02] <seb128> attente, the good news is that this issue is not due to you ;-)
[13:02] <seb128> same problem on f20 (/me just tested in a vm)
[13:02] <seb128> Sweetshark, ^
[13:03] <seb128> so not an appmenu/unity issue
[13:03] <Sweetshark> seb128: urgh.
[13:04] <Sweetshark> "also an issue with KingSoft" sounds like its "somewhere in the stack" not LO itself though ...
[13:04] <seb128> yeah, could be gnome-settings-daemon or gtk2
[13:04] <Sweetshark> time to arm the needle in haystack detector ...
[13:05] <seb128> Sweetshark, https://bugzilla.redhat.com/show_bug.cgi?id=958300
[13:05] <ubot2> bugzilla.redhat.com bug 958300 in libreoffice "Keyboard shortcuts doesn't work in Gnome if a non-US keyboard layout is active" [Unspecified,New]
[13:05] <seb128> no useful info there though
[13:08] <Sweetshark> seb128: if there are any quantal LibreOffice SRUs, we should just drop them unless there is a customer on them. IIRC quantal is EOL in two month and everyone caring about those fixes has switched to the LO ppa a long time ago anyway.
[13:09] <Sweetshark> seb128: copy paste work on a german layout here ...
[13:09] <seb128> Sweetshark, well the current one is in the queue, we could as well get it moved to updates
[13:10] <seb128> Sweetshark, german is an ascii layout, C,V are on the same position than the english layout
[13:10] <Laney> quantal has until april
[13:14] <Sweetshark> Laney: ah, right. It was the last 'longer' one.
[13:15] <Sweetshark> seb128: iteresting *cough*
[13:16] <Sweetshark> seb128: I just added Bengali -- an yep: Copypaste doesnt work there. Then I tried to switch to a 'Guest session' ....
[13:16] <seb128> Sweetshark, I tried with Russian
[13:16] <seb128> Sweetshark, I can confirm it doesn't work
[13:17] <Sweetshark> ... which repeatedly popped up 'IBus-Update' message on an otherwise black screen with a classic 1990 X11 cursor. I only got out of that with ctrl-alt-f2 and killing the second lightdm process.
[13:18] <seb128> Sweetshark, weird
[13:20] <seb128> Sweetshark, https://bugs.freedesktop.org/show_bug.cgi?id=55585
[13:20] <ubot2> Freedesktop bug 55585 in UI "Should check all XKB group indexes when matching key events for accelerators and mnemonics" [Normal,Needinfo]
[13:23] <Sweetshark> seb128: so a XFCE Guest session with Bengali does copy-paste as expected, so this is somewhere in the gnome3 stack ...
[13:24] <seb128> Sweetshark, right, see the libreoffice bug report
[13:24] <seb128> Sweetshark, it describes the issue
[13:42] <Sweetshark> seb128: yep
[13:42] <seb128> Sweetshark, upstream GNOME doesn't plan to change their stuff, their position is that libreoffice needs to be fixed
[13:43] <seb128> Sweetshark, I'm still pondering if we should rollback to the old way to handle keyboards or if we should try to push thing forward before the LTS
[13:43] <attente> seb128, yeah, i'm not sure what in the gnome stack could have caused that issue
[13:44] <seb128> attente, not your fault in any case
[13:44] <seb128> attente, good morning btw ;-)
[13:44] <seb128> attente, the first comment on https://bugs.freedesktop.org/show_bug.cgi?id=55585 describes it well
[13:44] <ubot2> Freedesktop bug 55585 in UI "Should check all XKB group indexes when matching key events for accelerators and mnemonics" [Normal,Resolved: duplicate]
[13:46] <attente> Sweetshark, i wonder how it was working in libreoffice before, do you know?
[13:47] <attente> seb128, good afternoon :)
[13:50] <seb128> attente, read the first comment on that bug
[13:50] <seb128> attente, in the old GNOME world xkb groups were handled differently
[13:51] <attente> oh... right
[14:11] <dobey> seb128: i'll try to look at it today
[14:12] <seb128> dobey, thanks
[14:29] <Laney> seb128: do you think we need a session on gnome plans to assign work items or do people generally know what to do?
[14:29] <Laney> (or did you make one already?)
[14:30] <seb128> Laney, I'm not sure there is much to discuss
[14:30] <Laney> turning it into work items
[14:31] <seb128> we would need everybody that is going to do work to join at the same time
[14:32] <seb128> my bet is that e.g robert_ancell is not going to wake up at 4am for that
[14:32] <seb128> we should have a blueprint in any case
[14:32] <seb128> I'm just not sure it's worth a session
[14:33] <Laney> okay, if it is going to be assigned another way
[14:36] <seb128> Laney, I would suggest "create a blueprint -> dump a list of everything we know about that needs done in it -> chase people to grab workitems -> get me to assign the remaining one"
[14:36] <seb128> or something along those lines
[14:36] <seb128> Laney, though there is not so much desktop work, stuff like "bring back menus" are already tracked through bugs
[14:39] <Laney> is that enough?
[14:39] <Laney> if so, fine, maybe we shouldn't bother
[14:40] <seb128> do you have example of work you want lined up?
[14:40] <seb128> it feels we already discussed what to update and strategy etc
[14:40] <seb128> cf my email to the desktop list
[14:40] <Laney> I think we know what the plan is, but aren't tracking the work to achieve it
[14:41] <seb128> it feels like a session would turn up into a "not a lot to discuss" or in "everybody lists their pet bugs"
[14:42] <seb128> hum, right
[14:47] <seb128> Laney, hum, assuming that times are UTC ones, it means sessions are from 2am to 8am for .au guys
[14:47] <seb128> Laney, I need to check with robert_ancell if he can/want to me online for a desktop workitems session
[14:47] <Laney> Can just fill in a BP outside of UDS
[14:48] <seb128> right
[14:54] <seb128> chrisccoulson, hey, do you still look at firefox issues? ;-)
[14:54] <seb128> chrisccoulson, do you know if https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1200272 is being worked/if it's an hunspell or firefox issue?
[14:54] <ubot2> Launchpad bug 1200272 in firefox (Ubuntu) "firefox crashed with SIGSEGV" [Medium,Confirmed]
[15:05] <seb128> jdstrand, mdeslaur, there are some apparmor changes in the sponsoring queue, do you guys plan to handle those? (some are debdiffs from Tyler)
[15:06] <chrisccoulson> seb128, i haven't looked at a firefox issue for ages ;)
[15:06] <mdeslaur> seb128: yeah, we'll handle those, thanks
[15:06] <seb128> mdeslaur, should I unsubscribe sponsors so others don't spend time reviewing?
[15:07] <mdeslaur> seb128: sure
[15:07] <mdeslaur> seb128: could you give me the bug # so we don't drop them though?
[15:07] <seb128> mdeslaur, sure
[15:07] <seb128> mdeslaur, https://code.launchpad.net/~cmiller/ubuntu/trusty/apparmor/chromium-new-sandbox-name/+merge/193657 is one
[15:08] <seb128> mdeslaur, seems like we should get that one in, the current chromium already has the rename ... does it mean the apparmor profile is unactive?
[15:09] <seb128> mdeslaur, bug #1231778 is on the with the diffs from Tyler
[15:09] <ubot2> Launchpad bug 1231778 in AppArmor "wifi not working on Saucy Salamander" [Medium,In progress] https://launchpad.net/bugs/1231778
[15:10] <Laney> bah
[15:10] <Laney> wayland testsuite fails
[15:10] <Laney> tjaalton: you like wayland? fancy looking at the updates? ;-)
[15:13] <seb128> timchen119, hey, thanks for the notify-osd work!
[15:14] <mdeslaur> seb128: thanks
[15:15] <seb128> mdeslaur, thank you for looking at those ;-)
[15:17] <sil2100> kenvandine: ping :)
[15:18] <kenvandine> sil2100, pong
[15:18] <tjaalton> Laney: alrighty
[15:18] <Laney> tjaalton: cool (blocks new gtk)
[15:18] <Laney> thanks
[15:23] <tjaalton> Laney: I guess wayland could be synced
[15:24] <tjaalton> pushed the Conflicts/Replaces diff to debian earlier, 1.3.0-1 has it
[15:24] <Laney> tjaalton: oh, in cursor0 too?
[15:25] <seb128> happyaron, hey
[15:25] <tjaalton> Laney: yup
[15:49] <Laney> tjaalton: whatever you think is right
[15:52] <tjaalton> Laney: synced
[15:53] <Laney> will need weston too to migrate to trusty
[15:53] <Laney> IIRC
[15:54] <tjaalton> weston needs cairo-gl, which then explodes on nvidia
[15:54] <tjaalton> probably could just disable building weston-screensaver instead
[15:55] <tjaalton> but wayland should be fine without weston
[15:56] <Laney> libwayland-server0 Breaks: weston (<< 1.2.0)
[15:57] <tjaalton> ah yes
[16:00] <tjaalton> stupid unity doesn't know meld is open
[16:04] <tjaalton> doesn't look like it's easy to disable wscreensaver, it's everywhere
[16:04] <seb128> drop weston from the archive?
[16:04] <tjaalton> until cairo-gl works, maybe
[16:05] <Laney> how come debian can enable it?
[16:07] <dpm> tedg, there's a discussion going on on #ubuntu-app-devel on how upstart could deal with fat packages containing binaries for different architectures. If you're around, would you mind joining in? thanks!
[16:07] <tjaalton> Laney: we've disabled cairo-gl in cairo
[16:08] <Laney> tjaalton: remoing/changing the --with-cairo= line isn't enough?
[16:08] <tjaalton> because the nvidia blob doesn't like it
[16:08] <tjaalton> oh..
[16:08] <tjaalton> I'll try
[16:08] <tjaalton> was grepping the wrong thing
[16:11] <Laney> how can you tell if it's bad?
[16:11] <Laney> just try it on nvidia?
[16:13] <tjaalton> yes, every gl client will use a lot of extra memory
[16:13] <Laney> seems to build without that and removing -screensaver from .install
[16:13] <Laney> go for it if that's good enough for you
[16:13] <happyaron> seb128: hi
[16:14] <seb128> happyaron, hey
[16:14] <happyaron> seb128: what's up?
[16:14] <tjaalton> Laney: yeah good enough for me
[16:14] <seb128> happyaron, I'm trying to figure what to do with the keyboard situation for the LTS
[16:14] <Laney> tjaalton: right, feel free to upload then
[16:14] <Laney> should unblock gtk
[16:15] <seb128> happyaron, do you know how happy were IMs users with the old way of doing things, e.g having layouts and IMs being separate concepts rather than grouped like GNOME did (and we us now)?
[16:16] <happyaron> seb128: actually we don't like the current way in any extent, and very few people like what Windows8 do (super+space)
[16:16] <seb128> happyaron, I'm trying to decide on whetever we should push forward or rollback for the LTS and decide the old way is the best we can do with xorg
[16:16] <seb128> happyaron, then have a better go at solving the issue with unity8/mir
[16:17] <seb128> happyaron, how often do you guys change layouts? e.g in the old world, did you interact with the layouts or only directly with ibus/fcitx?
[16:18] <happyaron> seb128: only ibus/fcitx, and it handles layout
[16:18] <seb128> happyaron, I'm not even sure at this point what the GNOME guys are trying to solve with the new design...
[16:18] <seb128> if the old ibus way was handling layouts as well
[16:19] <happyaron> seb128: ibus's xkb integration isn't good, and they wish to have the feature at that time, so they come up with current solution
[16:19] <happyaron> ibus-xkbc is almost abandoned upstream, and there are still compatibility issues with pure xkb settings
[16:22] <seb128> happyaron, what about fcitx?
[16:22] <happyaron> fcitx has the support in the main upstream project, and has some compatibility issues too.
[16:22] <seb128> happyaron, but do you need xkb integration? or do you just use e.g qwerty-english or qwerty+pinyin
[16:22] <happyaron> no, I don't.
[16:22] <seb128> I mean typically
[16:23] <seb128> so those are basically 2 different usecases
[16:23] <seb128> layouts are for people who e.g type russian or english and change between those
[16:23] <happyaron> I think few people need it, and when they really need it they could already have their own xkb configs.
[16:23] <seb128> IMs are for people who use 1 layout but need to change the way composition works?
[16:24] <happyaron> yes
[16:25] <happyaron> for example I need to input Chinese characters, but I have many ways inputing it, use PinYin or Wubi, I need switch between them as I wish
[16:26] <happyaron> and I also need to switch to English keyboard at times to input alphabets.
[16:27] <seb128> happyaron, well, you are always on qwerty in all those cases though?
[16:27] <happyaron> yes
[16:27] <seb128> happyaron, e.g typically you would only need to super-space with ibus
[16:27] <seb128> ok
[16:27] <seb128> happyaron, so it seems you +1 for the old way, e.g reverting would be an issue for you
[16:27] <seb128> wouldn't*
[16:27] <seb128> (sorry)
[16:27] <happyaron> typically ctrl+space, super-space is wired...
[16:28] <seb128> yeah, I just mean $favorite_keys
[16:28] <happyaron> :)
[16:28] <seb128> happyaron, great
[16:28] <happyaron> thanks
[16:28] <seb128> I'm going to start some list discussions on reverting or going forward and put a vUDS session about it
[16:28] <happyaron> great
[17:23] <colonelqubit> tkamppeter_: Bjoern (Sweeetshark) mentioned that you might be able to help LibreOffice triage a couple of printing bugs
[17:25] <colonelqubit> (We don't have access to particular printing hardware)
[17:27]  * didrocks waves good evening, see you on Tuesday!
[17:49] <seb128> sil2100, cyphermox: can we get a 13.10 SRU for indicator-application (there is 1 commit in there and it fixes a frequently reported issued)?
[17:49] <cyphermox> seb128: sure, I'll kick it off now
[17:49] <seb128> cyphermox, thanks
[17:49] <cyphermox> I'm not staying around though, I'm just on IRC by accident :)
[17:50] <seb128> cyphermox, have fun!
[17:59] <cyphermox> seb128: where you editing the bug?
[18:01] <cyphermox> seb128: build is running now, I'll check back on it later to push it to proposed
[18:29] <seb128> cyphermox, no I didn't, sorry was away for exercise, I can do it if you want, testcase is basically "watch if e.u.c reports stop coming"
[18:45] <bschaefer> attente, hey, were you able to get any callbacks from compiz?
[18:46] <attente> bschaefer, still no, but it's down to a modifier checking problem
[18:47] <bschaefer> attente, well hopefully thats good, so compiz is getting the action and everything? Just failing on a modifier not being set?
[18:48] <attente> compiz gets the action, compiz does the grab
[18:48] <attente> when time comes to check for the action which matches the event, it flops
[18:48] <attente> it seems to be dependent on what keybinding i provide too
[18:49] <bschaefer> hmm interesting, i've never actually had to follow that code before...is under one of the trigger* functions?
[18:49] <attente> yeah, i added some fprintfs to PrivateScreen::triggerKeyPressBindings
[18:50] <attente> in some cases like <Shift>F8, it gets a matching keycode, but the modifiers don't match
[18:50] <bschaefer> when you say it seems to be dependent on what keybinding you provide, what do you mean by that i suppose?
[18:51] <attente> in other cases, like <Control>p, it doesn't seem to match keycodes properly
[18:51] <bschaefer> hmm strange
[18:51] <bschaefer> what if you took an already working hot key
[18:51] <bschaefer> and tried use that?
[18:51] <bschaefer> such as Alt+Tab
[18:51] <bschaefer> hmm
[18:52] <bschaefer> attente, so its never returning true here:       if (match && eventManager.triggerPress (action, state, arguments))
[18:52] <bschaefer> ?
[18:53] <bschaefer> attente, also, try again Shift+F8, cause you added in the init state after you tried that
[18:53] <attente> bschaefer, basically match is never even true
[18:53]  * bschaefer looks for how it parses the key bindings
[18:56] <bschaefer> attente, looking at how its parsed in...i think you may be adding the hot key in, incorrectly
[18:57] <bschaefer>     binding.fromString(impl::CreateActionString(key, shortcut, flag));
[18:57] <bschaefer> something like that, is whats done that i see in unityshell.cpp
[18:57] <bschaefer> attente, and looking at your code, you just use: action->keyFromString(accelerator);
[18:58] <bschaefer> my guess is something is not producing the correct tokens for compiz to check
[18:59] <bschaefer> attente, a place to check would be in compiz/src/action.cpp::CompAction::KeyBinding::fromString (const CompString &str)
[19:16] <attente> bschaefer, looking at that function, it seems to be going by '<Modifier><Modifier>x_keysym_name'
[19:18] <bschaefer> attente, hmm well possibly try to use impl::CreateActionString(key, shortcut, flag)
[19:18] <bschaefer> to generate a string then pass it to binding.fromString()
[19:19] <bschaefer> attente, as it seems add that its getting wrong keycodes/keysyms...
[19:20] <attente> bschaefer, for it to make the grabs properly, it must've parsed them correctly, no?
[19:21] <bschaefer> attente, hmm how were you testing if the grabs were set up properly?
[19:21] <bschaefer> attente, and yes that would hmmm
[19:21] <bschaefer> attente, so the keycode from the current event isnt matching up with the keygrab?
[19:22] <attente> PrivateScreen::triggerKeyPressBindings was getting called only after i added the action to the screen
[19:23] <bschaefer> attente, hmm IIRC triggerKeyPressBindings is done on all keypresses...from XNextEvent...
[19:23] <bschaefer> line 846 in event.cpp
[19:25] <bschaefer> but if theres not keygrab set it i don't think the event would even get there hmm
[19:28] <attente> bschaefer, doesn't seem to be the case
[19:29] <attente> i can press most key combinations, and that doesn't get called
[19:29] <bschaefer> yeah, the grab has to be there, so yeah you're right that the grab is being set hmm
[19:30] <attente> so, on line 420 in event.cpp
[19:31] <attente> bindMods is 8
[19:31] <attente> sorry, 0x8
[19:32] <attente> event->state is 0x11
[19:32] <attente> modMask is 0x20000ed
[19:32] <attente> this is for '<Shift>F8'
[19:33] <attente> as far as i can tell, event->state is correct
[19:33] <bschaefer> hmm
[19:33] <bschaefer> attente, well
[19:34] <bschaefer> bindMods wont be equal
[19:34] <bschaefer> attente, what happens when you press say, alt+tab?
[19:34] <bschaefer> what is modMods, bindMods?
[19:34] <bschaefer> or something similar that compiz already has set up
[19:35] <attente> for alt+tab, i get 0x8 0x18 and 0x20000ed respectively, which matches because of the mask
[19:35] <bschaefer> yeah
[19:36] <bschaefer> attente, possibly change a hot key in unity shell plugin in ccsm to but like shift+F7
[19:36] <bschaefer> that way you can get the mod and mask is getting to through there, our it'll fail
[19:36] <bschaefer> and then its not your fault but compizs
[19:37] <bschaefer> but I just set up Shift+F1, and it seems to work hmm
[19:38] <attente> if i try '<Control>n', then it doesn't even seem to match the keycode
[19:39] <attente> ok, i might be being stupid here, let me check something
[19:39] <bschaefer> attente, well i mean change a hotkey in ccsm to that of a similar hot key you are trying to match up (Such as changing Alt+Tab to Shift+F7)
[19:41] <attente> bschaefer, where's the Alt+Tab option?
[19:41] <attente> i can't seem to find it
[19:41] <bschaefer> attente, under ccsm-> Unity Shell Plugin -> Switcher
[19:44] <attente> bschaefer, ok, so
[19:44] <bschaefer> that way you can see what the correct values should be
[19:44] <attente> that worked
[19:44] <attente> i set Shift+F12 for the switcher
[19:44] <attente> the correct mods are the same
[19:44] <bschaefer> really?
[19:44] <attente> 8 18 20000ed
[19:44] <bschaefer> o that 18 part is different though
[19:44] <attente> yeah, so something is clearly wrong on my side
[19:44] <bschaefer> you said
[19:44] <bschaefer>  event->state is 0x11, that should 0x18
[19:44] <attente> the 18 is fine since the 1 gets masked out
[19:45] <bschaefer> so the state is getting set to an incorrect value
[19:45] <attente> right, when ccsm does it, it works
[19:45] <attente> when i try to do it manually, it doesn't
[19:45] <bschaefer> yeah, hmm i wonder where that state gets set
[19:45] <attente> the state is direct from the XEvent
[19:45] <attente> oh..
[19:45] <attente> weird..
[19:45] <attente> because i thought 0x11 was correct
[19:46] <bschaefer> yeah...why is it 0x11 for you?
[19:46] <attente> and 0x8 was wrong
[19:46] <bschaefer> and 0x18 for ccsm?
[19:46] <attente> whoops, sorry
[19:46] <attente> i read the wrong line
[19:46] <attente> Shift+F12 via ccsm is 1 11 20000ed
[19:46] <bschaefer> oo
[19:46] <attente> that makes more sense
[19:46] <bschaefer> yeah
[19:47] <bschaefer> so the bindMods for you is incorrect
[19:47] <attente> yep
[19:47] <attente> i'll see what ccsm is using for the string
[19:47] <bschaefer> take a look at this: action->key ().modifiers ()
[19:48] <bschaefer> print that out for your shift+f8 and ccsms shift+f12
[19:48] <bschaefer> as im  guessing the value of that is whats inconsistent between the 2 cases
[19:56] <attente> bschaefer, sorry i'm taking so long, i'm getting overwhelmed with the debug output
[19:57] <bschaefer> attente, o no worries
[19:57] <bschaefer> attente, compiz is never easy to dig through, same with the x event loop
[19:58] <bschaefer> plus i've never actually dug through this part of compiz, so im just talking a bunch
[19:59] <attente> bschaefer, one thing i can say is that ccsm is not doing it by parsing a CompString
[20:00] <bschaefer> hmm let me take a look at the generated code
[20:00] <attente> oh man. i have no idea what's going on here, lol
[20:00] <bschaefer> haha, yeah neither do i :)
[20:00] <bschaefer> they seem to be:     action.keyFromString ("<Alt>Tab");
[20:00] <bschaefer> those are the default values though
[20:01] <bschaefer> attente, did you set this state:     state = CompAction::StateAutoGrab;?
[20:01] <attente> bschaefer, no, what does it do?
[20:01] <bschaefer> not sure, but all those hotkeys have it being set
[20:01] <bschaefer> they are setting StateAutoGrab | StateInitKey
[20:02] <bschaefer> soo possibly that changes how its being grabbed, which could cause a different bindMod?
[20:10] <attente> action->key ().modifiers () is 0x1 for the ccsm case, 0x10000 for our case
[20:10] <attente> going to see what that StateAutoGrab does now
[20:13] <bschaefer> hmm i wonder why then its getting a different bindMod
[20:14] <attente> yeah, no effect there
[20:15] <bschaefer> attente, well a funny thing to do would be, detect 0x10000, and change it to 0x1
[20:15] <bschaefer> to confirm thats the only problem, and you should (hopefully) get a callback
[20:16] <bschaefer> now i wonder why .modifers is 1 for ccsm and 65536 for our case
[20:17] <bschaefer> 65536 seems like a normal modifier...
[20:17] <attente> funny thing is, if i do an alt+`, the action->key ().modifiers () is also 0x10000
[20:17] <bschaefer> haha, try alt+f8
[20:18] <bschaefer> i wonder if its getting alt?
[20:18] <bschaefer> instead of a shift
[20:18] <attente> oh. that already binds to something
[20:19] <attente> window resizing
[20:19] <bschaefer> but you get the same value?
[20:19] <attente> yes
[20:19] <GunnarHj> attente: Hi!
[20:19] <attente> GunnarHj, hello!
[20:19] <bschaefer> very strange...now why is it turning your <Shift>F8 to <Alt>F8
[20:19] <GunnarHj> attente: Do you think that the suggestion in bug 1248349 can help fix the language list issue in u-s-s?
[20:19] <ubot2> Launchpad bug 1248349 in ubuntu-system-settings (Ubuntu) "[language] Confusing list of display language options" [Low,Triaged] https://launchpad.net/bugs/1248349
[20:21] <attente> bschaefer, can't seem to grab alt+f9, very weird problem indeed
[20:22] <attente> GunnarHj, sorry, taking a look now
[20:23] <attente> GunnarHj, ah
[20:23] <seb128> GunnarHj, didn't Laney said it should already be fixed in trunk?
[20:23] <attente> actually we had this discussion before
[20:23] <Laney> it's different in trunk
[20:23] <Laney> don't know if you'd call it fixed
[20:23] <Laney> pitti and attente discussed how to get the list some weeks ago
[20:24] <seb128> well, we reduced the variants
[20:24] <attente> the problem is u-s-s also uses that Display Languages for setting the formats locale as well
[20:24] <seb128> it was crazy before
[20:24] <seb128> we still have some though
[20:24] <GunnarHj> seb128: When testing a build of the trunk, it got worse (on the desktop).
[20:25] <seb128> GunnarHj, you clearly didn't test before
[20:25] <seb128> we had like every language and variant existing in the world earlier
[20:25] <seb128> it got better for sure ;-)
[20:26] <GunnarHj> seb128: True, I didn't. But it still seems to be pretty bad.
[20:26] <seb128> it's quite ok
[20:26] <seb128> not great, but good enough (well at least usable)
[20:26] <GunnarHj> seb128: What's wrong with doing it right?
[20:26] <bschaefer> attente, indeed very strange...
[20:27] <GunnarHj> seb128: You triaged the bug, btw. ;-)
[20:27] <seb128> GunnarHj, nothing, I agree it could be better, I just disagree with the way you undermine the work which has been currently done
[20:27] <Laney> I think the way l-s displays the options is nicer
[20:27] <seb128> it is
[20:27] <Laney> but our way isn't that bad
[20:28] <GunnarHj> seb128: I really don't try to undermine anything! Just trying to help improve.
[20:28] <Laney> that's Language (Variant) [don't know the proper terms]
[20:28] <seb128> GunnarHj, so focus on what should be done rather than trying to show how buggy you find the current solution ;-)
[20:28] <GunnarHj> seb128: Of course.
[20:31] <GunnarHj> attente: Do you mean that languages and regional formats are not set separately?
[20:31] <attente> GunnarHj, yes
[20:32] <Laney> https://wiki.ubuntu.com/LanguageAndText#phone
[20:32] <GunnarHj> Laney: tnx
[20:33] <Laney> It doesn't say that, but there's only one option for language so it's used to set both
[20:34] <seb128> I don't think it makes much sense to have different options
[20:34] <GunnarHj> attente: Well, in that case a simple 'locale -a' based list seems to be appropriate. I thought its only purpose was to select the display language, which is why I proposed the language-tools script.
[20:35] <seb128> the current list seems a bit too verbose
[20:35] <Laney> Display language might not be the best title in that case
[20:35] <attente> GunnarHj, thanks
[20:35] <seb128> like it has English-Ireland
[20:35] <seb128> how is that different from English?
[20:36] <GunnarHj> Laney: Agree that the title should be changed.
[20:36] <Laney> Probably in formatting
[20:36] <attente> does ireland use different formats?
[20:36] <seb128> I don't know
[20:36] <seb128> Laney might know
[20:36] <Laney> haha
[20:36] <Laney> I do not
[20:36] <seb128> :/
[20:36] <seb128> we need cjwatson :p
[20:37] <seb128> or Riddell
[20:37] <attente> i guess they don't like being grouped with the UK...
[20:37] <Laney> Some people might have a problem being force to set en_GB though
[20:37] <Laney> ...
[20:37] <seb128> Laney, you UK guys should know about the different between your countries :p
[20:37] <Laney> Ireland isn't in the UK
[20:37] <attente> yeah. i know :P
[20:38] <Laney> So yeah, it does make sense
[20:38] <Laney> I think it'd look a bit less jumbly if we used the same scheme as l-s
[20:38] <seb128> Laney, North Ireland is no?
[20:38] <Laney> that's probably not en_IE
[20:38] <GunnarHj> seb128: Just to clarify: Considering that it's considered sensible to distinguish between display language and formats on the desktop, why isn't that true for the phone?
[20:39] <seb128> GunnarHj, what are win8, iOS, android doing in that regard?
[20:39] <seb128> GunnarHj, phone tend to be less "geeky" than computer and we can do with some simplification there
[20:40] <GunnarHj> seb128: I don't own a phone, so I have no idea. ;-)
[20:40] <seb128> my android (samsung) seems similar to what we have
[20:40] <seb128> english
[20:40] <seb128> - australia
[20:40] <seb128> - ireland
[20:40] <seb128> - new zealand
[20:40] <seb128> - south africa
[20:40] <seb128> etc
[20:40] <GunnarHj> seb128: Ok.
[20:41] <GunnarHj> Guess I'm a little biased on this matter...
[20:41] <Laney> yeah that's pretty alright
[20:41] <Laney> It's basically saying that you can't choose them separately
[20:42] <Laney> I spy a ubuntu-tweak-tool on the horizon
[20:42] <seb128> Laney, sorry, I mean all those are all options
[20:42] <Laney> yep
[20:42] <Laney> I mean formats and language
[20:42] <seb128> right
[20:42] <seb128> well, "format" always seemed weird to me
[20:42] <seb128> I'm not sure what format people tweak
[20:43] <GunnarHj> Laney: And if that's the design decision, I'd better close the bug.
[20:43] <seb128> I never felt the need to tweak how numbers are displayed or such
[20:43] <attente> we could've just said locale i suppose
[20:43] <Laney> I dunno
[20:43] <Laney> Maybe if you live in another country?
[20:43] <Laney> Hard to guess what people use things for
[20:43] <seb128> GunnarHj, I'm not sure we have enough input from device to device
[20:43] <seb128> I'm not even clear what we are missing with the current approach
[20:43] <seb128> or what it gives us over the "list only countries"
[20:45] <GunnarHj> seb128: What we miss is an opportunity for people who lives in one country, but prefer the display language of some other country, to set date/time, number, currency etc. formats of their site.
[20:47] <seb128> GunnarHj, there is always a balance between standard needs and UI complexity
[20:48] <seb128> not sure how common those options are on a phone
[20:48] <GunnarHj> seb128: Indeed. Not saying that there is a right solution here.
[20:48] <seb128> they are useful on a desktop, but that's a more powerful/work oriented environment
[20:49] <GunnarHj> seb128: Agreed.
[20:49] <seb128> I think we should keep the bug and get input from mpt/design
[20:49] <GunnarHj> seb128: Ok. Then I won't close it.
[20:49] <seb128> thanks
[22:36] <tkamppeter> colonelqubit, yes, I could help you with testing. Please give me links to the bug reports.