[05:46] <hikiko> Hi
[07:09] <TheMuso> seb128: Hey there. Mind subscribing the desktop team as a bug contact for valadoc? I missed it, and it needs main inclusion, MIR is bug 1556703
[07:47] <seb128> good morning desktopers
[07:48] <seb128> TheMuso, hey, does it really make sense to have to maintain another vala tool in the lts just for that? other projects build their html and include them in the tarball, no point to waste builder cycles rebuilding again and again something which is static for a fixed version
[07:49] <seb128> shrug, intel driver corruption after vt switch
[07:49] <seb128> need to reboot
[07:49] <seb128> brb
[07:59] <seb128> k, back to working session
[08:03] <pitti> bonjour seb128
[08:03] <seb128> salut pitti, ça va bien ?
[08:03] <pitti> seb128: oui, et toi ?
[08:03] <seb128> c'est comment votre v-sprint? c'est sur quel sujet ?
[08:03] <pitti> error tracker vsprint going on, nightshifts again :)
[08:03] <seb128> oh, nice
[08:03] <seb128> moi ça va bien !
[08:04] <seb128> what things are you guys working on?
[08:04] <seb128> the error tracker could really do with some work
[08:04] <seb128> so nice to see it getting some focus ;-)
[08:04] <pitti> seb128: so far it took all three of us quite a while to deploy it into canonistack, we found a lot of issues, documented the process now, and fixed some bits
[08:04] <pitti> now working on bugs
[08:04] <pitti> as a warmup
[08:04] <pitti> not sure what Brian has planned for today and tmw
[08:05] <pitti> seb128: but for example https://bugs.launchpad.net/errors/+bug/1069743
[08:05] <seb128> that would be nice indeed
[08:20] <pitti> seb128: bug 1329779 approved -- that's just a sync? nice
[08:21] <seb128> pitti, indeed, thanks!
[08:23] <seb128> see we manage to clean up some cruft ;-)
[08:25] <pitti> heh yes, I was also removing some old wx bits recently, currently looking at wxwidgets2.8
[08:39] <didrocks> good morning guys (late good morning compared to my start time :p)
[08:40] <pitti> bonjour didrocks !
[08:40] <didrocks> hey pitti!
[08:40] <didrocks> pitti: systemd is driving me nuts btw :p
[08:41] <pitti> didrocks: it does that to all of us, don't worry :)
[08:41] <didrocks> heh
[08:41] <didrocks> I really don't understand why vlc is acting differently on a network connection when running as a service
[08:42] <pitti> err, do we talk about vlc the video player?
[08:42] <didrocks> yeah
[08:42] <didrocks> for a snappy demo
[08:42] <seb128> lut didrocks
[08:42] <didrocks> I tried to change StandardOuput/Input/Error to a tty just in case that was what changes its behavior (as it did for Qt apps) but it's not this
[08:42] <didrocks> salut seb128
[08:42] <didrocks> I'm a little bit clueless of what's different on the systemd env now :/
[08:43] <pitti> some missing environment? no session dbus?
[08:43] <pitti> (or do you run it as a session service, not system service?)
[08:43] <didrocks> I do run it as a system service, in an ubuntu core environment
[08:44] <didrocks> I'm getting some network connection errors
[08:44] <didrocks> (when trying to fetch a live stream)
[08:44] <didrocks> there is no session dbus for the user, so probably not this
[08:45] <didrocks> I'm just getting:
[08:45] <didrocks> Mar 15 08:32:54 localhost ubuntu-core-launcher[858]: [00007f41c4000e48] core access error: connection failed: Network is unreachable
[08:45] <didrocks> Mar 15 08:32:54 localhost ubuntu-core-launcher[858]: [00007f41c4000e48] http access error: cannot connect to www.youtube.com:80
[08:45] <didrocks> (same with https)
[08:45] <didrocks> the exact same command, ran directly (even under root), works
[08:46] <pitti> didrocks: snappy does some seccomp/apparmor/device restrictions etc stuff, any of that?
[08:46] <didrocks> pitti: yeah, we ruled that out
[08:46] <didrocks> it's running unconfined
[08:46] <didrocks> for the sake of testing
[08:46] <didrocks> and there is no denial
[08:46] <didrocks> (and both command and services are running the same command, generated by snappy)
[08:47] <pitti> well, this sure does smell like a private network ns or so
[08:47] <didrocks> mvo wrote: "ok, this took ages, I strongly doubt its a snappy problem, it looks like something strange with systemd. what happens is that the vlc/src/network/tcp.c module tries to connect to the youtube server via ipv4, then ipv6, gets ENETUNREACH, then ipv4 again (why?) then it gets a EINPROGRESS (which is correct). however it fails at this point and dies with network unreachable. I put a python3
[08:47] <didrocks> downloader into the script (just for fun) and that connects just fine to youtube. so I strongly suspect it is vlc (ENETUNREACH from ipv6, ipv4 gets an ok)
[08:47] <didrocks> "
[08:48] <didrocks> pitti: why would it get a private network under system (if we use curl, or any python server in the same script, it works)?
[08:49] <pitti> well, it normally doesn't, unless you enable the option for it; but I'm not familiar with the restrictions that are otherwise present on a snapy system
[08:49] <pitti> didrocks: if you run the service under ubuntu classic, does that work?
[08:50] <didrocks> pitti: let me try quickly
[08:50] <pitti> didrocks: nsenter might be an useful tool -- enter the namespaces of the vlc process, run a shell in it, and poke around
[08:50] <pitti> (in case you didn't try that yet)
[08:50] <didrocks> never used nsenter, let me try first running vlc on my system
[08:51] <pitti> didrocks: also, comparing /proc/<pid>/ns for your shell and for the vlc service process, to see if they are different
[08:54] <willcooke> morning desktoppers
[08:55] <didrocks> hey willcooke
[08:56] <didrocks> pitti: ok, so same on classic
[08:56] <didrocks> mars 16 09:55:42 tidus sh[8879]: [00007f6e6c000e48] core access error: connection failed: Network is unreachable
[08:56] <didrocks> mars 16 09:55:42 tidus sh[8879]: [00007f6e6c000e48] http access error: cannot connect to www.youtube.com:443
[08:56] <mvo> did you guys see what I wrote about connect() for ipv4/ipv6? that seems to be the crux
[08:56] <didrocks> just starting /usr/bin/vlc <youtube-stream> in a .service file
[08:56] <Trevinho> willcooke: morning!
[08:57] <seb128> hey willcooke Trevinho mvo
[08:57] <seb128> how are you?
[08:57] <Trevinho> Hi se
[08:57] <didrocks> pitti: would nsenter influence what mvo wrote about the ipv4/ipv6 thingy?
[08:57] <didrocks> hey Trevinho
[08:57] <Trevinho> Seb128*
[08:57] <Trevinho> didrocks: bonjour Didier
[08:57] <pitti> didrocks: nsenter doesn't affect the existing process at all, it just launches a new one in the same namespaces (mostly for debugging)
[08:57] <TheMuso> seb128: Yeah fair enough, will look into doing that tomorrow.
[08:57] <pitti> didrocks: think of it as the generalization of lxc-attach
[08:58] <pitti> lxc-attach is more or less nsenter
[08:58] <didrocks> pitti: the issue is that the process stops and exits
[08:58] <seb128> TheMuso, thanks
[09:04] <Laney> hullo
[09:04] <didrocks> hey Laney
[09:05] <seb128> hey Laney
[09:05] <pitti> hey Laney, good morning
[09:10] <didrocks> pitti: should I just add some long sleep() before vlc starts and look at what's different in the namespace that way?
[09:10] <pitti> didrocks: nsenter to get a shell doesn't help?
[09:10] <Laney> 3~3~3~what up
[09:10] <Laney> 3~3~3~!
[09:10] <didrocks> pitti: well, vlc exits immediatly
[09:11] <pitti> didrocks: ah; well, then change the process to "ExecStart=/bin/sleep infinity", nsenter that, and run vlc  from a shell?
[09:11] <pitti> then you can strace/gdb/etc.
[09:13]  * didrocks wonders how many services people will develop will have this kind of issues only as a systemd service
[09:17] <pitti> first time I hear about an oddity like that
[09:17] <didrocks> pitti: well, there is the one on stdout/stdin/stderr not being attached to real tty
[09:18] <didrocks> (some people spent 3 days because of this before I helped them :p)
[09:18] <didrocks> but it's not the case here
[09:18] <didrocks> pitti: I tried sudo nsenter --target <pid> --mount --uts --ipc --net --pid
[09:19] <didrocks> run in it /usr/bin/vlc <https_stream_url>
[09:19] <didrocks> and it works
[09:19] <didrocks> is there anything else that I'm missing in nsenter parameter namespaces?
[09:19] <davmor2> willcooke, seb128: okay that was weird after the updates yesterday I fired up my machine this morning, external display worked on lightdm and plymouth but didn't in session, turns out it had been deactivated in screen settings
[09:20]  * didrocks will add --user
[09:20] <seb128> davmor2, who is playing with your computer at night? ;-)
[09:20] <willcooke> heh
[09:20] <willcooke> Laney - is that ^ similar to your screen woes?
[09:21] <seb128> davmor2, can you re-activate it?
[09:21] <didrocks> pitti: same without any parameter btw (only --target)
[09:21] <seb128> Laney, how was the quizz? did you win? ;-)
[09:21] <davmor2> seb128: yeap up and running now
[09:21] <seb128> you are sure you didn't play with the UI?
[09:22] <davmor2> seb128: it's like that one setting got reverted, but sticky edges stayed turned off
[09:22] <seb128> davmor2, did you change anything in your monitors setup, like port they are connected on, number, etc?
[09:22] <seb128> davmor2, it looks like it maybe failed to restore the written config, or though that you setup didn't match a known one
[09:23] <davmor2> seb128: nope, not touched screen settings at all since I got it the way I wanted it
[09:23] <seb128> davmor2, is there any error in ~/.cache/upstart/unity-settings-daemon.log?
[09:24] <pitti> didrocks: does the vlc process started from the .service have different namespaces in the first place?
[09:24] <davmor2> davmor2@davmor2-XPS-13-9343:~⟫ cat .cache/upstart/unity-settings-daemon.log
[09:25] <davmor2> ** (unity-settings-daemon:2595): WARNING **: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
[09:25] <davmor2> Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[09:25] <davmor2> (unity-settings-daemon:2595): color-plugin-WARNING **: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/cups_HP_Photosmart_5520_series
[09:25] <seb128> mvo, hey, could you have a look to https://code.launchpad.net/~seb128/software-properties/security-update-tweaks/+merge/289151 ? it fixes the unattendee-upgrade issue I think (works for me at least)
[09:25] <davmor2> seb128: ^
[09:25] <seb128> davmor2, yeah, those are "normal/known", not due to your issue
[09:26] <didrocks> pitti: I'm not sure be skilled enough to answer. I didn't put anything in my .service file to change namespace at least
[09:26] <pitti> didrocks: most services don't, so if there's any difference to /proc/1/ns/ that would be a surprise
[09:26]  * seb128 tries to sync wxwidgets3 and notice that pitti already did
[09:26] <pitti> didrocks: but if there's no difference, then nsenter also won't make much difference
[09:26] <seb128> pitti, thanks!
[09:26] <pitti> seb128: ah, I noticed that you didn't and then just went aheaad
[09:26] <Laney> willcooke: I couldn't reactivate it
[09:26] <Laney> seb128: no!
[09:27] <seb128> pitti, I was in the middle of something else and it was next on my list, I was getting to it now .... no worry, it's done which is what matters ;-)
[09:27] <Laney> it was hard
[09:27] <didrocks> pitti: hum… so, it's something else that systemd does preventing it to access the network apparently
[09:27] <seb128> Laney, well, at least you know you can do better next time ;-)
[09:28] <pitti> didrocks: answer to different namespaces> just start vlc.service, get the pid, and compare "sudo ls -l /proc/<that pid>/ns" with "sudo ls -l /proc/1/ns"
[09:29] <didrocks> pitti: I did check the sleep() (as I can't check vlc when not working, as it's exiting), but yeah, it's the same namespace
[09:29] <pitti> didrocks: ok, so that's confirming what we expect; so nsenter, namespaces etc. are not involved here the
[09:29] <pitti> nn
[09:29] <pitti> "then"
[09:30] <didrocks> hence why vlc is working as expected from this shell…
[09:30] <pitti> and if wget or some python downloader is working and can access the net, then it's hardly something in the environment of that process that prevents it?
[09:31] <didrocks> pitti: exactly…
[09:31] <didrocks> (meaning, yeah, tried that)
[09:31] <pitti> the only ways how you actually could prevent net access for an invidivual process are either MAC (apparmor), putting it into a different network namespace, or do syscall filtering with seccomp
[09:32] <didrocks> but there is none of that in classic for my service, right?
[09:32] <didrocks> (and we would have denials in logs)
[09:32] <pitti> no
[09:32] <pitti> you don't get denials for seccomp or namespacing, just with apparmor
[09:33] <didrocks> ah ok, but anyway, it's not that. So, there is something in the env under systemd that vlc doesn't like and triggering it into this mode
[09:33] <pitti> but with namespacing wget would fail as well, and we don't apply seccomp restrictions in  classic
[09:33] <didrocks> yeah
[09:33] <pitti> didrocks: does strace give any insights?
[09:33] <pitti> I think you already identified the part of the code that fails (but I don't know the details there)
[09:35] <didrocks> pitti: strace is what mvo used for the above comment ^ (and the ipv4 which gets an ok, then ipv6 switch getting ENETUNREACH, then ipv4 again, then EINPROGRESS)
[09:39] <ksamak> hi all
[09:39] <ksamak> Trevinho: hi.
[09:39] <ksamak> Trevinho: just so i know, is there any planned delay for publishing of compiz
[09:39] <ksamak> 0.9.12.3?
[09:40] <ksamak> thanks for announcing btw
[09:40] <Trevinho> Hey
[09:40] <Trevinho> So, I'm quite busy with some stuff, but I'm going to do that after next landing
[09:40] <Trevinho> Ok?
[09:41] <ksamak> no problem.
[09:41] <ksamak> i just wanted to know to also plan
[09:42] <ksamak> btw, i'm preparing a better focus tracking, with new plugin focuspoll, and ezoom modified in consequence.
[09:42] <ksamak> that's quite necessary for impaired people. that'll definitely benefit ubuntu's impaired users.
[09:45] <didrocks> pitti: I did run a screen session as a system service
[09:46] <didrocks> pitti: starting vlc from it reading a youtube stream, and it works
[09:46] <seb128> crazyness
[09:47] <pitti> indeed -- sensitive to stdout/stderr being pipes? looking at $TERM? not having a PAM session?
[09:48] <didrocks> pitti: as I said, I tried to set StandardOut/Err/In to tty
[09:48] <didrocks> let's see if $TERM can play something
[09:49] <Trevinho> ksamak: awesome
[09:50] <Trevinho> ksamak: also, hikiko would work in improving the ezoom experience with unity. So you two might sync
[09:51] <hikiko> hey
[09:51]  * hikiko saw a highlight
[09:51] <hikiko> ksamak, hi
[09:52] <hikiko> are you preparing a change for the ezoom?
[09:53] <didrocks> hikiko: I hope you are enjoying your new laptop, I spent too much time of my life for this shipment :p
[09:53] <hikiko> hahhaha
[09:53] <hikiko> thanks didrocks :D
[09:53] <didrocks> yw!
[09:53] <hikiko> It's GREAT :)
[09:53] <hikiko> did you see the pic on telegram?
[09:54] <didrocks> yep
[09:55] <didrocks> pitti: nope, no progress. Any way I can give it a PAM session?
[09:55] <hikiko> compiling is super fast :D
[09:57] <pitti> didrocks: you can start it as root through su -c 'vlc' someuser ; but at that point it's probably easier to look at the particular network code that's failing
[09:57] <pitti> su - starts a PAM session
[09:58] <pitti> didrocks: did you compare the process environment already?
[09:58] <pitti> didrocks: screen, shells, etc. all read /etc/environment, set $HOME, etc.
[09:58] <pitti> a .service normally doesn't have any $HOME
[09:59] <didrocks> pitti: let me run it as my user (as it fails the same way) and inject my whole env
[10:00] <pitti> didrocks: or rather, start vlc from a shell through env -i
[10:01] <didrocks> pitti: other kind of errors without any env
[10:01] <didrocks> > [00007f94c0000e48] http access error: error: HTTP/1.1 404 Not Found
[10:01] <didrocks> for instance
[10:01] <pitti> interesting -- isn't that very similar to what you see?
[10:01] <pitti> like, it won't have a ~/.config/vlc, nor can it create one
[10:02] <didrocks> yeah, can be a side effect of this
[10:02] <didrocks> so trying to run the service as my user
[10:02] <pitti> didrocks: so, what happens if you add Environment=HOME=/tmp/foo to the service?
[10:02] <didrocks> and injecting my all env
[10:02] <pitti> (and create /tmp/foo)
[10:04] <didrocks> pitti: no, same issue (and not a different log)
[10:04]  * pitti doit faire les courses, à plus tard
[10:04] <didrocks> à tout à l'heure
[10:10] <ksamak> Trevinho: hikiko okay, sure. i modified things in ezoom, that are probably worth discussing.
[10:10] <ksamak> including the zoomarea center calculation.
[10:10] <ksamak> this'll probably have to change, with your input.
[10:11] <ksamak> hikiko: but let's talk about that when the patch is out.
[10:11] <ksamak> :-)
[10:11] <hikiko> ksamak, I am using only the final zTransform for my unity changes
[10:12] <hikiko> I guess that whatever the changes are you ll still pass a zTransform to compiz right?
[10:13] <ksamak> hikiko: yep, i just changed the maths a little.
[10:13] <mvo> seb128: on the phone, will look in a bit
[10:13] <seb128> mvo, thanks
[10:14] <didrocks> mvo: pitti: ok, dumping my whole user's env make it works, I need know just to bisect on which ones are needed
[10:14] <hikiko> then your changes probably wont affect unity at all :)
[10:17] <mvo> didrocks: its the env? woah, can't wait to hear which one it is
[10:18] <mvo> seb128: looks good
[10:18] <seb128> mvo, thanks!
[10:18] <seb128> mvo, let me upload that then ;-)
[10:19] <mvo> go go
[10:22] <didrocks> mvo: argh it's the XAUTHORITY apparently on my classic system… which is weird, because when running the command on a headless snappy system, we don't have it and it works…
[10:22] <didrocks> mvo: but it gives the same error, so I really think the network error is a side effect of something else failing
[10:26] <chrisccoulson> Is the lock screen meant to scale correctly on high DPI screens?
[10:28] <Laney> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1551820
[10:29] <chrisccoulson> Laney, thanks
[10:29] <Laney> it used to work
[10:30] <seb128> when did it regress?
[10:30] <seb128> is that happening all the time?
[10:31] <Laney> look at the date I filed the bug
[10:31] <Laney> yes
[10:31] <seb128> yeah, the report says "in many weeks" :p
[10:31] <seb128> I guess chrisccoulson has a new laptop so doesn't have more data :-/
[10:31] <seb128> Trevinho, ^ do you have any clue when that might have regressed?
[10:31] <chrisccoulson> Yeah, I've only had a high DPI screen for a few days :)
[10:32] <Laney> not sure that 'when' is super important to know if you know the code already
[10:32] <Laney> can probably blame/log the file or just look at the code
[10:33] <seb128> it helps to be able to find somebody to ping saying "that change of yours broke it" :p
[10:33] <seb128> otherwise it sits there as it current does :-/
[10:33] <chrisccoulson> Also, the online-accounts sign-in doesn't scale either. With http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/1365, the webengine will scale correctly as long as Qt indicates the device scale, but that's not hooked in Qt anywhere :(
[10:34] <Laney> that's not a matter of 'when'
[10:34] <seb128> if I would have to guess
[10:34] <seb128>   [ handsome_feng ]
[10:34] <seb128>   * Extend the lockscreen theme for kylin.
[10:34] <Laney> it's a matter of you have to ping people to get bugs attention
[10:34] <seb128> right
[10:34] <Laney> but I did post it on telegram at the time
[10:34] <seb128> but that I tried
[10:34] <seb128> if you ping without a change to point at you don't get much pong
[10:34] <seb128> true story :-/
[10:35] <caribou> Hello, I'm investigating a bug in Xenial with my external screen on VGA, is this a good place to ask ?
[10:35] <seb128> caribou, not really, it's not a support forum, try #ubuntu for user questions
[10:36] <caribou> seb128: on Xenial, not sure #ubuntu is the proper forum
[10:36] <Laney> #ubuntu+1
[10:36] <seb128> caribou, what Laney said
[10:36] <seb128> Laney, Trevinho, I'm going to have to bet it's the kylin changes for their custom greeter
[10:36] <caribou> hmm, didn't know about this one
[10:36] <Trevinho> Mh, yeah it might have happened there
[10:36] <Trevinho> let me check
[10:36] <caribou> seb128: Laney: thanks!
[10:36] <seb128> yw
[10:36] <seb128> Trevinho, thanks
[10:38] <Laney> Trevinho: grazie
[10:38] <Trevinho> Laney: di niente...
[10:38] <Trevinho> It's time to teach some more italian here... :)
[10:41]  * Laney wants a coffee
[10:41] <Laney> coincidence?
[10:42] <Trevinho> Laney: ok I think i've fixed it...
[10:42]  * Trevinho compiles
[10:42]  * Trevinho is just sooo lazy in making new branches + MPs... :-P
[10:42] <Laney> gimme a deb
[10:43] <Trevinho> Laney: I can give you diff, maximum :P
[10:43] <Laney> you're compiling :(
[10:43] <hikiko> I love compiling today :p with ssd + i7
[10:43] <Laney> think of the environment man
[10:43] <pitti> didrocks: ah, so it still tries to talk to X?
[10:44] <didrocks> pitti: well, but that's running in a X session, so it seems so. However, I can run it on ubuntu core headlessly (by executing the command)
[10:44] <didrocks> pitti: so I guess the error is just a side effect of errno not being empty
[10:44] <didrocks> and the error is actually somewhere else
[10:47] <didrocks> pitti: mvo: exporting the sudo env (where the commands directly run) to the wrapper doesn't work in the ubuntu core service :/
[10:48] <Trevinho> Laney: here you are https://code.launchpad.net/~3v1n0/unity/lockscreen-promptview-scaling-fix/+register-merge
[10:49] <Laney> Trevinho: blink
[10:52] <Trevinho> Laney: well uri is wrong, but well, you got it ;-)
[11:03]  * Laney spanks Trevinho 
[11:04] <Laney> fix your tests!
[11:35] <Laney> Trevinho: it works
[11:35] <Laney> !!!
[11:36] <Trevinho> Laney: of course, it does ;-)
[11:38] <Laney> unlike your testsuite
[11:38] <Laney> ^_^
[11:38] <seb128> lol
[11:39] <willcooke> :D burn
[11:40] <willcooke> added a task to Trello
[11:41]  * Laney attaches a log
[11:48] <willcooke> thanks Laney
[11:53] <mvo> didrocks: so it still does not work even with all the env?
[11:56] <didrocks> mvo: no, no progress (when running on Ubuntu Core). The only progress I got is that comparing their output is that in the successful case, there is "core access debug: connection succeeded (socket = 6)"
[11:56] <didrocks> mvo: looking at fd (if they are still the same after this read), it's /dev/urandom
[11:56] <didrocks> and I'm completely stuck then
[11:57] <didrocks> still working like clockword when using the command line version
[11:57] <didrocks> (even with sudo)
[12:26] <desrt> good morning all
[12:26] <desrt> hey didrocks :)
[12:27] <didrocks> hey desrt
[12:39] <seb128> hey desrt
[12:48] <desrt> morning, seb
[12:48] <desrt> got my fitbit :)
[12:49] <ogra_> so you can share your fat with your friends now !
[12:50] <desrt> fat with friends!
[12:50] <ogra_> :)
[12:50] <desrt> fatr!
[12:51] <desrt> it's stupid, but this thing is already causing me to get more exercise
[12:52] <desrt> it shames you into moving
[12:52] <seb128> hehe
[12:52] <desrt> if you didn't take 250 steps in an hour, it vibrates and shows you a frown and says "time to move!"
[12:52] <seb128> I'm looking forward seeing that one in Prague
[12:52] <seb128> oh, nice
[12:52] <desrt> and then if you do it it vibrates again and gives you some rewarding message like "you did it!"
[12:52] <seb128> mine didn't do that!
[12:52] <seb128> cool
[12:53] <desrt> it's basically the "stop being a sedentary software developer" feature
[13:28] <didrocks> pitti: waitpipe: already dying is another difference I can notice, I tried to set Ignore SIGPIPE to False in the service, but doesn't change…
[14:12] <didrocks> pitti: if you have time for it (I'm really stuck at it now), I have a very simple .service file and a script runner for an adt cloud image machine
[14:12] <didrocks> pitti: basically, running the script by hand works
[14:12] <didrocks> having the service starting doesn't
[14:12] <didrocks> exporting all env that the user have when the script runs by end fails as well
[14:14] <didrocks> (and I'm running the service as the "ubuntu" user to ensure we don't have issues due to running as root)
[14:19] <seb128> attente, hey, thanks for the nautilus discussion yesterday ... I've a patch that is easy enough and works, want to have a look and tell me if you think it looks fine? (the _cb changes are mostly a copy of what upstream did)
[14:20] <attente> seb128: sure, glad it worked out for you
[14:35] <attente> seb128: where is the patch?
[14:36] <seb128> attente, grah, sorry, I though I had copied the pastebin url, which apparently I didn't :p
[14:36] <seb128> attente, http://paste.ubuntu.com/15401688/
[14:36] <attente> hehe, no worries
[15:37] <attente> seb128: hey, is there a reason you switched to using selected_file instead of gtk_places_sidebar_get_location()?
[15:39] <seb128> attente, I basically backported https://git.gnome.org/browse/nautilus/commit/src/nautilus-window.c?id=52e4774e9942043739c1594a72e0ffb96694632b
[15:39] <seb128> attente, the bug hint they did that way because of gtkplacesidebar issues
[15:40] <seb128> like the selection isn't changing when you right click
[15:40] <seb128> (that looks a bit weird btw)
[15:40] <attente> ok
[15:40] <attente> seb128: the indentation is a bit weird at src/nautilus-window.c:880
[15:41] <seb128> I'm not surprised
[15:41] <seb128> upstream is weird
[15:41] <seb128> they decided they don't like tab indent which nautilus was using
[15:41] <seb128> so every change/new commit uses space indent
[15:41] <seb128> but they don't want to change existing code to now screw git blame&co
[15:41] <seb128> so nautilus sources are mix of style
[15:42] <seb128> eventually when all code is rewritten it's going to be consistent again :p
[15:43] <seb128> but yeah, seems like I forgot to fix that chunk when I copied it
[15:43] <seb128> attente, thanks for pointing it out!
[15:43] <attente> seb128: yeah, no worries. i think selected_(file|volume) might need to be cleared on destroy or finalize
[15:44] <attente> seb128: minor nit also, the added separator is a bit wider than the other ones
[15:44] <seb128> oh, right
[15:45] <seb128> I wonder if upstream has the issue/why
[15:45] <seb128> going to look at that
[15:45] <attente> yeah. i guess every time you pop up the popover it adds a ref, and only clears it when you actually click on that item
[15:46] <seb128> good catch
[15:46] <seb128> upstream fixed it it seems
[15:47] <seb128> attente, https://git.gnome.org/browse/nautilus/commit/src/nautilus-window.c?id=40a709cc11f60a47a0d956ea39af15e45d4339e3
[15:47]  * seb128 backports that as well
[15:47] <attente> nice
[15:52] <attente> seb128: not sure why the separators are a different size, but it's the same issue upstream as well
[15:52] <seb128> good, which means I can report it there ;-)
[16:01] <seb128> attente, they pack a GtkSeparator manually in the popover with bottom/top margins, I guess they also need some left/right ones
[16:01] <seb128> https://git.gnome.org/browse/nautilus/tree/src/nautilus-window.c#n1267
[16:02] <seb128> indeed
[16:03] <seb128> https://git.gnome.org/browse/gtk+/tree/gtk/gtkplacessidebar.c?h=gtk-3-18#n3349
[16:03] <attente> sounds about right
[16:04] <seb128> looks right with left/right at 12
[16:04] <seb128> thanks
[16:11] <seb128> attente, reported with a patch as https://bugzilla.gnome.org/show_bug.cgi?id=763768
[16:11] <seb128> attente, thanks for the review! (unsure if you are done?)
[16:12] <attente> seb128: nice! yeah, can't see any other real issues, it actually works pretty great as is. good job!
[16:13] <seb128> attente, great, thanks again for putting me back in the correct direction, unsure why I had discarted a partial port to gaction, and for the review!
[16:39] <seb128> attente, gnome-software stays as a service again after starting it from the dash and closing it, is that wanted/a known issue?
[16:40] <attente> seb128: yeah, apparently running from the dash dbus-activates it, which always runs it with the --gapplication-service flag
[16:40] <seb128> does it?
[16:41] <seb128> :-/
[16:41] <attente> yeah
[16:42] <attente> so i'm not sure what to do there exactly. i could try to strip out the flag but that seems really hacky
[16:42] <attente> it would work though i guess
[16:43] <seb128> I don't know on the code side, I guess you asked desrt what she thinks?
[16:43] <desrt> attente: we already discussed this...
[16:43] <seb128> but from an user experience, I just had it have an outdated update list because it didn't pick up/refresh after I apt-get installed some things
[16:43] <desrt> attente: the thing you ought to be doing is ignoring the flag entirely
[16:43] <desrt> if you want it to quit, let it quit
[16:44] <Laney> unity does dbus activation?
[16:44] <seb128> and it displays non-notify-osd friendly notificaitons
[16:44] <desrt> just get rid of the hold() irrespective of flag
[16:44] <desrt> Laney: anything that uses GIO does
[16:44] <Laney> huh!
[16:44] <Laney> cool
[16:44] <desrt> attente: or did i miss something and there is some other case where you want the hold?
[16:45] <attente> desrt: i'm pretty sure i tried removing the g_application_hold() but it still stuck around
[16:45] <desrt> because of the inactivity timeout and because of the hidden (not destroyed) main window
[16:45] <desrt> we solved those things, no?
[16:46] <attente> i don't remember, but i'll try it again
[16:46] <seb128> attente, thanks
[16:46] <desrt> you started destroying the main window, which led to the gs_application_activate -> gtk_widget_show() on destroyed window bug
[16:47] <desrt> after that, there are only two things that can keep the application around: hold() and inactivity timeouts
[16:47] <attente> right
[16:56] <chrisccoulson> Is anyone else seeing compiz gobble up memory in xenial? http://paste.ubuntu.com/15402706/
[16:57] <seb128>  2586 seb128    20   0  418612 194572  31764 S   0,0  4,9  15:11.12 compiz
[16:57] <seb128> no
[17:04] <seb128> pitti, what do you think about disabling the pygi warnings about using "require_version" for the lts? we still have quite some code not doing that, it's not a priority to fix now and spamming logs
[17:17] <pitti> seb128: seems fine to me; maybe two weeks before release?
[17:17] <seb128> sure
[17:17] <seb128> thanks
[17:32] <seb128> ok, time for some exercice, have a nice evening everyone
[17:32] <seb128> well, at least for those off before I'm back
[17:32] <seb128> bbl
[17:59] <willcooke> righty, school meeting tonight. *That* is how much I like meetings.
[18:00] <willcooke> nigth all
[18:03] <Laney> nn
[18:21] <Sweet5hark> got postgresql stuff in the libreoffice snap to build. snap is now at 2GB bundling all of postgres (not that we currently have an alternative) ...
[22:11] <seb128> robert_ancell, hey, is there a git branch where we should commit/push trivial fixes? is that wip/ubuntu-changes?
[22:11] <robert_ancell> seb128, eys
[22:11] <robert_ancell> yes
[22:11] <seb128> ok
[22:11] <seb128> 	uri = g_strdup_printf ("http://changelogs.ubuntu.com/changelogs/binary/%s/%s/%s/changelog", source_prefix, source, update_version);
[22:12] <seb128> I think the "source" there should be "binary_source"
[22:12] <seb128> I'm mentioning it in case you edit things around and want to change it
[22:12] <seb128> I'm going to do that tomorrow otherwise
[22:13] <robert_ancell> seb128, that change would be in wip/rancell/apt
[22:13] <seb128> ah
[22:14] <robert_ancell> oh, right. I was confused when you pointed that out before
[22:16] <seb128> why?
[22:16] <seb128> I didn't manage to check that today
[22:16] <seb128> but I think that's why language-selector-gnome's changelog is not showing
[22:17] <robert_ancell> you emailed me that a while ago, and I thought we needed to pass the source package to the URL, but now it clearly needs to be the binary name
[22:17] <seb128> right
[22:17] <seb128> I commented about that on some of the bugs
[22:25] <seb128> ok, I was just passing by
[22:25] <seb128> good day/night everyone