[00:41] TingPing, you might want to try with the 2.31.1 snapd [00:41] it is in testing for Fedora [00:41] https://bodhi.fedoraproject.org/updates/?packages=snapd [00:41] Son_Goku, i tested on ubuntu 16.04, which honestly is the only version i particularly care about [00:42] ah [00:42] I thought you were a Fedora user... [00:42] i am [00:42] apologies for assuming [00:43] snapd in Ubuntu 16.04 has had a tumultuous time getting updated [00:44] so they've been lagging behind Fedora on updates [01:05] funny [01:06] well, I try to keep things fresh ;) [01:07] Fedora also beat Ubuntu to getting an updated Mir, too ;) [01:07] despite all the issues caused by gcc8 [01:07] and fweimer's change to the distro compiler flags [01:07] sounds masochistic [01:08] while i'm here are there any download "badges" for snap? [01:08] badges? [01:08] what do you mean? [01:08] like a standardize logo to indicate a snap download [01:08] ah [01:09] you mean like the things Apple/Google do? [01:09] yea [01:10] yeah [01:10] there's a "snap|built and released" button [01:10] you can get it through build.snapcraft.io when you connect your GitHub account to the build system [01:11] but a regular button? I don't think so [01:11] an example badge: https://github.com/snapcrafters/atom/blob/master/README.md [01:11] * TingPing is working on this https://i.imgur.com/XP2i53v.png [01:12] snaps have an official logo [01:12] and generally speaking, the usage of the ubuntu logo isn't permitted in association with snaps, jfyi [01:13] link to their logo? [01:14] TingPing, yep, trying to find it [01:14] one sec [01:15] TingPing: https://assets.ubuntu.com/v1/d24ea71e-10.+SNAPCRAFT_LOGO_AW.zip [01:16] you'll want {PNG,SVG}_stacked/snapcraft_green-red_st_hex.{png,svg} [01:16] hmm [01:16] TIL that cloud-init has a logo [01:18] bit annoyingly sized [05:46] morning [06:31] * mborzecki is afk for ~1h === akash_ is now known as akash === oh4__ is now known as oh4_ === davdunc_ is now known as davdunc === lfaraone_ is now known as lfaraone === doko_ is now known as doko [07:18] good morning [07:38] aand i'm back [07:38] zyga-ubuntu: morning [07:38] hey [07:38] it's good to be home :-) [07:38] yay ;) [07:41] hey zyga-ubuntu and mborzecki ! [07:41] hey mvo! :) [07:41] mvo: hey [07:43] * zyga-ubuntu updates his fedora system [07:44] zyga-ubuntu: some intersting fedora work coming up? [07:47] I wanted to fix a build issue on newer gcc's [07:47] and since I have ubuntu on my laptop now I could play on fedora on my desktop for some time [07:56] zyga-ubuntu: what build issue on newer gcc? i have 7.3 here and rebuilt the package yesterday [07:56] I don't remember; Neal said there are some issues [07:56] I just rebooted and I'll make a rawhide chroot [07:58] zyga-ubuntu: maybe that's the media-sharing interace thing? [07:59] zyga-ubuntu: /media vs /run/media [07:59] I'll find out soon [07:59] that one was supported for long time now [07:59] but maybe it regressed [08:00] zyga-ubuntu: ok, ping me if you need help [08:01] hah, had to do blood tests in the morning, now i can make up for the lost blood with some chocolate :P [08:07] yum yum === pstolowski|afk is now known as pstolowski [08:11] morning! [08:13] hey pstolowski ! good morning [08:20] pstolowski: hey [08:27] mvo: hey, did you try the tea by any chance? :-) [08:28] hello everyone! I am not a linux expert and I have a question. Can I turn any program into a snap package if I can get its source code? I was thinking about virtualbox. [08:28] the official tutorial looks quite easy [08:28] user9445: hey, [08:29] user9445: virtual box may be a bit harder to snap unless you want to make the kernel modules optional [08:29] user9445: but in general, with enough persistence, yes you can snap anything, it's just a format for packaging [08:29] mborzecki: do you know how to get a fedora chroot? [08:30] I'd rather have a chroot with rawhide than a VM with one [08:31] systemd-nspawn is probably the easiest way, but you'll probably need dnf to install everything, maybe they still publis the raw rootfs images, so this might be a second way to try [08:32] oh, I didn't think about that [08:32] the host if F27 [08:32] zyga-ubuntu: yeah, its interessting. pretty strong flavor, not what I am used to but I will drink it a bit and see if it clicks :) [08:32] zyga-ubuntu: https://download.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz raw image [08:32] zyga-ubuntu: I will definitely get you some for the next sprint as well :) [08:33] mvo: not sure how many leaves did you use, I usually use a few for a sizable mug (~1L) [08:40] o/ [08:47] how was your travel back home guys? [08:47] pstolowski: short :P [08:49] pstolowski: and we got a chance to do some sightseeing on Saturday morning (at least me, zyga-ubuntu and koza, the rest were leaving earlier) [08:52] zyga-ubuntu: ok, I try a smaller one then :) [08:54] mborzecki: nice! [08:56] mvo: zyga-ubuntu: any idea about https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04/4440 ? [09:05] morphis: ah, interesting [09:05] I will respond on the forum [09:08] morphis: done [09:09] zyga-ubuntu: thanks! === __chip__ is now known as Chipaca [09:21] moin moin [09:22] mborzecki: would you mind doing the fuzzing thing again on the puritan pr? [09:22] mborzecki: I lopped a bunch of checks off [09:22] which should be fine, given they were unreachable :-) [09:23] Chipaca: ok, will try in a couple of minutes [09:23] mborzecki: thanks! [09:30] Chipaca: hey, good morning! do you think 4805 can be merged? or because of it being api we need a gustavo review? [09:30] mvo: I don't think rob addressed my concerns [09:30] let me check [09:32] mvo: "the correct behaviour is if the field is omitted to assume that classic is supported." <- that's not what we do for eveyr other boolean [09:32] Chipaca: please mark as "request change" then, just to ensure it does not get merged accidently [09:34] mvo: is https://github.com/pilebones/go-udev the udev implementation you found last week? [09:35] pstolowski: yes [09:35] PR snapd#4811 opened: tests/main/media-sharing: improve the test to cover /media and /run/media [09:35] nice & easy PR ^^ [09:42] mborzecki: commented [09:44] hey Chipaca! [09:45] pstolowski: hi! [09:45] pstolowski: cmd/snap-confine/spread-tests/main/media-visible-in-devmode this test? [09:45] mborzecki: yes [09:46] pstolowski: i don't think these are run at all [09:46] mborzecki: nb I misread the systems clause there, it's run everywhere but debian it seems; what makes you think it's not executed? [09:50] pstolowski: cmd/snap-confine/spread-tests is not referenced in the top level spread test file [09:53] mborzecki: it's not used [09:53] man, we should drop most of those tetsts [09:53] those are from when snap-confine was in a separate repository by itself [09:53] mborzecki: it's left there by zyga to catch the unwary [09:53] mborzecki: allright [09:54] +1 [09:54] haha, are those kept for reference or shall we make them go away then? :) [09:55] one by one either enable and port or drop [09:58] zyga-ubuntu: every seen this? [09:58] execl failed: Permission denied [09:58] child exited with status 1: File exists [09:58] zyga-ubuntu: https://api.travis-ci.org/v3/job/352240343/log.txt [09:59] Chipaca: yes, on Friday [09:59] is this against master or release? [09:59] zyga-ubuntu: master [09:59] hmmm [09:59] zyga-ubuntu: not a new master though, it's probably a few commits behind [10:00] perfect, 14.04, no logs [10:01] so what we saw in the release branch on Friday is that apparently something mixes old profile and new profile on disk [10:01] zyga-ubuntu: can you remind me again why 2.32 is broken and also why it seems not to be broken when I run an isolated 2.32 test in qemu? [10:01] great question mvo, still investigating that [10:02] so I don't really know yet [10:02] zyga-ubuntu: aha, great. can you reproduce it somehow? [10:02] yes [10:02] zyga-ubuntu: how? [10:02] I mean, I just ran it in qemu [10:02] was I just lucky? [10:02] zyga-ubuntu: I don't know :) did you run just a single failing test or the full ting? I just did the former and do the later now [10:03] I ran tests/main [10:04] my goals today are to fix that, fix the bug that manifests itself as /etc and get back to the bigger bug of /etc being writable [10:05] zyga-ubuntu: ok [10:05] zyga-ubuntu: should I just restart this particular test? [10:06] hmm hmm [10:06] there's nothing in the debug log there [10:06] yeah, restart it for now [10:06] I need to get this under control [10:18] Chipaca: got some panics [10:18] mborzecki: woo [10:18] mborzecki: show me :-) [10:18] Chipaca: i can let it run for a bit and then upload the corpus [10:19] mborzecki: ok [10:22] zyga-ubuntu: as a data point - tests seem to be ok if run in isolation so something is bleeding into it [10:22] yeah, I'm mid way and nothing failed now [10:23] :-( [10:23] Chipaca: https://paste.ubuntu.com/p/v45xJKWvSY/ [10:23] do you have the seed with a failure by any chance? [10:26] mborzecki: one of the errors in 4811 looks real [10:26] mborzecki: can i see the fuzz function? [10:26] mborzecki: (i suspect you're calling marshal directly :-) ) [10:27] Chipaca: yes i do [10:27] *unmarshal [10:27] zyga-ubuntu: maybe, let me try [10:27] mborzecki: ah, yes that won't work, now -- it's called on things that json already knows is valid json [10:27] mvo: I'm looping through this on my laptop [10:27] it did fail on Friday [10:28] zyga-ubuntu: 1520606008 is what travis was using [10:28] thanks, I will try that with another backend [10:29] not sure if this is reliable [10:29] Chipaca: https://paste.ubuntu.com/p/ngFTQqvD4Y/ corpus https://send.firefox.com/download/d3fc9b236a/#CmR2CZR9_Ej7kx3qLjX_JQ [10:31] mborzecki: ah! hm! oh! [10:32] mborzecki: thanks [10:32] Chipaca: that's the tool(ing) https://github.com/dvyukov/go-fuzz [10:34] mborzecki: so maybe I should put those checks back in; the bad data needs to be fed to UnmarshalJSON directly, but that's a public function so why wouldn't it [10:34] * Chipaca feels dumber and wiser at the same time [10:36] haha :) anyways, the fuzzer is a nice thing to play with [10:36] mborzecki: on the next run I got two of them: https://api.travis-ci.org/v3/job/352240343/log.txt [10:36] um [10:37] zyga-ubuntu: you ^ [10:37] zyga-ubuntu: one on 16.04 [10:37] wow [10:37] that's master + stuff right? [10:37] hm device cgroups stopped working or what? [10:38] zyga-ubuntu: master up to 275d1cac4a774fe784f764c0788a689e60cc9d0a [10:38] man [10:38] zyga-ubuntu: then it's jsonutil/puritan and using it from store; at the opposite end from cgroups :-) [10:38] this might be a race, I saw those failing sometimes (just saying) [10:38] it would be way better if spread would say which machine is running a given test [10:39] to show a trace of failure on a given machine [10:39] (I mean, we need to look into this but I wonder if its consistent) [10:39] reproducing this takes tons of time :/ [10:39] catching --strace='--raw' would be useful [10:40] I mean [10:40] I know what happens [10:40] not sure why it happens [10:40] what happens is that snap-confine doesn't have permission to run snap-update-ns [10:41] zyga-ubuntu: shouldn't the denial be logged? [10:41] yes [10:41] it should [10:41] and it's not [10:51] * Chipaca -> physio gym thing [10:52] mvo: i'll into tests/main/snap-service-refresh-mode as it's still failing randomly [10:52] look into === pstolowski is now known as pstolowski|lunch [10:57] * Chipaca -> really leaves [10:59] mborzecki: \o/ thank you [10:59] mborzecki: maybe its a real issue :( [11:00] (even though its hard for me to see from the code how this could be) [11:02] zyga-ubuntu: slightly frustrating, I have no luck reproducing the 2.32 failure in qemu so far, I did two runs, one with random seed and one with seed from a failing PR against qemu:ubuntu-16.04-64 but no failures so far (and almost finished) [11:03] could it be, perhaps, caused, by any changes in core that landed since? [11:03] * zyga-ubuntu looks at the logic in prepare code [11:03] #4789 needs a 2nd review [11:03] for me it's not failing anymore either [11:03] PR #4789: many: support holding refreshes by setting refresh.hold [11:08] mvo: are you running all of it or just some [11:08] maybe the update test leaks something into the system? [11:08] all of main [11:09] mvo, hey [11:09] cachio: hey [11:09] cachio: hope you are well! === BlackDex_ is now known as BlackDex [11:33] zyga-ubuntu: *cough* 2.32 is green again [11:33] :/ yeah same here [11:33] it's driving me nuts [11:33] so what changed since friday [11:34] is it just bad luck [11:34] what's the real problem we're not seeing [11:34] zyga-ubuntu: also green in travis [11:34] 1st world problems, tests are green but WHY :) [11:36] zyga-ubuntu: indeed, very peculiar [11:37] ok, I'll keep running and look at our prepare/restore code [11:37] and maybe, just maybe, something will come up [11:40] how come there's no shellcheck snap yet [11:58] mvo: I found a small bug in spread.yaml [11:58] mvo: the tests/completion suite's restore code doesn't remove snap-confine [11:58] it's not a big deal (maybe) [11:59] I've patched it locally now [11:59] snap-confine is supposed to be just transitional now [11:59] zyga-ubuntu: ta [11:59] PR snapd#4639 closed: store: enable deltas for core devices too [12:00] same with the regression suite [12:00] mvo: I just got a failure on the 2.32 branch [12:01] [Mon Mar 12 12:57:05 2018] audit: type=1400 audit(1520855826.802:795346): apparmor="DENIED" operation="exec" profile="/snap/core/4224/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=31151 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 [12:01] I have a debug shell [12:01] zyga-ubuntu: what test is that? [12:02] https://www.irccloud.com/pastebin/47FjVl3F/ [12:02] security-device-cgroups [12:02] with the uinput sub-test [12:02] the previous one was validate-container [12:02] this is on a single-machine qemu [12:03] zyga-ubuntu: thanks, looking [12:03] the profile on disk is: http://paste.ubuntu.com/p/BNBk4526cC/ [12:03] this is /etc/apparmor.d/snap.core.4224.usr.lib.snapd.snap-confine [12:04] there is no snap-device-helper here [12:04] zyga-ubuntu: hm, yeah [12:04] looking at the core snap [12:04] maybe the core snap got repackaged [12:04] with some broken stuff inside [12:05] zyga-ubuntu: oh, I think this is the snapd that uses the symlink, so looks like one more thing to cherry pick [12:05] this is the profile in the core snap there: http://paste.ubuntu.com/p/tcQ42chRQK/ [12:05] /usr/lib/snapd/snap-device-helper ixr, # drop [12:05] it _has_ permission to run this [12:06] so this is clearly broken [12:06] * zyga-ubuntu diffs the two files [12:06] zyga-ubuntu: meh, how can this happen? this looks like test prepare is broken [12:06] https://www.irccloud.com/pastebin/KmbgETkf/ [12:07] hum [12:07] this makes no sense [12:07] - /usr/lib/snapd/snap-device-helper ixr, # drop [12:07] + /lib/udev/snappy-app-dev ixr, # drop [12:08] how did we go from - snap-device-helper (from the core snap) to + snappy-app-dev from the apparmor.d dir? [12:08] * zyga-ubuntu looks at the preserved test tarball helper thing [12:08] mvo: I bet you this will show the prepare/restore is wrong [12:08] zyga-ubuntu: yeah, I need to get lunch now, biab [12:10] zyga-ubuntu: are you running just this test or the whole bunch? [12:10] mvo: confirmed, the tarball has junk inside [12:10] mborzecki: all of main each time [12:11] let me give you the seed [12:11] this is on top of release/2.32 [12:11] zyga@t470:~/snapd$ spread -debug -v qemu:ubuntu-16.04-64:tests/main/ [12:11] 2018-03-12 12:07:55 Found /home/zyga/snapd/spread.yaml. [12:11] 2018-03-12 12:07:58 Project content is packed for delivery (3.88MB). [12:11] 2018-03-12 12:07:58 Sequence of jobs produced with -seed=1520852878 [12:11] mborzecki: can you please run that and see if you get the exact same bug? [12:11] I will look at why this happens [12:11] I have an idea now [12:11] and man [12:13] mborzecki: I can send you my spread binary if that is a factor [12:18] 2018-03-12 12:16:21 Preparing qemu:ubuntu-16.04-64:tests/main/interfaces-many... [12:18] # ls -ld $SPREAD_PATH/snapd-state.tar.gz [12:18] -rw-r--r-- 1 root root 366991360 Mar 12 12:16 /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz [12:18] so at around the time when we ran interfaces-many test, the state tarball was made [12:18] and it wasn't touched since [12:18] and it contains _wrong_ code [12:19] as in, it captures a state that is wrong [12:19] and much much later [12:19] 2018-03-12 12:57:06 Error executing qemu:ubuntu-16.04-64:tests/main/security-device-cgroups:uinput : [12:19] this test failed because of that [12:20] that test doesn't fiddle with snapd [12:20] now [12:20] we have code that detects this and writes a correct profile [12:21] but when I inspected the system it wasn't apparent it ran === pstolowski|lunch is now known as pstolowski [12:22] aha [12:22] but this code only runs when we install core [12:22] and if none of the preceeding tests tired to run snap-devce-helper / snappy-app-whatever it was [12:22] it would not trigger [12:23] mvo: so we still have an issue that may need addressing [12:23] apart from 1) how did we get there we have the problem that on startup we 2) may run with stale profile for snap-confine because it is only remade when we install "core" [12:26] I also looked at the backend initialize function and I doubt it is loading the stale profile because it would only do so on system-key like events (nfs or overlay) [12:26] the system-key file also looks sensible [12:27] I added some debug and I will try to reproduce that with the same seed ( -seed=1520852878) [12:29] mvo: one thing that _may_ be related is that /var/cache/apparmor is full of things [12:31] as is /etc/apparmor.d/cache [12:31] the biggest question is if the seed will reproduce the issue [12:32] niemeyer, hey, when you have a time [12:32] https://github.com/snapcore/spread/pull/52 [12:32] PR spread#52: Add storage option for google [12:33] that shoul fix the issue that savic was reporting about out of space [12:33] tx [12:46] PR snapd#4812 opened: tests/main/snap-service-refresh-mode: refactor the test to rely on comparing PIDs [12:48] so, I wonder about an idea [12:48] let's say I get a failure again, and that -seed works [12:48] how can we make spread bisect the test suite to find what breaks [12:49] that is, run the failing test after running half of the preceding tests, etc [12:54] mvo, niemeyer I am waiting for a doctor at home, perhaps I'll be starting later the standup [13:19] excellent, I can reproduce the issue reliably now mvo [13:25] zyga-ubuntu: my test run is still in progress, should i abort? [13:25] no sure, why? [13:26] zyga-ubuntu: thought that maybe reuse the seed, and only use those 2 tests that you mentioned [13:26] aga [13:26] aha [13:26] well, which test are you on now? [13:26] * kalikiana will go try and have lunch without being too soaked in the rain [13:26] (143/234) [13:26] no, please wait then [13:26] it's on 155 AFAIR [13:26] so "soon" [13:26] taking ages :/ [13:28] mborzecki: when did you start it? [13:29] 12:40, but then it got stuck in a debug shell in a test i was working on, and took a while before i noticed [13:29] ah [13:29] for me it's ~30 minutes [13:30] +/- 15 minutes [13:30] zyga-ubuntu: part of the problem is that edge is not really edge [13:30] zyga-ubuntu: I just pushed a pr [13:30] oh? [13:30] mvo: can you explain please [13:30] I see [13:30] PR snapd#4813 opened: release: snapd 2.31.2 [13:30] zyga-ubuntu: snap info core :/ its on 2.31.2 in edge right now [13:30] mvo: but how would it be a factor [13:31] mvo: since we change the version to leet [13:31] zyga-ubuntu: 2.31 is still using snappy-app-dev [13:31] I mean, is it a factor? [13:31] zyga-ubuntu: so that explains why the profiles are strange [13:31] yes but whatever is in whatever channel we start with [13:31] we are repackaging core, no? [13:32] yes [13:32] mvo, can we get this merged so I can rebase? https://github.com/snapcore/snapd/pull/4811 [13:32] PR #4811: tests/main/media-sharing: improve the test to cover /media and /run/media [13:33] Son_Goku: merged [13:33] PR snapd#4811 closed: tests/main/media-sharing: improve the test to cover /media and /run/media [13:39] PR snapcraft#1985 closed: tests: document arm testing setup [13:42] mborzecki: did it fail? [13:42] zyga-ubuntu: nope, (214/234) [13:42] so it's past that test [13:42] were you on release/2.32 [13:42] zyga-ubuntu: i used the same seed as you [13:42] yes [13:42] and on qemu of xenial? [13:42] that's not great then :/ [13:43] thank you, I wonder what this says then [13:43] yes, tip of release/2.32 branch [13:51] niemeyer: so, the interface is named "dummy" atm, with a description saying "snapd dummy test interface" [13:52] pstolowski: What's the PR? [13:54] pstolowski: After the conversation we just had, that's not too bad actually.. perhaps "snapd-dummy".. I'd just like to have a look at the code first [13:54] niemeyer: #4358 [13:54] PR #4358: interfaces: interface hooks implementation [13:54] niemeyer: look for dummy.go [13:54] Thanks [13:55] niemeyer: no-op interface? [13:59] Chipaca: #4800 is the same as #4799 and the title suggests it ought to be a different thing [13:59]