[00:13] kyrofa: you have on failing unit [05:08] morning [06:22] Good morning everyone:-) [06:22] hey zyga [06:24] zyga: mvo: hey [06:26] good morning mborzecki [06:30] kyrofa: looking [06:32] kyrofa: at least on am64 116 is setgroups, perhaps that is a local config issue; nothing changed on Debian AFAIK [06:32] * zyga resumes documenting snap-confine [06:54] wow, that debian 9 thing when snapd socket is restarted is annoying [06:55] basically reproduces every time in 5948, but stops when i push the commit with extra debug information [07:03] mborzecki: gar, anyoing indeed === pstolowski|afk is now known as pstolowski [07:05] mornings [07:05] hey pawel, mvo [07:05] PR snapd#5960 opened: snap, wrappers: support restart-delay, generate RestartSec= in service units [07:06] should be a simple one ^^ [07:07] PR snapd#5894 closed: many: enable AppArmor on Arch [07:08] mvo: do you plan to merge master to 2.36 branch or should I prepare a backport of 5894? [07:09] mborzecki: I plan to merge master once more [07:09] mborzecki: I need to check the status of the tagged PRs [07:10] mvo: i tagged 5960, hope you don't mind [07:10] mborzecki: I don't - and if I do I just ignore it ;) [07:20] dot-tobias: hello, I replied on the thread about the issue you found [07:21] hi zyga! Yes I saw that, was just about to reply that I found the issue. It actually was the install hook, will post details in the thread as soon as I cleaned up my snapcraft.yaml 😊 Thank you very much again! [07:21] woot, that's great! [07:21] mvo: can we enable layouts wit the 2.36? [07:21] I think they are really ready now [07:22] zyga: (and sorry for suspecting snapcraft to be the culprit instead of my own incompetence 😄 ) [07:22] definitely not more buggy than other features :) [07:22] dot-tobias: I'm happy you are using snaps and was interested enough to try out new features [07:26] zyga: this one PR of yours needs a second review, right? then yes it can go in [07:26] I can change the approach any way deemed necessary [07:29] zyga: *nod* [07:29] zyga: I personally would just remove the experimental.layouts entirely not support defaults [07:30] sure, shall I just do that? [07:30] zyga: but I understand there is a possible use-case [07:30] but really it's the first thing that goes out of experimental stage [07:30] zyga: I don't feel super strong about it but I think it would make it much quicker to review :) [07:30] so I wanted to be more conservative [07:30] zyga: good point [07:30] we don't really have a well defined process yet [07:30] zyga: maybe gustavo has a stronger opinion [07:30] zyga: yeah, thats a good point [07:36] niemeyer: layout is the first experimental feature that goes out of experimental. the question came up how we do this: a) switch the default of experimental.layouts to "true" (so that users can still disable it) or b) just remove the option entirely because we now consider it "ready" (cc zyga). what is your opinion on this? [07:38] mvo: (with apologies) https://twitter.com/lolamby/status/1049949985406705666 [07:39] zyga: I don't get it? [07:39] do you recall how I always type apt-get out of a habit and you always correct me with just "apt"? [07:39] zyga: yeah, but I don't get why the twitter picture has the simley on apt-get and the disgusted face on apt [07:40] do you know this meme? [07:40] zyga: I mean, are there really people who dislike the progress bar? [07:40] zyga: I don't, sorry [07:40] well, apparently, it's not my tweet :) [07:40] zyga: maybe thats the problem :) [07:40] zyga: I guess there is someone on the internet for everything [07:42] zyga: I just have to ask :) [07:45] morning peeps [07:45] Chipaca: hi [07:45] mborzecki: hi, I added a couple of small comments to the asserts PR [07:46] mborzecki: btw did you see my comment over one of your old PRs about going over "for snapName ..." cases, most of them should be isntanceName I think [07:47] pedronis: `for snapName ..` in the general codebase? [07:47] mborzecki: yes, there not that many [07:48] mvo: do you remember, in snap pack, why we do all the exclusion work instead of asking mksquashfs to do it? [07:48] pedronis: i don't recall it, but agree it makes sense to revisit the code places that do that [07:48] mborzecki: otherwise I would not suggest it, but they are also confusing atm [07:51] mborzecki: I count about 20 of them, vs ~900 general uses of snapName [07:52] some of which are correct and some are not, but don't think we would to fix those in one go [07:52] some will be taken care by looking at the for cases [07:52] s/we would/we want/ [08:00] Chipaca: I think by mistake, if mksquashfs can do it so should we [08:00] Chipaca: we should also think about using fakeroot in snap pack [08:00] mvo: it's can do exclusion by globs and regexpses [08:00] Chipaca: or at least warn/error if we are not [08:00] mvo: you don't need fakeroot unless you're packing os or core, right? [08:01] Chipaca: cool, that sounds like a nice simplification [08:01] mvo: but we do needd -all-root for apps [08:01] i'm working on exactly that :) [08:01] Chipaca: the review tools will complain if you `snap pack` and the uid inside the squash is != 0 [08:01] bah [08:01] Chipaca: aha, right [08:01] Chipaca: yeah -all-root [08:01] i worked on a bunch of stuff snapcraft needs / could use from snap pack [08:01] Chipaca: except for os of course [08:01] Chipaca: nice! [08:01] Chipaca: \o/ [08:01] that was last night [08:02] today i'm picking it apart into branches and adding tests for people to read :) [08:02] good stuff [08:02] the using mksquashfs's exclusion bits is for later [08:02] mvo: first up is using different flags depending on type, and using it from core if available [08:03] mvo: Having the option to disable it sounds very interesting for us to be able to debug potential issues we observe after the feature goes live [08:03] Chipaca: if you're stil up for reviews today, can you take a look at https://github.com/snapcore/snapd/pull/5960 ? [08:03] PR #5960: snap, wrappers: support restart-delay, generate RestartSec= in service units [08:03] mborzecki: nice [08:03] people came in asking, i couldn't refuse :) [08:04] niemeyer: ok, that is how zyga implemented it currently (kept the option but switch the default). so that sounds great [08:04] mvo: And in either case, it would be polite to not error harshly if someone is trying to enable the feature that used to be experimental in the past release.. a grace period would be nice, so switching the default solves that as well [08:04] * mvo nods [08:05] mvo: niemeyer: panic("No more experiment for you!") [08:05] I created a simple snap with the x2goclient package that's in ubuntu 16.04, when I install and run it I have no fonts. here's the snapcraft.xml https://pastebin.com/xJSKq1J2 any ideas? this is my first snap, so it's likely to be a simple mistake [08:06] Chipaca: I'm sure people would appreciate that ;) [08:06] chesty: you don't have enough plugs. You probably want to at least add 'desktop' and 'desktop-legacy' [08:06] niemeyer: ikr [08:06] chesty: https://forum.snapcraft.io/t/desktop-app-support-qt/6833 [08:08] popey, cheers, rebuilding now [08:09] on master, tests running on amazon-linux-2 are hitting 'No space left on device' [08:09] Brb [08:13] re [08:14] Chipaca: thx for the review [08:14] mvo, niemeyer: great, I'm happy I wrote it that way then :) [08:15] the weather is very much not like autumn but the pressure feels low, I feel far to sleepy today [08:18] PR snapd#5956 closed: image: fetch device store assertion if available [08:21] mvo: hey! I just quickly set up a github branch for the core deb subiquity package: https://github.com/CanonicalLtd/subiquity/tree/core/bionic [08:21] mvo: I should make a backport for #5956 now, right? [08:21] PR #5956: image: fetch device store assertion if available [08:21] mvo: so in case you have any fixes you'd like to submit to the core-used bionic package, submit a PR there [08:21] I guess this will make things easier to coordinate [08:23] pedronis: no need for a backport for 5956 [08:23] pedronis: I will merge master [08:24] sil2100: ok, cool, I have a look [08:24] mvo: ah, ok [08:24] I thought you did that already [08:24] anyway, thanks :) [08:25] popey, that fixed the font issue, thanks. I think I now need the home plug as it won't save the ssh server fingerprint, and then it should be rough enough is good enough. cheers. [08:26] the home interface won't allow access to ~/.ssh, if that's what you're after [08:26] chesty: maybe you can set an environment: HOME: $SNAP_USER_DATA, to force x2go to store stuff in the snaps home directory [08:27] OK. will try that. thanks [09:02] I haven't got it to work yet, x2goclient pops up a box saying the server is unknown, do you trust the host, clicking OK closes the box and it reopens with the same question. i can see the home dir is set to ~/snap/x2goclient/x1 I think x2go has it's own dir for ssh host keys...hmmm, I don't know how to debug it, strace doesn't seem to work [09:03] PR snapcraft#2334 closed: schema: enfore string for versions [09:14] pstolowski: I am looking at a issue that was reported by the cloud team, when adding lxd as a snap boottime decreased and while looking at it it seems like a good chunk of the time is spend on connecting (see https://bugs.launchpad.net/cloud-images/+bug/1796137/comments/28) - iirc we had some pending work to run apparmor_parser less often - do you know more about where we stand here ? (cc zyga) [09:14] Bug #1796137: huge and slow image 20181002 due to seeded lxd snap [09:14] (cc zyga) [09:14] mvo: I know - there are two aspects of that [09:15] one is done, I think it needs a review (I will check in a sec) but it is only polishing the existing state, not changing it significantly [09:15] this involves just calling apparmor parser once for many profiles [09:15] it offers modest improvements [09:15] the big win comes from something we need to design first, [09:15] when you connect many interfaces to a snap, you will have a lot of intermediate state [09:16] that state may or may not be observed by hooks that get invoked [09:16] if the state is not observed by any hooks we probably don't need it [09:16] we could cut the number of invocations to apparmor parser significantly, from O(N) to O(1), if we do this optimisation [09:17] it would involve making a connection and marking interface security as dirty or in need of triggering (dpkg style) [09:17] and then performing those triggers [09:17] the trick is making this while preserving semantics and correctness [09:17] all in face of undo and what not [09:17] that is not done or even drafted [09:17] we just understand and recognise the problem [09:17] zyga: ok [09:17] zyga: that does not sound like a low hanging fruit at all [09:18] no, it's not [09:18] zyga: the cloud team would like to see improvements before cosmic :/ [09:18] feels like a cycle of rework [09:18] that's unlikely to happen [09:18] I think it would be easier without any hooks but given that we inject hook tasks and just do nothing in them if there is no hook to run makes optimisation much more challenging [09:19] we could brainstorm this after user mounts [09:19] in about a week and a half from now [09:19] (promise!) [09:20] mvo: i haven't looked at this. as zyga says not trivial. perhaps one relatively "quick win" (but probably not significant) would be to avoid scheduling interface hooks that don't exist (which is usually the case) [09:20] Is there a snap out there to enable printer sharing on UbuntuCore ? [09:21] pstolowski: that sounds good and easy and would avoid some cluttering in the output [09:21] pstolowski: I agree, if we could pull that off we would have an open slate to perhaps optimise the special case of no hooks at all [09:21] i think currently we mark all hooks optional, schedule the tasks only to realize hook script is not there and nothing happens [09:21] and then solve the more general case of some hooks [09:21] with no hooks at all we could add a trigger cycle just after the autoconnect cycle [09:22] and keep regular connect / disconnect as-is [09:22] also reducing complexity [09:22] mvo: i can look at avoiding running non-existing hooks [09:25] pstolowski: thanks that would be great I think [09:25] pstolowski: once you have something, please add the PR into the bug so that the progress/work is visible to them [09:27] pedronis: 5948 should be good now, now if only that spread job would pass [09:29] sil2100: I filed #1797342 with the console-conf issue [09:29] Bug #1797342: console-conf crashes on UC18 on arm64 (dragonboard and pi3 in 64bit mode) [09:29] mborzecki: ack [09:30] PR snapd#5961 opened: snap/pack, snap/squashfs: use type to determine mksquashfs args [09:30] sergiusens: ^^ [09:30] mvo: also perhaps you're intersted ^ [09:32] mvo: so it still happens for the dragonboard, huh? [09:32] . sil2100 correct [09:32] om26er: there's a cups snap [09:32] sil2100: I tested it yesterday [09:32] Chipaca: very! thank you [09:32] Had hopes that since I couldn't reproduce it on my pi3, it was gone [09:32] Chipaca: just need to juggle between tasks [09:32] mvo: psh [09:33] sil2100: yeah, I'm trying to build a pi3-64 image to make testing easier [09:33] sil2100: dragonboards are just rare :/ [09:33] sil2100: if you want I can give you my dragon for debugging [09:33] either remotely via my office or I can just hand you one in person [09:33] zyga: heh, nice that you have it so close [09:34] Chipaca: are you talking about https://forum.snapcraft.io/t/call-for-testing-openprintings-printing-stack-snap-printing-in-a-snap/4406 (printing-stack-snap) ? [09:34] zyga: fwiw (didn't catch this in the scrollback) we landed the pr to coalesce apparmor_parser calls a week ago [09:34] om26er: yes [09:34] Chipaca: aha, nice [09:35] if so, it seems to not be available for armhf. I admit that was missing from my initial question. [09:35] Chipaca: this means with 2.36~pre they should see *some* improvements at least [09:35] Chipaca: I will dig out the pr number and paste into the report [09:35] Chipaca: ah, thank you for that [09:35] mvo: ^ so the low hanging fruit is merged [09:35] zyga: ta [09:35] https://github.com/snapcore/snapd/pull/5469 fwiw [09:35] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:36] Chipaca: nice [09:36] * om26er is trying to convert a RaspberryPi into a print sharing server in our co-working space. [09:37] om26er: google cloud print? [09:38] om26er: till did some works on a cups snap recently maybe he can help [09:38] mvo: yep, that's printing-stack-snap [09:39] lots of good info in that forum post [09:40] nice [09:40] @popey How will that work ? The printer is connected to the RPi which is connected to the office internet. How do we discover the printer if it isn't shared ? [09:42] om26er: I'm not sure tbh. But I have seen people use it to share printers easily, especially older USB printers. [09:43] last time I looked it uses a host with the right software and local printer drivers to create a bridge between the printer and the google service [09:43] so you send your print jobs to the cloud, where they are pulled by the host with this service and sent to the local, pre-cloud, printer [09:43] at some point any chrome installation was able to be the helper host [09:43] and would allow a Chromebook print [09:47] zyga: any chrome installation? sounds scary [09:47] I think you have to enable it but yeah [09:47] the idea was that there would be _someone_ with a windows + chrome laptop or desktop [09:47] next step, print still from chromecast :) [09:47] that would share a "legacy" printer [09:48] as in the chromecast dongle [09:50] mvo: any idea what's the status of cups snap? [09:50] mborzecki: no, sorry, I did not follow it closely [09:54] mvo: since the issue is still around, I have also poked mwhudson to help out since he does own a dragonboard himself [09:54] sil2100: aha, nice [09:56] sil2100: do you think you could upload a probert with debug symbols to the foundations ppa so that we can get a core18 in edge that is easier to debug? I guess I can't do that mysefl because of lack of permissions(?) [10:18] PR snapd#5962 opened: ifacestate/hotplug: hotplug handlers [10:22] mvo, can you remove kiosk.autoconnect.service from the pi-gadget ? that interface is gone with mir 1.0 (it now uses the wayland interface for everything) so the hack can go too [10:22] mvo: we didn't have debugging symbols in probert? [10:22] ogra: sure [10:22] sil2100: iirc we didn't when we poked at it in brussels [10:24] PR snapd#5963 opened: tests/hotplug: spread test for hotplug based on dummy interface [10:26] mvo: ok, I'll look at that in a minute [10:38] PR snapd#5952 closed: tests/ifacestate: moved asserts-related mocking into helper [10:40] Chipaca: took your idea of stacking the erorr messages, the diff is slightly larger than expected https://paste.ubuntu.com/p/tFyFBth5w8/, i'm thinking of landing #5960 with suggestions from zyga and doing a follow up with that change [10:40] PR #5960: snap, wrappers: support restart-delay, generate RestartSec= in service units [10:40] and then we can bikeshed about error messages :) [10:43] brb [10:43] while it's sunny and lovely outside [10:43] I think I have a cold [10:43] so ... brb [10:50] mborzecki: sgtm [10:50] hmm, hmm [10:51] not sure 'cannot validate' is the right way to say 'we validated it, and found it lacking' [10:53] cannot allow [10:54] mborzecki: I think context should be added by the caller [10:54] that is [10:55] "cannot validate snap 'foo': %v" should be what the caller of Validate() does [10:55] not Validate itself [10:55] because [10:56] then you can say "cannot pack thesnap/" or "cannot install some.snap" or … [10:56] instead of having "cannot pack thesnap/: cannot validate "the.snap": …" [10:56] mhm [10:56] but maybe that's too hard :) [10:57] good point Chipaca [10:57] we already mostly do this [10:57] we do os.MkDir() and then "cannot mkdir: %v"; we don't expet MkDir to have the context [10:58] but when we write both sides of the code it's harder to remember, i guess [10:58] dunno [10:58] maybe i just need lunch [11:13] mborzecki: I looked a bit again at snap and Validate*, seems a snap/names package with the various Validate for name like things, and maybe even the regexps exposed could make sense [11:15] Is it possible to use plugin artifacts across builds, but refresh my app's source? I.e. using the Ruby or nodejs plugin, keep the built ruby/node runtime but refresh the pulled-in code from the part's repository? If I'm not overlooking something, the current snap clean my-part removes everything related to that part? [11:15] pedronis: in case you missed the diff i sent yesterday, https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/validate-name-separate-package that's the thing i was working on, i can tweak it further and propose it after 5948 [11:16] dot-tobias: this is a question for sergiusens or kyrofa but they may be around later since they are in another timezone [11:16] * zyga is happy to know time namespaces are coming to the kernel [11:16] feels appropriate somehow [11:17] mborzecki: I see, no I hadn't looked at it, yes seems to go were I was thinking [11:17] *where [11:17] zyga: Thanks, will keep a watch on the room list then 😊 [11:17] dot-tobias consider asking on the forum as well [11:17] pedronis: cool [11:17] zyga: Will do that [11:20] mvo: btw. did you see my e-mail question about the inconsistency in new model assertion names for core18? [11:27] mvo: the hooks optimization looks promising, i did the change but need to accomdate a large number of existing tests which inspect tasks [11:30] pstolowski: great, thanks for this heads up [11:38] rbasak: I followed up on 1796017 we can sync up after lunch, my comments are probably not super helpful :/ [11:38] * mvo lunch [11:46] * pstolowski lunch [11:47] dot-tobias: sort of, but mind asking that on the forum so everyone benefits from the full answer? [11:48] * Chipaca lynch [11:51] whom ? [11:54] When I execute `snap list` or `snap find` I see some publishers have a green tick beside their name - what does that indicate? [11:54] that the publisher is *verified* [11:55] identity wise [11:55] @zyga - thanks - I was overthinking it then... [11:56] @pedronis - thanks too [12:01] ak2766: what were you thinking it was? [12:01] ak2766: and, how could we improve the output of 'snap list --help' to better explain it? [12:02] Chipaca: [ v - identity of the publisher has been verified] (legend) [12:02] zyga: wasn't asking you :-þ [12:03] (we trialled legends and they didn't really work) [12:03] they're helpful the first N times, and then just get in the way [12:03] where N is … hard to get right [12:03] (because I looked at only showing the legend the first N times :) ) [12:04] mvo: ack [12:04] PR snapd#5960 closed: snap, wrappers: support restart-delay, generate RestartSec= in service units [12:05] * Chipaca remembers he had lunch cooking and goes to tend to it before the fire alarm does [12:08] the report of my lunch's death was an exaggeration === chihchun is now known as chihchun_afk [12:21] sergiusens: Re: plugin artifacts – Sure, here's the topic I opened for this: https://forum.snapcraft.io/t/keep-plugin-artifacts-environments-across-cleanups-for-faster-iteration/7834 [12:38] zyga: I wonder if it is possible to optimize the fastpath-- ie, when everything goes right, which is the normal case [12:38] yes, I believe so [12:39] do you have in your backlog the discussion between mvo, pstolowski and me? [12:39] zyga: cause looking at http://paste.ubuntu.com/p/RYd5mDB76q/, it is clear that it is taking 1-2 seconds to load the lxd profiles, but we do the whole group over and over again for now reason [12:39] (which I know you know, I phrased it that way for others in the channel) [12:39] zyga: I do [12:40] ah. ok :-) [12:40] s/now/no/ [12:40] I mean, I know the reason. I mean, there is no reason we have to do it that way :) [12:41] meh. the point is, maybe the situation can be improved for the normal case without having to rearchitect everything to handle the failure cases as efficiently [12:41] I don't have anything specific to suggest; just posing the question [12:42] pedronis: hey! Did you see my e-mail question regarding the model name inconsistencies for core18? Just wanted to know if I should special-case those names or will they still be changed [12:42] sil2100: it's not a question for me, it's more mvo [12:43] but afaict they are decided [12:43] *afaik [12:43] That would be too bad! [12:43] Oh well [12:43] mvo: once you're back ^ [12:43] jdstrand: the failure case is, I think, to just abort the op and re-setup security in the undo path [12:43] (with no optimisations) [12:43] I think it's not that hard as I initially thought actually [12:44] because the bulk of it is in the auto-connect logic [12:44] @Chipaca - I was thinking it had something to with whether it was a full container or needed --devmode... [12:44] that is one function [12:44] where we can just buffer the changes [12:44] post-process them [12:44] and then execute whenever someone needs to observe the current state [12:44] ak2766: aha [12:44] ak2766: if it needed devmode you wouldn't see it in 'snap find', fwiw [12:44] ak2766: and in snap list, it'd say devmode in the notes [12:44] i'll be adding colour to the notes sometime soon [12:45] zyga: oh, that is interesting. yes, you could queue everything up, then at the end, say 'run the queue', but the queue is smart (eg, a hash) and doesn't have duplicates [12:45] for ... in auto-connect-things { connect(plug, slot) and mark security as dirty; if hook { make security clean }; } make security clean; [12:45] thanks - good to know... I'm new to snap - the apt-get lxd was running like a dog and soneone suggested I try snap - never going back... [12:46] jdstrand: apart from writing tests changes it should be fairly small [12:46] (involving no new backend logic probably) [12:46] ak2766: glad to know it's being useful; do let us know when we mess up :) [12:46] +1000 :) [12:46] *probably* [12:46] :) [12:46] I didn't think deeply about interaction with other backends though [12:46] shall we buffer for everything [12:46] or just special case apaprmor [12:46] if we special case it is the case we thought about before [12:46] but I think we should not special case [12:47] to be even more efficient [12:47] and have predictable properties (no intermediate state) [12:47] we precompile seccomp. I don't know how measurable an impact it would make, but there is computation there, so probably worth doing [12:47] I'm happy to do this after user mounts [12:47] udev is just writing out files [12:47] yeah and also totally generic in that sense [12:47] less udev triggers, less apparmor, less seccomp, less selinux relabelling or what else we need to do [12:47] I mean, it would benefit for efficiency, but maybe not phase 1 [12:48] actually, there is the trigger, yes. probably should include that too [12:48] I actually think this is phase one and last, there would be no phases, just introduce the delayed setup to the auto-connect function [12:48] (in my head this doesn't change regular connect / disconnect) [12:49] wfm [12:49] anyway, just an idea, I didn't attempt this yet so there may be something we've missed [12:49] sil2100: I will reply in a bit, have not seen it [12:50] @Chipaca - definitely will - if I needed to post to a forum, do you have something akin to https://stgraber.org/ [12:50] zyga: right. the idea is each of the backends knows the difference between dirty and clean [12:50] ak2766: https://forum.snapcraft.io (in the topic in case you forget) [12:50] zyga: dirty is writing out the files. clean is running some command on them [12:50] @Chipaca - I've just joined snapcraft.io [12:50]