[02:28] <nacc> doko: thanks, will work on it on monday
[06:46] <cpaelzer> good morning!
[07:23] <rbasak> o/
[07:35] <cpaelzer> o/ rbasak
[08:00] <dupondje> lets hope we quickly have a firefox update :P
[08:00] <dupondje> seems its broken on all ubuntu's now :x
[08:16] <rbasak> dupondje: is there a bug on this please?
[08:18] <dupondje> https://bugs.launchpad.net/bugs/1659922
[08:19] <dupondje> the fix is easy :)
[08:26] <rbasak> dupondje: looks like this bug is a complete regression but only for users with an enforcing Firefox AppArmor profile. But this is not the default. Is this correct?
[08:27] <rbasak> dupondje: what's the fix? I don't see one.
[08:28] <rbasak> Ah, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239/comments/3 may be a reasonable fix.
[08:39] <dupondje> rbasak: well don't know whats the default apparmor status is ... :)
[08:47] <rbasak> dupondje: AFAICT, Firefox ships with a non-enabled-by-default AppArmor profile. Users can enable it, but it restricts Firefox. The new Firefox does stuff that the AppArmor profile doesn't permit to the point of complete breakage.
[10:36] <caribou> who's the resident expert on systemd nowadays ?
[10:36] <caribou> I'd appreciate a second look at LP: #1654600
[10:40] <seb128> caribou, not sure we have a "resident" one but you can try xnox or slangasek
[10:40] <caribou> seb128: yeah, thought so
[10:44] <infinity> caribou: Your analysis sounds reasonable.  systemctl list-dependencies will give you a tree that you might sort of be able to parse to understand what your changes do.
[10:44] <infinity> caribou: Which is better than testing and being subject to "oh, I beat the race, I must have fixed the bug" logic.
[10:45] <caribou> infinity: that was my worry, especially since the window where the lock might be taken can be quite short
[10:45] <caribou> infinity: that and I'm not too found of a unit *starting* when we're shutting down but that's debatable
[10:46] <infinity> caribou: It's a oneshot, starting or stopping amount to the same thing.
[10:46] <infinity> caribou: (But it may be true that claiming Start or Stop might subtly change ordering)
[10:47] <caribou> infinity: apparently not in that case as ExecStart will only be triggered after the Before= are shutdown
[10:47] <caribou> infinity: anyway thanks for looking
[10:48] <infinity> caribou: Though, ExecStop isn't even documented in systemd.unit... Did you make it up? :)
[10:48] <caribou> infinity: documented in services
[10:48] <infinity> Ahh, indeed.  Silly docs.
[10:51] <infinity> caribou: Docs claim that ExecStop won't run at all unless a service is actually running, though.
[10:52] <infinity> caribou: Which for a oneshot, then gets trickier.
[10:52] <infinity> caribou: See "Example 3. Stoppable oneshot service"
[10:53] <caribou> infinity: hence the RemainAfterExit
[10:53] <caribou> infinity: well, this seems to work, I'm just worried about "just being lucky"
[10:53] <infinity> caribou: Yeah, but that won't do anything without an ExecStart, surely.
[10:54] <infinity> (or something to start)
[10:54] <caribou> infinity: k,I'll double-check that
[10:54] <infinity> Maybe it will, though.  I dunno.
[10:54] <infinity> Easy to check.  "start" it, and then check status.
[10:54] <infinity> If it's running, you won, if not, you didn't, and your stop will never run.
[11:27] <ginggs> infinity: is it ok to sync libv8-3.14 now? it builds on ppc64el but not powerpc, and powerpc is no longer a release architecure in ubuntu, right?
[11:27] <infinity> ginggs: We haven't dropped it yet.
[11:27] <infinity> ginggs: We don't have a concept of "release" and "non-release" architectures.  It's in until it's out.
[11:28] <infinity> ginggs: But no reason it can't be synced after we definitely do drop it.
[11:29] <infinity> "Add support for powerpc, ppc and ppc64el platform merging patch from Ubuntu"
[11:29] <infinity> That implies it added ppc32 support too, though?
[11:29] <ginggs> infinity: ok, well i'm not sure it will not build ubuntu, but it didn't in debian
[11:30] <ginggs> infinity: and i can't test in a PPA :(
[11:30] <infinity> Hrm.  It looks like it wouldn't indeed.
[11:30] <infinity> Curious what they broke in taking our patch. :P
[11:31] <infinity> ginggs: Ask me in a few days, and I can maybe help clean it up.
[11:31] <ginggs> infinity: ok, thanks
[13:43] <dupondje> chrisccoulson: how are things going with firefox? :)
[14:50] <elopio> Laney: are you around? We are having issues with the armhf autopktest again.
[14:51] <seb128> elopio, he's on vac today (doesn't mean he's not going to look to IRC at some point but you probably shouldn't count on it)
[14:59] <elopio> seb128: thanks for the info. I've sent an RT, but I'm not sure if they have control over those machines.
[15:00] <seb128> elopio, you can maybe try people in the foundations team as well
[15:00] <seb128> they are the ones supposed to maintain that service
[15:00] <seb128> or at least p_itti was in their team so I guess they had some handover
[15:03] <elopio> slangasek: anybody else from your team can poke the armhf autopkgtest machines?
[15:04] <elopio> infinity: and for the record, now the problem is rustup, which doesn't know what to do when it receives armv8l :)
[15:07] <cjwatson> You probably always want to look into fixing the package that's failing as well
[15:07] <cjwatson> Not to say that the infra shouldn't take the conservative route, but it's still a bug in the package.
[15:18] <elopio> cjwatson: I will report a bug in rust. It's no package, it's a curl | bash: https://github.com/rust-lang/rustup.sh/blob/master/rustup.sh#L1551
[15:33] <slangasek> elopio: so, what the issue regarding armhf autopkgtest machines?  I don't see excessive armhf-specific queues, has this already been resolved?
[15:35] <cjwatson> slangasek: apparently they're running without the compat_uts_machine=armv7l (or whatever it is exactly) command line hack to stop uname reporting armv8l
[15:38] <elopio> slangasek: related to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520627
[15:38] <elopio> uname regressed to return armv8l
[15:40] <slangasek> elopio: ah, you're saying there's been a change in behavior on the test runners?
[15:52] <chiluk> slangasek mind sponsoring https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1660372 since you are the debian uploader?
[15:53] <chiluk> also cyphermox can I get sponsorship for https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/1660362
[15:55] <chiluk> also slangasek cyphermox if this request annoyed you https://wiki.ubuntu.com/chiluk/CoreDevApplication  ... my DMB coredev meeting is this afternoon.
[15:56]  * cyphermox looks
[15:57] <slangasek> chiluk: ah; I saw a mail from you that suggested I had already missed the deadline before I'd even read the mail, so I hadn't followed up :)
[15:57] <chiluk> slangasek ... DMB didn't reach quorum last meeting.
[15:57] <slangasek> "the debian uploader" - well, I'm /a/ Debian uploader, who doesn't upload it
[15:58] <chiluk> slangasek... stop beign so pedantic.
[15:58] <chiluk> Uploaders: Steve Langasek <vorlon@debian.org>, Christian Perrier <bubulle@debian.org>, Noèl Köthe <noel@debian.org>, Jelmer Vernooĳ <jelmer@debian.org>, Mathieu Parent <sathieu@debian.org>
[15:58] <chiluk> you were listed first...  must make you important..
[15:59] <slangasek> chiluk: it's ok you have slavic background I give you pass for definite and indefinite article confusion
[15:59] <chiluk> is true.
[16:02] <slangasek> chiluk: half of your merge changelog is false because it is not a remaining change
[16:04] <slangasek> elopio: so when did this regress?  I'm not aware of any changes we've made to the armhf autopkgtest runners recently
[16:09] <slangasek> elopio: also, that kernel bug says it's fixed for xenial in 4.4.0-3.17; porter-arm64 is running a later linux-lts-xenial generic kernel, and uname -m returns armv8l.  Perhaps this regressed in the kernel?
[16:09] <chiluk> slangasek you are absolutely correct.
[16:10] <elopio> slangasek: we noticed on Friday. Last time this happened, Iain said something about rebooting the machines.
[16:10] <slangasek> elopio: I can't imagine why rebooting the machines would fix the uname output...
[16:11] <slangasek> chiluk: ok, changelog edited locally, and uploading
[16:11] <elopio> ¯\_(ツ)_/¯
[16:11] <chiluk> thanks slangasek...shame on me..
[16:11] <slangasek> elopio: can you point me to specific autopkgtest logs showing the failure?
[16:11] <chiluk> I checked for the keyutils.. but didn't occur to me that you might have fixed debian.
[16:12] <cjwatson> slangasek,elopio: it's certainly worth checking /proc/cmdline if you can ...
[16:12] <cjwatson> maybe they somehow got rebooted without the override param
[16:12] <elopio> slangasek: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20170129_193742_803b1@/log.gz
[16:12] <elopio> search for rustup: unknown CPU type: armv8l
[16:13] <cjwatson> that seems more likely than a kernel regression, just in an Occam's razor kind of way :)
[16:18] <slangasek> oh, this requires a kernel parameter? it doesn't just dtrt under linux32?
[16:20] <cjwatson> slangasek: No, for reasons, basically that it was too late by the time we noticed this was a problem and the 32-on-64 ABI was already defined
[16:21] <cjwatson> slangasek: my memory was indeed correct and it's spelled compat_uts_machine=armv7l
[16:21] <cjwatson> slangasek: LP builders run with that
[16:27] <elopio> cjwatson: btw, do you know why is it that our armhf executions are slower?
[16:28] <cjwatson> elopio: executions where?
[16:36] <elopio> cjwatson: on those autopkgtest machines.
[16:36] <elopio> this is armhf: Ran 28 tests in 3581.469s
[16:36] <elopio> this is amd64: Ran 28 tests in 2746.484s
[16:37] <cjwatson> elopio: I know nothing about the autopkgtest machines.
[16:37] <cjwatson> Can't help you.
[16:38] <cjwatson> elopio: My comments above are just from sharing experience with how the LP builders are configured.
[16:39] <elopio> I know. I was just wondering :)
[16:40] <elopio> not a big deal anyway because now we are moving some platforms to the nightly run.
[16:46] <dobey> elopio: different load on the machines when the tests ran?
[16:47] <elopio> dobey: this was on sunday morning, I think no other tests were running. But maybe.
[16:56] <hallyn> Is there a way for non Canonical employees to verify whether someone has signed the CLA?
[16:59] <jgrimm> hallyn, "Canonical Contributor Agreement" team participation
[17:11] <hallyn> jgrimm: not sure that's reliable - i'm not listed there
[17:13] <jgrimm> hallyn, wonder if you are part of a team that has membership
[17:14] <jgrimm> hallyn, or something missing because you are a former canonical employee?  no idea
[17:15] <hallyn> ok - thanks.  it's not terribly important, guy had a merge request against vmbuilder.  but that's being forked on github anyway so i asked him to resubmit as  PR there where no CLA requirement exists
[17:16] <jgrimm> hallyn, if i look at your lp profile I'm able to see that you've signed.. is that field not visible if you look at someone elses id?
[17:17] <jgrimm> hallyn, cool
[17:21] <hallyn> jgrimm: where do you see that?
[17:21] <jgrimm> hallyn, i was wrong. sorry
[17:21] <hallyn> ok
[18:02] <hallyn> hm.     i don't seem able to push to lp:vmbuilder
[18:02] <hallyn> wonder whether it has to do with the switch to git
[18:04] <hallyn> hm, no, i seem to have been dropped from vmbuilder-dev
[18:05] <nacc> hallyn: wouldn't it be lp:vm-builder?
[18:05] <nacc> hallyn: oh i see there's a distinct 'upstream'
[18:05] <hallyn> no
[18:06] <hallyn> yeah that naming was always funky
[18:06] <hallyn> anyway, now someone needs to approve my membership, but there's noone to do that
[18:06] <hallyn> maybe mvo
[18:06] <hallyn> oh, smoser
[18:06] <hallyn> smoser: can you hit approve on my request to join vmbuilder?
[18:07] <smoser> here ? https://launchpad.net/~vmbuilder/+members#proposed
[18:07] <smoser> i dont see you
[18:08] <hallyn> sorry, no, vmbuilder-dev
[18:09] <smoser> apparently, i cannot
[18:09] <smoser> soren ^ ?
[18:09] <hallyn> lol
[19:00] <rbasak> !dmb-ping
[19:35] <elopio> slangasek: did you find anything about armv8l ?
[19:45] <slangasek> elopio: I'm just getting sshed in over there now, it's been a stack of meetings this morning
[19:50] <elopio> slangasek: thank you.
[20:01] <elopio> slangasek: Sergio told me to mention the alternative of skipping the rust tests for now in armhf, as this is blocking our SRU.
[20:02] <elopio> I know you don't like skips so I'm scared while I say this :)
[20:03] <elopio> I can make sure that they pass in rpi3.
[20:13] <slangasek> barry, tdaitx: what do you know about administering the armhf lxd autopkgtest runners?  I don't seem to have creds to ssh into the guests, and can't reach the host
[20:14] <slangasek> elopio: which SRU is blocking on this?
[20:14] <elopio> slangasek: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1659946
[20:32] <sergiusens> slangasek: I didn't push yet to xenial or yakkety as I wanted zesty to pass
[20:32] <sergiusens> slangasek: we can either disable the tests that use rust which has the machine detection problem or wait for the fix
[20:41] <barry> slangasek: i don't believe i have access either unfortunately
[20:49] <slangasek> barry: hrm, so this wasn't part of the training from pitti?
[20:49] <barry> slangasek: no.  i suppose we need to talk to is to give more of us access
[20:50] <slangasek> mmk
[20:59] <chiluk> Dmitrii-Sh: can i get an upload for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225
[21:00] <chiluk> Dmitrii-Sh: I have a feeling you are asleep by now... but maybe you can catch it in the morning.
[21:00] <Dmitrii-Sh> chiluk: 1 sec
[21:00] <chiluk> oh awesome.
[21:00] <chiluk> you just seem to be doing lots of qemu uploads recently
[21:00] <chiluk> so I figured I'd ping you.
[21:01] <Dmitrii-Sh> chiluk: oh, well I cannot do uploads myself yet
[21:02] <mwhudson> infinity: hey, does this look like a glibc bug do you? https://bugs.launchpad.net/snapd/+bug/1657504/comments/18
[21:02] <chiluk> oh ok.. ah I understand you have just packaged up public patches.
[21:02] <Dmitrii-Sh> chiluk: those were patches I was seeking sponsorship for basically
[21:02] <chiluk> thanks Dmitrii-Sh I'll find someone else to sponsor the uploa.. I should have checked your perms.
[21:03] <Dmitrii-Sh> chiluk: ok, np at all
[21:03] <chiluk> good night Dmitrii-Sh
[21:03] <Dmitrii-Sh> chiluk: thx
[21:17] <infinity> mwhudson: Maybe?  But I'd have to see more debug output.  I'm shocked to discover we're using runpath for this.  I guess I naively assumed snaps ran chrooted *in* the core snap somehow.
[21:18] <infinity> mwhudson: So, yes, this may well be a bug, as this is very infrequently exercised code, because Who Does That?
[21:19] <mwhudson> infinity: this is for classic snaps
[21:19] <mwhudson> which are a different breed of hack
[21:23] <infinity> mwhudson: On the other hand, some googling suggests the behaviour is correct, and the docs are muddy.
[21:27] <mwhudson> infinity: hm ok
[21:28] <mwhudson> the docs are not muddy, they are wrong :)
[21:29] <infinity> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638
[21:32] <infinity> mwhudson: That Qt blog seems to be frequently referenced from anyone else discussing the issue.  I'd like to think it being widely-known for 6+ years would mean someone might have mentioned it upstream. :P
[21:33] <mwhudson> infinity: what DT_RUNPATH is only 13 years old, do you think people are actually using it yet? :)
[21:34] <mwhudson> infinity: open since 2012 https://sourceware.org/bugzilla/show_bug.cgi?id=13945
[21:35] <infinity> 'The current gABI says "One object's DT_RUNPATH entry does not affect the
[21:35] <infinity> search for any other object's dependencies."'
[21:35] <mwhudson> oh heh https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html
[21:36] <mwhudson> ubuntulog_: lol
[21:36] <mwhudson> ubottu: lol
[21:36] <mwhudson> "The application or library can use whatever
[21:36] <mwhudson> prefix it put in its DT_RUNPATH on the strings it passes to dlopen directly."
[21:36] <mwhudson> except the library is sodding nss
[21:36] <slangasek> elopio, sergiusens: I would prefer having the failing test selectively disabled in the package on armhf (yes, my views on skip-test are well known! ;). but yes, I'm willing to ignore the test failure manually on a one-time basis if that helps.
[21:36] <infinity> mwhudson: So, yeah.  I think ld and dlopen are spec-compliant here.
[21:37] <slangasek> elopio, sergiusens: of course, disabling it in the package would mean working around an infrastructure issue, so ignore that I even said that. Yes, I'll skip-test this for you.
[21:37] <mwhudson> infinity: fair enough
[21:37] <infinity> mwhudson: One could argue that libc itself might want a RUNPATH to be able to find its own modules.
[21:37] <infinity> mwhudson: And I'd entertain that line of reasoning.
[21:37] <sergiusens> slangasek: sounds good
[21:37]  * sergiusens sees runpath/rpath conversations everywhere now
[21:37] <infinity> mwhudson: But I tihnk what snappy is trying to do here is RPATH (or LD_LIBRARY_PATH), not RUNPATH.
[21:38] <mwhudson> infinity: the thing that makes this extra fun is that the core snap is sometimes at / (for strict confinemt) and sometimes at /snap/core/current (for classic)
[21:38] <mwhudson> sergiusens: you can't escape!!!
[21:39] <infinity> mwhudson: Fun.  glibc isn't exactly the only library with plugins.  It's just the most obvious one.
[21:39] <infinity> mwhudson: And I bet some *do* set RUNPATH, and that'll break if you're relocating them.
[21:39] <mwhudson> yep
[21:39] <infinity> Kinda sounds like this all needs LD_LIBRARY_PATH wrappers of doom.
[21:40] <mwhudson> infinity: zyga is talking about patching the dynamic linker in the core snap
[21:40] <mwhudson> which is kinda the extreme version of that i guess
[21:40] <mwhudson> infinity: tbf we don't have to care about all libraries here
[21:40] <infinity> Patching it to do what?
[21:40] <mwhudson> just ones in the core snap
[21:41] <mwhudson> infinity: change search paths depending on whether the process is a classic confinement snap or not
[21:41] <infinity> I'm fundamentally opposed to ld.so (and, by extension, glibc) differing between a classic Ubuntu system and the ubuntu core snap.
[21:42] <infinity> For so many reasons.
[21:42] <infinity> So very many.
[21:42] <zyga> infinity: oh, thouse would not differe
[21:42] <zyga> infinity: on core we don't support confinement: classic snaps
[21:42] <infinity> zyga: Then expand on "patching the linker in the core snap".
[21:42] <zyga> infinity: we could ship the same glibc everywhere
[21:42] <mwhudson> ups kinda outstayed my welcome in this cafe biab
[21:43] <zyga> infinity: the core snap is used as the "runtime part" of supporting confinement: classic snaps on "classic" ubuntu
[21:43] <zyga> (the word classic has three meanings, sorry about that)
[21:43] <zyga> (classic snap on core, classic ubuntu and classic confinement)
[21:43] <infinity> zyga: Yes.  I get that.
[21:43] <infinity> zyga: I'm curious how you intend to patch the linker without patching the linker.
[21:43] <zyga> infinity: I intend to patch the linker and ship it everywhere in ubuntu (and upstream if possible, but not required)
[21:44] <sergiusens> slangasek: I'll be pushing something shortly then
[21:44] <zyga> infinity: simply the effect would only be visible on classic ubuntu running classic confinement snaps
[21:44] <zyga> infinity: (or any classic distro for that matter)
[21:45] <zyga> but that case is perhaps more complex so let's solve the easier case first
[21:46] <infinity> zyga: FWIW, as both glibc maintainer in Ubuntu and an upstream committer, I'm likely to push back on this unless it's got some very sane rationale, obvious thought about security considerations for heuristic lookup relocations, and some really solid likely/unlikely branching that makes it a near no-op for most cases.
[21:46] <infinity> zyga: But happy to see initial rough cuts of what you *mean* at least, so I can maybe steer in another direction. :P
[21:47] <zyga> infinity: ok, you have much better understanding of the internals than I do, perhaps just the simple goal statement would work; if you think that goal is hard to achieve (or unlikely for other reason) we can abort the process early
[21:48] <zyga> infinity: the goal is to have a way where people can unpack debs into their confinement:classic snaps (or just build something locally without voodoo) and have that work*
[21:48] <zyga> infinity: without the use of mount namespaces
[21:48] <zyga> infinity: so that it uses predictable (good) dynamic linker and shared libraries
[21:48] <infinity> And how do you envision that looking on the filesystem?
[21:48] <zyga> infinity: on the filesystem it looks as follows
[21:49] <infinity> Can I have both ubuntu-core 16 and ubuntu-core 18 snaps installed?  How do I know which one is which when I do a magic lookup?
[21:49] <zyga> infinity: the core snap is mounted at /snap/core/current (current is a symlink) but we are allowed to rely on it
[21:49] <zyga> infinity: yes, they would be different base snaps (gimme a sec)
[21:49] <infinity> Kay.  I'll go for a smoke while you type and come back to the full explanation. :)
[21:50] <zyga> infinity: the snap in question (say hello-classic) is monted at a similar location /snap/hello-classic/current/
[21:50] <zyga> infinity: when you execute hello-classic wrapper generated by snapd, via snap-run/snap-confine/snap-exec the predictable dynamic linker from the core snap is invoked (side-stepping any linke in the distro)
[21:51] <zyga> infinity: dynamic libraries should be resolved from the core snap, from the snap in question (hello-world) and not from the classic distro
[21:52] <zyga> infinity: when you exec something then we need to be careful (hence glibc patches) to intercept that and use our linker again
[21:52] <zyga> infinity: unless the executable is outside of /snap, where the normal behavior is expected (no magic)
[21:52] <infinity> So, all binaries have a wrapper?
[21:52] <zyga> infinity: similar redirection should happen when dlopen is used, it should not rely on libraries from classic distribution
[21:52] <zyga> infinity: no, just declared apps
[21:52] <zyga> infinity: but those are the only entry points
[21:53] <infinity> If you have a wrapper, I'm not sure why you need a special linker.  You can set LD_LIBRARY_PATH
[21:53] <zyga> infinity: but once you run (say declared app foo) you can freely exec any internal executable on the core snap, in your snap or on the host distro
[21:53] <zyga> infinity: that would leak to the child processes and it is not sufficient to ensure we use the right dynamic linker
[21:54] <zyga> infinity: that's my idea (so far), please tell me what you think
[21:54] <zyga> infinity: as a closing remark: classic confinement works "almost" allright as long as you build software from source
[21:55] <zyga> infinity: but it breaks if you want to use prebuilt software that people are more familiar with
[21:55] <zyga> infinity: (the only thing that breaks is the glibc bug that mwhudson found)
[21:55]  * zyga turns all ears
[21:55] <mwhudson> zyga: which apparently is not a bug and maybe snapcraft should use rpath not runpath after all
[21:59] <infinity> zyga: How do you propose finding the "correct" linker without specifying it manually?
[21:59] <infinity> http://paste.ubuntu.com/23896033/
[22:00] <infinity> Note that if I don't specify it there, I get the host system's linker/libc/libnss, which also works fine.
[22:02] <infinity> Or, you're proposing the host ld.so first checks the binary's path, then forks the ld.so in the ubuntu-core root?
[22:03] <zyga> infinity: snap-exec would know that it runs a confinement-classic app nffsdfsdfsfdsdfsdfadasd
[22:03] <zyga> re
[22:03] <zyga> sorry, lost connection
[22:03] <zyga> infinity: snap-exec would run the desired application through the right linker if it was instructed to do so by snapd
[22:03] <chiluk> hey cyphermox.. here's the qemu bug I'm needing sponsorship on https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225
[22:03] <zyga> infinity: so to be clear, running executables directly from (e.g. from shell) would not work
[22:04] <zyga> infinity: it would only work if it got initiated by snap-exec
[22:04] <zyga> infinity: and if we implement glibc changes to exec, from any process that uses classic confinement
[22:04] <zyga> infinity: looking at the pastebin now
[22:04] <infinity> zyga: Okay, so no linker changes needed there if snap-exec is divining which one to call.  ld.so is itself an executable for this very use-case.
[22:04] <sergiusens> mwhudson: let me do a test run with rpath
[22:05] <zyga> infinity: not directly, we'd run the linker instead of the executable in snapd
[22:05] <zyga> infinity: the host linker would never see the executable
[22:05] <mwhudson> sergiusens: s/--enable-new-dtags//g or whatever?
[22:05] <mwhudson> sergiusens: would be interesting to see
[22:06] <zyga> infinity: I don't know if this would work for the case that mwhudson found but perhaps we were just using the feature incorrectly due to bugs in the documentation
[22:06] <zyga> (though reading the elf spec I find this aspect confusing)
[22:06] <zyga> infinity: (the dlopen case)
[22:06] <infinity> zyga: Oh, s/RUNPATH/RPATH/ will definitely fix mwhudson's issue, but it does nothing for your pre-build binary case.
[22:07] <zyga> infinity: correct
[22:07] <infinity> And fixing the prebuilt binary case means you don't need RPATH in the from-source case either.
[22:07] <zyga> infinity: but there (I hope) we can patch the linker to chage its behavior
[22:07] <infinity> So that seems like a distraction.
[22:07] <zyga> infinity: oh? sorry, can you explain please?
[22:07] <zyga> infinity: how would it work for pre-build binaries?
[22:07] <infinity> zyga: You read my statement backwards. :)
[22:08] <zyga> infinity: ah
[22:08] <zyga> infinity: correct
[22:08] <infinity> zyga: I'm saying that if there's a solution for pre-built binaries, from-source doesn't need RPATH hacks, as they can be built with the same assumptions as a deb was.
[22:08] <zyga> (kids-going-to-bed-moment, sometimes distracting)
[22:08] <zyga> infinity: yes, I understand and totally agree
[22:08] <zyga> thanks
[22:09] <infinity> I'm still knee-jerking at the claim that the linker needs any special knowlege of this.
[22:09] <zyga> infinity: I think someone has to change the default search path, can it be anything but the linker?
[22:09] <zyga> infinity: does the linker take any arguments we could use?
[22:10]  * zyga runs --help to see 
[22:10] <infinity> --help won't help much. ;)
[22:10] <zyga> infinity: do you think setting --library-path is sufficient?
[22:11] <infinity> --library-path is effectively the same as LD_LIBRARY_PATH.
[22:11] <zyga> mmm, that's very promising then
[22:11] <zyga> infinity: but that still leaves the exec case open
[22:11] <infinity> Though, may fix your concern about leak-on-fork.
[22:11] <zyga> infinity: yes, it does fix the leak
[22:11] <zyga> infinity: and seems like a much cleaner solution
[22:12] <infinity> (FWIW, tangentially related, but I think relying on 'current' symlinks is incredibly short-sighted here)
[22:13] <infinity> Right now, you have one core ABI.  When 18 happens, you'll have two.  Without a flag day where all apps upgrade at once, you *need* any library-path wrapping magic to use versioned paths.
[22:13] <zyga> infinity: I think the plan for core will change before 18, AFAIK the idea is that we will have many base snaps and still exactly one core
[22:14] <zyga> infinity: and what you think of core will largely become base
[22:14] <zyga> infinity: (core will be a small snap with mostly just snapd itself)
[22:14] <infinity> And linker/libc?
[22:14] <zyga> infinity: if we had many bases then each classic confinement snap will link against a specific core
[22:15] <zyga> infinity: unclear, this is hand-wavy territory
[22:15] <zyga> infinity: I think it is safe to say that we'll see base-16 and base-18 (perhaps base-16 will just be called base for legacy reasons)
[22:15] <infinity> I mean, I know we've been kind enough to give you a stable ABI for almost 2 decades, but one should always prepare for their world being rocked by libc7. ;)
[22:15] <zyga> infinity: if we were to say that we cannot rely on the current symlink we can still resolve things correctly by running ld.so directly, I suspect
[22:16] <zyga> infinity: was it two decades already? wow
[22:16] <infinity> Anyhow, I'd think an app meant to run against core-16 should know that, and the wrappers should be set up to know that.
[22:16] <zyga> infinity: in case abi does change we should be fine as we can always run the right dynamic linker for each particular snap
[22:16] <zyga> infinity: right, the snap/app knows that and so does snapd
[22:17] <sergiusens> mwhudson: https://asciinema.org/a/bjzuw6ujlg3l39cx1ai1bn6ii
[22:17] <zyga> infinity: if we don't use rpath/dt-runpath and instead use ld.so directly I think we don't have a problem with (eventual) abi transitions, right?
[22:17] <infinity> zyga: It certainly makes life easier.
[22:17] <zyga> infinity: we only have the exec patch for glibc that lives in core/base
[22:18] <zyga> infinity: (still assuming that is needed unless we can find a way to make do away with it)
[22:18] <infinity> zyga: Which exec patch?
[22:18] <infinity> Did we just run full circle? :)
[22:18] <zyga> infinity: the (theorethical) patch that would allow a process to exec anything and still DTRT
[22:19] <zyga> infinity: maybe, bare with this for a moment
[22:19] <zyga> infinity: a process running under classic confinement can exec anything it wants from the core snap
[22:19] <zyga> infinity: if it runs /snap/core/current/bin/true we need to intercept that
[22:19] <infinity> zyga: IMO, any snap that's on the path should be taking care of its own runtime setup.  So, if it needs a wrapper, the thing on the path is a wrapper.
[22:19] <zyga> infinity: or it would again run with the system dynamic linker, right?
[22:20] <zyga> infinity: that's at odds with reusing prebuilt software where you don't know anything about that and at odds with not leaking LD_LIBRARY_PATH
[22:20] <infinity> zyga: Ahh.  I see.
[22:20] <infinity> zyga: So, if a snap runs /bin/true, you want it to run the core version, not the host version.
[22:20] <zyga> infinity: I think it is fine to limit this special behavior to just processes started by a snap
[22:20] <infinity> (true probably being a stupid example, but I get the point)
[22:21] <zyga> infinity: well, not really, /bin/true should be the host true
[22:21] <zyga> infinity: but /snap/core/*/bin/true should be the core version
[22:21] <zyga> infinity: e.g. imagine a bash shell snap
[22:21] <infinity> Why would a snap ever call something in that namespace that way?
[22:21] <zyga> infinity: it should be able to run stuff normally
[22:21] <zyga> infinity: when you said namespace did you mean to refer to linux namespaces or was it just a word clash?
[22:22] <infinity> My brain predates linux namespaces. :)
[22:22] <zyga> infinity: classic confinement snaps are allowed to use core resources _and_ host resources if they want to
[22:22] <zyga> hehe :)
[22:22] <zyga> infinity: so if you build a quick snap with stuff from firefox.deb
[22:22] <infinity> That feels like a strange design choice.
[22:22] <zyga> infinity: it should work fine even if it wants to run something from your distro
[22:23] <zyga> infinity: as long as it works fine by itself (I mean, it should not link to distro libs but it can run any executable and expect it to work normally)
[22:23] <zyga> infinity: that's the design we've got, perhaps I misunderstand mark's intent but I think it feels like a "this is what you can count on but you can use anything you like"
[22:23] <nacc> doko: in ldb 2:1.1.26-1ubuntu1, you changed -Xldb.so to -Xldb. in override_dh_makeshlibs. Was that intentional?
[22:24] <zyga> infinity: it should allow people to use snaps quickly without learning new things
[22:24] <doko> nacc: I assume that's an oversight
[22:24] <nacc> doko: and, iiuc, the reason to switch from -c4 to -c3 in that release was since a new library was being introduced for python3?
[22:25] <zyga> infinity: or even having to use devmode confinement (and have various other issues)
[22:25] <nacc> doko: ok, np, just wanted to confirm, I'll probably ahve other questions : )
[22:25] <zyga> infinity: if we can deliver that
[22:25] <infinity> zyga: But doesn't it seem odd to have people calling things in that bizarre path?
[22:25] <zyga> infinity: I think that's a big win
[22:25] <zyga> infinity: no, why? if I tell firefox snap to use "evince" from my system to open PDFs then it should just do that
[22:25] <zyga> infinity: it depends on each case but I think it is an important "no-barriers" design decision
[22:26] <infinity> I don't want to muddly my code with calls to /snap/core/current/usr/bin/thing when what I really want is to call 'thing' and get a working one if one exists.
[22:26] <zyga> infinity: move off debs/rpms/random stuff to stuff with no barriers in place
[22:27] <infinity> Or are you prepending all the /snap/blah paths to PATH and hoping for the best?
[22:27] <zyga> infinity: I'm doing neither, I don't think I understand your concern
[22:27] <infinity> Cause that way does indeed lie madness.  You're calling into a chroot without chrooting.
[22:28] <zyga> infinity: can you make an exaple, I think this is not mad and it should work OK but perhaps we're confusing something
[22:28] <infinity> zyga: So, you say that people should be free to use /snap/core/*/bin/command despite NOT being chrooted.  How do you expect them to call it?  On PATH, or directly, or?
[22:29] <zyga> infinity: I think I see your point, I didn't mention this but it should not be allowed (supported) to run /snap/* executables from the classic distro without going through /snap/bin and the snap-exec in the way
[22:29] <zyga> on the way
[22:30] <zyga> infinity: once that has happened (you ran via snap-exec) you should be able to execute any executable on the system correctly though
[22:30] <zyga> infinity: as long as you give your app and entry point (which we control) this seems like a reasonable limitation
[22:30] <zyga> infinity: e.g. a bash classic snap would work normally
[22:30] <zyga> infinity: so would any less demanding program
[22:30] <infinity> zyga: No, I'm not talking about how to run a snap from classic.  I'm talking about a snap itself forking.
[22:31] <zyga> infinity: ok, so a snap itself forks
[22:31] <zyga> infinity: if it chooses to exec something from the host that's fine (no patches needed), right?
[22:31] <infinity> zyga: And you're saying a forking snap should be able to call binaries inside core.
[22:31] <infinity> zyga: How is it calling them?
[22:31] <zyga> infinity: it would go through the systmem linker
[22:31] <zyga> infinity: yes
[22:31] <zyga> infinity: and that's the place where I believe we need to patch glibc
[22:32] <infinity> How.  Is.  It.  Calling.  Them?
[22:32] <zyga> infinity: so that exec is changed to exec via core's ld.so
[22:32] <infinity> You bring up a "bash snap" (I assume you mean a shell script).  Is that shell script calling things as /snap/core/current/bin/thing?
[22:32] <zyga> infinity: (I meant bash itself deployed as a snap)
[22:33] <infinity> Well, bash itself is just a binary like any other.
[22:33] <zyga> infinity: yes but let's say you want to snap install bash
[22:33] <infinity> There's nothing special about it.
[22:33] <zyga> infinity: (some new version)
[22:33] <zyga> infinity: and use that on your system for everything
[22:33] <zyga> infinity: (e.g. your login shell)
[22:33] <zyga> infinity: (* not everything but daily stuff)
[22:33] <zyga> infinity: you'd expect that bash to have no unreasonable limitations
[22:33] <jdstrand> I don't want to get embroiled in this cause infinity will be able to recomend the best course of action, but, if I ship 'foo' as a snap, aiui, /snap/bin/foo should use core's libraries/etc but 'foo' exec'ing 'ture' should get the host's 'true'. it going to /snap/core/current/bin/true seems like a huge corner case
[22:34] <infinity> Then /snap/bin/bash is a wrapper that configures it correctly.  This isn't relevant to the forking thing.
[22:34] <zyga> infinity: correct
[22:34] <infinity> So, again, no glibc patching.  Check.
[22:34] <zyga> infinity: what if in bash I run /snap/core/current/bin/true
[22:34] <jdstrand> if it wants to call its own stuff, it needs to use /snap/bin
[22:34] <infinity> Why are you running that?
[22:34] <jdstrand> yes, why?
[22:35] <zyga> infinity: because any app can run any command from core transparently as a normal course of action
[22:35] <infinity> How is that a use-case we want to waste any time supporting?
[22:35] <zyga> infinity: and that is supported today in other snaps
[22:35] <infinity> Any confined app can, yes.
[22:35] <zyga> infinity: and removing this would surely break something
[22:35] <infinity> classic apps are meant to run as if they're on the hose system.
[22:35] <zyga> infinity: (e.g. stuff running stuff via system() and what not)
[22:35] <jdstrand> I think the use cases are incredibly few
[22:35] <infinity> s/hose/host/
[22:35] <zyga> jdstrand: I disagree, we specifically say that you can rely on anything in the core snap being there
[22:36] <zyga> jdstrand: this translates to people using that
[22:36] <infinity> zyga: Here's the fundamental difference.  A confined app runs /bin/true and gets the core version.  To get the core version in a classic app, you have to obtusely call /snap/core/version/bin/true
[22:36] <zyga> jdstrand: and I don't think we want binary wrappers for any executable in the core snap
[22:36] <zyga> infinity: correct
[22:36] <jdstrand> zyga: classic, aiui, is about running your stuff as a snap and able to call the host's stuff without issue. calling into /snap/.../ without going through /snap/bin is totally unreasonable imho
[22:36] <infinity> zyga: The latter use-case makes zero sense to me.  This isn't about transparently supporting something.
[22:37] <zyga> infinity: hmm, I disagree, if I know that core snap has well-defined "awk" I may just decide to use it
[22:37] <zyga> infinity: why would it be unreasonable?
[22:37] <zyga> infinity: core snaps run in an unknown world where the only save heaven is the core snap
[22:37] <zyga> infinity: if we say that they cannot run any executable in the core snap then that feels like a broken story
[22:37] <infinity> zyga: Because calling into a weird chroot path is exactly the opposite of transparently running on the host system? :P
[22:38] <jdstrand> zyga: the one case I could see as interesting is foo wants to calls something in its own $SNAP, but that is easily remedied by exposing that thing being in /snap/bin
[22:38] <infinity> If your goal is for classic to have all the same features as a confined snap, you will fail.
[22:38] <infinity> Period.
[22:38] <zyga> jdstrand: except that's not something that they do today
[22:38] <jdstrand> zyga: but classic is fundamentally different than devmode or strict
[22:38] <zyga> infinity: that's not my goal but the goal is to offer classic as a simple way to have more things working as a snap, I think that not allowing to run executables from the core snap is at odds with that idea
[22:39] <zyga> jdstrand: technically yes but we should do our best to make that seem less so
[22:39] <zyga> jdstrand: it's a step towards devmode towards strict
[22:39] <infinity> zyga: And, to be clear, to support your use-case, you need to patch the HOST libc, not the core one.  Which means either this only works on Ubuntu, or you need to patch *all* host libcs.  If it only works on Ubuntu, we have a set of things people can rely on for classic snaps, it's called "Essential: yes" in dpkg/apt.
[22:39] <zyga> infinity: can you tell me why I'd have to patch the host libc?
[22:39] <jdstrand> zyga: my understanding of what is desired is to be able to run your thing and anything on the host, not your thing, anything on the host and any arbitrary thing in /snap that happens to have the x bit set
[22:40] <infinity> zyga: Because you're calling /snap/foo/bin/true, and the kernel is invoking the host ld.so.
[22:40] <infinity> zyga: Welcome to ELF.
[22:40] <zyga> infinity: I know, but my idea was that since this would *only* be allowed from classic confinement snaps
[22:40] <zyga> infinity: those would run with our libc
[22:40] <zyga> infinity: and those could have patched exec that injects the linker at that time
[22:41] <zyga> infinity: (as I said this doesn't apply to someone just wanting to run /snap/core/current/bin/true from outside of a snap)
[22:41] <jdstrand> why would they only use our libc?
[22:41] <jdstrand> classic isn't supported on other distros?
[22:41] <zyga> jdstrand: because on all distros they would link to our libc
[22:41] <zyga> jdstrand: via the ld.so trick we discussed earlier
[22:41] <infinity> Eh?
[22:42] <infinity> One of your stated goals for classic is to not rebuild binaries in special ways.
[22:42] <zyga> I think there's something fundamental that I'm either wrong about or I didn't state earlier
[22:42] <jdstrand> the ld.so trick was a snap run thing (ie /snap/bin wrapper), no?
[22:42] <zyga> infinity: correct,
[22:42] <zyga> jdstrand: correct
[22:42] <jdstrand> so, this thing is running now
[22:42] <zyga> jdstrand: and at that time you run against our libc
[22:42] <jdstrand> it execs /snap/random/binary
[22:43] <zyga> jdstrand: becuase our linker ran /snap/random/binary
[22:43] <jdstrand> that is going to use the host's libc
[22:43] <zyga> jdstrand: with altered library paths
[22:43] <zyga> jdstrand: no
[22:43] <zyga> jdstrand: that's the part I disagree aobut
[22:43] <zyga> *about
[22:43] <infinity> That's not how linkers work.
[22:43] <zyga> jdstrand: wait, sorry, (lag on irc)
[22:43] <zyga> infinity: I know what you mean
[22:43] <zyga> my assertion is as follows:
[22:44] <zyga> any app that *starts* executing via snap-exec + ld.so trick uses our libc?
[22:44] <zyga> can we all agree on that?
[22:44] <jdstrand> that sounds reasonable to me
[22:44] <infinity> I run /snap/bin/foo, which is a wrapper that calls into the core linker and loads foo with the core ld.so and libc.  So far, we're on the same page.  Then foo invokes /snap/core/current/bin/true, THAT will load with the system ld.so
[22:44] <zyga> yes
[22:44] <zyga> I agree and that's why I keep saying I think we need to patch our libc to do something different then
[22:44] <infinity> No.
[22:44] <zyga> how can a process run another application? only via exec right?
[22:45] <zyga> infinity: I agree that as things stand now /snap/core/current/bin/true will load with the distro/system ld.so
[22:45] <infinity> There are many entry points to the fork syscall.
[22:45] <infinity> What you want is a kernel patch, not a libc patch.  And you don't want a kernel patch either. :P
[22:45] <zyga> infinity: fork != exec, fork doesn't hurt us
[22:46] <zyga> infinity: I bet we can do this with just libc, what else is there? what am I missing?
[22:47]  * jdstrand reasserts that running /snap/core/current/bin/true would not be a case we should support. classic gives you your snap, /snap/bin and running host binaries. period. anything random executable in /snap is not supported by snapd proper, but a snap could invoke it on its own
[22:47] <jdstrand> (by setting whatever enviornment it wanted)
[22:47] <infinity> zyga: fork is exactly the case we were discussing.
[22:47] <zyga> jdstrand: that's not what mark described; I'm not arguing with you
[22:47] <zyga> jdstrand: I don't disagree with your POV but if we're asked to support /snap/core in its entirety that's what we need to do
[22:48] <jdstrand> zyga: I wasn't in those meetings but what I've read on the subject, I'm surprised /snap/core/current/bin/true is meant to be a supported use case
[22:48] <zyga> infinity: can you tell me how forking is a problem?
[22:48] <zyga> jdstrand: I can ask mark / gustavo to clarify
[22:48] <infinity> zyga: You want to be able to fork /snap/core/current/bin/true ... You can't.
[22:48] <zyga> jdstrand: but regardless I'd like to understand if we can technically do it
[22:48] <infinity> And I don't understand why you'd want to.
[22:49] <zyga> infinity: I think you exec /snap/core/current/bin/true, not fork it (then we agree)
[22:49] <zyga> infinity: fork just forks the process, right?
[22:49]  * jdstrand said his piece and wanders off
[22:49] <infinity> exec replaces a process with another process, fork creates a child process.
[22:49] <infinity> You may well want both, but both are fundamentally silly in this context.
[22:49] <zyga> infinity: and exec is a library call via glibc (I agree that it would not block someone going at the raw syscall)
[22:50] <zyga> infinity: ok we are in agreement on this; fork is not a problem because it doesn't interact with any of the parts at play, exec is the only point where we have issues
[22:50] <infinity> system(), for instance, is a fork.
[22:50] <infinity> Calling any process from a shell script is a fork.
[22:50] <zyga> infinity: fork + exec
[22:50] <infinity> Calling anything from python is a fork.
[22:50] <zyga> infinity: yes
[22:50] <zyga> infinity: sure but I don't see any issues in fork alone
[22:50] <infinity> Some languages use the raw syscall to do so.
[22:51] <zyga> infinity: you just have a new process running the same thing at that time
[22:51] <infinity> ...
[22:51] <zyga> infinity: that's interesting and that's indeed a problem
[22:51] <jdstrand> I will say one other thing. executing something in /snap/random/... is not a path towards devmode since that isn't at all supported by devmode
[22:51] <infinity> BUT YOU WANT TO ALLOW PEOPLE TO FORK /snap/core/current/bin/true
[22:51] <infinity> Just no.
[22:51] <zyga> infinity: (please don't shout at me, I'm trying to understand technical side, I want people to fork+exec /snap/core/bin/true and my assertion is still that with patched exec that's well possible to achieve
[22:52] <infinity> Classic snaps on Ubuntu have a defined set of things available to them.  It's called Essential.
[22:52] <zyga> jdstrand: except that /snap/core/current/bin/random may be allowed by the default policy or by an interface, then we do allow that
[22:52] <infinity> Classic snaps on other distros might not have such a set, but we can't "fix" that without patching the HOST.
[22:52] <sarnold> infinity: fork(2) absolutely must remain available. THat's how most unixy processes do threading.
[22:52] <jdstrand> zyga: but not at /snap/core/current/bin/random. /snap/core/current/bin/random isn't in your PATH
[22:52] <infinity> sarnold: Erm, yes.  But not relevant to this discussion.
[22:52] <zyga> jdstrand: that's true
[22:53] <zyga> infinity: I don't want to argue if it is a good idea to support that thing
[22:53] <jdstrand> so a classic snap has to go *completely* out of its way to call something in /snap/random/...
[22:53] <zyga> infinity: just to understand if it is technicaly doable
[22:53] <infinity> zyga: It's not doable without patching the host.  Host libc for reasonable coverage, host kernel for total coverage.
[22:53] <zyga> jdstrand: ok, I agree but I think we need to spin this around a little
[22:53] <zyga> jdstrand: let's forget about core
[22:53] <infinity> zyga: Neither of those seems like a thing we should do.
[22:54] <jdstrand> if it is going to do all that, it can call with the right linker or we can provide a helper for it to use that calls the linker
[22:54] <zyga> jdstrand: a snap can run its own apps
[22:54] <zyga> jdstrand: and if that's just a random app they have inside they should be ale to run it
[22:54] <zyga> jdstrand: and they cannot run it on !classic confinement if they expose it as an app
[22:54] <infinity> Sure, running their own stuff is simple, though, as they should be exposing it with the same wrapper style as the primary binary was.
[22:54] <zyga> infinity: that's not as simple as you think, we have some strong semantics of what that means
[22:55] <zyga> infinity: and they don't have to use any wrappers, today, to run executables from the same snap
[22:55] <jdstrand> zyga: core doesn't run anything. as for the random app of its own, that is the only interesting case. I think exposing that in /snap/bin is not unreasonable. both would be in its path
[22:55] <jdstrand> but, there is perhaps some thinking that needs to be done there
[22:55] <zyga> jdstrand: but that also lets users see it and it may not be something you wanted
[22:55] <zyga> jdstrand: and it would have different name
[22:55] <zyga> jdstrand: e.g. /snap/bin/$SNAP_NAME.foo
[22:55] <zyga> jdstrand: so breaks unpacking debs
[22:55] <infinity> So snap needs a libexec concept.
[22:56] <jdstrand> I understand. that is why I said it is the interesting case
[22:56]  * zyga is still convinced that we need to path exec to achieve transparency (except syscalls, I totally agree with infinity on that)
[22:56]  * jdstrand has to run
[22:56] <zyga> the libexec idea is intereting
[22:56] <zyga> I think it is worth exploring
[22:56] <zyga> e.g. for snapctl
[22:56] <zyga> jdstrand: o/
[22:57] <zyga> infinity: sorry for being so tought in this conversation, I really want to understand what we are standing on now
[22:57] <zyga> infinity: and I'm not desigining anything, just implementing a design (that I may misunderstand as it stands)
[22:57] <infinity> Well, designs can sometimes be wrong, too.
[22:57] <zyga> infinity: I'll talk to gustavo/mark about what are the guarantees we expect people to have in classic confinement
[22:57] <infinity> Shockingly.
[22:57] <zyga> infinity: totally
[22:57] <zyga> infinity: but wrong != impossible
[22:57] <zyga> infinity: and I was trying to probe what's doable
[22:58] <infinity> And Jamie and I seem to agree that a design that says classic snaps can execute things in the core snap is probably not quite right.
[22:58] <zyga> infinity: even if that's unorthodox behavior to say the least
[22:58] <zyga> infinity: I think that's fine and as I said a moment ago, the case of running stuff from their own snap without going through wrappers is far more interesting
[22:58] <infinity> The corollary there is: Not impossible != right
[22:58] <zyga> infinity: and perhaps the answer is indeed libexec
[22:59] <zyga> infinity: as that has many advantages (simplicity and flexibility)
[22:59] <infinity> And yes, being able to run your own subordinate binaries is a much more interesting and valid use-case.
[22:59] <zyga> infinity: but it also has some downsides that I can think of quickly
[22:59] <infinity> As it's a very UNIX thing to do, and dozens of applications do it.
[22:59] <zyga> infinity: e.g. hardcoded paths that don't go through path search
[22:59] <zyga> infinity: e.g. gtk/glib running some internal helpers that have baked-in paths based on prefix
[23:00] <infinity> The general way is either to ship subordinates in /usr/bin (in which case, they're expected to be on path, and should be wrapped in /snap/bin) or to ship in /usr/lib/$app/ and called directly, which needs a snap mapping think, probably.
[23:00] <sarnold> btw why not just recompile with ./;configure --prefix=/snap/ or whatever?
[23:00] <zyga> infinity: and people using --prefix=/snap/$SNAP_NAME/current/usr
[23:00] <zyga> infinity: I don't think that libexec idea can support that
[23:00] <zyga> eh, laggy again, probably lost connectiong
[23:00] <zyga> *connection
[23:02] <infinity> zyga: I didn't literally mean we need a BSD-style libexec (and, indeed, if snap mirrors the FHS, it's library subdirs per app), but that we're dealing with the concept of libexec, that is executables in a library directory.
[23:03] <infinity> zyga: That is an interesting problem to discuss (and should be entirely doable with the same launching/wrapping techniques used for /snap/bin)
[23:03] <infinity> Or, if you prefer "executables off the path", we just happen to stuff them in library dirs. :P
[23:04] <zyga> sarnold: debs
[23:04] <zyga> sarnold: people love to have snaps that just unpack 12 debs
[23:04] <zyga> sarnold: and expect them to run
[23:04] <zyga> sarnold: and if we can support that, we win hearts
[23:04] <infinity> But, unlike "all the things in /bin and /usr/bin in the core snap", the off-path executables in a package are a known quantity, identifiable, taggable, and wrappable.
[23:04] <zyga> infinity: I only agree if "good practice" == "actual practice"
[23:04] <zyga> infinity: if that breaks gedit I'll want exec interception
[23:04] <zyga> infinity: if gedit/gimp/whatever run fine then I won't argue :)
[23:04]  * zyga needs to EOD
[23:04] <zyga> as irssi tells me it's past midnight and my wife tells me I should stop working at some stage
[23:04] <zyga> infinity: can we use that idea even if an app ships hardcoded path to run something?
[23:05] <sarnold> zyga: gnight :)
[23:05] <infinity> Hardcoded paths are problematic in new and exciting ways. :P
[23:06] <infinity> But I also need to escape this discussion at least for today.  So you should EOD so I stop typing.
[23:14] <zyga> infinity: take care, thank you very much for the conversation :)
[23:17] <infinity> zyga: Have a good night unwinding and not arguing on the internet. ;)
[23:17] <infinity> (Though, there's plenty to argue about these days that isn't work related too :/)