[06:04] morning [06:13] mvo: hey [06:25] Hey [06:25] hey mborzecki and zyga [06:25] mvo: I sent a small tweak to the apt hook test [06:25] zyga: hey [06:26] plenty of reviews, unfortunately all are blocked by the tests :/ [06:26] Yeah [06:27] zyga: yeah, I approved it already [06:27] zyga: nice one [06:27] zyga: I think we still need a test that checks if we update the catalog on startup [06:27] zyga: but this one is nice as it adds clarity (and clean messages) [06:28] mborzecki: yeah, tests are very unhappy [06:28] zyga, mborzecki did anyone talk to the store last evening about the 403? [06:28] Yes [06:28] Daniel is on this [06:28] great [06:28] I was thinking that perhaps we should ask for a bug report to track [06:29] great [06:29] Even if only the bug is public [06:29] I need to take Bit out [06:29] Brrr [06:29] See you soon [06:54] is running hello-world.evil as root supposed to hit the permission denied error? [06:54] mwhudson: yes [06:55] because i get the permission denied as a regular user on debian [06:55] but not as root [06:55] (debian testing) [06:55] mwhudson: looking [06:55] mvo: tbh i'm surprised i get it at all on debian :) [06:56] i didn't think the kernel had all the apparmor snapd needed [06:57] mwhudson: this is what I see on ubuntu https://paste.ubuntu.com/p/Xy8BKNYwkT/ [06:57] mwhudson: [509022.132463] audit: type=1400 audit(1542697004.011:11343): apparmor="DENIED" operation="mknod" profile="snap.hello-world.evil" name="/var/tmp/myevil.txt" pid=29003 comm="evil" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 [06:57] mwhudson: can you post the output of `snap debug sandbox-features` somewhere? [07:20] mborzecki: http://paste.debian.net/1052415/ [07:27] mwhudson: hm, those apparmor options looks good, and yet hello-world.evil is not giving you an error? anything interessting in dmesg (I guess not) when you run this? [07:29] mwhudson: as a user, do you get a denial? [07:29] AFAIK we didn't enable the feature outside of arch and tumblweed [07:34] no, nothing in dmesg [07:34] for either user or root [07:34] right [07:34] maybe the non-root case is just failing on regular permissions? [07:35] mvo: are things still failing on the store? [07:35] zyga: hah yes, it failed as a user because i'd run it as root first... [07:35] \o/ [07:35] mwhudson: having said that I think we could enable apparmor on debian now [07:36] zyga: i though the plan was to interrogate the kernel and decide on that, not based on distro [07:36] zyga: we had one successful run [07:36] zyga: but yes [07:36] yes but it's not just the kernel [07:36] we check the kernel [07:36] but we also check the distribution [07:36] because apparmor userspace also matters and that was a simpler check [07:36] zyga: hm another sysctl tweak needed for rhel, max_user_namespaces is 0 by default :/ [07:36] ah [07:37] * zyga wonders if 4.20 will have everything [07:37] user namespaces? [07:37] can you tell me more about that [07:37] we don't use that [07:37] mwhudson, mborzecki: I'd love some eyes on https://github.com/snapcore/snapd/pull/6111 [07:37] I know it's probably most distant to being useful for debian at this stage [07:38] but that's the eventual goal, cut packaging cruft by using packaging/snapd.m [07:38] snapd.mk [07:38] zyga: "Fortunately the makefile world is much saner" i feel sorry for you! [07:38] haha, because of RPM of because thinking Makefile is saner :) ? [07:39] I mainly cannot understand how RPM macros can be this crippled [07:39] they are an oozing mess IMO [07:39] zyga: we don't but there's a test to check whether snaps can do, see tests/regression/lp-1618683 [07:39] * zyga looks [07:39] zyga: otoh, it's probably ok if users enable it themselves when needed [07:40] hah [07:40] that's a very specific test :-) [07:40] mborzecki: the test can also toggle that IMO [07:40] mborzecki: it will also self-document [07:40] fair enough :) [07:40] I think this is a test where we used to break LXD === pachulo_ is now known as pachulo === pstolowski|afk is now known as pstolowski [08:02] morning [08:19] zyga: i'm going to work on the yesterday's implicit hooks+interfaces issue, ok? [08:19] pstolowski: sure, thank you [08:19] I can close that tab :) [08:57] zyga: hi, I saw you are looking into catalogs, afaik /names was not working in the store last night and fixed just this morning [08:57] hey [08:57] yep, I know, I talked to daniel about it [08:57] I improved the test to fail faster with a clear error message [08:57] now back to ongoing tasks, trying to land stuff that's pending [08:59] zyga: ok, np, just making sure it was on the store side [08:59] wasn't sure if people pinged [08:59] yep [08:59] zyga: can you look at https://github.com/snapcore/snapd/pull/6168 later on? [08:59] mborzecki: sure [08:59] oh [08:59] I did, I have pending review comments [08:59] heh :) post'em [09:00] zyga: i reverted the snap-mgmt piece [09:01] btw. i installed kde on my laptop yday, the theming is off too, i have it set up to use the breeze theme for gtk apps and it's clearly using a different theme as well as font size [09:05] mborzecki: done [09:06] pedronis: I'll land 6150 with --from-snap-confine and do a small PR on top to rename that to --inherit-lock so that we don't lose a test slot [09:19] I need a 2nde review on https://github.com/snapcore/snapd/pull/6148 [09:19] mvo did one [09:19] +0, -7 branch [09:20] mborzecki: could you look at https://github.com/snapcore/snapd/pull/6111 [09:20] mborzecki: if not for centos, I'd love to have this for the next suse release [09:26] https://github.com/snapcore/snapd/pull/6168 - centos & spread is green :) [09:26] mborzecki: nice! [09:27] mvo: and needs a 2nd review [09:31] mborzecki: yeah, neck-deep in fontconfig again right now :( [09:31] mvo: np, i'll poke pstolowski [09:32] pstolowski: would you like to review 6168? [09:32] mborzecki: sure [09:32] pstolowski: ta [09:32] brb coffee [09:48] and re [09:49] hey Chipaca, cachio [09:50] SIGILL during go build https://www.irccloud.com/pastebin/n7OW8M6x/ [09:50] mvo: ^ [09:50] first time I saw this [09:50] 18.10 [09:53] zyga, running a test? [09:53] hey [09:54] not even that, just building [09:54] not a test, building snap-seccomp [09:57] mvo: tinyproxy is growing up 😍 [09:57] Chipaca: heh, yeah [09:57] Chipaca: maybe we need to rename it to lesstinyproxy [09:57] mediumproxy [09:57] midproxy? [09:57] lol [09:58] zyga, I'll try to reproduce it [09:58] Chipaca: dwarf proxy ;) [09:59] zyga: yeah... no, not that [09:59] right? :) [09:59] cachio: good morning! are things good for promotion of 2.36.1 to stable? [10:02] did we loose mup again? [10:02] mup: hello [10:02] Chipaca: https://github.com/minimaxir/big-list-of-naughty-strings :D [10:02] mvo, hi [10:02] zyga: yeah :-) [10:02] zyga: try setting that as the description of your snap [10:02] mvo, everything is ready [10:03] mvo, let me check with store team [10:04] cachio: awesome, thank you [10:05] mvo, np [10:06] mborzecki: remember this bug? https://github.com/snapcore/snapd/pull/6159 :D [10:06] it's green [10:06] heh, let me review that [10:06] it's not that short as I made more changes to tests and merged two functions together for simplicity [10:06] but the spread test is nice and much better than before [10:06] thanks! [10:06] one more to the done lane :) [10:10] Chipaca: hey, can you look at https://github.com/snapcore/snapd/pull/6174 - I'm not sure if this is done right wrt layering in the daemon [10:11] zyga: in 5 [10:11] mainly about how to get to refresh catalogs from api.go [10:11] sure, thanks! [10:41] who can I talk to about a missing repo in my build service dashboard? [10:41] specifically it's one that I've previously added that has disappeared [10:41] diddledan: not sure, anyone from the store I presume but not sure who's online now [10:42] I need to trigger a build so I went looking for it, but can't find it [10:42] the snap is still in my store dashboard, so I figured the store is correct [10:43] it's only the build service that's missing it [10:43] I tried to re-add it and it just sits there doing nothing [10:44] just sits there with the spinner spinning: https://usercontent.irccloud-cdn.com/file/LDUEyS53/image.png [10:45] opened a forum topic about theming under kde: https://forum.snapcraft.io/t/gtk-app-themes-under-kde/8597 (cc popey) [10:46] diddledan: I'd file a bug https://github.com/canonical-websites/build.snapcraft.io/issues [10:48] popey: interesting that you've filed a bug with a similar console log from the browser from when I try to re-add the repo to build: https://github.com/canonical-websites/build.snapcraft.io/issues/1155 [10:48] :) [10:48] Lukewh: ^ [10:49] 👀 [10:55] here's my bug: https://github.com/canonical-websites/build.snapcraft.io/issues/1175 [10:56] mvo, 2.36.1 is stable [10:57] cachio: \o/ [10:58] mvo, wiki updated too :) [11:01] mvo: do you remember the user request that caused us to look at `snap list --format=....`? [11:03] mvo: found it [11:08] Chipaca: ok [12:03] * zyga considers lunch [12:18] mvo: did you see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1804186 [12:19] zyga: yes, I think this will be fixed with 6156 [12:19] * zyga goes for lunch [12:19] yeah, I just wanted to have this on your radar [12:49] heh [12:49] I found some nice piece of garbage [12:50] mvo, hey, apt-hooks test failing because /var/cache/snapd/commands.db does not exist on ubuntu 18.04 [12:51] mvo: are the 2.36 and 2.37 lanes 'done' lanes, or 'doing' lanes? [12:51] and what's the relation between 19.04 done and 'done' done [12:51] * Chipaca is lost in a maze of lanes, all alike [12:51] mvo, I see this error https://paste.ubuntu.com/p/SxD8Jr2XJb/ [12:53] cachio: store names endpoint 403'ed well into last night [12:53] or timed out, yes [12:53] Chipaca: they are done lane [12:53] Chipaca, this is happening now too [12:53] but scoped to release version [12:53] I just reproduced that [12:54] cachio: really? seems to be working here :-( [12:54] Chipaca, it is happening sporadically in master [12:54] cachio: 'timeout reading body', or 403? [12:55] I just executed that on ubuntu-18.04-64 with -repeat 50 [12:55] Chipaca, the timeout [12:55] cachio: locally, or google cloud? [12:56] Chipaca, https://paste.ubuntu.com/p/2xsHgkgyNs/ [12:56] i'm seeing 8s, which is very close to the 10s timeout we have [12:56] on google cloud [12:56] running the test apt-hooks [12:57] ok [12:58] zyga: I've renamed them to say Done, then [12:58] Chipaca: I see now, nice [12:58] clearer [12:58] cachio: it's still a store issue though; not much we can do from our code [12:58] btw [12:58] zyga: i'm not really sure the 2.36 and 2.37 were done vs doing [12:58] this 5K monitor really pays for itself when you use our trello board :-) [12:59] zyga: but titling them will make it clearer if they weren't (somebody'll shout) [12:59] Chipaca: those were done [12:59] yep [13:01] Chipaca, nice, thanks [13:01] cachio: when exactly were those tests run? [13:02] wgrant wants to know :-) [13:02] Chipaca, I saw that error on travis [13:02] cachio: that's not an answer :-) [13:03] There wree 403s until I woke up about four hours ago. There were two brief periods of timeouts about an hour ago as fallout from the core release. [13:03] wgrant, it failed few ours ago on travis [13:03] Chipaca, [13:03] It's a criminal offense in most jurisdictions to report store problems without specific error messages and times. [13:03] 'about an hour ago' matches that fallout window [13:03] wgrant, Chipaca then I rexecuted that failed test from my machine few minutes ago [13:03] lol [13:03] this should go to quotes :) [13:03] and I could reproduce it [13:04] cachio: what's your ping to api.snapcraft.io? [13:04] Chipaca, wgrant I reproduced the error running from my machine the srpead test 30 minutes ago [13:04] Chipaca, the test was executed on a gce instance btw [13:04] ah [13:05] controlled locally, but run on gce, got it [13:05] yes [13:05] off to pick up the kids [13:07] Chipaca, spread -debug -repeat 50 google:ubuntu-18.04-64:tests/main/apt-hooks [13:07] I reproduced that by running that test [13:07] on master [13:24] mborzecki, centos in [13:27] Chipaca: 2.36,7 is done [13:31] hi, is snap supposed to honor the https_proxy env var? [13:31] I'm exporting it just before a snap install, but it's being ignored [13:31] (no sudo, I'm root already) [13:32] sergiusens, kyrofa hey, can someone help me with "Failed to pull source: unable to determine source type of 'fc/'." ? context is https://github.com/snapcore/core/pull/99 - what is puzzling is that this works in https://code.launchpad.net/~mvo/+git/fontconfig-multi-cache [13:32] https://pastebin.ubuntu.com/p/j7pwP4brsS/ [13:33] ahasenack: its complicated - snapd will honor it but the snap command will not pick it up and transfer it to snapd (if that makes sense) [13:34] ahasenack: so "http_proxy=... /usr/lib/snapd/snapd & ; sudo snap install foo" would work (in theory) [13:34] I see, it's the daemon [13:35] ahasenack: we could make this work by simply reading http_proxy in snap (the cli) and when talking to the daemon setting it for these requests [13:35] installing lxd suddenly became harder [13:35] ahasenack: this would require a bit of code and a design discussion. I think its what most users expect though [13:35] looks like I can add it to /etc/environment [13:35] and restart snapd [13:36] EnvironmentFile=-/etc/environment <-- because of that in its service file [13:36] ahasenack: yes, or "snap set core https.proxy=..." [13:47] cachio: pstolowski: thanks! [13:49] mvo: and was I right in thinking that the bare "Done" was "Done on master"? [13:51] Chipaca: done for things that cannot be associated with a release [13:57] Heya [13:58] I'm updating the blender snap during intervals here at the sprint [13:58] I just found what seems like another minor bug on the handling of installation flags: [13:58] % sudo snap install blender_2.79b_amd64.snap --dangerous [13:58] error: cannot perform the following tasks: [13:58] - Mount snap "blender" (unset) (snap "blender" requires classic confinement) [13:58] Looks like classic was ignored until too late [13:58] Chipaca: ^ [14:01] niemeyer: yes, i noticed that as well. it's just how we handle the error, fwiw [14:01] installPath doesn't do the handholding install does [14:01] and the blurb is slightly off for installPath [14:01] but it needs to do something [14:01] i'll get to it [14:01] currently on the warnings-as-yaml thing [14:01] Thanks! [14:01] * Chipaca lags [14:09] sergiusens: snapcraft is doing something curious with multi-line strings [14:10] \ compositing and motion tracking, even video editing and game\ncreation.\n\nBlender\ [14:10] \ is a public project, made by hundreds of people from around the\nworld; by studios\ [14:10] sergiusens: That's ending up in meta/snap.yaml [14:45] cachio: do you happen to know the status of the 2.35.5 SRU? is all the validation done from our side? [14:53] mvo, checking [14:54] mvo, last sru done is for 2.35.4 [14:55] I can make 2.35.5 today [14:55] cachio: great, thanks [14:55] cachio: lets try to get it out of the door, I pushed 2.36 into the sru queue but it can sit there [14:56] mvo, sure, I'll complete it todya [14:56] cachio: thank you [14:56] jdstrand: Heya [14:56] niemeyer: hi :) [14:56] jdstrand: Apparently the store reviews are blocking the title field: [14:56] " - unknown entries in snap.yaml: 'title'" [14:57] sergiusens: This is an issue as well for snapcraft ^ [14:57] Both license and title are being blocked [14:57] niemeyer: oh, huh. when was that added? [14:57] jdstrand: Curiously, it's been a while [14:58] that is curious [14:58] jdstrand: I think we didn't really notice because most people are either setting it in the store UI directly, or don't care [14:59] niemeyer: is this something where snap.yaml doesn't know about it but snapcraft is passing it through cause it is in snapcraft.yaml? of is it legitimate for snap.yaml? [14:59] s/of is/or is/ [14:59] jdstrand: It's been legitimate in snap.yaml for long now [14:59] huh [14:59] * jdstrand shrugs [14:59] I'll fix it [14:59] jdstrand: Again, I think it's just that most people that care about the title has been editing the whole metadata directly in the web UI [14:59] jdstrand: So bypassing the review [15:00] jdstrand: It gets down to snapd on install [15:00] * jdstrand nods [15:00] I see it in info_snap_yaml.go [15:00] I'll double check is anything else is missing while I'm at it [15:01] everything else is there [15:06] mvo: https://paste.ubuntu.com/p/vbJPDwH5YF/ [15:08] mvo, http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#snapd [15:08] not tests executed on bionic for 2.35.5 [15:09] jdstrand: Thanks! Can we get it through as well please [15:09] jdstrand: I also have 2.80 behind it [15:09] mvo, Not touching package due to block request by freeze (contact #ubuntu-release if update is needed) [15:09] niemeyer: yes, I'll review the queue [15:10] jdstrand: Danke! [15:26] niemeyer: thanks. I am off today but will work on title tomorrow (license should work without passthrough in 3.0). I will look at the code or ask Chipaca about rules for title since he has been doing the snap pack validation work [15:28] niemeyer the line breaks might be related to the use of | for description, we recently switched it to >. Thanks to sparkiegeek [15:29] sergiusens: | is what we want in general I believe [15:29] sergiusens: In either case, that looks like a longstanding issue.. I have pretty old snaps that have the description mangled like that [15:30] roadmr: hi! can you pull r1156 of the review tools? [15:30] jdstrand: howdy! totally, will do [15:30] thanks [15:31] jdstrand: I was not aware title made it in. But do tell me when you start allowing it so we do not block new users when using it. Passthrough should work in the meantime. [15:31] niemeyer: both are approvied [15:32] sergiusens: my ping to roadmr is for that [15:32] * sergiusens goes back to being off [15:32] sergiusens: so feel free to commit at your convenience. and enjoy your day off :) [15:34] zyga: can you try this in a vm? https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9 i can reproduce the mount problem quite reliably (you need to have bc installed) [15:34] just systemd and mount units [15:34] mvo, I just pulled that core PR #99, and those parts pull fine for me [15:35] Did you sort it out? [15:36] sergiusens: Let's please catch up when you are back. Using ">" is probably a bug too, but likely not it. I'll report a bug. [15:38] kyrofa: it fails in LP [15:38] kyrofa: it works locally [15:39] kyrofa: I'm very confused, it also works in a very similar setup (https://code.launchpad.net/~mvo/+snap/fontconfig-multi-cache) where it works [15:39] kyrofa: slightly desperate as it blocks some important work [15:41] Yeah I think I know what work that is :) [15:42] https://bugs.launchpad.net/snapcraft/+bug/1804258 https://bugs.launchpad.net/snapcraft/+bug/1804256 [15:42] mup: Are you okay? [15:43] Hmm.. freenode seems to be still blocking [15:43] mvo, can I see a LP log of the failure? [15:43] mup: Now? [15:43] mup: Now? [15:43] niemeyer: I really wish I understood what you're trying to do. [15:43] Yeah.. :/ [15:44] Need to improve mup to identify itself automatically to nickserv [15:44] kyrofa: https://travis-ci.org/snapcore/core/builds/457417770?utm_source=github_status&utm_medium=notification [15:45] kyrofa: and https://github.com/snapcore/core/blob/master/.travis.yml is the build script [15:46] kyrofa: maybe some outdated version of snapcraft or something? [15:46] mvo, https://github.com/snapcore/core/blob/master/.travis.yml#L22 [15:47] Do you intend to copy the fc dir there? [15:47] kyrofa: !!! [15:47] kyrofa: it looks like this script needs some serious love [15:47] kyrofa: thats exactly it, thank you so much [15:47] Haha, no problem [15:48] mvo, that error is a bit misleading, please do log a bug when able [15:50] * cachio lunch [15:56] mborzecki: re [15:56] mborzecki: trying [15:56] mborzecki: does it brick the system? :) [16:00] mborzecki: running on 16.04 [16:01] mborzecki: no luck yet [16:01] I can add more cores [16:01] (or less cores, need to check what's the key) [16:01] currently running with 4 cores [16:02] mborzecki: no luck, restored snapshot [16:03] going to 1 core [16:06] mborzecki: I got "3: disk-16 missing" [16:09] mvo, no 2.35.5 on proposed/bionic [16:10] mvo, is it agreed? [16:12] mborzecki: running for a longer while I see more "disk missing" errors [16:45] zyga: try 18.10 or fedora or arch [16:46] mborzecki: I'll jump into this tomorrow, I'm deep in something else now [16:46] mborzecki: but it failed on 16.04 too [16:46] when I went to one core it was failing faster [16:49] zyga: takes one run to reproduce on 18.10 :) [16:52] mborzecki: good [16:52] mborzecki: I think it's not systemd [16:52] I can show you where the lock is missing [16:52] but we can hack that tomorrow [16:52] I _suspect_ it's a security bug [16:52] so either fix quickly or be considerate [17:05] PR snapd#6177 opened: interfaces: draft of LimeSDR hotplug interface <⛔ Blocked> [17:19] hi jdstrand ! hey is it possible to make a plug in one snap automagically connect to another snap's slot? I know the IDs of both snaps. === pstolowski is now known as pstolowski|afk [18:01] Bug #1804281 opened: Cannot refresh snaps if home is in NFS with root_squash [18:04] jdstrand: Thanks for the approvals [18:05] jdstrand: Looking into it now.. I might have a new revision soon [18:13] dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libpthread.so.0 (used by debian/snapd/usr/lib/snapd/snap-failure) [18:13] WAT [19:02] * cachio afk [19:17] kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1763394 is a bug about this, I will amend it [19:17] Bug #1763394: cleanbuild gets confused with directory source type [19:50] pstolowski|afk: fyi, I saw and am still digesting your hotplug/autoconnect forum post [20:37] is there a snapd api i can hit to answer the question "will snap refresh --channel=$foo $bar do anything"? [20:38] there's /v2/find?select=refresh but that won't be correct if the snap is not tracking $foo already [20:38] another question! [20:39] if a snap revision is in two channels $foo and $bar and currently tracking $foo, will snap refresh --channel=$bar restart services from the snap? [20:39] i guess not === kali_ is now known as kaliy [22:19] mwhudson: o/ [22:19] mwhudson: no there isn't a "dry run" [22:20] mwhudson: there is 'snap refresh --list' which is something almost completely but not entirely different [22:20] why is there a --list and not a --dry-run? [22:20] probably "we r dum" [22:20]