[00:23] How do you add a license for a publish snap? === ackk is now known as Guest76534 === StoneTable is now known as aisrael [03:20] * Son_Goku hates his life right now [03:21] my air conditioning died, so now it's nearly 35C in my house === chihchun_afk is now known as chihchun [05:06] morning === chihchun is now known as chihchun_afk [05:58] Good morning [06:03] zyga: hey [06:06] :) [06:09] mup is quiet again? [06:10] https://github.com/snapcore/snapd/pull/5735 [06:10] simple one ^^ [06:10] mvo: hey [06:11] hey mborzecki [06:11] mvo: good morning [06:11] looking [06:12] good morning zyga [06:12] mvo: that issue from last evening, the journal included sigsegv [06:12] not sure if you noticed that [06:12] zyga: thanks for the log from last night I think I know now what is going on [06:12] zyga: yeah, console-conf [06:12] zyga: but the key was the error from snap-repair \o/ [06:13] oh? [06:13] can you explain? [06:16] zyga: part of the "bootstrap" of snapd itself is to start its services [06:17] zyga: if one of them fails the bootstrap fails [06:17] zyga: and snap-repair is failing apparently because it has no network [06:17] zyga: so the fix is probably as simple as making this non-fatal (which it is - I mean, it should be :) [06:18] ah, I see === chihchun_afk is now known as chihchun === pstolowski|afk is now known as pstolowski [07:09] morning [07:10] pstolowski: o/ [07:15] hey pstolowski ! good morning [07:32] zyga: if I could get a review for 5734 master should be good again [07:32] zyga: right now tests are failing there because of the latest core snap changes [07:35] mmm [07:35] doing now [07:36] mvo: question [07:36] zyga: ta [07:37] mvo: what shall we do with snapd code that groks alternatives, in a world with core18 and core16 and snapd there is no way to "depend" on the right build of core in snapd snap (or vice versa) [07:37] if I kill the small bit of code that handles alternatives in snap-confine and people upgrade the wrong way they will see old core with alternatives symlinks and nothing to handle that in s-c [07:37] shall I remove that code or just wait until nobody reasonably will be on the old snapd [07:37] zyga: if we find /etc/alternatives we keep doing what we are doing today [07:37] zyga: and once we have epochs we drop it [07:38] mvo: ah, so only after epochs [07:38] that was the answer I was looking for, thanks! === Guest76534 is now known as ackk [07:38] zyga: we can add a note in the code though [07:38] zyga: we *could* keep the test alive using ubuntu-core [07:38] ack [07:38] zyga: which never changes [07:38] zyga: I mean, the spread that we just removed [07:38] zyga: but I think its fine [07:38] nah [07:38] I think it's fine [07:39] :) agreement! [08:06] hello [08:06] hello [08:07] is there a recommended way to get python 3.6 or 3.7 in a snap? Xenial comes with 3.5... [08:07] You can use base: core18 to use ubuntu 18.04 as a base [08:07] or you can build python from source as a part [08:07] but I think using the base is easier [08:08] yes, I prefer not to spend the time to build python from source [08:08] right, I'll try core18. I thought that xenial was basically always the base image === chihchun is now known as chihchun_afk [08:09] maybe then it is also time to upgrade my laptop, so that I have the same environment everywhere :) [08:09] well, I use docker anyway [08:09] zyga: thanks [08:09] t1mp: you can now choose out of two stable bases [08:09] t1mp: with more coming [08:10] t1mp: obviously anyone can run all the snaps regardless of the base they use :) [08:12] zyga: True. But for testing my python lib, and building the snap (I'm not using cleanbuild) locally it is nice to have the same environment [08:12] yeah, I agree [08:12] well, good luck :-) [08:12] well, for testing the python code locally I use miniconda anyway. === chihchun_afk is now known as chihchun [08:54] pedronis: thank you for the review! :-D [08:55] pedronis: I'll look at writing that test asap [08:55] Chipaca: thx, I think that's how abort should work without lanes but I might be misremembering anyway my point was also about the comment [08:56] pedronis: yep, i'll add a comment also [08:56] Chipaca: question for you sir [08:56] zyga: the answer is that it was working that way when I found it, all I did was pick it up and put it somehwere dry, honest ociffer [08:56] what's the factor that chooses * over ✓ https://www.irccloud.com/pastebin/EYj3TrPi/ [08:58] zyga: canUnicode is true, assuming --unicode=auto, if the first one of LC_MESSAGES, LC_ALL, or LANG that is set has "UTF-8" or "UTF8" in it (case-insensitively) [08:58] hmm [08:58] interesting [08:58] zyga: I say "set" but I mean "set and non-empty", fwiw [08:59] Chipaca: this test works/fails depending on suse version [08:59] missing mocking? [08:59] zyga: I don't think so, but, maybe? [09:00] or maybe broken mocking, I'll re-trigger [09:02] zyga: maybe you're on to somehting with the mocking [09:02] Chipaca: the log comes from obs [09:03] zyga: I think we set LANG=UTF-8 in our run [09:03] er, C.UTF-8 [09:03] it's a regexp, we could change it to accept either :-) [09:03] yes, something for .1 [09:03] I'll fix that [09:03] the smile is because it'll be a fun regexp [09:04] [*✓] [09:04] :-) [09:04] zyga: but, there should be a bunch of other tests failing in the same way [09:04] or similar [09:04] mmm [09:04] zyga: 'snap info' output for ex [09:05] zyga: (not just publisher but the channel map will be different on non-utf8) [09:07] I _nearly_ succumbed to the temptation of working on widths this last vacation [09:07] but i resisted! i can do it in my 20% time if i ever do [09:08] 3 tests left [09:09] 2945 tests passed with my patch :) [09:09] zyga: hey, got a moment for HO? [09:09] yes [09:09] I saw your ping last evening [09:09] but I was on a walk then [09:09] let's HO [09:09] can you send me the link pelase [09:09] *please [09:20] pstolowski: I reviewed the sublevel PR with some comments [09:28] pedronis: thank you! [09:40] E: Failed to fetch http://us-east1.gce.archive.ubuntu.com/ubuntu/dists/xenial-updates/universe/binary-amd64/Packages.xz Hash Sum mismatch [09:40] heh [09:42] zyga, mvo is it true that you want to hide base snaps from "snap list" output ? if so, will there be an exception from this on Ubuntu Core (how would i find out the version of my rootfs otherwise ?) [09:47] ogra: snap list --all or something will show more things [09:47] but I see your point === tomwardill_ is now known as tomwardill [09:47] maybe on core we should show the boot snap [09:47] yeah [09:48] we often have customers digging through CVEs for example ... for that they need to know what rootfs revision they run etc [09:48] or perhaps add a --show-base option that lists them again [09:49] (i dont really care about the impleentation but the info is valuable on core) [09:51] ogra: I don't know what the exact argument to show / hide this would be but I think we agreed to have some [09:52] ah, cool, as long as seeing them somehow is still possible all is fine ... [09:54] xnox: so about the systemd env generator - i have put a PR up but it does not work and I am a bit lost about the why. setting env vars works just fine. as long as the env is not PATH. now the sad part is that even the man-page talks about reording path so I would assume systemd itself is fine but something we customize is probably not fine. any ideas? I am poking at the code and it looks like it applies DEFAULT_PATH for un [09:54] known reasons and nothing in the (manager) code stands out as strange [10:10] afternoon everyone! Is there any roadmap for core18 snap somewhere? Right now is 0.1 but the beta & edge channels revisions weight as twice as the one in the stable & candidate channels... [10:13] pachulo: https://forum.snapcraft.io/t/the-road-to-core18/5547 this do? [10:18] ok, yes, forgot about it, thanks popey ! [10:20] mvo, hey, I got +1 to go to stable with 2.35 [10:21] cachio: did you had a chance to check with sergiusens if there will be any issues from his side if we go to stable with 2.35? [10:21] mvo, no, I'll do it today [10:22] cachio: thank you! [10:24] mvo, yaw [10:25] sergiusens, please tell me which test we should do to validate snapcraft with the core 2.35 [10:25] mvo, I am leaving in 10 minutes, I'll ping you once I am back [10:26] cachio: sure, no worries [10:27] xnox: fwiw, just tested the same behavior on fedora28 with systemd 238 so might be an upstream bug [10:41] niemeyer: how do I 'fork' a comment into its own topic? For https://forum.snapcraft.io/t/where-is-a-snap-stored-and-how-can-i-change-that/3194/10?u=chipaca [10:42] Chipaca: Click on the wrench or gear (whatever it is) for the topic, and there should be an option there which will allow you to select the topics to split [10:42] niemeyer: https://imgur.com/xt0xCgS [10:43] Hmm [10:43] Chipaca: This is the post menu [10:44] Chipaca: At the bottom of the post there should be a topic-general one [10:44] ah, for the _topic_ [10:44] Yeah [10:44] niemeyer: yup! found it, thanks! [10:44] np [10:48] I plague of radioactive locusts on all randomly-failing tests [10:48] s/I/A/ [11:11] re :) [11:12] useful call with mborzecki [11:12] zyga: yeah, nice stuff [11:31] mborzecki: wrote that comment now [11:33] zyga: thanks === pstolowski is now known as pstolowski|lunch [11:41] cachio, mvo: "snap install snapcraft --classic && snap install lxd && cd $(mktemp -d) && snapcraft init && snapcraft cleanbuild" [11:44] sergiusens, lxd init ? not needed anymore ? [11:45] * Chipaca ~> lunch === chihchun is now known as chihchun_afk [11:57] * Chipaca ~> hopefully lunch cor real this time [12:00] ogra: yes you do, "lxd init --auto" should cover that [12:13] zyga: mvo: shall we land https://github.com/snapcore/snapd/pull/5720 ? [12:26] Hi, what does this mean? automated review rejected the snap [12:26] Failed to run click-review properly. click-review === pstolowski|lunch is now known as pstolowski === chihchun_afk is now known as chihchun [12:33] I can't even reupload it because automated review rejects with that dumb error that makes zero sense to user [12:34] debugging why systemd env generators do not work for PATH [12:35] sborovkov: there's been a regression on how review tools results are being handled, it should be getting fixed [12:35] pedronis: is there any workaround [12:36] ? [12:36] sborovkov: I think once the fix is out it should be possible to re-run things and get the proper result and go from there [12:36] mborzecki: yes, I see it was merged now [12:36] out in the store [12:37] mvo: hey [12:37] mvo: about that :) [12:37] sborovkov: roadmr can probably say more when he is around [12:37] mvo: I have a question related to PATH [12:37] mvo: (also systemd env generators were made for PATH so if they don't work it's a bit unexpected) [12:37] pedronis: ok, thanks. [12:37] mvo: on my quest to kill --with-snap-mount-dir I reached 990-snapd.conf.in [12:37] zyga: yeah, its super annoying [12:37] zyga: what is your question? [12:37] mvo: maybe we can ask Zbyszek about it (he implemented them) [12:38] mvo: can we simply add both /snap/bin:/var/lib/snapd/snap to PATH [12:38] zyga: do you know him? [12:38] mvo: so that we have one set of files [12:38] mvo: yes [12:38] mvo: I met him at flock and he lives nearby [12:38] zyga: I was trying to build a test case first before I bother upstream [12:38] mvo: he invited me to co-work with him on snapd topics in fedora yesterday but $meeting_frenzy [12:38] zyga: but even that is hard :/ [12:38] zyga: woah [12:38] zyga: ok, that sounds great [12:38] mvo: yes :) he's super nice [12:39] since he wrote this feature we may just ask [12:39] but ideally we'd have a reproducer that we can show him [12:39] (something trivial like a shell script that ECHOs one path) [12:39] mvo: so since we are looking at the same file now, how can I reproduce the problem? [12:39] pedronis: or is there anyone who i can ask to set it to the accepted state? since it's a branded store it should not be an issue [12:39] zyga: reproducer is really just "#!/bin/sh -ex; echo "PATH=$PATH:/snap/bin" ; echo "OTHER_ENV=foo" [12:40] ok [12:40] * zyga adds that and reboots [12:40] do I need to reboot? [12:40] zyga: and when I daemon-reload and run "systemd-run --unit testenv; journalctl -u testenv" [12:40] zyga: no [12:40] zyga: just daemon reload [12:40] ok, one sec [12:40] zyga: let me write a shell script [12:40] zyga: so that its bullet-proof [12:40] zyga: and then we can share it [12:40] -rw-rw-r-- 1 zyga zyga 32 Aug 24 14:00 990-snapd.conf.in [12:40] we drop the .in file !?! [12:41] not the .conf file [12:41] zyga: wuuut? [12:41] mvo, could that be it :D [12:41] yep [12:41] look at your disk [12:41] zyga: no, thats not it [12:41] zyga: I mean that is a problem but that is not related to the systemd env stuff I was poking at this morning [12:41] hm, something dropped .in on my disk [12:41] zyga: anyway, I make a reproducer script [12:41] k [12:41] zyga: and ping you [12:41] the in file is not from dpkg [12:42] how. I got it now [12:42] it's from august 24 [12:42] anyway [12:47] sborovkov: if it's a branded the store somebody on your team should have permissions to do that , but if the review-tools failed there might something off for real with the snap [12:49] pedronis, hmm, so we can override automatic review? my previous snap version was uploaded and review went fine. diff shows that there is no difference in snapcraft.yaml besides snap version [12:49] zyga: please try http://paste.ubuntu.com/p/pjMyGZ7RsR/ [12:50] mmm [12:50] sborovkov: there are checks on version too? what does version look like ? [12:50] zyga: hm? [12:50] nothing, just "mmm, trying" (ack) [12:50] I heard you :) [12:50] zyga: ta [12:50] zyga: sorry, misread :) [12:50] sborovkov: the first is not a question, there are checks on version too since a while [12:51] mvo: it doesn't work? [12:51] mborzecki: it does [12:51] mborzecki: *but* [12:51] mborzecki: not for PATH [12:51] hm [12:51] mborzecki: it looks like something overrides that later again [12:51] https://www.irccloud.com/pastebin/KGyqwVCZ/ [12:51] mvo: can you rename it to 99-test.sh ? [12:51] mborzecki: when I set PATHxxx=$PATH:/snap/bin I see a (very) different path [12:51] mborzecki: sure, let me try that [12:51] pedronis, I mean in the snapcraft.yaml I just bumped the version from 1.0.19 to 1.0.20. Error from the tools is very weird Failed to run click-review properly. click-review [12:52] something seems strange [12:52] niemeyer: I was actually considering runing delete on loading the warnings [12:52] niemeyer: I'll look into prune though, that might be better (or maybe both) [12:52] sborovkov: do you have a dot at the end of the version by chance or something else odd with the version line [12:53] niemeyer: note the current impl doesn't delete anywhere [12:53] zyga: hold on [12:53] sborovkov: is this a large snap? [12:53] zyga: the script has at least one bug, let me fix this first [12:53] mvo: I have some interesting findings from tinkering [12:53] k [12:54] mvo: for eg. here on arch i have 10-arch which overrides PATH [12:54] pedronis, no. it is a large snap yes [12:54] version is set to 1.0.20 [12:54] sborovkov: ok, either way we need somebody that can look around in the store (which I can't) [12:55] mvo: what's testenv? [12:55] Chipaca: Yeah, Prune seems perfect for that.. it's already multi-purpose, and has the goal of GCing [12:55] zyga: http://paste.ubuntu.com/p/JnmTrjpWsP/ [12:55] ah, 'EOF' is key [12:55] zyga: its just a systemd unit that runs the "env" command [12:55] zyga: yeah, sorry [12:55] mvo: where is testenv defined? [12:56] systemctl cat doesn't know about [12:56] about it [12:56] zyga: systemd-run --unit testenv env [12:56] zyga: thats what creates it [12:56] ahh [12:56] I see [12:56] zyga: I can add -k [12:56] neat [12:56] zyga: to keep it running [12:57] mvo: does systemd-environment-d-generator matter? [12:57] mvo: I have an idea! [12:57] one sec [12:58] sborovkov: I saw you opened a topic, I will ping somebody that can look when they are around [12:58] zyga: tell me more please [12:59] pedronis, thanks [12:59] there's a built-in generator that reads /etc/environment.d [12:59] and it is stated that generators can mutate the environment for future generators [12:59] so perhaps what happens is that we do something but then the default generator just overwrites PATH [13:01] The environment.d directories contain a list of "global" environment variable assignments for the user environment. systemd-environment-d-generator(8) parses them [13:01] and updates the environment exported by the systemd user instance to the services it starts. [13:01] zyga: standup :) [13:01] zyga: /etc/environment.d is empty for me [13:02] I have 999-snapd.conf there because I'm running dpkg -i'd master [13:03] zyga: but even that is ok, no? [13:04] zyga: i.e. nothing in it overrides PATH [13:04] Aug 29 15:03:52 fyke env[45277]: MAGIC=canary [13:04] Aug 29 15:03:52 fyke env[45277]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [13:04] Aug 29 15:03:52 fyke env[45277]: ALT_PATH=/sbin:/usr/sbin:/bin:/usr/bin:/it-worked [13:04] zyga: anyway I was also able to reproduce this in fedora [13:04] echo "ALT_PATH=$PATH:/it-worked" [13:04] echo "PATH=$PATH:/it-worked" [13:04] echo "MAGIC=canary" [13:04] zyga: but that was on our fedora (google image) [13:04] zyga: so same issue, right? [13:04] I'm testing on bionic locally [13:04] yes [13:04] but look that ALT_PATH is ok [13:04] but still contains _different_ value [13:05] so this smells like something else (pam?) changing everything [13:05] compare [13:05] : /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin vs /sbin:/usr/sbin:/bin:/usr/bin [13:05] zyga: yeah [13:06] zyga: the latest reproducer also uses PATH in the OTHER_ENV to show that [13:06] the first is PATH , the other is ALT_PATH sans the it-worked directory [13:06] zyga: so yeah, something is fishy [13:06] so [13:06] grep for /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [13:06] that's the one we get [13:06] zyga: well, grep for that in the systemd source ;) [13:06] zyga: it is also the #define DEFAULT_PATH there [13:07] zyga: its slightly more complicated there because it has it split up for combined /usr,/ and not but afaict its the same as we have in /etc/environment [13:07] it's all broken [13:07] look at this [13:07] zyga: I also moved /etc/environment away and tried with that [13:07] https://www.irccloud.com/pastebin/FnDZ58Y1/ [13:07] zyga: no difference, but maybe I need to reboot [13:07] the value in /etc/environment is _different_, it has /usr/games as well that we don't see [13:08] the one in login.defs matches [13:08] zyga: aha, I actually moved it away /etc/enviornment and still the same issue [13:08] let me grep elsewhere [13:08] zyga: yeah, I commted that out [13:08] zyga: same issue [13:08] zyga: I think its internal somehow but maybe I'm wrong [13:10] I did a grep in /usr [13:10] and ... nothing sensible [13:10] nothing in systemd [13:10] or libraries [13:10] https://www.irccloud.com/pastebin/WKOrsDWb/ [13:11] mvo: /bin/slogin or /bin/rlogin [13:11] are those used? [13:12] ah, I didn't grep in /lib [13:12] zyga: https://github.com/systemd/systemd/blob/54fe2ce1b943b55162cc35b28e976c4fbf490dae/src/basic/path-util.h#L26 [13:12] it's internal https://www.irccloud.com/pastebin/NI6HRX6J/ [13:24] mvo: your test script has the same issue here on systemd 239 [13:34] mborzecki: something also overrides path for you? yeah, I think we need zyga to talk to upstream [13:38] some more fun with PATH [13:38] I'll share my script [13:48] zyga: anything interessting? [13:48] mvo: yes [13:48] so, some more context needed [13:48] zyga: does it work? [13:48] wanna HO? [13:49] https://hangouts.google.com/call/-0nioHSGU_Bqe5rpEuYaAAEI === chihchun is now known as chihchun_afk [14:27] mvo, yo! re the testing. [14:27] mvo, you do need to reboot... [14:27] cause manager.c doesn't really rerun system generators on reload/re-exec, or at least I do not see it do that. [14:28] sergiusens, hey, I got this https://paste.ubuntu.com/p/BCyssdQKTZ/ [14:28] xnox: I think reboot does not help and afaicts it does re-run the generators, I did "strace -f -p 1 -e trace=execve -s256 -v" and I can see daemon-reload running my generator [14:28] xnox: but let me try to reboot just to be one the safe side [14:29] cachio: try again, but "snap refresh snapcraft --edge" first. [14:30] xnox: http://paste.ubuntu.com/p/JnmTrjpWsP/ <- fwiw - my reproducer [14:30] that should come out as soon as this ends https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024 [14:30] xnox: but *maybe* it runs the generator just does not pick it up [14:30] for which I was hoping more interaction with, but oh well. [14:30] xnox: anyway, trying to reboot now [14:34] * zyga had lunch and needs a small break [14:36] xnox: ohhh, it looks like the reboot helped, let me try this again on a clean system (cc zyga) [14:36] mvo: hold on, I rebooted _doen_ times [14:36] mvo: what did you get? [14:36] zyga: oh [14:36] *dozen* [14:37] mvo: did you get PATH changed? [14:37] mvo, i think daemon-reexec may be sufficient, deamon-reload would not be. === chihchun_afk is now known as chihchun [14:37] mvo, note that system-environment-generators are not available in xenial [14:38] mvo, i need this in bionic and up, .deb package... [14:38] http://paste.ubuntu.com/p/DGKWqtQvZW/ [14:38] mvo, such that on classic systems things are right. [14:38] that's what I ran [14:38] and on core18 [14:38] xnox: yeah, I'm testing this on bionic [14:38] zyga: yes http://paste.ubuntu.com/p/Sr2BMvh8fq/ [14:38] zyga: spread test for parallel instances and the content interface https://paste.ubuntu.com/p/qh33dy9j3W/ basically install some instances, poke data here and there, verify that it's written and visible everywhere [14:38] zyga: I'm trying inside spread now [14:39] mvo, zyga $ systemclt daemon-reexec [14:39] mvo: can you add /foo or something like that and check if that is pickedu p [14:39] zyga: I messed around quite a bit with my system [14:39] not just daemon-reload.... [14:39] k [14:39] xnox: cool, will try that [14:39] I'll check [14:39] mborzecki: ack [14:39] zyga: yeah, its strange [14:42] xnox: also the documentation is a bit misleading: "After installing new generators or updating the configuration, systemctl daemon-reload may be executed. This will re-run all generators, updating environment configuration. It will be used for any services that are started subsequently." (from the systemd.environment-generator man page) [14:42] xnox: but yeah, running inside spread now, hopefully that was it :) [14:44] sergiusens, https://paste.ubuntu.com/p/sqb3YRpZSH/ [14:45] sergiusens, am I doing somthing wrong? [14:45] cachio: is the store down? that is basically "snap install core" failing on lxd [14:45] mvo, yeah that's lies. [14:46] xnox: :( thanks for confirming [14:46] mvo, * but will not affect running units, units that are starting or stopping, failed units, or things that have been loaded already, or manager instance env will not be updated and so on and so forth [14:46] is closer to truth [14:47] mvo: because of the fact that the test cleans up after itself my rebooting was not a factor [14:47] sergiusens, it is not [14:47] zyga: ohhhhh [14:47] zyga: ok [14:47] I though it was a problem on my network config [14:47]