[05:15] <didrocks> good morning
[05:15] <duflu> Hi didrocks
[05:16] <didrocks> hey duflu
[06:23] <oSoMoN> good morning desktoppers
[06:30] <didrocks> sesalut oSoMoN
[06:34] <oSoMoN> sesalut didrocks :)
[06:35] <duflu> Morning oSoMoN
[06:59] <Wimpress> Morning
[07:05] <marcustomlinson> goedemorgen
[07:09] <duflu> Morning Wimpress and marcustomlinson
[07:16] <didrocks> hey Wimpress, marcustomlinson
[07:18] <seb128> lut didrocks
[07:18] <seb128> good morning desktopers
[07:18] <didrocks> salut seb128
[07:19] <seb128> en forme ?
[07:19] <duflu> Hi seb128
[07:19] <seb128> hey duflu
[07:21] <didrocks> ça va, et toi ?
[07:25] <seb128> ça va bien !
[07:26] <seb128> duflu, oh, I forgot to mention it again, but that keeps coming as an issue in team meetings, please don't directly nominated bugs to stable serie without assignee. Either you/Marco plan to work on the fix and assign it as appropriate or rls-bb-incoming tag them so they go through the proper team review process
[07:27] <duflu> seb128, ok
[07:27] <seb128> thanks!
[07:28]  * duflu assigns self
[07:28] <seb128> it's a bit annoying that we don't have a proper way to flag "affects that serie" that doesn't conflict with the rls tracking process but that's the way it is atm :/
[07:34] <duflu> didrocks, I would like to drop the patch for bug 1797355, because it's preventing us from getting a bigger bug 1705369 fixed. I can't seem to reproduce 1797355 - can you?
[07:35] <didrocks> duflu: I need to retry with a newer GNOME SHell, but the fix isn't applied upstream IIRC, so let's see
[07:36] <didrocks> duflu: mind if I test it either tomorrow/next Monday? Don't want to reboot/context switch with the potential of not booting right now :p
[07:36] <duflu> I know. It looks to me like upstream had it right
[07:36] <duflu> didrocks, no problem -- I'll just block any code review waiting for you some timwe
[07:36] <duflu> time
[07:37] <didrocks> duflu: I'll retry and keep you posted
[07:43] <seb128> bah, it's ranting week or what on discourse/forums
[07:43] <seb128> snaps, i386, ...
[07:44] <duflu> People care about things. Which means people have opinions
[07:44] <duflu> The good news is that it means they care about Ubuntu
[07:44] <seb128> the french forum seems to have turned into a group of old school people who think a community is about complaining about anything done in the project you are supposed to care about...
[08:02] <Laney> yo
[08:08] <duflu> sup Laney
[08:08] <didrocks> hey Laney
[08:13] <Laney> hey duflu didrocks
[08:20] <oSoMoN> seb128, complaining is very French, nothing new under the sun :)
[08:23] <seb128> hey Laney
[08:23] <seb128> oSoMoN, yeah, just wrote a long reply on discourse
[08:24] <duflu> Remember you can always mute a topic at the bottom of each page
[08:24] <seb128> I'm refraining to register on the french forum to tell them "weird view of being part of a community/project to see that as $must_bitch_about_the_thing_Im_supposed_to_care_about)
[08:25] <seb128> they look like a bunch of biter old linux men :/
[08:25] <duflu> https://xkcd.com/386/
[08:25] <seb128> duflu, :-)
[08:26] <marcustomlinson> all absolute statements are wrong
[08:31] <seb128> well, they are right that our gnome-calculator startup time is embarassing and we should fix that
[08:32] <duflu> Yeah, though I was refraining from discussing that till someone else opened the bug. I just find the slowness annoying and not practical right now
[08:33] <didrocks> I guess this is the most visible point which starts this fud
[08:33] <didrocks> and TBH, it's a little bit embarrassing after having snaps by default for multiple releases. So, I can understand, this is why I asked them to come with facts on the french forum
[08:33] <didrocks> rather the "I think/I don't like/blablabla"
[08:33] <seb128> we transitioned those in 17.10 IIRC
[08:34] <seb128> they wake up 2 years later and act like it was the end of the world today
[08:34] <didrocks> they don't wake up 2 years later :)
[08:34] <didrocks> I've been containing those topics (and raised them here already) multiple times on the french forum
[08:34] <didrocks> telling them we are working on the speed improvements (and we did for some)
[08:35] <seb128> right, that's what I'm telling
[08:35] <didrocks> I guess after 2 years, as everything isn't fixed, they are coming to the conclusion it won't get fixed (but that's just my perception)
[08:35] <seb128> they prefer to bitch in their closed group
[08:35] <seb128> rather than try to work with us on solution...
[08:35] <didrocks> oh… "opening bugs/talking about it in the community forum" is a mantra I have for years with them :)
[08:35] <didrocks> but it doesn't always succeed
[08:35] <seb128> thx for keeping reminding them :)
[08:35] <didrocks> also, I think speaking in english is a high barreer
[08:35] <didrocks> barrier*
[08:36] <seb128> right
[08:36] <seb128> well I read a bit their post
[08:36] <didrocks> yeah, you can find something 3-4 pages for each release since 17.10
[08:36] <seb128> I don't like their mentality, unsure if we can make them reconsider their approach
[08:36] <didrocks> (the topic is archived on the "instable" forum)
[08:37] <seb128> their reply to any "$software has $issue" is "remove the snap, install the deb"
[08:37] <didrocks> I think if we come with "there is now more speed difference between snaps & debs", it will get harder for them to argue
[08:37] <seb128> which then goes "I've a years old version"
[08:37] <seb128> where they reply" try that ppa"
[08:37] <didrocks> yeah, the ppa approach is :/
[08:37] <seb128> would be more constructive to figure out the issue in the snap and get it reported/fixed
[08:37] <didrocks> I don't think they are technical enough for this
[08:37] <didrocks> especially when helping people on the LTS (which is where we pushed the snap)
[08:38] <didrocks> but TBH, I think we have enough "issues" we know about (like the startup time), already, getting those fixed, will help a lot in the perception of the tech
[08:38] <seb128> right
[08:38] <seb128> it's just sad the way they go about it
[08:38] <seb128> like one user had an issue with "retroarch"
[08:39] <seb128> it went through the "ah, it's because you use the snap"
[08:39] <seb128> they recommended installing the deb
[08:39] <seb128> and the user said "I've an year old version now and it still doesn't work"
[08:39] <seb128> so they are making thing more complicated
[08:39] <seb128> and not helping the users
[08:39] <seb128> he's off in a worth situation after they "helped"
[08:39] <seb128> they would better just not reply
[08:39] <didrocks> yeah, I guess this is the issue with not technical enough people
[08:40] <didrocks> the "use the deb" could be understandable: they are just trying to get things fixed for the use case (like sys admins)
[08:40] <didrocks> without seeing the greeter good, but at the same time, they are not beta tester
[08:40] <didrocks> which doesn't help us fixing issues, I agree
[08:40] <didrocks> BUT, in cases like this
[08:40] <didrocks> you end up in a worse situation, I agree
[08:41] <didrocks> "tinkering", was the term I was looking for
[08:41]  * seb128 must refrains from subscribing and trying to reply to every user problem :p
[08:41] <didrocks> good luck then :p
[08:42] <didrocks> I only monitor the "unstable version" topic
[08:42] <didrocks> and sometimes, on Monday, it's already a lot :p
[08:42] <seb128> I did a long reply on discourse, hopefully it's a bit usefulk
[08:42] <didrocks> yeah, read it, sounds good to me
[08:42] <seb128> thx :)
[08:42] <seb128> k, I just close that french forum
[08:42] <seb128> already too much to do, I don't need more distraction
[08:42] <didrocks> I think we should admit that the startup time issue is taking longer to fix than we thought, and this will help
[08:43] <seb128> right
[08:43] <seb128> I also think that for some reason gnome-calculator is praticularly slow
[08:43] <seb128> evince or gnome-calendar are faster to start than the calculator for me
[08:44] <seb128> also the snap exec metric shows that the desktop-launcher is not the main offender, which I though it would have been
[08:44] <didrocks> yeah, I guess we fixed most of the issues there
[08:44] <seb128> but there is no obvious time consumer in the top 10 either
[08:44] <didrocks> so, could be in snapd itself
[08:44] <seb128> right, maybe the compression
[08:44] <seb128> we need mvo&co to get to the bottom of that
[08:46] <didrocks> yep
[08:51] <oSoMoN> seb128, good answer on discourse, also thanks popey for your patience and repeated requests for actionable data
[08:51] <seb128> oSoMoN, thx!
[08:51] <popey> oSoMoN: np
[08:52] <mvo> seb128: you can test if its the compression by using "snap try" on the gnome-calculator prime dir and measure this
[08:53] <oSoMoN> I also like Ian Weisser's articulate replies, they contrast nicely with all those very emotional and unhelpful rants
[08:53] <mvo> seb128: we did some measurements just last week and it looks like squashfs/compression overhead is very small (chipaca wrote a script and measured a bunch of snaps)
[08:53] <seb128> mvo, the dir is /snap/<name>/current counts as "prime"?
[08:54] <oSoMoN> you'll probably need to unsquashfs the snap file to measure that reliably
[08:56] <mvo> seb128: sry was a bit terse, what oSoMoN said is easiest, just unsquash and snap try it
[08:56] <seb128> mvo, k, needs more debugging then :/ Like that recent discussion/report, the user has a 7 seconds start time, the desktop-launcher is the biggest offender in the snap exec metrics with 1 s and the other items are 0.3 seconds or such
[08:56] <mvo> seb128: snap try /path/to/unpack/dir
[08:56] <mvo> seb128: do you have a link?
[08:57] <mvo> seb128: is that hdd or ssd?
[08:57] <seb128> mvo, https://bugs.launchpad.net/snappy/+bug/1833004
[08:57] <mvo> seb128: I wonder if library loading/symbole resolving is slow, we never got around to measure this but I would love to get data for that too
[08:57] <popey> i get 7 second launch if i haven't used chromium for a day - so the cache is cold
[08:58] <popey> https://paste.ubuntu.com/p/mN8MtCPzYW/
[08:58] <seb128> on warm cache with calculator I get 0.7s vs 2s
[08:58] <seb128> like I already position my mouse on the X to close the dialog as it opens and click click click
[08:58] <popey> faster to use alt-f4
[08:58] <popey> as soon as the window appears
[08:58] <seb128> k
[08:58] <popey> IMO
[08:58] <seb128> bah, laptop flat
[08:58] <seb128> I need to go back to my desk
[08:58] <seb128> brb
[08:59] <popey> ^ totally not seb pressing alt-f4 accidentally on irc
[09:01] <oSoMoN> :)
[09:10] <seb128> and back
[09:16] <seb128> popey, mvo, that chromium pastebin is a bit weird btw
[09:16] <seb128>   8.304s /snap/chromium/750/usr/lib/chromium-browser/chrome
[09:16] <seb128>   4.624s /proc/self/exe
[09:16] <seb128> Total time: 9.529s
[09:17] <seb128> until now I though that the list if items were chunck of the total
[09:17] <duflu> Is that second line a fork() ?
[09:17] <duflu> Or just a bad lookup and should be grouped into the first?
[09:18] <mvo> the measure code may encounter something unexpected
[09:20] <duflu> I guess chrome does fork lots. That might be it
[09:22] <oSoMoN> it does fork a lot
[14:22] <tkamppeter> Anyone familiar with the autopkg tests of network-manager, this Python stuff using the unittest Python module?
[14:22] <Laney> a bit
[14:23] <Laney> tkamppeter: what's the problem?
[14:24] <tkamppeter> Laney, I have added some extra print() statements and I do not get the output of them in the log, even not the output of the already existing statements, like print('******* NM initialized *********\n\n'). I have set the NM_LOG_STDOUT env variable and actually get live view of the log output.
[14:35] <Laney> tkamppeter: hmm I dunno, sorry, I certainly saw a lot of output when I ran it before
[14:41] <tkamppeter> Laney, seems that only pitti knows it who has initially created it and then there was never a failure and I am the very first one having it fail.
[14:42] <Laney> No, we've certainly fixed things with it in the past
[14:43] <Laney> It's not something that's been touched a lot - Martin did a good job in making a robust test script - but it has been maintained a bit.
[15:06] <pitti> Laney, tkamppeter: where is this now? (not sure if I missed some distro git packaging changes)
[15:07] <pitti> at first sight it smells like a subprocess issue that gets redirected
[15:07] <Laney> hey pitti
[15:07] <pitti> hey Laney and tkamppeter, wie  geht's?
[15:07] <Laney> I think Till's working from https://code.launchpad.net/~network-manager/network-manager/+git/ubuntu/+ref/gir-nm
[15:10] <pitti> tkamppeter: so where exactly in https://git.launchpad.net/network-manager/tree/debian/tests/nm.py?h=gir-nm did you try and add a print?
[15:11] <pitti> print() in these tests should work fine
[15:17]  * Laney would think so too: buffering's off, stderr redirected to stdout
[15:18] <Laney> pitti: I'm juju 2-ifying/Mojoing autopkgtest atm :-)
[15:18] <Laney> RIP deploy.sh
[15:18] <Laney> hope you're well too
[15:18] <pitti> Laney: oh, poor man's juju! :)
[15:18] <pitti> Laney: I am, thanks! enjoying the summer
[15:19] <Laney> heh
[15:19] <Laney> we've not had one of those yet
[15:20] <Laney> http://[2001:ba8:1f1:d03:216:3eff:fef0:f2f0]/running <- first lxd/armhf test is a-go
[15:21]  * Trevinho undecided weather to go wild and try to fix a g++ thing or just leave the bug and testcase for the future generations :)
[15:21] <Trevinho> whether*
[15:21] <Laney> hey Trevinho
[15:21] <Trevinho> hi Laney
[15:21] <Laney> ¿cómo estás?
[15:21] <seb128> Trevinho, stop getting too much distracted by fixing all the world issues :)
[15:22] <Trevinho> seb128: you know, making better world is my mission :P, but I won't try this one indeed
[15:22] <seb128> :-)
[15:22] <Trevinho> Laney: all good
[15:23] <Trevinho> just was helping with one big improvement to gjs, which is blocked by mozjs, which I've workarounded also upstream, but still is eventually a g++ issue
[15:24] <Trevinho> Laney: as I expect you to be curious, try https://www.pastery.net/dvmjsj/ with both g++ and clang++ and see the nm inconsistency
[15:26] <Laney> I am, but it's 16:25 and I didn't eat my lunch yet, so I'll be curious later :P
[15:26]  * Laney was sweating trying to get lxd stuff to work
[15:27] <Laney> not many things left to do now ^_^
[15:27] <seb128> Laney, woot, well done! enjoy the lunch :-)
[15:28] <Laney> 1) poking the proxies in, 2) testing if ExecReload= works properly, 3) hooking up github stuff
[15:29] <Laney> 4) ssl, but can't really test that without a domain name, which requires the staging environment
[15:29] <Laney> biab
[15:53] <kenvandine> oSoMoN: i repacked the chromium snap adding the gnome-3-28-1804 content interface
[15:53] <kenvandine> and it seems to shave roughly 20% off startup time
[15:53] <kenvandine> very unscientific measurement
[15:53] <kenvandine> rm -rf ~/snap/chromium
[15:54] <kenvandine> time snap run chromium
[15:54] <kenvandine> then alt-f4 when i see the window
[15:55] <oSoMoN> kenvandine, so that's a 20% gain on first run, right? what about subsequent runs?
[15:55] <kenvandine> first run
[15:55] <kenvandine> 2nd run is hard to measure because it starts very fast
[15:55] <oSoMoN> kenvandine, also, the chromium snap launcher will copy an existing profile in ~/.config/chromium, so for measurements you should ensure there's nothing there
[15:56] <kenvandine> oSoMoN: do you know if there is an arg i can pass to exit after startup?
[15:56] <kenvandine> oSoMoN: yeah, i created a new user account
[15:56] <kenvandine> so completely empty home dir
[15:56] <oSoMoN> good
[15:58] <kenvandine> i seem to recall firefox having an arg you can pass to exit after it loads, which seems silly but it very useful for this kind of profiling :)
[15:58] <kenvandine> my reaction time to hit alt-f4 after seeing the window is included here
[15:59] <oSoMoN> kenvandine, not that I know of
[15:59] <kenvandine> the subsequent runs are under 2 seconds including my reaction time
[15:59] <kenvandine> so i'm guessing ~1 second startup
[16:00] <oSoMoN> there's the --product-version switch, but it doesn't actually perform a full initialization of the browser, so it doens
[16:00] <oSoMoN> doesn't count
[16:00] <kenvandine> yeah
[16:01] <Laney> could you use Selenium to close the window?
[16:03] <marcustomlinson> or remove some runtime that causes it crash late :)
[16:03] <Laney> you hackers
[16:05] <ahayzen[m]> instead of using $ time command  you could start a script which scans open X11 windows until Chrome appears?  like hitting xwininfo -root -tree  or something
[16:05] <kenvandine> ahayzen[m]: that's a good idea
[16:06] <Laney> in case you don't know, Selenium is a browser testing framework.
[16:07] <marcustomlinson> XD
[16:09] <marcustomlinson> It's be nice though to have a solution that works on non-browser desktop snaps too
[16:09] <kenvandine> yeah, not sure i want the overhead of running that :)
[16:09] <Laney> depends if you only ever want the most trivial tests or if actually making sure the thing works is interesting ...
[16:15] <Laney> chromium's deb had some autopkgtests that used selenium
[16:16] <Laney> one of them basically opened the browser, checked the version, and quit it
[16:16] <Laney> not sure, but I would guess that the snap doesn't have anything like that/
[16:16] <Laney> (the other one ran a copy of html5test.com)
[16:28] <oSoMoN> Laney, the snap has the same tests, they're installed in /snap/chromium/current/tests/
[16:28] <oSoMoN> but they're run headless, so no window is shown
[16:28] <oSoMoN> although it's trivial to remove the headless parameter, and they should work equally fine
[16:30] <Laney> nice!
[16:49] <oSoMoN> that'll do for today, have a good evening everyone!