| mborzecki | morning guys | 06:03 |
|---|---|---|
| zyga-ubuntu | good morning | 06:12 |
| zyga-ubuntu | it's snowing!!! | 06:12 |
| zyga-ubuntu | man, I haven't seen snow in years | 06:12 |
| mborzecki | zyga-ubuntu: hey | 06:14 |
| mborzecki | yeah, splendid weather | 06:15 |
| zyga-ubuntu | mborzecki: just like I remember it my whole childhood :) | 06:19 |
| zyga-ubuntu | mborzecki: it will be white by the time my kids go to school today | 06:19 |
| mborzecki | zyga-ubuntu: https://forum.snapcraft.io/t/core-snap-fails-auto-review-in-the-store-since-friday/2897 | 06:21 |
| zyga-ubuntu | mborzecki: yep, I know :/ | 06:21 |
| zyga-ubuntu | though, let me read about new developments | 06:21 |
| zyga-ubuntu | mborzecki: the store review code diff was one character | 06:22 |
| zyga-ubuntu | mborzecki, ogra_: commented | 06:28 |
| zyga-ubuntu | man it's whiter every second | 06:28 |
| zyga-ubuntu | the roof is now fully white | 06:28 |
| zyga-ubuntu | and my wife's car too (poor her!) | 06:28 |
| zyga-ubuntu | I only wish it was colder so the snow would not melt away so quickly | 06:28 |
| zyga-ubuntu | so, today, I have a few branches to iterate on | 06:29 |
| zyga-ubuntu | but I'd like to fix the other LXD issue once and for all | 06:29 |
| zyga-ubuntu | to have that boulder off my back | 06:29 |
| mborzecki | well, it's raining right here, there's still some spots of snow that apparently fell over the night, but it's ugly as hell (i.e. typical november) | 06:30 |
| zyga-ubuntu | mvo: hello | 06:35 |
| zyga-ubuntu | mvo: SNOW! :D | 06:36 |
| zyga-ubuntu | mvo: some unhappy store news | 06:36 |
| zyga-ubuntu | mvo: new review tools not deployed yet (it seems), jdstrand sent us email over weekend | 06:36 |
| zyga-ubuntu | mvo: not sure if there are things he said we could do | 06:36 |
| mvo | hey zyga-ubuntu ! good morning | 06:40 |
| mvo | zyga-ubuntu: looking at my mail now. any other unhappy news? | 06:40 |
| mvo | zyga-ubuntu: snow is nice | 06:40 |
| zyga-ubuntu | mvo: no, nothing other than that | 06:42 |
| zyga-ubuntu | mvo: but I haven't checked much yet | 06:42 |
| zyga-ubuntu | mvo: waking kids up now | 06:42 |
| mborzecki | mvo: morning | 06:42 |
| mvo | hey mborzecki - good morning | 06:43 |
| zyga-ubuntu | (I don't like when they don't go to school at 8AM) | 06:43 |
| stgraber | zyga-ubuntu: FYI, https://bugs.launchpad.net/snapd/+bug/1733211 | 07:02 |
| mup | Bug #1733211: lxd snap fails to install w/apparmor "permission denied" error <snapd:New> <https://launchpad.net/bugs/1733211> | 07:02 |
| stgraber | zyga-ubuntu: going to bed now, but I expect we'll have more people run into this one as we've pushed a deprecation warning to all our PPA users on Friday telling them to move to the snap or backports | 07:03 |
| zyga-ubuntu | stgraber: thank you for the note, reading | 07:03 |
| zyga-ubuntu | stgraber: that looks like a new bug right? | 07:04 |
| zyga-ubuntu | stgraber: or a regression technically | 07:04 |
| zyga-ubuntu | but this is weird, we have the rule to read that: | 07:05 |
| zyga-ubuntu | @{PROC}/@{pid}/cmdline r, | 07:05 |
| zyga-ubuntu | stgraber: if this is about privileged containers that don't stack apparmor then this is ECANNOTFIX | 07:06 |
| zyga-ubuntu | stgraber: I sincerely hope it's not, let me read the bug carefully | 07:06 |
| stgraber | zyga-ubuntu: no, I hit this outside of a container | 07:06 |
| stgraber | zyga-ubuntu: usually on machines that are already running other snaps | 07:06 |
| zyga-ubuntu | stgraber: aha! | 07:06 |
| zyga-ubuntu | stgraber: thank you, I'll investigate | 07:07 |
| zyga-ubuntu | since you said that rebooting helped it smells like apparmor cache bug we ran into before | 07:07 |
| stgraber | zyga-ubuntu: the fact that rebooting the system fixes the issue is somewhat puzzling | 07:07 |
| zyga-ubuntu | I'll try to reproduce now | 07:07 |
| stgraber | oh, yeah, could be the apparmor cache | 07:07 |
| stgraber | not sure why I didn't think of that, I could have dumped the content of the cache and profile before rebooting the system (though to be fair, they were broken production systems, so didn't have much time for debugging :)) | 07:08 |
| stgraber | which makes me wonder, I have that backup host that may actually have the same issue and would let me check this quickly without risk | 07:08 |
| stgraber | and nope, no such luck, that system installs the lxd snap without any problem... | 07:09 |
| * stgraber tries a few other random systems in his basement real quick | 07:09 | |
| zyga-ubuntu | stgraber: no worries, enjoy your evening and let us investigate | 07:09 |
| jibel | good morning | 07:19 |
| jibel | there is a recent increase of this problem on errors.u.c https://errors.ubuntu.com/problem/cf07c2fa3f39a98f0b52aaf20ff82faab7969129 | 07:19 |
| zyga-ubuntu | jibel: good morning | 07:19 |
| jibel | it started around Nov. 14th | 07:19 |
| zyga-ubuntu | jibel: thank you for the notice | 07:19 |
| stgraber | that sounds surprisingly similar to that issue we were just discussing, also permission denied, also for a path that should be allowed and also in the configure hook | 07:21 |
| zyga-ubuntu | jibel: oh, interesting, this is a yet another issue | 07:22 |
| zyga-ubuntu | stgraber: yes, we ran into this one a while ago ~1 month | 07:22 |
| zyga-ubuntu | stgraber: it was a bug in apparmor then | 07:22 |
| zyga-ubuntu | stgraber: and we included a workaround for that | 07:22 |
| zyga-ubuntu | something we need to look into, apparently | 07:22 |
| jibel | zyga-ubuntu, yeah other crash are with specific snaps, but this one is with the core snap | 07:22 |
| jibel | on 17.10 and 18.04 | 07:22 |
| zyga-ubuntu | mvo: so we have more "news" apparently | 07:23 |
| zyga-ubuntu | 2.29.3 is very worrying, it should have been fixed before | 07:23 |
| mvo | zyga-ubuntu: the configure script error is probably not 2.29.3 itself, just the fact that we have an update, no? | 07:28 |
| mvo | zyga-ubuntu: I mean, the mass update of core triggered this I presume? triggered the apparmor bug | 07:28 |
| mvo | zyga-ubuntu: do you remember the details for the previous workaround? that was part of 2.28.X, right? | 07:29 |
| mvo | zyga-ubuntu: I don't see a mail from jamie about the script in my inbox, maybe it just went to you? | 07:31 |
| zyga-ubuntu | mvo: let me check | 07:33 |
| mup | PR snapd#4249 opened: release: snapd 2.29.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4249> | 07:34 |
| zyga-ubuntu | mvo: the previous bug we did something (AFAIR you did after talking to tyhicks) that casuses cache to be purged on core updates on core | 07:34 |
| zyga-ubuntu | mvo: ok, I should eat something before jumping into the fray | 07:35 |
| zyga-ubuntu | mvo: I see that we have three issues: LXD + remove bug (close to being fixed, oldest), bug reported by stgraber above (mysteriously fixes itself on reboot) and the bug form errors.u.c from 14th Nov | 07:36 |
| zyga-ubuntu | mvo: the other two may be related but not sure if they are yet | 07:36 |
| zyga-ubuntu | mvo: let's split work in 20 minutes, I need to eat something | 07:36 |
| mvo | zyga-ubuntu: sure, eat | 07:37 |
| mvo | zyga-ubuntu: ssee you then | 07:37 |
| mborzecki | zyga-ubuntu mvo anything I can help with? | 08:07 |
| zyga-ubuntu | mvo: ok properly back now | 08:12 |
| * zyga-ubuntu made _warm_ breakfast for a change | 08:12 | |
| zyga-ubuntu | mborzecki: definitely! | 08:17 |
| mvo | zyga-ubuntu, mborzecki I created http://pad.ubuntu.com/Wkp2bPRAnI so that we have a scratchpad, please add all you know there for now and once we have a bit more we can make that three forum topics | 08:19 |
| mvo | zyga-ubuntu: I'm especially interessted in "lxd-+remove bug", is that the one you were chasing for some time ? | 08:19 |
| mvo | zyga-ubuntu: i.e. the one where the rshared is not set correctly on /snap ? | 08:20 |
| zyga-ubuntu | mvo: yes | 08:20 |
| zyga-ubuntu | mvo: yes | 08:20 |
| mvo | zyga-ubuntu: and if it is this one, why is it on the list? its not something new in 2.29.4, or is it? | 08:20 |
| mborzecki | mvo: can you paste the bug report from errors.ubuntu.com in the pad? I've only requested access there | 08:21 |
| zyga-ubuntu | mvo: no, nothin new | 08:21 |
| mvo | zyga-ubuntu: ok, if its nothing new, lets move it down the priorites just for now to figure out if 2 and 3 are regressions and what we can do about them (?) | 08:22 |
| zyga-ubuntu | mvo: +1 | 08:22 |
| zyga-ubuntu | done | 08:23 |
| mvo | mborzecki: I added some more data, unfortunately its not much, I guess we need a reproducer, might be as simple as going from an old core to the new core on 17.10, but then I do that all the time and have not seen it :/ | 08:23 |
| zyga-ubuntu | I added some ideas on what might happen | 08:23 |
| mvo | zyga-ubuntu: ta | 08:24 |
| zyga-ubuntu | mvo: is issue 2 (renumbered) affecting those as LXD guest or host? | 08:30 |
| zyga-ubuntu | mvo: (those releases) | 08:30 |
| mvo | zyga-ubuntu: yeah, I wonder the same, I just tried it on a normal system in 17.10 and did not see the error | 08:32 |
| zyga-ubuntu | mvo: I don't see 2.29.3 in the archive | 08:33 |
| zyga-ubuntu | on 17.10 | 08:33 |
| mborzecki | it's 2.28.5 iirc | 08:33 |
| zyga-ubuntu | yes, that's what I see | 08:33 |
| mvo | zyga-ubuntu: not even in -proposed? | 08:33 |
| zyga-ubuntu | mvo: ah, I didn't look there (not a default setup) | 08:33 |
| zyga-ubuntu | do you think people affected by 2nd bug used proposed? | 08:34 |
| mvo | zyga-ubuntu: maybe but its strange | 08:34 |
| mvo | zyga-ubuntu: because I can't reproduce it on a regular system | 08:35 |
| mvo | zyga-ubuntu: with 2.29.3 from the debs on 17.10 | 08:35 |
| mvo | zyga-ubuntu: but maybe I need to try harder | 08:35 |
| zyga-ubuntu | mvo: same result with stable debs + core | 08:36 |
| mvo | thanks jibel btw for raising this issue! | 08:36 |
| mvo | zyga-ubuntu: worth exploring if its happening inside lxd only, but then - the amount of users(17.10) & users(lxd) & users(snapd) are producing a relative high number of errror reports | 08:39 |
| jibel | mvo, yw | 08:47 |
| kalikiana | o/ | 08:49 |
| mup | PR snapd#4250 opened: packaging: fix typo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4250> | 08:54 |
| zyga-ubuntu | brb | 09:18 |
| zyga-ubuntu | re | 09:38 |
| zyga-ubuntu | mvo: do we retry core configure failures/ | 09:39 |
| mvo | zyga-ubuntu: no, I we just ignore failures on them | 09:41 |
| zyga-ubuntu | mvo: that's curious | 09:41 |
| zyga-ubuntu | mvo: look at those: | 09:41 |
| zyga-ubuntu | https://errors.ubuntu.com/oops/c8ec99fe-cdd2-11e7-919f-fa163ef911dc | 09:41 |
| zyga-ubuntu | https://errors.ubuntu.com/oops/7fecbe46-cdd2-11e7-9435-fa163ebeb28a | 09:41 |
| zyga-ubuntu | mvo: that's one system | 09:42 |
| zyga-ubuntu | right? | 09:42 |
| mvo | zyga-ubuntu: yeah, thats strange indeed | 09:43 |
| mvo | zyga-ubuntu: it looks almost like the install fails and it is retrying | 09:43 |
| zyga-ubuntu | mvo: could it be a fresh install? | 09:43 |
| zyga-ubuntu | mvo: after restarting into new snapd | 09:43 |
| zyga-ubuntu | mvo: maybe another LXD cluster with privileged containers for that cloud certification? | 09:44 |
| mvo | zyga-ubuntu: it has DidRexec set to 0 | 09:44 |
| zyga-ubuntu | mvo: ah, I see | 09:44 |
| zyga-ubuntu | puzzlin | 09:44 |
| mvo | zyga-ubuntu: yeah | 09:44 |
| zyga-ubuntu | mvo: so ... proposed testing? | 09:44 |
| zyga-ubuntu | mvo: maybe this is some adt machine? | 09:44 |
| zyga-ubuntu | mvo: running off proposed? | 09:44 |
| mvo | zyga-ubuntu: that sounds like a good theory | 09:45 |
| mvo | zyga-ubuntu: and its a 16.04 one | 09:45 |
| zyga-ubuntu | did you have any luck in reproducing this? | 09:47 |
| mup | PR snapd#4251 opened: timeutil: include test input in error message in TestParseSchedule() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4251> | 09:48 |
| === mup_ is now known as mup | ||
| Shibe | guys is there any nightly for snappy? | 10:16 |
| Shibe | for ubuntu | 10:16 |
| zyga-ubuntu | Shibe: we have the edge channel which is just like that | 10:17 |
| Shibe | zyga-ubuntu: how do I enable it on ubuntu? | 10:17 |
| zyga-ubuntu | Shibe: install snapd, install core snap (if you don't have one already) and snap refresh core --edge | 10:17 |
| zyga-ubuntu | mvo: no idea how to reproduce this, I tried in various containers with and without proposed | 10:31 |
| mvo | zyga-ubuntu: yeah, I am also clueless so far, I think we need to move it to the forum and see if we can find someone who actually hits this or can give us other clues | 10:34 |
| zyga-ubuntu | hmm | 10:35 |
| zyga-ubuntu | http://pad.ubuntu.com/ep/pad/reconnect - forbidden | 10:35 |
| zyga-ubuntu | how i "love" etherpad | 10:36 |
| mvo | zyga-ubuntu: http://pad.ubuntu.com/Wkp2bPRAnI ? | 10:39 |
| mvo | zyga-ubuntu: and yeah, its very annoying | 10:39 |
| zyga-ubuntu | mvo: connected back, thanks | 10:39 |
| mvo | yw | 10:40 |
| zyga-ubuntu | pull requests are kind of red | 10:40 |
| zyga-ubuntu | + snap refresh | 10:41 |
| zyga-ubuntu | error: cannot refresh []: cannot query the store for updates: got unexpected | 10:41 |
| zyga-ubuntu | HTTP status code 500 via POST to | 10:41 |
| zyga-ubuntu | "http://localhost:11028/api/v1/snaps/metadata" | 10:41 |
| mvo | zyga-ubuntu: yeah, I have a look in a tiny bit. but this sounds much like a problem for our friends in #snapstore :) | 10:41 |
| zyga-ubuntu | that's interesting, why are we refreshing a list of no snaps? | 10:41 |
| zyga-ubuntu | man | 10:43 |
| zyga-ubuntu | I *HATE* travis moronic log output behavior | 10:43 |
| zyga-ubuntu | why does clicking on any line closes the fold? | 10:44 |
| zyga-ubuntu | Nov 20 09:09:04 li157-129 snapd[31385]: 2017/11/20 09:09:04.824015 logger.go:76: DEBUG: < "HTTP/1.1 500 Internal Server Error\r\nContent-Length: 111\r\nContent-Type: text/plain; charset=utf-8\r\nDate: Mon, 20 Nov 2017 09:09:04 GMT\r\nX-Content-Type-Options: nosniff\r\n\r\ninternal error collecting snaps: open /tmp/read-file456639681/unpack/meta/snap.yaml: no such file or directory\n" | 10:44 |
| zyga-ubuntu | mvo: is that us or the store is sending that? | 10:44 |
| zyga-ubuntu | ah, that's fakestore | 10:45 |
| pedronis | zyga-ubuntu: that's our fakestore | 10:45 |
| mvo | zyga-ubuntu: uhhh, which PR is thisß | 10:45 |
| mvo | ? | 10:45 |
| mup | PR snapd#4252 opened: store: fix download caching and add integration test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4252> | 10:46 |
| zyga-ubuntu | this was 4242 but I just hit restart | 10:46 |
| zyga-ubuntu | it looks like timing / race in fakestore | 10:46 |
| mvo | zyga-ubuntu: ok, no worries, I try to reproduce | 10:46 |
| mup | PR snapd#4251 closed: timeutil: include test input in error message in TestParseSchedule() <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4251> | 10:47 |
| mvo | zyga-ubuntu: hm, not all is terrible, 4251 was green for example. there is a silver lining :) | 10:47 |
| mup | PR snapd#4250 closed: packaging: fix typo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4250> | 10:48 |
| mup | PR snapd#4247 closed: interfaces: allow /bin/chown and fchownat to root:root <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4247> | 10:50 |
| mvo | if someone could do a second review on 4242 that would be great, looks like an easy win | 10:50 |
| zyga-ubuntu | mvo: that 4247 one had a question | 10:52 |
| mvo | zyga-ubuntu: yes, I'm 99% sure the answer is "its fine", let me write that in the PR | 10:53 |
| zyga-ubuntu | mvo: done | 10:53 |
| mvo | zyga-ubuntu: ha! even better, thank you :) | 10:53 |
| zyga-ubuntu | mvo: I mean 4242 :) | 10:53 |
| mup | PR snapd#4235 closed: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidRe… <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4235> | 10:54 |
| mvo | zyga-ubuntu: let me check | 10:54 |
| mvo | zyga-ubuntu: aha, sorry, async communication is hard ;) | 10:54 |
| mvo | zyga-ubuntu: comment and I also looked at the source and my confidence is at 99.9 now | 10:57 |
| zyga-ubuntu | mvo: thank you, I shared that but wanted to check just in case | 10:58 |
| zyga-ubuntu | mvo: the BPF code just ingores those arguments | 10:58 |
| mvo | zyga-ubuntu: yeah | 10:58 |
| mvo | zyga-ubuntu: some PRs in flight, once there tests are green we can merge and will be below 25 again :) | 11:05 |
| mup | PR snapd#4253 opened: task tunner: extended task runner test <Created by stolowski> <https://github.com/snapcore/snapd/pull/4253> | 11:09 |
| zyga-ubuntu | mvo: yeah I'll merge them as soon as we can, I restarted a few random failures today | 11:11 |
| zyga-ubuntu | though way too more for my liking | 11:11 |
| mvo | zyga-ubuntu: yeah, its too fragile currently | 11:12 |
| mvo | zyga-ubuntu: the did-rexec in the error reports is a red-herring :/ the problem is that we unset SNAP_DID_REEXEC to not confuse classic confinement snaps. and that is the env that the err tracker picks up | 11:27 |
| zyga-ubuntu | mvo: are you saying that we should set a new flag SNAPD_WE_ACTUALLY_DID=reexec | 11:28 |
| zyga-ubuntu | pstolowski: hey, do you have a moment for 2nd look on https://github.com/snapcore/snapd/pull/4224 | 11:31 |
| mup | PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes <Created by zyga> <https://github.com/snapcore/snapd/pull/4224> | 11:31 |
| zyga-ubuntu | pstolowski: I changed the approach slightly after your comment | 11:31 |
| mvo | zyga-ubuntu: maybe, I look into this right now | 11:31 |
| zyga-ubuntu | mvo: I kind of feel that the set of constraints is lost | 11:32 |
| zyga-ubuntu | mvo: we have some super ancient versions of snapd that put them | 11:32 |
| zyga-ubuntu | mvo: but they have now escaped me | 11:32 |
| zyga-ubuntu | mvo: maybe you could write this down in some reegex.go extented comment? | 11:32 |
| zyga-ubuntu | ha, and I said "regeexec" instead of reexec :) | 11:32 |
| mup | PR snapd#4242 closed: asserts/sysdb: panic early if pointed to staging but staging keys are not compiled-in <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4242> | 11:33 |
| pstolowski | zyga-ubuntu, will do in a few moments | 11:39 |
| niemeyer | Hello hello | 11:46 |
| zyga-ubuntu | niemeyer: hello | 11:47 |
| mborzecki | niemeyer: hi there | 11:52 |
| niemeyer | o/ | 11:52 |
| mvo | hey niemeyer ! welcome back | 11:54 |
| mborzecki | is there a way to have check do a pretty print of unequal values like spew does? | 11:54 |
| niemeyer | mvo: Thanks! | 11:55 |
| niemeyer | mborzecki: Not a pretty print, yet at least | 12:04 |
| mariogrip | jdstrand: ok got ubports-installer to work pretty nice in devmode now :) now the confined part, how do i handle the usb-raw part? post-install connect thing? | 12:15 |
| mup | PR snapd#4254 opened: cmd, errtracker: get rid of SNAP_DID_REEXEC environment <Created by mvo5> <https://github.com/snapcore/snapd/pull/4254> | 12:15 |
| zyga-ubuntu | mvo: ^ you have a conflict there | 12:17 |
| mup | PR snapd#4245 closed: interfaces/screen-inhibit-control: handle ScreenSaver/Screensaver in DBus API <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4245> | 12:46 |
| zyga-ubuntu | fg | 13:00 |
| ogra_ | full grin ? | 13:00 |
| ogra_ | :P | 13:00 |
| mup | PR snapd#4255 opened: interfaces/screen-inhibit-control: fix case in screen inhibit control <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4255> | 13:04 |
| kalikiana | yikes, my /var/lib/snapd/hostfs is empty!? | 13:11 |
| kalikiana | no wonder I'm getting strange failures | 13:11 |
| ogra_ | you mean from inside a "snap run --shell" ? | 13:11 |
| kalikiana | no, from outside as well | 13:12 |
| jdstrand | kalikiana: just passing by, but note it is only populated inside the snap | 13:12 |
| jdstrand | it is supposed to be empty on the host | 13:12 |
| ogra_ | kalikiana, thats normal, | 13:12 |
| ogra_ | only snap-confine mounts sumething there at runtime | 13:12 |
| kalikiana | hmmm so it's "only" an issue in the snap | 13:12 |
| kalikiana | I got a file not found error | 13:12 |
| kalikiana | I can't "--shell" since this is a classic snap... (snapcraft) | 13:14 |
| kalikiana | I'm pretty sure the relevant code hasn't changed | 13:14 |
| niemeyer | Is it me or hangouts just broke? | 13:15 |
| zyga-ubuntu | niemeyer: you | 13:15 |
| niemeyer | "There is a problem connecting to this video call. Try again in a few minutes." | 13:15 |
| zyga-ubuntu | niemeyer: you froze after "guys" | 13:15 |
| kalikiana | oh, actually --shell does something, but it looks like my real shell | 13:16 |
| mvo | niemeyer: some more investigation (quite raw) http://pad.ubuntu.com/Wkp2bPRAnI | 13:16 |
| kalikiana | jdstrand: ogra_ : so hostfs is empty within `snapcraft run --shell snapcraft` as well | 13:17 |
| kalikiana | feels like snapd changed something here | 13:17 |
| jdstrand | kalikiana: is snapcraft classic? | 13:17 |
| kalikiana | jdstrand: yes | 13:18 |
| jdstrand | iirc, is is only populated for non-classic | 13:18 |
| zyga-ubuntu | jdstrand: correct | 13:19 |
| zyga-ubuntu | hostfs on classic is / | 13:19 |
| zyga-ubuntu | so we don't do anything | 13:19 |
| zyga-ubuntu | perhaps we could use a trick | 13:19 |
| zyga-ubuntu | so in classic distros hostfs is a symlink to / | 13:19 |
| zyga-ubuntu | and for confined apps it is a directory and we pivot root there as we do | 13:20 |
| kalikiana | jdstrand, zyga-ubuntu: the code in snapcraft hasn't changed, though... | 13:20 |
| kalikiana | hrm, lemme debug this a bit | 13:22 |
| kalikiana | it's weird actually the fact that hosts even shows up as a path here. the code isn't doing that.. | 13:24 |
| kalikiana | hrmpf, now it works again, no change... | 13:33 |
| diddledan | https://forum.snapcraft.io/t/corebird-1-7-3-release-with-added-emoji/2906 | 13:42 |
| diddledan | \o/ | 13:42 |
| mup | PR snapd#4256 opened: snap-confine: add workaround for snap-confine on 4.13/upstream <Created by mvo5> <https://github.com/snapcore/snapd/pull/4256> | 13:51 |
| zyga-ubuntu | mvo: +1 | 13:52 |
| zyga-ubuntu | jdstrand: ^^ | 13:52 |
| mvo | zyga-ubuntu: I'm running the test in my manual created sid spread image now, will take a little bit | 13:54 |
| zyga-ubuntu | mvo: mvo thank you | 13:56 |
| zyga-ubuntu | mvo: my fix didn't work, I probably broke something just a moment ago as it was in a better shape last fix, digging | 13:56 |
| mvo | zyga-ubuntu: thank *you*, you came up with the right apparmor line | 13:56 |
| zyga-ubuntu | mvo: no, that was jdstrand :) | 13:57 |
| mvo | zyga-ubuntu: oh? the fix for the lxd remove? or a different fix that does not work? | 13:57 |
| zyga-ubuntu | mvo: for the remove | 13:57 |
| mvo | zyga-ubuntu: aha, ok. still, I think you put it in the forum, I'm sure there is plenty of reason to thank you :) | 13:57 |
| zyga-ubuntu | :D | 13:57 |
| * jdstrand reviewed 4256 | 13:57 | |
| * zyga-ubuntu tries -shell-before to see what's wrong | 13:57 | |
| mvo | zyga-ubuntu: testing on debian-sid shows some other issues, I will expand this pr a little bit, just fyi | 14:19 |
| zyga-ubuntu | mvo: ack | 14:21 |
| jdstrand | roadmr: hi! hope you had a nice weekend. not sure you read email yet, but can you update the review tools for r945? | 14:26 |
| jdstrand | popey: hey, do you have a moment to talk about snapcrafters? | 14:27 |
| roadmr | jdstrand: hey! | 14:33 |
| roadmr | jdstrand: I hadn't, but I'll get the ball rolling | 14:33 |
| kalikiana | sergiusens: just to double-check, we have our weekly tomorrow/ Tuesday again? | 14:34 |
| jdstrand | roadmr: thanks! | 14:34 |
| roadmr | jdstrand: I was aware of the situation on Friday but there was not much we could do then :( | 14:34 |
| kalikiana | sergiusens: I see it in the calendar, just at the back of my head someone said it would be Monday again | 14:34 |
| jdstrand | roadmr: yeah. r944 and r945 came in at an unfortunate time | 14:34 |
| mborzecki | need to finish for today, enjoy the rest of the day guys, cu | 14:36 |
| zyga-ubuntu | mvo: hey, I _think_ found the issue now (removed one line of apparmor by vim mistake probably) | 14:39 |
| zyga-ubuntu | mvo: running again to see | 14:39 |
| zyga-ubuntu | mvo: how are your stuff? | 14:39 |
| zyga-ubuntu | (debian) | 14:39 |
| * kalikiana going out for lunch shortly, will be back in ~hour or so | 14:40 | |
| mvo | zyga-ubuntu: debian is running, a bit slow but running. it was net-tools missing that broke it earlier, I added it to the PR | 14:41 |
| mvo | zyga-ubuntu: looking forward for the removal fix PR :) | 14:41 |
| kalikiana | zyga-ubuntu: hrm, seems I'm still seeing the weird hostfs issue, it only went away since I tried straight from git, not from the snap... it seems the lxd snap/ lxc command is receiving a path starting with /var/lib/snapd/hostfs/ and that's what I see in the error | 14:42 |
| zyga-ubuntu | mvo: once this run goes green I'll drop the unrelated changes and test again | 14:42 |
| zyga-ubuntu | mvo: and publush | 14:42 |
| zyga-ubuntu | *publish | 14:42 |
| zyga-ubuntu | kalikiana: can you please refresh my memory? | 14:42 |
| kalikiana | zyga-ubuntu: what I just described above | 14:52 |
| kalikiana | zyga-ubuntu: error: open /var/lib/snapd/hostfs/home/cris/snap/lxd/common/snapcrafts3h6q44p/core_3440.assert: no such file or directory from subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/cris/snap/lxd/common/snapcrafts3h6q44p/core_3440.assert', 'helga:snapcraft-oman/run/core_3440.assert']' returned non-zero exit status 1. | 14:53 |
| kalikiana | when the file exists in the folder | 14:53 |
| kalikiana | on the host | 14:53 |
| kalikiana | zyga-ubuntu: Wondering what could cause this... the path from snapcraft is the real one | 14:54 |
| mup | PR snapd#4257 opened: interfaces/opengl: also allow read on 'revision' in /sys/devices/pci <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4257> | 14:59 |
| mup | PR snapd#4249 closed: release: snapd 2.29.4 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4249> | 15:03 |
| zyga-ubuntu | re | 15:06 |
| zyga-ubuntu | kalikiana: sorry, no (immediate) idea, trying to wrap up one issue, then will switch context to this if you need help | 15:07 |
| kalikiana | zyga-ubuntu: aye, will have my lunch break first, no rush | 15:08 |
| kalikiana | well, late lunch haha | 15:08 |
| mvo | jdstrand: silly question, I get an apparmor denial in snap-confine/debina-sid http://paste.ubuntu.com/26005784/ but the rule looks valid to me, how can I check how @multiarch is expanded? | 15:09 |
| * jdstrand looks | 15:10 | |
| mvo | jdstrand: I have the VM in front of me if you need more info, its slightly puzzling | 15:10 |
| jdstrand | mvo: the rule looks right | 15:12 |
| jdstrand | mvo: is this a reexec situation? | 15:12 |
| jdstrand | (or lack thereof) | 15:12 |
| mvo | jdstrand: no, re-exec is disabled on debian-sid right now | 15:13 |
| mvo | jdstrand: its also happening when I directly run snap-confine in the shell | 15:13 |
| jdstrand | mvo: so /etc/apparmor.d/usr.lib.snapd.snap-confine.real has the rule you pasted? | 15:13 |
| * jdstrand isn't sure .real is used in Debian... | 15:14 | |
| mvo | jdstrand: *cough* the file is 0 bytes long | 15:14 |
| jdstrand | ah | 15:14 |
| mvo | jdstrand: so something is fishy here | 15:14 |
| jdstrand | well, that might have a consequence or two | 15:14 |
| jdstrand | sounds like the cache file is being used | 15:14 |
| mvo | jdstrand: indeed, looks like the debian packaging is broken :/ the deb is also zero bytes | 15:15 |
| jdstrand | yikes | 15:15 |
| zyga-ubuntu | deb is zero byts?! | 15:15 |
| zyga-ubuntu | hmmm | 15:16 |
| zyga-ubuntu | something fishy here: | 15:16 |
| zyga-ubuntu | umount: /snap/core/3495 unmounted | 15:16 |
| zyga-ubuntu | + unsquashfs '/var/lib/snapd/snaps/core_3495.snap | 15:16 |
| zyga-ubuntu | /var/lib/snapd/snaps/core_3495.snap' | 15:16 |
| zyga-ubuntu | Could not open /var/lib/snapd/snaps/core_3495.snap | 15:16 |
| zyga-ubuntu | /var/lib/snapd/snaps/core_3495.snap, because No such file or directory | 15:16 |
| zyga-ubuntu | there's a newline in that filename | 15:17 |
| mvo | zyga-ubuntu: the snap-confine.real in the deb is zero byte | 15:17 |
| zyga-ubuntu | mvo: I dropped junk from my branch, trying again | 15:21 |
| zyga-ubuntu | mvo: it passed :D | 15:30 |
| zyga-ubuntu | mvo: man, I just had to throw the garbage out | 15:30 |
| mvo | zyga-ubuntu: yay | 15:30 |
| zyga-ubuntu | mvo: I'll run a bit more of main to see one more test that broke on me earlier | 15:31 |
| zyga-ubuntu | mvo: any luck with that @multiarch thing? | 15:31 |
| mvo | zyga-ubuntu: zero size snap-confine.real apparmor in the package in debina | 15:33 |
| mvo | zyga-ubuntu: thats the culprit, I still try to understand why | 15:33 |
| zyga-ubuntu | mvo: kk | 15:33 |
| stgraber | zyga-ubuntu: did you find the source of that permission denied thing? | 15:35 |
| zyga-ubuntu | stgraber: yes, it was regular permission in the end | 15:35 |
| zyga-ubuntu | stgraber: that issue is fixed now snap-confine is now setgid root | 15:35 |
| zyga-ubuntu | stgraber: thank you :) | 15:35 |
| zyga-ubuntu | stgraber: also chasing (and almost fixed) the bug where snaps don't get removed in LXD | 15:35 |
| stgraber | zyga-ubuntu: oh, any idea why rebooting would solve it? | 15:35 |
| zyga-ubuntu | stgraber: ah, no, not that one | 15:36 |
| zyga-ubuntu | stgraber: sorry, no idea what caused that | 15:36 |
| zyga-ubuntu | stgraber: we tried to reproduce it in the morning without much luck, there's an etherpad with some details: http://pad.ubuntu.com/Wkp2bPRAnI | 15:36 |
| zyga-ubuntu | mvo: tentative, probably something I need to discuss with jdstrand https://github.com/snapcore/snapd/compare/master...zyga:fix/lxd-remove-bug?expand=1 | 15:37 |
| zyga-ubuntu | actually | 15:37 |
| zyga-ubuntu | the commit message is stale, one sec | 15:37 |
| mvo | zyga-ubuntu: so I think the problem is that we disable apparmor in debian, this leads to the zero byte file. do you think we should unconditionally enable apparor in debian now? or just install the apparmor profile for snapd and leave the rest as is? (cc jdstrand ) | 15:45 |
| stgraber | zyga-ubuntu: left a comment in the pad about setup but yeah, it's certainly not trivial to reproduce as I tried a dozen other systems here and none of them are affected despite all of them also being 16.04 with live patch | 15:46 |
| jdstrand | mvo: I think the idea was that we would enable 'partial' support in Debian, which would mean all the policy is in place. zyga-ubuntu was working towards that | 15:50 |
| mvo | jdstrand: ok, I will go with that then | 15:51 |
| jdstrand | zyga-ubuntu: this is a short week for me. I have 4170 and 4109 on my list for reviews this week. is there anything else pressing? | 15:52 |
| jdstrand | (reviews for you that is) | 15:52 |
| jdstrand | zyga-ubuntu: are both of those ready for me to review? | 15:52 |
| zyga-ubuntu | mvo: yes, we should enable apparmor in debian now | 16:02 |
| zyga-ubuntu | stgraber: thank you, I'll check in a moment | 16:02 |
| zyga-ubuntu | jdstrand: yes, I think we can use partial policy | 16:03 |
| zyga-ubuntu | jdstrand: 4170 is good, as is 4224 | 16:04 |
| zyga-ubuntu | jdstrand: 4109 is optional, we can close it if you want; I can just take a small refactoring patch and propose it separately | 16:04 |
| zyga-ubuntu | *separately | 16:04 |
| zyga-ubuntu | jdstrand: if we focus on this we could do most or all of layouts this week, if we get to a quick feedback cycle for PRs each dayt | 16:05 |
| zyga-ubuntu | *day | 16:05 |
| zyga-ubuntu | jdstrand: we are just a few PRs short of this now, most of the code is in, just some glue is left | 16:05 |
| zyga-ubuntu | jdstrand: all my PRs are ready to review, except for the one that's marked as "blocked" | 16:05 |
| jdstrand | zyga-ubuntu: so, 4170 and 4224 require reviews from me (and optionally 4109). correct? | 16:07 |
| zyga-ubuntu | jdstrand: yes | 16:07 |
| * jdstrand adds 4224 | 16:08 | |
| jdstrand | thanks | 16:08 |
| flexiondotorg | elopio: Hi | 16:15 |
| flexiondotorg | I'm working on (just about finished) a language guide for creating snaps of Rust apps. | 16:16 |
| flexiondotorg | I've use Parity as the example yaml. | 16:16 |
| flexiondotorg | elopio: Can you explain why you are staging libc in the upstream parity yaml? | 16:16 |
| kyrofa | elopio, I'm seeing a number of adt test failures that only include the autoremove output in the error string: https://pastebin.ubuntu.com/26006225/ | 16:26 |
| kyrofa | So they fail, but it doesn't say why | 16:26 |
| kennyloggins | popey 's off today - hope all is cool with him & his cat Sky. | 16:28 |
| kyrofa | Hey zyga-ubuntu, any progress on that other lxd issue? | 16:32 |
| zyga-ubuntu | kyrofa: which one? (we have >> 1 now) | 16:33 |
| zyga-ubuntu | kyrofa: the oldest remove bug? | 16:33 |
| kyrofa | zyga-ubuntu, indeed | 16:33 |
| zyga-ubuntu | kyrofa: yes, running main tests now, I'll work with mvo and jdstrand on reviewing this quickly | 16:33 |
| kyrofa | zyga-ubuntu, wonderful, thank you! | 16:34 |
| elopio | kyrofa: that's executing the command. We need something that will capture stderr for all those executions, and puts it in the test details. | 16:35 |
| elopio | maybe an assertCommandOutput, or something. | 16:35 |
| kalikiana | kyrofa: that looks like the binary couldn't be run - although I could be mistaken | 16:36 |
| magicaltrout | anyone tried jdbc connections with that mysql snap part from nextcloud? | 16:36 |
| mup | PR snapd#4255 closed: interfaces/screen-inhibit-control: fix case in screen inhibit control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4255> | 16:39 |
| kyrofa | elopio, ah, okay | 16:41 |
| elopio | I upgraded to bionic and you will never guess what happened next... | 16:48 |
| elopio | no wifi disconnections the whole morning! | 16:48 |
| kyrofa | elopio, ah! Amazing! | 16:48 |
| kyrofa | elopio, so I see you haven't learned your lesson :P | 16:48 |
| kalikiana | elopio: I would've recommended trying from a USB stick first... which is funny because our risk aversity is reversed in non-digital life, like cross streets | 16:51 |
| elopio | I haven't been trained for non-digital life. | 16:54 |
| === petevg_afk is now known as petevg | ||
| zyga-ubuntu | kyrofa: https://github.com/snapcore/snapd/pull/4258 | 17:01 |
| mup | PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <https://github.com/snapcore/snapd/pull/4258> | 17:01 |
| mup | PR snapd#4258 opened: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <https://github.com/snapcore/snapd/pull/4258> | 17:01 |
| zyga-ubuntu | jdstrand: please look at that PR briefly to see if it's on the right track | 17:04 |
| kyrofa | Nice work zyga-ubuntu, thanks for hacking on that | 17:04 |
| kalikiana | elopio: your parents raised you through a webcam? | 17:04 |
| elopio | kalikiana: no, but that's not a bad idea. Maybe I can take some coursera classes to learn how to deal with the city :) | 17:25 |
| zyga-ubuntu | hmm | 17:35 |
| zyga-ubuntu | snapd fails on 4.14 | 17:35 |
| zyga-ubuntu | in bionic | 17:36 |
| niemeyer | Weird.. I thought we had discussed and agreed not to release the progress bar making use of ASCII background color | 17:39 |
| niemeyer | But stable apparently has it | 17:39 |
| gsilvapt | hello all | 17:47 |
| gsilvapt | Anyone with experience writing tests for snapcraft? | 17:47 |
| pstolowski | niemeyer, ok, i've found the problem with taskrunner | 17:48 |
| niemeyer | pstolowski: Oh! Tell us! | 17:48 |
| zyga-ubuntu | pstolowski: I'm curious now | 17:48 |
| gsilvapt | kyrofa, maybe you could help finish this issue :p | 17:50 |
| gsilvapt | Maybe I'm using click framework poorly but I am not 100% sure | 17:50 |
| pstolowski | niemeyer, zyga-ubuntu so my hunch about run-hook not having undo handler was correct, but I missed the fact that fixing this in hookmgr doesn't affect the tests (because test register own handler with undo=nil). so yes, when taskrunner sees undo handler == nil, it immediately transitions from UndoStatus -> DoneStatus, disregarding any other tasks. so if the hook task was a prerequistite of some other task, that other task gets unblocked immediately | 17:51 |
| pstolowski | so the culprit is in the block of code marked with // Cannot undo. Revert to done status. | 17:55 |
| kalikiana | gsilvapt: what're you up to? I have more experience with tests than I ever asked for :-P | 17:56 |
| gsilvapt | kalikiana, basically I'm implementing a method to retrieve snapcraft's version by calling a command snapcraft version | 17:56 |
| gsilvapt | Using click, I think I have properly defined this implementation. | 17:56 |
| kalikiana | ah, nice | 17:56 |
| niemeyer | pstolowski: I still don't see how that's a problem | 17:57 |
| gsilvapt | But, when I wrote the test, I can see the exit_code = 2, which I cannot find in that definition so I have no idea what that means and/or if the method is implemented properly | 17:57 |
| gsilvapt | the method = mine | 17:57 |
| niemeyer | pstolowski: In particular, your last statement about unblocking immediately sounds like exactly what we want | 17:57 |
| kalikiana | gsilvapt: is the code you're talking about in a branch? I think I need some more context to be helpful | 17:58 |
| gsilvapt | kalikiana, well, I created my own branch to write my own code but I can send you a pastebin or something | 17:58 |
| pstolowski | niemeyer, the hook task is part of the chain where every task waits for the next one; so suddenly a task in the middle of the chain is considered Done, regardless of the tasks following it | 17:58 |
| kalikiana | gsilvapt: sure, pastebin is fine, whichever is convenient | 17:58 |
| niemeyer | pstolowski: Again, that's exactly what we want | 17:59 |
| niemeyer | pstolowski: Tasks *following* it will *follow* it | 17:59 |
| gsilvapt | kalikiana, https://gist.github.com/anonymous/4064b69dbd96ac9fcea88747fc0d178d | 18:00 |
| niemeyer | pstolowski: Which doesn't mean you are wrong.. I just don't see what the actual issue is yet | 18:00 |
| pstolowski | niemeyer, adding non-nil undo handler (that does nothing) to run-hook in the test immediately fixes the out-of-order tasks. this cannot be right | 18:00 |
| gsilvapt | kalikiana, if you need some help reading my code, let me know. I'm new around and only started learning how to code properly in September or so - please be patient :D | 18:01 |
| niemeyer | pstolowski: Which out of order tasks? | 18:01 |
| niemeyer | pstolowski: Again.. it all sounds quite vague | 18:01 |
| magicaltrout | so..... is there a size limit on snaps? | 18:01 |
| kyrofa | gsilvapt, that looks good, but does not look complete | 18:01 |
| niemeyer | pstolowski: If a task B has A ordered before it, and A is done, B is immediately unblocked | 18:01 |
| niemeyer | That's what we want | 18:01 |
| kyrofa | gsilvapt, you need to actually _use_ it in cli/__init__.y | 18:01 |
| gsilvapt | Hum, can you say what is missing in abstract terms? Maybe I can think of something to complete it | 18:02 |
| pstolowski | niemeyer, http://pastebin.ubuntu.com/26006783/ | 18:02 |
| niemeyer | pstolowski: Ok, what should I look at there? | 18:02 |
| gsilvapt | kyrofa, so I need to change the @click.version() bit? | 18:02 |
| pstolowski | niemeyer, HO? | 18:02 |
| kyrofa | gsilvapt, go into the cli directory, and grep around for "help" | 18:02 |
| niemeyer | pstolowski: Sure | 18:02 |
| kyrofa | gsilvapt, no, you need to actually hook your new subcommand into snapcraft | 18:02 |
| kyrofa | gsilvapt, look for how the help command is done | 18:03 |
| niemeyer | pstolowski: Waiting in the standup | 18:03 |
| kyrofa | You can grep for "helpcli" as well | 18:03 |
| kalikiana | gsilvapt: one thing I notice is the except ImportError - maybe not the issue you were asking about, but I'd say if you are running this code, snapcraft is installed... so you shouldn't need that at all | 18:03 |
| gsilvapt | kalikiana, what if the user does not have snapcraft installed? | 18:04 |
| gsilvapt | kyrofa, thank you, I'll look at the example and see if I can figure this out | 18:04 |
| kalikiana | gsilvapt: think about it. the code is part of snapcraft | 18:04 |
| kalikiana | unless I misunderstood what you're trying to do | 18:05 |
| kyrofa | gsilvapt, sure. Sorry for letting you pound your head on this, but it really is the best way to learn things sometimes! Let me know if you need another hint | 18:05 |
| gsilvapt | kyrofa, please do not apologise for that! This helps me understand what is going on and learn how to do stuff so yes, this is actually better! | 18:06 |
| gsilvapt | kalikiana, all packages will return no package found 'package-name' so I think this command should return the exception it could not find snapcraft installed in the system | 18:07 |
| gsilvapt | Perhaps the Exception is poorly designed and thus is confusing you but maybe we can work it out too | 18:07 |
| kalikiana | gsilvapt: just to be clear: will this code be part of snapcraft? | 18:07 |
| kalikiana | or another tool? | 18:08 |
| * kalikiana needs to change location, will be back in a few minutes | 18:08 | |
| gsilvapt | kalikiana, I did not follow entirely | 18:08 |
| kalikiana | gsilvapt: will version.py be part of snapcraft or a different project? | 18:08 |
| gsilvapt | kyrofa, it worked.Thank you! | 18:09 |
| kyrofa | Awesome! | 18:09 |
| gsilvapt | part of snapcraft, under cli | 18:09 |
| gsilvapt | Did not know we had to import things and tell cli which to consider. Makes sense though! | 18:09 |
| kennyloggins | elopio: What channel is this on, again in #freenode ? https://twitter.com/d3fc0n3/status/932649813090369536 | 18:12 |
| magicaltrout | kyrofa: niemeyer whats the snap upload limit? | 18:13 |
| kyrofa | magicaltrout, I don't know that there is one | 18:14 |
| magicaltrout | well i get internal server error and proxy error on snap push | 18:14 |
| magicaltrout | which is reminicent of the juju resource upload issue | 18:14 |
| magicaltrout | https://gist.github.com/buggtb/2a5ebbb7f779a1e35a6329306c85c18c | 18:16 |
| elopio | kennyloggins: there are many ubuntu channels, it depends on who you want to thank :) | 18:16 |
| gsilvapt | kalikiana, any suggestion? I want to understand your point before submitting the push and the consequent PR | 18:16 |
| kennyloggins | elopio, I just thought it was an ubuntu - with a rallying point, my mistake (again). | 18:17 |
| kennyloggins | **ubuntu-day | 18:17 |
| elopio | kennyloggins: the rallying point is the hub, https://ubu.one/ucaday | 18:17 |
| kalikiana | gsilvapt: Right. So what I'm saying is, the code will only be executed if snapcraft is installed, or you run it from git - so you don't need to handle the case where the import fails, because other code makes sure it works | 18:25 |
| gsilvapt | kalikiana, so I should remove the try and except bit and just leave the command? | 18:26 |
| kalikiana | gsilvapt: Yup | 18:27 |
| gsilvapt | Ok, I will submit the push + PR now | 18:27 |
| gsilvapt | Thank you, kalikiana and kyrofa | 18:27 |
| niemeyer | magicaltrout: That's a pretty big snap indeed.. I suggest asking in the forum about what the limit is | 18:28 |
| niemeyer | magicaltrout: #store category | 18:28 |
| magicaltrout | thanks | 18:28 |
| gsilvapt | Well, now comes the tricky part. I also included a test but should I run something else aside from this, kyrofa? | 18:29 |
| kyrofa | gsilvapt, I suppose that depends on the test you wrote. Can I see it? | 18:30 |
| gsilvapt | Basically, it is a repetition of the one already there for --version. As mentioned in LP it should return the same. | 18:31 |
| gsilvapt | But, here's a gist: https://gist.github.com/gsilvapt/41de75a1a920e0ec93163091f1960a05 | 18:31 |
| kyrofa | elopio, can I get a review on snapraft#1743 when you're able? | 18:31 |
| kyrofa | Uh. snapcraft#1743 | 18:32 |
| mup | PR snapcraft#1743: catkin plugin: support building entire workspace <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1743> | 18:32 |
| kyrofa | gsilvapt, no need to print. That seems fine to me | 18:32 |
| kyrofa | gsilvapt, propose it! | 18:32 |
| gsilvapt | Thank you! | 18:32 |
| kyrofa | gsilvapt, you'll get more feedback in the pull request | 18:33 |
| gsilvapt | Yes, I'm expecting that. Hopefully nothing too diminishing, hehe :-) | 18:33 |
| gsilvapt | Is there a way to check if I've signed the CLA? I'm pretty sure I did but I want to check first | 18:34 |
| kyrofa | gsilvapt, make sure the commit message looks like this: https://pastebin.ubuntu.com/26007003/ | 18:34 |
| kyrofa | gsilvapt, make a PR and it'll check to ensure you've signed | 18:35 |
| kyrofa | Assuming the email address under which you're committing is also in your LP account | 18:35 |
| pstolowski | niemeyer, ha, so the fix we discussed is correct and we have 2 test checks in snapstate_test built around wrong assumption ;). PR is coming | 18:35 |
| gsilvapt | Right, thank you remembering that kyrofa | 18:37 |
| mup | PR snapcraft#1746 opened: Implemented method to get snapcraft version <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746> | 18:37 |
| kalikiana | gsilvapt: I added a comment on the test - instead of the print I think it'd be better to compare the value to the expected version with Equals or Contains | 18:45 |
| gsilvapt | Bah, I'm an idiot. That was not suppose to be there -.- | 18:46 |
| gsilvapt | Thank you for letting me know. Lets see if I don't screw this up while trying to squash commits | 18:46 |
| zyga-ubuntu | drat | 18:47 |
| mup | PR snapd#4259 opened: snapd: fix handling of undo in the taskrunner <Created by stolowski> <https://github.com/snapcore/snapd/pull/4259> | 18:47 |
| pstolowski | niemeyer, ^ | 18:47 |
| gsilvapt | kalikiana, you prefer your method instead of just assertThat()? | 18:49 |
| gsilvapt | The print statement is obviously a mistake. On Saturday night I was working on this and the exit_code = 2 was driving me nuts. This was a desperate attempt to try to see what value the method was returning | 18:49 |
| gsilvapt | how do you squash commits though? Rebase? | 18:54 |
| * zyga-ubuntu considers EODing | 18:55 | |
| mup | PR snapd#4258 closed: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258> | 18:56 |
| zyga-ubuntu | jdstrand: I closed 4258 as it doesn't seem to work in linode, I need to look at that (doing so now) but it's not worth reviewing until I do | 18:58 |
| kyrofa | zyga-ubuntu, how sad | 18:59 |
| kyrofa | gsilvapt, yeah, run `git fetch` and then run `git rebase -i origin/master` | 19:00 |
| kyrofa | Assuming `origin` is the remote name for upstream | 19:00 |
| gsilvapt | kyrofa, so do changes, add/commit, fetch, rebase and force push to my repo? | 19:00 |
| gsilvapt | I think I have to do force push after rebase, not sure | 19:00 |
| kyrofa | gsilvapt, assuming you've already pushed, yes, you'll need to force | 19:01 |
| gsilvapt | What do you mean assuming I have pushed? | 19:01 |
| kyrofa | gsilvapt, if you haven't pushed, then you don't need to force in order to push | 19:01 |
| kyrofa | (since there's nothing up there for it to conflict with | 19:01 |
| gsilvapt | Ok, let me give that a try | 19:01 |
| kyrofa | ) | 19:01 |
| gsilvapt | kyrofa, I think I have to force because it now says by branch is behind its remote counterpart | 19:04 |
| kyrofa | gsilvapt, which means you pushed it | 19:04 |
| kyrofa | So yes, you need to force | 19:04 |
| gsilvapt | No, I was holding for instructions | 19:04 |
| gsilvapt | I pushed before when I wanted to submit the PR, not after | 19:05 |
| gsilvapt | Well, it worked I think | 19:06 |
| jdstrand | zyga-ubuntu: I provided some feedback | 19:07 |
| zyga-ubuntu | jdstrand: thank you | 19:20 |
| gsilvapt | kyrofa, one question: Can you help me understand this? https://travis-ci.org/snapcore/snapcraft/builds/304902240?utm_source=github_status&utm_medium=notification | 19:21 |
| gsilvapt | I know what CI is but I never worked with it more closely | 19:22 |
| zyga-ubuntu | jdstrand: I replied on some of the feedback, thank you for looking | 19:24 |
| zyga-ubuntu | jdstrand: the problem is that snapd is too late and cannot be the one fixing this, it must be genuinely something in the distro package | 19:24 |
| zyga-ubuntu | jdstrand: (or snapd before reexec, perhaps) | 19:24 |
| zyga-ubuntu | jdstrand: but really it must happen before apps start running | 19:24 |
| kyrofa | gsilvapt, yeah, you need to run ./runtests.sh static | 19:25 |
| gsilvapt | but I did :o | 19:25 |
| zyga-ubuntu | jdstrand: I tried several other approaches, including a .mount unit (so that systemd would do it) but systmed is insufficient | 19:25 |
| kyrofa | gsilvapt, take a look: https://travis-ci.org/snapcore/snapcraft/jobs/304902243#L1094 | 19:25 |
| gsilvapt | Hum, weird. Lets give that another look | 19:26 |
| zyga-ubuntu | jdstrand: ideas (any, I will gladly investigate their viabilty are welcome) | 19:26 |
| gsilvapt | Thanks kyrofa | 19:27 |
| kyrofa | elopio, where is the bot? | 19:27 |
| kyrofa | elopio, I can't run adt | 19:27 |
| gsilvapt | kyrofa, is it possible to run Travis for every commit pushed to a given repo? This is not entirely related with Travis but a personal curiosity | 19:40 |
| kyrofa | gsilvapt, yes | 19:40 |
| gsilvapt | Without needing PRs, I meant | 19:40 |
| kyrofa | gsilvapt, right, still yes :) | 19:41 |
| gsilvapt | Ok, thank you :) | 19:42 |
| jdstrand | zyga-ubuntu: I gave several ideas to look into with: https://github.com/snapcore/snapd/pull/4258#pullrequestreview-77885255 | 19:42 |
| mup | PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258> | 19:42 |
| jdstrand | zyga-ubuntu: the thrust of each idea is that snapd in lxd can detect if it is running in a container and do something. what that something is needs investigating. maybe it creates different .mount files for the snaps. maybe different .service files. maybe it performs an operation on /, maybe something else | 19:43 |
| elopio | kyrofa: ^ | 21:30 |
| zyga-ubuntu | jdstrand: if we can start from clean slate then we might do something else | 21:34 |
| zyga-ubuntu | jdstrand: iff we can have control before snap units are mounted, we can do one operation (bind mount /snap over) | 21:34 |
| zyga-ubuntu | jdstrand: I did succeed in doing that with a mount unit but it was _not_ rshared at that stage | 21:34 |
| zyga-ubuntu | jdstrand: but systemd cannot both bind mount and rshare | 21:35 |
| zyga-ubuntu | jdstrand: perhaps my earlier approach, with a /snap mount unit (just bind mount) and snap-confine that just does equivalent of mount --make-rshared /snap will do | 21:35 |
| zyga-ubuntu | jdstrand: the key is that we must do this before 1st snap runs and unshares a mount namespace | 21:35 |
| zyga-ubuntu | jdstrand: think about this and let me know, I'll iterate tomorrow | 21:36 |
| jdstrand | zyga-ubuntu: that is what I was thinking. this is all within lxd, no? if so, you have to run the snap command to install anything, therefore, you have an opportunity to do what you need. rather than make systemd do bind mount with rshared, just have a teensy tiny helper that does that, put that in a service file that you conditionally use if in a container | 21:45 |
| zyga-ubuntu | jdstrand: this also affects 14.04 | 21:45 |
| jdstrand | the helper could be in the upstart job or whatever too | 21:45 |
| zyga-ubuntu | jdstrand: we have that helper but it's not working | 21:45 |
| zyga-ubuntu | jdstrand: because it runs after snap units are mounted | 21:46 |
| zyga-ubuntu | jdstrand: and then there are two entries | 21:46 |
| zyga-ubuntu | jdstrand: and that causes the bug | 21:46 |
| zyga-ubuntu | jdstrand: one before bind+rshare, one after | 21:46 |
| zyga-ubuntu | jdstrand: this also confuses systemd so stopping mount units doesn't work | 21:46 |
| zyga-ubuntu | (it hangs) | 21:46 |
| jdstrand | I don't claim to have all the details, but in my head: sudo snap install foo -> am I in a container? -> yes, add unit file with helper to bind/rshared /snap -> start unit -> proceed with install | 21:47 |
| zyga-ubuntu | jdstrand: but I think the approach can be made to work with a combination of mount units (those have dependencies so we could get correct ordering) and a bit of code in snap-confine (easy guarantee to run before we construct snap namespace) | 21:47 |
| jdstrand | there are certainly details to be worked through | 21:47 |
| zyga-ubuntu | jdstrand: that won't work after reboot | 21:47 |
| jdstrand | you can make it work | 21:47 |
| zyga-ubuntu | jdstrand: again, the order of mount operations (either via systemd or helpers) is crucial | 21:47 |
| zyga-ubuntu | jdstrand: but yes, the /snap mount unit is a trick we should use here | 21:48 |
| jdstrand | make that service file a noop for the default case and all mount units start after it. if in container, then tweak the unit to run the helper | 21:48 |
| zyga-ubuntu | jdstrand: then we need to tweak all mount units to have before/after stanazas to order themselves | 21:48 |
| jdstrand | or similar | 21:48 |
| zyga-ubuntu | jdstrand: I think it's all solvable | 21:49 |
| jdstrand | we are the ones writing the mount units, no? | 21:49 |
| jdstrand | I see, yes | 21:49 |
| jdstrand | you were saying what needs to be done, not objecting | 21:49 |
| zyga-ubuntu | jdstrand: yes but curretly snapd has no facility to correct the mount units (we have another bug pending on tihs) | 21:49 |
| zyga-ubuntu | jdstrand: again, I agree, it's just steps to get there | 21:49 |
| jdstrand | 2 bug fixes for the price of one! :) | 21:49 |
| zyga-ubuntu | jdstrand: and some bugs in systemd that cause this to be harder than it has ot | 21:50 |
| zyga-ubuntu | *to | 21:50 |
| zyga-ubuntu | jdstrand: (the other bug is 14.04 mount ordering) | 21:50 |
| zyga-ubuntu | jdstrand: offtopic, did you have a chance to look at the two PRs for snap-update-ns? | 21:51 |
| jdstrand | zyga-ubuntu: I'm looking at 4170 now. I already gave a quick comment you may want to consider | 21:52 |
| zyga-ubuntu | looking | 21:52 |
| zyga-ubuntu | man, that PR will never land | 21:52 |
| zyga-ubuntu | I restarted tests >> 20 times on it | 21:53 |
| zyga-ubuntu | something always fails | 21:53 |
| zyga-ubuntu | store hicckup, some racy test here or there :// | 21:53 |
| jdstrand | zyga-ubuntu: the good thing is that when it does, no other PR will land :P | 21:53 |
| jdstrand | *sigh* | 21:53 |
| jdstrand | I had a racy test that had a similar issue | 21:53 |
| jdstrand | so I feel your pain | 21:54 |
| zyga-ubuntu | jdstrand: master is super super unreliable recently | 21:54 |
| * jdstrand nods | 21:54 | |
| zyga-ubuntu | jdstrand: and we are playing the game of "flip a coin N times, ensuring it's heads each time" while incrementing N | 21:54 |
| zyga-ubuntu | jdstrand: so I maybe agree if your proposal is undo-safe | 21:55 |
| zyga-ubuntu | jdstrand: note that we may be asked to completely undo any of this | 21:56 |
| zyga-ubuntu | jdstrand: and that the typical situation, nothing is hidden under the tmpfs mount | 21:56 |
| gsilvapt | kyrofa, I saw your comment. I'll try to see what can I do. I already did a test that checks if both commands' outputs are the same. Now I have to see what you meant with duplicating click's template | 21:56 |
| zyga-ubuntu | jdstrand: (apart from a fragment of a squashfs mount) | 21:56 |
| zyga-ubuntu | jdstrand: the simple approach I took guarantees (I hope, prove me wrong please) that I can always undo | 21:56 |
| zyga-ubuntu | jdstrand: and create another layout | 21:56 |
| jdstrand | zyga-ubuntu: that might be a case for needing the contents of the mounted over directory | 21:58 |
| kyrofa | gsilvapt, just run `snapcraft --version` and compare the output to `snapcraft version` and you'll see what I mean | 21:58 |
| kyrofa | gsilvapt, what timezone are you in, by the way? | 21:58 |
| zyga-ubuntu | jdstrand: I also toyed with one more ideqa | 22:00 |
| zyga-ubuntu | *idea | 22:00 |
| zyga-ubuntu | jdstrand: iff it's a good assumption that we can look at hostfs, we can fish the snap mounts there | 22:00 |
| zyga-ubuntu | jdstrand: but it's not generic as the same code should be useful for poking holes in various places that are not just /snap | 22:00 |
| zyga-ubuntu | jdstrand: and while it's possible to find the same place in hostfs it may have been changed by the hardcoded mount commands in snap-confine | 22:01 |
| gsilvapt | kyrofa, GMT | 22:06 |
| gsilvapt | kyrofa, I have to learn how to setup a testing environment for this. The last time I tried I ended up deleting most stuff andsuch | 22:07 |
| gsilvapt | I understand the outputs are different, the test is being rejected currently. I just am not too comfortable with Click yet :P | 22:07 |
| kyrofa | gsilvapt, yeah you don't need to change click, just `click.echo` something that makes the `version` command echo the same thing as what you see `--version` doing | 22:12 |
| gsilvapt | kyrofa, this might take too much time. I'm having issues with python and pip again... | 22:42 |
| kyrofa | gsilvapt, what's up? | 22:42 |
| gsilvapt | I can't use pip3 and I only want to use python3 | 22:43 |
| gsilvapt | Every command I run using pip3 gives a common _NameSpace Attribute Error which was previously solved by updating setuptools, wheel and/or pip. None of those work | 22:43 |
| kyrofa | Ouch | 22:44 |
| gsilvapt | I messed this up badly. And this is something I can't just uninstall and reinstall | 22:46 |
| zyga-ubu1tu | jdstrand: I was thinking about the writable aspect of the mimic, perhaps we should actually bind mount without "ro" | 22:48 |
| zyga-ubu1tu | if the substrate is read only, it doesn't change anything | 22:48 |
| zyga-ubu1tu | if for whatever reason it is not, we should mount as writable | 22:48 |
| zyga-ubu1tu | as for rbind vs bind, if we rbind we must understand what we did or we cannot undo this | 22:49 |
| zyga-ubu1tu | so that feels like "bind now, rbind and be smarter about undo later" | 22:49 |
| jdstrand | zyga-ubu1tu: that works for me (both) | 22:49 |
| jdstrand | just update the comment on rbind to not be a question and be either a TODO or Note | 22:50 |
| jdstrand | zyga-ubu1tu: if you make non-comment changes, happy to review tomorrow | 22:51 |
| zyga-ubu1tu | yes, I'll make all the changes and iterate, thank you for the insight! | 22:51 |
| jdstrand | thanks for the PR :) | 22:51 |
| zyga-ubu1tu | jdstrand: btw, one more thing to think about -- once we do full layouts I only expect to tweak confinement (allow more things) and add blacklists (to prevent known unsafe ops), I hope nothing else has to change (in a major way) | 22:53 |
| jdstrand | that's going to be the tricky part | 22:54 |
| zyga-ubu1tu | jdstrand: I think the trick (ha) is the tmp bind mount | 22:54 |
| jdstrand | making sure we don't accidentally allow /etc/shadow into the app's area | 22:54 |
| gsilvapt | kyrofa, regarding the feature, could you tell me some pointers I could look at? While this thing updates and reinstalls stuff, I'm trying to figure out a solution but I confess I am not seeing where the return string is built | 22:55 |
| jdstrand | I'm not sure a blacklist is the way to go, but also don't know what you are thinking about. we can discuss that in the PR | 22:55 |
| zyga-ubu1tu | jdstrand: yes, we need deny rules in the profile, deny mounts for /etc and /{run/}media, for special places /{proc,sys,dev} | 22:55 |
| kyrofa | gsilvapt, did you run `snapcraft --version`? | 22:55 |
| zyga-ubu1tu | jdstrand: ok | 22:55 |
| gsilvapt | yes | 22:55 |
| kyrofa | gsilvapt, what was its output? | 22:58 |
| gsilvapt | snapcraft, version *** | 23:00 |
| gsilvapt | in this case, 2.35 | 23:01 |
| kyrofa | gsilvapt, and `snapcraft version` prints what? | 23:01 |
| gsilvapt | 2.35 | 23:01 |
| mup | PR snapd#4260 opened: Stop various JSON field from being sent with null values <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4260> | 23:36 |
| mup | PR snapd#4257 closed: interfaces/opengl: also allow read on 'revision' in /sys/devices/pci <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4257> | 23:48 |
| kyrofa | gsilvapt, so instead of making `snapcraft version` print just the number, make it print "snapcraft, version 2.35" | 23:49 |
| gsilvapt | kyrofa, guide me on this one: How do I compile snapcraft 2.35? | 23:51 |
| gsilvapt | I'm going around in circles here. I've tried branching to 2.35 and then running the requirement install phase but always get this Can't install 'snapcraft'. No files were found to uninstall. error | 23:52 |
| gsilvapt | Note: pip, wheels, setuptools and virtualenv are up-to-date | 23:53 |
| gsilvapt | kyrofa, it seems that running pip install wheel and python setup.py bdist-wheel has solved the issue | 23:56 |
| gsilvapt | Or not. Can't compile Snapcraft: https://pastebin.com/HgjMwDSx | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!