[00:56] anyone around who wants to talk about https://github.com/snapcore/snapd/pull/6700 [00:56] PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> [05:19] morning [06:00] good morning [06:00] mwhudson: hey [06:00] mwhudson: I think that's mborzecki and mvo [06:01] mborzecki: did you see the feedback on https://github.com/snapcore/snapd/pull/6700 [06:01] PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> [06:09] zyga: hi, yeah, i've seen it, i think maybe we should hold the pr for a bit and wait for the feedback about kernel patches [06:10] pedronis: https://github.com/snapcore/snapd/pull/6642 is green and has +2, do you want to review it or can I merge it? [06:10] PR #6642: cmd/snap-confine: prevent cwd restore permission bypass [06:17] mborzecki: https://eventhorizontelescope.org/blog/media-advisory-first-results-event-horizon-telescope-be-presented-april-10th <- something to look at later today [06:28] zyga: interesting, thanks! [06:31] good morning mvo [06:32] mvo: some feedback on https://github.com/snapcore/snapd/pull/6700 [06:32] PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> [06:32] hey zyga [06:33] zyga: looking [06:35] * zyga tries to control his tabs-as-backlog disease [06:40] mvo: hey [06:54] zyga: I replied, I guess we may need a HO with michael and alex === pstolowski|afk is now known as pstolowski [07:02] morning [07:03] mvo: there is also a response by seth arnold on the bug report [07:03] hello pstolowski [07:04] pstolowski: hey [07:06] zyga: thanks, reading this as well [07:06] zyga: I can understand their reaction [07:06] yes [07:06] zyga: *but* we are in a different situation - if we break devices because of -buildmode=pie its *our* head not theirs [07:06] well, good luck with that [07:07] arguably they are saying that there are other solutions [07:08] zyga: yes, to me this is about risks. a) risk of random bug because -buildmode=pie is hardly tested and barely supported upstream b) risk of not having buildmode=pie preventing a security issue - at this point risk(a) > risk(b) to me [07:09] zyga: maybe I'm just grumpy this morning [07:09] zyga: I will definitely think about it [07:09] mvo: notice that we don't have a regression test in that PR [07:09] pie is only a part of picture, what the go allocator does is also part of the picture [07:09] zyga: and we should talk about it (either in a HO or in the standup) [07:09] pedronis: yes [07:11] I marked it blocked for now [07:11] pedronis: what do you have in mind for such a test? in a sense the entire testsuite is a regression test. if we have a 32bit system with a 4.4 kernel that does not have the two patches mentioned in the LP bugreport then the testsuite will not survive 5s. so in a sense we have a regression test. or do you think we need soemthing that tests that we really don't have -buildmode=pie? [07:12] anyways, it was fun debugging that issue :) wish we had perf on the device, then maybe we could finger point the exact line where mmap2 failed [07:12] mvo: but that test will never be run again [07:12] in the suite [07:13] unless we add such a device in the lab [07:13] or fake the sitution in the suite somewhere [07:13] pedronis: maybe a HO? I may be too slow this morning [07:14] * zyga notices more BPF love https://lwn.net/Articles/785263/ [07:14] pedronis: not sure I understand the suggestion/question [07:14] mvo: I can undo those changes and nothing will turn red [07:14] * zyga would love to listen in on the call [07:14] pedronis: right, so we want a test that checks if "-buildmode=pie" is really *not* used [07:15] if pedronis and mvo will HO please indicate so [07:15] mvo: we can test that but is kind of shallow [07:15] zyga: sure thing - maybe its not needed - probably better if not or I will just rant [07:15] because as I said pie is only one part of the problem [07:15] pedronis: correct [07:16] pedronis: ok, maybe a HO afterall? I think this is complex (or might become complex) [07:16] * pedronis needs to have breakfast first [07:16] https://meet.google.com/gik-uony-oni?authuser=0 <- in case anyone want to meet [07:17] zyga: ^ [07:17] ack, I saw [07:17] pedronis: just ping us when you are ready and no worries :) maybe I'm less grumpy by hte time you had breakfast [07:17] mvo: join, you can vent any frustration ahead of the discussion :) [07:18] zyga: haaha [07:19] mvo: mic is not allowed [07:19] I can hear you though [07:20] mvo: my 2fa device [07:20] no microphone found [07:20] hold on :D [07:21] mvo: I'm a perfect listener today [07:21] glib or glibc === chihchun_afk is now known as chihchun [08:01] Chipaca: hey, any thoughts on https://github.com/snapcore/snapd/pull/6698#discussion_r273011330 ? [08:01] PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries [08:03] pstolowski: hm? [08:03] pstolowski: why is client/ caring about the length of it? [08:03] Chipaca: re zyga's question [08:04] re zyga's question, if it's going to get shortened, yes === chihchun is now known as chihchun_afk [08:04] Chipaca: (the unicode thing) [08:04] Chipaca: ok. it's cosmetics. thanks [08:04] pstolowski: but [08:04] i knew there will be "but" ;) [08:05] but then you have to handle dumb terminals [08:05] zyga: ok, no point in doing this then === chihchun_afk is now known as chihchun [08:06] my 'but' was going to be: if you want it to be <12, then it's not str[:12]+"…" (nor str[:12] + "...") [08:07] assuming str starts out as ascii, if len(12) you want str[:11]+"…", or str[:9]+"..." [08:08] if you don't know if str is ascii, then none of those slices are going to be ok [08:10] Chipaca: it's ascii only, it's for sha256 checksum string [08:10] ah, then it's fixed length! [08:14] pstolowski: what we've done elsewhere to handle that is just "%.7s…" [08:14] Chipaca: ah, indeed [08:14] pstolowski: in o/sh/backend [08:17] thanks [08:18] zyga does have a point about dumb terminals, but for … we don't worry too much (it's supported on the default framebuffer font, and if it's not supported the resulting rhombus is not too hard to figure out) [08:22] +1 Chipaca [08:29] PR snapd#6577 closed: many: make Remodel() download everything first before installing [08:30] \o/ [08:30] pedronis: I also updated the two followups [08:30] ok [08:46] pstolowski: I'm not sure I need to review 6698, if we switched … though, we should do it also for the vendor ? [08:50] pedronis: yes, i did it for vendor in same PR [08:51] pedronis: and np, i will ask around for 2nd review [09:06] mborzecki: hey, do you have a moment to review #6698? [09:06] PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries [09:07] pstolowski: sure, in a bit, looking at the LK pr now === chihchun is now known as chihchun_afk [10:24] need a 2nd review on #6692, it's super simple, just a cleanup [10:24] PR #6692: interfaces: cleanup internal tool lookup in system-key [10:37] stepping out for a bit, teachers' strike is still on but i need to take the kids to some extra classes in robotics :) === ricab is now known as ricab|bbl [11:08] re [11:32] PR snapd#6698 closed: overlord/ifacestate: introduce HotplugKey type use short key in change summaries [11:41] zyga: idk if you've seen this: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/7 [11:41] i'm updating my fedora vm now [11:51] zyga: obviously none of that happens in a vm :/ [13:10] zyga: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/12 some logs here too [13:11] looks like snap-device-helper cannot be executed? [13:13] zyga: ha, i can reproduce with 2.38 on fedora [13:25] mborzecki: i have not seen this yet [13:26] zyga: i cannot reproduce it with other snaps i tried where i've seen snap-device-helper being invoked too [13:26] eh [13:26] I know this bug [13:27] libexec vs lib [13:27] zyga: but other snaps on fedora also invoke /usr/lib/snapd/snap-device-helper and it works [13:28] nno [13:28] it's more complex than that [13:29] there are two consumers [13:29] one on the inside of the ns and one on the outside === chihchun_afk is now known as chihchun [13:41] zyga: https://paste.ubuntu.com/p/NTNMJFkkdq/ hahaha [13:44] zyga: ehh, so fedora patches their snap-device-helper to use #!/usr/bin/sh [13:44] zyga: and with base specified, we take host's libexecdir into snap mount ns right? [13:44] PR snapcraft#2530 opened: Patchelf test branch [14:02] back at the office [14:05] mborzecki: I responded on the forum [14:05] mborzecki: right [14:05] we knew about this for a while :/ [14:05] mborzecki: correct [14:05] mborzecki: it's all broken because of complexity [14:05] it's hard to reason about anythiign [14:06] and many things have to be ultra portable in consequence [14:06] zyga: still, intersting why they end up using /usr/bin/sh, probably some flatpak/ostree requirement [14:06] zyga: oh, and where that happens, i don't see anyting obvious in rpm build log [14:07] mborzecki: it's an automatic change [14:08] mborzecki: merged usr probably [14:08] mborzecki: I reported it when it broke spread tests [14:09] mborzecki: our spread tests take the incorrect assumption that a locally built snapd can work in re-exection context and can be injected into core snaps [14:10] zyga: hm maybe we should just have a symlink /usr/bin/sh -> /bin/sh in core18 [14:10] no no no [14:10] I mean [14:10] I don't care about symlinks [14:10] we need to fix the complexity aspect [14:10] and clearly indicate in each executable where it is expected to run [14:10] as a quick fix I would rewrite snap-device-helper in C [14:11] zyga: there was a pr from jamesh to rewrite it in go iirc [14:11] yes [14:11] I would prefer C to speed up startup time [14:11] it's quite expensive already [14:12] zyga: we could probably keep it within ~1M range with go [14:12] it doesn't need to be in go, really [14:12] we need to rethink [14:12] perhaps it is obsolete entirely [14:12] mborzecki: it's the fact that it is invoked numerous times that bugs me [14:12] on app startup [14:13] right, but it should be cached after first call [14:13] but starting a 1MB executable is not free [14:13] anyway, I don't see the point for go there [14:13] or the need for the executable if we do things right [14:13] and we could write it in minimal go, like print() instead of fmt.* [14:13] * zyga is not conviniced by any of that [14:14] anyways, looks like we need to address this soon-ish [14:15] low-cost fix is to change fedora package to undo the interpreter change [14:15] then I would like to rip it out of snap-confine exec path [14:15] then the path doesn't matter anymore [14:15] zyga: provided there isn't some made up policy that disallows that :P [14:15] lastly I would remove the executable entirely [14:16] by changing how snapd uses it [14:19] mborzecki: we can talk tomorrow [14:38] zyga: something appears to have broken gl in 19.04 [14:38] snap install godot --classic, works on 18.04, 18.10, not on 19.04 [14:38] We had this with 18.10 iirc, is there some hard-wired path that's changed again? [14:41] * zyga doesn't know and remarks that the gl solution is a hack that outgrew its usefulness vs cost [14:41] mvo: did you see https://errors.ubuntu.com/problem/5e58e04cdc647a1fd50f71f02724dd0b5b8c1f4b [14:41] popey: please report a bug with hardware details [14:41] ok [14:43] zyga: I did see it [14:43] popey: we still hope to start gl work this cycle but it's not something to be finished yet [14:43] mvo: any ideas? go's backtraces are useless [14:43] zyga: I did not really dive into it, sorry, I suspect correction [14:43] correction? [14:44] err.data = 0x20 [14:44] zyga: corruption [14:44] zyga: sorry [14:44] #3 0x0000563c3ac477a7 in github.com/snapcore/snapd/systemd.SdNotify (notifyState=..., ~r1=...) at /build/snapd-DbAuQM/snapd-2.38+18.04/_build/src/github.com/snapcore/snapd/systemd/sdnotify.go:51 [14:45] seems like when we try to talk to systemd something goes south [14:45] * mvo nods [14:46] zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168 [14:46] Bug #1824168: classic opengl application on 19.04 fail to find gl drivers

