=== KindTwo is now known as KindOne === Eighth_Doctor is now known as Conan_Kudo === Conan_Kudo is now known as Eighth_Doctor [05:13] morning [06:01] Hey [06:10] zyga: mvo: hey [06:10] zyga: how's your dog? [06:11] good morning mborzecki and zyga [06:12] zyga: oh? is your dog not well? [06:20] PR snapd#8753 closed: tests: reload systemd --user for root, if present [06:23] zyga: 8744 has a potentially interessting log for you [06:23] zyga: in the ubuntu-14.04 logs [06:33] Hey [06:33] Not sept much [06:33] Dog hurt but alive [06:33] Will go to vet soon [06:33] zyga: uh, what happend [06:33] ? [06:34] Dog ran under bike, got hurt, ran way and got lost [06:34] One of those bikers that must go super fast at all times [06:35] We went out of an alley l, it was dark [06:35] We looked for him for an hour or more [06:35] Wound on leg, lost tooth, minor wounds on feet as well [06:36] Internal state uncertain but likely no bleeding [06:36] zyga: uh, ok - good luck! [06:40] PR snapd#8757 opened: tests: update statx test to run on all LTS releases [06:45] PR snapd#8758 opened: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases [06:46] in the office [06:49] mvo: looking [06:51] hmm! [06:53] mvo: I downloaded logs and restarted [06:53] I will look at in detail after the morning calls [06:53] at first sight I don't know [06:55] zyga: sure [06:55] zyga: no problem [06:57] hm maybe we should grow an `xdg` apckage with a desktop file parser inside [06:58] zyga: do i remember correctly that https://github.com/snapcore/snapd/pull/8699 is just a start and eventually we'd like to launch non snap apps too? [06:58] PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps [07:02] morning [07:07] pstolowski: hey [07:18] hey pstolowski [07:18] mborzecki: +1 for xdg [07:19] mborzecki: xdgutil probably [07:22] i landed core18 early config yesterday, this unblocks #8567 [07:22] PR #8567: o/devicestate: core20 early config from gadget defaults [07:22] mvo ^ [07:55] PR snapd#8759 opened: tests: move *-tool tests to their own suite [07:56] zyga: hi, ^ , that's something you considered I think [07:56] yep, I noticed [07:57] my dream there would be so that that suite could be tested without building snapd but that's a longer piece of work [07:57] I'll review it later today for sure [07:58] I reviewed dbus activation https://github.com/snapcore/snapd/pull/6258#pullrequestreview-419847153 [07:58] PR #6258: interfaces: support D-Bus activation <:birthday:> [07:59] zyga: could you take another look at #8640, i've addressed your comment [07:59] PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) [07:59] pstolowski: after some calls, unles urgent [07:59] zyga: it's not, np [08:23] there's a new raspberry pi with 8GB ram now [08:23] ogra: ^ do you have it? [08:23] lol [08:23] i'm not *that* fast [08:23] $$$ [08:24] bought [08:24] i'll have fabrica appliance images for it though ! [08:24] (https://snapcraft.io/fabrica build.snapcraft.io for your home ;) ) [08:25] ooooooh [08:25] nice [08:26] you nered to see it ... i only did a shappy prototype in pylxd ... then james jeudason came ... now it beats build.s.io ! [08:26] *need [08:26] its all go now [08:27] (and it supports non GH trees as long as they are cloneable) [08:28] man at 8GB that's pretty much the same as my thinkpad [08:28] I wonder how it behaves as a desktop [08:28] well, the SD card is stilla bottleneck [08:29] but it is easy enough to just use the SD to jumpstart the boot and have writable on USB [08:45] mvo: pushed a little patch to https://github.com/snapcore/snapd/pull/8749 [08:45] PR #8749: configcore: show better error when disabling services [08:48] mborzecki: thank you! [08:49] zyga: #8758 failed on 20.04 in a weird way, something you looked into before? [08:49] PR #8758: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases [08:49] there;s this in the logs: `2020-05-28T07:29:05.7615493Z May 28 07:29:04 may280655-963480 snapd[91768]: May 28 07:28:58 may280655-963480 systemd[1308]: snapd.session-agent.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.` [09:22] zyga, FYI ... ordered ... :) [09:24] re [09:24] small break to check on the dog and then reviews [09:25] mborzecki: nice [09:25] mborzecki: I think I have something that fixes that [09:25] I think this is related [09:25] https://github.com/snapcore/snapd/pull/8753 [09:25] PR #8753: tests: reload systemd --user for root, if present [09:25] but it landed already [09:25] just not sure if it's present in the PRs where things failed [09:26] and as I said yesterday [09:26] I need to (or we need to) look at the code that writes snapd.session-agent.{socket,service} [09:26] as I suspect it is buggy [09:26] and rewrites the unit without real need to [09:26] but fascinating that sockets can be broken this way [09:26] brb [09:27] abeato: hi, i've updated your hugepages-control PR, please take a look whether the changes are fine https://github.com/snapcore/snapd/pull/8271 [09:27] PR #8271: interfaces: add hugepages-control [09:35] pstolowski: hi, I updated the proposal in #8691 [09:35] PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities [09:47] re [09:53] morning [09:54] hey diddledan [09:54] nice wave of snaps all the time [09:54] thanks for making that website :) [09:54] :-) [09:55] really happy people are finding it useful :-) [09:59] pedronis: thanks, will take a look [10:04] ogra: did yo notice that pi foundation also released a 64 bit raspbian OS? [10:16] they did quite a while ago but only as developer preview [10:16] stating explicitly that it isnt supported [10:16] did they change that ? [10:21] PR snapd#8760 opened: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions [10:29] zyga: is there already some code that launches user processes via systemd run --user ? [10:29] (in the tree) [10:33] In tests or not tests? [10:33] non-tests [10:33] I do use it in tests [10:33] Otherwise no [10:33] We cannot rely on that [10:34] zyga: i'm asking in the context of https://github.com/snapcore/snapd/pull/8699 we start he child ourselves and need to let it go and be reparented to whatever is the right subreaper, but userd is long running [10:34] PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps [10:34] and it kinda sucks to have to do it through sh -c [10:35] I’ll review it [10:35] if we only had a common way to start whatever is in the desktop files instead of calling the gio/gtk/kio/random helper [10:41] PR snapd#8756 closed: tests: skip interfaces-openvswitch for centos 8 in nightly suite [11:14] jdstrand: hey, when you have a while, Multipass 2105 needs a "lxd" interface installation assertion (not auto-connect at this time), thanks! === msalvatore_ is now known as msalvatore [11:27] zyga, hey [11:28] zyga, I created a new pr to test spread https://github.com/sergiocazzolato/spread/pull/1 [11:28] PR sergiocazzolato/spread#1: Use GitHub actions [11:29] do you think we can run it with the rest of the snapd tests? [11:30] zyga, have you done much work on opencl enablement? I'm looking at getting fakecam to support it but the opencv library complains that `Error on line 2205 (ocl.cpp): CL_DEVICE_SVM_CAPABILITIES via clGetDeviceInfo failed: -30` [11:30] there are no denials in the logs either. it's nicely silent. [11:31] I've got an strace if it will help [11:33] strace: https://cloud.bowlhat.net/index.php/s/pMYqG4RpFrQz7qt [11:33] while we'Re fixing such stuff, intel fixing VAAPI support would be awesome too 🙂 [11:33] *fixing intel ... [11:33] * diddledan cuddles ogra [11:33] 🙂 [11:33] diddledan, did you see my ping from a few days ago in #snapcraft ? [11:34] about the desktop launcher and zoom? [11:34] i tried to use your ld cache stuff in zoom ... [11:34] yeah [11:34] how do you make it not fail ?? [11:34] yeah, donno what's up with that.. I don't really do anything particularly special, just having it in the chain [11:34] the hooks run as root after all ... it falls flat on its face for me [11:35] i use the old desktop launcher though ... not the gnome extension ... perhaps they behave different [11:36] maybe. although I use the gtk2 one with gimp so probably not that [11:36] I will be around but I need about 40 minutes still [11:37] oh wait, no I don't use the gtk2 one, I hack the one from the extension [11:38] cachio: hi, can you take another look at #8710? [11:38] PR #8710: tests: spread test for preseeding in lxd container (3/3)

