[05:13] <mborzecki> morning
[06:01] <zyga> Hey
[06:10] <mborzecki> zyga: mvo: hey
[06:10] <mborzecki> zyga: how's your dog?
[06:11] <mvo> good morning mborzecki and zyga
[06:12] <mvo> zyga: oh? is your dog not well?
[06:20] <mup> PR snapd#8753 closed: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
[06:23] <mvo> zyga: 8744 has a potentially interessting log for you
[06:23] <mvo> zyga: in the ubuntu-14.04 logs
[06:33] <zyga> Hey
[06:33] <zyga> Not sept much
[06:33] <zyga> Dog hurt but alive
[06:33] <zyga> Will go to vet soon
[06:33] <mvo> zyga: uh, what happend
[06:33] <mvo> ?
[06:34] <zyga> Dog ran under bike, got hurt, ran way and got lost
[06:34] <zyga> One of those bikers that must go super fast at all times
[06:35] <zyga> We went out of an alley l, it was dark
[06:35] <zyga> We looked for him for an hour or more
[06:35] <zyga> Wound on leg, lost tooth, minor wounds on feet as well
[06:36] <zyga> Internal state uncertain but likely no bleeding
[06:36] <mvo> zyga: uh, ok - good luck!
[06:40] <mup> PR snapd#8757 opened: tests: update statx test to run on all LTS releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8757>
[06:45] <mup> PR snapd#8758 opened: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8758>
[06:46] <zyga> in the office
[06:49] <zyga> mvo: looking
[06:51] <zyga> hmm!
[06:53] <zyga> mvo: I downloaded logs and restarted
[06:53] <zyga> I will look at in detail after the morning calls
[06:53] <zyga> at first sight I don't know
[06:55] <mvo> zyga: sure
[06:55] <mvo> zyga: no problem
[06:57] <mborzecki> hm maybe we should grow an `xdg` apckage with a desktop file parser inside
[06:58] <mborzecki> 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] <mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
[07:02] <pstolowski> morning
[07:07] <mborzecki> pstolowski: hey
[07:18] <mvo> hey pstolowski
[07:18] <mvo> mborzecki: +1 for xdg
[07:19] <zyga> mborzecki: xdgutil probably
[07:22] <pstolowski> i landed core18 early config yesterday, this unblocks #8567
[07:22] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[07:22] <pstolowski> mvo ^
[07:55] <mup> PR snapd#8759 opened: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
[07:56] <pedronis> zyga: hi, ^ , that's something you considered I think
[07:56] <zyga> yep, I noticed
[07:57] <zyga> 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] <zyga> I'll review it later today for sure
[07:58] <zyga> I reviewed dbus activation https://github.com/snapcore/snapd/pull/6258#pullrequestreview-419847153
[07:58] <mup> PR #6258: interfaces: support D-Bus activation <:birthday:> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6258>
[07:59] <pstolowski> zyga: could you take another look at #8640, i've addressed your comment
[07:59] <mup> PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
[07:59] <zyga> pstolowski: after some calls, unles urgent
[07:59] <pstolowski> zyga: it's not, np
[08:23] <zyga> there's a new raspberry pi with 8GB ram now
[08:23] <zyga> ogra: ^ do you have it?
[08:23] <ogra> lol
[08:23] <ogra> i'm not *that* fast
[08:23] <zyga> $$$
[08:24] <zyga> bought
[08:24] <ogra> i'll have fabrica appliance images for it though !
[08:24] <ogra> (https://snapcraft.io/fabrica build.snapcraft.io for your home ;) )
[08:25] <zyga> ooooooh
[08:25] <zyga> nice
[08:26] <ogra> 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] <ogra> *need
[08:26] <ogra> its all go now
[08:27] <ogra> (and it supports non GH trees as long as they are cloneable)
[08:28] <zyga> man at 8GB that's pretty much the same as my thinkpad
[08:28] <zyga> I wonder how it behaves as a desktop
[08:28] <ogra> well, the SD card is stilla bottleneck
[08:29] <ogra> but it is easy enough to just use the SD to jumpstart the boot and have writable on USB
[08:45] <mborzecki> mvo: pushed a little patch to https://github.com/snapcore/snapd/pull/8749
[08:45] <mup> PR #8749: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
[08:48] <mvo> mborzecki: thank you!
[08:49] <mborzecki> zyga: #8758 failed on 20.04 in a weird way, something you looked into before?
[08:49] <mup> PR #8758: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8758>
[08:49] <mborzecki> 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] <ogra> zyga, FYI ... ordered ... :)
[09:24] <zyga> re
[09:24] <zyga> small break to check on the dog and then reviews
[09:25] <zyga> mborzecki: nice
[09:25] <zyga> mborzecki: I think I have something that fixes that
[09:25] <zyga> I think this is related
[09:25] <zyga> https://github.com/snapcore/snapd/pull/8753
[09:25] <mup> PR #8753: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
[09:25] <zyga> but it landed already
[09:25] <zyga> just not sure if it's present in the PRs where things failed
[09:26] <zyga> and as I said yesterday
[09:26] <zyga> I need to (or we need to) look at the code that writes snapd.session-agent.{socket,service}
[09:26] <zyga> as I suspect it is buggy
[09:26] <zyga> and rewrites the unit without real need to
[09:26] <zyga> but fascinating that sockets can be broken this way
[09:26] <zyga> brb
[09:27] <mborzecki> 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] <mup> PR #8271: interfaces: add hugepages-control <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
[09:35] <pedronis> pstolowski: hi, I updated the proposal in #8691
[09:35] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[09:47] <zyga> re
[09:53] <diddledan> morning
[09:54] <zyga> hey diddledan
[09:54] <zyga> nice wave of snaps all the time
[09:54] <zyga> thanks for making that website :)
[09:54] <diddledan> :-)
[09:55] <diddledan> really happy people are finding it useful :-)
[09:59] <pstolowski> pedronis: thanks, will take a look
[10:04] <zyga> ogra: did yo notice that pi foundation also released a 64 bit raspbian OS?
[10:16] <ogra> they did quite a while ago but only as developer preview
[10:16] <ogra> stating explicitly that it isnt supported
[10:16] <ogra> did they change that ?
[10:21] <mup> PR snapd#8760 opened: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8760>
[10:29] <mborzecki> zyga: is there already some code that launches user processes via systemd run --user ?
[10:29] <mborzecki> (in the tree)
[10:33] <zyga> In tests or not tests?
[10:33] <mborzecki> non-tests
[10:33] <zyga> I do use it in tests
[10:33] <zyga> Otherwise no
[10:33] <zyga> We cannot rely on that
[10:34] <mborzecki> 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] <mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
[10:34] <mborzecki> and it kinda sucks to have to do it through sh -c
[10:35] <zyga> I’ll review it
[10:35] <mborzecki> 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] <mup> PR snapd#8756 closed: tests: skip interfaces-openvswitch for centos 8 in nightly suite <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8756>
[11:14] <Saviq> jdstrand: hey, when you have a while, Multipass 2105 needs a "lxd" interface installation assertion (not auto-connect at this time), thanks!
[11:27] <cachio> zyga, hey
[11:28] <cachio> zyga, I created a new pr to test spread https://github.com/sergiocazzolato/spread/pull/1
[11:28] <mup> PR sergiocazzolato/spread#1: Use GitHub actions <Created by sergiocazzolato> <https://github.com/sergiocazzolato/spread/pull/1>
[11:29] <cachio> do you think we can run it with the rest of the snapd tests?
[11:30] <diddledan> 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] <diddledan> there are no denials in the logs either. it's nicely silent.
[11:31] <diddledan> I've got an strace if it will help
[11:33] <diddledan> strace: https://cloud.bowlhat.net/index.php/s/pMYqG4RpFrQz7qt
[11:33] <ogra> while we'Re fixing such stuff, intel fixing VAAPI support would be awesome too 🙂
[11:33] <ogra> *fixing intel ...
[11:33]  * diddledan cuddles ogra
[11:33] <ogra> 🙂
[11:33] <ogra> diddledan, did you see my ping from a few days ago in #snapcraft ?
[11:34] <diddledan> about the desktop launcher and zoom?
[11:34] <ogra> i tried to use your ld cache stuff in zoom ...
[11:34] <ogra> yeah
[11:34] <ogra> how do you make it not fail ??
[11:34] <diddledan> yeah, donno what's up with that.. I don't really do anything particularly special, just having it in the chain
[11:34] <ogra> the hooks run as root after all ... it falls flat on its face for me
[11:35] <ogra> i use the old desktop launcher though ... not the gnome extension ... perhaps they behave different
[11:36] <diddledan> maybe. although I use the gtk2 one with gimp so probably not that
[11:36] <zyga> I will be around but I need about 40 minutes still
[11:37] <diddledan> oh wait, no I don't use the gtk2 one, I hack the one from the extension
[11:38] <pstolowski> cachio: hi, can you take another look at #8710?
[11:38] <mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[11:38] <cachio> pstolowski, sure
[11:39] <diddledan> 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] <mup> PR snapcraft#3128 closed: extensions: pre/append_dir: support rpath tokens by not using eval <bug> <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3128>
[11:45] <diddledan> aaah, maybe it's not compatible with the qt5 desktop helper. I'll do some checking
[11:45] <diddledan> I know I've had success with the GTK ones
[11:47] <diddledan> oh. I think it's an opensuse bug
[11:48] <diddledan> related, at least.
[11:52] <diddledan> 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] <diddledan> maybe we need mborzecki(are they the right name? I get lost with all the people :-p) to have a poke?
[11:55] <diddledan> I forget who is involved with suse
[11:58] <diddledan> at least I think it's `/root` it might be `/root/snap/$SNAPNAME/current` which would make more sense
[11:59] <cachio> pstolowski, minor comment
[11:59] <cachio> the rest it ok
[12:00] <diddledan> either that, or their `$XDG_CACHE_HOME` is not set when running the hooks
[12:01] <diddledan> oh no, not XDG_CACHE_HOME, that's explicitly set to $SNAP_USER_COMMON/.cache by the launch script
[12:08] <pedronis> pstolowski: there's something off with the dir in #8567, but maybe reorging the code a bit can solve that
[12:08] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[12:10] <pstolowski> pedronis: hmm, i must have misunderstood the flow
[12:13] <pedronis> 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] <pedronis> pstolowski: as I said we should do something with the code org that makes this more easy to get right
[12:14] <pstolowski> i need to have a spread test, i think things are stable now to pick it up again
[12:15] <pedronis> pstolowski: also look at go doc InstallHostWritableDir in boot , it would be good to know if it makes sense
[12:16] <pedronis> pstolowski: tbh your PR is old enough that the code in install was buggy and it was fixed since
[12:16] <pedronis> possibly
[12:16] <pstolowski> i see
[12:17] <pedronis> pstolowski: but yes, definitely +1 on the spread test
[12:23] <mborzecki> diddledan: zyga does the opensuse packaging, but that sounds strange, why would the hook store anything un root's home?
[12:24] <diddledan> 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] <mborzecki> sounds like a problem with the script then
[12:32] <pedronis> pstolowski: btw, I answered your comments in #8691
[12:32] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[12:38] <pstolowski> ty
[12:47] <pstolowski> pedronis: right, i see InstallHostWritableDir is the relatively new addition, my PR was based on what was there before
[12:48] <pstolowski> pedronis: thanks for spotting
[12:48] <pedronis> the spread should have caught it
[12:49] <pedronis> pstolowski: anyway let's chat how to organize the code, possibly in a follow up
[12:56] <pstolowski> ijohnson: hi! can you take another look at #8639? are you ok with the reasoning about locking?
[12:56] <mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[12:56] <pedronis> pstolowski: he's off today
[12:57] <pstolowski> ah
[13:08] <diddledan> 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] <mup> Bug #1880698 changed:  /etc/writable is double mounted <uc20> <Snappy:Fix Released> <https://launchpad.net/bugs/1880698>
[13:36] <mup> PR snapd#8761 opened: add msteams url support <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[13:40]  * zyga wonders what to focus on first
[13:44] <mup> PR snapcraft#3148 opened: [wip] specifications: environment-manager datastore <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3148>
[13:50] <zyga> maybe only after the calls
[13:50]  * zyga quick coffee
[13:59] <jdstrand> Saviq: hey, done
[14:02] <Saviq> jdstrand: thanks!
[14:13] <Saviq> jdstrand: can you confirm for us whether multipass is auto-connected on "home: read: all"? Not sure how to reliably check that :)
[14:13] <axino> hi
[14:13] <axino> I'm trying to install MAAS snaps in a cohort
[14:13] <axino> but I'm getting different versions for the same tracks
[14:14] <axino> ah I think I found the root cause
[14:14] <axino> "snap info" lies
[14:16] <roadmr> hi sergiusens
[14:16] <jdstrand> Saviq: you have the snap declaration that should do that
[14:16] <Saviq> jdstrand: ack, that's what I thought, thanks :)
[14:23] <jdstrand> Saviq: but just installing on core would be the test
[14:23] <Saviq> jdstrand: right, that :)
[14:24] <Saviq> was thinking something on my host, but I've not found how to "forget" previous manual connections
[14:24] <jdstrand> since that tests both the 'auto-connect on core' and the 'auto-connect with read'
[14:25] <pstolowski> cachio: i've addressed your recent comments to preseed-lxd test
[14:26] <cachio> pstolowski, looking
[14:26] <cachio> thanks
[14:27] <zyga> end of meetings
[14:35] <roadmr> 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] <mup> PR snapd#8762 opened: snap-bootstrap: remove key-file/recovery-key on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
[15:31] <pedronis> mvo: ^ a comment there
[15:37] <mup> PR snapd#8763 opened: gadget: make ext4 filesystems with or without metadata checksum <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8763>
[15:38] <sergiusens> roadmr: I don't understand the question itself, but your two statements is how snapcraft promote works today
[15:39] <sergiusens> 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] <roadmr> TooLMaN  :)
[15:40] <sergiusens> oops on autocomplete
[15:40] <sergiusens> tied too
[15:40] <roadmr> heheh
[15:40] <roadmr> sergiusens: interesting
[15:41] <roadmr> sergiusens: so if I try that manually how would that work?
[15:41] <roadmr> sergiusens: assuming I have two local .snap files, one for each arch
[15:41] <diddledan> https://www.youtube.com/watch?v=CDvCCcFr1Vc
[15:41] <roadmr> let's change the command, what if I snapcraft push --release 1_amd64.snap stable
[15:41] <roadmr> then snapcraft push --release 2_armhf.snap stable
[15:41] <roadmr> diddledan: I am NOT clicking on your rickrolling link. (/me does)
[15:42] <sergiusens> roadmr: you will have stable with revision 1 for amd64 and revision 2 for armhf
[15:42] <roadmr> sergiusens: aha, ok that's what the question was about really
[15:42] <roadmr> and that's what I was expecting
[15:43] <sergiusens> so snap install name on amd64 will give you rev 1 and for armhf will return rev 2
[15:43] <roadmr> righto :) as expected
[15:43] <sergiusens> assuming the store assigns rev1 to the first push and rev2 to the second
[15:43] <roadmr> right
[15:43] <sergiusens> as I just noticed I was biased by seeing the revision in the version part of the filename
[15:44] <sergiusens> with no name!
[15:45] <sergiusens> roadmr: also, "snapcraft upload" ftw :-)
[15:45] <roadmr> \o/!!!
[15:45] <roadmr> I'll try that next time!
[15:49] <zyga> No systemd in WSL2
[15:51] <zyga> And wsl repo is broken somehow?
[15:54]  * cachio lunch
[15:54] <diddledan> zyga, lies
[15:55] <diddledan> just needs a bit of customisation, and systemd works
[15:59] <ogra> pfft ... make them switch to upstart !
[16:01] <roadmr> \o/
[16:01] <diddledan> ogra, not SMF?
[16:01] <diddledan> :-p
[16:01] <diddledan> or, daemontools?
[16:02] <diddledan> :-p
[16:02] <ogra> busybox ...
[16:11] <mvo> pedronis: thanks for your comment there
[16:14] <cmatsuoka> mvo: the metadata_csum change should only affect snap-bootstrap, the rest should work without metadata_csum as it was before
[16:17] <mvo> 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] <cmatsuoka> 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] <cmatsuoka> 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] <cmatsuoka> mvo: the new contents, with the old function name, is called by snap-bootstrap only
[16:28] <mvo> 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] <cmatsuoka> mvo: it can be renamed if you think it's really misleading
[16:33] <mvo> 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] <mvo> cmatsuoka: anyway, have a look, I get dinner now(ish)
[16:36] <pedronis> mvo: cmatsuoka: we should double check with maciej but I don't think making filesystems is used at all by gadget updates
[16:36] <pedronis> atm
[16:40] <kyrofa> Anyone know of snap confinement issues on pop os?
[16:41] <kyrofa> 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] <cmatsuoka> 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] <pedronis> cmatsuoka: as far I know it's used on anything but uc20
[16:43] <cmatsuoka> 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] <pedronis> cmatsuoka: we don't have code that make images
[16:44] <pedronis> only ubuntu-image does
[16:44] <zyga> 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] <pedronis> and as I said, I'm 90% sure that that code is not used by gadget updates
[16:45] <cmatsuoka> pedronis: so can we just drop -O -metadata_csum and always use the default paramters for mkfs?
[16:46] <pedronis> cmatsuoka: in my opinion yes, probably living a comment about the code now working on xenial as is
[16:46] <pedronis> *leaving
[16:46] <pedronis> and we can deal with that when we have to
[16:46] <pedronis> cmatsuoka: we had a long term plan to subsume some work of ubuntu-image, that's what maciej prototype was about
[16:46] <cmatsuoka> ah ok
[16:47] <pedronis> cmatsuoka: anyway as I said we probably need maciej to double check this
[16:47] <kyrofa> zyga, it's taken from the host? Then how do you explain this? https://paste.ubuntu.com/p/j52StNjpxk/
[16:47] <pedronis> but my perusing of the code and removing stuff seems to confirm that nothing but boostrap was actively using those bits
[16:47] <zyga> kyrofa: /etc is
[16:47] <zyga> kyrofa: ls -ld /etc/os-release?
[16:47] <cmatsuoka> but even on xenial, the default parameters on xenial's mkfs should do the right thing
[16:47] <zyga> kyrofa: if that points to /whatever/stuff then that certainly won't work
[16:48] <pedronis> cmatsuoka: I don't understand,  we can make uc16 images on focal
[16:48] <pedronis> if that's your question
[16:48] <pedronis> but we don't have code to do that e2e
[16:48] <kyrofa> zyga, but wait-- my pastebin shows that it's using the os-release out of the core snap, doesn't it?
[16:49] <kyrofa> So how would the host having a symlink there matter?
[16:49] <pedronis> cmatsuoka: ubuntu-image does
[16:50] <pedronis> cmatsuoka: it mkfs that breaks? or is the kernel using the filesystem that will break?
[16:50] <zyga> kyrofa: stop and think - /etc is *exactly* from the host, what is /etc/os-release on your pop-os host?
[16:50] <cmatsuoka> pedronis: it's mkfs that breaks during the uc20 installation
[16:50] <cmatsuoka> on the 600P
[16:50] <pedronis> cmatsuoka: well, we are not xenial at point
[16:51] <kyrofa> zyga, that's my point, let's back up: how can /etc be *exactly* from the host given my pastebin?
[16:51] <pedronis> sorry it probably more confusing that it should be
[16:51] <cmatsuoka> so there are two constraints: xenial forbids metadata_csum, 600P requires metadata_csum
[16:51] <zyga> kyrofa: I'll let you run ls -ld and answer your question :)
[16:51] <zyga> don't cat it
[16:51] <kyrofa> Oh because it's a relative symlink
[16:51] <zyga> :D
[16:52] <zyga> tadam
[16:52] <zyga> os-release may be a symlink that points anywhere
[16:52] <pedronis> 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] <pedronis> I mean the kernel we shipped with xenial/UC16 ?
[16:52] <cmatsuoka> pedronis: the comment says that the system doesn't boot afterwards
[16:53] <pedronis> cmatsuoka: ?
[16:53] <pedronis> cmatsuoka: I'm not talking uc20
[16:53] <pedronis> cmatsuoka: I'm asking about xenial
[16:53] <cmatsuoka> pedronis: yes, let me find the comment here
[16:54] <cmatsuoka> pedronis: [using metadata_csum] were unsupported in Ubuntu 16.04 and Ubuntu Core 16 systems and would lead to a boot failure if enabled
[16:58]  * cmatsuoka verifies if FilesystemImageWriter is actually used somewhere...
[16:58] <pedronis> cmatsuoka: afaict is not, but please double check
[17:01]  * cmatsuoka missed lunch time again
[17:01] <roadmr> cmatsuoka: it's never too late :)
[17:01] <cmatsuoka> yeah, I'll be back soon :)
[17:52] <pedronis> mmh, the preseed tests have started failing on 19.10
[18:45] <pedronis> cmatsuoka: thanks for the changes, made some suggestions about the comments in that function
[18:50] <cmatsuoka> pedronis: thank you, will update
[18:53] <mup> PR snapd#8764 opened: tests: adding ubuntu 20.10 to spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8764>
[19:26] <kyrofa> zyga, apparently on pop os the os-release file is in /etc/pop-os/os-release. Is that not accessible from confinement?
[20:21] <cmatsuoka> cachio: did you see tumbleweed degraded mode errors recently?
[20:21] <cachio> cmatsuoka, no
[20:21] <cachio> do you have any link?
[20:21] <cachio> cmatsuoka, I could check that
[20:22] <cmatsuoka> cachio: just a sec, let me find it
[20:22] <cmatsuoka> cachio: also preseed errors
[20:23] <cmatsuoka> cachio: https://github.com/snapcore/snapd/pull/8763/checks?check_run_id=717978228
[20:23] <mup> PR #8763: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8763>
[20:23] <cachio> cmatsuoka, thanks, I'll take a look
[20:24] <cmatsuoka> cachio: also this one: https://github.com/snapcore/snapd/pull/8763/checks?check_run_id=717976666
[20:29] <cachio> cmatsuoka, the last one please merge it to master
[20:29] <cmatsuoka> ok
[20:29] <cachio> for all the erros related to preseed
[20:31] <cachio> checking the othe rone
[20:31] <cmatsuoka> cachio: hmm, I can't merge master, this is against release/2.45, what is the fix to cherry pick?
[20:31] <cachio> cmatsuoka, ah, need to check with pawel in this case
[20:32] <cmatsuoka> ah ok, I'd also need mvo to actually cherry pick that into the release branch
[20:32] <cachio> yes
[20:33] <cachio> the other one I need to check it becuase the service which is failing is one that we fix while the image is update
[20:33] <cachio> d
[20:33] <cachio> so it shouldn't fail
[20:33] <cachio> I'll take a look
[22:14] <zyga> kyrofa: it might be accessible but not with any stock interface, perhaps except system files
[22:15] <kyrofa> zyga, so /etc is mounted in from the host, but it's not all actually accessible, which I suppose makes sense. I didn't realize ubuntu derivatives did things like that. No confined snap will be able to read /etc/os-release on pop os by default
[22:16] <kyrofa> We might want to consider ways to resolve that
[22:16] <zyga> kyrofa: correct
[22:16] <zyga> kyrofa: my way to resolve that is to stop sharing /etc altogether
[22:16] <zyga> it was a mistake IMO
[22:17] <kyrofa> Yeah that was a bit of a sledgehammer, but we can't really take it back now
[22:17] <zyga> there is a path forward and a way out, we can add an empty /etc and populate it with curated content
[22:17] <zyga> and not break apps
[22:18] <zyga> if we understand what each interface provides
[22:18] <zyga> it's a lot of work
[22:18] <zyga> but it's not impossible
[22:23] <kyrofa> It certainly effects the cross-distro story. Anyway, I told my reporter to report the bug against snapd, so keep an eye out for that
[22:23] <zyga> ok
[22:23] <kyrofa> Thanks for the help!
[22:23] <zyga> pleasure :)