[14:47] popey: I don't have the hardware to debug this [14:47] popey: but I believe it is the switch to libgl [14:47] that is out of sync with 16.04 based solution currently present [14:47] you might be able to debug in virtualbox [14:47] popey: how? [14:48] run 19.04 in virtualbox and install the snap inside it [14:48] (which also fails) [14:48] but it works on 18.04 and 18.10 in virtualbox on the same host [14:48] popey: understood [14:55] PR snapd#6706 opened: ubuntu: disable -buildmode=pie on armhf to fix memory issue <⚠ Critical> === ricab|bbl is now known as ricab [15:04] popey: https://twitter.com/zygoon/status/1115993934927421440 [15:07] shared [15:15] * cachio lunch [15:17] zyga: I've got a GTX 960 [15:18] currently running 19.04 pre-release [15:19] tomwardill: and proprietary drivers? [15:19] yep [15:20] release 390, according to software center [15:20] tomwardill: can you pastebin lsmod, dpkg -S nvdia-* (not sure what the package names are); run a steam game and while it is running cat /proc/pid-of-game/maps [15:20] yep [15:20] will report back in a few minutes :) [15:20] tomwardill: thank you, that will allow me to collect this kind of stuff into a script later [15:20] sure, thank you! [15:21] tomwardill: also, if you have any, run a non-trivial non-steam game [15:22] will factorio do? [15:22] tomwardill: via strace -ff -o [15:22] I suspect so :) [15:22] and also collect the log, it may be heavier though [15:22] tomwardill: do you know how to reach me via email? [15:22] I can look you up in the directory :) [15:22] perfect [15:25] tomwardill: perhaps attach to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168 [15:25] more useful this way [15:25] Bug #1824168: classic opengl application on 19.04 fail to find gl drivers