[11:38] pstolowski, sure [11:39] the patch I apply doesn't change anything particularly related to failing to run as root, though: https://github.com/diddlesnaps/gimp/blob/master/patches/desktop-launch.patch [11:44] PR snapcraft#3128 closed: extensions: pre/append_dir: support rpath tokens by not using eval [11:45] aaah, maybe it's not compatible with the qt5 desktop helper. I'll do some checking [11:45] I know I've had success with the GTK ones [11:47] oh. I think it's an opensuse bug [11:48] related, at least. [11:52] On Ubuntu, snapd's root environment for the hooks has `$HOME` set to `/root`, but possibly on opensuse it doesn't set `$HOME` so all the paths using the variable expand to `/foo` instead of `/root/foo`. [11:54] maybe we need mborzecki(are they the right name? I get lost with all the people :-p) to have a poke? [11:55] I forget who is involved with suse [11:58] at least I think it's `/root` it might be `/root/snap/$SNAPNAME/current` which would make more sense [11:59] pstolowski, minor comment [11:59] the rest it ok [12:00] either that, or their `$XDG_CACHE_HOME` is not set when running the hooks [12:01] oh no, not XDG_CACHE_HOME, that's explicitly set to $SNAP_USER_COMMON/.cache by the launch script [12:08] pstolowski: there's something off with the dir in #8567, but maybe reorging the code a bit can solve that [12:08] PR #8567: o/devicestate: core20 early config from gadget defaults [12:10] pedronis: hmm, i must have misunderstood the flow [12:13] pstolowski: you should look at the cloud-init tests there and you'll see the rootdir involved is a bit different than what you picked [12:13] pstolowski: as I said we should do something with the code org that makes this more easy to get right [12:14] i need to have a spread test, i think things are stable now to pick it up again [12:15] pstolowski: also look at go doc InstallHostWritableDir in boot , it would be good to know if it makes sense [12:16] pstolowski: tbh your PR is old enough that the code in install was buggy and it was fixed since [12:16] possibly [12:16] i see [12:17] pstolowski: but yes, definitely +1 on the spread test [12:23] diddledan: zyga does the opensuse packaging, but that sounds strange, why would the hook store anything un root's home? [12:24] the hook uses the desktop-helper script to set up the environment to be able to know where all the runtime libraries are located so it can create the ld.so.cache. the problem is that script _also_ does stuff like making symlinks and creating user-specific caches, so it accesses the $SNAP_USER_DATA or $HOME [12:25] sounds like a problem with the script then [12:32] pstolowski: btw, I answered your comments in #8691 [12:32] PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities [12:38] ty [12:47] pedronis: right, i see InstallHostWritableDir is the relatively new addition, my PR was based on what was there before [12:48] pedronis: thanks for spotting [12:48] the spread should have caught it [12:49] pstolowski: anyway let's chat how to organize the code, possibly in a follow up [12:56] ijohnson: hi! can you take another look at #8639? are you ok with the reasoning about locking? [12:56] PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) [12:56] pstolowski: he's off today [12:57] ah [13:08] interesting. I just ran radeontop while running my fakecam app - it looks like I am successfully running something against the card even though opencv says it couldn't initialise [13:18] Bug #1880698 changed: /etc/writable is double mounted [13:36] PR snapd#8761 opened: add msteams url support [13:40] * zyga wonders what to focus on first [13:44] PR snapcraft#3148 opened: [wip] specifications: environment-manager datastore [13:50] maybe only after the calls [13:50] * zyga quick coffee [13:59] Saviq: hey, done [14:02] jdstrand: thanks! [14:13] jdstrand: can you confirm for us whether multipass is auto-connected on "home: read: all"? Not sure how to reliably check that :) [14:13] hi [14:13] I'm trying to install MAAS snaps in a cohort [14:13] but I'm getting different versions for the same tracks [14:14] ah I think I found the root cause [14:14] "snap info" lies [14:16] hi sergiusens [14:16] Saviq: you have the snap declaration that should do that [14:16] jdstrand: ack, that's what I thought, thanks :) [14:23] Saviq: but just installing on core would be the test [14:23] jdstrand: right, that :) [14:24] was thinking something on my host, but I've not found how to "forget" previous manual connections [14:24] since that tests both the 'auto-connect on core' and the 'auto-connect with read' [14:25] cachio: i've addressed your recent comments to preseed-lxd test [14:26] pstolowski, looking [14:26] thanks [14:27] end of meetings [14:35] sergiusens: say I have revision 1 for amd64, and revision2 for armhf. If I do snapcraft release name 1 stable; snapcraft release 2 stable; will both be available, I just get the one that matches client architecture? [15:02] PR snapd#8762 opened: snap-bootstrap: remove key-file/recovery-key on reinstall [15:31] mvo: ^ a comment there [15:37] PR snapd#8763 opened: gadget: make ext4 filesystems with or without metadata checksum [15:38] roadmr: I don't understand the question itself, but your two statements is how snapcraft promote works today [15:39] roadmr: that is, you cannot choose the architecture of the channel being released to, that's decided Snap Store side depending on the architecture the revision is tied TooLmaN [15:39] TooLMaN :) [15:40] oops on autocomplete [15:40] tied too [15:40] heheh [15:40] sergiusens: interesting [15:41] sergiusens: so if I try that manually how would that work? [15:41] sergiusens: assuming I have two local .snap files, one for each arch [15:41] https://www.youtube.com/watch?v=CDvCCcFr1Vc [15:41] let's change the command, what if I snapcraft push --release 1_amd64.snap stable [15:41] then snapcraft push --release 2_armhf.snap stable [15:41] diddledan: I am NOT clicking on your rickrolling link. (/me does) [15:42] roadmr: you will have stable with revision 1 for amd64 and revision 2 for armhf [15:42] sergiusens: aha, ok that's what the question was about really [15:42] and that's what I was expecting [15:43] so snap install name on amd64 will give you rev 1 and for armhf will return rev 2 [15:43] righto :) as expected [15:43] assuming the store assigns rev1 to the first push and rev2 to the second [15:43] right [15:43] as I just noticed I was biased by seeing the revision in the version part of the filename [15:44] with no name! [15:45] roadmr: also, "snapcraft upload" ftw :-) [15:45] \o/!!! [15:45] I'll try that next time! [15:49] No systemd in WSL2 [15:51] And wsl repo is broken somehow? [15:54] * cachio lunch [15:54] zyga, lies [15:55] just needs a bit of customisation, and systemd works [15:59] pfft ... make them switch to upstart ! [16:01] \o/ [16:01] ogra, not SMF? [16:01] :-p [16:01] or, daemontools? [16:02] :-p [16:02] busybox ... [16:11] pedronis: thanks for your comment there [16:14] mvo: the metadata_csum change should only affect snap-bootstrap, the rest should work without metadata_csum as it was before [16:17] cmatsuoka: thanks, I looked at the code and it was not obvious to me that this mkfs handler is just used by the uc20 code, it looked like a generic gadget helper that would also be used by other gadget update stuff. if not that's great [16:25] mvo: I admit the name choices can be confusing, but my idea was to use the default name to do the default thing (and the special name to pass extra options) [16:27] mvo: that helper is used by, i think, image generation and maybe more things, but the new function that's there is actually calling the old mkfs contents [16:27] mvo: the new contents, with the old function name, is called by snap-bootstrap only [16:28] cmatsuoka: yeah, sorry, I think I get it now. I will comment in the PR, sorry again that I did not dig deeper [16:30] mvo: it can be renamed if you think it's really misleading [16:33] cmatsuoka: it's fine, I followed up with yet another question, maybe it's a sign I should actually call it a aday :) [16:33] cmatsuoka: anyway, have a look, I get dinner now(ish) [16:36] mvo: cmatsuoka: we should double check with maciej but I don't think making filesystems is used at all by gadget updates [16:36] atm [16:40] Anyone know of snap confinement issues on pop os? [16:41] Got a bug report where the snap can't access /etc/os-release, which is contained in the core snap. Works for me on ubuntu [16:42] pedronis: mvo raised an interesting point, is that code used only on the actual device? if so we can always use the defaults instead of having two functions using different parameters [16:43] cmatsuoka: as far I know it's used on anything but uc20 [16:43] pedronis: but does it run when, say, creating an uc image on a different host, or does it only run on the device itself? [16:44] cmatsuoka: we don't have code that make images [16:44] only ubuntu-image does [16:44] kyrofa: /etc/os-release is taken from the host, if /etc/os-release is a symlink then it will most likely not work [16:44] and as I said, I'm 90% sure that that code is not used by gadget updates [16:45] pedronis: so can we just drop -O -metadata_csum and always use the default paramters for mkfs? [16:46] cmatsuoka: in my opinion yes, probably living a comment about the code now working on xenial as is [16:46] *leaving [16:46] and we can deal with that when we have to [16:46] cmatsuoka: we had a long term plan to subsume some work of ubuntu-image, that's what maciej prototype was about [16:46] ah ok [16:47] cmatsuoka: anyway as I said we probably need maciej to double check this [16:47] zyga, it's taken from the host? Then how do you explain this? https://paste.ubuntu.com/p/j52StNjpxk/ [16:47] but my perusing of the code and removing stuff seems to confirm that nothing but boostrap was actively using those bits [16:47] kyrofa: /etc is [16:47] kyrofa: ls -ld /etc/os-release? [16:47] but even on xenial, the default parameters on xenial's mkfs should do the right thing [16:47] kyrofa: if that points to /whatever/stuff then that certainly won't work [16:48] cmatsuoka: I don't understand, we can make uc16 images on focal [16:48] if that's your question [16:48] but we don't have code to do that e2e [16:48] zyga, but wait-- my pastebin shows that it's using the os-release out of the core snap, doesn't it? [16:49] So how would the host having a symlink there matter? [16:49] cmatsuoka: ubuntu-image does [16:50] cmatsuoka: it mkfs that breaks? or is the kernel using the filesystem that will break? [16:50] kyrofa: stop and think - /etc is *exactly* from the host, what is /etc/os-release on your pop-os host? [16:50] pedronis: it's mkfs that breaks during the uc20 installation [16:50] on the 600P [16:50] cmatsuoka: well, we are not xenial at point [16:51] zyga, that's my point, let's back up: how can /etc be *exactly* from the host given my pastebin? [16:51] sorry it probably more confusing that it should be [16:51] so there are two constraints: xenial forbids metadata_csum, 600P requires metadata_csum [16:51] kyrofa: I'll let you run ls -ld and answer your question :) [16:51] don't cat it [16:51] Oh because it's a relative symlink [16:51] :D [16:52] tadam [16:52] os-release may be a symlink that points anywhere [16:52] cmatsuoka: is mkfs that breaks on xenial on that param? or is the kernel also that can't use a filesystem built with that param? [16:52] I mean the kernel we shipped with xenial/UC16 ? [16:52] pedronis: the comment says that the system doesn't boot afterwards [16:53] cmatsuoka: ? [16:53] cmatsuoka: I'm not talking uc20 [16:53] cmatsuoka: I'm asking about xenial [16:53] pedronis: yes, let me find the comment here [16:54] pedronis: [using metadata_csum] were unsupported in Ubuntu 16.04 and Ubuntu Core 16 systems and would lead to a boot failure if enabled === KindTwo is now known as KindOne [16:58] * cmatsuoka verifies if FilesystemImageWriter is actually used somewhere... [16:58] cmatsuoka: afaict is not, but please double check [17:01] * cmatsuoka missed lunch time again [17:01] cmatsuoka: it's never too late :) [17:01] yeah, I'll be back soon :) [17:52] mmh, the preseed tests have started failing on 19.10 [18:45] cmatsuoka: thanks for the changes, made some suggestions about the comments in that function [18:50] pedronis: thank you, will update [18:53] PR snapd#8764 opened: tests: adding ubuntu 20.10 to spread tests [19:26] zyga, apparently on pop os the os-release file is in /etc/pop-os/os-release. Is that not accessible from confinement? [20:21] cachio: did you see tumbleweed degraded mode errors recently? [20:21]