[05:15] good morning [05:15] Hi didrocks [05:16] hey duflu [06:23] good morning desktoppers [06:30] sesalut oSoMoN [06:34] sesalut didrocks :) [06:35] Morning oSoMoN [06:59] Morning [07:05] goedemorgen === pstolowski|afk is now known as pstolowski [07:09] Morning Wimpress and marcustomlinson [07:16] hey Wimpress, marcustomlinson [07:18] lut didrocks [07:18] good morning desktopers [07:18] salut seb128 [07:19] en forme ? [07:19] Hi seb128 [07:19] hey duflu [07:21] ça va, et toi ? [07:25] ça va bien ! [07:26] 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] seb128, ok [07:27] thanks! [07:28] * duflu assigns self [07:28] 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] 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:34] bug 1797355 in gdm3 (Ubuntu) "Once logged in, GDM Shell process CPU usage spiking at 100%" [Undecided,Fix released] https://launchpad.net/bugs/1797355 [07:34] bug 1705369 in gdm3 (Ubuntu) "Ubuntu boots to blank screen when using Nvidia (on a desktop with an unused Intel GPU)" [High,In progress] https://launchpad.net/bugs/1705369 [07:35] duflu: I need to retry with a newer GNOME SHell, but the fix isn't applied upstream IIRC, so let's see [07:36] 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] I know. It looks to me like upstream had it right [07:36] didrocks, no problem -- I'll just block any code review waiting for you some timwe [07:36] time [07:37] duflu: I'll retry and keep you posted [07:43] bah, it's ranting week or what on discourse/forums [07:43] snaps, i386, ... [07:44] People care about things. Which means people have opinions [07:44] The good news is that it means they care about Ubuntu [07:44] 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] yo [08:08] sup Laney [08:08] hey Laney [08:13] hey duflu didrocks [08:20] seb128, complaining is very French, nothing new under the sun :) [08:23] hey Laney [08:23] oSoMoN, yeah, just wrote a long reply on discourse [08:24] Remember you can always mute a topic at the bottom of each page [08:24] 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] they look like a bunch of biter old linux men :/ [08:25] https://xkcd.com/386/ [08:25] duflu, :-) [08:26] all absolute statements are wrong [08:31] well, they are right that our gnome-calculator startup time is embarassing and we should fix that [08:32] 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] I guess this is the most visible point which starts this fud [08:33] 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] rather the "I think/I don't like/blablabla" [08:33] we transitioned those in 17.10 IIRC [08:34] they wake up 2 years later and act like it was the end of the world today [08:34] they don't wake up 2 years later :) [08:34] I've been containing those topics (and raised them here already) multiple times on the french forum [08:34] telling them we are working on the speed improvements (and we did for some) [08:35] right, that's what I'm telling [08:35] 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] they prefer to bitch in their closed group [08:35] rather than try to work with us on solution... [08:35] oh… "opening bugs/talking about it in the community forum" is a mantra I have for years with them :) [08:35] but it doesn't always succeed [08:35] thx for keeping reminding them :) [08:35] also, I think speaking in english is a high barreer [08:35] barrier* [08:36] right [08:36] well I read a bit their post [08:36] yeah, you can find something 3-4 pages for each release since 17.10 [08:36] I don't like their mentality, unsure if we can make them reconsider their approach [08:36] (the topic is archived on the "instable" forum) [08:37] their reply to any "$software has $issue" is "remove the snap, install the deb" [08:37] 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] which then goes "I've a years old version" [08:37] where they reply" try that ppa" [08:37] yeah, the ppa approach is :/ [08:37] would be more constructive to figure out the issue in the snap and get it reported/fixed [08:37] I don't think they are technical enough for this [08:37] especially when helping people on the LTS (which is where we pushed the snap) [08:38] 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] right [08:38] it's just sad the way they go about it [08:38] like one user had an issue with "retroarch" [08:39] it went through the "ah, it's because you use the snap" [08:39] they recommended installing the deb [08:39] and the user said "I've an year old version now and it still doesn't work" [08:39] so they are making thing more complicated [08:39] and not helping the users [08:39] he's off in a worth situation after they "helped" [08:39] they would better just not reply [08:39] yeah, I guess this is the issue with not technical enough people [08:40] the "use the deb" could be understandable: they are just trying to get things fixed for the use case (like sys admins) [08:40] without seeing the greeter good, but at the same time, they are not beta tester [08:40] which doesn't help us fixing issues, I agree [08:40] BUT, in cases like this [08:40] you end up in a worse situation, I agree [08:41] "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] good luck then :p [08:42] I only monitor the "unstable version" topic [08:42] and sometimes, on Monday, it's already a lot :p [08:42] I did a long reply on discourse, hopefully it's a bit usefulk [08:42] yeah, read it, sounds good to me [08:42] thx :) [08:42] k, I just close that french forum [08:42] already too much to do, I don't need more distraction [08:42] I think we should admit that the startup time issue is taking longer to fix than we thought, and this will help [08:43] right [08:43] I also think that for some reason gnome-calculator is praticularly slow [08:43] evince or gnome-calendar are faster to start than the calculator for me [08:44] also the snap exec metric shows that the desktop-launcher is not the main offender, which I though it would have been [08:44] yeah, I guess we fixed most of the issues there [08:44] but there is no obvious time consumer in the top 10 either [08:44] so, could be in snapd itself [08:44] right, maybe the compression [08:44] we need mvo&co to get to the bottom of that [08:46] yep [08:51] seb128, good answer on discourse, also thanks popey for your patience and repeated requests for actionable data [08:51] oSoMoN, thx! [08:51] oSoMoN: np [08:52] seb128: you can test if its the compression by using "snap try" on the gnome-calculator prime dir and measure this [08:53] I also like Ian Weisser's articulate replies, they contrast nicely with all those very emotional and unhelpful rants [08:53] 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] mvo, the dir is /snap//current counts as "prime"? [08:54] you'll probably need to unsquashfs the snap file to measure that reliably [08:56] seb128: sry was a bit terse, what oSoMoN said is easiest, just unsquash and snap try it [08:56] 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] seb128: snap try /path/to/unpack/dir [08:56] seb128: do you have a link? [08:57] seb128: is that hdd or ssd? [08:57] mvo, https://bugs.launchpad.net/snappy/+bug/1833004 [08:57] Launchpad bug 1833004 in Snappy "Application SNAP is slower than DEB at first launch" [Undecided,New] [08:57] 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] i get 7 second launch if i haven't used chromium for a day - so the cache is cold [08:58] https://paste.ubuntu.com/p/mN8MtCPzYW/ [08:58] on warm cache with calculator I get 0.7s vs 2s [08:58] like I already position my mouse on the X to close the dialog as it opens and click click click [08:58] faster to use alt-f4 [08:58] as soon as the window appears [08:58] k [08:58] IMO [08:58] bah, laptop flat [08:58] I need to go back to my desk [08:58] brb [08:59] ^ totally not seb pressing alt-f4 accidentally on irc [09:01] :) [09:10] and back [09:16] popey, mvo, that chromium pastebin is a bit weird btw [09:16] 8.304s /snap/chromium/750/usr/lib/chromium-browser/chrome [09:16] 4.624s /proc/self/exe [09:16] Total time: 9.529s [09:17] until now I though that the list if items were chunck of the total [09:17] Is that second line a fork() ? [09:17] Or just a bad lookup and should be grouped into the first? [09:18] the measure code may encounter something unexpected [09:20] I guess chrome does fork lots. That might be it [09:22] it does fork a lot === cpaelzer__ is now known as cpaelzer [14:22] Anyone familiar with the autopkg tests of network-manager, this Python stuff using the unittest Python module? [14:22] a bit [14:23] tkamppeter: what's the problem? [14:24] 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] tkamppeter: hmm I dunno, sorry, I certainly saw a lot of output when I ran it before [14:41] 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] No, we've certainly fixed things with it in the past [14:43] 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] Laney, tkamppeter: where is this now? (not sure if I missed some distro git packaging changes) [15:07] at first sight it smells like a subprocess issue that gets redirected [15:07] hey pitti [15:07] hey Laney and tkamppeter, wie geht's? [15:07] I think Till's working from https://code.launchpad.net/~network-manager/network-manager/+git/ubuntu/+ref/gir-nm [15:10] 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] print() in these tests should work fine [15:17] * Laney would think so too: buffering's off, stderr redirected to stdout [15:18] pitti: I'm juju 2-ifying/Mojoing autopkgtest atm :-) [15:18] RIP deploy.sh [15:18] hope you're well too [15:18] Laney: oh, poor man's juju! :) [15:18] Laney: I am, thanks! enjoying the summer [15:19] heh [15:19] we've not had one of those yet [15:20] 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] whether* [15:21] hey Trevinho [15:21] hi Laney [15:21] ¿cómo estás? [15:21] Trevinho, stop getting too much distracted by fixing all the world issues :) [15:22] seb128: you know, making better world is my mission :P, but I won't try this one indeed [15:22] :-) [15:22] Laney: all good [15:23] 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] 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] 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] not many things left to do now ^_^ [15:27] Laney, woot, well done! enjoy the lunch :-) [15:28] 1) poking the proxies in, 2) testing if ExecReload= works properly, 3) hooking up github stuff [15:29] 4) ssl, but can't really test that without a domain name, which requires the staging environment [15:29] biab [15:53] oSoMoN: i repacked the chromium snap adding the gnome-3-28-1804 content interface [15:53] and it seems to shave roughly 20% off startup time [15:53] very unscientific measurement [15:53] rm -rf ~/snap/chromium [15:54] time snap run chromium [15:54] then alt-f4 when i see the window [15:55] kenvandine, so that's a 20% gain on first run, right? what about subsequent runs? [15:55] first run [15:55] 2nd run is hard to measure because it starts very fast [15:55] 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] oSoMoN: do you know if there is an arg i can pass to exit after startup? [15:56] oSoMoN: yeah, i created a new user account [15:56] so completely empty home dir [15:56] good [15:58] 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] my reaction time to hit alt-f4 after seeing the window is included here [15:59] kenvandine, not that I know of [15:59] the subsequent runs are under 2 seconds including my reaction time [15:59] so i'm guessing ~1 second startup [16:00] there's the --product-version switch, but it doesn't actually perform a full initialization of the browser, so it doens [16:00] doesn't count [16:00] yeah [16:01] could you use Selenium to close the window? [16:03] or remove some runtime that causes it crash late :) [16:03] you hackers [16:05] 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] ahayzen[m]: that's a good idea [16:06] in case you don't know, Selenium is a browser testing framework. [16:07] XD [16:09] It's be nice though to have a solution that works on non-browser desktop snaps too [16:09] yeah, not sure i want the overhead of running that :) [16:09] depends if you only ever want the most trivial tests or if actually making sure the thing works is interesting ... [16:15] chromium's deb had some autopkgtests that used selenium [16:16] one of them basically opened the browser, checked the version, and quit it [16:16] not sure, but I would guess that the snap doesn't have anything like that/ [16:16] (the other one ran a copy of html5test.com) [16:28] Laney, the snap has the same tests, they're installed in /snap/chromium/current/tests/ [16:28] but they're run headless, so no window is shown [16:28] although it's trivial to remove the headless parameter, and they should work equally fine [16:30] nice! [16:49] that'll do for today, have a good evening everyone! === pstolowski is now known as pstolowski|afk