[05:35] PR snapd#6477 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined [05:40] PR snapd#6479 opened: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) [06:10] morning === phoenix_firebrd is now known as murthy [08:05] mvo: morning [08:05] mborzecki: hey, good morning [08:06] mvo: there was bit of trouble with osx builds yday, fortunately john reminded me of how yaml is super ambiguous about numerical vs string representation [08:06] mborzecki: yeah, I saw that, thank you! [08:07] mborzecki: I updated the 2.37 version now as well and removed esc.bold [08:07] mvo: i think we could cherry-pick the path warning for .2 too [08:07] oh, ok [08:07] mborzecki: yeah, we could, probably won't hurt either way === pstolowski|afk is now known as pstolowski [08:12] mornings [08:13] pstolowski: hey [08:16] hello [08:23] hey pstolowski and pedronis [08:23] hey pedronis [08:23] we're down to 43 PRs, not bad [08:24] indeed and 6479 will land as soon as its green so 42 effectively [08:29] PR snapd#6380 closed: interfaces: add more permissions to network-manager slot [08:30] PR snapd#5915 opened: interfaces/network-setup-control: allow calling netplan generate/apply <⛔ Blocked> [09:03] * dot-tobias waves hello [09:07] PR snapd#6479 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) [09:09] is there a way to force "prune" of old snap revisions? [09:16] Saviq: in which sense? we keep a fixed number of them per snap [09:17] Saviq: snap list --all, and some scripting [09:17] Saviq: also, you can configure how many to keep, down to a minimum of 2 [09:18] Saviq: https://superuser.com/questions/1310825/how-to-remove-old-version-of-installed-snaps [09:22] right, that! thanks [09:29] PR snapd#6480 opened: release: 2.37.2 [09:36] hey [09:36] I'm just popping in briefly now [09:36] mvo: have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ? [09:36] Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix [09:37] zyga: I have not, that sounds alarming [09:38] zyga: the second user who is affected is using 4.15 so it looks like its not disco only [09:38] yeah but it's not widespread either, I haven't seen this on any of my machines [09:38] I bet we're missing something [09:38] xnox: re 1814141> any denials in dmesg? (cc zyga) [09:39] zyga: yeah [09:39] oh, I didn't notice who reported it! [09:43] mvo: there's a new version of apparmor around 2.13 [09:43] mvo: wonder if that is related [09:43] mvo: but it doesn't feel like just apparmor, we would die on many other things before [09:43] well, the error is very specific [09:44] cannot read mount namespace identifier of pid 1 [09:44] where do we do that? [09:44] we check if we are in pid-1 mount namespace [09:45] but [09:45] we do that after we check if we are confined or not [09:45] so either we are confined but the profile is no longer sufficient [09:45] or we are not confined at all (apparmor disabled on boot) but we get denied somehow? [09:45] perhaps this is a container so outer container profile is too strict [09:46] or we lost the setuid bits? [09:46] Chipaca: snap has "pack" - should it not also have an 'unpack'? Which does whatever unsquashfs does? [09:47] pedronis: I think we need to get more information from xnox [09:47] popey: nobody's asked for it :-) [09:47] there is nothing really special into unpacking a snap [09:49] zyga: mvo: also we do run tests on disco, no? [09:49] but as root? [09:50] pedronis: no, we don't [09:50] pedronis: not in typical travis-spread run [09:50] pedronis: we should start that soon, when sergio is back [09:50] pedronis: we run many things as root but a single test running as an user would pick this up [09:50] (if it was totally broken) [09:51] I think we have some tests that run snaps as user [09:52] ok [09:52] anyway we need more info [09:52] yes, at least in the smoke suite some interface tests run as user we should probably add a very simple explict one still [09:52] * mvo does that [09:53] mvo: fun idea: run prepare/restore as root, run execute as non-root [10:10] PR snapd#6481 opened: tests: run test snap as user in the smoke test === murthy is now known as phoenix_firebrd_ [10:11] zyga: hm, interessting idea [10:16] pedronis: thank you for the review [10:20] mvo: will you have time to take a look at https://github.com/snapcore/snapd/pull/6322 (after release stuff is over)? [10:20] PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get [10:23] pstolowski: yeah, sounds like something for later today or tomorrow (assuming 1814141 isn't a new fire :/) [10:28] uhm [10:43] arch package updated [10:43] mborzecki: \o/ [10:47] pstolowski: we have a new beta 2.37.2 - if you still have the rpi around, helping with the validation would be most welcome, I created a trello card with the individual tasks [10:48] mvo: sure, will do [10:50] Chipaca: hi, did you see my ping about doing a review pass on 6079 given you reviewed some of the prereq [10:55] pedronis: I did not [10:55] pedronis: on it now [10:55] Chipaca: thank you === phoenix_firebrd_ is now known as murthy [11:23] grah, we're being inconsistent with our help strings again :-( [11:25] Chipaca: can't we write tests about some of the rules? or is too much NLP? [11:25] pedronis: we do have some tests [11:25] but apparently not one for this :-) [11:25] which makes me think maybe we didn't discuss & agree on it [11:27] Chipaca: what is about? [11:31] Chipaca: I mean, what more we should be consistent about and aren't ? [11:31] pedronis: sorry didn't see your q [11:31] pedronis: see "snap list --help" [11:32] pedronis: some options' description ends with a period, some don't [11:32] Ah [11:32] it's silly but it irks :-) [11:33] Chipaca: what is your preference? [11:34] pedronis: with [11:35] bah, in an ideal world with unicorns and flying cars and no climate change, all but the last option description ends with a ;, and the last one with a . [11:35] Chipaca: do we more with or more without [11:35] PR snapcraft#2455 closed: cli: retrieve error data from provider [11:35] (fun fact: we'd have to i18n the ;) [11:35] pedronis: dunno, i'll look into this later [11:35] in the middle of the 'connections' pr [11:35] mborzecki: ping [11:36] Chipaca: I don't the whole constute a sentence and there is scansion in other ways [11:36] Chipaca: pong [11:36] Chipaca: so I don't have a strong opinion [11:36] pedronis: you a verb there [11:36] Chipaca: oops, I don't think the whole of options constitue a sentence [11:36] mborzecki: if I disconnect all the connections of a snap, 'snap connections' doesn't notice [11:37] mborzecki: wondering if I'm holding it wrong [11:37] Chipaca: hmm === murthy is now known as phoenix_firebrd_ [11:37] bah, "doesn't notice", that's not quite true [11:37] Chipaca: fwiw, I'm slightly in favor of without myself ... but I'm interested whether we tended to do one or the other as well [11:37] as I said no very strong opinion here, I do agree we shouldn't do both tough [11:38] that is just sloppy [11:38] the difference is just very subtle [11:38] pedronis: same here [11:38] Chipaca: doesn't notice how? [11:39] mborzecki: sorry, it does, it's just very subtle [11:39] this is home, when you disconnect it: [11:39] icdiff:home :home home disconnected,manual [11:39] super clear it's disconnected [11:39] this is personal-files, when you disconnect it: [11:39] icdiff:gitconfig - personal-files - [11:40] why the difference? [11:40] Chipaca: right, there is no slot, so no connection, we could show 'disconnected' in the notes column to make it clear === phoenix_firebrd_ is now known as murthy [11:41] mborzecki: but home does show the slot it would connect to when disconnected [11:41] why are these so different when they're only different in their autoconnection [11:41] and that's just an assertion away [11:42] also, silly question, shouldn't removing a snap reset its connections? [11:42] if I disconnect something, remove the snap, and then install the snap, shouldn't it have the default connections connected? [11:42] Chipaca: afaik we keep the undersired conenctions in case you install it again [11:43] how do I tell it to connect that which it would've connected? [11:43] Chipaca: explicitly with snap connect [11:43] mborzecki: but that leaves it manually connected [11:44] icdiff:home :home home manual [11:44] Chipaca: yes, because it's a manual connection now [11:45] Chipaca: afaiu there's no going back to the intial state now [11:45] so how do i reset it to not be manual? [11:45] :-( [11:46] Chipaca: so the difference in presentation, what about showing (dis|un)connected in the notes column when there was no slot for a plug? [11:46] mborzecki: what does --all do when you specify a snap? [11:47] mborzecki: +1 to show disconnected when it's disconnected [11:47] Chipaca: --all is quite useless when you name a snap unfortunately, but i didn't error out there [11:48] Chipaca: we're back at https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/5 with parameters and presentation [11:49] mborzecki: playing with it "for real" always iterates these things [11:50] Chipaca: mhm [11:51] mborzecki: some more comments on the PR itself [11:51] Chipaca: thanks! [11:58] mborzecki: https://i.imgur.com/9s6nQG4.png ? [11:58] (that is: dim repeated snap names?) [11:59] Chipaca: fancy [11:59] hm, i should add a 'dim' property to escapes, separately [12:01] mborzecki: don't get me wrong the pr looks good [12:01] mborzecki: i'm just wanting to be super nitpicky about ux because we got it wrong three times already :-) [12:02] hahah :) [12:23] PR snapd#6482 opened: [RFC] cmd/snap: make 'snap list' show disabled snaps dimmed [12:23] * Chipaca had his fun, and now goes for lunch [12:48] mvo, zyga: fyi, I'm going to start looking at apparmor 2.13 for disco soon (assuming I can ever get away from things that keep preempting it :\) [12:51] ack [12:52] jdstrand: suse has it now [12:52] so does Debian [12:56] yes, I think I saw it in sid as well [12:56] Chipaca: thanks for #6356, a few small comments still [12:56] PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump === ricab is now known as ricab|lunch [13:00] mvo: fedora builds under way, I will keep you posted, going back to bed :/ [13:02] zyga: bed? are you sick... oh wait I know why you're sleep deprived! hang in there! [13:02] roadmr: yeah, sick [13:02] oh ouch :( get better, zyga [13:02] thank you :) [13:19] jdstrand: can you look at https://launchpadlibrarian.net/409976796/journalctl__grep_DENIED__tail.txt [13:20] this is from https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 [13:20] Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix [13:23] jdstrand, mvo: I added a hypothesis to that bug report [13:27] jezz pi3 tests are soo sloow, 195/262 and it's already over 3h [13:46] mborzecki: ping === ricab|lunch is now known as ricab [14:27] niemeyer, mvo, Chipaca, zyga, mborzecki: so snappy variant is now a thing in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/f171adca021ec0a2c599ce7c87f841c7face5f69?branch=master [14:27] :D [14:28] woop woop :-) [14:28] Son_Goku: nice! [14:28] thank you, that's a great milestone! [14:28] now I just need to simplify and rework my tool for building the base snap [14:29] Son_Goku: a SMOP [14:29] :-) [14:29] ? [14:30] haha [14:30] indeed it is [14:31] Son_Goku: Woo, nice! [14:31] now I just need snapcraft to know how to consume fedora content using dnf [14:31] Son_Goku: woah, amazing! [14:31] * mvo hugs Son_Goku [14:32] 😊 [14:32] niemeyer, do you think you could see if snapcraft folks would prioritize integrating support for dnf as a backend as an alternative to apt? [14:33] I'm fairly confident by now that I'll have fedora releng pushing official base snap stuff for fedora 30 [14:33] I just need to figure out _what_ should be in it :P [14:34] sergiusens: ^ [14:36] Son_Goku: It seems reasonably easy.. not sure if the snapcraft folks (e.g. Sergio :-) would do that first, or if it might be easier to just contribute an initial patch that abstracts the package management away [14:36] I did write a skeleton patch to separate the backend from the interface two years ago [14:36] Son_Goku: If nothing else, that would make it easier to discuss the design [14:36] I'll need to check how much of that is needed now with snapcraft 3.0 [14:37] sure [14:37] Son_Goku: It probably hasn't changed much, and it should now also be easier to integrate it nicely since we have proper base (IOW, multi image) support [14:37] right [14:37] niemeyer, part of this is that if there are problems with DNF interfaces/APIs, we can start poking the DNF team to look at fixing them [14:37] if we can't fix them ourselves, that is [14:38] as a package manager developer, you better than anyone else can understand how "weird" snapcraft's use-case is [14:38] Son_Goku: Once you have a better idea of how this should work, feel free to schedule (or ask to) a meeting with you, sergiusens, cmatsuoka, pedronis, and myself [14:38] will do, though I can't say I know who cmatsuoka is? [14:39] He's hanging here.. Claudio Matsuoka.. he's recently joined the team and will be working on snapcraft in the next few weeks at least [14:39] nice [14:39] well, for the moment, I'm focused on getting the base snap work done [14:40] but it's something that's on my infinitely long TODO :) [14:43] pedronis: hey, I'm looking at https://github.com/snapcore/snapd/blob/master/interfaces/policy/policy.go#L98 [14:44] pedronis: meh, nm for the moment [14:45] pedronis: no, actually, that function is checking the slots (snap decl, then base) then checking the plugs (snap decl, then base) [14:46] jdstrand: sorry, not following what you are pointing to [14:47] pedronis: such that, if there is an error (aka, aiui, something that would prevent installation), then something in the slots that prevented installation would preempt something in the plugs that might allow it [14:47] pedronis: checkSlot will look at snap then base [14:47] jdstrand: that is correct [14:47] slots and plugs are orthogonal at that level [14:47] it's not like connections [14:48] you cannot unblock installing a slot [14:48] I was expecting the logic to be different [14:48] by telling something about plugs [14:48] I see [14:48] that wouldn't make sense [14:50] jdstrand: I mean that logic is correct and doing otherwise feels like would be wrong security wise [14:50] pedronis: ok. basically, I'm rewriting the snap decl checks in the review tools to use the same procedure as snapd. I chose installation since it was before connection in the file, but it has a different algorithm that I don't need to worry about. thanks for clearing that :) [14:51] jdstrand: but I can confirm, connection checks and installation checks are very different [14:52] jdstrand: for connection is about can this plug be connected to that slot, but sides have a voice [14:52] * jdstrand nods [14:53] jdstrand: for installation, is can I install a snap sporting a plug of this interface, can I instal a snap sporting this slot? and plug and slot of the same interface on a snap are really unrelated for this [14:53] yeah [14:53] that isn't expressed in the spec afaics, so that would be another point to finetune [14:54] ok, thanks! that reminder helps a lot [14:56] mvo: when the beta validation test says "(for snapd promotion)", does it mean anything for the test? [15:04] Son_Goku: looking at how dpkg support was implemented, adding support to dnf/rpm shouldn't be too hard [15:04] pstolowski: its just a reminder for myself [15:05] pstolowski: this means this particular test is used to test the snapd snap [15:05] pstolowski: the other tests are about the "core" snap [15:05] hey, does `snap` have a way to wait for snapd to be ready? [15:05] Son_Goku: posted karma for EPEL update [15:05] cmatsuoka, I already contributed support to dump rpms a couple of years ago [15:05] pstolowski: so in theory we could release core once all tests are done and later snapd (once those tests are done) [15:05] pstolowski: does that make sense? [15:05] cmatsuoka, it's just that adding proper support for an rpm distro as a repo source was really hard [15:08] Son_Goku: it would certainly require a lot of tests and experimentation after the basic support is in place [15:08] Son_Goku: what were the main problems you found back then? [15:08] mvo: hmm, kind of; i don't know how to run "beta validation core18 - fresh install pi3 (for snapd promotion)" then per sergio's instructions [15:09] cmatsuoka, well, back then, I couldn't figure out how to make the code do the right thing [15:09] because snapcraft didn't know bases [15:10] mvo: sounds like it's more than just installing beta of core18 on pi3 and running the tests with dev_snapd_pi_18 [15:10] Son_Goku: oh I see. it should be easier now :) [15:10] and also, snapcraft goes back and forth between in chroot and out of chroot [15:10] pstolowski: that should be enough, use the fresh image of UC18 generator with the validator thing and run the dev_snapd_pi_18 [15:10] pstolowski: that should be ok [15:10] and one other problem is that the package manager likes to record its stuff in the databases in /var/lib/rpm and /var/lib/dnf [15:10] mvo: allright [15:10] mvo: thanks [15:11] and we _need_ that information to be writable during snap build time [15:11] or rather $SNAP/var/lib/rpm and $SNAP/var/lib/dnf [15:12] we can obviously not include them on the layered snap, but the way the package manager works requires that [15:12] and of course, figuring out how to block "updating" base libraries [15:12] the last part, I have an idea for, but the others I don't [15:15] Son_Goku: so now you could theoretically use a fedora base in the build provider, install all the packages you need there during the snap build [15:15] right [15:15] the build provider being a multipass vm [15:15] oh right [15:15] we don't have multipass in Fedora yet... [15:16] it's installabe as a snap [15:16] and in fedora infra, we have to be able to run snapcraft in a chroot [15:16] I run multipass on a bare metal fedora, it works well [15:16] I thought multipass only makes ubuntu VMs? [15:17] that's not particularly useful in this case [15:17] but wait, let me understand exactly what you are trying to accomplish here :) [15:17] I want: [15:17] 1. to be able to build snaps using a fedora base [15:17] 2. to be able to use snapcraft for snaps to be built on top of the fedora base, even officially by fedora packagers [15:18] 3. to be able to run snapcraft within Koji, the fedora build system [15:19] ok. then you need snapcraft to recognize fedora (or a specific version of fedora) as a base. then during the build process snapcraft would instance a fedora VM, install rpm packages, stage, prime and produce the snap [15:20] at runtime, you would need a fedora base image to support the snap created on top of the fedora base VM [15:21] the main issue is that Koji does not allow VM creation [15:21] Koji instantiates target-specific chroots, and runs the stuff in there [15:21] and they're not privileged enough to spin up VMs [15:22] can we run lxd containers there? === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [15:22] we should have support to lxd providers in some near future [15:22] no [15:23] no lxd packaged in fedora, and no support in koji [15:23] the former would be required for the latter [15:24] I also run lxd from snap on my fedora system, but you probably want something more "native" [15:25] I can't say for sure if snapcraft would work with a plain chroot provider, perhaps sergiusens could enlighten us here [15:26] cmatsuoka: we have nothing built out for chroots today [15:28] sergiusens: but that would be feasible? [15:28] cmatsuoka: I suspect --destructive-mode could work and then it could be just like those docker images people build [15:28] sergiusens: yes, that's my feeling as well [15:30] Son_Goku: so you could set up your chroot, put snapcraft and the source project there, and run snapcraft in destructive mode inside the chroot [15:30] Son_Goku: the dnf-aware snapcraft [15:31] okay, so there's a mode there [15:32] Son_Goku: yes, currently the default is to use a build provider such as multipass (and, in fact, it's the only provider available right now) [15:32] Son_Goku: but you can also tell snapcraft to not use the provider, and run in the host environment [15:33] this is the "destructive mode" [15:33] does multipass use libvirt? [15:33] ah, so it does [15:34] it'd be cool if it was packaged in Fedora and could use the Fedora-published VM images [15:34] or at least if the snap could make fedora VMs too [15:37] currently multipass itself is packaged as a snap and runs on fedora, but I don't know if there's a fedora image availability [15:38] s/availability/available right now/ [15:38] hey all, is there a `snap waitforready` of some kind that will ensure I'm not calling `snap install` before snapd is ready? [15:39] Saviq: yes [15:39] Saviq: there's even a service that uses that, that we use in cloud? i think? [15:40] Saviq: snapd.seeded.service [15:40] Saviq: does a "snap wait system seed.loaded" [15:40] Saviq: do we have any fedora image available for multipass? [15:41] Chipaca: the socket doesn't exist yet here so that won't work... [15:41] Saviq: whoa [15:41] Saviq: how does the socket not exist yet? what's starting your thing? [15:42] Chipaca: lxd container [15:42] Saviq: 1. wait for the socket (it should get created really early in boot) [15:42] Saviq: 2. as above :-) [15:42] Saviq: is it a systemd unit? [15:42] Chipaca: no, just driving snapcraft from outside the container [15:43] Saviq: note the socket gets created before the snapd binary is started [15:43] I know, socket activated [15:43] yup [15:43] meaning it's in relatively early boot [15:43] but still, I get ENOFILE when trying to install a snap [15:43] new installs of my snap package (i.e., not updates) have started complaining about "mkdir: cannot create directory ‘/home/[username]/snap/[packagename]’: Read-only file system". Does anyone know what would cause this? [15:43] oh well, will get bash to wait for the socket [15:44] or just try to install a couple times ;P [15:44] pedronis: in laneSnaps, your argument to pass in the tasks seems to mean I should actually pass in the rerefresh task (so the id and tasks are obviously in sync) [15:44] cmatsuoka: I've not tried, but https://alt.fedoraproject.org/cloud/ should work [15:44] as long as it has cloud-init [15:44] Chipaca: that makes sense [15:44] Son_Goku: ^^ [15:45] pedronis: it's going to break the unit tests :-) but easy to fix [15:45] it does have cloud-init [15:45] Chipaca: yes, it's a change, but I tried to explain why I think it makes sense :) [15:45] Son_Goku: `snap install multipass --classic --beta; multipass launch https://...` will tell you soon enough whether it works or not [15:46] pedronis: i agree [15:46] I'll have to try that later, then :) [15:50] PR snapcraft#2460 closed: build providers: recreate instance if base changed [15:54] Son_Goku: fwiw the OpenStack image seems to work fine, there's probably rough edges as we're assuming dpkg inside at the moment [15:54] yeah [15:55] also a bug in our snap packaging prevents the `launch https://` from working - need to download the image and `launch file://` [15:56] and `dnf makecache` takes quite a while, we should not wait for that [15:56] PR snapcraft#2462 opened: Release changelog for 3.1.1 [15:57] Son_Goku: feel free to file bugs under https://github.com/CanonicalLtd/multipass/issues/new as you encounter them :) [16:16] hey all, we want to transition multipass to core18 and realized there's a case where the upgrade needs user intervention to avoid data loss, what's the state-of-the-art approach to this situation? forcing a rollback (how)? failing one of the hooks (which)? [16:16] epochs are not a thing yet, are they? would they be of help? [16:16] Oh thank god a Snap chat [16:16] modprobe: FATAL: Module msr not found in directory /lib/modules/4.15.0-45-generic [16:16] Wtf is msr? [16:17] I was building a Snap with lxd [16:17] I have Linux Mint [16:18] Sorry I meant how do I get the msr. I have an idea what it is [16:18] JnR: hey, this module lets you ~interrogate the BIOS to find out about virtualization support [16:19] JnR: would you please file an issue in https://github.com/CanonicalLtd/multipass/issues/ [16:19] JnR: and in the mean time run `kvm-ok` that will guide you through ensuring your system can build snaps through multipass [16:20] some reading about why that's needed https://forum.snapcraft.io/t/reasoning-behind-the-move-to-multipass/9648 [16:20] Saviq at what point run kvm-ok? in substitute of snapcraft? [16:21] I haven't heard that command mention in any articles [16:21] JnR: just once, now is fine [16:21] the msr module won't be needed if kvm is already set up proper [16:21] PR # closed: snapd#5644, snapd#5915, snapd#5962, snapd#6034, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, [16:21] snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6406, snapd#6410, snapd#6413, snapd#6418, snapd#6436, snapd#6464, snapd#6465, snapd#6469, snapd#6472, snapd#6476, snapd#6478, snapd#6480, snapd#6481, snapd#6482 [16:23]