| didrocks | good morning | 05:15 |
|---|---|---|
| duflu | Hi didrocks | 05:15 |
| didrocks | hey duflu | 05:16 |
| oSoMoN | good morning desktoppers | 06:23 |
| didrocks | sesalut oSoMoN | 06:30 |
| oSoMoN | sesalut didrocks :) | 06:34 |
| duflu | Morning oSoMoN | 06:35 |
| Wimpress | Morning | 06:59 |
| marcustomlinson | goedemorgen | 07:05 |
| === pstolowski|afk is now known as pstolowski | ||
| duflu | Morning Wimpress and marcustomlinson | 07:09 |
| didrocks | hey Wimpress, marcustomlinson | 07:16 |
| seb128 | lut didrocks | 07:18 |
| seb128 | good morning desktopers | 07:18 |
| didrocks | salut seb128 | 07:18 |
| seb128 | en forme ? | 07:19 |
| duflu | Hi seb128 | 07:19 |
| seb128 | hey duflu | 07:19 |
| didrocks | ça va, et toi ? | 07:21 |
| seb128 | ça va bien ! | 07:25 |
| 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:26 |
| duflu | seb128, ok | 07:27 |
| seb128 | thanks! | 07:27 |
| * 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:28 |
| 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:34 |
| ubot5 | 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 |
| ubot5 | 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:34 |
| didrocks | duflu: I need to retry with a newer GNOME SHell, but the fix isn't applied upstream IIRC, so let's see | 07:35 |
| 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:36 |
| didrocks | duflu: I'll retry and keep you posted | 07:37 |
| seb128 | bah, it's ranting week or what on discourse/forums | 07:43 |
| seb128 | snaps, i386, ... | 07:43 |
| 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... | 07:44 |
| Laney | yo | 08:02 |
| duflu | sup Laney | 08:08 |
| didrocks | hey Laney | 08:08 |
| Laney | hey duflu didrocks | 08:13 |
| oSoMoN | seb128, complaining is very French, nothing new under the sun :) | 08:20 |
| seb128 | hey Laney | 08:23 |
| seb128 | oSoMoN, yeah, just wrote a long reply on discourse | 08:23 |
| 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:24 |
| seb128 | they look like a bunch of biter old linux men :/ | 08:25 |
| duflu | https://xkcd.com/386/ | 08:25 |
| seb128 | duflu, :-) | 08:25 |
| marcustomlinson | all absolute statements are wrong | 08:26 |
| seb128 | well, they are right that our gnome-calculator startup time is embarassing and we should fix that | 08:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| didrocks | yep | 08:46 |
| 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:51 |
| mvo | seb128: you can test if its the compression by using "snap try" on the gnome-calculator prime dir and measure this | 08:52 |
| 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:53 |
| oSoMoN | you'll probably need to unsquashfs the snap file to measure that reliably | 08:54 |
| 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:56 |
| mvo | seb128: is that hdd or ssd? | 08:57 |
| seb128 | mvo, https://bugs.launchpad.net/snappy/+bug/1833004 | 08:57 |
| ubot5 | Launchpad bug 1833004 in Snappy "Application SNAP is slower than DEB at first launch" [Undecided,New] | 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:57 |
| 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:58 |
| popey | ^ totally not seb pressing alt-f4 accidentally on irc | 08:59 |
| oSoMoN | :) | 09:01 |
| seb128 | and back | 09:10 |
| 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:16 |
| 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:17 |
| mvo | the measure code may encounter something unexpected | 09:18 |
| duflu | I guess chrome does fork lots. That might be it | 09:20 |
| oSoMoN | it does fork a lot | 09:22 |
| === cpaelzer__ is now known as cpaelzer | ||
| tkamppeter | Anyone familiar with the autopkg tests of network-manager, this Python stuff using the unittest Python module? | 14:22 |
| Laney | a bit | 14:22 |
| Laney | tkamppeter: what's the problem? | 14:23 |
| 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:24 |
| Laney | tkamppeter: hmm I dunno, sorry, I certainly saw a lot of output when I ran it before | 14:35 |
| 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:41 |
| Laney | No, we've certainly fixed things with it in the past | 14:42 |
| 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. | 14:43 |
| pitti | Laney, tkamppeter: where is this now? (not sure if I missed some distro git packaging changes) | 15:06 |
| 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:07 |
| 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:10 |
| pitti | print() in these tests should work fine | 15:11 |
| * Laney would think so too: buffering's off, stderr redirected to stdout | 15:17 | |
| 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:18 |
| Laney | heh | 15:19 |
| Laney | we've not had one of those yet | 15:19 |
| Laney | http://[2001:ba8:1f1:d03:216:3eff:fef0:f2f0]/running <- first lxd/armhf test is a-go | 15:20 |
| * 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 | |
| Laney | not many things left to do now ^_^ | 15:27 |
| seb128 | Laney, woot, well done! enjoy the lunch :-) | 15:27 |
| Laney | 1) poking the proxies in, 2) testing if ExecReload= works properly, 3) hooking up github stuff | 15:28 |
| Laney | 4) ssl, but can't really test that without a domain name, which requires the staging environment | 15:29 |
| Laney | biab | 15:29 |
| 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:53 |
| kenvandine | time snap run chromium | 15:54 |
| kenvandine | then alt-f4 when i see the window | 15:54 |
| 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:55 |
| 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:56 |
| 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:58 |
| 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 | 15:59 |
| 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:00 |
| Laney | could you use Selenium to close the window? | 16:01 |
| marcustomlinson | or remove some runtime that causes it crash late :) | 16:03 |
| Laney | you hackers | 16:03 |
| 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:05 |
| Laney | in case you don't know, Selenium is a browser testing framework. | 16:06 |
| marcustomlinson | XD | 16:07 |
| 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:09 |
| Laney | chromium's deb had some autopkgtests that used selenium | 16:15 |
| 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:16 |
| 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:28 |
| Laney | nice! | 16:30 |
| oSoMoN | that'll do for today, have a good evening everyone! | 16:49 |
| === pstolowski is now known as pstolowski|afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!