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> | 01:52 |
---|---|---|
zyga | good morning | 06:06 |
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> | 06:58 |
zyga | hey mborzecki | 07:06 |
mborzecki | zyga: hey | 07:06 |
pstolowski | morning | 08:06 |
zyga | o/ | 08:06 |
zyga | hey pedronis, mvo | 08:42 |
pedronis | hi | 08:42 |
mvo | hey zyga | 08:45 |
mup | Bug #1909033 changed: QFileDialog calls portal when ShowDirsOnly is set but not available <Snappy:Invalid> <https://launchpad.net/bugs/1909033> | 09:13 |
pedronis | pstolowski: I left some small further comments on the AtSequence PR, I think it's ready for 2nd reviews as well | 10:38 |
pstolowski | pedronis: great, thank you | 10:41 |
ogra | zyga, i do have in fact two picos here, but havent played with them yet missing networking is kinda limiting the use cases | 10:59 |
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:00 |
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:18 |
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:19 |
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:54 |
mvo | pedronis: feedback on 9859 would be great | 11:58 |
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> | 11:59 |
mvo | pedronis: not super ugent as I need to write some more code first but wanted to mention it :) | 12:00 |
mup | PR snapd#9898 opened: gadget: fix documentation/typos <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9898> | 12:05 |
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:11 |
pstolowski | and landing it will help with followup PRs ;) | 12:12 |
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:13 |
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:19 |
pedronis | mvo: I wasn't aware I was blocking things there | 12:20 |
mvo | pedronis: no problem, not really blocking, thanks a lot! | 12:22 |
pstolowski | bbiab | 12:23 |
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> | 12:30 |
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:07 |
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:08 |
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:11 |
ogra | now all my fast Pi's feel slow again 😞 | 13:12 |
zyga | ogra what did you take? | 13:13 |
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:15 |
ogra | should be sufficient for the next 5y ... and allows more ram later | 13:16 |
zyga | ogra oh, an intel chip | 13:22 |
zyga | why did you go with intel? | 13:22 |
ogra | because i had intel already, i didnt want to change anything witht he installed system or tinker with software in any way | 13:23 |
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:24 |
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:25 |
zyga | ogra I think you can trim it somehow | 13:28 |
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:29 |
ogra | well, the still occupied blocks are the issue though ... | 13:31 |
pedronis | mvo: I commented there, hope what I wrote makes sense | 13:37 |
mvo | thanks pedronis | 13:43 |
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> | 13:59 |
xnox | ogra: tah. | 14:01 |
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:05 |
ogra | xnox, i'd have expected the build stamp to be roughly the same in initrd and rootfs | 14:06 |
ogra | (just curiosity, not a complaint ...) | 14:07 |
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:32 |
* 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:33 |
xnox | horum =/ | 14:34 |
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:35 |
ogra | weird upstream decision ... | 14:36 |
ijohnson | huh, so in a UC20 VM, `blockdev --getbsz /dev/vda` returns 4096 | 15:23 |
ijohnson | aha I should be using `--getpbsz` instead of `--getbsz` | 15:33 |
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:35 |
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:36 |
jschwart | I currently use autofs to access my NAS through /net | 15:37 |
jschwart | can I provide a snap access to that? | 15:37 |
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> | 15:56 |
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:42 |
ijohnson | hi benfrancis 👋 | 16:48 |
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:49 |
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:50 |
ijohnson | yeah that would make sense | 16:51 |
benfrancis | ijohnson: Perfect, thanks | 16:52 |
ijohnson | I admit I don't actually know what command you want to try with xhost though | 16:52 |
benfrancis | I'm going to try "xhost si:localuser:snap_daemon" | 16:53 |
ijohnson | seems logical to me :-) | 16:53 |
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:29 |
mborzecki | re | 18:48 |
mborzecki | ijohnson: let me take a quick look | 18:48 |
=== ijohnson is now known as ijohnson|lunch | ||
=== dariball_ is now known as dariball | ||
jschwart | cjp256: yeah that could work, I guess I have to do the bind mount as root though? | 19:08 |
cjp256 | I'd expect so, unless you have a `user` mount option in your fstab to mount it without root. | 19:10 |
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:26 |
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:31 |
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 | 19:32 |
=== popey5 is now known as popey | ||
ogra | jschwart, there is also /var/snap/<snapname>/common|current if you look after mounting it on a more systemish level | 20:38 |
ogra | (in fact i think only "common" since "current" is a symlink that can dynamically change | 20:47 |
ogra | ) | 20:47 |
=== ijohnson|lunch is now known as ijohnson | ||
jschwart | ogra: ah that would be a lot better yeah!! | 21:49 |
jschwart | ogra: yeah that is perfect really, just tried it and it works great, thanks a lot!! | 21:56 |
ogra | 😄 | 21:56 |
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:07 |
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> | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!