| mup | PR snapcraft#1915 closed: snap: patch ctypes for the snap <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1915> | 01:43 |
|---|---|---|
| thomi | niemeyer: Oh! I didn't realise I had edit rights to that post myself, or I would have just edited it directly, sorry :D | 02:17 |
| niemeyer | thomi: All good! I was still tuning it nevertheless, but yeah, if you want to tweak in the future feel free | 02:18 |
| niemeyer | and the magic happens ... https://snapdocs.labix.org/getting-started/3876 | 02:19 |
| thomi | nice | 02:19 |
| mup | PR snapcraft#1912 closed: lxd: unset SNAP to work-around LXD deb thinking it's a snap <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1912> | 03:20 |
| niemeyer | Forum going down for maintenance.. assume impact position please. | 03:47 |
| niemeyer | Forum is back up | 03:51 |
| mborzecki | morning | 06:11 |
| zyga | good morning | 06:32 |
| mborzecki | zyga: mvo_: hey | 06:34 |
| mvo_ | hey mborzecki - good morning | 06:36 |
| zyga | hey guys | 06:52 |
| mvo_ | hey zyga | 06:58 |
| zyga | hey :-) | 06:59 |
| mup | PR snapd#4611 closed: overlord/configstate/config: make [GS]etSnapConfig use *RawMessage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4611> | 07:00 |
| * zyga iterates on the feedback from jamie | 07:03 | |
| zyga | jdstrand thank you :) | 07:03 |
| zyga | oh, I have a conflict to resolve first | 07:03 |
| mup | PR snapd#4604 closed: cmd/snap-confine: create lib/{gl,gl32,vulkan} under /var/lib/snapd and chown as root:root <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4604> | 07:38 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#4612 opened: snap: exclude `gettimeofday` from `snap run --strace` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4612> | 08:01 |
| kalikiana | sliff | 08:01 |
| pstolowski | good morning! | 08:13 |
| zyga | hey pawel | 08:16 |
| mvo_ | hey pstolowski ! | 08:17 |
| zyga | mvo_ 4590 is now ready, I pushed some WIP patches by accident but they are gone now | 08:18 |
| zyga | I'll add a spread test before jumping into sun profiles more | 08:19 |
| mvo_ | zyga: ta | 08:19 |
| kalikiana | o/ pstolowski | 08:20 |
| * kalikiana coffee | 08:21 | |
| zyga | jamesh hey | 08:21 |
| jamesh | zyga: hi | 08:21 |
| zyga | I wanted to catch up with you | 08:21 |
| mborzecki | pstolowski: morning | 08:21 |
| zyga | how is that branch, I saw jamie gave you a review, are you just waiting on a re-review from him? | 08:22 |
| zyga | I also wanted to give you an update on some of the work I'm doing that intersects (though I don't anticipate any problems) | 08:22 |
| zyga | we will soon have per-snap profiles for snap-update-ns | 08:23 |
| ackk | mvo_, hi, was the updated base-18 with distro-data built? | 08:23 |
| zyga | (apparmor profiles that is) | 08:23 |
| jamesh | zyga: I still need to get the mountinfo stuff working: I had other things on my plate on Friday, and was flying home on Monday | 08:23 |
| mvo_ | ackk: it was, iirc it was sitting in the review queue, we need to poke jdstrand about accepting the updated base-18 snap | 08:23 |
| ackk | mvo_, oh, I see | 08:24 |
| zyga | jamesh did my suggestion help you in any way? | 08:24 |
| jamesh | zyga: I still need to think it over a bit more. I wasn't even looking at the device numbers before. | 08:26 |
| zyga | okay | 08:26 |
| zyga | my changes for per snap s-u-n profiles will touch snap-confine a little and mostly the backend code | 08:27 |
| zyga | there will be some new logic before running s-u-n from C | 08:27 |
| zyga | the idea behind sun profiles is that they can be tailored to the given snap and describe the operations we anticipate to perform | 08:29 |
| zyga | so that s-u-n doesn't have to carry very broad write and mount permissions | 08:29 |
| zyga | jamesh when do you think your branch will be ready for re-review? | 08:30 |
| jamesh | zyga: well, I need to be able to add the check jdstrand requested, which so far I haven't been able to implement | 08:30 |
| zyga | jamesh ok, I'll look at that part, maybe I can help somehow | 08:31 |
| zyga | jamesh do you mind if I push there directly? | 08:32 |
| zyga | woot, 4590 is ready for 2nd review | 08:40 |
| zyga | ~100 diff | 08:40 |
| zyga | (and most of that is in apparmor which was acked by jamie) | 08:41 |
| zyga | anyone? :) | 08:41 |
| === chihchun is now known as chihchun_afk | ||
| zyga | hey Chipaca | 08:55 |
| Chipaca | moin moin | 08:55 |
| zyga | Chipaca maybe I can grab you for a 2nd review of about 100 lines | 09:01 |
| zyga | https://github.com/snapcore/snapd/pull/4590 | 09:01 |
| mup | PR #4590: many: allow constructing layouts (phase 1) <Created by zyga> <https://github.com/snapcore/snapd/pull/4590> | 09:01 |
| mup | PR snapd#4613 opened: release: snapd 2.31 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4613> | 09:05 |
| Chipaca | zyga: missed your message before, looking now | 09:18 |
| === chihchun_afk is now known as chihchun | ||
| zyga | thank you | 09:20 |
| Chipaca | fmt's widths and precision are pretty messed up | 09:23 |
| mup | PR snapd#4614 opened: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <https://github.com/snapcore/snapd/pull/4614> | 09:23 |
| pedronis | mvo_: ^ trivial fix/tweak to snap-repair service unit | 09:23 |
| mvo_ | pedronis: looking | 09:24 |
| mvo_ | pedronis: ta | 09:25 |
| zyga | have we tested repairs for real yet? | 09:26 |
| pedronis | zyga: no, they have been tested in staging, it's been 2nd highest prioritity thing for a while though, next weeks might be the charm though | 09:29 |
| zyga | cool, it's a very important thing to see work as it can save our skin one day | 09:29 |
| pedronis | zyga: anyway that PR is the result of me trying to reload state about them | 09:31 |
| === sparkieg` is now known as sparkiegeek | ||
| pedronis | zyga: it's also been delayed by meltdown/spectre, as many other things | 09:33 |
| zyga | yeah, timing is not on our side | 09:33 |
| ikey | do you guys regret picking go yet? :) | 09:49 |
| pedronis | ikey: instead of? | 09:49 |
| ikey | i mean in general | 09:49 |
| ikey | seems to me the lower down you go with go the more ugly warts are there waiting to be found | 09:50 |
| mup | PR snapd#4614 closed: data/systemd: for debugging/testing use /etc/environment also for snap-repair runs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4614> | 09:52 |
| mup | PR snapd#4615 opened: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615> | 09:52 |
| mborzecki | ikey: how far down? | 09:52 |
| ikey | mborzecki, process level attributes and sandboxing | 09:53 |
| ikey | namespaces, etc | 09:53 |
| ikey | (also process vs thread) | 09:54 |
| ikey | sorta stuff we ran into with solbuild in solus, kinda assumed similar brick walls would be hit and worked around with snapd | 09:54 |
| mborzecki | right, that doesn't work so well (at all) in go | 09:54 |
| ikey | then again i suppose the flipside is not dealing with berkley sockets :] | 09:55 |
| pedronis | it mostly affects snap-confine though (wich now is split between C and go helpers) | 09:55 |
| ikey | ah so thats why its split, makes sense | 09:55 |
| ikey | so the design is more like "bootstrap environment and then exec" in a sense? | 09:55 |
| zyga | yes | 09:55 |
| zyga | and actually, we managed to move a lot of it to go now | 09:55 |
| ikey | neat way of doing it :] | 09:55 |
| zyga | snap-update-ns and snap-confine do stuff together | 09:56 |
| zyga | and we can move much more to go | 09:56 |
| ikey | oh nice | 09:56 |
| pedronis | otherwise we mostly hit issues with go threads and exec | 09:56 |
| zyga | there are just a handful of things that cannot be done from go | 09:56 |
| ikey | yeah go threads are.. special | 09:56 |
| zyga | (where C pre-go code doesn't count as "go" ;-) | 09:56 |
| mborzecki | there are workaround those | 09:56 |
| mborzecki | i mean, iirc libcontainer is all go right? | 09:56 |
| ikey | huh spose yea | 09:56 |
| mborzecki | probably quite a lot of (un-)lockosthread and maxprocs fun | 09:57 |
| ikey | yea | 09:57 |
| mborzecki | not that i would like to do it though :) | 09:57 |
| ikey | but ofc. :D | 09:57 |
| ikey | i think the most evil go issue i had wasn't actually go's fault, cgo/xz | 09:57 |
| pedronis | the other issue is that go moves faster than some distros (this one we haven't tackled but probably should somehow) | 09:57 |
| ikey | i suspected i had a memory leak but my peanut gallery training told me that nope, that memory will get returned, its just virtual memory | 09:58 |
| mborzecki | oh and we haven't done anything with go assembly, which is quite nice actually :) | 09:58 |
| ikey | that was until it OOM'd with 30GB used | 09:58 |
| ikey | hadn't heard about go assembly, gonna have to google it | 09:58 |
| mborzecki | ikey: try this https://talks.golang.org/2016/asm.slide | 09:59 |
| zyga | mborzecki note that even with those some things just cannot be done in go (several syscalls require you to have ever only had one thread in a process) | 09:59 |
| ikey | mborzecki, danke | 09:59 |
| mborzecki | zyga: hm i wonder if that couldn't be doen with GOMAXPROCS=1 and LockOsThread in init() | 10:00 |
| ikey | o cheeky | 10:00 |
| zyga | no | 10:00 |
| zyga | we tried | 10:00 |
| zyga | go does stuff in library initialization | 10:00 |
| ikey | go needs a -pleasebelikec flag lol | 10:00 |
| zyga | and it's too late then | 10:00 |
| zyga | hence the magic in snap-update-ns | 10:00 |
| zyga | and the split in general | 10:00 |
| ikey | so i assume you just wanna do the bare minimum in C land | 10:01 |
| ikey | i.e. what cant be done in go | 10:01 |
| ikey | er what cant be done /safely/sanely/ * | 10:01 |
| mborzecki | if not c then probably d or rust could be used as alternatives | 10:03 |
| zyga | I think we'll stick to C | 10:03 |
| mborzecki | provided you can actually build those on older systems | 10:03 |
| zyga | no need to introduce a new language for a tiny fragment | 10:03 |
| zyga | we really need C for pivot_root and some of the early namespace manipulation | 10:04 |
| mup | PR snapd#4590 closed: many: allow constructing layouts (phase 1) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4590> | 10:29 |
| mup | PR snapd#4616 opened: interfaces/apparmor: remove leaked future layout code <Created by zyga> <https://github.com/snapcore/snapd/pull/4616> | 10:31 |
| mvo_ | Chipaca: bad news, powerpc is failing since some days and it looks the change is the addition of the osutil/context.go stuff | 10:51 |
| Chipaca | mvo_: can i see? | 10:51 |
| zyga | mvo_ is that going to block the release? | 10:51 |
| zyga | and do you need my powerpc box? | 10:51 |
| mvo_ | Chipaca: https://launchpadlibrarian.net/355941418/buildlog_ubuntu-xenial-powerpc.snapd_2.31~rc2+git540.4a4ed58~ubuntu16.04.1_BUILDING.txt.gz | 10:52 |
| mvo_ | zyga: its just master afaict | 10:52 |
| Chipaca | so much "reading database" | 10:52 |
| mvo_ | Chipaca: silly dpkg | 10:52 |
| mvo_ | Chipaca: we are getting rid of this ;) | 10:52 |
| Chipaca | i thought that was apt | 10:52 |
| mvo_ | Chipaca: that part is dpkg | 10:53 |
| mvo_ | Chipaca: or, hold on | 10:53 |
| mvo_ | Chipaca: yeah, thats dpkg | 10:53 |
| Chipaca | zyga: mind if i use your powerpc box? | 10:54 |
| zyga | not at all | 10:55 |
| zyga | please coordinate with mvo, there's just 1GB ram | 10:55 |
| mvo_ | Chipaca: the backtrace is not helpful at all | 10:55 |
| Chipaca | mvo_: are you going to use zyga's powerpc? | 10:55 |
| mvo_ | Chipaca: yeah, I was about to. but if you are on it, I will leave it, its almost lunchtime anyway | 10:56 |
| Chipaca | mvo_: yeah if it's my context thing it's fair that i bash my head on it | 10:56 |
| mvo_ | Chipaca: it probably is (this is the merge when the builds start to fail). thanks for looking into it! | 10:56 |
| * Chipaca sees a 'if runtime.GOARCH == "powerpc" { throw a fit }' in his future | 10:57 | |
| Chipaca | zyga: do i have sudo on the ppc box? | 10:59 |
| zyga | checking | 11:00 |
| zyga | yes | 11:01 |
| zyga | you should | 11:01 |
| Chipaca | zyga: what i might not have is a password :-) | 11:01 |
| zyga | aha :D | 11:01 |
| mborzecki | your voice is .. | 11:02 |
| Chipaca | .. not what it was | 11:02 |
| mborzecki | ha ha :) | 11:02 |
| Chipaca | ok, I've seen this error once before and thought it was weird gamma ray thing :-) but this being the second time, I need to bring it up | 11:07 |
| Chipaca | + mkdir -p /home/test/snap/test-snapd-tools/6/ | 11:07 |
| Chipaca | + touch '/home/*/snap/test-snapd-tools/6/mock-data' | 11:07 |
| Chipaca | touch: cannot touch '/home/*/snap/test-snapd-tools/6/mock-data': No such file or directory | 11:07 |
| Chipaca | what the *what* | 11:07 |
| ikey | did you quote the wildcard? | 11:08 |
| * Chipaca looks at the test | 11:08 | |
| Chipaca | ikey: that's a good question :-) | 11:08 |
| Chipaca | thank you | 11:08 |
| ikey | np | 11:08 |
| Chipaca | ikey: although if it was that, it wouldn't fail just sometimes | 11:08 |
| Chipaca | still, looking | 11:09 |
| Chipaca | ikey: the script actually has | 11:09 |
| Chipaca | mkdir -p /home/*/snap/test-snapd-tools/$rev/ | 11:10 |
| Chipaca | touch /home/*/snap/test-snapd-tools/$rev/mock-data | 11:10 |
| ikey | o | 11:10 |
| Chipaca | it expands the first one, but fails to expand the second one | 11:10 |
| ikey | but what. | 11:11 |
| * ikey scratches head | 11:11 | |
| zyga | Chipaca concurrent magic? | 11:11 |
| Chipaca | in spread? | 11:11 |
| zyga | suggestion: get rid of the * and use a one-time expansion to know what the thing is called | 11:11 |
| Chipaca | zyga: in the log above, it logs it expanded | 11:12 |
| zyga | hmm hmm | 11:12 |
| pedronis | Chipaca: you have '' there | 11:12 |
| pedronis | so no * expansion | 11:12 |
| pedronis | afaict | 11:12 |
| ikey | looks like the set +x escape put the ' in | 11:12 |
| pedronis | Chipaca: it might also be, the file doesn't exist, so it doesn't expand | 11:13 |
| pedronis | there's no match for that | 11:13 |
| Chipaca | hmmmm | 11:14 |
| pedronis | but then why it works for the dir | 11:14 |
| Chipaca | gasp | 11:14 |
| Chipaca | bah | 11:15 |
| Chipaca | I'm going to push a PR that changes the test, dunno why we're using a * but it's hard to think about | 11:15 |
| Chipaca | meanwhile restarting this individual run should be good enough for now | 11:15 |
| Chipaca | thanks | 11:15 |
| pstolowski | pedronis, hey, struggling a bit with autoconnect test based on content interface, policy check prevents autoconnect, what to do in my mocked snaps to make it happy? | 11:24 |
| pedronis | pstolowski: where are you writing the test? | 11:24 |
| pstolowski | pedronis, in overlord/managers_test.go | 11:24 |
| pedronis | pstolowski: you need to setup snap declarations from the same publisher, we should have some tests like that there | 11:26 |
| pstolowski | pedronis, thanks, looking | 11:30 |
| pedronis | pstolowski: it's mostly tedious and long | 11:31 |
| pedronis | there are some helpers though | 11:31 |
| pedronis | I think | 11:31 |
| cachio_ | mvo_, hey, unit tests failing in the PR which is removing gettimeofday | 11:34 |
| zyga | - Download snap "test-snapd-control-consumer" (2) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/a8xXlpZKNsesIzT1wxZ4kP0DaCzeDUtj_2.snap: dial tcp 91.189.92.19:443: i/o timeout) | 11:35 |
| * zyga restarts | 11:36 | |
| Chipaca | mvo_: there are many changes in debian/ between what I get via apt, and git | 11:39 |
| Chipaca | mvo_: to the point where dpkg-buildpackage from master doesn't work | 11:39 |
| mvo_ | Chipaca: what version do you get via apt? | 11:41 |
| mvo_ | Chipaca: try "apt build-dep ./" if build-deps are missing | 11:41 |
| Chipaca | mvo_: snapd-2.29.4.2 | 11:41 |
| mvo_ | Chipaca: or are vendor/ dirs missing? | 11:41 |
| Chipaca | mvo_: I did, nothing new brought in | 11:41 |
| mvo_ | Chipaca: what is the failure? | 11:41 |
| Chipaca | mvo_: oh i thought dpkg-buildpackage does that? | 11:41 |
| * Chipaca does that | 11:41 | |
| Chipaca | govendor does _not_ like ppc | 11:43 |
| Chipaca | powerpc* | 11:43 |
| Chipaca | I can't even install govendor :-( | 11:43 |
| * Chipaca copies his vendor tree from a reasonable architecture | 11:44 | |
| pstolowski | pedronis, ok, i see store signing stack is already created in managers_test; it will work if I install snaps via InstallPath and with devmode provide correct SideInfo? | 11:45 |
| * zyga found a CD with the doors in one of the boxes yesterday | 11:47 | |
| * zyga never listened to that | 11:47 | |
| Chipaca | zyga: the doors! (beep tweedle bip bip)* | 11:49 |
| zyga | it sounds nice | 11:49 |
| Chipaca | zyga: talk to me when your beep-tweedle-bip-bip counter reaches 10k | 11:50 |
| Chipaca | mvo_: it was the vendor tree missing that was thwarting me, silly me, and thank you | 11:51 |
| mvo_ | Chipaca: happy that it works now | 11:55 |
| mup | PR snapd#4617 opened: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617> | 11:56 |
| Chipaca | mvo_: hmm. I think you dropped these from around a word there: ❝❞ | 11:59 |
| Chipaca | but hey the package is building :) so that's something | 12:00 |
| zyga | hmm hmm lunch time | 12:01 |
| mup | PR snapcraft#1916 opened: lxd: initialize remote lazily <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1916> | 12:03 |
| Chipaca | hmm, gccgo doesn't seem to find things from vendor/ | 12:05 |
| ackk | hi, I have a snapcraft question: I'm including a python lib from a deb via stage-packages, but the resulting library in the snap seems laid out differently. does snapcraft do anything special? | 12:05 |
| ackk | kalikiana, ^ perhaps you can help? | 12:09 |
| pedronis | pstolowski: yes, it should work with SideInfo | 12:11 |
| pstolowski | pedronis, thanks, got it working! | 12:14 |
| mborzecki | pstolowski: should i restart the travis job in 4584 or will you be pushing more patches to that branch? | 12:19 |
| ikey | sadface. looks like snap mounts are regressing my boot | 12:20 |
| ikey | blocks early boot: https://ibin.co/3qlqeUao9o5w.png | 12:20 |
| pstolowski | mborzecki, yeah, pls restart, thanks, no more commits | 12:20 |
| kalikiana | ackk: can you be more specifc? in what sense are the files laid out differently? | 12:23 |
| mborzecki | anyone feels like looking at #4615? | 12:23 |
| mup | PR #4615: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4615> | 12:23 |
| ackk | kalikiana, I think I found the issue, locally I have a deb which is more recent than the one in the repo, but snapcraft pulls deb from the archive directly, so it's using a different version fro the one installed locally | 12:23 |
| ackk | kalikiana, if I copy my updated deb in .cache/snapcraft/...... will it pick the latest? | 12:24 |
| ackk | kalikiana, or does it only use what's in the archive | 12:24 |
| zyga | ikey idea: use auto mounts | 12:24 |
| ikey | ? | 12:24 |
| zyga | ikey they will start only when accessed | 12:25 |
| ikey | these are the mount units written by snapd | 12:25 |
| ikey | not me | 12:25 |
| zyga | 3 min | 12:25 |
| zyga | yes | 12:25 |
| * ikey blinks | 12:25 | |
| zyga | it would be a patch | 12:25 |
| ikey | oh you mean patch it to mungle it | 12:25 |
| ikey | hm | 12:25 |
| ikey | could do yeah | 12:25 |
| zyga | *chew chew* | 12:25 |
| zyga | sorry, I stuffed a sandwitch into my mouth to type | 12:25 |
| zyga | so | 12:25 |
| zyga | systemd can do that mount lazily by installing an automount unit | 12:26 |
| zyga | I believe it's a tiny one word patch in each .mount unit | 12:26 |
| zyga | do an experiment | 12:26 |
| zyga | let me tell you ... | 12:26 |
| zyga | add x.systemd-automount to mount options | 12:27 |
| zyga | just edit those mount units and change that | 12:27 |
| zyga | and reboot | 12:27 |
| zyga | aww, systemd needs foo.automount as unit name | 12:28 |
| zyga | but maybe the option will be sufficient | 12:28 |
| zyga | (option in a mount unit) | 12:28 |
| zyga | ah wait | 12:28 |
| zyga | no | 12:28 |
| zyga | so reading systemd.automount | 12:28 |
| zyga | keep the mount units | 12:28 |
| ikey | right | 12:29 |
| zyga | just add a .automount unit next to vanilla mount units | 12:29 |
| zyga | so if you do that experiment and it works we can consider that as a feature to add | 12:29 |
| zyga | it would be nice as it would help boot time and also improve memory use | 12:29 |
| ikey | yeah | 12:29 |
| ikey | not having every possible snap mounted unless it needs to be | 12:29 |
| zyga | yep | 12:29 |
| zyga | I believe we could also do automatic deactivation so they would go away over time, when unused | 12:30 |
| zyga | maybe there are dragons (because it's tricky what we do) but worth a check | 12:30 |
| ikey | aye | 12:30 |
| mborzecki | zyga: TimeoutIdleSec= ? | 12:33 |
| zyga | yeah | 12:33 |
| mborzecki | right, doesn't look like too much work | 12:33 |
| kalikiana | ackk: Hmmm why do you have a different version? Do you want to use the local version? You could specify the .deb file in that case | 12:35 |
| ackk | kalikiana, yes I wanted to user the newer version I have installed. So, I can specify the path to a deb file instead of just the name in stage-packages? | 12:35 |
| kalikiana | ackk: You can use a part with plugin: dump and source: foobar.deb | 12:37 |
| kalikiana | ackk: The files will be extracted relative to the part ie. ./usr/bin/foobar | 12:40 |
| ackk | kalikiana, does this work for libs too? | 12:41 |
| kalikiana | ackk: Sure | 12:42 |
| ackk | kalikiana, thanks, TIL | 12:42 |
| Chipaca | ikey: zyga: in my experience automount is a pain in the pudenda | 12:43 |
| Chipaca | ikey: zyga: maybe you can get the same effect by giving snap .mounts a reasonable After=? | 12:43 |
| ikey | possible | 12:44 |
| Chipaca | mvo_: so, I have a super easy way for tests to pass on powerpc | 12:44 |
| Chipaca | mvo_: (beyond "skip this test" :-) | 12:44 |
| Chipaca | but … hmm | 12:45 |
| zyga | Chipaca after=5 minutes ;-) | 12:45 |
| Chipaca | mvo_: i suspect gccgo has not been well tested [in general but especially] on uniprocessors | 12:46 |
| mup | PR snapd#4616 closed: interfaces/apparmor: remove leaked future layout code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4616> | 12:47 |
| mup | PR snapd#4618 opened: tests: new snaps to test installs nightly <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4618> | 12:50 |
| zyga | mvo_ trivial feedback on https://github.com/snapcore/snapd/pull/4617 | 12:54 |
| mup | PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617> | 12:54 |
| mup | PR snapd#4576 closed: cmd/snap-update-ns: large refactor / update of unit tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4576> | 12:55 |
| mvo_ | zyga: ta | 12:59 |
| zyga | for wht? | 12:59 |
| zyga | :) | 12:59 |
| zyga | oh, meeting | 12:59 |
| mvo_ | Chipaca: I look forward to the fix | 12:59 |
| Chipaca | mvo_: ah, oh, hm | 12:59 |
| mvo_ | zyga: the feedback in my PR | 12:59 |
| Chipaca | mvo_: the fix is "run go test with GOMAXPROCS=<something bigger than 1>" | 12:59 |
| mvo_ | heh | 13:00 |
| Chipaca | mvo_: which I suspect means actual gccgo programs don't work well on uniprocessors | 13:00 |
| zyga | Chipaca: buy bigger machine | 13:00 |
| Chipaca | mvo_: I need to test this obvs | 13:00 |
| mvo_ | ok | 13:00 |
| * kalikiana lunch | 13:48 | |
| Chipaca | zyga: "on any supported Fedora system you be good to," -> "on any supported Fedora system you should be good to go," | 13:48 |
| Chipaca | zyga: imho | 13:48 |
| zyga | ah | 13:48 |
| zyga | should | 13:48 |
| zyga | I should add should | 13:48 |
| zyga | Thanks for spotting | 13:50 |
| zyga | I could use some coffee | 13:55 |
| * genii slides zyga a large shiny Ubuntu mug full of strongly brewed Somalian Arabica, at just the right temperature for sipping | 13:56 | |
| zyga | man | 13:56 |
| zyga | I wish there was "snap install coffee" | 13:56 |
| genii | :D | 13:56 |
| zyga | coffee sounds like a nice name for software | 13:57 |
| zyga | what would it do though? | 13:57 |
| zyga | grind? | 13:57 |
| genii | Keep you awake, ideally | 13:58 |
| Chipaca | zyga: you are a step away from reinventing java | 13:59 |
| zyga | oooh | 13:59 |
| Chipaca | zyga: are you sure you want to continue [n/N/WTFNO] | 13:59 |
| zyga | it could do coffee in containers known as *capsules* | 13:59 |
| * zyga stands up and walks to the coffee machine | 13:59 | |
| * pstolowski lunch | 14:01 | |
| jdstrand | mvo_: re base-18> as of last night, it wasn't in the review queue. I didn't see it all last week. I feel like I *did* see it at some point and accepted it. yes, r5 was accepted. r6 has some extra 'unusual' files in it. if you request a manual review, I'll accept it | 14:11 |
| zyga | hey jamie! thank you for the feedback there | 14:12 |
| Saviq | niemeyer: hey, we've had a handful of jobs fail today with spread tasks getting stuck (?) on linode https://travis-ci.org/MirServer/mir/jobs/337880107 | 14:12 |
| jdstrand | you're welcome. sorry if I was a bit confused :) | 14:12 |
| Saviq | niemeyer: shall we add -v on top of the -v to see what's what if this hits us again? | 14:13 |
| zyga | I'll have more soon, I'm working on tests for existing, non-hardened implementation | 14:13 |
| Chipaca | niemeyer: @attache in the forum (on the planet jumper post) has the exact same cpu/gpu as i do | 14:13 |
| Chipaca | and the error is the same | 14:14 |
| mup | PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619> | 14:15 |
| jdstrand | mvo_: so, I've add sudo and the ssh binaries to the review tools, but the /var/log/journal setgid dir is weird. did you actually want to include that? | 14:15 |
| Chipaca | mvo_: why do we worry so much about powerpc if we don't have a core for it? | 14:16 |
| mvo_ | jdstrand: aha, good point, will kill it | 14:16 |
| mvo_ | jdstrand: we don't want this to prevent wear out o | 14:16 |
| mvo_ | f the mmc | 14:17 |
| mvo_ | Chipaca: don't ask | 14:17 |
| Chipaca | mvo_: OK. | 14:17 |
| mvo_ | Chipaca: well, I will answer anyway | 14:17 |
| Chipaca | mvo_: oops too late, already retracted my question | 14:17 |
| Chipaca | I can't undo the undo! the universe will fall apart! | 14:17 |
| jdstrand | mvo_: ping me when r7 is uploaded and you request a manual review and I'll push it through | 14:17 |
| mvo_ | Chipaca: we should stop supporting it, but that means a bit of paperwork, i.e. add this to the exception for our SRU policy etc. which probably needs approval and discussion. the end result is most likely that supporting is cheaper than stopping | 14:18 |
| jdstrand | *this* is the week that I will *finally* request a pull of the review tools, but ping me until that is in prod | 14:18 |
| mvo_ | jdstrand: will do, let me kill that dir, I think it sneaked in due to a systemd change | 14:18 |
| * jdstrand nods | 14:21 | |
| Chipaca | pedronis: niemeyer: is there any obvious (or non-obvious) bug in this: https://pastebin.ubuntu.com/26530120/ ? | 14:31 |
| Chipaca | pedronis: niemeyer: symptom I'm seeing is that in some environments it never prints a dot, and hangs forever | 14:32 |
| Chipaca | pedronis: niemeyer: gccgo and the playground | 14:32 |
| Chipaca | and, where do bugs on gccgo get reported :-) | 14:33 |
| mvo_ | jdstrand: there is a r7 now for base-18 | 14:34 |
| mborzecki | niemeyer: https://paste.ubuntu.com/26530133/ TLS handshake timeout, are we abusing linode too much? | 14:35 |
| Chipaca | zyga: do you have a bionic system to hand? | 14:38 |
| zyga | mborzecki, niemeyer: I updated 4610 | 14:39 |
| kalikiana | re | 14:47 |
| jdstrand | mvo_: can you request a manual review? (if I do, then I can't process it) | 14:47 |
| mvo_ | jdstrand: ups, sorry, done. thank you | 14:48 |
| jdstrand | mvo_: approved but not published to a channel | 14:49 |
| mvo_ | jdstrand: ta | 14:51 |
| mborzecki | niemeyer: edited the https://forum.snapcraft.io/t/core-configuration-options/87 and added info on refresh.timer, feel free to review and redact as needed | 14:51 |
| mvo_ | ackk: please check the latest base-18 in edge | 14:51 |
| ackk | mvo_, ah, thanks, checking now | 14:52 |
| * Chipaca bbiab | 14:52 | |
| mup | PR snapd#4619 closed: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4619> | 14:52 |
| pedronis | Chipaca: sounds like a compiler that doesn't put, let's give a chance to other goroutines checkpoints, in some cases ? | 14:59 |
| mup | PR snapd#4607 closed: wrappers: cleanup enabled service sockets <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4607> | 15:04 |
| mvo_ | cachio_: I triggered a new 2.31 core snap build, it seems the builders are quite busy right now, so hopefully in ~1h it will be there | 15:08 |
| cachio_ | mvo_, great, tx | 15:08 |
| cwayne | mvo_: do we expect it in beta today? | 15:27 |
| andyrock | mvo_ , niemeyer: hi! In bionic we are almost ready to push the changes (in udisks2 and gnome-disk-utility) to hide snap loop devices from gnome-disks | 15:40 |
| Chipaca | pedronis: yeah, going to file a bug | 15:40 |
| zyga | for context, we need a way to refresh existing .mount units to get the benefits for all the snaps people have installed | 15:41 |
| Chipaca | pedronis: as soon as i check it isn't yet fixed in a more recent build | 15:41 |
| pedronis | didn't we have already something else that required .mount updates? | 15:41 |
| Chipaca | hence me asking around for a B | 15:41 |
| andyrock | yeah thanks zyga | 15:41 |
| zyga | I was thinking we could port that code to use the ensure dir state code so that we can freely change mount units in the future | 15:42 |
| zyga | but I wasn't sure where to put the call, probably just like interface manager | 15:42 |
| zyga | (on interface startup) | 15:42 |
| zyga | er | 15:43 |
| zyga | s/interface/overlord/ | 15:43 |
| ackk | mvo_, so I got further then bafore with base-18, but maas snap now fails with django.db.utils.DataError: invalid value for parameter "TimeZone": "UTC" | 15:44 |
| mvo_ | ackk: aha, the I think this one if from the timezone database | 15:45 |
| mvo_ | ackk: if you use the beta core snap, you can probably use "snap run --strace" when starting your app to see what files it tries to access | 15:45 |
| ackk | mvo_, so the build you gave a while ago add something that's still missing in edge I guess | 15:45 |
| * cachio_ lunch | 15:46 | |
| mvo_ | cwayne: yeah, it should be in beta today | 15:46 |
| mvo_ | cwayne: builds are a bit slow though | 15:46 |
| mvo_ | cachio_: i386/amd64/ppc64el are ready | 15:47 |
| zyga | mvo_, do you think this can be a 2.32 roadmap item? | 15:51 |
| mvo_ | ackk: let me check the timezone db, is that something that the snap could ship? | 15:53 |
| mvo_ | zyga: what is "this"? | 15:53 |
| zyga | mvo_ what I described above, a way to refresh .mount units | 15:53 |
| ackk | mvo_, maybe yes | 15:53 |
| ackk | mvo_, fwiw http://paste.ubuntu.com/26530521/ is the diff between the content of the custom built you gave me and the one in edge | 15:54 |
| mvo_ | ackk: I think its the -./usr/share/zoneinfo/Etc/UTC zoneinfo stuff | 16:06 |
| mvo_ | cachio_: armhf/arm64 are ready now too | 16:08 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | pedronis: https://github.com/golang/go/issues/23721 fwiw | 16:14 |
| ackk | mvo_, yeah I think so, could that be included too? | 16:14 |
| Chipaca | mvo_: ^that's our powerpc issue :-) | 16:14 |
| Chipaca | mvo_: workaround coming in a pr rsn | 16:14 |
| niemeyer | andyrock: Thanks for that | 16:20 |
| andyrock | niemeyer the problem is that this is not going to work for existing mounted snaps | 16:20 |
| andyrock | so zyga proposed a way | 16:21 |
| andyrock | but we (the desktop team) need to know it this is going to get done before B is released | 16:21 |
| mup | PR snapd#4620 opened: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <https://github.com/snapcore/snapd/pull/4620> | 16:22 |
| mup | PR snapd#4619 opened: tests/main/user-data-handling: get rid of ordering bug <Created by chipaca> <https://github.com/snapcore/snapd/pull/4619> | 16:24 |
| niemeyer | andyrock: I'm a bit out of context about what this is fixing and what we want to achieve at the end. Is there a thread I could read? | 16:28 |
| andyrock | niemeyer: https://www.irccloud.com/irc/canonical.com/messages/zyga | 16:29 |
| andyrock | sorry | 16:29 |
| andyrock | https://github.com/snapcore/snapd/pull/4294 | 16:29 |
| mup | PR #4294: Mount with x-gdu.hide option <Created by azzar1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4294> | 16:29 |
| * zyga raises his ear | 16:30 | |
| zyga | (feel free to pull me into the conversation) | 16:30 |
| zyga | jdstrand replied | 16:31 |
| zyga | 37 seconds after you asked :) | 16:31 |
| niemeyer | andyrock: Thanks, get it now | 16:36 |
| andyrock | niemeyer so zyga proposed this: | 16:37 |
| andyrock | https://www.irccloud.com/pastebin/EwM37tE1/ | 16:37 |
| andyrock | if we know that this is going to be done before B is released we push the changes as they're upstream | 16:38 |
| zyga | andyrock why not push the changes already? | 16:39 |
| andyrock | otherwise for the moment we apply also a distro patch to work around this (in gnome-disk-utilities) | 16:39 |
| andyrock | zyga to avoid pushing twice | 16:39 |
| * zyga doesn't get it | 16:39 | |
| andyrock | first push: the generic fix (already upstream) | 16:39 |
| andyrock | second push: the ubuntu specific fix | 16:40 |
| zyga | what is the difference between them? | 16:40 |
| zyga | I assumed we would just carry the patch in the package | 16:40 |
| andyrock | if we know that this is not going to get done we push both | 16:40 |
| zyga | aha, I see | 16:40 |
| niemeyer | I don't quite see yet.. one way or the other the fix will work out | 16:41 |
| zyga | I think the answer is, it will be done, the only question is how soon | 16:41 |
| andyrock | in Ubuntu | 16:41 |
| andyrock | not in other distros | 16:41 |
| niemeyer | In one scenario it gets gradually cleaned, in other it gets cleaned at once | 16:41 |
| zyga | and the patch won't hurt, in other places everyone will benefit from new upstream udisks | 16:41 |
| niemeyer | For anyone installing 18.04, they have no previous mounts | 16:41 |
| zyga | and all new installs are not affected anymore | 16:41 |
| niemeyer | I'd actually prefer to do nothing on that basis.. at least for now.. rewriting all mount units feels uncomfortable from a sanity standpoint, if nothing else | 16:42 |
| andyrock | seb128: ^^^ | 16:42 |
| andyrock | so at this point we could just apply the workaround | 16:43 |
| jdstrand | andyrock: as an aside, thank you for your work on this. this will be a nice improvement | 16:43 |
| seb128 | andyrock, in a call atm but I read later, if it's not perfect / have some mounts still showing that clean over time that's not the end of the world | 16:43 |
| * jdstrand only just now saw that PR | 16:44 | |
| andyrock | seb128: kk. So what I suggest is the following: | 16:44 |
| andyrock | both in bionic, artful and xenial we distro patch to use the workaround (just hide if the loop backing file has the ".snap" suffix) | 16:45 |
| andyrock | the workaround is just in gnome-disk-utilities | 16:45 |
| zyga | andyrock is that released? I still see them | 16:46 |
| andyrock | upstream will benefits from the upstreamed patches | 16:46 |
| seb128 | zyga, not yet, should be uploaded to bionic tomorrow | 16:46 |
| zyga | ah | 16:46 |
| niemeyer | andyrock: Sounds nice | 16:47 |
| andyrock | seb128: If you arealdy started the uploading process we can keep it | 16:48 |
| andyrock | it can be used somewhere else too | 16:49 |
| seb128 | andyrock, not, I'm in a call, I'm going to do that tomorrow morning | 16:49 |
| seb128 | but yours patches are still good/right | 16:49 |
| Chipaca | zyga: finished with the powerpc box | 16:49 |
| seb128 | so why not including them? | 16:49 |
| andyrock | kk | 16:49 |
| andyrock | but I'll proposed another workaround too | 16:49 |
| andyrock | but we can discuss about this in #ubuntu-desktop after the call | 16:50 |
| seb128 | right, let's discuss that tomorrow morning | 16:51 |
| seb128 | that call is still ongoing for a while and then I need to go | 16:51 |
| zyga | Chipaca glad I could help, sad I could help | 16:52 |
| andyrock | kk | 16:57 |
| philroche | Is there a way to enable site-packages in the virtualenv in a snap built with the python plugin? I have a requirement python-apt that cannot be installed using pip. I can't see anything in the docs or examples on how to do this | 17:04 |
| * kalikiana wrapping up for today | 17:09 | |
| kalikiana | philroche: not quite an answer to your question, but Snapcraft uses a tarball in requirements.txt to achieve the same thing. See https://github.com/snapcore/snapcraft/blob/master/requirements.txt#L10 | 17:10 |
| philroche | kalikiana: Interesting. Thank you | 17:11 |
| lotuspsychje | good eveing to all | 17:44 |
| jdstrand | mvo_: I see new revisions for base-18. can you request manual review for the ones you are interested in? | 17:44 |
| lotuspsychje | someone might know why skype doesnt come anywhere latest here? http://feeds.feedburner.com/uAppExplorerNewSnaps | 17:45 |
| kyrofa | lotuspsychje, uAppExplorer is a third-party site, we have no control over it | 17:47 |
| lotuspsychje | kyrofa: ok, im trying to find an rss the way sudo snap find lists the latest ones, got any idea? | 17:48 |
| Chipaca | mvo_: question about #4617 | 17:55 |
| mup | PR #4617: many: implement "refresh-mode: survive" for services <Created by mvo5> <https://github.com/snapcore/snapd/pull/4617> | 17:55 |
| Chipaca | mvo_: if it's survive, and has a reloadcommand, wouldn't you fire that? | 17:55 |
| Chipaca | hm, maybe i'll ask it on the pr :-) | 17:56 |
| * Chipaca sees it's dinnertime in mvoland | 17:56 | |
| * Chipaca EOWs (mostly) | 18:01 | |
| el_tigro1 | kurofa: Thanks again for the help yesterday | 18:11 |
| el_tigro1 | zyga: I ran into this great documentation today which I'm assuming you wrote | 18:12 |
| zyga | which documentation was that? | 18:13 |
| el_tigro1 | zyga: https://github.com/snapcore/snapd/wiki/Snap-Execution-Environment | 18:13 |
| zyga | ah, yes | 18:13 |
| el_tigro1 | Question about the last paragraph "Preserving the mount namespace". The "/run/ns/snapd/" directory doesn't seem to exist on my system | 18:14 |
| zyga | sorry, that's backwards, it should be /run/snapd/ns | 18:14 |
| zyga | let me fix that | 18:15 |
| el_tigro1 | Ohh I should have caught that :D | 18:15 |
| el_tigro1 | zyga: Also I was wondering in what order "snap-confine" does its job. I'm assuming it handles the mount namespace stuff first, and then applies the apparmor/seccomp confinement? | 18:19 |
| zyga | it's complicated, I should write something more in depth | 18:19 |
| zyga | it handles all of mount namespace handling first, using itself and a helper process (snap-update-sn) | 18:20 |
| zyga | it applies seccomp and apparmor and cgroup handling before running the application | 18:20 |
| zyga | normally the order should not matter to apps, it should just work | 18:20 |
| el_tigro1 | really? the reason I assumed that was the order is that I thought apparmor/seccomp could disable the "mount" system call | 18:22 |
| el_tigro1 | Actually I mean the unshare/clone system calls | 18:23 |
| el_tigro1 | Actually I'm confused. Just ignore what I'm saying :P | 18:23 |
| zyga | yes it can | 18:23 |
| zyga | during the whole process the sandbox changes a few times | 18:23 |
| zyga | snap-confine itself is confined with one profile | 18:23 |
| zyga | snap-update-ns is confined with another profile | 18:23 |
| zyga | and the application being started is confined with its own profile | 18:24 |
| zyga | (and some of the work I'm doing now will also tailor snap-update-ns to have different profile per snap) | 18:24 |
| zyga | all of this is so that it's harder to attack the system and so that super-power wielding things are as confined as possible | 18:24 |
| zyga | mount is confined both at syscall level through seccomp and at path/device/options level through apparmor | 18:25 |
| el_tigro1 | Thanks. I find this stuff really interesting | 18:27 |
| el_tigro1 | I guess 'snap-confine' uses the 'pivot_root' system call to change its root? | 18:28 |
| zyga | yes, that's correct | 18:28 |
| zyga | it also jumps in and out of namespaces | 18:28 |
| zyga | inspects them, invalidates them when necessary | 18:28 |
| zyga | it handles cgroups (freezer and device) | 18:28 |
| zyga | it uses snap-update-ns to construct and update existing namespaces | 18:29 |
| zyga | and saves them on disk to preserve them across process lifecycle | 18:29 |
| el_tigro1 | 'pivot_root' takes an 'put_old' argument, which I guess is the '/var/lib/snapd/hostfs'? | 18:31 |
| zyga | yes | 18:31 |
| el_tigro1 | And in that documentation link from above "Certain directories from the host file system are mapped (bind-mounted) to the mount namespace (see below).". They directories are the ones listed below the "The mount profile of the snap is applied (e.g. content sharing uses this)" bullet point right? | 18:32 |
| zyga | yes | 18:33 |
| zyga | though that's an incomplete list now, it also depends on interfaces | 18:33 |
| zyga | and it also depends on nvidia driver being used | 18:33 |
| el_tigro1 | Wow thanks a lot for your time. You've given me quite a few leads. Back to experimenting/studying :D | 18:34 |
| zyga | feel free to ask questions | 18:34 |
| zyga | perhaps you would like to contribute back by writing documentation | 18:34 |
| zyga | let me know if you'd like to help | 18:35 |
| el_tigro1 | Defintely. Once I feel like I have a solid enough understanding | 18:35 |
| mvo_ | ackk: I added tzdata now, it will be part of the next base-18 build | 18:55 |
| mvo_ | ackk: (sorry for the delay) | 18:55 |
| el_tigro1 | One thing that I noticed is that older versions of snaps are not removed. For example if I do 'ls /snap/lxd' I see 3 folders and a symbolic link 'current' pointing to the latest version. Would removing the directories containing the older versions be a bad idea? | 18:57 |
| zyga | this is on purpose | 18:57 |
| zyga | you also have three revisions of the snap installed, but not active | 18:57 |
| zyga | (only one is active) | 18:58 |
| zyga | when something goes bad and you want to revert to a prior version (e.g. broken update) the data is kept around | 18:58 |
| el_tigro1 | ahh I see | 18:58 |
| zyga | over time old revisions are removed, no need to do that manually | 18:58 |
| zyga | niemeyer +1 to merge 4610? | 19:29 |
| niemeyer | zyga: Should be.. let me check | 19:29 |
| niemeyer | zyga: Looks fine, thanks for double checking | 19:32 |
| zyga | great, thank you! | 19:33 |
| * zyga gets a coffee and works on some more :) | 19:33 | |
| mup | PR snapd#4610 closed: interfaces/apparmor: early support for snap-update-ns snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4610> | 19:33 |
| philroche | Can anyone see what is wrong with my snapcraft.yaml as I can not get the organize section to work with the python plugin https://github.com/philroche/ubuntu-watch-packages/blob/master/snap/snapcraft.yaml ? Thanks | 20:16 |
| nacc_ | philroche: i think it's your .' | 20:17 |
| nacc_ | philroche: so i believe, it's going to be running form the root of your source | 20:17 |
| nacc_ | it won't find 'wrapper' there | 20:17 |
| mup | PR snapd#4621 opened: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4621> | 20:18 |
| nacc_ | philroche: i put wrappers in their own part that's dump'd into the snap | 20:18 |
| nacc_ | philroche: alternatively, you put it i your MANIFEST.in | 20:18 |
| nacc_ | philroche: but otherwise, i don't thinkt he setup.py will see it and soo the python plugin won't | 20:19 |
| philroche | nacc_: I tried it with wrapper in root too and the same error "The specified command 'wrapper' defined in the app 'ubuntu-watch-packages' does not exist or is not executable" | 20:19 |
| philroche | nacc_: Yeah using a second dump part was my next approach | 20:19 |
| nacc_ | philroche: i would try that first (the dump part) | 20:20 |
| philroche | nacc_: I hadn't thought of using the MANIFEST.in either but that seems a bit dirty by introducing snap stuff to the python package | 20:20 |
| nacc_ | philroche: yeah i woulldn't recommend it :) | 20:21 |
| sergiusens | jdstrand stgraber in case you have a couple of minutes https://forum.snapcraft.io/t/disconnected-issue-a-cocktail-of-running-snapcraft-cleanbuild-in-multipass-with-the-lxd-snap/3891 | 20:31 |
| philroche | nacc_: Thanks. Trying dump method now | 20:34 |
| cachio_ | niemeyer, https://travis-ci.org/snapcore/snapd/builds/338037140 | 21:25 |
| cachio_ | Cannot allocate linode:ubuntu-14.04-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout | 21:25 |
| cachio_ | that happened today | 21:26 |
| cachio_ | it is not so frequent but I see 1 or 2 of those every day | 21:26 |
| niemeyer | cachio_: Thanks, also keeping an eye on those | 21:27 |
| niemeyer | cachio_: But the most important issue is still the state corruption they seem to observe | 21:27 |
| niemeyer | cachio_: Without that sorted we'll need to go elsewhere in the near future.. fingers crossed | 21:27 |
| cachio_ | niemeyer, good, tx | 21:28 |
| kyrofa | zyga, I can't seem to reproduce the LXD issue as of 2.30. I'm not sure what changed | 21:56 |
| zyga | maybe lxd shipped some workaround? | 21:56 |
| kyrofa | Yeah that's my only clue as well | 21:56 |
| zyga | are you sure you are on 2.30? | 21:56 |
| kyrofa | Yeah, rev 3748 | 21:57 |
| kyrofa | (tracking stable) | 21:58 |
| mup | Issue snapcraft#1918 opened: Add y/n support for sending errors back <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1918> | 22:08 |
| mup | Issue snapcraft#1919 opened: Add Always/neVer support when sending errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1919> | 22:08 |
| mup | Issue snapcraft#1920 opened: Design error reporting <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1920> | 22:08 |
| mup | PR snapd#4622 opened: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622> | 22:44 |
| mup | PR snapd#4620 closed: debian/rules: workaround for https://github.com/golang/go/issues/23721 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4620> | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
