| sergiusens | kyrofa: you have on failing unit | 00:13 |
|---|---|---|
| mborzecki | morning | 05:08 |
| zyga | Good morning everyone:-) | 06:22 |
| mvo | hey zyga | 06:22 |
| mborzecki | zyga: mvo: hey | 06:24 |
| mvo | good morning mborzecki | 06:26 |
| zyga | kyrofa: looking | 06:30 |
| zyga | 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:32 | |
| mborzecki | wow, that debian 9 thing when snapd socket is restarted is annoying | 06:54 |
| mborzecki | basically reproduces every time in 5948, but stops when i push the commit with extra debug information | 06:55 |
| mvo | mborzecki: gar, anyoing indeed | 07:03 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:05 |
| zyga | hey pawel, mvo | 07:05 |
| mup | PR snapd#5960 opened: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960> | 07:05 |
| mborzecki | should be a simple one ^^ | 07:06 |
| mup | PR snapd#5894 closed: many: enable AppArmor on Arch <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5894> | 07:07 |
| mborzecki | mvo: do you plan to merge master to 2.36 branch or should I prepare a backport of 5894? | 07:08 |
| mvo | mborzecki: I plan to merge master once more | 07:09 |
| mvo | mborzecki: I need to check the status of the tagged PRs | 07:09 |
| mborzecki | mvo: i tagged 5960, hope you don't mind | 07:10 |
| mvo | mborzecki: I don't - and if I do I just ignore it ;) | 07:10 |
| zyga | dot-tobias: hello, I replied on the thread about the issue you found | 07:20 |
| dot-tobias | 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 |
| zyga | woot, that's great! | 07:21 |
| zyga | mvo: can we enable layouts wit the 2.36? | 07:21 |
| zyga | I think they are really ready now | 07:21 |
| dot-tobias | zyga: (and sorry for suspecting snapcraft to be the culprit instead of my own incompetence š ) | 07:22 |
| zyga | definitely not more buggy than other features :) | 07:22 |
| zyga | dot-tobias: I'm happy you are using snaps and was interested enough to try out new features | 07:22 |
| mvo | zyga: this one PR of yours needs a second review, right? then yes it can go in | 07:26 |
| zyga | I can change the approach any way deemed necessary | 07:26 |
| mvo | zyga: *nod* | 07:29 |
| mvo | zyga: I personally would just remove the experimental.layouts entirely not support defaults | 07:29 |
| zyga | sure, shall I just do that? | 07:30 |
| mvo | zyga: but I understand there is a possible use-case | 07:30 |
| zyga | but really it's the first thing that goes out of experimental stage | 07:30 |
| mvo | zyga: I don't feel super strong about it but I think it would make it much quicker to review :) | 07:30 |
| zyga | so I wanted to be more conservative | 07:30 |
| mvo | zyga: good point | 07:30 |
| zyga | we don't really have a well defined process yet | 07:30 |
| mvo | zyga: maybe gustavo has a stronger opinion | 07:30 |
| mvo | zyga: yeah, thats a good point | 07:30 |
| mvo | 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:36 |
| zyga | mvo: (with apologies) https://twitter.com/lolamby/status/1049949985406705666 | 07:38 |
| mvo | zyga: I don't get it? | 07:39 |
| zyga | do you recall how I always type apt-get out of a habit and you always correct me with just "apt"? | 07:39 |
| mvo | zyga: yeah, but I don't get why the twitter picture has the simley on apt-get and the disgusted face on apt | 07:39 |
| zyga | do you know this meme? | 07:40 |
| mvo | zyga: I mean, are there really people who dislike the progress bar? | 07:40 |
| mvo | zyga: I don't, sorry | 07:40 |
| zyga | well, apparently, it's not my tweet :) | 07:40 |
| mvo | zyga: maybe thats the problem :) | 07:40 |
| mvo | zyga: I guess there is someone on the internet for everything | 07:40 |
| mvo | zyga: I just have to ask :) | 07:42 |
| Chipaca | morning peeps | 07:45 |
| pedronis | Chipaca: hi | 07:45 |
| pedronis | mborzecki: hi, I added a couple of small comments to the asserts PR | 07:45 |
| pedronis | 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:46 |
| mborzecki | pedronis: `for snapName ..` in the general codebase? | 07:47 |
| pedronis | mborzecki: yes, there not that many | 07:47 |
| Chipaca | mvo: do you remember, in snap pack, why we do all the exclusion work instead of asking mksquashfs to do it? | 07:48 |
| mborzecki | pedronis: i don't recall it, but agree it makes sense to revisit the code places that do that | 07:48 |
| pedronis | mborzecki: otherwise I would not suggest it, but they are also confusing atm | 07:48 |
| pedronis | mborzecki: I count about 20 of them, vs ~900 general uses of snapName | 07:51 |
| pedronis | some of which are correct and some are not, but don't think we would to fix those in one go | 07:52 |
| pedronis | some will be taken care by looking at the for cases | 07:52 |
| pedronis | s/we would/we want/ | 07:52 |
| mvo | Chipaca: I think by mistake, if mksquashfs can do it so should we | 08:00 |
| mvo | Chipaca: we should also think about using fakeroot in snap pack | 08:00 |
| Chipaca | mvo: it's can do exclusion by globs and regexpses | 08:00 |
| mvo | Chipaca: or at least warn/error if we are not | 08:00 |
| Chipaca | mvo: you don't need fakeroot unless you're packing os or core, right? | 08:00 |
| mvo | Chipaca: cool, that sounds like a nice simplification | 08:01 |
| Chipaca | mvo: but we do needd -all-root for apps | 08:01 |
| Chipaca | i'm working on exactly that :) | 08:01 |
| mvo | Chipaca: the review tools will complain if you `snap pack` and the uid inside the squash is != 0 | 08:01 |
| Chipaca | bah | 08:01 |
| mvo | Chipaca: aha, right | 08:01 |
| mvo | Chipaca: yeah -all-root | 08:01 |
| Chipaca | i worked on a bunch of stuff snapcraft needs / could use from snap pack | 08:01 |
| mvo | Chipaca: except for os of course | 08:01 |
| mvo | Chipaca: nice! | 08:01 |
| mvo | Chipaca: \o/ | 08:01 |
| Chipaca | that was last night | 08:01 |
| Chipaca | today i'm picking it apart into branches and adding tests for people to read :) | 08:02 |
| mvo | good stuff | 08:02 |
| Chipaca | the using mksquashfs's exclusion bits is for later | 08:02 |
| Chipaca | mvo: first up is using different flags depending on type, and using it from core if available | 08:02 |
| niemeyer | 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 |
| mborzecki | Chipaca: if you're stil up for reviews today, can you take a look at https://github.com/snapcore/snapd/pull/5960 ? | 08:03 |
| mup | PR #5960: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960> | 08:03 |
| Chipaca | mborzecki: nice | 08:03 |
| mborzecki | people came in asking, i couldn't refuse :) | 08:03 |
| mvo | niemeyer: ok, that is how zyga implemented it currently (kept the option but switch the default). so that sounds great | 08:04 |
| niemeyer | 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:04 | |
| Chipaca | mvo: niemeyer: panic("No more experiment for you!") | 08:05 |
| chesty | 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:05 |
| niemeyer | Chipaca: I'm sure people would appreciate that ;) | 08:06 |
| popey | chesty: you don't have enough plugs. You probably want to at least add 'desktop' and 'desktop-legacy' | 08:06 |
| Chipaca | niemeyer: ikr | 08:06 |
| popey | chesty: https://forum.snapcraft.io/t/desktop-app-support-qt/6833 | 08:06 |
| chesty | popey, cheers, rebuilding now | 08:08 |
| mborzecki | on master, tests running on amazon-linux-2 are hitting 'No space left on device' | 08:09 |
| zyga | Brb | 08:09 |
| zyga | re | 08:13 |
| pedronis | Chipaca: thx for the review | 08:14 |
| zyga | mvo, niemeyer: great, I'm happy I wrote it that way then :) | 08:14 |
| zyga | the weather is very much not like autumn but the pressure feels low, I feel far to sleepy today | 08:15 |
| mup | PR snapd#5956 closed: image: fetch device store assertion if available <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5956> | 08:18 |
| sil2100 | 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 |
| pedronis | mvo: I should make a backport for #5956 now, right? | 08:21 |
| mup | PR #5956: image: fetch device store assertion if available <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5956> | 08:21 |
| sil2100 | 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 |
| sil2100 | I guess this will make things easier to coordinate | 08:21 |
| mvo | pedronis: no need for a backport for 5956 | 08:23 |
| mvo | pedronis: I will merge master | 08:23 |
| mvo | sil2100: ok, cool, I have a look | 08:24 |
| pedronis | mvo: ah, ok | 08:24 |
| pedronis | I thought you did that already | 08:24 |
| pedronis | anyway, thanks :) | 08:24 |
| chesty | 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:25 |
| popey | the home interface won't allow access to ~/.ssh, if that's what you're after | 08:26 |
| popey | chesty: maybe you can set an environment: HOME: $SNAP_USER_DATA, to force x2go to store stuff in the snaps home directory | 08:26 |
| chesty | OK. will try that. thanks | 08:27 |
| chesty | 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:02 |
| mup | PR snapcraft#2334 closed: schema: enfore string for versions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2334> | 09:03 |
| mvo | 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 |
| mup | Bug #1796137: huge and slow image 20181002 due to seeded lxd snap <cloud-images:Confirmed> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1796137> | 09:14 |
| mvo | (cc zyga) | 09:14 |
| zyga | mvo: I know - there are two aspects of that | 09:14 |
| zyga | 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 |
| zyga | this involves just calling apparmor parser once for many profiles | 09:15 |
| zyga | it offers modest improvements | 09:15 |
| zyga | the big win comes from something we need to design first, | 09:15 |
| zyga | when you connect many interfaces to a snap, you will have a lot of intermediate state | 09:15 |
| zyga | that state may or may not be observed by hooks that get invoked | 09:16 |
| zyga | if the state is not observed by any hooks we probably don't need it | 09:16 |
| zyga | we could cut the number of invocations to apparmor parser significantly, from O(N) to O(1), if we do this optimisation | 09:16 |
| zyga | it would involve making a connection and marking interface security as dirty or in need of triggering (dpkg style) | 09:17 |
| zyga | and then performing those triggers | 09:17 |
| zyga | the trick is making this while preserving semantics and correctness | 09:17 |
| zyga | all in face of undo and what not | 09:17 |
| zyga | that is not done or even drafted | 09:17 |
| zyga | we just understand and recognise the problem | 09:17 |
| mvo | zyga: ok | 09:17 |
| mvo | zyga: that does not sound like a low hanging fruit at all | 09:17 |
| zyga | no, it's not | 09:18 |
| mvo | zyga: the cloud team would like to see improvements before cosmic :/ | 09:18 |
| zyga | feels like a cycle of rework | 09:18 |
| zyga | that's unlikely to happen | 09:18 |
| zyga | 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:18 |
| zyga | we could brainstorm this after user mounts | 09:19 |
| zyga | in about a week and a half from now | 09:19 |
| zyga | (promise!) | 09:19 |
| pstolowski | 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 |
| om26er | Is there a snap out there to enable printer sharing on UbuntuCore ? | 09:20 |
| mvo | pstolowski: that sounds good and easy and would avoid some cluttering in the output | 09:21 |
| zyga | 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 |
| pstolowski | i think currently we mark all hooks optional, schedule the tasks only to realize hook script is not there and nothing happens | 09:21 |
| zyga | and then solve the more general case of some hooks | 09:21 |
| zyga | with no hooks at all we could add a trigger cycle just after the autoconnect cycle | 09:21 |
| zyga | and keep regular connect / disconnect as-is | 09:22 |
| zyga | also reducing complexity | 09:22 |
| pstolowski | mvo: i can look at avoiding running non-existing hooks | 09:22 |
| mvo | pstolowski: thanks that would be great I think | 09:25 |
| mvo | pstolowski: once you have something, please add the PR into the bug so that the progress/work is visible to them | 09:25 |
| mborzecki | pedronis: 5948 should be good now, now if only that spread job would pass | 09:27 |
| mvo | sil2100: I filed #1797342 with the console-conf issue | 09:29 |
| mup | Bug #1797342: console-conf crashes on UC18 on arm64 (dragonboard and pi3 in 64bit mode) <subiquity:New> <https://launchpad.net/bugs/1797342> | 09:29 |
| pedronis | mborzecki: ack | 09:29 |
| mup | PR snapd#5961 opened: snap/pack, snap/squashfs: use type to determine mksquashfs args <Created by chipaca> <https://github.com/snapcore/snapd/pull/5961> | 09:30 |
| Chipaca | sergiusens: ^^ | 09:30 |
| Chipaca | mvo: also perhaps you're intersted ^ | 09:30 |
| sil2100 | mvo: so it still happens for the dragonboard, huh? | 09:32 |
| zyga | . sil2100 correct | 09:32 |
| Chipaca | om26er: there's a cups snap | 09:32 |
| zyga | sil2100: I tested it yesterday | 09:32 |
| mvo | Chipaca: very! thank you | 09:32 |
| sil2100 | Had hopes that since I couldn't reproduce it on my pi3, it was gone | 09:32 |
| mvo | Chipaca: just need to juggle between tasks | 09:32 |
| Chipaca | mvo: psh | 09:32 |
| mvo | sil2100: yeah, I'm trying to build a pi3-64 image to make testing easier | 09:33 |
| mvo | sil2100: dragonboards are just rare :/ | 09:33 |
| zyga | sil2100: if you want I can give you my dragon for debugging | 09:33 |
| zyga | either remotely via my office or I can just hand you one in person | 09:33 |
| mvo | zyga: heh, nice that you have it so close | 09:33 |
| om26er | 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 |
| Chipaca | zyga: fwiw (didn't catch this in the scrollback) we landed the pr to coalesce apparmor_parser calls a week ago | 09:34 |
| Chipaca | om26er: yes | 09:34 |
| mvo | Chipaca: aha, nice | 09:34 |
| om26er | if so, it seems to not be available for armhf. I admit that was missing from my initial question. | 09:35 |
| mvo | Chipaca: this means with 2.36~pre they should see *some* improvements at least | 09:35 |
| mvo | Chipaca: I will dig out the pr number and paste into the report | 09:35 |
| zyga | Chipaca: ah, thank you for that | 09:35 |
| zyga | mvo: ^ so the low hanging fruit is merged | 09:35 |
| mvo | zyga: ta | 09:35 |
| Chipaca | https://github.com/snapcore/snapd/pull/5469 fwiw | 09:35 |
| mup | PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5469> | 09:35 |
| mvo | Chipaca: nice | 09:36 |
| * om26er is trying to convert a RaspberryPi into a print sharing server in our co-working space. | 09:36 | |
| popey | om26er: google cloud print? | 09:37 |
| mvo | om26er: till did some works on a cups snap recently maybe he can help | 09:38 |
| Chipaca | mvo: yep, that's printing-stack-snap | 09:38 |
| Chipaca | lots of good info in that forum post | 09:39 |
| mvo | nice | 09:40 |
| om26er | @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:40 |
| popey | om26er: I'm not sure tbh. But I have seen people use it to share printers easily, especially older USB printers. | 09:42 |
| zyga | 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 |
| zyga | 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 |
| zyga | at some point any chrome installation was able to be the helper host | 09:43 |
| zyga | and would allow a Chromebook print | 09:43 |
| mborzecki | zyga: any chrome installation? sounds scary | 09:47 |
| zyga | I think you have to enable it but yeah | 09:47 |
| zyga | the idea was that there would be _someone_ with a windows + chrome laptop or desktop | 09:47 |
| mborzecki | next step, print still from chromecast :) | 09:47 |
| zyga | that would share a "legacy" printer | 09:47 |
| mborzecki | as in the chromecast dongle | 09:48 |
| mborzecki | mvo: any idea what's the status of cups snap? | 09:50 |
| mvo | mborzecki: no, sorry, I did not follow it closely | 09:50 |
| sil2100 | mvo: since the issue is still around, I have also poked mwhudson to help out since he does own a dragonboard himself | 09:54 |
| mvo | sil2100: aha, nice | 09:54 |
| mvo | 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(?) | 09:56 |
| mup | PR snapd#5962 opened: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962> | 10:18 |
| ogra | 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 |
| sil2100 | mvo: we didn't have debugging symbols in probert? | 10:22 |
| mvo | ogra: sure | 10:22 |
| mvo | sil2100: iirc we didn't when we poked at it in brussels | 10:22 |
| mup | PR snapd#5963 opened: tests/hotplug: spread test for hotplug based on dummy interface <Hotplug š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5963> | 10:24 |
| sil2100 | mvo: ok, I'll look at that in a minute | 10:26 |
| mup | PR snapd#5952 closed: tests/ifacestate: moved asserts-related mocking into helper <Hotplug š> <Simple š> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5952> | 10:38 |
| mborzecki | 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 |
| mup | PR #5960: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960> | 10:40 |
| mborzecki | and then we can bikeshed about error messages :) | 10:40 |
| zyga | brb | 10:43 |
| zyga | while it's sunny and lovely outside | 10:43 |
| zyga | I think I have a cold | 10:43 |
| zyga | so ... brb | 10:43 |
| Chipaca | mborzecki: sgtm | 10:50 |
| Chipaca | hmm, hmm | 10:50 |
| Chipaca | not sure 'cannot validate' is the right way to say 'we validated it, and found it lacking' | 10:51 |
| zyga | cannot allow | 10:53 |
| Chipaca | mborzecki: I think context should be added by the caller | 10:54 |
| Chipaca | that is | 10:54 |
| Chipaca | "cannot validate snap 'foo': %v" should be what the caller of Validate() does | 10:55 |
| Chipaca | not Validate itself | 10:55 |
| Chipaca | because | 10:55 |
| Chipaca | then you can say "cannot pack thesnap/" or "cannot install some.snap" or ā¦ | 10:56 |
| Chipaca | instead of having "cannot pack thesnap/: cannot validate "the.snap": ā¦" | 10:56 |
| mborzecki | mhm | 10:56 |
| Chipaca | but maybe that's too hard :) | 10:56 |
| zyga | good point Chipaca | 10:57 |
| Chipaca | we already mostly do this | 10:57 |
| Chipaca | we do os.MkDir() and then "cannot mkdir: %v"; we don't expet MkDir to have the context | 10:57 |
| Chipaca | but when we write both sides of the code it's harder to remember, i guess | 10:58 |
| Chipaca | dunno | 10:58 |
| Chipaca | maybe i just need lunch | 10:58 |
| pedronis | 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:13 |
| dot-tobias | 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 |
| mborzecki | 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:15 |
| zyga | 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 | |
| zyga | feels appropriate somehow | 11:16 |
| pedronis | mborzecki: I see, no I hadn't looked at it, yes seems to go were I was thinking | 11:17 |
| pedronis | *where | 11:17 |
| dot-tobias | zyga: Thanks, will keep a watch on the room list then š | 11:17 |
| zyga | dot-tobias consider asking on the forum as well | 11:17 |
| mborzecki | pedronis: cool | 11:17 |
| dot-tobias | zyga: Will do that | 11:17 |
| sil2100 | mvo: btw. did you see my e-mail question about the inconsistency in new model assertion names for core18? | 11:20 |
| pstolowski | mvo: the hooks optimization looks promising, i did the change but need to accomdate a large number of existing tests which inspect tasks | 11:27 |
| mvo | pstolowski: great, thanks for this heads up | 11:30 |
| mvo | rbasak: I followed up on 1796017 we can sync up after lunch, my comments are probably not super helpful :/ | 11:38 |
| * mvo lunch | 11:38 | |
| * pstolowski lunch | 11:46 | |
| sergiusens | dot-tobias: sort of, but mind asking that on the forum so everyone benefits from the full answer? | 11:47 |
| * Chipaca lynch | 11:48 | |
| ogra | whom ? | 11:51 |
| ak2766 | 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 |
| zyga | that the publisher is *verified* | 11:54 |
| pedronis | identity wise | 11:55 |
| ak2766 | @zyga - thanks - I was overthinking it then... | 11:55 |
| ak2766 | @pedronis - thanks too | 11:56 |
| Chipaca | ak2766: what were you thinking it was? | 12:01 |
| Chipaca | ak2766: and, how could we improve the output of 'snap list --help' to better explain it? | 12:01 |
| zyga | Chipaca: [ v - identity of the publisher has been verified] (legend) | 12:02 |
| Chipaca | zyga: wasn't asking you :-Ć¾ | 12:02 |
| Chipaca | (we trialled legends and they didn't really work) | 12:03 |
| Chipaca | they're helpful the first N times, and then just get in the way | 12:03 |
| Chipaca | where N is ā¦ hard to get right | 12:03 |
| Chipaca | (because I looked at only showing the legend the first N times :) ) | 12:03 |
| rbasak | mvo: ack | 12:04 |
| mup | PR snapd#5960 closed: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5960> | 12:04 |
| * Chipaca remembers he had lunch cooking and goes to tend to it before the fire alarm does | 12:05 | |
| Chipaca | the report of my lunch's death was an exaggeration | 12:08 |
| === chihchun is now known as chihchun_afk | ||
| dot-tobias | 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:21 |
| jdstrand | zyga: I wonder if it is possible to optimize the fastpath-- ie, when everything goes right, which is the normal case | 12:38 |
| zyga | yes, I believe so | 12:38 |
| zyga | do you have in your backlog the discussion between mvo, pstolowski and me? | 12:39 |
| jdstrand | 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 |
| jdstrand | (which I know you know, I phrased it that way for others in the channel) | 12:39 |
| jdstrand | zyga: I do | 12:39 |
| zyga | ah. ok :-) | 12:40 |
| jdstrand | s/now/no/ | 12:40 |
| jdstrand | I mean, I know the reason. I mean, there is no reason we have to do it that way :) | 12:40 |
| jdstrand | 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 |
| jdstrand | I don't have anything specific to suggest; just posing the question | 12:41 |
| sil2100 | 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 |
| pedronis | sil2100: it's not a question for me, it's more mvo | 12:42 |
| pedronis | but afaict they are decided | 12:43 |
| pedronis | *afaik | 12:43 |
| sil2100 | That would be too bad! | 12:43 |
| sil2100 | Oh well | 12:43 |
| sil2100 | mvo: once you're back ^ | 12:43 |
| zyga | jdstrand: the failure case is, I think, to just abort the op and re-setup security in the undo path | 12:43 |
| zyga | (with no optimisations) | 12:43 |
| zyga | I think it's not that hard as I initially thought actually | 12:43 |
| zyga | because the bulk of it is in the auto-connect logic | 12:44 |
| ak2766 | @Chipaca - I was thinking it had something to with whether it was a full container or needed --devmode... | 12:44 |
| zyga | that is one function | 12:44 |
| zyga | where we can just buffer the changes | 12:44 |
| zyga | post-process them | 12:44 |
| zyga | and then execute whenever someone needs to observe the current state | 12:44 |
| Chipaca | ak2766: aha | 12:44 |
| Chipaca | ak2766: if it needed devmode you wouldn't see it in 'snap find', fwiw | 12:44 |
| Chipaca | ak2766: and in snap list, it'd say devmode in the notes | 12:44 |
| Chipaca | i'll be adding colour to the notes sometime soon | 12:44 |
| jdstrand | 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 |
| zyga | for ... in auto-connect-things { connect(plug, slot) and mark security as dirty; if hook { make security clean }; } make security clean; | 12:45 |
| ak2766 | 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:45 |
| zyga | jdstrand: apart from writing tests changes it should be fairly small | 12:46 |
| zyga | (involving no new backend logic probably) | 12:46 |
| Chipaca | ak2766: glad to know it's being useful; do let us know when we mess up :) | 12:46 |
| jdstrand | +1000 :) | 12:46 |
| zyga | *probably* | 12:46 |
| jdstrand | :) | 12:46 |
| zyga | I didn't think deeply about interaction with other backends though | 12:46 |
| zyga | shall we buffer for everything | 12:46 |
| zyga | or just special case apaprmor | 12:46 |
| zyga | if we special case it is the case we thought about before | 12:46 |
| zyga | but I think we should not special case | 12:46 |
| zyga | to be even more efficient | 12:47 |
| zyga | and have predictable properties (no intermediate state) | 12:47 |
| jdstrand | 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 |
| zyga | I'm happy to do this after user mounts | 12:47 |
| jdstrand | udev is just writing out files | 12:47 |
| zyga | yeah and also totally generic in that sense | 12:47 |
| zyga | less udev triggers, less apparmor, less seccomp, less selinux relabelling or what else we need to do | 12:47 |
| jdstrand | I mean, it would benefit for efficiency, but maybe not phase 1 | 12:47 |
| jdstrand | actually, there is the trigger, yes. probably should include that too | 12:48 |
| zyga | 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 |
| zyga | (in my head this doesn't change regular connect / disconnect) | 12:48 |
| jdstrand | wfm | 12:49 |
| zyga | anyway, just an idea, I didn't attempt this yet so there may be something we've missed | 12:49 |
| mvo | sil2100: I will reply in a bit, have not seen it | 12:49 |
| ak2766 | @Chipaca - definitely will - if I needed to post to a forum, do you have something akin to https://stgraber.org/ | 12:50 |
| jdstrand | zyga: right. the idea is each of the backends knows the difference between dirty and clean | 12:50 |
| Chipaca | ak2766: https://forum.snapcraft.io (in the topic in case you forget) | 12:50 |
| jdstrand | zyga: dirty is writing out the files. clean is running some command on them | 12:50 |
| ak2766 | @Chipaca - I've just joined snapcraft.io | 12:50 |
| jdstrand | zyga: that should work | 12:50 |
| zyga | jdstrand: perhaps, though I would even avoid writing the files, dirty is we know we want to do it and that's that; | 12:50 |
| zyga | we can always compute the current state | 12:51 |
| zyga | clean is that we actually do it because someone wants to use the state | 12:51 |
| zyga | this way backends don't change | 12:51 |
| jdstrand | zyga: the only trick is ensuring that we never end up in a permanent dirty state | 12:51 |
| zyga | well, that's nice too | 12:51 |
| zyga | dirty state is ... nothing happened :) | 12:51 |
| zyga | we have a connection in the state | 12:51 |
| * Chipaca ~> cuppa tea and something to much during the meeting | 12:51 | |
| zyga | but nothing else | 12:51 |
| zyga | so on reboot we will setup security and things will be back to normal | 12:51 |
| zyga | (in case we lose power in the dirty state) | 12:51 |
| zyga | but I would only record the connection changes of auto-connect *after* we clean after the loop | 12:52 |
| jdstrand | zyga: well, the thing is, we need the thing being written out to disk to be all of them, but the command to run them to only be at the end | 12:52 |
| niemeyer | Folks, I've got a conflicting meeting today at the same time as our standup, please don't wait for me.. I'll join if it doesn't happen or ends early | 12:52 |
| zyga | jdstrand: yes but I think that approach is more complex | 12:53 |
| jdstrand | zyga: I think that requires a small change to the backends, no? | 12:53 |
| zyga | it doesn't harm us not to write anything | 12:53 |
| zyga | we don't call backend.setup at all until all of the connections are established | 12:53 |
| jdstrand | no, it wouldn't. assuming we end up with the same thing written out | 12:53 |
| zyga | well, that's guaranteed by the design of the security model | 12:53 |
| zyga | based on the ensure logic | 12:53 |
| jdstrand | zyga: I'm thinking: plugs: [ a, b, c ] | 12:53 |
| zyga | I think that's easier | 12:53 |
| mup | PR snapd#5949 closed: osutil,asserts,daemon: support force password change in system-user assertion <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5949> | 12:53 |
| zyga | niemeyer: ack | 12:53 |
| jdstrand | zyga: but only c is plugged at the end when the command is run (ie, we forgot to record a and b into the files written to disk) | 12:54 |
| zyga | jdstrand: btw, I wrote something I want to share, a detailed walkthrough through snap-confine, I want to have this in the forum so that people can review my persistent per-user mount namespace patches | 12:54 |
| mup | PR snapd#5964 opened: overlord/snapstate: export getFeatureFlagBool <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5964> | 12:54 |
| zyga | jdstrand: that's the thing | 12:54 |
| jdstrand | zyga: re aside> we had something like that before. it is good to have it updated | 12:54 |
| zyga | jdstrand: in the idea where we don't run setup at all | 12:55 |
| zyga | jdstrand: the fact that [a, b, c] are connected is not known to anyone but the auto-connect loop | 12:55 |
| zyga | once we are done we setup security for the set of affected snaps | 12:55 |
| zyga | and that's that | 12:55 |
| zyga | before we start that setup nothing on the system knows about the connection (not even snapd state) | 12:55 |
| jdstrand | zyga: I see. I haven't looked at all the code in a very long time. I'm not saying there is a problem or advocating a solution. I'm just describing what I'd be concerned about | 12:55 |
| zyga | jdstrand: right | 12:55 |
| zyga | jdstrand: after thinking about it briefly earlier today I changed my mind about teaching backends about this | 12:56 |
| zyga | because precisely this is less complex to do correctly | 12:56 |
| jdstrand | zyga: hey, that's great :) | 12:56 |
| zyga | we can only forget to setup security in the end, and that implies the connection is just absent | 12:56 |
| zyga | so that's not any more dangerous | 12:56 |
| zyga | I was really only concerned about hooks | 12:56 |
| zyga | because hooks do need to see the partial state | 12:57 |
| zyga | but current logic has no distinction between a hook that exists for sure | 12:57 |
| zyga | and a hook that simply may exist | 12:57 |
| zyga | so it's hard to optimise if the sequence is like | 12:57 |
| zyga | [compute-intermediate-1, maybe-observe-1, compute-intermediate-2, maybe-observe-2, ...] | 12:57 |
| zyga | pstolowski is looking at discarding the maybe-observe-N that really are no-ops | 12:57 |
| zyga | so that we know exactly when to setup security | 12:57 |
| zyga | it is also interesting that the security setup involves a subset of affected snaps | 12:58 |
| jdstrand | I dont follow that last sentence | 12:58 |
| zyga | but effectively in the end the full set is obtained | 12:58 |
| zyga | a simple example | 12:58 |
| mup | PR snapd#5965 opened: interfaces/tests: use TestInterface instead of a custom local helper <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5965> | 12:58 |
| zyga | we auto connect core | 12:58 |
| pstolowski | pstolowski: what is maybe-observe-*, sorry? ;) | 12:58 |
| zyga | and there are two snaps [a, b] that connect network | 12:59 |
| zyga | we get core:network a:network | 12:59 |
| zyga | and core:network b:network (well, swapped around but you get the idea) | 12:59 |
| zyga | assuming that both have hooks that need to observe the network being connected | 12:59 |
| zyga | we need to setup security for (core, a), (core, b) | 12:59 |
| zyga | where ( ... ) denotes the set of snaps affected by a connection | 12:59 |
| zyga | we don't need to re-setup security for a when we do the intermediate state for b | 13:00 |
| pstolowski | i'm looking at not creating prepare-* or connect-* hook tasks at all if they are no-ops (ie. hooks not present) | 13:00 |
| zyga | pstolowski: that's perfect, that is what I meant | 13:00 |
| pstolowski | okay | 13:00 |
| pstolowski | it's not affecting profile generation at all, but it should save some cycles as we serialize hooks execution | 13:00 |
| zyga | +1 | 13:01 |
| cwayne | sil2100: heya, so one thing we found in testing: whenever the 3b+ reboots were getting a new MAC address | 13:03 |
| jdstrand | mvo: where are we in the 2.36 cycle? is there time to get stuff in? | 13:04 |
| jdstrand | mvo: hi btw :) | 13:04 |
| mvo | jdstrand: in a meeting - but yes, still time until later today | 13:05 |
| mvo | jdstrand: but there may be exceptions for you | 13:05 |
| sil2100 | ogra: ^ | 13:06 |
| zyga | mvo: ^ | 13:06 |
| sil2100 | cwayne: hm, thanks | 13:06 |
| sil2100 | cwayne: I wonder if ogra saw the same thing during his testing | 13:06 |
| ogra | sil2100, worth filing a bug but not worth holding back the image for IMHO | 13:06 |
| ogra | i didnt actually check the MACs i must admit | 13:07 |
| ogra | but the b+ uses a new ethernet NIC so it is well possible | 13:07 |
| ogra | we can add a fix for this in later iterations | 13:07 |
| sil2100 | ogra: yeah, if it's something we can fix out-of-image then +1 on that | 13:07 |
| ogra | well, it might need a new gadget at some point and the payload in the gadget isnt upgradeable (only metadata) ... so it might also need a new image eventually | 13:08 |
| ogra | but having a b+ image with changing MAC is still better than not having a b+ image at all | 13:08 |
| jdstrand | mvo: there are 2 maybe 3 things: https://github.com/snapcore/snapd/pull/5739, then an upcoming k8s interfaces PR (profile updates with 2 new interfaces) and possibly a 'miscellaneous profile updates' PR. I don't know how feasible it is for all of it. I know kjackal_bot *really* wants 5739 and it is passing now | 13:08 |
| ogra | we have many peopel eagerly waiting for it | 13:08 |
| ogra | *people | 13:09 |
| mup | PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739> | 13:09 |
| sil2100 | ogra: a bit troublesome then, we'd have to mention that in some release notes | 13:09 |
| ogra | yes | 13:09 |
| sil2100 | Not sure if we have any for core16 | 13:09 |
| ogra | you can mention it in the forum thread wher people are sitting and tapping their feet | 13:10 |
| ogra | sil2100, https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 | 13:11 |
| sil2100 | lool: hey! Since you were the one requesting the pi3b+ support first hand, would you be fine with images that don't have constant MAC addresses? | 13:11 |
| ogra | sil2100, i'll start working on that in ~10 days and produce a fix ... currently i#m just busy with preparing for IoT worldcongress and next week i'll persent there ... after that i can take care of that bug ... but i dont think we should delay the image another two weeks | 13:12 |
| cwayne | sil2100: from our end we'd definitely prefer it fixed first | 13:13 |
| cwayne | plars: ^ | 13:13 |
| ogra | k | 13:13 |
| plars | it's a serious problem for anyone who needs to access it remotely | 13:13 |
| ogra | i think cwayne is authoritative here | 13:13 |
| cwayne | As it is it will mess with our lab setup | 13:13 |
| ogra | ok | 13:13 |
| cwayne | ogra: <3 | 13:13 |
| ogra | sil2100, then i'm with plars and cwayne | 13:13 |
| ogra | i'll try to squeeze in some time tomorrow, perhaps the fix is simple | 13:14 |
| ogra | (with luck is its just an addition to the devicetree ... and worst case it needs the same initrd scrit the dragonboard uses, bth are fixable via the kernel snap) | 13:15 |
| cwayne | We're happy to help and test along the way ogra | 13:15 |
| ogra | ok | 13:15 |
| ogra | cwayne, plars i assume thats only with wired ? | 13:15 |
| ogra | (wlan should be identical to the normal pi3) | 13:15 |
| cwayne | That's my understanding | 13:15 |
| ogra | good | 13:15 |
| mup | PR snapcraft#2342 opened: nodejs plugin: update to the latest 8.x LTS version <Created by anthonyfok> <https://github.com/snapcore/snapcraft/pull/2342> | 13:15 |
| sil2100 | ogra, cwayne, plars: yeah, +1 on that | 13:16 |
| ogra | btw https://snapcraft.io/mac-spoofer :P | 13:17 |
| sil2100 | lool: ^ | 13:17 |
| sil2100 | The problem is, this week probably we'll be switching off core16 image builds for a bit to enable core18 ones | 13:17 |
| sil2100 | We want to enable core18 ones but then we'll have to wait for a livecd-rootfs SRU to get released in xenial to be able to switch on core16 ones again | 13:18 |
| ogra | and here we go: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/lan78xx.c?id=760db29bdc97b73ff60b091315ad787b1deb5cf5 | 13:18 |
| ogra | ppisati, ^^^ do you know if we have this in the pi 4.4 kernels ? | 13:19 |
| sil2100 | If that's it then we'll need a new image for the fix indeed | 13:20 |
| ppisati | ogra: i think we do | 13:21 |
| ogra | sil2100, nah, if this one fixes it we only need a kernel update | 13:22 |
| ppisati | let me check | 13:22 |
| ogra | sil2100, the prob is if there are bits needed in the u-boot config or a u-boot patch ... then we need a new gadget and gadgets are not upgradeable (you are stuck with the first bootloader binary and config you install on core) | 13:22 |
| ppisati | ogra: nak, we don't have it | 13:23 |
| ogra | thought so | 13:23 |
| ppisati | ogra: do we need that? i guess so | 13:23 |
| ogra | ppisati, think it is hard to add ? | 13:23 |
| ppisati | ogra: nah, it appears easy | 13:23 |
| ogra | it would be helpful indeed :) | 13:23 |
| sil2100 | ogra: don't we have the kernel in the boot partition as well? Oh, or is this built as a module? | 13:23 |
| ppisati | ogra: i'm working on mvo's rasp3b+ regression, i'll move to this immediately after | 13:23 |
| ogra | i still need some idea how to injetc a fixed MAC into the DT though ... | 13:23 |
| ogra | sil2100, the kernel in the boot partition gets updated when the snap gets updated | 13:24 |
| ogra | ppisati, <3 | 13:24 |
| sil2100 | ogra: ok, nice | 13:24 |
| ogra | sil2100, the only non-upgradeable bit is the bootloader (sadly) | 13:24 |
| ogra | fixes in that area require a re-flash | 13:25 |
| ogra | (and new image indeed) | 13:25 |
| pstolowski | mborzecki: zyga can you take a look at #5964 and #5965? these are real trivials | 13:27 |
| mup | PR #5964: overlord/snapstate: export getFeatureFlagBool <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5964> | 13:27 |
| mup | PR #5965: interfaces/tests: use TestInterface instead of a custom local helper <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5965> | 13:27 |
| mvo | ppisati: oh, nice! could you reproduce the no-carrier on eth0? | 13:27 |
| zyga | done | 13:29 |
| jdstrand | zyga: would you mind taking a look at https://github.com/snapcore/snapd/pull/5739 ? You have a request changes and I've fixed it and it passes | 13:32 |
| mup | PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739> | 13:32 |
| zyga | not at all, looking | 13:32 |
| mborzecki | jdstrand: can you take a look at https://github.com/snapcore/snapd/pull/5947 ? there's one trivial commit to interfaces/builtin which may be of interest to you | 13:35 |
| mup | PR #5947: many: cleanup remaining parallel installs TODOs <Parallel installs ā> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947> | 13:35 |
| jdstrand | mborzecki: done | 13:37 |
| mborzecki | jdstrand: thanks! | 13:37 |
| zyga | jdstrand: replied :) | 13:39 |
| zyga | jdstrand: this is nice because we could use something similar for parser bugs eventually | 13:40 |
| zyga | jdstrand, roadmr: is the review tools bug that I bumped into last week really fixed | 13:44 |
| zyga | I mean fedora29 snap I uploaded and hit that cleanup issue | 13:45 |
| mup | PR snapd#5964 closed: overlord/snapstate: export getFeatureFlagBool <Simple š> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5964> | 13:45 |
| ppisati | mvo: yes, and i'm debugging it | 13:45 |
| zyga | I'm asking because I tried to upload it again and hit the same error | 13:45 |
| roadmr | zyga: I haven't yet deployed the updated reviewer-tools to the store :/ working on it | 13:45 |
| zyga | roadmr: ah, thank you for the explanation | 13:45 |
| roadmr | zyga: so it is fixed in the tools themselves but I'm not yet using the fixed version | 13:45 |
| zyga | no worries! | 13:45 |
| zyga | it's not urgent | 13:46 |
| roadmr | zyga: if all goes well, it'll be out today. | 13:46 |
| mup | PR snapd#5965 closed: interfaces/tests: use TestInterface instead of a custom local helper <Simple š> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5965> | 13:48 |
| mvo | ppisati: awesome, thank you ! | 13:48 |
| mborzecki | zyga: do you know if it's really broken? https://www.reddit.com/r/linux/comments/9n50ba/lets_see_why_flatpak_and_sandboxing_are_awesome/e7kld6h/ | 13:49 |
| mvo | jdstrand: thanks for the update. I have a look at 5739. do you have an estimate when the other bits you plan will be ready? (roughly?) | 13:50 |
| jdstrand | mvo: I will have the feedback from zyga addressed for 5739 in a few minutes (running ./run-checks now) | 13:52 |
| jdstrand | mvo: I will do the fast parts of miscellaneous profile updates next (~1 hour?). I will move to the k8s PR next. a few hours I would say | 13:54 |
| mup | PR snapd#5966 opened: snap: overhaul validation error messages <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5966> | 13:56 |
| jdstrand | zyga: responded to feedback: https://github.com/snapcore/snapd/pull/5739 | 13:56 |
| * zyga -> walk | 13:56 | |
| mup | PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739> | 13:56 |
| rbasak | Does anyone else always forget whether they're in a snap run --shell or not? A PS1 change would be nice, though I'm not sure if that's appropriate for snap run to arbitrarily do by default. | 13:57 |
| zyga | jdstrand: +1 | 13:57 |
| jdstrand | rbasak: since it went to the group I'll chime in and say I've never forgotten that :) | 13:57 |
| jdstrand | zyga: thanks! | 13:58 |
| jdstrand | mvo: ok, zyga approved 5739 and all feedback is addressed. spread is running (it took 4 times yesterday for a good run yesterday (unrelated to my changes)). do you want a 2.36 PR? | 13:59 |
| * cachio afk | 13:59 | |
| niemeyer | Chipaca: Before you spend time on it, added some comments on the --lines topic | 14:11 |
| Chipaca | niemeyer: the problem is that, right now, the results you see if you don't scroll are the least relevant | 14:12 |
| Chipaca | we could also auto-pager, but some people don't like that :) | 14:13 |
| niemeyer | Chipaca: It's a common behavior to have more relevant at the top | 14:13 |
| Chipaca | oh, it's the right thing to do, to have the most relevant at the top | 14:13 |
| Chipaca | i don't mean to imply otherwise | 14:13 |
| niemeyer | Chipaca: If the list is too long, either I want to see a long list so I can go through it, or my search was poorly done | 14:14 |
| niemeyer | Chipaca: In the first case, I want to see the list.. in the second case, I may opt to reissue the command with a better search instead of knowing about 25 results | 14:14 |
| mvo | jdstrand: no need for a 2.36 pr right now, I will merge master back (not that many changes so far) | 14:15 |
| mvo | jdstrand: and some hours sounds fine | 14:15 |
| mborzecki | zyga: i'm thinking of tuning the spread tests to do https://paste.ubuntu.com/p/q5skPJqRXg/ on case by case basis | 14:16 |
| niemeyer | Chipaca: Do you have sample searches that made you wish for the change in behavior? | 14:23 |
| Chipaca | niemeyer: some simple and perhaps over-broad ones, like 'snap search game' | 14:24 |
| Chipaca | niemeyer: or 'snap search developer' | 14:24 |
| jdstrand | mvo: great, thanks! | 14:25 |
| niemeyer | Chipaca: Interesting.. these are good examples of the two cases I mentinoed | 14:25 |
| niemeyer | Chipaca: Searching for developer is a bit pointless, so improving the parameter would be better.. searching for game, clearly one wants to browse through results | 14:25 |
| Chipaca | niemeyer: snap find 'developer tool' :) | 14:26 |
| Chipaca | but, yeah | 14:26 |
| Chipaca | i do see your point | 14:26 |
| Chipaca | niemeyer: next time i come across a really bad one i'll take note :) | 14:27 |
| zyga | re | 14:27 |
| zyga | mborzecki: +1, this is why I introduced the command in the first place | 14:27 |
| mborzecki | zyga: yup, now with the profile info and features we can pick an choose | 14:28 |
| zyga | and have better coverage | 14:28 |
| mborzecki | if opensuse leap 15 was in we could use that too | 14:28 |
| mborzecki | zyga: it had the right kernel if i'm not mistaken? | 14:29 |
| mborzecki | or was it just TW? | 14:29 |
| zyga | TW | 14:40 |
| zyga | leap 16 will be good | 14:40 |
| zyga | Chipaca: snap find "for raspberry pi" | 14:42 |
| rbasak | mvo: around? | 14:45 |
| rbasak | mvo: your suggestion actually works well for me. | 14:45 |
| rbasak | And allows me to fix it for now at least I think. | 14:45 |
| rbasak | mvo: http://paste.ubuntu.com/p/Yx2f4gKM55/ | 14:46 |
| rbasak | Because quilt calls awk via PATH, and that allows me to insert a wrapper. | 14:46 |
| rbasak | More generally, could you use patchelf or whatever to make all paths to the loader in the core snap relative? Would that break anything? | 14:47 |
| * rbasak wonders if the kernel will even accept that | 14:47 | |
| mvo | rbasak: nice | 14:47 |
| mvo | rbasak: I guess we could its just risky | 14:48 |
| mvo | rbasak: patchelf sometimes also is called breakelf | 14:48 |
| mvo | rbasak: we had some known issues (to be faire mostly with go binaries) | 14:48 |
| rbasak | What role does the core snap play for classic snaps? | 14:49 |
| mvo | rbasak: none really, I mean classic snaps mostly deliberately avoid it | 14:50 |
| mvo | rbasak: for the reasons we ran into, its hard to use it from a classic snap | 14:50 |
| rbasak | nacc is offline right now | 14:50 |
| rbasak | I wonder what caused the use of the core snap like we're doing in git-ubuntu in the first place. | 14:50 |
| rbasak | Because another way to solve this would be to build our own awk. | 14:50 |
| rbasak | And avoid the core snap altogether - which I think is the default if we don't point to it? | 14:51 |
| mvo | rbasak: or just include the one from the distro via stage-packages | 14:51 |
| mvo | rbasak: but yeah, thats probably easier and more controlled | 14:51 |
| rbasak | Good point :) | 14:51 |
| mvo | rbasak: i.e. you would know exactly what awk you get (and what quilt etc) so less risk | 14:51 |
| mvo | rbasak: plus these bits are not very big | 14:51 |
| rbasak | Oh. Using stage-packages will make it a symlink to /etc/alternatives | 14:52 |
| rbasak | But that can be hacked around | 14:52 |
| mvo | rbasak: gar | 14:52 |
| mvo | rbasak: I really dislike /etc/alternatives nowdays :) | 14:52 |
| ogra | who doesnt | 14:52 |
| rbasak | :) | 14:52 |
| mvo | jdstrand: do you mind if I commit a unit test to 5739 around release/apparmor.go:probeAppArmorParser ? | 14:53 |
| mup | PR snapd#5967 opened: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug š> <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5967> | 15:05 |
| pstolowski | zyga, mborzecki one more trivial please, if you have a moment: #5967 | 15:05 |
| zyga | sure | 15:05 |
| mup | PR #5967: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug š> <Simple š> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5967> | 15:05 |
| mup | PR snapd#5968 opened: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968> | 15:08 |
| jdstrand | mvo: re 5739> not at all | 15:08 |
| jdstrand | mvo: fyi, https://github.com/snapcore/snapd/pull/5968 | 15:08 |
| mup | PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968> | 15:08 |
| mvo | jdstrand: cool, I updated the 5739 and added a diff with my suggestions - if those look sensible I can commit/push | 15:10 |
| mvo | jdstrand: looking at this new one now | 15:10 |
| mvo | jdstrand: I can also do the tweaks in a followup | 15:11 |
| mvo | jdstrand: its just "sugar" :) | 15:11 |
| jdstrand | mvo: please see the git commit for the dbus private bus for maximum context | 15:11 |
| mvo | ta | 15:11 |
| * Chipaca afk | 15:12 | |
| pstolowski | mborzecki, zyga ty! | 15:14 |
| mvo | zyga: 5867 has a conflict | 15:15 |
| zyga | mmm | 15:15 |
| jdstrand | mvo: ok, I commented in the PR. feel free to adjust based on the paste if so inclined | 15:17 |
| jdstrand | mvo: thanks! | 15:17 |
| mvo | jdstrand: thank you | 15:18 |
| zyga | mvo: resolved inside github | 15:18 |
| zyga | I'll grab coffee, brb | 15:18 |
| mvo | jdstrand: heh - thats what you get with code reviews, conflicting opinions ,) | 15:19 |
| mvo | jdstrand: don't worry I take care of it and we land your PR its fine as is | 15:20 |
| jdstrand | mvo: :) thanks! | 15:20 |
| * jdstrand hugs mvo | 15:20 | |
| jdstrand | mvo: ok, now let me resurrect my k8s branch. this will be a few hours | 15:20 |
| mvo | jdstrand: no worries, I check back later tonight then | 15:21 |
| jdstrand | mvo: if you have to move faster than me, go ahead. I'll let you know if I don't want it for 2.36 | 15:21 |
| jdstrand | but I'm working on it now | 15:21 |
| mup | PR snapd#5969 opened: apparmor: add unit test for probeAppArmorParser and simplify code <Created by mvo5> <https://github.com/snapcore/snapd/pull/5969> | 15:24 |
| zyga | re | 15:25 |
| zyga | reviewed mvo | 15:27 |
| mvo | jdstrand: one more question - since what ubuntu release do we have "unsafe" ? roughtly ? 16.04? 18.04? | 15:27 |
| mvo | zyga: ta | 15:27 |
| zyga | mvo, thank *you* | 15:27 |
| mvo | zyga: I want to do a spread test for this too just to be on the safe side | 15:27 |
| zyga | mvo: note that the original failed in spread, this is why we knew | 15:28 |
| mvo | zyga: heh - tests ftw! | 15:28 |
| === jkridner|pd is now known as jkridner | ||
| jdstrand | mvo: it was introduced in 2016. it is in 2.10.95 which was backported to trusty | 15:39 |
| mvo | jdstrand: thanks, I add a spread test that ensures this works on ubuntu then | 15:40 |
| jdstrand | cool, thanks | 15:41 |
| lool | sil2100: I dont have strong objections about random MAC, but is this a regression specific to that image or 3B+? | 15:42 |
| lool | ogra: ^ | 15:42 |
| lool | sil2100: best to get in touch wiht ogra in general, he understands the lower levels much better than I do | 15:42 |
| cwayne | lool we only saw it on pi 3b+. It would severely impact my teams ability to auto-test it so we'd prefer it fixed before release | 15:44 |
| Chipaca | jdstrand: unit test failure in #5968 | 15:45 |
| mup | PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968> | 15:45 |
| Chipaca | jdstrand: https://travis-ci.org/snapcore/snapd/jobs/440193822#L1540 | 15:45 |
| jdstrand | :\ I ran them locally | 15:46 |
| * jdstrand looks | 15:46 | |
| ogra | lool, sil2100, given that b+ was not supported *at all* before it is indeed not a regression | 15:46 |
| * mvo hugs Chipaca for adding the staged tests in travis | 15:46 | |
| jdstrand | darn it, I didn't run it on that | 15:47 |
| * jdstrand fixes | 15:47 | |
| Chipaca | :-D | 15:47 |
| * Chipaca takes all the hugs he can get | 15:47 | |
| mvo | jdstrand: no worries | 15:47 |
| lool | sil2100: given cwayne's feedback, let's hold on calling this gold I guess | 15:47 |
| mvo | jdstrand: running this is "cheap" now :) | 15:47 |
| lool | ogra, cwayne: any idea on how to fix this? | 15:47 |
| ogra | lool, right, thats the plan | 15:47 |
| lool | is it a boot assets issue? | 15:47 |
| ogra | lool, there is a patch https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/lan78xx.c?id=760db29bdc97b73ff60b091315ad787b1deb5cf5 that allows it to set it from the dtb ... i'll be looking for a way to inject the serial into that from u-boot | 15:48 |
| jdstrand | mvo: I noticed that refactoring. really nice :) | 15:48 |
| ogra | lool, injecting it into the dtb is a boot asset thing (uboot.env most likely) ... the rest is kernel and paolo already agreed to pull that patch into the next kernel | 15:49 |
| lool | ogra: how do the rpi official upstream images manage it? | 15:50 |
| jdstrand | Chipaca (cc mvo): thanks, fixed | 15:51 |
| ogra | lool, not sure but i'll find out ... i know that debian specifically added this kernel patch tough ... | 15:52 |
| niemeyer | Chipaca: This is looking very nice: https://travis-ci.org/snapcore/snapd/builds/440193821 | 15:59 |
| niemeyer | Chipaca: Thank you! | 15:59 |
| ogra | lool, actually the patch comes from raspberrypi.org https://lore.kernel.org/lkml/1524066323-109628-2-git-send-email-phil@raspberrypi.org/ | 16:07 |
| ogra | so i assume they are using it too ... | 16:08 |
| niemeyer | jdstrand: Quick question on #5968 | 16:15 |
| mup | PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968> | 16:15 |
| jdstrand | niemeyer: hi | 16:15 |
| mvo | zyga: one idea 5867 | 16:17 |
| zyga | mm | 16:17 |
| zyga | lookinf | 16:17 |
| zyga | mvo: +1 if you have that handy to push | 16:18 |
| zyga | (my tree is full of user mounts) | 16:18 |
| zyga | nice idea, thank you | 16:18 |
| mvo | zyga: ta | 16:20 |
| mvo | zyga: if your pr is green I will merge and followup, otherwise I can push into the pr | 16:20 |
| mvo | zyga: anyway, I will deal with it :) | 16:21 |
| mvo | Chipaca: you mentioned mksquafs doing the exclude pattern, are you working on this ? it sounds like a great idea the more I look at the snap pack code | 16:21 |
| jdstrand | niemeyer: answered | 16:22 |
| zyga | thank you mvo | 16:22 |
| niemeyer | jdstrand: Thanks for explaining | 16:25 |
| ogra | plars, https://paste.ubuntu.com/p/whNnhnQCRx/ could you cross check if your MAC in the dtb differs ? | 16:34 |
| mup | Bug #1797423 opened: "Channel <blank> for poedit is closed; temporarily forwarding to stable." when amending a locally installed snap <Snappy:New> <https://launchpad.net/bugs/1797423> | 16:34 |
| ogra | if it does we actually only need the patch added to the kernel and should be good to go | 16:35 |
| plars | ogra: hmm, I can't seem to break into uboot from the console, do I need serial for it? | 16:38 |
| ogra | yeah, i guess it defaults to serial input | 16:39 |
| ogra | U-Boot> printenv stdin | 16:39 |
| ogra | stdin=serial | 16:39 |
| ogra | yeah | 16:39 |
| ogra | (though i'm using a kiosk gadget here ... not sure what the generic pi3 one uses, i have used device specific pi gadgets in ages) | 16:40 |
| * ogra checks GH | 16:40 | |
| ogra | https://github.com/snapcore/pi3-gadget/blob/master/uboot.env.in says "stdin=serial,usbkbd" so it should theoretically work | 16:41 |
| smoser | hi. wondering if anyone can help out https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1797218 | 16:41 |
| mup | Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1797218> | 16:41 |
| smoser | at this point, a few hours from final freeze of ubuntu 18.10, it looks like the only possible solution is to drop seeding of snaps in ubuntu cloud images. | 16:42 |
| zyga | smoser: looking | 16:42 |
| zyga | smoser: are cloud images using overlayfs? | 16:42 |
| zyga | smoser: can we pull oops 4d395dae-ccc5-11e8-90ca-fa163e102db1 ? | 16:43 |
| smoser | pull ? | 16:45 |
| ogra | zyga, you mean https://errors.ubuntu.com/oops/4d395dae-ccc5-11e8-90ca-fa163e102db1 ? | 16:45 |
| smoser | one use case for our cloud images (used in maas deployment and other cases) is overlayroot. | 16:45 |
| ogra | https://errors.ubuntu.com/oops/4d395dae-ccc5-11e8-90ca-fa163e102db1 | 16:46 |
| ogra | err | 16:46 |
| ogra | ERROR run hook "install": cannot create lock directory /run/snapd/lock: Permission denied | 16:46 |
| ogra | zyga, ^^^ | 16:46 |
| === pstolowski is now known as pstolowski|afk | ||
| plars | ogra: do I need to do anything before run loadfiles? I get an error | 16:51 |
| plars | ** Bad device 0:1 0x00200000 ** | 16:51 |
| plars | ogra: but fdt print ethernet still gives me output: | 16:51 |
| ogra | nope, loadfiles loads kernel, dtb and initrd ... | 16:51 |
| plars | https://www.irccloud.com/pastebin/ptELLP5i/ | 16:51 |
| zyga | ogra: is this a container? | 16:51 |
| zyga | that's so weird | 16:52 |
| zyga | it feels like a container that runs on snapd with unstacked apparmor | 16:52 |
| ogra | plars, \o/ it differs !! so just the kernel patch is enough ! | 16:52 |
| zyga | smoser: I see | 16:52 |
| zyga | smoser: let me think then | 16:52 |
| ogra | plars, thanks a lot | 16:52 |
| zyga | smoser: can I see such an image somewhere | 16:52 |
| zyga | pull it and boot it in qemu for experiments? | 16:52 |
| plars | ogra: great news! happy to help :) | 16:53 |
| zyga | ogra: thank you for the oops | 16:53 |
| ogra | zyga, no idea, i just gave you the error msg from the oops you mentioned ;) | 16:53 |
| zyga | I suspect I understand the problem | 16:53 |
| zyga | smoser: ^ | 16:53 |
| zyga | smoser: but I need a this image to provide a fix | 16:53 |
| zyga | mvo: ^ if this is true we need this for 18.10 final | 16:53 |
| ogra | lool, so the kernel patch is the right thing, the upstream firmware actually seeds local-mac-address in the devicetree with a unique MAC already, our kernel just doesnt pick it up | 16:54 |
| zyga | smoser, mvo, jdstrand: ^ it seems that cloud images use overlayfs and need extra permissions for our various apparmor profiles | 16:54 |
| lool | ogra: cool | 16:54 |
| zyga | jdstrand: it seems that we cannot create the lock directory because the real permission is /upper/run/snapd/lock or something like that | 16:55 |
| smoser | zyga: you need this image ? | 16:55 |
| zyga | smoser: do you have apparmor denials (domes | grep DENIED) | 16:55 |
| zyga | smoser: please, it would allow me to test and fix this | 16:55 |
| smoser | i provided recreate instructions | 16:55 |
| smoser | and you can download the image from cloud-images.ubuntu.com | 16:55 |
| zyga | thank you | 16:56 |
| ogra | zyga, would be odd if /run was a part of an overlay though, i'd consider that a gross design bug, it should simply be tmpfs | 16:56 |
| zyga | I'll do that now | 16:56 |
| zyga | ogra: well, that is my current theory, more in some time | 16:56 |
| smoser | ogra: right. /run is not a overlay | 16:56 |
| zyga | smoser: which one of http://cloud-images.ubuntu.com/cosmic/current/ should I get? | 16:56 |
| smoser | that would be odd for sure. overlayfs over a tmpfs backed by a tmpfs | 16:57 |
| ogra | heh | 16:57 |
| smoser | i'd get cosmic-server-cloudimg-amd64.img | 16:57 |
| ogra | it would make a funny anecdote though :) | 16:57 |
| zyga | thanks, getting that | 16:58 |
| jdstrand | why are cloud images using overlayfs? | 16:58 |
| zyga | jdstrand: dunno | 16:59 |
| mup | PR snapd#5967 closed: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug š> <Simple š> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5967> | 16:59 |
| zyga | smoser: can you please tell me how to run that image in qemu? | 16:59 |
| ogra | makes them more cloudy ? | 16:59 |
| jdstrand | and yes, why /run of all things? | 16:59 |
| zyga | jdstrand: I suspect they use ephemeral images with overlayfs for Maas | 16:59 |
| zyga | but I'm just guessing | 16:59 |
| zyga | jdstrand: right? :) | 16:59 |
| Odd_Bloke | This was found during curtin testing, so I believe you are correct, this is ephemeral images. | 17:00 |
| smoser | these are just standard images | 17:01 |
| jdstrand | it looks like they are | 17:01 |
| smoser | they're booted with overlayroot=tmpfs | 17:01 |
| smoser | command line | 17:01 |
| zyga | smoser: do I need any magic for cloud init or whatever? | 17:02 |
| Odd_Bloke | Right, but being used in an ephemeral context, right? | 17:02 |
| zyga | I'm not a cloud expert | 17:02 |
| jdstrand | this is currently unsupported, but we have overlayfs detection logic-- it could be updated | 17:02 |
| smoser | you'll need to provide some way to get into the image | 17:02 |
| smoser | either | 17:02 |
| smoser | a.) provide a cloud-init seed of some sort (and have it set a password for login) | 17:03 |
| smoser | b.) mount the image, set a root password, unmount it | 17:03 |
| jdstrand | but just cause snap-confine is updated, doesn't mean snaps are going to run correctly. this is not a bug as much a missing feature | 17:03 |
| zyga | yeah, I agree | 17:03 |
| jdstrand | use of overlayfs is not at all transparent to apparmor | 17:03 |
| jdstrand | that said, I'm surprised other things in the cloud image, like dhclient, would work | 17:04 |
| zyga | smoser: are all cloud images using ovelayfs / - that is - is this a generic problem? | 17:04 |
| jdstrand | (in this ephemeral env) | 17:04 |
| zyga | or can we solve a specific case and be okay because normally they use a regular filesystem? | 17:04 |
| zyga | jdstrand: depending on how this is set up | 17:04 |
| zyga | jdstrand: apparmor.service is not started | 17:04 |
| zyga | jdstrand: so maybe all confinement is off | 17:05 |
| zyga | apart from snapd | 17:05 |
| jdstrand | right | 17:05 |
| zyga | smoser: can you provide a cloud-init blob with some dummy password please | 17:05 |
| jdstrand | so, we could detect this, bump everything down to PartialAppArmor | 17:05 |
| zyga | and show me how to run this? | 17:05 |
| zyga | jdstrand: I believe that we are failing on snap-confine | 17:05 |
| jdstrand | and adjust snap-confine enough to not die | 17:05 |
| zyga | the profile allows it to mkdir /run/snapd/lock | 17:05 |
| zyga | but we cannot | 17:05 |
| zyga | so plain partial would not work | 17:06 |
| zyga | yeah | 17:06 |
| zyga | that might work | 17:06 |
| zyga | *might* | 17:06 |
| zyga | I still don't understand the use of overlayfs and the intent to use snaps in that context fully | 17:06 |
| jdstrand | zyga: yes, I'm assuming we could do something similar for it like with livecd. I'm worried about when snap-confine then runs and tries to launch stuff and all snaps die | 17:06 |
| * jdstrand doesn't either | 17:06 | |
| * jdstrand goes back to k8s | 17:06 | |
| smoser | i updated bug with recreate instructions that are about as simple as possible. | 17:14 |
| zyga | thank you | 17:14 |
| pedronis | smoser: when were snaps added to those? did they work and now they stopped? or just not yet tested in all the relevant situations? | 17:14 |
| smoser | there are a lot of moving parts so its not easy to say. | 17:15 |
| cachio | pstolowski|afk, which hotplugs do you need to simulate? | 17:16 |
| smoser | but i suspect the key change that caused this to fail was the transition of lxd from being installed in the image as a debian package | 17:16 |
| cachio | pstolowski|afk, insert usb? | 17:16 |
| smoser | to being a pre-seeded snap | 17:16 |
| smoser | that happened 10181002 | 17:16 |
| smoser | (https://bugs.launchpad.net/cloud-images/+bug/1796137) | 17:16 |
| mup | Bug #1796137: huge and slow image 20181002 due to seeded lxd snap <cloud-images:Confirmed> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1796137> | 17:16 |
| pedronis | smoser: I see, where snaps not really used until then? | 17:17 |
| pedronis | anywy lxd is one of the most demanding snaps as well | 17:17 |
| pedronis | in terms of moving parts | 17:17 |
| * jdstrand notes that lxd is only shipped as a snap now | 17:18 | |
| smoser | snaps would have been used via user instalaltion or cloud-init '#snap' configuration. | 17:19 |
| pedronis | jdstrand: I know, it still seems that some use case went untested | 17:19 |
| smoser | but probably not in conjunction with overlayroot | 17:19 |
| smoser | the key difference being use cases that did not involve snaps (such as vmtest or maas installation) worked fine | 17:20 |
| smoser | but now use of the system is generally not possible as it never gets fully booted. | 17:20 |
| smoser | in this overlayroot scenario | 17:20 |
| pedronis | smoser: does mass installation need lxd? is that overlayroot situtation temporary, or something the machine then run with forever? | 17:20 |
| smoser | temporary. maas installs in a overlayroot environment. | 17:21 |
| smoser | then reboots into the installed environment. | 17:21 |
| pedronis | but we have one image that now has a lxd snap | 17:22 |
| pedronis | that we don't need | 17:22 |
| pedronis | but tries to be seeded/do stuff ? | 17:22 |
| pedronis | I mean don't need in that situation | 17:22 |
| smoser | "one image" in that yes, one base image is used for many things. | 17:23 |
| pedronis | smoser: are those snaps meant to carry over to the installed environment, or will there be a different boot where snapd is not seeded yet | 17:24 |
| smoser | well, on first boot of the installed environment it will have exactly the same content as the image. | 17:25 |
| smoser | so it will seed its own snap | 17:25 |
| smoser | and will not have been booted with overlayroot | 17:25 |
| pedronis | so the snapd seeding we get in overlayroot env is just unfortunate? it just happens but we don't need it? | 17:26 |
| pedronis | smoser: I'm basically trying to understand if things need to work or just not explode, also it would seem this seeding is a waste (not that we have a clean way to turn it off afaik) | 17:31 |
| pedronis | atm | 17:31 |
| pedronis | zyga: we don't drop connections on refreshes right? unless some plug/slot went away | 17:32 |
| zyga | pedronis: correct | 17:37 |
| smoser | seeding in the overlayroot environment is not needed currently. | 17:39 |
| pedronis | zyga: mvo: maybe the cheapest thing is to somehow fail the sanity check in that env? | 17:44 |
| smoser | if /snap is on a overlayroot, just disable snapd | 17:49 |
| Chipaca | mvo: I'll be looking at using mksquashfs's exclude thing, unless you want to get your hands dirty with that | 17:50 |
| Odd_Bloke | smoser: pedronis: zyga: FWIW, subiquity is a snap that, I think, is in a overlayroot environment and works. | 17:54 |
| Odd_Bloke | So we need to be careful to not turn things off with a big hammer that breaks other use cases. | 17:54 |
| pedronis | Odd_Bloke: intersting, I imagine it's a classic snap tough? | 17:55 |
| Odd_Bloke | Yes, I believe it is. | 17:55 |
| pedronis | yea, it is | 17:55 |
| Odd_Bloke | But that does mean that snapd still needs to function in an overlayroot environment, so I don't think we can just disable it as suggested by smoser. | 17:56 |
| mup | PR snapd#5968 closed: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5968> | 17:57 |
| smoser | yeah, i' not sure how subiquity is working | 17:58 |
| Odd_Bloke | It's classic, so it may just skip the AA stuff that's failing? | 17:59 |
| smoser | fwiw, the ' cannot create lock directory /run/snapd/lock: Permission denied' | 17:59 |
| smoser | is kind of misleading | 17:59 |
| smoser | as | 17:59 |
| smoser | $ ls -l /run | grep snap | 17:59 |
| smoser | srw-rw-rw- 1 root root 0 Oct 11 17:52 snapd-snap.socket | 17:59 |
| smoser | srw-rw-rw- 1 root root 0 Oct 11 17:52 snapd.socket | 17:59 |
| smoser | $ ls -l /run/snapd | 17:59 |
| smoser | ls: cannot access '/run/snapd': No such file or directory | 17:59 |
| smoser | so its not really that it can't create /run/snapd/lock its that /run/snapd does not exist. | 18:00 |
| rharper | smoser: I created that | 18:00 |
| rharper | before snapd starts and it still fails | 18:00 |
| rharper | you can quickly test creating that dir before the snap install on bionic to confirm | 18:01 |
| rharper | I had to use aacomplain on snap-confine to allow it to complete | 18:01 |
| rharper | the trickery IIUC is that snapd has to transition the apparmor rules from /etc/apparmor.d to the verison present in the core snap; the linked bug I found mentions this | 18:02 |
| smoser | Odd_Bloke: do we have evidence that subiquity install works ? | 18:02 |
| smoser | in cosmic | 18:02 |
| Odd_Bloke | smoser: Good question. | 18:02 |
| Odd_Bloke | vorlon: ^ | 18:03 |
| Odd_Bloke | I'm downloading the ISO ATM. | 18:03 |
| mvo | pedronis, smoser just finished reading backlog - having a sanity.Check for this sounds indeed like a great option | 18:05 |
| smoser | well, other than potentially meaning subiquity does not work | 18:05 |
| mvo | smoser: yeah, I lied when I said I read backlog - I wasn't quite finished :/ | 18:06 |
| mvo | smoser: a shame, its a straightforward fix | 18:06 |
| mvo | well "fix" | 18:06 |
| Odd_Bloke | WTB 10G NICs on cdimage.u.c | 18:07 |
| zyga | Iām a bit AFK with the kids but I will resume working in this bug as soon as I can | 18:09 |
| smoser | boot of http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/cosmic-live-server-amd64.iso | 18:12 |
| smoser | seems to get to a place where i could isntall | 18:12 |
| smoser | ie, i think subiquity is running | 18:12 |
| smoser | and 'snap install hello && hello' works | 18:12 |
| Odd_Bloke | hello is confined? | 18:15 |
| Odd_Bloke | Yes. | 18:15 |
| smoser | snap version and uname are the same between the two (comment 11 recreate and core image boot) | 18:17 |
| smoser | err... subiquity boot | 18:17 |
| vorlon | smoser, Odd_Bloke: subiquity absolutely works, every successful install w/ the server live image relies on subiquity as a snap | 18:19 |
| smoser | so whats different? | 18:19 |
| vorlon | classic vs non-classic snap? | 18:19 |
| vorlon | I was aware that non-classic snaps don't work on overlayfs | 18:19 |
| smoser | well, hello works in one and does not in the other. | 18:19 |
| Odd_Bloke | Is lxd in the subiquity image? | 18:20 |
| vorlon | how do you mean, "works in one"? | 18:20 |
| vorlon | I haven't checked if lxd is in the subiquity image. It should be. | 18:20 |
| smoser | snap list in the subiquity image does *not* have lxd | 18:21 |
| smoser | and i did mis-informa bit. | 18:21 |
| smoser | hello works subiquity image (snap install hello, hello) | 18:21 |
| smoser | but fails to install (due to general brokenness) in cosmic | 18:21 |
| smoser | but installs but fails to run in "boot bionic enable overlayroot reboot" case as described in comment 13 | 18:22 |
| vorlon | smoser: the subiquity image has code to prevent re-exec of snapd from the core snap | 18:23 |
| vorlon | did you already handle that? | 18:23 |
| smoser | i did what i showed in that comment. | 18:24 |
| smoser | nothing else. | 18:24 |
| vorlon | what comment? | 18:24 |
| smoser | comment 13 on bug 1797218 | 18:24 |
| mup | Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1797218> | 18:24 |
| vorlon | smoser: https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-server/includes.binary/overlay/lib/systemd/system/snapd.service.d/no-reexec.conf | 18:26 |
| smoser | vorlon: http://paste.ubuntu.com/p/jJDvTgKzwd/ | 18:35 |
| smoser | thats bionic overlayroot -> tmpfs | 18:36 |
| vorlon | smoser: ok. that looks like the known incompatibility between non-classic snaps and overlayfs that we ran into previously. | 18:37 |
| vorlon | I don't know why a 'snap install hello' would work on the subiquity image | 18:37 |
| smoser | well. | 18:37 |
| smoser | http://paste.ubuntu.com/p/PGkK3bfRf9/ | 18:38 |
| vorlon | bionic? | 18:38 |
| smoser | no | 18:38 |
| smoser | that is cosmic | 18:38 |
| smoser | were do writes go on installer environment ? | 18:40 |
| vorlon | tmpfs | 18:40 |
| smoser | ok. i was thinking that might be the difference. | 18:40 |
| vorlon | cosmic is snapd 2.35.4+18.10; bionic-updates is snapd 2.34.2+18.04 | 18:41 |
| smoser | cosmic *image* (that fails entirely differently) is the same version as installer environment. | 18:42 |
| vorlon | which is the cosmic image failure? | 18:43 |
| smoser | as shown in description in 1797218 | 18:43 |
| vorlon | even if you set SNAP_REEXEC=0? | 18:44 |
| smoser | i did not try that. i can quickly. | 18:44 |
| smoser | well, it doesnt seem that reexec change fixes anything | 18:54 |
| smoser | http://paste.ubuntu.com/p/6KB34MctXt/ | 18:54 |
| mvo | 5867 needs a second review | 18:56 |
| mup | PR snapd#5970 opened: snapstate: tweak GetFeatureFlagBool() to have a default argument <Created by mvo5> <https://github.com/snapcore/snapd/pull/5970> | 18:58 |
| vorlon | smoser: is this in the ephemeral boot? | 19:01 |
| vorlon | smoser: I mean, is it the ephemeral boot case being broken that caused you to care about this? | 19:01 |
| smoser | what caused me to care about this is a green dot in jenkins going red. | 19:02 |
| smoser | which is due to vmtest (curtin's test harness) starting to fail | 19:03 |
| smoser | which does use overlayroot | 19:03 |
| vorlon | smoser: workaround forming itself in my mind is for overlayroot package to disable the snapd service when overlayroot is in used | 19:03 |
| vorlon | subiquity uses an overlayfs | 19:03 |
| vorlon | but does not use overlayroot to implement that | 19:03 |
| vorlon | so there'd be no impact to any of the places that snaps on overlayfs currently work | 19:04 |
| smoser | i'd rather understand why. | 19:05 |
| vorlon | sure | 19:05 |
| smoser | and i'd also rather revert the thing that broke this | 19:05 |
| vorlon | but I think the above workaround is something to keep in our back pocket | 19:05 |
| smoser | than make other people change to accomodate | 19:05 |
| vorlon | by which you mean, revert the move of lxd to a snap? | 19:05 |
| smoser | yes | 19:06 |
| mup | PR snapd#5971 opened: interfaces: include invalid type in Attr() error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5971> | 19:07 |
| zyga | re | 20:29 |
| * zyga notices a bit of backlog | 20:29 | |
| cachio | sergiusens, hey, I see some tests related to plainbox failing on snapd sru http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd | 22:13 |
| cachio | sergiusens, any idea if it could be an issue or it is a tests problem? | 22:14 |
| mup | PR snapcraft#2341 closed: schema, meta: support app command-chain <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2341> | 22:25 |
| mup | PR snapcraft#2343 opened: schema, meta: add "full" app adapter <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2343> | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!