=== ecloud is now known as ecloud_wfh === pstolowski|afk is now known as pstolowski [07:38] gooood morning desktopers [07:38] Salut seb128 [07:39] lut jibel, en forme ? tjs pas trouvé de release blockers? ;) [07:39] seb128, en forme, et pas de release blocker. [07:39] :) [07:40] Morning seb128 and jibel [07:40] I'm wondering if we should change the swap to use a partition instead of a zvol since that's the main feedback from the short experiment [07:40] hey duflu, how are you today? [07:40] not a big change but lot of retest [07:40] seb128, average I think. You? [07:40] is there a bug with the details? [07:40] hi rest of the world [07:41] 👋🌏 [07:41] seb128, https://bugs.launchpad.net/bugs/1847628 it's a known problem upstream under high memory pressure [07:41] Launchpad bug 1847628 in ubiquity (Ubuntu) "When using swap in ZFS, system stops when you start using swap" [High,Incomplete] [07:41] which on desktop summarizes to using gnome-shell ;) [07:41] j/k [07:41] lol [07:42] That's odd. RSS really should default to and stick below 300MB [07:42] for gnome-shell [07:43] GNOME isn't usable in a 2G vm [07:43] I was kidding about gnome-shell but if you have eg 8G of RAM it's quickly used with the shell, a webbrowser and a couple of apps [07:43] even with 2.6 [07:43] and I mean standard desktop, like I couldn't get an install done in a such vm with ubiquity only [07:43] the shell would freeze/hang before the end of the install [07:44] I think it's the web browser mostly. Even a leaky gnome-shell should stay in the MB, not GB [07:44] you cannot start a live session with 2G [07:44] But there might be new leaks? [07:45] duflu, start a live session with 2G in a VM, start ubiquity and you'll see that OOM killer is triggered preetty quickly [07:45] no webbrowser needed [07:46] anyway the minimal requirement is 4GB for a reason [07:46] it's not the shell only, just GNOME [07:46] right sorry [07:46] like gnome-software as a service [07:46] eds [07:46] etc [07:46] Make sure you're not looking at VSIZE [07:46] Im' not looking at anytthing [07:47] me neither, it is just that the system is not usable with 2GB [07:47] I've a virtualbox vm with a 2G RAM allocation [07:47] which used to work fine at the unity time and is getting worth every cycle [07:47] I could get through the 19.10 install with it [07:48] It should be clear which process(es) are to blame so if that's known then bugs should be created [07:48] couldn(t* [07:48] I should have a look to that yeah [07:49] * duflu looks [07:50] good morning desktoppers [07:50] lut oSoMoN [07:50] this tool was very useful to analyze memory maps https://www.eqware.net/articles/CapturingProcessMemoryUsageUnderLinux/index.html [07:50] My live session uses 729MB of RAM [07:50] salut seb128 [07:51] no sure it still works on recent ubuntu [07:51] Morning oSoMoN [07:51] hey duflu [07:51] salut jibel [07:51] and zero swap [07:51] hola oSoMoN [07:51] duflu, unsure what's going on then why it hangs in a 2G env [07:51] you czn try to see if you get the same experience? [07:51] Admittedly 200MB is gnome-shell [07:51] duflu, where do you get this number from? [07:52] jibel, ps command RSS [07:52] or 'free -m' [07:53] duflu, you cannot use RSS directly to get the amount of memory used by a process [07:54] jibel, it's the most accurate measure available other than digging deeper in /proc/PID/status [07:54] for me gnome-shell uses 290MB of RSS [07:54] Yes you can [07:54] Well close enough [07:54] but with all the libs it loads it uses 3.3GB [07:54] (output of pmap) [07:54] That's a beginner's mistake... it's not real memory. Ignore VSZ [07:55] Although it is a mistake our users keep making so I'm mindful of it [07:55] sorry for being a beginner in memory analysis :) [07:56] I'm out for now, minimum requirement is 4GB :) [07:56] virtual memory is not real memory it's just address space requiring no RAM or swap [07:56] Though the real memory usage is within that [07:57] jibel, the best measure I can suggest is the VmSize value in /proc/PID/status [07:58] So yeah for me that is 300MB [07:59] Oops [07:59] I mean VmRSS, plus VmLib etc [07:59] I made the beginners' mistake [08:00] Though I am assume VmLib includes shared memory and that might also be wrong [08:01] assuming [08:01] Anyway, providing the 'free' command tells you you're not using swap then you can just measure processes by the RSS value [08:07] bbl, I've an appointement at 10:30 (souldn't be long) and then going to the hackfest [08:12] moin [08:12] Morning Laney [08:19] moin Laney [08:19] good morning tkamppeter [08:35] Morning o/ [08:41] hey Wimpress [08:44] Morning Wimpress [09:31] seb128, I am enjoying eoan on the Pi [09:31] In the end it only needs power and ethernet [09:31] duflu, ah, nice, did you resolve the password problem? [09:32] seb128, yeah I hacked one in. But our policy for the live image is apparently that you need to boot first with ethernet to be able to change it normally. I did not, so it got confused and then reset my password [09:32] duflu, don't spend weeks on the libffi issue though, if it's too challenging maybe we can plan B to build without neon on armhf or something? [09:32] duflu, ah, I see [09:32] seb128, it's fine. I plan to finish today/tomorrow [09:32] k:) [09:33] seb128, I just wish I found out that the pi3 image supports Pi 4 earlier [09:33] The Pi 3 is limited to 20MB/s on the SD card :( [09:33] it's probably something we should write about [09:33] discourse or blog [09:34] so users who google find that they can (easily?) get ubuntu working on it and how [09:34] I think I found out from the 19.10 release notes. It's not on the download page [09:35] https://wiki.ubuntu.com/EoanErmine/ReleaseNotes#Raspberry_Pi_.2B2DzfUw- [09:36] seb128, also many people have blogged about Pi SD card performance already [09:40] duflu, I doubt that people will end up on the release note section if they google for "ubuntu pi 4", I still think a blog post or discourse would give us a more reliable/visible page [09:41] seb128, I would just change "For Raspberry Pi 3 boards." on http://cdimage.ubuntu.com/releases/19.10/beta/ [09:42] ah, willcooke just when you need him :) [09:42] Of course that's not the final URL [09:42] willcooke, hey! how do you feel today? better? [09:42] Morning willcooke [09:42] going to [09:42] going to/already in London? [09:42] just arrived. Better than yesterday, but not 100% [09:44] willcooke, hopefully you are fixed tomorrow for the release beers :) [09:44] :) [09:44] anything I should be testing on the haunted laptop? [09:44] willcooke, duflu was mentioning that http://cdimage.ubuntu.com/releases/19.10/beta/ should perhaps mention that the raspberry image also work on the pi4? [09:44] it does mention the 3 version only atm [09:44] As the release notes already do/does [09:45] I've just this second seen that the webinar that Prod. Man. are running will include that topic [09:45] also I was suggesting that a blog on the topic might give us some visibility to users who have a pi4 and google for what to do with it [09:45] Similarly the common kernel is called raspi2 :/ [09:46] So the image is called pi3, it works on Pi 4 and the kernel is called pi2 [09:46] that's probably more busy work to change for little benefit [09:47] Yes, you still need to be a hacker regardless [09:48] seb128, duflu - sil2100 will add it [09:48] thx [09:48] cool [10:39] duflu: yeah, we wanted to actually rename the raspi3 subarch for the images to raspi, but we backtracked it as we weren't sure if we can support the pi4 with the same image [10:39] And we only landed the full support recently, so we deemed it too late to do the whole rename dance - this should happen for 20.04 tho [10:53] sil2100, thanks [11:15] seb128, OK that's enough of my life spent on that... https://salsa.debian.org/science-team/fftw3/merge_requests/1 [11:17] duflu, great, thx! [11:19] seb128, it got to Arm assembler being generated from C macros and that's where I stopped. Not sensible for me to learn the intent there. Just avoid the bug location [11:19] It might be gcc's fault but other bugs in fftw3 prevent me from verifying :S [11:20] yeah, I think the solution makes sense, no point spending tons of efforts trying to fix neon on armhf [11:20] Also, there's an upstream bug suggesting Neon is slower than non-Neon [11:24] we're looking to do a re-spin to fix the nvidia:i386 stuff btw [11:24] don't know if anybody said yet [11:25] no [11:25] Laney, did anyone talk about the zfs/swap thing jibel asked about earlier? [11:25] dunno [11:26] not hearing anything about it [11:26] can you bring the topic? [11:26] what are you after? [11:26] https://bugs.launchpad.net/bugs/1847628 [11:26] Launchpad bug 1847628 in ubiquity (Ubuntu) "When using swap in ZFS, system stops when you start using swap" [High,Incomplete] [11:26] I mean - you want someone here to fix it or what? [11:27] Laney: nice. I just added the nvidia thing to my release notes, so I can get ready to remove it again :) [11:27] if I understood jibel correclty he seemed to point out something that we might want to change/fix before release [11:27] or if we respin [11:28] I'm ready to test nvidia when new isos drop. [11:28] now I don't understand the topic enough to know if that's something we should or how important that is [11:28] Laney, basically I would welcome other people to have a look and state if they think it's a release problem in their opinion [11:28] and if it is then we need to figure out what we do I guess? [11:29] ok [11:29] infinity: please read the above [11:30] thx [11:32] seb128: If there's a fix in the pipeline that's clear and reviewable, I'm all for reviewing it and letting it in, if not, release note it. It's an experimental feature, we don't expect perfection. [11:32] jibel, ^ do you have a candidate fix? [11:40] Laney, infinity, if I upload an ubuntu-settings change to follow https://gitlab.gnome.org/GNOME/gcr/commit/b841b1f29ae6 can we still get that in or should I rather turn it into a SRU? [11:41] well, gcr needs updating as well [11:42] just let me know if the upload needs to include a bug reference if it's turned into a SRU [11:49] seb128, no I don't [11:49] jibel, would it be easy to do the change or do you think we should just aim for release note at this point? [11:50] as I said earlier it's a lot of test because it changes the partition table. I think we should release note it [11:51] then release the fix first thing when 20.04 opens [11:52] k, what you wrote earlier sounded like you were pondering if that was worth going through the new round of testing [11:52] like you were not decided it was not worth it [11:52] seems like you are now :) [11:53] yeah while working on the fix I realize it's a significant change and didrock is not here today to do a review [11:54] Laney, infinity, sorry, we had the gcr change (I did backport it some weeks ago), but I overlooked at the time that we had a settings overriding which is basically undoing it :/ [11:54] it's a schemas change which is used by one app afaik so should be pretty safe [11:54] I've a feeling London left for lunch :p [11:56] Laney, infinity, k, I uploaded ubuntu-settings, up to you to approve/reject [12:06] seb128: thanks [12:07] didn't but we are pair programming atm, not got full attention on irc [12:12] k [12:48] jibel, added to release notes known issues re: swap & zfs [12:48] feel free to edit [12:48] *I added [13:10] willcooke, thanks [14:49] good morning desktopers [14:50] good morning hellsworth ! [14:50] how's it going oSoMoN ? [14:51] I'm doing alright, how are you yourself? [14:51] oh i'm ok. kinda tired but nothing coffee can't fix :) [14:51] heh [15:26] ha... i think the swap on zfs bug has been what's been annoying me [15:26] i was trying to figure out what was causing the hangs yesterday, but couldn't find anything interesting in the logs [15:27] going to teach you to real stop opting in for experimental filesystems ;) [15:29] seb128: yeah... i said i wasn't going to do it... but then my ssd failed and had to do a fresh install [15:29] which perfectly alligned with the experimental feature being enabled and i caved [15:29] :) [15:29] <- will never learn [15:33] i guess reducing swapiness would help, i was using small bits of swap even though i had plenty of free memory [15:34] if no one use experimental features, we don't find bugs and they stay experimental forever [15:34] so thanks kenvandine for being so brave [15:35] indeed [15:35] and i am happy now that i know what was causing it [15:47] is there a way i can have more than one snapcraft build going on the same system at the same time? like if i have two gnome-sdk clones on my system and i want to build them at the same time, that doesn't work (maybe because the multipass vm would have the same name). [15:48] if i use lxd, does that enable me to run parallel builds of the same name? [15:49] being confined to one build at a time on a system, i have all 4 computers at home running builds but would be more convenient if i could do it all on one system [15:50] if it is one build per system, then i could add a couple of rpis to my build cluster.. does snapcraft and multipass work on arm64? [15:50] that's maybe a stretch.. [16:22] hellsworth: ask in #snapcraft [16:22] it would be handle to be able to name the multipass instance [16:22] or rather override the default name [16:32] thanks kenvandine === pstolowski is now known as pstolowski|afk [18:03] Evening hellsworth o/ [18:03] what's up :) [18:08] ok lunchtime!! [18:09] YAY LUNCH [18:46] * kenvandine needs lunch [22:28] https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1848394 [22:28] Launchpad bug 1848394 in software-properties (Ubuntu) "software properteries shows "open source" for proprietary nvidia driver" [Undecided,New] [22:28] anyone got an nvidia 19.10 machine to confirm that? [22:32] Wimpress: ^^ [22:32] pretty sure Martin is going to test the nvidia install anyway for the steam/i386 bug [22:49] Yep, I will test an install on nvidia now. [23:11] popey you using the graphics-driver PPA? [23:15] RikMills popey I can't reproduce https://pad.lv/1848394 [23:15] Launchpad bug 1848394 in software-properties (Ubuntu) "software properteries shows "open source" for proprietary nvidia driver" [Undecided,New] [23:17] IIRC the graphics-driver PPA shows up as open source because it is not in restricted, not sure if this is definitely that issue though [23:20] Wimpress: popey yup, they have at least one package from a system76 PPA - LP-PPA-system76-pop, I'm guessing that is it