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