mupPR snapd#8001 opened: boot: enable UC20 kernel extraction and bootState20 handling <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>04:53
mborzeckiinteresting postrm test failure on debian: https://paste.ubuntu.com/p/WVGk8pW7rF/06:47
mupPR snapd#8002 opened: tests/core18/snapd-failover: collect more debug info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8002>07:08
mborzeckianother one in 2.43.1 PR https://paste.ubuntu.com/p/F2WWvNc3Gv/07:35
mborzeckimvo: hey07:51
mvomborzecki: good morning!07:52
mborzeckimvo: can you upload the snapd release tarballs for 43 and 43.1?07:53
mvomborzecki: yes, sorry, will do that now!08:02
mborzeckimvo: thank you!08:02
mvomborzecki: also need to update the roadmap and some more things related to the release. there were some build failures (mostly 7997 related) that delayed things08:02
mvomborzecki: big thanks for 800208:03
mborzeckipstolowski: hey08:03
mvohey pstolowski - good morning!08:03
mborzeckimvo: btw. some weird interaction between apt command-not-found and snap advise https://paste.ubuntu.com/p/F2WWvNc3Gv/08:03
mvopstolowski: 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 here08:04
pstolowskimvo: sure, thanks for invite08:04
mvomborzecki: 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
mborzeckimvo: uh,w8 not that one, this one https://paste.ubuntu.com/p/WVGk8pW7rF/08:05
mvomborzecki: looking08:09
pstolowskimvo: 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:09
mvomborzecki: 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 pipe08:10
mvoquiet: 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 back08:10
zygagood morning08:11
mvopstolowski: 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 there08:11
mborzeckimvo: oh cool, i was a bit confused that it'd call cnf handler on removal too08:11
mborzeckizyga: hey08:11
zygahey, what's up?08:12
juliankmborzecki: what's the apt version?08:12
mborzeckijuliank: let me check08:12
zygaI'll try to do coding today but my hand hurts even more :/08:15
zygaI wonder if this is that wrist injury that some coders have08:15
zygaand that little wrestling with Janek is unrelated08:15
zygaor i can type with just one hand, dunnop08:16
mvomborzecki: I don't remember the details but it's a bit strange08:16
mvomborzecki: tarballs updated08:23
mborzeckijuliank: it's 1.8.0~alpha3, though i see there's 1.8.4 uploaded already but we don't update it in the tests08:24
mborzeckimvo: thanks!08:24
juliankmborzecki: that needs updating, that's even a pre-release apt08:24
mborzeckijuliank: got it, thanks!08:25
mvomborzecki: sounds like sergio needs to update the images?08:26
mborzeckimvo: yup08:26
mborzeckimvo: i'll ping him when he gets online08:26
mvojuliank: thank you! and sorry for the noise, we should have figured this out ourselfs08:26
mvomborzecki: thank you08:26
juliankjust let me double check08:26
juliankthat bug was fixed in 1.8.0~rc108:27
pedronismvo: 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 arbitrary08:27
mborzeckijuliank: thanks for double checking! we'll update the spread images, and hopefully the problem will go away ;)08:28
mvopedronis: sure, when do you want to chat?08:30
pstolowskimvo: yes, it's possible, that's what i did originally08:31
pedronismvo: mborzecki: in 5-10 mins ?08:32
mvopstolowski: ok, maybe worth a chat with pedronis if we can give the server team something before we nail services08:32
mvopedronis: works for me, standup channel in 10min?08:33
mborzeckipedronis: sure, let me grab some coffee08:34
pstolowskimvo: sure, sounds good08:35
pedronismborzecki: mvo: I'm in the standup08:41
zygaafk for a moment08:59
pstolowskimvo, pedronis let me know if/when we can talk about firstboot & services09:12
mvopstolowski: either around 11:30 or after the standup, depends how my meeting at 11:00 goes but probably after the standup09:18
mvopstolowski: does not have to be long, just making sure we have a common understanding going into the other meeting today with server09:19
pstolowskimvo: ok, either sounds fine09:20
* zyga goes upstairs to make cofee10:04
mupPR snapd#8003 opened: o/ifacestate, api: implementation of snap disconnect --forget <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>10:18
sdhd-saschai have trouble with glibc. Is it possible to deliver my own glibc inside a snap ?10:19
zygasdhd-sascha: yes though I'd like to understand why you think that is required10:19
zygaI'll be back shortly, I really need to make that coffee10:20
* zyga gets up and leaves10:20
sdhd-saschazyga: 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 NULL10:22
sdhd-saschazyga: i already asked sergiusens. But he's really busy.10:24
sdhd-saschaMaybe there is another solution, which i didn't see. (My C++ knowledge is very old and non-practical)10:24
sdhd-saschaThis is the source, which works only without `snapcraft-preload`.10:27
sdhd-saschaWith `snapcraft-preload` one call of `realpath` failed.10:27
sdhd-saschaIs there already a non-compat glibc which could be packaged with a snap ?10:31
* sdhd-sascha lunch10:32
mborzeckihmmm - Download snap "strace-static" (18) from channel "stable" (http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug="")10:42
mvoGOAWAY is rude10:42
* mvo shakes fist10:42
mborzeckilog if anyone's interested: https://paste.ubuntu.com/p/NMRnvTRTqP/10:43
zygamvo: we should rename it to PLEASESTOP10:43
mborzeckizyga: mvo: and the client sends BENICE10:43
zygait should just return BEHAVE!10:43
mborzeckibtw https://github.com/systemd/systemd/issues/10872 is fixed, i'm trying the reproducer right now to confirm it's fine10:46
mborzecki(across a decent number of runs)10:46
Chipacais http2 secretly intercal10:48
pedronismvo: mborzecki: I made this comment in the UC20 boot PR: https://github.com/snapcore/snapd/pull/7992#issuecomment-57460940811:02
mupPR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>11:02
* sdhd-sascha re11:03
pstolowskisigh, 'git push merge master' should dwim11:03
sdhd-saschazyga: 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:05
* Chipaca brb11:06
zygasdhd-sascha: is the problem that realpath() does not behave as it is documented to?11:07
sdhd-saschazyga: 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-saschaI mean: with preload: it returns NULL instead of the path, if the seconde param is NULL.11:13
zygasdhd-sascha: can this be fixed by changing the preload library?11:13
zygasdhd-sascha: perhaps fixing it in snapcraft itself11:13
sdhd-saschazyga: 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:16
sdhd-saschaThe preload-library isn't part of snapcraft, yet. https://github.com/sergiusens/snapcraft-preload11:17
zygaI see11:17
zygasdhd-sascha: can you use dlvsym?11:17
zygait allows you to pick the version you want11:18
sdhd-saschazyga: well, i can think about it, to change all library calls... good, idea11:18
sdhd-saschazyga: what glibc version would you prefer for the future ?11:20
zygaI have no idea what I am supposed to answer11:20
sdhd-saschamaybe, 2.19 ?11:21
sdhd-saschazyga: thank you11:23
zygano idea :)11:23
zygacan you explain why one over another?11:23
zygaperhaps you should dlvsym the newset that you knew about11:24
zygaand then fall back11:24
zyganote that it is not library version11:24
zygabut symbol version11:24
zygacheck the symbol versions available for realpath11:24
zygaand probably pick the one that works the way you want11:24
zyga(one exact hit)11:24
sdhd-saschazyga: 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:24
* zyga doesn't understand how that is related11:25
zygaor doesn't understand the original question11:25
mupPR snapd#8000 closed: release: 2.43.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8000>11:25
sdhd-saschazyga: sorry. I think you understand me. My last sentence was about specific to serguissens code ;-)11:25
sdhd-saschazyga: i ask about the version. Because i would create a PR, if i get it worked. I need at least > 2.311:26
zygayou can always reimplement realpath11:27
zygaif good version in glibc -> use it11:27
zygaotherwise -> here's one from scratch11:27
sdhd-saschazyga: 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
zygasdhd-sascha: what's with /dev/shm that is a problem for your app?11:28
sdhd-saschazyga: yes. Apparmor says permission denied for /dev/shm/....11:29
zygaright, because apps tend to drop random bits of shm there and we don't want them to use it as unmediated IPC11:29
sdhd-saschaYes, and here, i first patch sway to use "mktemp...". Then the "application menu" wants to write /dev/shm too...11:30
zygainterplay of apps and /dev/shm is ... complex11:31
sdhd-saschaI mean, i patched "wlroots", which i base library for wayland desktop's.11:31
sdhd-saschaIt would be nice, if a snap could mount tmpfs over /dev/shm. But is then with xdg-proxy, i some application want to talk11:33
sdhd-saschaWhat is with xdg-proxy... I mean "inter-snap" communication of snaps over "/dev/shm"11:34
sdhd-saschazyga: you already helped me. I think i try to fix the preload-library ?!11:35
zygasdhd-sascha: I think that usage of /dev/shm must be changed and reorganized11:37
zygasdhd-sascha: currently it's pretty much like exchanging files via /tmp11:37
sdhd-saschaOh, well... What if i use dlvsym with version... And then there are some more preloads used11:37
zygasdhd-sascha: we don't have private per-snap /dev/shm because that would break everything11:37
zygasdhd-sascha: but I think something along those lines would help a _lot_11:38
sdhd-saschaMaybe, 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 convention11:39
zygawhat I was describing was a long term plan11:40
zygafor short term we need hacks and hacks and tweaks to apparmor policy11:40
zygasadly :/11:40
sdhd-saschaI think, something like chroot and overlayfs would change the snap world.11:41
zygayou can use chroot11:41
zygabut I don't think that helps with the complexity of modern IPC11:41
Chipacasdhd-sascha: do you have a minimal snapcraft with a .c that tries to use realpath and fails?11:41
zygawayland + pulseaudio == loads of /dev/shm usage11:41
sdhd-saschaThis code, fails on local machine, too. If i use the LD_PRELOAD=./libsnapcraft-preload.so11:43
sdhd-saschaon, eoan11:43
mborzeckicachio: hi, can you trigger an update of debian-sid base image?11:44
mborzeckicachio: apt in that image needs to be updated, otherwise this problem can happen occassionally https://paste.ubuntu.com/p/WVGk8pW7rF/11:45
mvoI guess "apt full-upgrade -y" is not a bad idea11:46
sdhd-saschazyga: the code above, goes in gdb the way to "glibc-2.30"/stdlib/canonicalize.c" :11:47
cachiomborzecki, hello, sure, let me take a look11:48
sdhd-saschaAnd there, it's returns NULL as path11:48
sdhd-saschaIf i use, dlvsym, then no other preload can overwrite realpath.11:50
sdhd-saschaOr, i'm wrong ? not sure11:50
zygasdhd-sascha: I dont think that works this way11:51
zygasdhd-sascha: but I cannot focus on this right now, sorry11:51
zygasdhd-sascha: dlvsym is really just "in the symbols I've loaded, find the one with the version marker as well"11:52
zygait's not "load just that version"11:52
zygayou really only open one glibc.so11:52
zygainside you look for a symbol with matching name *and* version11:52
zygathat's the trick11:52
cachiomborzecki, https://travis-ci.org/snapcore/spread-cron/builds/63619961111:52
cachiomborzecki, it was updated on  Monday11:53
cachiothe image we use for our tests11:53
sdhd-saschazyga: thank you. I was wrong. It's still possible to use other preloads, because of the loading order of the libs ;-)11:54
mupPR 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:54
mupPR snapd#8004 opened: cmd/snap: print full channel in 'snap list' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8004>11:57
Chipacapedronis: do we want snap info to explicitly point out a default track?12:02
Chipacaas in, default-track: foo if foo != ""12:02
mborzeckicachio: 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 reason12:04
cachiomborzecki, ok12:04
cachiomborzecki, we are not doing the full upgrade for sid because of this12:05
cachio    # We are not making dist-upgrade because it is creating a dependencies issue12:05
cachio    # which is making fail the preparation of the snapd test suite12:05
cachioI'll manually trigger and then we can see how it works12:05
cachiomborzecki, running12:07
cachioin case the image breaks we can revert it12:07
mvocachio: aha, this is sid? yeah, then feel free to just uprade apt12:20
cachiomvo, I updated the file and am upgrading sid, it will be ready for testing in few minutes12:21
mvocachio: nice, thank you12:22
mborzeckicachio: thanks!12:27
pedronisChipaca: there was this proposal to put a default note on the most stable risk of it12:38
pedronisChipaca: if we add default-track:  it should probably be only in --verbose12:39
Chipacapedronis:   foo/candidate ♪ :)12:44
pedronisChipaca: 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 mvo12:46
pedroniscontext: https://forum.snapcraft.io/t/the-snapd-roadmap/197312:47
mvoijohnson: sure thing, we are in the standup ho now14:59
Chipacafailures in debian-sid are expected right now, yes?15:01
sergiusenspstolowski: hey there, mind taking a look at https://github.com/snapcore/snapcraft/pull/287615:14
mupPR snapcraft#2876: meta: handle plug & slot string objects <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2876>15:14
pstolowskisergiusens: sure, with a caveat that my python foo got a bit rusty ;)15:17
pstolowskibut it's better than my vala foo ;)15:18
* zyga still fights with a bug15:39
zygaI should break for coffee and think instead of just hammering the keyboard15:39
sergiusenspstolowski: insights appreciated more around the semantics around slots/plugs than the code :-)16:02
ijohnsonmvo: 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:24
mvoijohnson: yes! feel free to edit16:30
ijohnsonmvo: cool :-)16:30
=== pedronis_ is now known as pedronis
pedronisChipaca: does our snap/partial caching do nothing in this case? https://forum.snapcraft.io/t/failure-to-fetch-assertions-stops-installation-immediately/1505916:38
Chipacapedronis: no16:40
Chipacapedronis: not if the change was aborted16:40
pstolowskisergiusens: reviewed16:46
sergiusensthanks pstolowski16:46
mupPR snapcraft#2876 closed: meta: handle plug & slot string objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2876>16:48
* cachio lunch17:01
mupPR 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:24
mupPR 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
mupPR 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>17:39
mupPR 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>18:21
mupPR snapd#8006 opened: tests: skip interfaces-network-manager on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8006>19:00
pedronisijohnson: do we still need Recovery: true in the new tests in 799219:01
mupPR snapd#8007 opened: tests: remove execution of ubuntu 19.04 from google backend <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8007>19:11
=== zylop is now known as ExplicitedE_Xplo
=== ExplicitedE_Xplo is now known as Zylop
=== Zylop is now known as zylop`
mupBug #1745772 changed: Can't run snap in lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1745772>21:41
mupBug #1664427 changed: thefuck snap gets an apparmor denial even in classic confinement <classic> <isv> <Snappy:Confirmed> <https://launchpad.net/bugs/1664427>21:44
mupBug #1675413 changed: snap disconnect doesn't support tab completion <Snappy:Fix Released> <https://launchpad.net/bugs/1675413>21:44
mupPR snapd#8008 opened: render: add the render package and basic widgets <Created by zyga> <https://github.com/snapcore/snapd/pull/8008>23:02
mupPR snapcraft#2880 opened: [RFC] schema: introduce configuration for package management repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2880>23:22

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!