[02:28] doko: thanks, will work on it on monday [06:46] good morning! [07:23] o/ [07:35] o/ rbasak === Darcy is now known as Spydar007 [08:00] lets hope we quickly have a firefox update :P [08:00] seems its broken on all ubuntu's now :x [08:16] dupondje: is there a bug on this please? [08:18] https://bugs.launchpad.net/bugs/1659922 [08:18] Launchpad bug 1659922 in firefox (Ubuntu) "Firefox 51.0.1 does not display pages/shows blank pages." [Critical,Triaged] [08:19] the fix is easy :) [08:26] 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] dupondje: what's the fix? I don't see one. [08:28] Ah, https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239/comments/3 may be a reasonable fix. [08:28] Launchpad bug 1627239 in firefox (Ubuntu) "Web pages not rendering with e10s enabled and AppArmor profile in enforce mode" [High,Confirmed] [08:39] rbasak: well don't know whats the default apparmor status is ... :) [08:47] 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. === jamesh_ is now known as jamesh [10:36] who's the resident expert on systemd nowadays ? [10:36] I'd appreciate a second look at LP: #1654600 [10:36] Launchpad bug 1654600 in unattended-upgrades (Ubuntu Xenial) "unattended-upgrade-shutdown hangs when /var is a separate filesystem" [High,Confirmed] https://launchpad.net/bugs/1654600 [10:40] caribou, not sure we have a "resident" one but you can try xnox or slangasek [10:40] seb128: yeah, thought so [10:44] 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] caribou: Which is better than testing and being subject to "oh, I beat the race, I must have fixed the bug" logic. [10:45] infinity: that was my worry, especially since the window where the lock might be taken can be quite short [10:45] infinity: that and I'm not too found of a unit *starting* when we're shutting down but that's debatable [10:46] caribou: It's a oneshot, starting or stopping amount to the same thing. [10:46] caribou: (But it may be true that claiming Start or Stop might subtly change ordering) [10:47] infinity: apparently not in that case as ExecStart will only be triggered after the Before= are shutdown [10:47] infinity: anyway thanks for looking [10:48] caribou: Though, ExecStop isn't even documented in systemd.unit... Did you make it up? :) [10:48] infinity: documented in services [10:48] Ahh, indeed. Silly docs. [10:51] caribou: Docs claim that ExecStop won't run at all unless a service is actually running, though. [10:52] caribou: Which for a oneshot, then gets trickier. [10:52] caribou: See "Example 3. Stoppable oneshot service" [10:53] infinity: hence the RemainAfterExit [10:53] infinity: well, this seems to work, I'm just worried about "just being lucky" [10:53] caribou: Yeah, but that won't do anything without an ExecStart, surely. [10:54] (or something to start) [10:54] infinity: k,I'll double-check that [10:54] Maybe it will, though. I dunno. [10:54] Easy to check. "start" it, and then check status. [10:54] If it's running, you won, if not, you didn't, and your stop will never run. [11:27] 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] ginggs: We haven't dropped it yet. [11:27] ginggs: We don't have a concept of "release" and "non-release" architectures. It's in until it's out. [11:28] ginggs: But no reason it can't be synced after we definitely do drop it. [11:29] "Add support for powerpc, ppc and ppc64el platform merging patch from Ubuntu" [11:29] That implies it added ppc32 support too, though? [11:29] infinity: ok, well i'm not sure it will not build ubuntu, but it didn't in debian [11:30] infinity: and i can't test in a PPA :( [11:30] Hrm. It looks like it wouldn't indeed. [11:30] Curious what they broke in taking our patch. :P [11:31] ginggs: Ask me in a few days, and I can maybe help clean it up. [11:31] infinity: ok, thanks === hikiko is now known as hikiko|ln === _salem is now known as salem_ === hikiko|ln is now known as hikiko [13:43] chrisccoulson: how are things going with firefox? :) [14:50] Laney: are you around? We are having issues with the armhf autopktest again. [14:51] 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] seb128: thanks for the info. I've sent an RT, but I'm not sure if they have control over those machines. [15:00] elopio, you can maybe try people in the foundations team as well [15:00] they are the ones supposed to maintain that service [15:00] or at least p_itti was in their team so I guess they had some handover [15:03] slangasek: anybody else from your team can poke the armhf autopkgtest machines? [15:04] infinity: and for the record, now the problem is rustup, which doesn't know what to do when it receives armv8l :) [15:07] You probably always want to look into fixing the package that's failing as well [15:07] Not to say that the infra shouldn't take the conservative route, but it's still a bug in the package. [15:18] 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] elopio: so, what the issue regarding armhf autopkgtest machines? I don't see excessive armhf-specific queues, has this already been resolved? [15:35] 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] slangasek: related to bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520627 [15:38] Launchpad bug 1520627 in linux (Ubuntu Xenial) "New personality for more accurate armv7l emulation on arm64" [High,Fix released] [15:38] uname regressed to return armv8l [15:40] elopio: ah, you're saying there's been a change in behavior on the test runners? [15:52] slangasek mind sponsoring https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/1660372 since you are the debian uploader? [15:52] Launchpad bug 1660372 in cifs-utils (Ubuntu) "merge cifs-utils with debian 2:6.6-5" [Undecided,New] [15:53] also cyphermox can I get sponsorship for https://bugs.launchpad.net/ubuntu/+source/clock-setup/+bug/1660362 [15:53] Launchpad bug 1660362 in clock-setup (Ubuntu) "Merge clock-setup with debian 0.131 for zesty" [Undecided,New] [15:55] 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] 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] slangasek ... DMB didn't reach quorum last meeting. [15:57] "the debian uploader" - well, I'm /a/ Debian uploader, who doesn't upload it [15:58] slangasek... stop beign so pedantic. [15:58] Uploaders: Steve Langasek , Christian Perrier , Noèl Köthe , Jelmer Vernooĳ , Mathieu Parent [15:58] you were listed first... must make you important.. [15:59] chiluk: it's ok you have slavic background I give you pass for definite and indefinite article confusion [15:59] is true. [16:02] chiluk: half of your merge changelog is false because it is not a remaining change [16:04] elopio: so when did this regress? I'm not aware of any changes we've made to the armhf autopkgtest runners recently [16:09] 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] slangasek you are absolutely correct. [16:10] slangasek: we noticed on Friday. Last time this happened, Iain said something about rebooting the machines. [16:10] elopio: I can't imagine why rebooting the machines would fix the uname output... [16:11] chiluk: ok, changelog edited locally, and uploading [16:11] ¯\_(ツ)_/¯ [16:11] thanks slangasek...shame on me.. [16:11] elopio: can you point me to specific autopkgtest logs showing the failure? [16:11] I checked for the keyutils.. but didn't occur to me that you might have fixed debian. [16:12] slangasek,elopio: it's certainly worth checking /proc/cmdline if you can ... [16:12] maybe they somehow got rebooted without the override param [16:12] 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] search for rustup: unknown CPU type: armv8l [16:13] that seems more likely than a kernel regression, just in an Occam's razor kind of way :) [16:18] oh, this requires a kernel parameter? it doesn't just dtrt under linux32? [16:20] 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] slangasek: my memory was indeed correct and it's spelled compat_uts_machine=armv7l [16:21] slangasek: LP builders run with that [16:27] cjwatson: btw, do you know why is it that our armhf executions are slower? [16:28] elopio: executions where? [16:36] cjwatson: on those autopkgtest machines. [16:36] this is armhf: Ran 28 tests in 3581.469s [16:36] this is amd64: Ran 28 tests in 2746.484s [16:37] elopio: I know nothing about the autopkgtest machines. [16:37] Can't help you. [16:38] elopio: My comments above are just from sharing experience with how the LP builders are configured. [16:39] I know. I was just wondering :) [16:40] not a big deal anyway because now we are moving some platforms to the nightly run. [16:46] elopio: different load on the machines when the tests ran? [16:47] dobey: this was on sunday morning, I think no other tests were running. But maybe. [16:56] Is there a way for non Canonical employees to verify whether someone has signed the CLA? [16:59] hallyn, "Canonical Contributor Agreement" team participation [17:11] jgrimm: not sure that's reliable - i'm not listed there [17:13] hallyn, wonder if you are part of a team that has membership [17:14] hallyn, or something missing because you are a former canonical employee? no idea [17:15] 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] 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] hallyn, cool [17:21] jgrimm: where do you see that? [17:21] hallyn, i was wrong. sorry [17:21] ok [18:02] hm. i don't seem able to push to lp:vmbuilder [18:02] wonder whether it has to do with the switch to git [18:04] hm, no, i seem to have been dropped from vmbuilder-dev [18:05] hallyn: wouldn't it be lp:vm-builder? [18:05] hallyn: oh i see there's a distinct 'upstream' [18:05] no [18:06] yeah that naming was always funky [18:06] anyway, now someone needs to approve my membership, but there's noone to do that [18:06] maybe mvo [18:06] oh, smoser [18:06] smoser: can you hit approve on my request to join vmbuilder? [18:07] here ? https://launchpad.net/~vmbuilder/+members#proposed [18:07] i dont see you [18:08] sorry, no, vmbuilder-dev [18:09] apparently, i cannot [18:09] soren ^ ? [18:09] lol [19:00] !dmb-ping [19:00] bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping. [19:35] slangasek: did you find anything about armv8l ? [19:45] elopio: I'm just getting sshed in over there now, it's been a stack of meetings this morning [19:50] slangasek: thank you. [20:01] 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] I know you don't like skips so I'm scared while I say this :) [20:03] I can make sure that they pass in rpi3. [20:13] 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] elopio: which SRU is blocking on this? [20:14] slangasek: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1659946 [20:14] Launchpad bug 1659946 in snapcraft (Ubuntu Zesty) "[SRU] New stable micro release 2.26" [Undecided,New] [20:32] slangasek: I didn't push yet to xenial or yakkety as I wanted zesty to pass [20:32] slangasek: we can either disable the tests that use rust which has the machine detection problem or wait for the fix [20:41] slangasek: i don't believe i have access either unfortunately [20:49] barry: hrm, so this wasn't part of the training from pitti? [20:49] slangasek: no. i suppose we need to talk to is to give more of us access [20:50] mmk [20:59] Dmitrii-Sh: can i get an upload for https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225 [20:59] Launchpad bug 1655225 in qemu (Ubuntu) "Under heavy load qemu hits bdrv_error_action: Assertion `error >= 0' failed" [Medium,New] [21:00] Dmitrii-Sh: I have a feeling you are asleep by now... but maybe you can catch it in the morning. [21:00] chiluk: 1 sec [21:00] oh awesome. [21:00] you just seem to be doing lots of qemu uploads recently [21:00] so I figured I'd ping you. [21:01] chiluk: oh, well I cannot do uploads myself yet [21:02] infinity: hey, does this look like a glibc bug do you? https://bugs.launchpad.net/snapd/+bug/1657504/comments/18 [21:02] Launchpad bug 1657504 in Snapcraft "asciinema 1.3.0 snap is segfaulting on 14.04" [Critical,In progress] [21:02] oh ok.. ah I understand you have just packaged up public patches. [21:02] chiluk: those were patches I was seeking sponsorship for basically [21:02] thanks Dmitrii-Sh I'll find someone else to sponsor the uploa.. I should have checked your perms. [21:03] chiluk: ok, np at all [21:03] good night Dmitrii-Sh [21:03] chiluk: thx [21:17] 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] mwhudson: So, yes, this may well be a bug, as this is very infrequently exercised code, because Who Does That? [21:19] infinity: this is for classic snaps [21:19] which are a different breed of hack [21:23] mwhudson: On the other hand, some googling suggests the behaviour is correct, and the docs are muddy. [21:27] infinity: hm ok [21:28] the docs are not muddy, they are wrong :) [21:29] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1253638 [21:29] Launchpad bug 1253638 in eglibc (Ubuntu) "dynamic linker does not use DT_RUNPATH for transitive dependencies" [Undecided,Confirmed] [21:32] 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] infinity: what DT_RUNPATH is only 13 years old, do you think people are actually using it yet? :) [21:34] infinity: open since 2012 https://sourceware.org/bugzilla/show_bug.cgi?id=13945 [21:34] sourceware.org bug 13945 in dynamic-link "RUNPATH behaviour is not transitive" [Normal,New] [21:35] 'The current gABI says "One object's DT_RUNPATH entry does not affect the [21:35] search for any other object's dependencies."' [21:35] oh heh https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html [21:35] sourceware.org bug 2002 in general "frysk's custom /usr/lib/frysk/pkgconfig/glib-java.pc is corrupt" [Normal,Resolved: fixed] [21:36] ubuntulog_: lol [21:36] ubottu: lol [21:36] "The application or library can use whatever [21:36] prefix it put in its DT_RUNPATH on the strings it passes to dlopen directly." [21:36] except the library is sodding nss [21:36] 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] mwhudson: So, yeah. I think ld and dlopen are spec-compliant here. [21:37] 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] infinity: fair enough [21:37] mwhudson: One could argue that libc itself might want a RUNPATH to be able to find its own modules. [21:37] mwhudson: And I'd entertain that line of reasoning. [21:37] slangasek: sounds good [21:37] * sergiusens sees runpath/rpath conversations everywhere now [21:37] mwhudson: But I tihnk what snappy is trying to do here is RPATH (or LD_LIBRARY_PATH), not RUNPATH. [21:38] 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] sergiusens: you can't escape!!! [21:39] mwhudson: Fun. glibc isn't exactly the only library with plugins. It's just the most obvious one. [21:39] mwhudson: And I bet some *do* set RUNPATH, and that'll break if you're relocating them. [21:39] yep [21:39] Kinda sounds like this all needs LD_LIBRARY_PATH wrappers of doom. [21:40] infinity: zyga is talking about patching the dynamic linker in the core snap [21:40] which is kinda the extreme version of that i guess [21:40] infinity: tbf we don't have to care about all libraries here [21:40] Patching it to do what? [21:40] just ones in the core snap [21:41] infinity: change search paths depending on whether the process is a classic confinement snap or not [21:41] I'm fundamentally opposed to ld.so (and, by extension, glibc) differing between a classic Ubuntu system and the ubuntu core snap. [21:42] For so many reasons. [21:42] So very many. [21:42] infinity: oh, thouse would not differe [21:42] infinity: on core we don't support confinement: classic snaps [21:42] zyga: Then expand on "patching the linker in the core snap". [21:42] infinity: we could ship the same glibc everywhere [21:42] ups kinda outstayed my welcome in this cafe biab [21:43] infinity: the core snap is used as the "runtime part" of supporting confinement: classic snaps on "classic" ubuntu [21:43] (the word classic has three meanings, sorry about that) [21:43] (classic snap on core, classic ubuntu and classic confinement) [21:43] zyga: Yes. I get that. [21:43] zyga: I'm curious how you intend to patch the linker without patching the linker. [21:43] infinity: I intend to patch the linker and ship it everywhere in ubuntu (and upstream if possible, but not required) [21:44] slangasek: I'll be pushing something shortly then [21:44] infinity: simply the effect would only be visible on classic ubuntu running classic confinement snaps [21:44] infinity: (or any classic distro for that matter) [21:45] but that case is perhaps more complex so let's solve the easier case first [21:46] 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] 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] 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] 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] infinity: without the use of mount namespaces [21:48] infinity: so that it uses predictable (good) dynamic linker and shared libraries [21:48] And how do you envision that looking on the filesystem? [21:48] infinity: on the filesystem it looks as follows [21:49] 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] infinity: the core snap is mounted at /snap/core/current (current is a symlink) but we are allowed to rely on it [21:49] infinity: yes, they would be different base snaps (gimme a sec) [21:49] Kay. I'll go for a smoke while you type and come back to the full explanation. :) [21:50] infinity: the snap in question (say hello-classic) is monted at a similar location /snap/hello-classic/current/ [21:50] 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] 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] infinity: when you exec something then we need to be careful (hence glibc patches) to intercept that and use our linker again [21:52] infinity: unless the executable is outside of /snap, where the normal behavior is expected (no magic) [21:52] So, all binaries have a wrapper? [21:52] infinity: similar redirection should happen when dlopen is used, it should not rely on libraries from classic distribution [21:52] infinity: no, just declared apps [21:52] infinity: but those are the only entry points [21:53] If you have a wrapper, I'm not sure why you need a special linker. You can set LD_LIBRARY_PATH [21:53] 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] infinity: that would leak to the child processes and it is not sufficient to ensure we use the right dynamic linker [21:54] infinity: that's my idea (so far), please tell me what you think [21:54] infinity: as a closing remark: classic confinement works "almost" allright as long as you build software from source [21:55] infinity: but it breaks if you want to use prebuilt software that people are more familiar with [21:55] infinity: (the only thing that breaks is the glibc bug that mwhudson found) [21:55] * zyga turns all ears [21:55] zyga: which apparently is not a bug and maybe snapcraft should use rpath not runpath after all [21:59] zyga: How do you propose finding the "correct" linker without specifying it manually? [21:59] http://paste.ubuntu.com/23896033/ [22:00] Note that if I don't specify it there, I get the host system's linker/libc/libnss, which also works fine. [22:02] 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] infinity: snap-exec would know that it runs a confinement-classic app nffsdfsdfsfdsdfsdfadasd [22:03] re [22:03] sorry, lost connection [22:03] infinity: snap-exec would run the desired application through the right linker if it was instructed to do so by snapd [22:03] hey cyphermox.. here's the qemu bug I'm needing sponsorship on https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1655225 [22:03] Launchpad bug 1655225 in qemu (Ubuntu) "Under heavy load qemu hits bdrv_error_action: Assertion `error >= 0' failed" [Medium,New] [22:03] infinity: so to be clear, running executables directly from (e.g. from shell) would not work [22:04] infinity: it would only work if it got initiated by snap-exec [22:04] infinity: and if we implement glibc changes to exec, from any process that uses classic confinement [22:04] infinity: looking at the pastebin now [22:04] 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] mwhudson: let me do a test run with rpath [22:05] infinity: not directly, we'd run the linker instead of the executable in snapd [22:05] infinity: the host linker would never see the executable [22:05] sergiusens: s/--enable-new-dtags//g or whatever? [22:05] sergiusens: would be interesting to see [22:06] 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] (though reading the elf spec I find this aspect confusing) [22:06] infinity: (the dlopen case) [22:06] zyga: Oh, s/RUNPATH/RPATH/ will definitely fix mwhudson's issue, but it does nothing for your pre-build binary case. [22:07] infinity: correct [22:07] And fixing the prebuilt binary case means you don't need RPATH in the from-source case either. [22:07] infinity: but there (I hope) we can patch the linker to chage its behavior [22:07] So that seems like a distraction. [22:07] infinity: oh? sorry, can you explain please? [22:07] infinity: how would it work for pre-build binaries? [22:07] zyga: You read my statement backwards. :) [22:08] infinity: ah [22:08] infinity: correct [22:08] 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] (kids-going-to-bed-moment, sometimes distracting) [22:08] infinity: yes, I understand and totally agree [22:08] thanks [22:09] I'm still knee-jerking at the claim that the linker needs any special knowlege of this. [22:09] infinity: I think someone has to change the default search path, can it be anything but the linker? [22:09] infinity: does the linker take any arguments we could use? [22:10] * zyga runs --help to see [22:10] --help won't help much. ;) [22:10] infinity: do you think setting --library-path is sufficient? [22:11] --library-path is effectively the same as LD_LIBRARY_PATH. [22:11] mmm, that's very promising then [22:11] infinity: but that still leaves the exec case open [22:11] Though, may fix your concern about leak-on-fork. [22:11] infinity: yes, it does fix the leak [22:11] infinity: and seems like a much cleaner solution [22:12] (FWIW, tangentially related, but I think relying on 'current' symlinks is incredibly short-sighted here) [22:13] 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] 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] infinity: and what you think of core will largely become base [22:14] infinity: (core will be a small snap with mostly just snapd itself) [22:14] And linker/libc? [22:14] infinity: if we had many bases then each classic confinement snap will link against a specific core [22:15] infinity: unclear, this is hand-wavy territory [22:15] 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] 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] 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] infinity: was it two decades already? wow [22:16] 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] 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] infinity: right, the snap/app knows that and so does snapd [22:17] mwhudson: https://asciinema.org/a/bjzuw6ujlg3l39cx1ai1bn6ii [22:17] 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] zyga: It certainly makes life easier. [22:17] infinity: we only have the exec patch for glibc that lives in core/base [22:18] infinity: (still assuming that is needed unless we can find a way to make do away with it) [22:18] zyga: Which exec patch? [22:18] Did we just run full circle? :) [22:18] infinity: the (theorethical) patch that would allow a process to exec anything and still DTRT [22:19] infinity: maybe, bare with this for a moment [22:19] infinity: a process running under classic confinement can exec anything it wants from the core snap [22:19] infinity: if it runs /snap/core/current/bin/true we need to intercept that [22:19] 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] infinity: or it would again run with the system dynamic linker, right? [22:20] 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] zyga: Ahh. I see. [22:20] zyga: So, if a snap runs /bin/true, you want it to run the core version, not the host version. [22:20] infinity: I think it is fine to limit this special behavior to just processes started by a snap [22:20] (true probably being a stupid example, but I get the point) [22:21] infinity: well, not really, /bin/true should be the host true [22:21] infinity: but /snap/core/*/bin/true should be the core version [22:21] infinity: e.g. imagine a bash shell snap [22:21] Why would a snap ever call something in that namespace that way? [22:21] infinity: it should be able to run stuff normally [22:21] infinity: when you said namespace did you mean to refer to linux namespaces or was it just a word clash? [22:22] My brain predates linux namespaces. :) [22:22] infinity: classic confinement snaps are allowed to use core resources _and_ host resources if they want to [22:22] hehe :) [22:22] infinity: so if you build a quick snap with stuff from firefox.deb [22:22] That feels like a strange design choice. [22:22] infinity: it should work fine even if it wants to run something from your distro [22:23] 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] 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] doko: in ldb 2:1.1.26-1ubuntu1, you changed -Xldb.so to -Xldb. in override_dh_makeshlibs. Was that intentional? [22:24] infinity: it should allow people to use snaps quickly without learning new things [22:24] nacc: I assume that's an oversight [22:24] 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] infinity: or even having to use devmode confinement (and have various other issues) [22:25] doko: ok, np, just wanted to confirm, I'll probably ahve other questions : ) [22:25] infinity: if we can deliver that [22:25] zyga: But doesn't it seem odd to have people calling things in that bizarre path? [22:25] infinity: I think that's a big win [22:25] 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] infinity: it depends on each case but I think it is an important "no-barriers" design decision [22:26] 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] infinity: move off debs/rpms/random stuff to stuff with no barriers in place [22:27] Or are you prepending all the /snap/blah paths to PATH and hoping for the best? [22:27] infinity: I'm doing neither, I don't think I understand your concern [22:27] Cause that way does indeed lie madness. You're calling into a chroot without chrooting. [22:28] 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] 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] 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] on the way [22:30] 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] infinity: as long as you give your app and entry point (which we control) this seems like a reasonable limitation [22:30] infinity: e.g. a bash classic snap would work normally [22:30] infinity: so would any less demanding program [22:30] zyga: No, I'm not talking about how to run a snap from classic. I'm talking about a snap itself forking. [22:31] infinity: ok, so a snap itself forks [22:31] infinity: if it chooses to exec something from the host that's fine (no patches needed), right? [22:31] zyga: And you're saying a forking snap should be able to call binaries inside core. [22:31] zyga: How is it calling them? [22:31] infinity: it would go through the systmem linker [22:31] infinity: yes [22:31]