[04:53] <mup> PR snapd#8001 opened: boot: enable UC20 kernel extraction and bootState20 handling <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[06:31] <mborzecki> morning
[06:47] <mborzecki> interesting postrm test failure on debian: https://paste.ubuntu.com/p/WVGk8pW7rF/
[07:08] <mup> PR snapd#8002 opened: tests/core18/snapd-failover: collect more debug info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8002>
[07:35] <mborzecki> another one in 2.43.1 PR https://paste.ubuntu.com/p/F2WWvNc3Gv/
[07:51] <mborzecki> mvo: hey
[07:52] <mvo> mborzecki: good morning!
[07:53] <mborzecki> mvo: can you upload the snapd release tarballs for 43 and 43.1?
[08:02] <mvo> mborzecki: yes, sorry, will do that now!
[08:02] <mborzecki> mvo: thank you!
[08:02] <mvo> mborzecki: also need to update the roadmap and some more things related to the release. there were some build failures (mostly 7997 related) that delayed things
[08:03] <mvo> mborzecki: big thanks for 8002
[08:03] <pstolowski> morning
[08:03] <mborzecki> pstolowski: hey
[08:03] <mvo> hey pstolowski - good morning!
[08:03] <pstolowski> o/
[08:03] <mborzecki> mvo: btw. some weird interaction between apt command-not-found and snap advise https://paste.ubuntu.com/p/F2WWvNc3Gv/
[08:04] <mvo> pstolowski: the server team is asking for a meeting about boot speed today, I added you, hope you have time. you will also need to refresh my memories where we stand here
[08:04] <pstolowski> mvo: sure, thanks for invite
[08:05] <mvo> mborzecki: this logs fails with  snapd : Depends: apparmor (>= 2.10.95-0ubuntu2.2) but 2.10.95-0ubuntu2 is to be installed - which looks unrelated to c-n-f. what am I missing :) ?
[08:05] <mborzecki> mvo: uh,w8 not that one, this one https://paste.ubuntu.com/p/WVGk8pW7rF/
[08:09] <mvo> mborzecki: looking
[08:09] <pstolowski> mvo: it got side-tracked by the need of fixing services (generating wrappers, enabling them with regard to install hook and start-snap-services). first PR of the firsboot stuff landed (snap-preseed command), but will become usable once the snapd changes PR lands (blocked by services). services fixes have one open PR atm, there will be one more touching snapctl side.
[08:10] <mvo> mborzecki: thanks, that " E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Broken pipe
[08:10] <mvo> quiet: end of output" might be interessting for juliank. I remember him fixing a issue there a while ago but it seems like it's coming back
[08:11] <zyga> good morning
[08:11] <mvo> pstolowski: that's what I remember, I wonder if we could build a version that works without services or is that just impossible? i.e. we need the changes there
[08:11] <mborzecki> mvo: oh cool, i was a bit confused that it'd call cnf handler on removal too
[08:11] <mborzecki> zyga: hey
[08:12] <zyga> hey, what's up?
[08:12] <juliank> mborzecki: what's the apt version?
[08:12] <mborzecki> juliank: let me check
[08:15] <zyga> I'll try to do coding today but my hand hurts even more :/
[08:15] <zyga> I wonder if this is that wrist injury that some coders have
[08:15] <zyga> and that little wrestling with Janek is unrelated
[08:16] <zyga> or i can type with just one hand, dunnop
[08:16] <mvo> mborzecki: I don't remember the details but it's a bit strange
[08:23] <mvo> mborzecki: tarballs updated
[08:24] <mborzecki> juliank: it's 1.8.0~alpha3, though i see there's 1.8.4 uploaded already but we don't update it in the tests
[08:24] <mborzecki> mvo: thanks!
[08:24] <juliank> mborzecki: that needs updating, that's even a pre-release apt
[08:25] <mborzecki> juliank: got it, thanks!
[08:26] <mvo> mborzecki: sounds like sergio needs to update the images?
[08:26] <mborzecki> mvo: yup
[08:26] <mborzecki> mvo: i'll ping him when he gets online
[08:26] <mvo> juliank: thank you! and sorry for the noise, we should have figured this out ourselfs
[08:26] <mvo> mborzecki: thank you
[08:26] <juliank> just let me double check
[08:27] <juliank> yup
[08:27] <juliank> that bug was fixed in 1.8.0~rc1
[08:27] <pedronis> mvo: mborzecki: we need to chat about boot partition layouts, because I probably misunderstood something, and we are producing confusing code as a consequence, also I'm not sure the differences between 20 and 18/16 for boot have a reason or just arbitrary
[08:28] <mborzecki> juliank: thanks for double checking! we'll update the spread images, and hopefully the problem will go away ;)
[08:30] <mvo> pedronis: sure, when do you want to chat?
[08:31] <pstolowski> mvo: yes, it's possible, that's what i did originally
[08:32] <pedronis> mvo: mborzecki: in 5-10 mins ?
[08:32] <mvo> pstolowski: ok, maybe worth a chat with pedronis if we can give the server team something before we nail services
[08:33] <mvo> pedronis: works for me, standup channel in 10min?
[08:33] <pedronis> yes
[08:34] <mborzecki> pedronis: sure, let me grab some coffee
[08:35] <pstolowski> mvo: sure, sounds good
[08:41] <pedronis> mborzecki: mvo: I'm in the standup
[08:59] <zyga> afk for a moment
[09:09] <zyga> re
[09:12] <pstolowski> mvo, pedronis let me know if/when we can talk about firstboot & services
[09:18] <mvo> pstolowski: either around 11:30 or after the standup, depends how my meeting at 11:00 goes but probably after the standup
[09:19] <mvo> pstolowski: does not have to be long, just making sure we have a common understanding going into the other meeting today with server
[09:20] <pstolowski> mvo: ok, either sounds fine
[10:04]  * zyga goes upstairs to make cofee
[10:04] <zyga> *coffee
[10:18] <mup> PR snapd#8003 opened: o/ifacestate, api: implementation of snap disconnect --forget <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
[10:18] <sdhd-sascha> hi,
[10:19] <sdhd-sascha> i have trouble with glibc. Is it possible to deliver my own glibc inside a snap ?
[10:19] <zyga> sdhd-sascha: yes though I'd like to understand why you think that is required
[10:20] <zyga> I'll be back shortly, I really need to make that coffee
[10:20]  * zyga gets up and leaves
[10:22] <sdhd-sascha> zyga: i use `libsnapcraft-preload.so`. And in `canonicalize.c` is a macro: "`#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_3)`". I want to remove this part, because the `realpath` function only works if the `resolved` is non NULL
[10:24] <sdhd-sascha> zyga: i already asked sergiusens. But he's really busy.
[10:24] <sdhd-sascha> Maybe there is another solution, which i didn't see. (My C++ knowledge is very old and non-practical)
[10:27] <sdhd-sascha> This is the source, which works only without `snapcraft-preload`.
[10:27] <sdhd-sascha> With `snapcraft-preload` one call of `realpath` failed.
[10:27] <sdhd-sascha> https://www.irccloud.com/pastebin/wyZvthyv/
[10:31] <sdhd-sascha> Is there already a non-compat glibc which could be packaged with a snap ?
[10:32] <zyga> re
[10:32] <sdhd-sascha> :)
[10:32]  * sdhd-sascha lunch
[10:42] <mborzecki> hmmm - Download snap "strace-static" (18) from channel "stable" (http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug="")
[10:42] <mvo> GOAWAY is rude
[10:42]  * mvo shakes fist
[10:43] <mborzecki> log if anyone's interested: https://paste.ubuntu.com/p/NMRnvTRTqP/
[10:43] <zyga> mvo: we should rename it to PLEASESTOP
[10:43] <mborzecki> zyga: mvo: and the client sends BENICE
[10:43] <zyga> it should just return BEHAVE!
[10:43] <mvo> :-D
[10:46] <mborzecki> btw https://github.com/systemd/systemd/issues/10872 is fixed, i'm trying the reproducer right now to confirm it's fine
[10:46] <mborzecki> (across a decent number of runs)
[10:48] <Chipaca> is http2 secretly intercal
[11:02] <pedronis> mvo: mborzecki: I made this comment in the UC20 boot PR: https://github.com/snapcore/snapd/pull/7992#issuecomment-574609408
[11:02] <mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
[11:03]  * sdhd-sascha re
[11:03] <pstolowski> sigh, 'git push merge master' should dwim
[11:05] <sdhd-sascha> zyga: what do you think, what is the best way to solve the issue with realpath ? Would be nice, if it would be possible to mount tmpfs over /dev/shm. So i didn't need the preload library with the realpath issue.
[11:06]  * Chipaca brb
[11:07] <zyga> sdhd-sascha: is the problem that realpath() does not behave as it is documented to?
[11:13] <sdhd-sascha> zyga: with the preload library, realpath goes the call-path, like GLIBC <= 2.3. Without it like modern. The preload code, seems to choose a wrong entry point for realpath.
[11:13] <sdhd-sascha> I mean: with preload: it returns NULL instead of the path, if the seconde param is NULL.
[11:13] <zyga> sdhd-sascha: can this be fixed by changing the preload library?
[11:13] <zyga> sdhd-sascha: perhaps fixing it in snapcraft itself
[11:16] <sdhd-sascha> zyga: yes, i'm sure, it could be fixed by changing the preload library. But i don't know yet, how i could make this function call `dlsym (RTLD_NEXT, FUNC_NAME)` to choose the correct version.
[11:17] <sdhd-sascha> The preload-library isn't part of snapcraft, yet. https://github.com/sergiusens/snapcraft-preload
[11:17] <zyga> I see
[11:17] <zyga> sdhd-sascha: can you use dlvsym?
[11:18] <zyga> it allows you to pick the version you want
[11:18] <sdhd-sascha> zyga: well, i can think about it, to change all library calls... good, idea
[11:20] <sdhd-sascha> zyga: what glibc version would you prefer for the future ?
[11:20] <zyga> >
[11:20] <zyga> I have no idea what I am supposed to answer
[11:21] <sdhd-sascha> maybe, 2.19 ?
[11:23] <sdhd-sascha> zyga: thank you
[11:23] <zyga> no idea :)
[11:23] <zyga> can you explain why one over another?
[11:24] <zyga> perhaps you should dlvsym the newset that you knew about
[11:24] <zyga> and then fall back
[11:24] <zyga> note that it is not library version
[11:24] <zyga> but symbol version
[11:24] <zyga> check the symbol versions available for realpath
[11:24] <zyga> and probably pick the one that works the way you want
[11:24] <zyga> (one exact hit)
[11:24] <sdhd-sascha> zyga: no, i have to read the documentation. Many of the redirected calls are from linux itself, and i only need to redirect the stdlib, and so ...
[11:25]  * zyga doesn't understand how that is related
[11:25] <zyga> or doesn't understand the original question
[11:25] <mup> PR snapd#8000 closed: release: 2.43.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8000>
[11:25] <sdhd-sascha> zyga: sorry. I think you understand me. My last sentence was about specific to serguissens code ;-)
[11:26] <sdhd-sascha> zyga: i ask about the version. Because i would create a PR, if i get it worked. I need at least > 2.3
[11:27] <zyga> you can always reimplement realpath
[11:27] <zyga> if good version in glibc -> use it
[11:27] <zyga> otherwise -> here's one from scratch
[11:28] <sdhd-sascha> zyga: well. my problem is not realpath. It's /dev/shm. That's why i use the preload. But then the realpath didn't worked...
[11:28] <zyga> sdhd-sascha: what's with /dev/shm that is a problem for your app?
[11:29] <sdhd-sascha> zyga: yes. Apparmor says permission denied for /dev/shm/....
[11:29] <zyga> right, because apps tend to drop random bits of shm there and we don't want them to use it as unmediated IPC
[11:30] <sdhd-sascha> Yes, and here, i first patch sway to use "mktemp...". Then the "application menu" wants to write /dev/shm too...
[11:31] <zyga> interplay of apps and /dev/shm is ... complex
[11:31] <sdhd-sascha> I mean, i patched "wlroots", which i base library for wayland desktop's.
[11:31] <sdhd-sascha> is
[11:33] <sdhd-sascha> It would be nice, if a snap could mount tmpfs over /dev/shm. But is then with xdg-proxy, i some application want to talk
[11:34] <sdhd-sascha> What is with xdg-proxy... I mean "inter-snap" communication of snaps over "/dev/shm"
[11:35] <sdhd-sascha> zyga: you already helped me. I think i try to fix the preload-library ?!
[11:37] <zyga> sdhd-sascha: I think that usage of /dev/shm must be changed and reorganized
[11:37] <zyga> sdhd-sascha: currently it's pretty much like exchanging files via /tmp
[11:37] <sdhd-sascha> Oh, well... What if i use dlvsym with version... And then there are some more preloads used
[11:37] <zyga> sdhd-sascha: we don't have private per-snap /dev/shm because that would break everything
[11:38] <zyga> sdhd-sascha: but I think something along those lines would help a _lot_
[11:39] <sdhd-sascha> Maybe, for my case is to recompile glibc, without the old `realpath`. Or, like you says. Write another `realpath`. Or i patch sway, to use the old calling convention
[11:40] <zyga> what I was describing was a long term plan
[11:40] <zyga> for short term we need hacks and hacks and tweaks to apparmor policy
[11:40] <zyga> sadly :/
[11:41] <sdhd-sascha> I think, something like chroot and overlayfs would change the snap world.
[11:41] <zyga> you can use chroot
[11:41] <zyga> but I don't think that helps with the complexity of modern IPC
[11:41] <Chipaca> sdhd-sascha: do you have a minimal snapcraft with a .c that tries to use realpath and fails?
[11:41] <zyga> wayland + pulseaudio == loads of /dev/shm usage
[11:43] <sdhd-sascha> This code, fails on local machine, too. If i use the LD_PRELOAD=./libsnapcraft-preload.so
[11:43] <sdhd-sascha> https://www.irccloud.com/pastebin/GubDCCNh/
[11:43] <sdhd-sascha> on, eoan
[11:44] <mborzecki> cachio: hi, can you trigger an update of debian-sid base image?
[11:45] <mborzecki> cachio: apt in that image needs to be updated, otherwise this problem can happen occassionally https://paste.ubuntu.com/p/WVGk8pW7rF/
[11:46] <mvo> I guess "apt full-upgrade -y" is not a bad idea
[11:47] <sdhd-sascha> zyga: the code above, goes in gdb the way to "glibc-2.30"/stdlib/canonicalize.c" :
[11:48] <cachio> mborzecki, hello, sure, let me take a look
[11:48] <sdhd-sascha> https://www.irccloud.com/pastebin/kL1fM19L/
[11:48] <sdhd-sascha> And there, it's returns NULL as path
[11:50] <sdhd-sascha> If i use, dlvsym, then no other preload can overwrite realpath.
[11:50] <sdhd-sascha> Or, i'm wrong ? not sure
[11:51] <zyga> sdhd-sascha: I dont think that works this way
[11:51] <zyga> sdhd-sascha: but I cannot focus on this right now, sorry
[11:52] <zyga> sdhd-sascha: dlvsym is really just "in the symbols I've loaded, find the one with the version marker as well"
[11:52] <zyga> it's not "load just that version"
[11:52] <zyga> you really only open one glibc.so
[11:52] <zyga> inside you look for a symbol with matching name *and* version
[11:52] <zyga> that's the trick
[11:52] <zyga> IMO
[11:52] <cachio> mborzecki, https://travis-ci.org/snapcore/spread-cron/builds/636199611
[11:53] <cachio> mborzecki, it was updated on  Monday
[11:53] <cachio> the image we use for our tests
[11:54] <sdhd-sascha> zyga: thank you. I was wrong. It's still possible to use other preloads, because of the loading order of the libs ;-)
[11:54] <mup> PR snapd#7986 closed: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7986>
[11:57] <mup> PR snapd#8004 opened: cmd/snap: print full channel in 'snap list' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8004>
[12:02] <Chipaca> pedronis: do we want snap info to explicitly point out a default track?
[12:02] <Chipaca> as in, default-track: foo if foo != ""
[12:04] <mborzecki> cachio: so maybe we need to do a full-upgrade like mvo indicated, apt version in sid is 1.8.4 atm, but our image has 1.8.0~alpha3 for some reason
[12:04] <cachio> mborzecki, ok
[12:05] <cachio> mborzecki, we are not doing the full upgrade for sid because of this
[12:05] <cachio>     # We are not making dist-upgrade because it is creating a dependencies issue
[12:05] <cachio>     # which is making fail the preparation of the snapd test suite
[12:05] <cachio> I'll manually trigger and then we can see how it works
[12:07] <cachio> mborzecki, running
[12:07] <cachio> in case the image breaks we can revert it
[12:17] <zyga> brb.
[12:20] <mvo> cachio: aha, this is sid? yeah, then feel free to just uprade apt
[12:21] <cachio> mvo, I updated the file and am upgrading sid, it will be ready for testing in few minutes
[12:22] <mvo> cachio: nice, thank you
[12:27] <mborzecki> cachio: thanks!
[12:38] <pedronis> Chipaca: there was this proposal to put a default note on the most stable risk of it
[12:39] <pedronis> Chipaca: if we add default-track:  it should probably be only in --verbose
[12:44] <Chipaca> pedronis:   foo/candidate ♪ :)
[12:46] <pedronis> Chipaca: this re-landed only recently right: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769  , it's not in 2.43 ? cc mvo
[12:47] <pedronis> context: https://forum.snapcraft.io/t/the-snapd-roadmap/1973
[14:59] <mvo> ijohnson: sure thing, we are in the standup ho now
[15:01] <Chipaca> failures in debian-sid are expected right now, yes?
[15:14] <sergiusens> pstolowski: hey there, mind taking a look at https://github.com/snapcore/snapcraft/pull/2876
[15:14] <mup> PR snapcraft#2876: meta: handle plug & slot string objects <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2876>
[15:17] <pstolowski> sergiusens: sure, with a caveat that my python foo got a bit rusty ;)
[15:18] <pstolowski> but it's better than my vala foo ;)
[15:39]  * zyga still fights with a bug
[15:39] <zyga> I should break for coffee and think instead of just hammering the keyboard
[16:02] <sergiusens> pstolowski: insights appreciated more around the semantics around slots/plugs than the code :-)
[16:24] <ijohnson> mvo: should we add `system-backup` (and potentially any other new interfaces in 2.43) to the snapd release roadmap as new features for 2.43?
[16:30] <mvo> ijohnson: yes! feel free to edit
[16:30] <ijohnson> mvo: cool :-)
[16:38] <pedronis> Chipaca: does our snap/partial caching do nothing in this case? https://forum.snapcraft.io/t/failure-to-fetch-assertions-stops-installation-immediately/15059
[16:40] <Chipaca> pedronis: no
[16:40] <Chipaca> pedronis: not if the change was aborted
[16:46] <pstolowski> sergiusens: reviewed
[16:46] <sergiusens> thanks pstolowski
[16:47] <pstolowski> yw
[16:48] <mup> PR snapcraft#2876 closed: meta: handle plug & slot string objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2876>
[17:01]  * cachio lunch
[17:24] <mup> PR snapd#8005 opened: api: don't return connections referring to non-existing plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
[17:39] <mup> PR snapcraft#2878 opened: extensions: fix merge_lists to handle non-string list cases <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2878>
[17:39] <mup> PR pc-amd64-gadget#33 opened: grub.cfg-boot: use $prefix/kernel instead of $ubuntu-boot/kernel <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/33>
[18:21] <mup> PR snapcraft#2879 opened: [3.9-backport] meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2879>
[19:00] <mup> PR snapd#8006 opened: tests: skip interfaces-network-manager on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8006>
[19:01] <pedronis> ijohnson: do we still need Recovery: true in the new tests in 7992
[19:11] <mup> PR snapd#8007 opened: tests: remove execution of ubuntu 19.04 from google backend <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8007>
[21:41] <mup> Bug #1745772 changed: Can't run snap in lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1745772>
[21:44] <mup> Bug #1664427 changed: thefuck snap gets an apparmor denial even in classic confinement <classic> <isv> <Snappy:Confirmed> <https://launchpad.net/bugs/1664427>
[21:44] <mup> Bug #1675413 changed: snap disconnect doesn't support tab completion <Snappy:Fix Released> <https://launchpad.net/bugs/1675413>
[23:02] <mup> PR snapd#8008 opened: render: add the render package and basic widgets <Created by zyga> <https://github.com/snapcore/snapd/pull/8008>
[23:22] <mup> PR snapcraft#2880 opened: [RFC] schema: introduce configuration for package management repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2880>