[03:37] PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58 [03:38] PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58 [06:38] morning [07:53] good morning [07:57] zyga: hey [07:59] hey [07:59] reading notes from the sprint [08:02] morning [08:03] pstolowski: hey [08:03] pstolowski: did you have you morning coffee already? :) [08:03] we need to talk [08:03] good morning [08:03] mborzecki: I didn't but I can listen :) [08:03] I went outside, the air is foul :/ [08:08] mborzecki: hey, i'm having 2nd cup right now ;), would like to have a chat about the panic? [08:09] pstolowski: yup, standup HO? [08:09] mborzecki: sure, coming [08:09] zyga: ^^ [08:09] up [08:41] PR snapd#8026 opened: data/selinux: workaround incorrect fonts cache labeling on RHEL7 [08:41] pstolowski: ^^ [08:43] hi, [08:43] does anybody has experience with `build-snap` and `pkgconf` inside of the build-snap ? [08:43] In the build- & prime-stage of the snap with the *.pc there is : `prefix=/root/stage/usr` [08:43] In the build stage, where the `build-snap` is used. There is this inside of *.pc: `prefix=/build/wlroots/stage/usr` [08:43] Inside of the multipass VM - there is no directory "/build/wlroots". [08:43] Now, of course, `meson snapbuild` has trouble to resolve. [08:46] sdhd-sascha: sorry, doesn't ring a bell [08:46] what is pkgconf and build-snap [08:46] zyga: pkg-config command - the new spelling [08:46] aha [08:47] zyga: build-snap: i mean a snap which includes only library and headers [08:47] I know, that snapcraft replaces the prefix inside of *.pc (pkg-config files) [08:47] Then i have a second snap, which want to use the library-snap. [08:48] In the second snap is `prefix=/build/wlroots/stage/usr`` [08:48] zyga: It's okay, i can figure it out by myself. [08:49] sdhd-sascha: good luck, sorry I'm not of much help - I rarely use snapcraft myself [08:50] zyga: thank you :-) [08:50] zyga: a replacement for pkg-config [08:50] * sdhd-sascha i wonder, if it's worth the time. And i should search some other task to fix... [08:51] afaik there should be a symlink as pkg-config too [08:51] mborzecki: btw, do you know more [08:51] why is a replacement called nearly the same [08:51] is the upstream the same? [08:52] zyga: didn't investigate much other than what was discussed on arch dev mailing lists https://lists.archlinux.org/pipermail/arch-dev-public/2018-May/029252.html [08:52] zyga: but it's supposed to be maintained (not necessarily true for pkg-config though) [08:53] zyga: btw. seems like fedora may have more info https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation [08:54] thanks, that's interesting [08:54] zyga: haha and our friend Eighth_Doctor was involved :P maybe you could poke him [08:55] hey, is the snap installation directory fixed ? Should it be always /snap// ? Also for build-snaps ? Or is this not a must [08:55] sdhd-sascha: snaps should not have to know about where they might be installed, that's the theory [08:55] sdhd-sascha: a snap can find its assets and data using $SNAP and $SNAP_DATA environment variables [08:56] mborzecki: most pkgconfig files in Debian/Ubuntu are broken [08:56] sdhd-sascha: many snaps assume they are installed in /snap/$SNAP_NAME/current/ and use that as quasi-prefix [08:56] zyga: well, that means, that on installation snapd has to give the snap some ENV to the *.pc files [08:56] the --prefix capability isn't going to work because a lot of pkgconfig files are not correctly written for prefixes to work correctly [08:56] Eighth_Doctor: hah, that's reassuring [08:56] sdhd-sascha: why? [08:57] sdhd-sascha: are you shipping .pc files in snaps? [08:57] and because Debian/Ubuntu don't actually use pkgconfig for dependencies or any reasonable validation, they never catch that [08:57] * zyga doesn't follow [08:57] Eighth_Doctor: you mean, that i should ignored the prefix ? And look a `meson` why the path isn't resolved ? [08:57] mborzecki: when we switched from deb/fdo pkg-config to pkgconf, we caught *a lot* of broken pkgconfig files [08:57] Eighth_Doctor: to be fair, pkgconfig has limited usefulness if everything is in the usual locations and you need only -lfoo to link to foo (and nothing else) [08:57] so I don't blame anyone for not using something when the advantage is non-existent most of the time [08:58] zyga: ironically, the reason why that is largely rests at pkg-config's own broken implementation of --prefix [08:58] Eighth_Doctor: it only shows that .pc files need a better validator/linter [08:58] Eighth_Doctor: or need to be discouraged unless required [08:58] it doesn't support it correctly, and iirc, bug reports for it have gone unanswered for a while [08:58] Eighth_Doctor: i have fun with `wayland-scanner` here: `protocols/meson.build:51: WARNING: Custom target input '//root/parts/sway/install/root/parts/sway/install/build/wlroots/stage/usr/share/wayland-protocols/unstable/xdg-output/xdg-output-unstable-v1.xml' can't be conv [08:58] erted to File object(s).` [08:59] sdhd-sascha: I dunno, is that path valid? [08:59] Eighth_Doctor: no, of course [09:00] I don't work with snapcraft either, I know it rewrites pc files sometimes, I don't know how good it is at it [09:00] zyga: pkgconf has a pc validator internally [09:00] but for political reasons, Debian refuses to switch default implementations [09:01] Eighth_Doctor: i will debug my case. And can report later what was the failing point ;-) [09:01] (the creator of pkgconf used to be a Debian Developer who tried to replace dpkg with a better package manager, and went on to create Alpine's apk after their prototype was rejected by Debian) [09:02] this is a story that would be near and dear to Gustavo's heart, as he tried to get Debian and Ubuntu to replace apt with smart nearly 15 years ago [09:02] mborzecki, zyga: ^ [09:03] that's interesting [09:03] I guess FOSS is never about merit [09:03] well, anything involving people isn't about merit [09:03] it's always about people [09:03] more about soft skills, knowing people and just sticking to it [09:03] yeay [09:03] yeah [09:04] at this point, I think the only reason pkgconfig is maintained is because Debian uses it [09:04] I switched Fedora, Mageia, and openSUSE [09:04] Arch, OpenMandriva, Yocto, and Buildroot have followed [09:05] Eighth_Doctor: I know pkg-config mostly from gnome sources [09:05] OpenWrt recently changed too [09:05] sdhd-sascha: fdo pkg-config originally came from GNOME [09:05] :-) [09:06] * zyga notices kubuntu focus laptop [09:06] how can anyone want a 1080p 16" screen? [09:06] my 15" CRT had better pixel density [09:06] zyga: the greatest irony is that pkg-config was invented by a Debian Developer to make it easier to create dev dependencies across libraries, but the debian package manager people refuse to use the data for dependency generation for dev packages [09:09] * sdhd-sascha just remembering `gnome 1` [09:10] * Eighth_Doctor remembers when gnome used to have as large of a sprawl of libraries as KDE does today [09:11] :-D [09:13] on a side note, coincidentally, the author of the original pkg-config is active on this channel ;) [09:13] oh, who is it? [09:13] zyga: jamesh [09:13] ha, such a small planet [09:13] (shame it's going up in smokes) [09:14] tep [09:14] yep [09:14] my original version was in shell though [09:15] yep, iirc, dan nicholson rewrote it into C [09:15] jamesh: I think it's fair to say everything starts as shell :) [09:15] the one that got popular was a C rewrite by Havoc Pennington [09:15] oh Havoc did it [09:15] hey!! it's someone I know! :D [09:15] and I can even guess why he did it! [09:16] probably to reduce the number of ugly shell things that rpm depended on when the pkgconfig dependency generator was added to rpm [09:17] (for those who don't know, Havoc was a base system developer on Red Hat Linux, and was involved in the early days of developing Fedora with Fedora Core) [09:17] there was a similar general purpose script called "gnome-config", which could take a list of packages and produce appropriate cflags and libs [09:18] it worked by combining the output of the relevant "*-config" scripts for those libraries [09:18] also... Havoc created freedesktop.org :D [09:18] what pkg-config brought to the table was having a single script driven by data files [09:18] yes [09:20] * sdhd-sascha i like the idea of pkg-config :-) [09:21] most people do :D [09:23] Here's that ancient script: https://gitlab.gnome.org/Archive/gnome-libs/blob/master/gnome-config.in -- it looks like it can be extended via data files, but it primarily had special handling for most modules [09:26] jamesh: :-) [09:26] huh, TIL that Erik Troan was the one who first rewrote alternatives from Perl to C [09:27] but of course, that version never propagated to Debian, who in turn took a Perl implementation of chkconfig from SUSE instead of the C one from Red Hat and stuffed it into Debian [09:28] (interestingly, the sources for alternatives in RH-ish systems is bundled with chkconfig because it's essentially a single freestanding C file) [09:29] I think a decade or so later, Debian rewrote their own alternatives implementation from Perl to C [09:29] but it still retains its dependency on dpkg [09:30] This: `wl_protocol_dir = wayland_protos.get_pkgconfig_variable('pkgdatadir')` [09:30] And this goes wrong: [09:30] ``` [09:30] prefix=/build/wlroots/stage/usr [09:30] datarootdir=${prefix}/share [09:30] pkgdatadir=${pc_sysrootdir}${datarootdir}/wayland-protocols [09:30] ``` [09:31] * __chip__ waves [09:36] hey __chip__ [09:37] <__chip__> zyga: sup [09:37] __chip__: mosly ok, some issues to be discussed more next week [09:37] how's the sprint? [09:38] <__chip__> zyga: awesome [09:38] <__chip__> zyga: ffantastic [09:38] <__chip__> zyga: beeeoootiful [09:38] * __chip__ stops [09:38] I see the wine was good :D [09:40] __chip__: got some notes regarding the segfault [09:40] __chip__: i'll push a proposed fix, please bring it up with samuele [09:40] <__chip__> mborzecki: i commented on that pr [09:41] __chip__: just seen that, cool [09:43] PR snapd#8026 closed: data/selinux: workaround incorrect fonts cache labeling on RHEL7 [09:46] <__chip__> mborzecki: basically all those AddTask in Update* are suspect [09:46] <__chip__> mborzecki: but we need to look [09:46] <__chip__> it's some gnarly code :) [09:51] __chip__: updated the standup doc with more context [09:51] <__chip__> mborzecki: tks [10:27] mborzecki: is https://github.com/snapcore/snapd/pull/7614 is green, do you think it is something you could review this week? [10:27] PR #7614: cmd/snap-confine: implement snap-device-helper internally [10:28] zyga: yes, want to push a proposal for the aliases thing, and then look at ian's boot pr first [10:28] ok [11:04] brb, need coffee [11:04] (real not decaf) [11:04] making small progress on older PRs [11:04] should have all green week :) [11:51] brb [11:55] PR snapd#8023 closed: devicestate: encryption regardless of grade [11:56] PR snapd#8027 opened: snap: disable auto-import in uc20 install-mode [12:29] hello, is it a known issue that telegram-desktop snap cant open URLs when linked? [12:29] I've got 'user-open error: cannot open supplied URL' in ~/.xsession-errors whenever I click on one === ricab is now known as ricab|lunch [12:54] thresh: I don't believe so [12:54] but perhaps mborzecki knows more, he was patching it recently [12:55] hmm hmm? [12:55] mborzecki: telegram-desktop and xdg-open [12:55] ijohnson: meh, can't push to #8001 [12:55] PR #8001: boot: enable UC20 kernel extraction and bootState20 handling [12:57] mborzecki: sorry the box wasn't ticked [12:57] try again, I just checked the box [12:57] ijohnson: cool :) [12:58] ijohnson: and pushed [12:58] zyga: thresh: that's a message from userd, looks like it actually ran xdg-open on the host, but that exited with an error [12:59] thresh: can copy the url, and then in a separate shell try to run `xdg-open ` (that's what snap userd did)? [13:01] small break [13:03] hmm, just remembering about gentoo. And wondering, if snap supports gentoo's build system ? can a gentoo package be build with snapcraft ? [13:03] sdhd-sascha: snap or snapcraft? [13:03] that is a snapcraft question [13:03] probably no [13:03] sdhd-sascha: for snapd on gentoo, iirc zyga had an overlay [13:04] because of little general interest in gentoo [13:04] zyga: right ;-) i'm just asking to start to think about it. (do not mention) [13:05] zyga: sorry - we previously bootstrap winXp machines with a custom gentoo [13:06] i like the concept to use compiler-options to go through all sources (e.g. snaps) [13:07] mborzecki, huh, I feel embarassed a bit since I didnt have xdg-utils installed on this laptpo. [13:08] it worked right after apt install'ing it. thanks a lot! [13:08] mborzecki: was just an idea, to use `snapcraft` to build a gentoo package [13:09] ;-) [13:10] thresh: that explains why it didn't work ;) [13:10] thresh: interesting, missing dependency or a weak dependency? [13:12] doesnt look like snapd package depends/suggests/recommends it [13:12] (i'm on debian) [13:12] hmm, not godo [13:12] *good [13:13] https://packages.debian.org/bullseye/snapd <- I'm on testing [13:32] zyga: hi, I was looking a way to run a snap in gdb as user, I saw https://github.com/snapcore/snapd/pull/6825 (and previous), but is there anything going on for that, or how can i do that? [13:32] PR #6825: cmd: rework `snap run --gdb` to work as user <⛔ Blocked> [13:32] Trevinho: I'm afraid I don't know [13:32] I think it died because of ENOTIME [13:33] zyga: ok, thanks anyways [13:52] mborzecki: I'm going for a walk with Bit because kids don't want to [13:52] I'll join from my phone === ondra_ is now known as ondra [14:03] hey, Is there a way to only install packages, which would by: "--no-install-recommends". [14:03] Or can i blacklist apt-packages inside `build-packages` ? === ricab|lunch is now known as ricab [14:23] zyga: looks mostly ok, but we probably need a wrapper for dprintf() https://github.com/snapcore/snapd/pull/7614#pullrequestreview-345913137 [14:23] PR #7614: cmd/snap-confine: implement snap-device-helper internally === heather1 is now known as hellsworth [14:37] I have to write down a decision table. Classic-mode has no gnome-extension. Strict-Mode is lesser Yaml with it... [15:41] pstolowski: I'm looking at a uc20 spread failure and it seems the upower snap is not found, is that expected? is the upower snap supposed to be in the store? I can't seem to find that snap anywhere [15:41] pstolowski: I only ask you because I seem to remember you used that snap in one of your recent hook permissions spread tests [15:46] ijohnson: that's very weird, https://github.com/snapcore/snapd/pull/7871 passed [15:46] PR #7871: tests: add spread test for hook permissions [15:46] ijohnson: fwtw interfaces-upower-observe test needs it as well [15:47] pstolowski: yes that test failed too [15:47] ijohnson: huh [15:47] maybe I should ask in the store if there's some sort of outage happening or something [15:47] ijohnson: maybe something has changed. i cannot find this snap anymore as you said [15:48] yeah it's very odd [15:48] pstolowski: I asked in the store team's channel [15:51] pstolowski: it seems the snap has been unpublished as per https://forum.snapcraft.io/t/upower-snap-deprecation/14772 [15:51] ijohnson: :( [15:51] pstolowski: since this will now break master I will push up a "test-snapd-upower" snap and convert all the tests to use that snap [15:52] ijohnson: oh that's super nice, thank you [15:52] ijohnson: i was already crushed about that hook-permissions test becoming useless [15:52] yeah :-( [16:30] if I have environment.PATH = $SNAP/somepath:$PATH, does snapd expand that before invoking command? [16:37] cjp256: it should [16:42] I have a classic snap that directly invokes a python script (#!/usr/bin/env python3), and PATH seems to just take on the default path. If it uses a shell script (#!/bin/sh), $PATH applies as expected. I'm not sure the cause of the change of behavior. [16:50] cjp256: i'm just not on keyboard. but send me the snap. maybe i look tomorrow or later ? [16:51] did you mean `subprocess.run` ? And the env is not as excepted ? Did you use some `extension` or other preloads ? [16:51] cjp256: hmm strange, does it work if you don't use env and execute python3 directly instead? [16:53] i have been playing around with the various options, though i gotta jet for a bit. I'll come back later with a small example :) thanks! [16:56] * sdhd-sascha since zyga says, that snapcraft & snapd should handle every preload stuff. I'm too unsure if i should be worried if the env is unexpected [16:56] mborzecki: thank you, will do [17:27] PR snapd#8028 opened: tests: use test-snapd-upower instead of upower <⚠ Critical> [18:08] ijohnson: nice [18:08] zyga: thanks [18:10] zyga: I still want to have a separate "test-snapd-snaps" repo with all these test snaps that are complicated enough to not build locally from the test that just rebuilds the snaps every so often but mostly so it's easier to keep track of these snaps we use in the tests [18:10] yeah, I think it would be good to get out of the manual pipeline [18:10] not sure how to structure it [18:10] perhaps a repo is the way to goi [18:10] I think a repo with all the snaps is more scalable than a repo per snap, since we have many of these snaps I think [18:11] yeah, I agree [18:11] it would be a problem if they were asymmetric in compile cost [18:11] but it's mostly lots of the same [18:12] yes most of these are pretty similar [18:24] zyga: if you have some task, which i could help. Just ask ;-) [18:25] sdhd-sascha: hmmm [18:26] uggghh stupid upower snap needs new dependencies [18:26] I see why tony deprecated this snap :-( [18:27] sdhd-sascha: do you prefer coding or review? [18:28] zyga: i'm from starting more coder... but at my current level, review, would also be okay ;-) [18:29] zyga: i'm fix things by review, you know ;-) [18:42] sdhd-sascha: I don't know how you could help right now [18:43] sdhd-sascha: drive what you want to drive, learn, work with us for reviews/advice and have fun :) [18:43] I guess that's how most FOSS works [18:47] zyga: its okay. I didn't go. I love linux and debian. So i love ubuntu too ;-) I know i can help, if i'm expert in som language. But not if i can many language ;-) [18:47] sdhd-sascha: are you a debian developer or maintainer? [18:47] sdhd-sascha: we could use help with debian maintenance (always) [18:49] hmm, zyga: i could - but i'm don't - why? In debian, it's very difficult to be diplomatic ;-) [18:49] I asked mainly to check if you have commit access to various places [18:50] zyga: i'm with you - about the social-skills, what you say today ;-) +1 [18:51] zyga: yesterday, i wonder about, how to write a cover-letter for canonical ... but tomorrow, or some time - ... i will try again ;-) [18:54] hey, didn't anybody see `mvo` these days ? [18:54] sdhd-sascha: mvo is in south africa this week at a company sprint and is generally unavailable this week [18:55] sdhd-sascha: mvo will be back next week tuesday or wednesday (not sure how much time he's taking off after the sprint) [18:55] ijohnson: cool :-) wish him all the best. could him only help by one task, yet [18:56] What is the sprint ? i talk about juju and kubernetes. And that these things are bundeled with snap ;-) [18:57] sdhd-sascha: it's a company wide sprint, discussing business planning things for canonical [18:57] juju and kubernetes are sometimes bundled as snaps; have you used them as snaps before? [18:58] ijohnson: ok. (Today, i talk with alisson about my old company. But couldn't go in detail. I'm sure you all could help ;-) ) [18:59] ijohnson: yes. i tried conjure-up, to a time, where canonicals-kubernetes has problems with apparmor ... sorry. But it's great to use this `python` ncurses widget ... [19:00] I love the idea... But then, in my last company, i fixed rancher, that the zfs utils are included [19:01] Soon, i will use manual-juju-machines or maas.. i will see [19:03] ijohnson: i found it... it was again, just a silly thing: https://github.com/sd-hd/hyperkube/commit/5a7acceeedccf41d45210004daa7eb557ebc77b7 [19:04] zyga: sorry - it's late... but could you tomorrow look at `clean-install` from this repo ? [19:05] sdhd-sascha: can you tell me more? [19:05] I'm not a docker person [19:05] zyga: it's just a wrapper around `apt-get install --no-recommends` ... it would make sense for snap ? [19:10] sdhd-sascha: I honestly don't know [19:10] perhaps tomorrow with fresh head [19:11] sdhd-sascha: if canonical kubernetes has trouble with apparmor, I suggest filing a bug. perhaps joedborg could provide the link [19:12] zyga: i'm too ;-) ( hope i'm not so disturbing ) [19:12] jdstrand: yes, you are right. but this was a time, where i didn't talk so much with you ;-) sorry [19:12] Is there anything special I should know about timers for systemd on ubuntu core? I'm really not getting it to work. my service runs once and then no more even with a OnCalendar=: [19:12] jdstrand: to the snap repo? [19:13] joedborg: I have no context. sdhd-sascha may have lost the context but can comment [19:13] i will try it soon. jdstrand: i figured out, that it was the zfs-drivers again. Like in rancher ;-) [19:17] * ijohnson is back from lunch [19:19] sdhd-sascha: re: clean-install do you mean when building snaps you want snapcraft to not include recommended debian packages? [19:23] ijohnson, oh, arent you in CPT ? [19:23] ogra: nah [19:23] ogra: are you? [19:24] next week [19:24] sales planning etc ... [19:25] ijohnson: no, no - `clean-install` is really just a wrapper from google for `apt-get` with least possible packages... [19:26] sdhd-sascha: sure, but how does that apply to snaps? [19:26] if, some snap needs libXYZ ... then i don't want ... [19:27] sdhd-sascha, you could add an override-pull that mangles the hosts apt config [19:27] sdhd-sascha: snaps are meant to be self-contained so they don't have dependencies the same way that a debian package does. if a snap application needs libXYZ, then libXYZ will be bundled inside the snap (except for a few exceptions) [19:28] like you'd do when addint a ppa [19:28] *adding [19:29] ijohnson, well, recommands are typically optional dependencies ... not necessarily needed to actually *run* the app (but likely needed if you want the full feature set) [19:29] *recommends [19:29] ijohnson: are you sure, that when i install `lxterm` inside a snap. That only packages needed, are installed ? I'm not sure. I'm don't know [19:30] sdhd-sascha: I don't know about the lxterm snap, but yes that is how snaps are supposed to be designed is that all of their dependencies are included inside the snap [19:30] :-) [19:32] (IIRC lubuntu and xubuntu are both setting "APT::Install-Recommends "false";" and "APT::Install-Suggests "false"; " in their apt.conf by default ... apps work, install is smaller but to get all features from all apps you'd have to install additional packages [19:32] ) [19:32] ogra: cool :) [19:33] I don’t think we’re doing that in Xubuntu [19:33] Hence the 1.7gb image these days :( [19:33] so if size is really a concern it is surely possible to mangle the apt config by droping someting into the /etc/apt.conf.d/ dir, run apt update and only get the essential deps [19:33] bluesabre, oh, then i remember that wrongly, i thought you did [19:34] i doubt the benefit inside a snap is really big anyway ... given the squashfs is compressed and all ... [19:36] but if your app pulls in all LaTex packages (which is probably in the area of 100+ MB) just for some exotic feature it probably makes sense [19:46] ogra, doesn't snapcraft do deb dependency tree generation internally - i.e. not using apt/apt-get/dpkg so that config option probably has little effect? [19:52] does it ? i thought it calls out to apt [19:52] i know it doesnt run maintainer scripts of the packages .... but i thought dependency resolution still comes from apt [19:53] diddledan: really? [19:53] diddledan: you mean: dpkg -i ? [19:53] maybe I'm mistaken :-) [19:54] I figured it was doing it all internally to not run those maintainer scripts and such [19:54] i don't know ... but this way - would be too much code, or ? [19:54] hmm [20:00] * sdhd-sascha just talked to my old bosses - to use ubuntu for everything (sometimes i'm so stupid... - but i love to see, that a laboritory company use linux ! ) [20:04] zyga: i've just seen some logs from my mobile-phone... could you send me your irc-logs ? [21:23] PR snapd#8029 opened: tests: use test-snapd-upower instead of upower <⚠ Critical> [21:38] ijohnson: wrt the PATH being odd, i have a small test case: https://github.com/cjp256/pedrolino with a script to reproduce quickly enough: https://github.com/cjp256/pedrolino/blob/master/reproducer.sh [21:38] cjp256: nice I'll take a look [21:39] the simplest case, printpath is just a C binary that prints the path. it does not see the expanded $PATH. However, the wrapper (shell script) and shell script example both do have expanded paths... [21:40] https://github.com/cjp256/pedrolino/blob/master/snap.yaml is the corresponding snap.yaml [21:47] cjp256: hmm yeah so I can reproduce your bug [21:47] to be clear the issue is that the printpath app's $PATH doesn't include $SNAP/other-path correct ? [21:48] sorry I left that bit in there from another test and removed it. PATH: $SNAP/usr/bin:$PATH [21:48] (i was just testing per-app environment vs per-snap environment) [21:49] cjp256: to be clear, this is basically what you see as well: https://pastebin.ubuntu.com/p/r3qzGh92K3/ right? [21:49] I built the snap you linked to and used the resulting snap [21:50] ijohnson: yeah [21:50] i'd expect all the PATHs to be the same? [21:50] cjp256: yes I would expect them all to be the same as well [21:50] it's possible that classic confinement has something to do with this [21:51] did you try just changing confinement for the same snap to be strict and see what happens? [21:51] strict looks fine fwict [21:53] well congratulations I think you found a real bug! (until someone comes along and says that this is intended behavior from some random decision 8 years ago :-) ) [21:55] PR snapd#8030 opened: tests: add a command-chain service test [22:02] ijohnson: lol, ok well I'll just punt this LP bug in snapd's general direction ;D [22:02] sounds good to me! [22:15] hey, guys - only work this much - if it works for you ;-) [22:41] zyga: i don't know how.. but you listen, and then you was the first who answer (i know that many people write ;-) ) [22:41] sdhd-sascha: I try to, though I am a flawed human as all of us :) [22:42] * zyga tries to put lucy to bed [22:42] :) [22:42] * sdhd-sascha hope you understand - i like you, as you are ;-) [22:49] hey, ijohnson: could i learn something from you? i know i'm different. And sometimes slow ... But i want still help -- hey, give me a chance ;-) [22:50] well... okay .. i have to lean `golang`... [22:51] r [23:03] ijohnson: did you think i have a chance to work for canonical ? or what did i wrong ? [23:04] sdhd-sascha: we're really happy to have you contributing to the project, it's just we're all a bit busy at the moment and it's difficult sometimes to find things that are easy for new folks to work on. This week is also unfortunate timing because our main manager and architect are at a company sprint so they are largely unavailable this week. I'm sure that next week when Michael is back that he will have some more [23:04] things you could work on. [23:05] hey, then give me a half time job ;-) i love it [23:07] sdhd-sascha: regarding whether you have a chance to work at Canonical or not, unfortunately that is not a question for me to answer as I am not a manager here, but I strongly encourage you to talk with Michael, and IMHO I think you're already demonstrating a willingness and ability to work on things so that can only work to your benefit. [23:07] ijohnson: thank you :-) [23:07] sdhd-sascha: but also it's important to understand that the company is not always hiring on every team, I'm not sure if we have openings on the snapd team or not right now [23:08] Michael really is the best person to talk about that and I'm sure he'd be happy to set up a meeting for you next week [23:08] ijohnson: that's ok. snapd was the basic ;-0 [23:08] ;-) [23:08] Also, yes learning more about coding in Go is a great idea considering snapd is mostly a Go project [23:09] i told mvo that without "secomp" (which told zyga) and without apparmor... there was no conjure-up `juju` [23:10] ijohnson: to learn some `common` language is ok... to learn brainfuck ... is not okay !!! [23:11] ijohnson: without `zyga` i was some days behind here !!! really !! [23:13] ijohnson: for me the language doesn't matter. (i will talk about the language... ) but make the best of the existing ;-) [23:14] ijohnson: and you can trink some beer with me ;-) [23:14] sdhd-sascha: one other thing I just wanted to mention is that most of the Snapd team is EU based and so it gets quite late for them around this time and they won't be around on IRC (even if they are logged in). I'm based in the US so I'm around at this hour but not many of the others are around at this hour (and if they are they probably shouldn't be :-) ) [23:15] ijohnson: i inspect them ;-) it's cool to know the time .. and told my wife... where i have to work... [23:16] i read the jobs from MAAS too.. They are often in American [23:17] So i didn't work on MAAS [23:17]