=== JanC is now known as Guest73457 === JanC_ is now known as JanC === JoshStrobl|Work is now known as JoshStrobl|zzz [01:19] PR snapd#3964 opened: many: implement our own ANSI-escape-using progress indicator [07:15] o/ [08:08] Bug #1717900 opened: Confined snap fail for user with homedir in /var/lib === JoshStrobl|zzz is now known as JoshStrobl [12:12] PR snapd#3965 opened: interfaces/mount: add support for parsing x-snapd-{mode,user,group}= === King_InuYasha is now known as Son_Goku [13:39] \o === chihchun is now known as chihchun_afk [13:52] Hey ogra_, think you might have any free time today to sit down with Chris to talk about gadget snaps? [13:53] sure [13:53] kyrofa, any time you like [13:53] ogra_, wonderful, thank you, I'll ping you :) === d_ed is now known as d__ed [14:15] lool, you around? [14:16] lool, question about your dnsmasq snap [14:19] hey kyrofa [14:19] how's the event? [14:19] zyga-ubuntu, going quite well. Nice to just sit down with these folks and get their stuff working [14:21] kyrofa: what are you working on there? [14:22] https://pastebin.com/neAd9iPU [14:26] * zyga-ubuntu wonders why removing unused code makes tests fail [14:26] it must have been _slightly_ used :/ [14:28] ah wait, master is broken!? [14:28] or artful is broken [14:29] everything is broken, zyga-ubuntu [14:35] zyga-ubuntu, got a few roboticists here working on snapcraft updates and snapping their stuff [14:37] kyrofa: sounds great, tweet a few pics, that stuff is very interesting to people [14:42] PR snapd#3966 opened: cmd/snap-seccomp,osutil: make user/group lookup functions public [14:53] davidcalle: is there any target date when docs.ubuntu.com will be refreshed? [14:57] morphis: afaict, there is a deployment outage since sep 21st, I'm running one now, will ping you when I know more === chihchun_afk is now known as chihchun [15:09] davidcalle: ok, thanks [15:11] <__chip__> zyga-ubuntu: how's things? [15:11] __chip__: hey [15:11] __chip__: climbing out of the rm -rf hole but making progress [15:12] <__chip__> zyga-ubuntu: sergiusens could use some pointers, i hear [15:13] __chip__: about? [15:13] <__chip__> zyga-ubuntu: climbing out of the rm -rf hole [15:13] <__chip__> zyga-ubuntu: although in his case i think it's a "do git clone in the wrong place" hole [15:13] <__chip__> or git reset? [15:14] <__chip__> i dunno [15:14] <__chip__> it sounded nasty so i didn't listen, just in case he wanted me to fix it [15:16] @ogra_ Hey, would you be available to look at making a gadget snap with me? [15:16] cratliff: No such command! [15:16] __chip__: I killed my data last week [15:16] ogra_ [15:23] cratliff, sure, where are you ? [15:23] ogra_ I'm in the snapcraft room on the conference floor, but it is a little full in here if me coming to you works. [15:24] ah, i'll come down in 20-0min then (need to finish a test ) [15:24] *20-30 [15:24] and i wanted to see the snapcraft room anyway [15:24] ogra_ thanks, cya then. [15:25] sergiusens: i found another case of plugins on classic not dtrt -- the python pluginn invokes /usr/bin/env in the rewrite: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L370 [15:25] (if it is to full we can go to the ballroom or some such ... ) [15:25] sergiusens: the whole code needs to be audited for that, IMO [15:25] *if* one tries to modify LD_LIBRARY_PATH and that wrapper gets invoked, you get segfaults when mismatchinng host and classic snap distribution :) [15:26] and no built-in way to avoid it [15:31] for a classic app, does snapd setup LD_LIBRARY_PATH for the app? To refer to the core snap? Can I assume that in my own environment (so I can say prepend my snap's library paths)? [15:32] bschaefer, i cant get the card to misbehave :/ so i guess i'll need the one where you are actually seeing the breakage ... were you using it on pi2 or pi3 ? [15:32] ogra_, raspi3 [15:32] yeah, thats what i'm trying it on [15:33] yeah i got the things installed i need so you can get this one if you want, ive not had the issue [15:33] since ive manually mounted the overlay.tar [15:33] or ... w/e it was [15:33] but yeah umm you can take this one as well and i can use that one [15:33] ogra_, what room are you in? [15:34] bschaefer, at the end of the same corridor you are === JoshStrobl is now known as JoshStrobl|AFK [16:06] PR snapd#3967 opened: release: release snapd 2.28 [16:07] nacc: IIRC, snapcraft will set flags to try and link using -rpath to point at the core snap [16:08] rather than setting LD_LIBRARY_PATH for you [16:08] depending on your app's build system, that might not take effect though [16:09] cratliff, sorry, will still take a bit up here ... i'm in 1419 though in case you want to come upstairs [16:14] jamesh: ok, so in theory, do I need to specify LD_LIBRARY_PATH for *classic* snaps to force my app to use only my snap's libs and the core snap's libs? [16:14] ogra_, no problem. Does after lunch work well? [16:17] jamesh: specifically, since a 16.04-built classic snap with a 16 core could run on artful, it's *really* important not to use libs from the host. [16:17] nacc: if your project's build system respects the LDFLAGS environment variable, it should end up with an rpath that will search common paths in both itself and the core snap [16:18] jamesh: ok, let me try that [16:18] kyrofa: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5 [16:18] Bug #1598309: The aplay command doesn't work [16:21] nacc: try running "objdump -x /path/to/my/exe | grep RPATH" [16:22] jamesh: i have had to do stuff in my own wrappers so far, because I will get thinngs like man in my snap not finding the custom-built /usr/lib/man-db in my snap [16:22] jamesh: will do [16:22] nacc: that should show up paths that will be searched before the default library locations [16:22] if it doesn't show anything, then you might need to alter your project build system to make use of LDFLAGS [16:22] jamesh: are you sure what you describe is true for classic snaps? [16:23] cratliff, sure [16:23] popey, moop moop [16:23] nacc: yes. You can see the logic in Snapcraft's build_env() function at /usr/lib/python3/dist-packages/snapcraft/internal/project_loader/_env.py [16:24] popey, oh ... unmoop ... [16:24] wat wat [16:25] jamesh: ok, man for instance is installed via stage-packages [16:26] in any case, i'll try it [16:27] jamesh: i'm really curious if this is tested with builds on xenial run on artful? [16:28] nacc: if the executable isn't being built under control of snapcraft (as would be the case if you're pulling executables from the Ubuntu archive), then you wouldn't see the rpath [16:28] nacc: it would be up to you to handle it [16:29] either by trying to patch in an rpath, or use a wrapper shell script that configures LD_LIBRARY_PATH instead [16:30] patchelf can add an rpath to an existing binary, but sometimes fails [16:30] jamesh: ok, so there are two cases, got it [16:31] (it isn't always possible to modify an already linked executable) === ShalokShalom_ is now known as ShalokShalom [16:44] well, fwiw, (jamesh is gone), the python3 generated in the classic snap by using the pythonn plugin also does nont have any RPATH set [16:51] core snap's ldd references a host path [16:51] (/bin/sh) [16:52] err, /bin/bash [16:56] morphis: it will be deployed at some point in the next hours (https://docs.staging.ubuntu.com/core/en/stacks/network/index) , IS is looking into it. [17:23] * nacc is super-confused, the bash in the core snap also has no rpath [17:24] so was jamesh wrong earlier? [17:24] and if i try to run binaries from the core snap restricting LD_LIBRARY_PATH i get segfaults (Probably implies I'm being too strict) [17:25] nacc, snaps do a pivot_root when running ... how do you check ? [17:26] nacc, http://paste.ubuntu.com/25621829/ [17:26] ogra_: classic snaps too? [17:26] nacc, thats a zyga-ubuntu question [17:26] ogra_: ok [17:26] zyga-ubuntu: --^ :) [17:26] i assume they *don't* otherwise they couldn't use the host at all [17:27] but if they don't, none of the core snap makes much sense [17:27] debugging all of this has really not been fun, and makes me thinks classic snaps on artful may just be sort of broken (even if they happen to work some of the time) [17:28] ogra_: your paste makes total sense on core and with confined snaps (to me) [17:29] they could use the host if they pivot and then bind-mount half the host ;) [17:29] i hope that isn't how it's done :) [17:29] but it might be, true [17:29] and i guess snapd has privilege to do that before running the app [17:30] ogra_: but i still don't see any actual use of rpath in the core snap's binaries [17:30] (which they do via /var/lib/snapd/hostfs/ i think) [17:30] well, the core snap is built from debs ... iirc rpath isnt allowed in debs [17:30] ogra_: ok, so maybe there is snapd voodoo for that on classic, for core snap binaries [17:31] the problem is, I have almost no way of knowing if that is true :) [17:31] https://wiki.debian.org/RpathIssue [17:31] "While there's no policy dictating the accepted use of RPATH, it's been a general consensus that RPATH use is discouraged, given the interactions between the above reasons and Debian's way of dealing with libraries and package dependencies. " === JoshStrobl|AFK is now known as JoshStrobl === JanC_ is now known as JanC [17:53] jdstrand, hey, what conf room are you in? [17:53] pstolowski: hey [17:53] pstolowski: how's the event? [17:53] zyga-ubuntu, it's good! === chihchun is now known as chihchun_afk [17:58] mvo, https://github.com/snapcore/snapd/pull/2105 [17:58] PR #2105: snapstate: only import defaults from gadget on install [17:59] mvo, https://github.com/CanonicalLtd/ubuntu-image/pull/72 [17:59] PR CanonicalLtd/ubuntu-image#72: Make sure /image/etc gets into the system-data directory [18:08] is it possible that while building a snap, one part (e.g., mine that builds xz-utils) gets staged/built, and then a subsequent part that depends on it (dpkg), sees the xz binary in stage, but rpath hasn't been modified on it yet, so it, at runtime, tries to load core libs, instead of libs from my snap? [18:08] nacc, rpath hasn't been modified one... what? xz? [18:09] s/one/on/ [18:09] kyrofa: yeah, on the staged xz [18:09] i'm wondering about the order here [18:09] http://paste.ubuntu.com/25622009/ [18:09] is the error dpkg's autopoint is spitting out [18:09] nacc, the first bit makes total sense: if part A builds "after" part B, part B will be staged before A is built [18:09] which feels like a mismatch between the just built xz and the libs being loaded [18:10] Ah, this sounds like an LD_LIBRARY_PATH ordering issue [18:10] * __chip__ might be having too much fun right now [18:10] PR snapd#3968 opened: daemon: use client.Snap instead of map[string]interface{} for snaps [18:10] kyrofa: maybe? i'm not setting it at all [18:11] kyrofa: this is during the build [18:11] nacc, yeah but snapcraft does. Checking... [18:11] kyrofa: yeah :) [18:11] nacc, this is a classic snap, I assume? [18:11] kyrofa: so i can confirm the core snap's liblzma is XZ_5.0 while my built one is XZ_5.2 [18:11] kyrofa: yep [18:16] morphis: It's live [18:17] kyrofa: would i need to write my own plugin in the short-term? [18:18] nacc, I suspect something odd is happening in snapcraft itself, particularly in snapcraft/internal/project_loader/_env.py [18:18] Could the LDFLAGS be going wrong there? [18:19] kyrofa: it could be (although i don't know how to debug that) -- but also, how is it finding my just built xz? I don't see PATH manipulation there [18:21] nacc, look at runtime_env there [18:23] kyrofa: but that's for runninng binaries, not building them? [18:23] or is the xz now a runtime [18:23] kyrofa: bbiab [18:24] nacc, yeah the name is perhaps a bit misleading: it still gets evaluated for the build env [18:24] sgclark, SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft [18:25] thanks! [18:30] pstolowski, https://docs.ubuntu.com/core/en/reference/interfaces/index [18:33] Hey ogra_ any idea why we're using /etc/profile to add /snap/bin to the path? Is there no way to do it without a login shell? [18:44] <__chip__> kyrofa: hey, what's that about /etc/profile and login shells? [18:45] kyrofa, the only other way is /etc/environment and that can only be changed for new installs ... [18:46] <__chip__> well, there is environment.d [18:46] kyrofa, we could surely talk to foundations (hey slangasek ) about adding /snap/bin to /etc/environment in new artful installs by default as we do since a while on ubuntu core images [18:47] __chip__, is that finally landed ? [18:47] ogra_, yeah it's odd to have different behavior depending on how you're logging in, e.g. we have someone here trying to package mosh [18:47] (i only know thats a lennart plan but havent heard anyone implemented it yet in a stable distro) [18:48] kyrofa, if you're logging in it should always work [18:48] <__chip__> ogra_: I don't think we've got it yet, no, definitely not in x [18:48] ogra_, over ssh [18:48] mosh doesn't run a login shell, so you have to give it an absolute path to the mosh server [18:48] <__chip__> kyrofa: fun fact: fedora (and rhel?) load profile.d from non-login shells as well [18:48] kyrofa, if you're logging in it should always work (and surely does with ssh ... ) if you do *not* log in ssh will strip your path [18:49] kyrofa, but thats an ssh thing ... [18:49] kyrofa, anyway ... what needs to happen to have it globally is to add it to /etc/environment ... and by poloicy we do not touch it on installed systems [18:50] <__chip__> kyrofa: why doesn't mosh run a login shell? [18:50] *policy [18:51] kyrofa, the issue is that when using snapd on other distros we can not control /etc/environment (unless they have environment.d support as __chip__ pointed out) ... so there profile.d is the only way [18:52] ogra_, this is what needs to work in order for e.g. mosh to work: https://pastebin.ubuntu.com/25622245/ [18:52] __chip__, no clue [18:52] __chip__, https://github.com/mobile-shell/mosh/issues/182 [18:53] __chip__, not a mosh user myself [18:53] More of an SSH+screen guy === JoshStrobl is now known as JoshStrobl|AFK [18:58] pstolowski: 1413 [19:01] jdstrand, k, will be there in a few minutes [19:03] kyrofa, well, the only way currently is to make mosh use 'ssh sh -l -c ""' instead of 'ssh ""' ... there is also elopio's bug 1659719 that explains it [19:03] Bug #1659719: ssh can't call a binary from a snap without the full path

