[00:56] <mwhudson> anyone around who wants to talk about https://github.com/snapcore/snapd/pull/6700
[00:56] <mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
[05:19] <mborzecki> morning
[06:00] <zyga> good morning
[06:00] <zyga> mwhudson: hey
[06:00] <zyga> mwhudson: I think that's mborzecki and mvo
[06:01] <zyga> mborzecki: did you see the feedback on https://github.com/snapcore/snapd/pull/6700
[06:01] <mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
[06:09] <mborzecki> 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] <zyga> 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] <mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
[06:17] <zyga> mborzecki: https://eventhorizontelescope.org/blog/media-advisory-first-results-event-horizon-telescope-be-presented-april-10th <- something to look at later today
[06:28] <mborzecki> zyga: interesting, thanks!
[06:31] <zyga> good morning mvo
[06:32] <zyga> mvo: some feedback on https://github.com/snapcore/snapd/pull/6700
[06:32] <mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
[06:32] <mvo> hey zyga
[06:33] <mvo> zyga: looking
[06:35]  * zyga tries to control his tabs-as-backlog disease
[06:40] <mborzecki> mvo: hey
[06:54] <mvo> zyga: I replied, I guess we may need a HO with michael and alex
[07:02] <pstolowski> morning
[07:03] <zyga> mvo: there is also a response by seth arnold on the bug report
[07:03] <zyga> hello pstolowski
[07:04] <mborzecki> pstolowski: hey
[07:06] <mvo> zyga: thanks, reading this as well
[07:06] <mvo> zyga: I can understand their reaction
[07:06] <zyga> yes
[07:06] <mvo> zyga: *but* we are in a different situation - if we break devices because of -buildmode=pie its *our* head not theirs
[07:06] <zyga> well, good luck with that
[07:07] <zyga> arguably they are saying that there are other solutions
[07:08] <mvo> 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] <mvo> zyga: maybe I'm just grumpy this morning
[07:09] <mvo> zyga: I will definitely think about it
[07:09] <pedronis> mvo: notice that we don't have a regression test in that PR
[07:09] <pedronis> pie is only a part  of picture, what the go allocator does is also part of the picture
[07:09] <mvo> zyga: and we should talk about it (either in a HO or in the standup)
[07:09] <mvo> pedronis: yes
[07:11] <pedronis> I marked it blocked for now
[07:11] <mvo> 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] <mborzecki> 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] <pedronis> mvo: but that test will never be run again
[07:12] <pedronis> in the suite
[07:13] <pedronis> unless we add such a device in the lab
[07:13] <pedronis> or fake the sitution in the suite somewhere
[07:13] <mvo> 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] <mvo> pedronis: not sure I understand the suggestion/question
[07:14] <pedronis> mvo: I can undo  those changes and nothing will turn red
[07:14]  * zyga would love to listen in on the call
[07:14] <mvo> pedronis: right, so we want a test that checks if "-buildmode=pie" is really *not* used
[07:15] <zyga> if pedronis and mvo will HO please indicate so
[07:15] <pedronis> mvo: we can test that but is kind of shallow
[07:15] <mvo> zyga: sure thing - maybe its not needed - probably better if not or I will just rant
[07:15] <pedronis> because as I said pie is only one part of the problem
[07:15] <mvo> pedronis: correct
[07:16] <mvo> 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] <zyga> https://meet.google.com/gik-uony-oni?authuser=0 <- in case anyone want to meet
[07:17] <pedronis> zyga: ^
[07:17] <zyga> ack, I saw
[07:17] <mvo> pedronis: just ping us when you are ready and no worries :) maybe I'm less grumpy by hte time you had breakfast
[07:17] <zyga> mvo: join, you can vent any frustration ahead of the discussion :)
[07:18] <mvo> zyga: haaha
[07:19] <zyga> mvo: mic is not allowed
[07:19] <zyga> I can hear you though
[07:20] <zyga> mvo: my 2fa device
[07:20] <zyga> no microphone found
[07:20] <zyga> hold on :D
[07:21] <zyga> mvo: I'm a perfect listener today
[07:21] <zyga> glib or glibc
[08:01] <pstolowski> Chipaca: hey, any thoughts on https://github.com/snapcore/snapd/pull/6698#discussion_r273011330 ?
[08:01] <mup> PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
[08:03] <Chipaca> pstolowski: hm?
[08:03] <Chipaca> pstolowski: why is client/ caring about the length of it?
[08:03] <pstolowski> Chipaca: re zyga's question
[08:04] <Chipaca> re zyga's question, if it's going to get shortened, yes
[08:04] <pstolowski> Chipaca: (the unicode thing)
[08:04] <pstolowski> Chipaca: ok. it's cosmetics. thanks
[08:04] <Chipaca> pstolowski: but
[08:04] <pstolowski> i knew there will be "but" ;)
[08:05] <zyga> but then you have to handle dumb terminals
[08:05] <pstolowski> zyga: ok, no point in doing this then
[08:06] <Chipaca> my 'but' was going to be: if you want it to be <12, then it's not str[:12]+"…" (nor str[:12] + "...")
[08:07] <Chipaca> assuming str starts out as ascii, if len(12) you want str[:11]+"…", or str[:9]+"..."
[08:08] <Chipaca> if you don't know if str is ascii, then none of those slices are going to be ok
[08:10] <pstolowski> Chipaca: it's ascii only, it's for sha256 checksum string
[08:10] <Chipaca> ah, then it's fixed length!
[08:14] <Chipaca> pstolowski: what we've done elsewhere to handle that is just "%.7s…"
[08:14] <pstolowski> Chipaca: ah, indeed
[08:14] <Chipaca> pstolowski: in o/sh/backend
[08:17] <pstolowski> thanks
[08:18] <Chipaca> 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] <zyga> +1 Chipaca
[08:29] <mup> PR snapd#6577 closed: many: make Remodel() download everything first before installing <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6577>
[08:30] <pedronis> \o/
[08:30] <mvo> pedronis: I also updated the two followups
[08:30] <pedronis> ok
[08:46] <pedronis> pstolowski: I'm not sure I need to review 6698, if we switched … though, we should do it also for the vendor ?
[08:50] <pstolowski> pedronis: yes, i did it for vendor in same PR
[08:51] <pstolowski> pedronis: and np, i will ask around for 2nd review
[09:06] <pstolowski> mborzecki: hey, do you have a moment to review #6698?
[09:06] <mup> PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
[09:07] <mborzecki> pstolowski: sure, in a bit, looking at the LK pr now
[10:24] <mborzecki> need a 2nd review on #6692, it's super simple, just a cleanup
[10:24] <mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
[10:37] <mborzecki> stepping out for a bit, teachers' strike is still on but i need to take the kids to some extra classes in robotics :)
[11:08] <mborzecki> re
[11:32] <mup> PR snapd#6698 closed: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6698>
[11:41] <mborzecki> zyga: idk if you've seen this: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/7
[11:41] <mborzecki> i'm updating my fedora vm now
[11:51] <mborzecki> zyga: obviously none of that happens in a vm :/
[13:10] <mborzecki> zyga: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/12 some logs here too
[13:11] <mborzecki> looks like snap-device-helper cannot be executed?
[13:13] <mborzecki> zyga: ha, i can reproduce with 2.38 on fedora
[13:25] <zyga> mborzecki: i have not seen this yet
[13:26] <mborzecki> zyga: i cannot reproduce it with other snaps i tried where i've seen snap-device-helper being invoked too
[13:26] <zyga> eh
[13:26] <zyga> I know this bug
[13:27] <zyga> libexec vs lib
[13:27] <mborzecki> zyga: but other snaps on fedora also invoke /usr/lib/snapd/snap-device-helper and it works
[13:28] <zyga> nno
[13:28] <zyga> it's more complex than that
[13:29] <zyga> there are two consumers
[13:29] <zyga> one on the inside of the ns and one on the outside
[13:41] <mborzecki> zyga: https://paste.ubuntu.com/p/NTNMJFkkdq/ hahaha
[13:44] <mborzecki> zyga: ehh, so fedora patches their snap-device-helper to use #!/usr/bin/sh
[13:44] <mborzecki> zyga: and with base specified, we take host's libexecdir into snap mount ns right?
[13:44] <mup> PR snapcraft#2530 opened: Patchelf test branch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2530>
[14:02] <zyga> back at the office
[14:05] <zyga> mborzecki: I responded on the forum
[14:05] <zyga> mborzecki: right
[14:05] <zyga> we knew about this for a while :/
[14:05] <zyga> mborzecki: correct
[14:05] <zyga> mborzecki: it's all broken because of complexity
[14:05] <zyga> it's hard to reason about anythiign
[14:06] <zyga> and many things have to be ultra portable in consequence
[14:06] <mborzecki> zyga: still, intersting why they end up using /usr/bin/sh, probably some flatpak/ostree requirement
[14:06] <mborzecki> zyga: oh, and where that happens, i don't see anyting obvious in rpm build log
[14:07] <zyga> mborzecki: it's an automatic change
[14:08] <zyga> mborzecki: merged usr probably
[14:08] <zyga> mborzecki: I reported it when it broke spread tests
[14:09] <zyga> 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] <mborzecki> zyga: hm maybe we should just have a symlink /usr/bin/sh -> /bin/sh in core18
[14:10] <zyga> no no no
[14:10] <zyga> I mean
[14:10] <zyga> I don't care about symlinks
[14:10] <zyga> we need to fix the complexity aspect
[14:10] <zyga> and clearly indicate in each executable where it is expected to run
[14:10] <zyga> as a quick fix I would rewrite snap-device-helper in C
[14:11] <mborzecki> zyga: there was a pr from jamesh to rewrite it in go iirc
[14:11] <zyga> yes
[14:11] <zyga> I would prefer C to speed up startup time
[14:11] <zyga> it's quite expensive already
[14:12] <mborzecki> zyga: we could probably keep it within ~1M range with go
[14:12] <zyga> it doesn't need to be in go, really
[14:12] <zyga> we need to rethink
[14:12] <zyga> perhaps it is obsolete entirely
[14:12] <zyga> mborzecki: it's the fact that it is  invoked numerous times that bugs me
[14:12] <zyga> on app startup
[14:13] <mborzecki> right, but it should be cached after first call
[14:13] <zyga> but starting a 1MB executable is not free
[14:13] <zyga> anyway, I don't see the point for go there
[14:13] <zyga> or the need for the executable if we do things right
[14:13] <mborzecki> 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] <mborzecki> anyways, looks like we need to address this soon-ish
[14:15] <zyga> low-cost fix is to change fedora  package to undo  the interpreter change
[14:15] <zyga> then I would like to rip it out of snap-confine exec path
[14:15] <zyga> then the path doesn't  matter anymore
[14:15] <mborzecki> zyga: provided there isn't some made up policy that disallows that :P
[14:15] <zyga> lastly I would remove the executable entirely
[14:16] <zyga> by changing how snapd uses it
[14:19] <zyga> mborzecki: we can talk tomorrow
[14:38] <popey> zyga: something appears to have broken gl in 19.04
[14:38] <popey> snap install godot --classic, works on 18.04, 18.10, not on 19.04
[14:38] <popey> 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] <zyga> mvo: did you see https://errors.ubuntu.com/problem/5e58e04cdc647a1fd50f71f02724dd0b5b8c1f4b
[14:41] <zyga> popey: please report a bug with hardware details
[14:41] <popey> ok
[14:43] <mvo> zyga:  I did see it
[14:43] <zyga> popey: we still hope to start gl work this cycle but it's not something to be finished yet
[14:43] <zyga> mvo: any ideas? go's backtraces are useless
[14:43] <mvo> zyga: I did not really dive into it, sorry, I suspect correction
[14:43] <zyga> correction?
[14:44] <zyga>         err.data = 0x20 <error: Cannot access memory at address 0x20>
[14:44] <mvo> zyga: corruption
[14:44] <mvo> zyga: sorry
[14:44] <zyga> #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] <zyga> seems like when we try to talk to systemd something goes south
[14:45]  * mvo nods
[14:46] <popey> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168
[14:46] <mup> Bug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>
[14:47] <zyga> popey: I don't have the hardware to debug this
[14:47] <zyga> popey: but I believe it  is the switch to libgl
[14:47] <zyga> that is out of sync with 16.04 based solution currently present
[14:47] <popey> you might be able to debug in virtualbox
[14:47] <zyga> popey: how?
[14:48] <popey> run 19.04 in virtualbox and install the snap inside it
[14:48] <popey> (which also fails)
[14:48] <popey> but it works on 18.04 and 18.10 in virtualbox on the same host
[14:48] <zyga> popey: understood
[14:55] <mup> PR snapd#6706 opened: ubuntu: disable -buildmode=pie on armhf to fix memory issue <⚠ Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6706>
[15:04] <zyga> popey: https://twitter.com/zygoon/status/1115993934927421440
[15:07] <popey> shared
[15:15]  * cachio lunch
[15:17] <tomwardill> zyga: I've got a GTX 960
[15:18] <tomwardill> currently running 19.04 pre-release
[15:19] <zyga> tomwardill: and proprietary drivers?
[15:19] <tomwardill> yep
[15:20] <tomwardill> release 390, according to software center
[15:20] <zyga> 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] <tomwardill> yep
[15:20] <tomwardill> will report back in a few minutes :)
[15:20] <zyga> tomwardill: thank you, that will allow me to collect this kind of stuff into a script later
[15:20] <zyga> sure, thank you!
[15:21] <zyga> tomwardill: also, if you have any, run a non-trivial non-steam game
[15:22] <tomwardill> will factorio do?
[15:22] <zyga> tomwardill: via strace -ff  -o
[15:22] <zyga> I suspect so :)
[15:22] <zyga> and also collect the log, it may be heavier though
[15:22] <zyga> tomwardill: do you know how to reach me via email?
[15:22] <tomwardill> I can look you up in the directory :)
[15:22] <zyga> perfect
[15:25] <zyga> tomwardill: perhaps attach to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168
[15:25] <zyga> more useful this way
[15:25] <mup> Bug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>
[15:26] <zyga> I need to go AFK, running for classes
[15:26] <zyga> ttyl
[15:41] <tomwardill> zyga: added files to the bug
[16:00] <Chipaca> zyga: can a snap that exposes a content interface itself have apps?
[16:22] <cachio> https://www.irccloud.com/pastebin/NqYOg55m/
[16:22] <cachio> Chipaca:
[16:22] <mup> PR snapd#6707 opened: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests  <Created by pedronis> <https://github.com/snapcore/snapd/pull/6707>
[16:37] <cachio> mvo: hey, ubuntu-core snap is being use currently?
[16:37] <cachio> Chipaca:
[16:37] <cachio> 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] <cachio> Chipaca: any idea if it is working as designed or it is a bug?
[16:38] <Chipaca> cachio: what does a partial have to do with --dangerous?
[16:38] <Chipaca> .partial files are from the store
[16:44] <cachio> Chipaca: I implemented a new mechanism to speedup the installation of snaps on out test suite
[16:45] <cachio> Chipaca: so the idea is to download a snap and leave it in /var/lib/snapd/snaps as a .partial
[16:45] <Chipaca> cachio: right
[16:45] <Chipaca> cachio: but that only works for snaps that you download
[16:45] <Chipaca> cachio: install_local doesn't look at .partials
[16:45] <cachio> right
[16:45] <cachio> so in ubuntu core 18
[16:45] <Chipaca> I mean, literally, the code that checks .partial is in store/, it never reaches that for InstallPath
[16:45] <cachio> I install jq
[16:46] <cachio> and it uses the core_*.snap.partial
[16:46] <cachio> which is the base
[16:46] <cachio> but if I do snap install test-snapd-tools --dangerous
[16:46] <cachio> it is not resuming the .partial for core
[16:46] <cachio> so it downloads core
[16:47] <Chipaca> oh, no i got it
[16:47] <Chipaca> that sounds like a bug
[16:47] <cachio> ahh, ok
[16:47] <cachio> it should resume ritght?
[16:47] <Chipaca> yes
[16:47] <cachio> ok
[16:48] <cachio> do you want a forum post, a lp bug?
[16:48] <cachio> nothing :)
[16:49] <cachio> Chipaca: https://travis-ci.org/snapcore/spread-cron/builds/518148049#L2108
[16:49] <cachio> initially I saw that just running locally
[16:50] <cachio> but now I also see errors on the boards which run in the lab
[16:50] <Chipaca> cachio: lp bug
[16:50] <cachio> Chipaca: nice, thanks
[16:57]  * cachio akf
[16:57]  * cachio afk
[17:15] <pedronis> zyga: 6642 can land
[18:47] <zyga> pedronis: ack, thank you. I’ll land it now
[18:47] <Chipaca> zyga: can a snap that exposes a content interface itself have apps?
[18:48] <zyga> Chipaca: technically yes
[18:48] <mup> PR snapd#6642 closed: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6642>
[18:49] <zyga> E.g. a hypothetical Java JRE snap
[18:49] <zyga> Chipaca: though today I don’t know of any that do
[18:49] <zyga> I’m on a bus so please forgive my inconsistent response speed
[18:49] <Chipaca> zyga: does a snap that uses a content interface need to specify a default provider?
[18:50] <zyga> Chipaca: I believe it may but does not have to. I would have to consult specifications to see if this is required
[18:51] <Chipaca> zyga: np
[18:52] <Chipaca> 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] <zyga> Yes
[18:52] <zyga> Assuming the connection is not ambiguous
[18:52] <zyga> I don’t believe we changed that yet
[18:52] <Chipaca> zyga: ambiguous as in have more than one snap expose the same one?
[18:53] <zyga> We discussed having hints about the number of accepted connections that might allow an app to, for example, connect all plugins
[18:53] <zyga> Ambiguous as in having more than one connection candidate available
[18:54] <zyga> What are you looking at Chipaca?
[18:54] <Chipaca> zyga: some weird integration req's; i'll cc you in
[18:55] <zyga> Thank you sir!
[19:23] <jdstrand> 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] <jdstrand> s/bug/big/
[19:31] <Chipaca> jdstrand: note the forum is now in IS's hands
[19:39] <jdstrand> Chipaca: oh, I did not know that
[19:39] <jdstrand> Chipaca: does that mean RT?
[19:41] <Chipaca> jdstrand: probably
[19:46] <om26er85> come on
[19:48] <om26er> Hi! How can I make my snap be able to read a config file from ~/my_config.yaml ?
[19:49] <om26er> 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] <cachio> om26er: hi, you need to use the home interface for that
[19:55] <om26er> hmm, I do have home interface connected apparently, but $HOME seems to resolve to $SNAP_USER_COMMON still, what am I missing ?
[19:58] <cachio> om26er: which error do you see when you try to access the config file?
[20:03] <om26er> 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] <Chipaca> om26er: it's not SNAP_USER_COMMON, but yes
[20:03] <Chipaca> that's expected
[20:04] <Chipaca> om26er: if you need to get actual HOME, you'll need to use look it up
[20:05] <cachio> Chipaca: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824230
[20:05] <mup> Bug #1824230: Download not resumed for base snap when using "snap install --dangerous" <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824230>
[20:05] <om26er> Chipaca hmm, like checking if /home/$USER/my_file.yaml exists and reading that ?
[20:05] <Chipaca> om26er: or https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73
[20:09] <om26er> ^ 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] <Chipaca> om26er: what package does that require you to stage?
[20:10] <Chipaca> om26er: (it uses nothing that's not in core)
[20:10] <om26er> git-icdiff ?
[20:11] <Chipaca> om26er: that's the snap that's used on
[20:11] <Chipaca> om26er: that sed line adds a perl command at the top of the script
[20:11] <Chipaca> om26er: the perl command is the one you might want
[20:12] <Chipaca> om26er: i.e. HOME=$(perl -we "print((getpwuid $>)[7])")
[20:12] <om26er> Chipaca sorry, I misunderstood that, seems it just work :)
[20:12] <Chipaca> no problem
[20:12] <mup> PR snapcraft#2531 opened: snap: revert to patchelf 0.9 with local patches <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2531>
[20:12] <om26er> thanks Chipaca
[20:15] <zyga> Chipaca: can I land https://github.com/snapcore/snapd/pull/6690 ?
[20:15] <mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
[20:15] <Chipaca> zyga: you can land _everything_
[20:15] <zyga> that's very encouraging
[20:15] <zyga> landing then :)
[20:15] <mup> PR snapd#6690 closed: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6690>
[20:16] <Chipaca> 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] <roadmr> https://memegen.link/_eHkJbGFuZC9hbGxfdGhlX3RoaW5ncwkJ.jpg
[20:16] <Chipaca> zyga: what roadmr said
[20:16] <zyga> Chipaca: woot
[20:16] <zyga> I'm off to watch black hole stuff with my kids
[20:17] <zyga> we have to watch it in spanish because that's the best intersection of comprehension and quality :D
[20:22] <Chipaca> zyga: https://xkcd.com/2135/
[20:23] <zyga> that's great
[20:23] <zyga> it's really difficult to talk about the scale of that thing using human scales
[20:23] <zyga> ha
[20:23] <Chipaca> yeah, my scales only go up to about 120kg
[20:24] <zyga> and the author is wrong here
[20:24] <zyga> the event horizon is much smaller than the black ring
[20:24] <zyga> er, black hole inside the ring
[20:24] <zyga> so voyager woud be surely "past" it in this sense
[20:25] <zyga> anyway, very exciting times to live :)
[20:29] <Chipaca> zyga: also, https://www.youtube.com/watch?v=zUyH3XhpLTo
[21:34] <ahasenack> 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] <ahasenack> is it because it was too fast? Is there a way to tell when snapd is ready?
[21:36] <ijohnson> ahasenack: try using `snap wait system seed.loaded`
[21:39] <ahasenack> that seems to have helped
[21:46] <mup> Bug #1824240 opened: snapd can't be purged with latest AWS Xenial AMI <Snappy:New> <https://launchpad.net/bugs/1824240>
[21:52] <mup> Bug #1824240 changed: snapd can't be purged with latest AWS Xenial AMI <Snappy:New> <https://launchpad.net/bugs/1824240>
[21:58] <mup> PR snapcraft#2531 closed: snap: revert to patchelf 0.9 with local patches <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2531>
[22:31] <sergiusens> cmatsuoka: just manually tested the new edge using 0.9+snapcraft, seems like we are back in business
[22:44]  * cachio afk
[23:07] <mup> PR snapcraft#2530 closed: Patchelf test branch <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2530>