[01:52] <mup> PR snapd#9805 closed: interfaces: add an optional mount-host-font-cache plug attribute to the desktop interface <Needs Samuele review> <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/9805>
[06:06] <zyga> good morning
[06:58] <mborzecki> morning
[06:58] <mup> PR snapd#9894 closed: snap/info.go: add doc-comment for SortServices <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9894>
[07:06] <zyga> hey mborzecki
[07:06] <mborzecki> zyga: hey
[08:06] <pstolowski> morning
[08:06] <zyga> o/
[08:42] <zyga> hey pedronis, mvo
[08:42] <pedronis> hi
[08:45] <mvo> hey zyga
[09:13] <mup> Bug #1909033 changed: QFileDialog calls portal when ShowDirsOnly is set but not available <Snappy:Invalid> <https://launchpad.net/bugs/1909033>
[10:38] <pedronis> pstolowski: I left some small further comments on the AtSequence PR,  I think it's ready for 2nd reviews as well
[10:41] <pstolowski> pedronis: great, thank you
[10:59] <ogra> zyga, i do have in fact two picos here, but havent played with them yet missing networking is kinda limiting the use cases
[11:00] <ogra> i'll surely snap up the userspace tools for them 🙂
[11:00] <ogra> (if nobody else does it at lest)
[11:00] <ogra> *least
[11:18] <zyga> ogra I have an idea on how to use them
[11:18] <zyga> maybe something others may find useful as well
[11:18] <zyga> I want to use them as pre-made signal generators
[11:18] <zyga> e.g. a pi-co that does specific i2c transfers all the time
[11:18] <zyga> then those can just be connected to a test board and used in automated testing
[11:19] <zyga> I got a bag to see how far I can go with this
[11:19] <zyga> some of the people I de-facto direct now may help with this, but that's still a few weeks away
[11:54] <pstolowski> pedronis: thanks for the review; i've implemented error-list handling for sequences in #9893, obviously landing at-sequence will help reduce the diff
[11:54] <mup> PR #9893: store: support validation sets with fetch-assertions action <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9893>
[11:54] <mup> PR snapd#9875 closed: gadget: use ResolvedSource in MountedFilesystemWriter <Run nested> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9875>
[11:58] <mvo> pedronis: feedback on 9859 would be great
[11:59] <mvo> pedronis: this will help me with the next step for the kernel-dtb refreshes (the next test will build on this one)
[11:59] <mup> PR snapd#9886 closed: gadget: cleanup MountedFilesystem{Writer,Updater} <Run nested> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9886>
[12:00] <mvo> pedronis: not super ugent as I need to write some more code first but wanted to mention it :)
[12:05] <mup> PR snapd#9898 opened: gadget: fix documentation/typos <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9898>
[12:11] <pstolowski> #9892 needs a 2nd review and is a small, simple and pleasant warm-up for asserts/validation-sets ;)
[12:11] <mup> PR #9892: asserts: introduce AtSequence <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9892>
[12:12] <pstolowski> and landing it will help with followup PRs ;)
[12:13] <pedronis> mvo: ok, I thought 9859 maybe doesn't need me
[12:13] <pedronis> mvo: I mean, it wasn't clear it needed my review
[12:19] <mvo> pedronis: maybe not, there was a bit of discussion about the re-refresh task and settle not converging, maybe a word from you here would be helpful :)
[12:19] <pedronis> mvo: ok, I'll try to look in a bit
[12:20] <pedronis> mvo: I wasn't aware I was blocking things there
[12:22] <mvo> pedronis: no problem, not really blocking, thanks a lot!
[12:23] <pstolowski> bbiab
[12:30] <mup> PR snapd#9899 opened: gadget: improve error handling around resolving content sources <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9899>
[13:07] <ogra> zyga, cool idea !
[13:07] <ogra> (sorry, had a meeting)
[13:07] <zyga> ogra, no worries :)
[13:07] <zyga> ogra I will definitely share the code once my boards arrive
[13:07] <ogra> awesome !
[13:07] <zyga> but they are on the way now, I may have them for weekend
[13:07] <zyga> ogra I want to explore an idea where you can essentially just put a sticker on them
[13:08] <zyga> or maybe configure them with something simple
[13:08] <zyga> and get the desired signal coming out
[13:08] <zyga> for easy-to-use test lab support
[13:11] <ogra> speaking of test labs ...
[13:11]  * ogra just upgraded the guts of his desktop 
[13:11] <ogra> ogra@anubis:~$ grep -c ^processor /proc/cpuinfo
[13:11] <ogra> 12
[13:11] <ogra> ogra@anubis:~$ LANG=C free -m | grep ^Mem
[13:11] <ogra> Mem:          32076        4299       22920         423        4855       26682
[13:11] <ogra> ogra@anubis:~$ sudo hdparm -t /dev/nvme0n1p1 | grep buffered
[13:11] <ogra>  Timing buffered disk reads: 6910 MB in  3.00 seconds = 2303.21 MB/sec
[13:11] <ogra> 😄
[13:12] <ogra> now all my fast Pi's feel slow again 😞
[13:13] <zyga> ogra what did you take?
[13:15] <ogra> i actually only wanted to have more ram, but the board was too old to go up to 32G ... this is a new asus board (PRIME Z490M-PLUS) , 32G corsair ram (samsung chips), an i5-10600K and a WD black NVME
[13:16] <ogra> should be sufficient for the next 5y ... and allows more ram later
[13:22] <zyga> ogra oh, an intel chip
[13:22] <zyga> why did you go with intel?
[13:23] <ogra> because i had intel already, i didnt want to change anything witht he installed system or tinker with software in any way
[13:24] <zyga> I see, well, that's a refresh for sure :)
[13:24] <ogra> yeah
[13:24] <zyga> I got a little bit more ram, mainly for VMs
[13:25] <ogra> i rarely run VMs but more disk for more lxd containers is really helpful ... especially since the virtual disk that lxd uses doesnt actually shrink even if you remove containers
[13:28] <zyga> ogra I think you can trim it somehow
[13:29] <ogra> yeah, probably ... i knoe you can grow it but shrinking is hairy
[13:29] <ogra> *know
[13:29] <zyga> note that it's not really shrinking
[13:29] <zyga> as in making the virtual size any different
[13:29] <zyga> just dropping blocks that are unused
[13:29] <zyga> like on SSDs
[13:31] <ogra> well, the still occupied blocks are the issue though ...
[13:37] <pedronis> mvo: I commented there, hope what I wrote makes sense
[13:43] <mvo> thanks pedronis
[13:59] <ogra> xnox, https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1914608
[13:59] <mup> Bug #1914608: no console during boot on UC20 <linux-raspi (Ubuntu):New> <https://launchpad.net/bugs/1914608>
[14:01] <xnox> ogra:  tah.
[14:05] <ogra> xnox, btw, journalctl -b timestamps on a UC20 pi look really funny (starts with Nov19, jumps to Apr. 1st and once network is up to the actual time 🙂 ) ... i thought systemd uses its own build stamp to set it, why do initrd and rootfs times differ so much
[14:05] <mup> PR snapd#9867 closed: overlord/devicestate: task for updating boot configs, spread test <Run nested> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9867>
[14:05] <mup> PR snapd#9898 closed: gadget: fix documentation/typos <Simple 😃> <Skip spread> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9898>
[14:06] <ogra> xnox, i'd have expected the build stamp to be roughly the same in initrd and rootfs
[14:07] <ogra> (just curiosity, not a complaint ...)
[14:32] <ijohnson> ogra: there's an outstanding bug with focal systemd in that the Nov19 date from the initrd is supposed to be bumped on each systemd update, but it's not w/o an sru
[14:32] <ogra> ah
[14:33]  * ogra forgot SRUs ... 
[14:33] <ijohnson> ogra: https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969
[14:33] <mup> Bug #1878969: time-epoch never changes in SRUs <ubuntu-core-initramfs:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Focal):New> <https://launchpad.net/bugs/1878969>
[14:33] <ogra> yeah
[14:34] <xnox> horum =/
[14:35] <ogra> i actually thought it uses a timestamp from a binary ... funny it uses NEWS
[14:35] <xnox> well, the fix is to use the timestamp from the debian/changelog top entry.
[14:35] <xnox> (as that's what deb builds set for reproducible builds)
[14:35] <ogra> yeah, good as well
[14:36] <ogra> weird upstream decision ...
[15:23] <ijohnson> huh, so in a UC20 VM, `blockdev --getbsz /dev/vda` returns 4096
[15:33] <ijohnson> aha I should be using `--getpbsz` instead of `--getbsz`
[15:35] <xnox> ideally we should use 4k everywhere, if at all possible....
[15:35] <xnox> or do we get the totals wrong because of that?
[15:36] <jschwart> hi all, I accidentally asked this in #snapcraft already, but I'm looking for a solution to provide NFS access to something I installed through snap
[15:36] <ijohnson> xnox: it was a bug in my code, nothing for you to worry about
[15:37] <jschwart> I currently use autofs to access my NAS through /net
[15:37] <jschwart> can I provide a snap access to that?
[15:56] <ijohnson> mborzecki: do you think you will be able to take a look at #9889 today or tomorrow? would be good to have that in 2.49
[15:56] <mup> PR #9889: cmd/snap-bootstrap/initramfs-mounts: write realistic modeenv for recover+install <Needs Samuele review> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9889>
[16:42] <benfrancis> Does anyone know if there a snap I can install which includes the "xhost" utility? I think I need to run xhost to give the snap_daemon user access to an X11 session started as root, but xhost doesn't appear to be included on Ubuntu Core by default.
[16:48] <ijohnson> hi benfrancis 👋
[16:49] <ijohnson> I don't think there is one, if I understand the context of your request though, I think you probably want to bundle xhost in your snap and use xhost to grant snap_daemon user access to the X11 session before dropping to snap_daemon, in the same wrapper script you have been adding other things
[16:49] <benfrancis> ijohnson: Yes, exactly
[16:50] <benfrancis> ijohnson: I suspect this is the source of the "No protocol specified" error I'm seeing before my Electron app segfaults.
[16:50] <benfrancis> ijohnson: (hi)
[16:50] <ijohnson> benfrancis: it seems on bionic the package you need for `xhost` is `x11-xserver-utils`, so add that to your stage-packages and then you should be able to use xhost to configure access for snap_daemon
[16:51] <ijohnson> yeah that would make sense
[16:52] <benfrancis> ijohnson: Perfect, thanks
[16:52] <ijohnson> I admit I don't actually know what command you want to try with xhost though
[16:53] <benfrancis> I'm going to try "xhost si:localuser:snap_daemon"
[16:53] <ijohnson> seems logical to me :-)
[18:29] <cjp256> jschwart: if the snap in question has access to home directory, perhaps you can bind mount /net somewhere in your home dir? or if it has removable-media, into /media?
[18:48] <mborzecki> re
[18:48] <mborzecki> ijohnson: let me take a quick look
[19:08] <jschwart> cjp256: yeah that could work, I guess I have to do the bind mount as root though?
[19:10] <cjp256> I'd expect so, unless you have a `user` mount option in your fstab to mount it without root.
[19:26] <mup> PR snapd#9900 opened: o/configstate,o/devicestate:  introduce devicestate.EarlyConfig implemented by configstate.EarlyConfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/9900>
[19:31] <mup> PR snapd#9901 opened: o/devicestate,many: introduce DeviceManager.preloadGadget for EarlyConfig <Run nested> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9901>
[19:32] <jschwart> so I cannot mount anything at the system level below a snap's /snap directory, because that's a read-only filesystem and I have to use root to bind mount a network path inside ~user/snap/.....
[19:32] <jschwart> that seems quite awkward, hopefully there will be a cleaner solution in the future
[20:38] <ogra> jschwart, there is also /var/snap/<snapname>/common|current if you look after mounting it on a more systemish level
[20:47] <ogra> (in fact i think only "common" since "current" is a symlink that can dynamically change
[20:47] <ogra> )
[21:49] <jschwart> ogra: ah that would be a lot better yeah!!
[21:56] <jschwart> ogra: yeah that is perfect really, just tried it and it works great, thanks a lot!!
[21:56] <ogra> 😄
[22:07] <mup> PR snapd#9902 opened: HACKING.md: explain how to run UC20 spread tests with QEMU <Documentation> <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9902>
[22:47] <mup> PR snapd#9903 opened: tests/lib/prepare.sh: add another console= to the reflash magic grub entry <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9903>