[19:07] ogra_, how is that fix-committed for snappy? [19:08] Or is that just ubuntu core, and it should also apply to snapd? [19:50] PR snapcraft#1570 closed: Don't fail over empty or faulty lines [19:50] PR snapcraft#1571 closed: Make sure we don't try to include an empty set [19:50] jdstrand, your alsa workaround got us further, but now we're getting a denial on /dev/snd/controlC0. snappy-debug suggests the alsa plug, but we're already using it [20:08] <__chip__> niemeyer: https://forum.snapcraft.io/t/2268 <- let me know if that seems reasonable, you [20:15] PR snapd#3969 opened: hooks: rename refresh hook to post-refresh [20:25] mvo, ^ [20:25] pstolowski: hm? could you please paste it again? [20:26] mvo, sorry, sure - https://github.com/snapcore/snapd/pull/3969 [20:26] PR #3969: hooks: rename refresh hook to post-refresh [20:26] pstolowski: ta [20:26] i hope the branch name is accurate ;P [20:27] kyrofa: i'm here now [20:32] cratliff, https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives [20:33] kyrofa: did you have any furhter thoughts? this is a relatively big blocker for me right now [20:38] kyrofa: i'm going to try reordering my build [20:38] we don't really care about usinng the new xz in dpkg's build, I do't think [20:40] compression is overrated anyway :P [20:41] heh [20:41] well, SOVERSION'd compression ;) [20:49] kyrofa, the bugy is fix comitted for Ubuntu Core (Snappy) and livecd-rootfs, snapd had at a similar time the fix in profile.d (which was the only sane thing we could do from a cross distro perspective) [20:50] (sorry, only just noticed you answered above) [21:01] cratliff, https://forum.snapcraft.io/t/service-ordering [21:02] kyrofa: cool, i think orderign (after adding some deps), is letting dpkg build [21:02] kyrofa: but it does imply a snapcraft bug if the ordering breaks the build inn a non-obvious way [21:03] nacc, yes I'd say so [21:03] kyrofa: i'll add it to my backlog of bugs to file :) [21:50] PR snapcraft#1573 opened: WIP project_loader: parse YAML without processing it [21:57] kyrofa: any ideas? http://paste.ubuntu.com/25623175/ [22:09] kyrofa: that's pygit2 from a part using the python snap [22:09] nacc, are you using python from the archive? [22:11] kyrofa: yes [22:13] Bug #1719747 opened: Fedora 26 LXD container: cannot load apparmor profile [22:14] nacc, sergiusens will know more, but I seem to remember an issue with that, e.g. it's hard-coded to the wrong libc or something. We had to build our own Python in snapcraft to get around it === JoshStrobl|AFK is now known as JoshStrobl|zzz