[07:58] <Mikerhinos> Hi all, I installed a wifi driver with the dkms/modprobe thing, but performances are worst than the default one, how can I uninstall it and get back to the default ?
[09:44] <uebera||> Hi. I just had a look at https://launchpad.net/ubuntu/+source/linux an saw that there's no 4.6 kernel to be found anymore (a couple of days ago, 4.6.0-10.12 was listed there). Has this been pulled or renamed?
[11:13] <DJones> uebera||: Might because of this http://mybroadband.co.za/news/software/176309-linux-kernel-4-6-reaches-end-of-life.html
[12:37] <uebera||> DJones: I see, thanks for the pointer! (was kind of expecting that they switch to 4.7 instead--but there's no hurry)


[07:27] <mborzecki> morning
[08:00] <mborzecki> mvo: hey
[08:01] <mborzecki> mvo: something hopefully simple: https://github.com/snapcore/snapd/pull/9945
[08:01] <mup> PR #9945: cmd/snap, boot: add debug set-boot-vars <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9945>
[08:02] <pstolowski> morning
[08:07] <zyga> hey guys
[08:07] <zyga> looong night
[08:07] <mvo> good morning mborzecki and pstolowski and zyga
[08:07] <mvo> zyga: what happend?
[08:07] <mvo> mborzecki: looking at this PR now
[08:07] <mborzecki> hey guys
[08:07] <zyga> mvo lucy had fever and wasn't sleeping very well
[08:07]  * zyga reviews that simple PR
[08:07] <mvo> zyga: oh no!
[08:08] <zyga> just tired
[08:12]  * mvo  hugs zyga
[08:13] <zyga> mborzecki https://github.com/snapcore/snapd/pull/9945#pullrequestreview-595090208
[08:13] <mup> PR #9945: cmd/snap, boot: add debug set-boot-vars <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9945>
[08:23] <mup> PR snapd#9880 closed: tests/lib/fakestore: support repair assertions too  <Needs Samuele review> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9880>
[08:31] <mborzecki> uhh slow start today
[08:43] <mup> PR snapd#9859 closed: overlord: add manager gadget refresh test <Skip spread> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9859>
[09:59] <dot-tobias> Is there a way (read: interface) to allow my snap read access to /proc/zoneinfo? The latest WPE WebKit version tries to read that file for the internal memory pressure monitor.
[10:02] <ogra> ogra@anubis:~/datengrab/devel/branches/snapd:master$ grep zoneinfo interfaces/builtin/*
[10:02] <ogra> interfaces/builtin/timezone_control.go:/usr/share/zoneinf👋     r,
[10:02] <ogra> interfaces/builtin/timezone_control.go:/usr/share/zoneinfo/**    r,
[10:02] <ogra> not to the proc node it seems
[10:04] <ogra> it'd only be a one line change (and a security review) away though
[10:04] <ogra> 🙂
[10:05] <dot-tobias> ogra: Ok thanks, wanted to make sure I didn't overlook something 😊 (and LOL at “datengrab” path 😄 ) Asking because I finally managed to get the WPE Mir Kiosk snap running on armhf, so I'm back to debugging AppArmor warnings. One of which is
[10:05] <dot-tobias> “= AppArmor = Log: apparmor="DENIED" operation="open" profile="snap.wpe-webkit-mir-kiosk.daemon" name="/proc/zoneinfo" pid=11238 comm="PressureMonitor" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /proc/zoneinfo (read) Suggestion: * adjust program to not access '@{PROC}/zoneinfo'"
[10:07] <ogra> well, i guess it makes sense that timezone-control has read access to what the kernel thinks about the timezone ...
[10:07] <dot-tobias> ogra: to be clear, /proc/zoneinfo has nothing to do with timezones (just learned that)
[10:07] <ogra> oh !
[10:07] <ogra> me too now 🙂
[10:08] <ogra> i was wondering why a "pressure monitor" would access it ...
[10:08] <dot-tobias> Yup. I guess /proc/zoneinfo may be a tad more complicated from a security viewpoint …
[10:10] <ogra> well, it seems to be very similar to /proc/vmstat ... which has read permission via system-observe
[10:10] <ogra> heh ... and browser-support ...
[12:07] <dot-tobias> ogra: I'll ask for this on the forum, any name I should @ for “all things interfaces”? Read that jdstrand has taken on a new path 😊
[12:09] <ogra> dot-tobias, try amurray or emitorino ...
[12:13] <mup> PR snapcraft#3442 opened: storeapi: reduce the amount of constants and their meaning <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3442>
[13:10] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/9943 ? i'll take care of the failur eon arch in a separate PR
[13:10] <mup> PR #9943: boot: introduce good recovery systems, provide compatibility handling <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9943>
[13:13] <mup> PR snapcraft#3435 closed: extensions: Fix Documents, Pictures etc symlinks <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3435>
[13:39] <mup> PR snapd#9949 opened: spread: disable Go modules support in environment  <Simple 😃> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9949>
[13:40] <ogra> so i have snapped thonny on the weekend to be able to play with my Pi Pico's ... on startup thonny tries to detect the attched Pico Pi's by simply running the mount command ... when plugging in a Pico it gets auto mounted as USB disk ... when thonny reads the munt feedback it gets /media/ogra/$DEVICE returned ... but it *also* gets the matching hostfs entry returned ...
[13:41] <ogra> seemingly mount orders the hostfs entry first ... so thonny tries to access this one ... but that path is not covered by the removable-media interface so everything explodes ... i have to patch the call to the mount command in thonny itself to filter all hostfs entries to make it work at all ...
[13:41] <ogra> is there a way to hide hostfs somethow on the snap side without having to patch the applications ?
[13:43] <ogra> (or should hostfs/media/ogra/$FOO be included in permitted paths for removable-media ?)
[13:54] <om26er> My snap sees `/var/lib/snapd/lib/gl` as empty, even if it's connected to the OpenGL interface. What is broken ?
[13:55] <om26er> note: this is a custom snapd build for the Yocto project
[13:55] <ogra> well, does your yocto ship nvidia drivers on the host ?
[13:55] <om26er> yes, infact its a Nvidia hardware (Xavier NX)
[13:56] <ogra> and the drivers are n the expected places ?
[13:56] <ogra> snapd only maps what it knows ... i.e. it wont map a driver from /opt to snapd/lib/gl
[13:57] <mvo> mborzecki: landed
[13:57] <om26er> It has drivers in `/usr/lib/lib` mostly
[13:57] <om26er> sorry, `/usr/lib`
[13:58] <om26er> ogra the drivers are in the right place. What is responsible for actually "mounting" those files. Maybe our installation is missing a systemd service that takes care of that stuff ?
[13:58] <ogra> on ubuntu desktops they end up in /usr/lib/nvidia-$version ...
[13:59] <ogra> i think thats snap-confine (not sure though)
[13:59] <ogra> if so, it should be doing that on the fly at app startup ... not based on any systemd service
[14:00] <mup> PR snapd#9943 closed: boot: introduce good recovery systems, provide compatibility handling <Run nested> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9943>
[14:03] <om26er> ogra I guess here is a list of libraries that are supposed to get "mounted" under that directory https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support-nvidia.c#L83 -- They definitely exist on the host but don't get mounted anywhere
[14:05] <om26er> our current "hack" is to add `/var/lib/snapd/hostfs/usr/lib` to LD_LIBRARY_PATH
[14:05] <ogra> https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support-nvidia.c#L506
[14:05] <ogra> it looks for an arch triplet subdir
[14:07] <ogra> (or alternetively for /usr/lib/nvidia)
[14:09] <om26er> ah, interesting. That's quite different from the structure that Jetson platform follows. I'll see if monkey patching snapd works for us. Then will create a  bug report or forum post for this.
[14:17] <ogra> just add bind mounts on the host side 😉
[14:17] <ogra> way faster for testing than patching snapd
[15:14]  * pstolowski doctor
[16:01]  * cachio lunch
[16:32] <pstolowski> re
[17:27] <jdstrand> amurray, emitorino: I suspect that /proc/zoneinfo (for dot-tobias) is a candidate for system-observe (man proc)
[17:45] <pedronis> pstolowski: I finished a full pass on #9930, mostly small things except for the comment for AddSequenceToUpdate
[17:45] <mup> PR #9930: asserts: pool changes for validation-sets <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9930>
[17:45] <pstolowski> pedronis: that's great, thank you!
[17:47] <pedronis> pstolowski: let me know if you have questions
[17:47] <pedronis> pstolowski: thank you
[17:50] <mup> PR snapd#9947 closed: tests: find files before using cat command when checking broadcom-asic-control interface <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9947>
[17:50] <mup> PR snapd#9948 closed: tests: use new path to find kernel.img in uc20 for arm devices <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9948>
[17:53] <mup> Bug #1606510 opened: Mechanism to create system groups <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1606510>
[17:56] <mup> Bug #1606510 changed: Mechanism to create system groups <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1606510>
[18:05] <mup> Bug #1606510 opened: Mechanism to create system groups <lxd> <Snappy:Confirmed> <https://launchpad.net/bugs/1606510>
[18:33] <mup> PR snapcraft#3443 opened: extensions: add conditional for GNOME Makefile using bindtextdomain <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3443>
[20:00] <tianon> is there a ~easy way to run an i386 snapcraft build on an amd64 environment?  (maybe some clever way to change the LXD image that gets used?)
[20:01] <tianon> (I found --target-arch which doesn't work with Multipass or LXD and the experimental version that only works with core20 which thus can't work with i386 :D)
[20:02] <tianon> my "best" thought so far is to convince snapcraft to run in "host" mode inside a Docker container, but I figure there's gotta be a better way (especially since my build uses other snaps, so I don't think the Docker method is even gonna work)
[20:17] <tianon> I guess I could implement the "snapcraft via LXD the hard way" steps, but that sounds really tedious and error-prone for what I was hoping could just be an easy "smoke test" in GitHub actions O:)
[20:34] <ijohnson> tianon: one way I can think of for you to try is to manually start a lxd container with the right i386 arch that has the same name that snapcraft would create if it was managing it, then try running SNAPCRAFT_BUILD_ENVIRONMENT=lxd snapcraft (or whatever the env var is), and see what falls out
[20:34] <ijohnson> I don't know if that would work or not tbh, I have done that before to customize some bits in the container OOB from snapcraft but always with the same arch container
[20:34] <tianon> ah hahaha, I like it; I'll see what I can do
[20:46] <mup> PR snapd#9950 opened: tests: fix for preseed test on 21.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9950>
[22:21] <mup> PR snapd#9951 opened: tests/regression/lp-1910456: cleanup the /snap symlink when done  <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9951>
[23:04] <mup> PR snapcraft#3444 opened: snap: explicitly add setuptools-rust package to python-packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3444>
[23:29] <om26er> how to run snapd in "verbose" mode ? I need to checks its errors and warnings
[23:29] <ijohnson> om26er: SNAPD_DEBUG=1 in /etc/environment
[23:29] <ijohnson> also for snap commands like snap run there is SNAP_CONFINE_DEBUG=1
[23:31] <om26er> Thanks, both would do :+1:
[23:52] <mup> PR snapd#9949 closed: spread: disable Go modules support in environment  <Simple 😃> <⚠ Critical> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9949>
[23:56] <amurray> jdstrand: ah thanks for the ping - yeah zoneinfo looks pretty similar to vmstat which is already in system-observe so this feels like a good fit


[08:19] <aleb> Hi, I understand UbuntuStudio is a Ubuntu version, then you guys are busy more with Ubuntu than UbuntuStudio? Or is there a lot of work for UbuntuStudio specifically (what)? I'm just curious.