| dave_uy | How do you add a license for a publish snap? | 00:23 |
|---|---|---|
| === ackk is now known as Guest76534 | ||
| === StoneTable is now known as aisrael | ||
| * Son_Goku hates his life right now | 03:20 | |
| Son_Goku | my air conditioning died, so now it's nearly 35C in my house | 03:21 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 05:06 |
| === chihchun is now known as chihchun_afk | ||
| zyga | Good morning | 05:58 |
| mborzecki | zyga: hey | 06:03 |
| zyga | :) | 06:06 |
| mborzecki | mup is quiet again? | 06:09 |
| mborzecki | https://github.com/snapcore/snapd/pull/5735 | 06:10 |
| mborzecki | simple one ^^ | 06:10 |
| mborzecki | mvo: hey | 06:10 |
| mvo | hey mborzecki | 06:11 |
| zyga | mvo: good morning | 06:11 |
| mvo | looking | 06:11 |
| mvo | good morning zyga | 06:12 |
| zyga | mvo: that issue from last evening, the journal included sigsegv | 06:12 |
| zyga | not sure if you noticed that | 06:12 |
| mvo | zyga: thanks for the log from last night I think I know now what is going on | 06:12 |
| mvo | zyga: yeah, console-conf | 06:12 |
| mvo | zyga: but the key was the error from snap-repair \o/ | 06:12 |
| zyga | oh? | 06:13 |
| zyga | can you explain? | 06:13 |
| mvo | zyga: part of the "bootstrap" of snapd itself is to start its services | 06:16 |
| mvo | zyga: if one of them fails the bootstrap fails | 06:17 |
| mvo | zyga: and snap-repair is failing apparently because it has no network | 06:17 |
| mvo | zyga: so the fix is probably as simple as making this non-fatal (which it is - I mean, it should be :) | 06:17 |
| zyga | ah, I see | 06:18 |
| === chihchun_afk is now known as chihchun | ||
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:09 |
| mborzecki | pstolowski: o/ | 07:10 |
| mvo | hey pstolowski ! good morning | 07:15 |
| mvo | zyga: if I could get a review for 5734 master should be good again | 07:32 |
| mvo | zyga: right now tests are failing there because of the latest core snap changes | 07:32 |
| zyga | mmm | 07:35 |
| zyga | doing now | 07:35 |
| zyga | mvo: question | 07:36 |
| mvo | zyga: ta | 07:36 |
| zyga | 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 |
| zyga | 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 |
| zyga | shall I remove that code or just wait until nobody reasonably will be on the old snapd | 07:37 |
| mvo | zyga: if we find /etc/alternatives we keep doing what we are doing today | 07:37 |
| mvo | zyga: and once we have epochs we drop it | 07:37 |
| zyga | mvo: ah, so only after epochs | 07:38 |
| zyga | that was the answer I was looking for, thanks! | 07:38 |
| === Guest76534 is now known as ackk | ||
| mvo | zyga: we can add a note in the code though | 07:38 |
| mvo | zyga: we *could* keep the test alive using ubuntu-core | 07:38 |
| zyga | ack | 07:38 |
| mvo | zyga: which never changes | 07:38 |
| mvo | zyga: I mean, the spread that we just removed | 07:38 |
| mvo | zyga: but I think its fine | 07:38 |
| zyga | nah | 07:38 |
| zyga | I think it's fine | 07:38 |
| mvo | :) agreement! | 07:39 |
| t1mp | hello | 08:06 |
| zyga | hello | 08:06 |
| t1mp | is there a recommended way to get python 3.6 or 3.7 in a snap? Xenial comes with 3.5... | 08:07 |
| zyga | You can use base: core18 to use ubuntu 18.04 as a base | 08:07 |
| zyga | or you can build python from source as a part | 08:07 |
| zyga | but I think using the base is easier | 08:07 |
| t1mp | yes, I prefer not to spend the time to build python from source | 08:08 |
| t1mp | right, I'll try core18. I thought that xenial was basically always the base image | 08:08 |
| === chihchun is now known as chihchun_afk | ||
| t1mp | maybe then it is also time to upgrade my laptop, so that I have the same environment everywhere :) | 08:09 |
| t1mp | well, I use docker anyway | 08:09 |
| t1mp | zyga: thanks | 08:09 |
| zyga | t1mp: you can now choose out of two stable bases | 08:09 |
| zyga | t1mp: with more coming | 08:09 |
| zyga | t1mp: obviously anyone can run all the snaps regardless of the base they use :) | 08:10 |
| t1mp | 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 |
| zyga | yeah, I agree | 08:12 |
| zyga | well, good luck :-) | 08:12 |
| t1mp | well, for testing the python code locally I use miniconda anyway. | 08:12 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | pedronis: thank you for the review! :-D | 08:54 |
| Chipaca | pedronis: I'll look at writing that test asap | 08:55 |
| pedronis | 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:55 |
| Chipaca | pedronis: yep, i'll add a comment also | 08:56 |
| zyga | Chipaca: question for you sir | 08:56 |
| Chipaca | 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 |
| zyga | what's the factor that chooses * over ✓ https://www.irccloud.com/pastebin/EYj3TrPi/ | 08:56 |
| Chipaca | 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 |
| zyga | hmm | 08:58 |
| zyga | interesting | 08:58 |
| Chipaca | zyga: I say "set" but I mean "set and non-empty", fwiw | 08:58 |
| zyga | Chipaca: this test works/fails depending on suse version | 08:59 |
| zyga | missing mocking? | 08:59 |
| Chipaca | zyga: I don't think so, but, maybe? | 08:59 |
| zyga | or maybe broken mocking, I'll re-trigger | 09:00 |
| Chipaca | zyga: maybe you're on to somehting with the mocking | 09:02 |
| zyga | Chipaca: the log comes from obs | 09:02 |
| Chipaca | zyga: I think we set LANG=UTF-8 in our run | 09:03 |
| Chipaca | er, C.UTF-8 | 09:03 |
| Chipaca | it's a regexp, we could change it to accept either :-) | 09:03 |
| zyga | yes, something for .1 | 09:03 |
| zyga | I'll fix that | 09:03 |
| Chipaca | the smile is because it'll be a fun regexp | 09:03 |
| Chipaca | [*✓] | 09:04 |
| Chipaca | :-) | 09:04 |
| Chipaca | zyga: but, there should be a bunch of other tests failing in the same way | 09:04 |
| Chipaca | or similar | 09:04 |
| zyga | mmm | 09:04 |
| Chipaca | zyga: 'snap info' output for ex | 09:04 |
| Chipaca | zyga: (not just publisher but the channel map will be different on non-utf8) | 09:05 |
| Chipaca | I _nearly_ succumbed to the temptation of working on widths this last vacation | 09:07 |
| Chipaca | but i resisted! i can do it in my 20% time if i ever do | 09:07 |
| zyga | 3 tests left | 09:08 |
| zyga | 2945 tests passed with my patch :) | 09:09 |
| pstolowski | zyga: hey, got a moment for HO? | 09:09 |
| zyga | yes | 09:09 |
| zyga | I saw your ping last evening | 09:09 |
| zyga | but I was on a walk then | 09:09 |
| zyga | let's HO | 09:09 |
| zyga | can you send me the link pelase | 09:09 |
| zyga | *please | 09:09 |
| pedronis | pstolowski: I reviewed the sublevel PR with some comments | 09:20 |
| pstolowski | pedronis: thank you! | 09:28 |
| mborzecki | 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 |
| mborzecki | heh | 09:40 |
| ogra | 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:42 |
| zyga | ogra: snap list --all or something will show more things | 09:47 |
| zyga | but I see your point | 09:47 |
| === tomwardill_ is now known as tomwardill | ||
| zyga | maybe on core we should show the boot snap | 09:47 |
| ogra | yeah | 09:47 |
| ogra | we often have customers digging through CVEs for example ... for that they need to know what rootfs revision they run etc | 09:48 |
| ogra | or perhaps add a --show-base option that lists them again | 09:48 |
| ogra | (i dont really care about the impleentation but the info is valuable on core) | 09:49 |
| zyga | ogra: I don't know what the exact argument to show / hide this would be but I think we agreed to have some | 09:51 |
| ogra | ah, cool, as long as seeing them somehow is still possible all is fine ... | 09:52 |
| mvo | 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 |
| mvo | known reasons and nothing in the (manager) code stands out as strange | 09:54 |
| pachulo | 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:10 |
| popey | pachulo: https://forum.snapcraft.io/t/the-road-to-core18/5547 this do? | 10:13 |
| pachulo | ok, yes, forgot about it, thanks popey ! | 10:18 |
| cachio | mvo, hey, I got +1 to go to stable with 2.35 | 10:20 |
| mvo | 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 |
| cachio | mvo, no, I'll do it today | 10:21 |
| mvo | cachio: thank you! | 10:22 |
| cachio | mvo, yaw | 10:24 |
| cachio | sergiusens, please tell me which test we should do to validate snapcraft with the core 2.35 | 10:25 |
| cachio | mvo, I am leaving in 10 minutes, I'll ping you once I am back | 10:25 |
| mvo | cachio: sure, no worries | 10:26 |
| mvo | xnox: fwiw, just tested the same behavior on fedora28 with systemd 238 so might be an upstream bug | 10:27 |
| Chipaca | 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:41 |
| niemeyer | 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 |
| Chipaca | niemeyer: https://imgur.com/xt0xCgS | 10:42 |
| niemeyer | Hmm | 10:43 |
| niemeyer | Chipaca: This is the post menu | 10:43 |
| niemeyer | Chipaca: At the bottom of the post there should be a topic-general one | 10:44 |
| Chipaca | ah, for the _topic_ | 10:44 |
| niemeyer | Yeah | 10:44 |
| Chipaca | niemeyer: yup! found it, thanks! | 10:44 |
| niemeyer | np | 10:44 |
| Chipaca | I plague of radioactive locusts on all randomly-failing tests | 10:48 |
| Chipaca | s/I/A/ | 10:48 |
| zyga | re :) | 11:11 |
| zyga | useful call with mborzecki | 11:12 |
| mborzecki | zyga: yeah, nice stuff | 11:12 |
| zyga | mborzecki: wrote that comment now | 11:31 |
| mborzecki | zyga: thanks | 11:33 |
| === pstolowski is now known as pstolowski|lunch | ||
| sergiusens | cachio, mvo: "snap install snapcraft --classic && snap install lxd && cd $(mktemp -d) && snapcraft init && snapcraft cleanbuild" | 11:41 |
| ogra | sergiusens, lxd init ? not needed anymore ? | 11:44 |
| * Chipaca ~> lunch | 11:45 | |
| === chihchun is now known as chihchun_afk | ||
| * Chipaca ~> hopefully lunch cor real this time | 11:57 | |
| sergiusens | ogra: yes you do, "lxd init --auto" should cover that | 12:00 |
| mborzecki | zyga: mvo: shall we land https://github.com/snapcore/snapd/pull/5720 ? | 12:13 |
| sborovkov | Hi, what does this mean? automated review rejected the snap | 12:26 |
| sborovkov | Failed to run click-review properly. click-review | 12:26 |
| === pstolowski|lunch is now known as pstolowski | ||
| === chihchun_afk is now known as chihchun | ||
| sborovkov | I can't even reupload it because automated review rejects with that dumb error that makes zero sense to user | 12:33 |
| mvo | debugging why systemd env generators do not work for PATH | 12:34 |
| pedronis | sborovkov: there's been a regression on how review tools results are being handled, it should be getting fixed | 12:35 |
| sborovkov | pedronis: is there any workaround | 12:35 |
| sborovkov | ? | 12:36 |
| pedronis | 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 |
| zyga | mborzecki: yes, I see it was merged now | 12:36 |
| pedronis | out in the store | 12:36 |
| zyga | mvo: hey | 12:37 |
| zyga | mvo: about that :) | 12:37 |
| pedronis | sborovkov: roadmr can probably say more when he is around | 12:37 |
| zyga | mvo: I have a question related to PATH | 12:37 |
| zyga | mvo: (also systemd env generators were made for PATH so if they don't work it's a bit unexpected) | 12:37 |
| sborovkov | pedronis: ok, thanks. | 12:37 |
| zyga | mvo: on my quest to kill --with-snap-mount-dir I reached 990-snapd.conf.in | 12:37 |
| mvo | zyga: yeah, its super annoying | 12:37 |
| mvo | zyga: what is your question? | 12:37 |
| zyga | mvo: maybe we can ask Zbyszek about it (he implemented them) | 12:37 |
| zyga | mvo: can we simply add both /snap/bin:/var/lib/snapd/snap to PATH | 12:38 |
| mvo | zyga: do you know him? | 12:38 |
| zyga | mvo: so that we have one set of files | 12:38 |
| zyga | mvo: yes | 12:38 |
| zyga | mvo: I met him at flock and he lives nearby | 12:38 |
| mvo | zyga: I was trying to build a test case first before I bother upstream | 12:38 |
| zyga | mvo: he invited me to co-work with him on snapd topics in fedora yesterday but $meeting_frenzy | 12:38 |
| mvo | zyga: but even that is hard :/ | 12:38 |
| mvo | zyga: woah | 12:38 |
| mvo | zyga: ok, that sounds great | 12:38 |
| zyga | mvo: yes :) he's super nice | 12:38 |
| zyga | since he wrote this feature we may just ask | 12:39 |
| zyga | but ideally we'd have a reproducer that we can show him | 12:39 |
| zyga | (something trivial like a shell script that ECHOs one path) | 12:39 |
| zyga | mvo: so since we are looking at the same file now, how can I reproduce the problem? | 12:39 |
| sborovkov | 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 |
| mvo | zyga: reproducer is really just "#!/bin/sh -ex; echo "PATH=$PATH:/snap/bin" ; echo "OTHER_ENV=foo" | 12:39 |
| zyga | ok | 12:40 |
| * zyga adds that and reboots | 12:40 | |
| zyga | do I need to reboot? | 12:40 |
| mvo | zyga: and when I daemon-reload and run "systemd-run --unit testenv; journalctl -u testenv" | 12:40 |
| mvo | zyga: no | 12:40 |
| mvo | zyga: just daemon reload | 12:40 |
| zyga | ok, one sec | 12:40 |
| mvo | zyga: let me write a shell script | 12:40 |
| mvo | zyga: so that its bullet-proof | 12:40 |
| mvo | zyga: and then we can share it | 12:40 |
| zyga | -rw-rw-r-- 1 zyga zyga 32 Aug 24 14:00 990-snapd.conf.in | 12:40 |
| zyga | we drop the .in file !?! | 12:40 |
| zyga | not the .conf file | 12:41 |
| mvo | zyga: wuuut? | 12:41 |
| zyga | mvo, could that be it :D | 12:41 |
| zyga | yep | 12:41 |
| zyga | look at your disk | 12:41 |
| mvo | zyga: no, thats not it | 12:41 |
| mvo | 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 |
| zyga | hm, something dropped .in on my disk | 12:41 |
| mvo | zyga: anyway, I make a reproducer script | 12:41 |
| zyga | k | 12:41 |
| mvo | zyga: and ping you | 12:41 |
| zyga | the in file is not from dpkg | 12:41 |
| zyga | how. I got it now | 12:42 |
| zyga | it's from august 24 | 12:42 |
| zyga | anyway | 12:42 |
| pedronis | 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:47 |
| sborovkov | 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 |
| mvo | zyga: please try http://paste.ubuntu.com/p/pjMyGZ7RsR/ | 12:49 |
| zyga | mmm | 12:50 |
| pedronis | sborovkov: there are checks on version too? what does version look like ? | 12:50 |
| mvo | zyga: hm? | 12:50 |
| zyga | nothing, just "mmm, trying" (ack) | 12:50 |
| zyga | I heard you :) | 12:50 |
| mvo | zyga: ta | 12:50 |
| mvo | zyga: sorry, misread :) | 12:50 |
| pedronis | sborovkov: the first is not a question, there are checks on version too since a while | 12:50 |
| mborzecki | mvo: it doesn't work? | 12:51 |
| mvo | mborzecki: it does | 12:51 |
| mvo | mborzecki: *but* | 12:51 |
| mvo | mborzecki: not for PATH | 12:51 |
| mborzecki | hm | 12:51 |
| mvo | mborzecki: it looks like something overrides that later again | 12:51 |
| zyga | https://www.irccloud.com/pastebin/KGyqwVCZ/ | 12:51 |
| mborzecki | mvo: can you rename it to 99-test.sh ? | 12:51 |
| mvo | mborzecki: when I set PATHxxx=$PATH:/snap/bin I see a (very) different path | 12:51 |
| mvo | mborzecki: sure, let me try that | 12:51 |
| sborovkov | 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:51 |
| pedronis | something seems strange | 12:52 |
| Chipaca | niemeyer: I was actually considering runing delete on loading the warnings | 12:52 |
| Chipaca | niemeyer: I'll look into prune though, that might be better (or maybe both) | 12:52 |
| pedronis | sborovkov: do you have a dot at the end of the version by chance or something else odd with the version line | 12:52 |
| Chipaca | niemeyer: note the current impl doesn't delete anywhere | 12:53 |
| mvo | zyga: hold on | 12:53 |
| pedronis | sborovkov: is this a large snap? | 12:53 |
| mvo | zyga: the script has at least one bug, let me fix this first | 12:53 |
| zyga | mvo: I have some interesting findings from tinkering | 12:53 |
| zyga | k | 12:53 |
| mborzecki | mvo: for eg. here on arch i have 10-arch which overrides PATH | 12:54 |
| sborovkov | pedronis, no. it is a large snap yes | 12:54 |
| sborovkov | version is set to 1.0.20 | 12:54 |
| pedronis | sborovkov: ok, either way we need somebody that can look around in the store (which I can't) | 12:54 |
| zyga | mvo: what's testenv? | 12:55 |
| niemeyer | Chipaca: Yeah, Prune seems perfect for that.. it's already multi-purpose, and has the goal of GCing | 12:55 |
| mvo | zyga: http://paste.ubuntu.com/p/JnmTrjpWsP/ | 12:55 |
| zyga | ah, 'EOF' is key | 12:55 |
| mvo | zyga: its just a systemd unit that runs the "env" command | 12:55 |
| mvo | zyga: yeah, sorry | 12:55 |
| zyga | mvo: where is testenv defined? | 12:55 |
| zyga | systemctl cat doesn't know about | 12:56 |
| zyga | about it | 12:56 |
| mvo | zyga: systemd-run --unit testenv env | 12:56 |
| mvo | zyga: thats what creates it | 12:56 |
| zyga | ahh | 12:56 |
| zyga | I see | 12:56 |
| mvo | zyga: I can add -k | 12:56 |
| zyga | neat | 12:56 |
| mvo | zyga: to keep it running | 12:56 |
| zyga | mvo: does systemd-environment-d-generator matter? | 12:57 |
| zyga | mvo: I have an idea! | 12:57 |
| zyga | one sec | 12:57 |
| pedronis | sborovkov: I saw you opened a topic, I will ping somebody that can look when they are around | 12:58 |
| mvo | zyga: tell me more please | 12:58 |
| sborovkov | pedronis, thanks | 12:59 |
| zyga | there's a built-in generator that reads /etc/environment.d | 12:59 |
| zyga | and it is stated that generators can mutate the environment for future generators | 12:59 |
| zyga | so perhaps what happens is that we do something but then the default generator just overwrites PATH | 12:59 |
| zyga | 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 |
| zyga | and updates the environment exported by the systemd user instance to the services it starts. | 13:01 |
| mvo | zyga: standup :) | 13:01 |
| mvo | zyga: /etc/environment.d is empty for me | 13:01 |
| zyga | I have 999-snapd.conf there because I'm running dpkg -i'd master | 13:02 |
| mvo | zyga: but even that is ok, no? | 13:03 |
| mvo | zyga: i.e. nothing in it overrides PATH | 13:04 |
| zyga | Aug 29 15:03:52 fyke env[45277]: MAGIC=canary | 13:04 |
| zyga | Aug 29 15:03:52 fyke env[45277]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | 13:04 |
| zyga | Aug 29 15:03:52 fyke env[45277]: ALT_PATH=/sbin:/usr/sbin:/bin:/usr/bin:/it-worked | 13:04 |
| mvo | zyga: anyway I was also able to reproduce this in fedora | 13:04 |
| zyga | echo "ALT_PATH=$PATH:/it-worked" | 13:04 |
| zyga | echo "PATH=$PATH:/it-worked" | 13:04 |
| zyga | echo "MAGIC=canary" | 13:04 |
| mvo | zyga: but that was on our fedora (google image) | 13:04 |
| mvo | zyga: so same issue, right? | 13:04 |
| zyga | I'm testing on bionic locally | 13:04 |
| zyga | yes | 13:04 |
| zyga | but look that ALT_PATH is ok | 13:04 |
| zyga | but still contains _different_ value | 13:04 |
| zyga | so this smells like something else (pam?) changing everything | 13:05 |
| zyga | compare | 13:05 |
| zyga | : /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin vs /sbin:/usr/sbin:/bin:/usr/bin | 13:05 |
| mvo | zyga: yeah | 13:05 |
| mvo | zyga: the latest reproducer also uses PATH in the OTHER_ENV to show that | 13:06 |
| zyga | the first is PATH , the other is ALT_PATH sans the it-worked directory | 13:06 |
| mvo | zyga: so yeah, something is fishy | 13:06 |
| zyga | so | 13:06 |
| zyga | grep for /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | 13:06 |
| zyga | that's the one we get | 13:06 |
| mvo | zyga: well, grep for that in the systemd source ;) | 13:06 |
| mvo | zyga: it is also the #define DEFAULT_PATH there | 13:06 |
| mvo | 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 |
| zyga | it's all broken | 13:07 |
| zyga | look at this | 13:07 |
| mvo | zyga: I also moved /etc/environment away and tried with that | 13:07 |
| zyga | https://www.irccloud.com/pastebin/FnDZ58Y1/ | 13:07 |
| mvo | zyga: no difference, but maybe I need to reboot | 13:07 |
| zyga | the value in /etc/environment is _different_, it has /usr/games as well that we don't see | 13:07 |
| zyga | the one in login.defs matches | 13:08 |
| mvo | zyga: aha, I actually moved it away /etc/enviornment and still the same issue | 13:08 |
| zyga | let me grep elsewhere | 13:08 |
| mvo | zyga: yeah, I commted that out | 13:08 |
| mvo | zyga: same issue | 13:08 |
| mvo | zyga: I think its internal somehow but maybe I'm wrong | 13:08 |
| zyga | I did a grep in /usr | 13:10 |
| zyga | and ... nothing sensible | 13:10 |
| zyga | nothing in systemd | 13:10 |
| zyga | or libraries | 13:10 |
| zyga | https://www.irccloud.com/pastebin/WKOrsDWb/ | 13:10 |
| zyga | mvo: /bin/slogin or /bin/rlogin | 13:11 |
| zyga | are those used? | 13:11 |
| zyga | ah, I didn't grep in /lib | 13:12 |
| mvo | zyga: https://github.com/systemd/systemd/blob/54fe2ce1b943b55162cc35b28e976c4fbf490dae/src/basic/path-util.h#L26 | 13:12 |
| zyga | it's internal https://www.irccloud.com/pastebin/NI6HRX6J/ | 13:12 |
| mborzecki | mvo: your test script has the same issue here on systemd 239 | 13:24 |
| mvo | mborzecki: something also overrides path for you? yeah, I think we need zyga to talk to upstream | 13:34 |
| zyga | some more fun with PATH | 13:38 |
| zyga | I'll share my script | 13:38 |
| mvo | zyga: anything interessting? | 13:48 |
| zyga | mvo: yes | 13:48 |
| zyga | so, some more context needed | 13:48 |
| mvo | zyga: does it work? | 13:48 |
| zyga | wanna HO? | 13:48 |
| zyga | https://hangouts.google.com/call/-0nioHSGU_Bqe5rpEuYaAAEI | 13:49 |
| === chihchun is now known as chihchun_afk | ||
| xnox | mvo, yo! re the testing. | 14:27 |
| xnox | mvo, you do need to reboot... | 14:27 |
| xnox | cause manager.c doesn't really rerun system generators on reload/re-exec, or at least I do not see it do that. | 14:27 |
| cachio | sergiusens, hey, I got this https://paste.ubuntu.com/p/BCyssdQKTZ/ | 14:28 |
| mvo | 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 |
| mvo | xnox: but let me try to reboot just to be one the safe side | 14:28 |
| sergiusens | cachio: try again, but "snap refresh snapcraft --edge" first. | 14:29 |
| mvo | xnox: http://paste.ubuntu.com/p/JnmTrjpWsP/ <- fwiw - my reproducer | 14:30 |
| sergiusens | that should come out as soon as this ends https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43/7024 | 14:30 |
| mvo | xnox: but *maybe* it runs the generator just does not pick it up | 14:30 |
| sergiusens | for which I was hoping more interaction with, but oh well. | 14:30 |
| mvo | xnox: anyway, trying to reboot now | 14:30 |
| * zyga had lunch and needs a small break | 14:34 | |
| mvo | xnox: ohhh, it looks like the reboot helped, let me try this again on a clean system (cc zyga) | 14:36 |
| zyga | mvo: hold on, I rebooted _doen_ times | 14:36 |
| zyga | mvo: what did you get? | 14:36 |
| mvo | zyga: oh | 14:36 |
| zyga | *dozen* | 14:36 |
| zyga | mvo: did you get PATH changed? | 14:37 |
| xnox | mvo, i think daemon-reexec may be sufficient, deamon-reload would not be. | 14:37 |
| === chihchun_afk is now known as chihchun | ||
| xnox | mvo, note that system-environment-generators are not available in xenial | 14:37 |
| xnox | mvo, i need this in bionic and up, .deb package... | 14:38 |
| zyga | http://paste.ubuntu.com/p/DGKWqtQvZW/ | 14:38 |
| xnox | mvo, such that on classic systems things are right. | 14:38 |
| zyga | that's what I ran | 14:38 |
| xnox | and on core18 | 14:38 |
| mvo | xnox: yeah, I'm testing this on bionic | 14:38 |
| mvo | zyga: yes http://paste.ubuntu.com/p/Sr2BMvh8fq/ | 14:38 |
| mborzecki | 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 |
| mvo | zyga: I'm trying inside spread now | 14:38 |
| xnox | mvo, zyga $ systemclt daemon-reexec | 14:39 |
| zyga | mvo: can you add /foo or something like that and check if that is pickedu p | 14:39 |
| mvo | zyga: I messed around quite a bit with my system | 14:39 |
| xnox | not just daemon-reload.... | 14:39 |
| zyga | k | 14:39 |
| mvo | xnox: cool, will try that | 14:39 |
| zyga | I'll check | 14:39 |
| zyga | mborzecki: ack | 14:39 |
| mvo | zyga: yeah, its strange | 14:39 |
| mvo | 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 |
| mvo | xnox: but yeah, running inside spread now, hopefully that was it :) | 14:42 |
| cachio | sergiusens, https://paste.ubuntu.com/p/sqb3YRpZSH/ | 14:44 |
| cachio | sergiusens, am I doing somthing wrong? | 14:45 |
| sergiusens | cachio: is the store down? that is basically "snap install core" failing on lxd | 14:45 |
| xnox | mvo, yeah that's lies. | 14:45 |
| mvo | xnox: :( thanks for confirming | 14:46 |
| xnox | 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 |
| xnox | is closer to truth | 14:46 |
| zyga | mvo: because of the fact that the test cleans up after itself my rebooting was not a factor | 14:47 |
| cachio | sergiusens, it is not | 14:47 |
| mvo | zyga: ohhhhh | 14:47 |
| mvo | zyga: ok | 14:47 |
| cachio | I though it was a problem on my network config | 14:47 |
| mvo | zyga: I updated the spread test | 14:47 |
| sergiusens | cachio: try installing core on a "lxc launch ubuntu:xenial" lxd instance | 14:47 |
| sergiusens | it might be your network, did you "sudo lxd init"? | 14:48 |
| xnox | mvo, zyga - basically we need to affect the internal structure of manager object, which does load /etc/systemd/system.conf and stuff from the generators, but from then on it keeps on serializing state and keeping it persistent even across re-execs. Thus to be sure, we need a reboot, such that manager object loads things correctly upon initial exec. | 14:48 |
| xnox | i mean, i can fix manager.c to be better, but that will not help with upgrades =) and by the time we rebooted once we should be tip top =) | 14:49 |
| cachio | trying | 14:50 |
| cachio | sergiusens, let me try it | 14:50 |
| mvo | xnox: does https://github.com/mvo5/systemd/commit/9040e581561d920d3ba4ee0e01661392985c4bf6 look sensible? | 14:54 |
| mvo | xnox: just so that the next guy does not have this misleading experience | 14:54 |
| === chihchun is now known as chihchun_afk | ||
| mvo | xnox: actually that did not work in my clean test env - trying the full reboot now | 14:56 |
| xnox | mvo, i think they will want an issue that adding system generator, things do not change, after daemon-reload/rexec. | 14:57 |
| xnox | mvo, reading the code i see that it does re-run generators; but then does deserialize; thus wiping the results of generators. | 14:58 |
| xnox | mvo, imho it should run generators; deserialize; re-run generators again | 14:58 |
| mvo | xnox: +1 for that | 14:58 |
| mvo | xnox: I can file a bug, its easy enough to reproduce | 14:59 |
| xnox | mvo, yeah, and look at manager_reload function in manager.c | 14:59 |
| mvo | xnox: in a meeting now | 15:00 |
| xnox | and point out that probably manager_deserialize wipes out the result of manager_run_environment_generators earlier | 15:00 |
| xnox | ack | 15:00 |
| mvo | xnox: thanks, will do | 15:00 |
| mvo | xnox: (in a meeting now) | 15:10 |
| eraserpencil | Hi guys, I'm following the official docs and guide https://blog.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft, but I cant seem to get it to work. | 15:15 |
| eraserpencil | i'm having trouble creating the docker instance | 15:15 |
| cachio | sergiusens, I had to reinstall lxd | 15:17 |
| cachio | sergiusens, it worked las executino | 15:17 |
| cachio | so, do I need to do something else? | 15:18 |
| sergiusens | cachio: on edge? ok that should be released tomorrow | 15:18 |
| cachio | sergiusens, yes, https://paste.ubuntu.com/p/H8ghgN6Pmw/ | 15:18 |
| cachio | this is the log | 15:18 |
| cachio | jdstrand, could you please take a look to the error in #5722 | 15:22 |
| sergiusens | cachio: 👍 | 15:22 |
| cachio | sergiusens, nice | 15:22 |
| jdstrand | cachio: ok | 15:23 |
| cachio | jdstrand, tx | 15:26 |
| mvo | Chipaca: review for 5731 would be great, should be trivial | 15:27 |
| cachio | mvo, checked with snapcraft | 15:28 |
| cachio | so I'll make the promotion if its ok for you | 15:28 |
| cachio | I need to check with the store guys for sure | 15:28 |
| mvo | cachio: yay | 15:28 |
| Chipaca | mvo: hmm. That's a query old gnome-software would do IIRC | 15:28 |
| mvo | Chipaca: do we support that query? | 15:29 |
| mvo | Chipaca: I looked at the source and could not see we handle unknown | 15:29 |
| Chipaca | mvo: we should not fail on it | 15:29 |
| mvo | Chipaca: or am I not looking hard enough | 15:29 |
| Chipaca | I think all the test is checking is that we don't fall over | 15:29 |
| Chipaca | source is supposed to be A or B, but if it's C, don't panic | 15:30 |
| Chipaca | something like that | 15:30 |
| mvo | Chipaca: well, I think the test is wrong in any case, if you run it in isolation it fails | 15:31 |
| Chipaca | mvo: I'll take a look later, if that's ok | 15:31 |
| mvo | Chipaca: totally | 15:31 |
| Chipaca | mvo: where does the test come from? i don't have it on master | 15:31 |
| mvo | Chipaca: wuut? not in master. its from 2016 | 15:31 |
| Chipaca | grep -r TestSnapsInfoUnknownSource -> nothing | 15:32 |
| Chipaca | on master here | 15:32 |
| mvo | git grep TestSnapsInfoUnknownSource | 15:32 |
| mvo | daemon/api_test.go:func (s *apiSuite) TestSnapsInfoUnknownSource( | 15:32 |
| Chipaca | I get nothing for the same query :-( | 15:33 |
| Chipaca | what's going on | 15:33 |
| Chipaca | mvo: where is it in this: https://github.com/snapcore/snapd/blob/master/daemon/api_test.go | 15:34 |
| zyga | mvo: so what's the bottom line, daemon reexec or bug in manager? | 15:34 |
| Chipaca | Author: Michael Vogt <mvo@ubuntu.com> | 15:34 |
| Chipaca | Date: Tue Aug 28 12:31:46 2018 +0200 | 15:34 |
| Chipaca | daemon: remove TestSnapsInfoUnknownSource | 15:34 |
| Chipaca | 15:34 | |
| Chipaca | mvo: you removed that one yesterday | 15:35 |
| Chipaca | mvo: in 22cbc462724b9ee7ef42fe0b768981773e6b95bb | 15:35 |
| mvo | Chipaca: uhhh, ok | 15:35 |
| * Chipaca hugs mvo | 15:35 | |
| mvo | Chipaca: sounds like the pr needs to change then | 15:35 |
| mvo | Chipaca: and I need to re-add it so that we can inspect it | 15:36 |
| Chipaca | mvo: leave it as is for now | 15:36 |
| Chipaca | mvo: I'll think about it and we can talk tomorrow | 15:36 |
| mvo | Chipaca: +1 | 15:36 |
| Chipaca | mvo: it worries me that you're forgetting what you did yesterday :-/ you ok? | 15:36 |
| mvo | Chipaca: i am - but maybe a bit too spread out recently :( | 15:38 |
| Chipaca | mvo: take care | 15:38 |
| * Chipaca afk for a bit for same | 15:39 | |
| * mvo hugs Chipaca | 15:39 | |
| * Chipaca hugs back | 15:39 | |
| pedronis | Chipaca: what happened I think is that https://github.com/snapcore/snapd/pull/5732 was merged that included the removal PR | 16:12 |
| cachio | mvo, 2.35 is stable | 16:17 |
| mvo | cachio: thank you! | 16:19 |
| cachio | mvo, yaw | 16:19 |
| * zyga ->walk | 16:26 | |
| === pstolowski is now known as pstolowski|afk | ||
| Chipaca | pedronis: what surprised me was that the new pr didn't conflcit | 17:16 |
| pedronis | Chipaca: it was older than one that merged | 17:20 |
| pedronis | *than the | 17:20 |
| pedronis | Chipaca: out-of-order merging | 17:21 |
| Chipaca | pedronis: All I hear is 'github r dumb' | 17:21 |
| pedronis | Chipaca: github doesn't care afaik, if you create a chain of 10 PR and merge the last one, you get everything in | 17:21 |
| pedronis | nothing stopping you | 17:21 |
| Chipaca | pedronis: right, but at that point why doesn't it mark the merged ones somehow | 17:22 |
| pedronis | as implicitly merged? | 17:22 |
| pedronis | it doesn't know, it tracks the to be merged branch, not the target | 17:23 |
| Chipaca | pedronis: well it does something to detect conflicts | 17:23 |
| Chipaca | pedronis: i'm sure the same something can detect nops | 17:23 |
| pedronis | probably | 17:24 |
| Chipaca | pedronis: OTOH, ¯\_(ツ)_/¯ | 17:24 |
| pedronis | it doesn't seem they care supporting chain of PRs | 17:24 |
| pedronis | it's not a thing it seems for their pov | 17:24 |
| ogra | zyga, what ever happened to the non-apparmor side of https://forum.snapcraft.io/t/apparmor-profile-caching/1268 ? did you ever fix the updating of the rootfs mount time ? | 17:48 |
| zyga | ogra: checking | 17:56 |
| zyga | ogra: ah that | 17:57 |
| zyga | non apparmor side is not affected | 17:57 |
| zyga | it was really a combination of apparmor caching, devices without battery-powered RTC _and_ the bug in the time restore from mount time | 17:57 |
| zyga | apparmor caching was reliant upon mtime | 17:57 |
| zyga | with the fix to the last part of the chain the bug is gone | 17:58 |
| ogra | zyga, well, the not-updating of the last mount time causes other issues for customer snaps | 17:59 |
| zyga | and that was fixed | 18:00 |
| ogra | we have customers with x509 certs in use that fail when the tie isnt correct | 18:00 |
| ogra | *time | 18:00 |
| zyga | AFAIK | 18:00 |
| ogra | (using them inside their app snaps) | 18:00 |
| ogra | do you know who worked on it so i can point to a PR in a bug ? | 18:01 |
| zyga | let me think | 18:01 |
| zyga | checking | 18:02 |
| ogra | (this can also wait til tomorrow ... no hurry ... i was just pinged about it ...) | 18:02 |
| zyga | sorry | 18:02 |
| zyga | I'm wrong | 18:03 |
| zyga | I fixed one aspect of apparmor usage that made us immune to time skew | 18:03 |
| zyga | but I believe someone else (not sure who) worked on the root bug | 18:03 |
| ogra | yeh,, that one i know | 18:03 |
| zyga | I will show you what I did | 18:03 |
| ogra | i had hoped Chipaca has probably looked into the shutdown issue to fix the root cause | 18:03 |
| zyga | https://github.com/snapcore/snapd/commit/32a63a0326f365d0b008893c76a3371a740a79cf#diff-57dc34ab6f4bf9730b356d0439daa0fd | 18:03 |
| zyga | and woot for the commit message | 18:04 |
| Chipaca | ogra: ? | 18:04 |
| ogra | zyga, right, that doesnt really help with the clock :) | 18:04 |
| ogra | Chipaca, fixrtc reads the last mount time stamp from dumpe2fs on systems without rtc ... due to the fact that snapd-shutdown-helper never really unmounts, that timestamp permananetly stays at image creation time | 18:05 |
| zyga | http://commit.style/ | 18:05 |
| Chipaca | ogra: why does snapd-shutdown-helper never really unmount? | 18:05 |
| zyga | ogra: AFAIK it was slightly different | 18:05 |
| zyga | ogra: kernel chooses not to update that timestamp if the filesystem is remounted ro before unmounting | 18:06 |
| ogra | Chipaca, i think thats actually an ext4 bug that zyga discovered | 18:06 |
| zyga | and that's what happens | 18:06 |
| ogra | right | 18:06 |
| ogra | that | 18:06 |
| Chipaca | ogra: so, no, i haven't fixed it -- first i'm hearing of it :-) | 18:06 |
| ogra | heh, yeah, obviously | 18:06 |
| Chipaca | in my defence i've been on holidays for a week | 18:06 |
| ogra | lets talk tomorrow :) | 18:07 |
| Chipaca | … I could easily go away for another week though | 18:07 |
| Chipaca | this 'working' thing sucks | 18:07 |
| ogra | its late and i dont want to keep anyone busy after hours | 18:07 |
| Chipaca | :-) | 18:07 |
| ogra | :) | 18:07 |
| Chipaca | yeah, i've got to walk the dog, and see about dinner | 18:07 |
| ogra | enjoy ... i'll ping tomorrow | 18:07 |
| Chipaca | k | 18:07 |
| jdstrand | kjackal_bot: fyi, https://github.com/snapcore/snapd/pull/5739 | 19:39 |
| jdstrand | kjackal_bot: fyi, having trouble getting to the docker-support side, so I just sent up the classic change | 19:42 |
| MattJ | Howdy. I searched the docs and the forum, but couldn't find an answer... is there a way for a snap to access /etc/ssl? It seems like it would be a common requirement, but I don't know how people handle it | 20:38 |
| Doctor_Nick | MattJ: Sounds like you'd need a plug to access the root file system, or just use classic containment | 21:12 |
| Doctor_Nick | also, if someone could help me out with this issue here, I would be greatly appreciative: https://forum.snapcraft.io/t/getting-a-part-build-artifact-into-another-parts-build-before-pull/7082 | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!