[15:26] I need to go AFK, running for classes [15:26] ttyl [15:41] zyga: added files to the bug [16:00] zyga: can a snap that exposes a content interface itself have apps? [16:22] https://www.irccloud.com/pastebin/NqYOg55m/ [16:22] Chipaca: [16:22] PR snapd#6707 opened: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests === pstolowski is now known as pstolowski|afk [16:37] mvo: hey, ubuntu-core snap is being use currently? [16:37] Chipaca: [16:37] Chipaca: Chipaca: There is an issue when we install with --dangerous, which is that it is not resuming a .partial file for hte base snap and it is affecting the core18 tests when we run install_local xxxx [16:38] Chipaca: any idea if it is working as designed or it is a bug? [16:38] cachio: what does a partial have to do with --dangerous? [16:38] .partial files are from the store [16:44] Chipaca: I implemented a new mechanism to speedup the installation of snaps on out test suite [16:45] Chipaca: so the idea is to download a snap and leave it in /var/lib/snapd/snaps as a .partial [16:45] cachio: right [16:45] cachio: but that only works for snaps that you download [16:45] cachio: install_local doesn't look at .partials [16:45] right [16:45] so in ubuntu core 18 [16:45] I mean, literally, the code that checks .partial is in store/, it never reaches that for InstallPath [16:45] I install jq [16:46] and it uses the core_*.snap.partial [16:46] which is the base [16:46] but if I do snap install test-snapd-tools --dangerous [16:46] it is not resuming the .partial for core [16:46] so it downloads core [16:47] oh, no i got it [16:47] that sounds like a bug [16:47] ahh, ok [16:47] it should resume ritght? [16:47] yes [16:47] ok [16:48] do you want a forum post, a lp bug? [16:48] nothing :) [16:49] Chipaca: https://travis-ci.org/snapcore/spread-cron/builds/518148049#L2108 [16:49] initially I saw that just running locally [16:50] but now I also see errors on the boards which run in the lab [16:50] cachio: lp bug [16:50] Chipaca: nice, thanks [16:57] * cachio akf [16:57] * cachio afk [17:15] zyga: 6642 can land [18:47] pedronis: ack, thank you. I’ll land it now [18:47] zyga: can a snap that exposes a content interface itself have apps? [18:48] Chipaca: technically yes [18:48] PR snapd#6642 closed: cmd/snap-confine: prevent cwd restore permission bypass [18:49] E.g. a hypothetical Java JRE snap [18:49] Chipaca: though today I don’t know of any that do [18:49] I’m on a bus so please forgive my inconsistent response speed [18:49] zyga: does a snap that uses a content interface need to specify a default provider? [18:50] Chipaca: I believe it may but does not have to. I would have to consult specifications to see if this is required [18:51] zyga: np [18:52] zyga: does a content interface exposed by a snap and used by another get connected when you install one of the two and have the other one installed? [18:52] Yes [18:52] Assuming the connection is not ambiguous [18:52] I don’t believe we changed that yet [18:52] zyga: ambiguous as in have more than one snap expose the same one? [18:53] We discussed having hints about the number of accepted connections that might allow an app to, for example, connect all plugins [18:53] Ambiguous as in having more than one connection candidate available [18:54] What are you looking at Chipaca? [18:54] zyga: some weird integration req's; i'll cc you in [18:55] Thank you sir! [19:23] niemeyer: hey, not a bug deal, but it seems the forum checkbox plugin thing went away again (ie, I can't see it in https://forum.snapcraft.io/t/manual-review-for-squaremetrics-ble-scanner/10836/2) [19:23] s/bug/big/ [19:31] jdstrand: note the forum is now in IS's hands [19:39] Chipaca: oh, I did not know that [19:39] Chipaca: does that mean RT? [19:41] jdstrand: probably [19:46] come on [19:48] Hi! How can I make my snap be able to read a config file from ~/my_config.yaml ? [19:49] My software reads its runtime configuration from that file, So basically a user can just open that file, edit it and then run my snap [19:51] om26er: hi, you need to use the home interface for that [19:55] hmm, I do have home interface connected apparently, but $HOME seems to resolve to $SNAP_USER_COMMON still, what am I missing ? [19:58] om26er: which error do you see when you try to access the config file? [20:03] cachio my snap is not able to see that file because it expands $HOME to /home/om26er/snap/surc/14 instead of /home/om26er [20:03] om26er: it's not SNAP_USER_COMMON, but yes [20:03] that's expected [20:04] om26er: if you need to get actual HOME, you'll need to use look it up [20:05] Chipaca: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824230 [20:05] Bug #1824230: Download not resumed for base snap when using "snap install --dangerous" [20:05] Chipaca hmm, like checking if /home/$USER/my_file.yaml exists and reading that ? [20:05] om26er: or https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73 [20:09] ^ that's intelligent though I'll find a somewhat similar solution that doesn't require me to stage a new package in my snap [20:10] om26er: what package does that require you to stage? [20:10] om26er: (it uses nothing that's not in core) [20:10] git-icdiff ? [20:11] om26er: that's the snap that's used on [20:11] om26er: that sed line adds a perl command at the top of the script [20:11] om26er: the perl command is the one you might want [20:12] om26er: i.e. HOME=$(perl -we "print((getpwuid $>)[7])") [20:12] Chipaca sorry, I misunderstood that, seems it just work :) [20:12] no problem [20:12] PR snapcraft#2531 opened: snap: revert to patchelf 0.9 with local patches [20:12] thanks Chipaca [20:15] Chipaca: can I land https://github.com/snapcore/snapd/pull/6690 ? [20:15] PR #6690: overlord/snapstate: inhibit refresh for up to a week [20:15] zyga: you can land _everything_ [20:15] that's very encouraging [20:15] landing then :) [20:15] PR snapd#6690 closed: overlord/snapstate: inhibit refresh for up to a week [20:16] zyga: the one i'd asked you to hold, i'd tagged with blocked, and then removed the tag when it was done [20:16] https://memegen.link/_eHkJbGFuZC9hbGxfdGhlX3RoaW5ncwkJ.jpg [20:16] zyga: what roadmr said [20:16] Chipaca: woot [20:16] I'm off to watch black hole stuff with my kids [20:17] we have to watch it in spanish because that's the best intersection of comprehension and quality :D [20:22] zyga: https://xkcd.com/2135/ [20:23] that's great [20:23] it's really difficult to talk about the scale of that thing using human scales [20:23] ha [20:23] yeah, my scales only go up to about 120kg [20:24] and the author is wrong here [20:24] the event horizon is much smaller than the black ring [20:24] er, black hole inside the ring [20:24] so voyager woud be surely "past" it in this sense [20:25] anyway, very exciting times to live :) [20:29] zyga: also, https://www.youtube.com/watch?v=zUyH3XhpLTo [21:34] hm, hi, I just got this error in a script that installs snapd, and then a snap: https://pastebin.ubuntu.com/p/VHpxMY9grP/ [21:35] is it because it was too fast? Is there a way to tell when snapd is ready? [21:36] ahasenack: try using `snap wait system seed.loaded` [21:39] that seems to have helped [21:46] Bug #1824240 opened: snapd can't be purged with latest AWS Xenial AMI [21:52] Bug #1824240 changed: snapd can't be purged with latest AWS Xenial AMI [21:58] PR snapcraft#2531 closed: snap: revert to patchelf 0.9 with local patches [22:31] cmatsuoka: just manually tested the new edge using 0.9+snapcraft, seems like we are back in business [22:44] * cachio afk [23:07]