Chipacawgrant: should http://cpisnap.ols.internal/api/v1/ still work?00:11
jorianhello, I'm trying to make a snap for openmw (re-implementation of the morrowind game engine) and when trying to launch my snap, I'm getting the error "libGL error: unable to load driver: i965_dri.so"  I think I might be missing a plug.  Does anyone happen to know which plug would make that driver available?  I've tried adding x11, opengl, home, and pulseaudio.01:05
qenghojorian: This may be a red herring, but my question is, is there such a file inside your snap?01:14
jorianqengho: it seems to be in 3 places inside the snap directory01:20
jorianplus in stage and prime01:20
olympionexI'm looking at the guide for creating a snappy interface on zygoon.pl.  The method involves editing the snapd source and the recompiling the whole project.  Is there currently a way to add interfaces externally / by installing a snap similar to how the core snap works?02:07
olympionexI need to create an interface to allow writes to /var/run but I don't really want to have to manage a custom version of snapd02:11
kyrofaThank you wgrant, I appreciate the help!03:09
kyrofaolympionex, the only reason the core snap can make any interface available is because the interfaces it supports are supported by snapd03:10
kyrofaIt's not doing anything special03:10
olympionexkyrofa: thanks -- I see that now looking at the source03:11
olympionexkyrofa: all the interfaces are in snapd itself03:11
kyrofaqengho, if jorian comes back, the gl libs are required in stage-packages. Specifically libgl1-mesa-dri03:11
kyrofaolympionex, indeed: interface SUPPORT is in snapd, but then the producer (slot) side of interfaces must be supplied by a snap, and the consumer (plug) side must be consumed by a snap03:12
kyrofaThe interface being USED by the plug/slot, however, must still be one that's supported by snapd03:12
kyrofaOh wait... qengho nevermind, looks like that lib made it into prime. Just missing the right LD_LIBRARY_PATH then, it seems03:14
olympionexI see - so the content plugin lets a snap provide access to some internal path, but if I want to access some other system path, I will have to add it to snapd03:14
kyrofaolympionex, yes. Although I'm curious about your use-case, do you mind sharing?03:14
olympionexkyrofa: yeah, I just have a binary that I don't have the source to and it creates some socket files in /var/run03:15
kyrofaolympionex, yep that would do it :P . However, have you investigated using LD_PRELOAD to get around it?03:15
olympionexkyrofa: i was using classic mode, and probably still can, but it looks like it changed a bit in 2.22 maybe03:16
olympionexhmm, I'm have a look at that03:16
kyrofa2.22 is a bit behind, 2.25 is out now03:16
kyrofaolympionex, there's a preload part out there already if you want to check it out. Here's an example of how to use it: https://github.com/nextcloud/client_theming/blob/master/linux/snap/snapcraft.yaml#L5003:17
kyrofaCheck out line 34 as well for where it's pulled in03:17
olympionexI actually meant snapcraft 2.22.  The new version doesn't add the library paths to the command wrappers it generates.   I can of course just make my own script that gets called by the wrapper, but I need to research all the consequences.  I was just checking again about running it in strict mode03:18
kyrofaolympionex, in that case it's even older: 2.29 is out :P03:19
kyrofaolympionex, yeah, strict is _always_ best if you can swing it03:19
kyrofaolympionex, classic snaps have trouble running on other distros, and they don't run on ubuntu core either03:19
kyrofaolympionex, definitely worth investigating that preload part, especially considering it's an extra line and a half03:20
wgrantkyrofa: We've identified the two bugs in dashboard.snapcraft.io that combined to cause this issue. It's possible you'll run into similar issues again with that particular snap until we fix the root cause properly, but we know what's going on now so that should be quick.03:20
kyrofawgrant, it's something particular to the snap?!03:21
kyrofaWhat did I break?03:21
wgrantkyrofa: A review race caused one of the revisions to get stuck in a bad state, and that will possibly confuse further automatic refuses until we fix that old revision.03:22
wgrantHopefully not refusals :)03:22
kyrofawgrant, ah ha, I wondered about that weird rev :P03:22
wgrantThey shouldn't fail, just get stuck03:22
kyrofawgrant, if I reject it, would that fix things?03:22
wgrantkyrofa: Quite possibly. We already know we need to manually fix that revision, so rejecting it can't really make it worse.03:23
wgrantSo might be worth a try.03:23
* kyrofa tries03:23
olympionexkyrofa: fortunately i have a limited set of systems I have to run on.  I use snapcraft to simply our internal deployment of some software.  Still, i prefer to get things working in the most supported way to avoid suprises later.03:24
kyrofaolympionex, understood03:25
wgrantkyrofa: Looks like that's worked.03:26
wgrantSo we just need to manually fix up 1418 later.03:26
kyrofawgrant, no need to worry about that one03:27
olympionexkyrofa: thanks for the preload info, i was  looking at some ELF hacking but this may be cleaner03:28
kyrofaolympionex, yeah that would not be fun03:28
kyrofaAnd of course, any time :)03:28
mupPR snapd#3393 opened: Add retry mechanism for snap install command to fix test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3393>05:56
=== koza|away is now known as koza
=== JanC_ is now known as JanC
=== elfgoh_ is now known as elfgoh
abeatopedronis, mvo mind unblocking re-reviewing https://github.com/snapcore/snapd/pull/3353 ?07:11
mupPR snapd#3353: Add support for reboot parameter <Blocked> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>07:11
zygagood morning07:18
mupPR snapcraft#1333 opened: state: search for the dependencies in the archive <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1333>07:19
pstolowskimorning zyga!07:21
morphiszyga: hey!07:32
morphiszyga: time for a review on https://github.com/snapcore/snapd/pull/3371 ?07:32
mupPR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>07:32
zygamorphis: looking07:35
morphiszyga: CI hates me, another store timeout07:39
morphiszyga: but thanks for approving07:52
morphiszyga: and a review on https://github.com/snapcore/snapd/pull/3365 would be nice too07:52
mupPR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>07:52
zygamorphis: what does it mean https://github.com/snapcore/snapd/pull/3365/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R268 ?08:03
mupPR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>08:03
zygadidn't the pkgdb helper land already08:04
zygasorry, I see08:04
morphiszyga: you can't use it at this place08:04
morphisok :-)08:04
Chipacaooh, listen to the wind!08:05
Chipacait sounds like "reeeeviewwsss"08:05
Chipacagood morning peeps08:05
zygamorphis: done08:09
zygahey Chipaca08:10
* zyga feels miserable08:10
Chipacazyga: :-(08:11
Chipacazyga: did you see the issues ryebot was having yesterday?08:11
zygaChipaca: yes but I didn't manage to reply08:13
Chipacazyga: 's ok; i just don't want to have to remember it myself08:13
Chipacaif you're aware, i can forget08:14
zygathanks :-)08:14
pedronisChipaca: I nitpicked a bit on one of your PRs08:41
Chipacapedronis: good morning to you too :-)08:41
morphiszyga: ok, updated the PR08:42
Chipacapedronis: good points you make08:43
Chipacapedronis: i'm currently working on a bug where we don't distinguish "already at the latest revision on that channel" from "that channel does not exist"08:43
zygaany wording suggestions before I do the full set?08:43
Chipacapedronis: (you can try it! snap refresh core --channel potato)08:44
Chipacapedronis: (then check 'snap info')08:44
zyga(ideally the output would be more consistent)08:44
zygaand not sure what to do with "allows"08:44
zygamaybe just skip it08:44
Chipaca's fun08:44
zygafun fact: we have 91 interfaces08:45
zygaI'll add a 100th anniversary interface ;-)08:45
pedronisChipaca: can we do it without store help?08:47
Chipacapedronis: the store is telling us08:47
Chipaca(more or less)08:47
Chipacapedronis: i'm fixing it alreayd08:48
mvozyga: I don't want to be a party pooper but https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-possible-revert-race-condition/722 is currently higher on the priority list than anniversaries ;)08:48
Chipacapedronis: basically ListRefresh is fine for multi-updates, but we need a special one for single updates that doesn't throw away this info08:48
Chipacapedronis: pretty much exactly the same except if the store returns nothing, raise an error08:48
pedronisChipaca: just telling me why you won't fixing my nitpicks straight away :)08:48
Chipacapedronis: yes, that's exactly what i'm doing08:49
Chipacayou're very perceptive today08:49
pedronisbut inpolite because I didn't say good morning yet08:49
Chipacapedronis: what's a good name for something that does what store.ListRefresh does, but for a single refresh candidate?08:50
zygamvo: you are completely right08:50
zygamvo: I'll finish this PR and send it for review in a moment08:50
zygamvo: but before I do that, let's chat here briefly08:51
zygamvo: if the new syntax is a blocker (I mean |N) then the plan falls apart08:51
mvozyga: yeah, its rather annoying08:52
zygamvo: your plan to compile seccomp profiles in snapd is possible08:52
zygamvo: but, well, needs discussion08:52
zygamvo: we could make a new internal helper08:52
mvozyga: we would have to generate old-style files for a while for backward compatiblity08:52
zygamvo: why? I don't think so08:52
mvozyga: old style with a frozen format so that also is slightly complicated08:52
mvozyga: no?08:52
zygamvo: (just whatever matches snap-confine)08:52
mvozyga: aha, just leave the old ones around :) ?08:52
zygamvo: yes08:52
zygamvo: so we'd stop writing the old files entirely (but not remove them yet)08:53
zygamvo: for revert specifically08:53
mvozyga: hm, that would break in the case of "snap refresh core; snap install hello; snap revert core", then hello would no  longer work. maybe not too terrible08:53
zygamvo: aha08:53
zygamvo: interesting, yes, it would work if snapd would start before "hello" but I see your point08:53
mvozyga: aha, good point08:54
zygamvo: but the bigger issue is that we'd have two seccomp profiles per security tag08:54
zygamvo: one old and one new, with different semantics (because no |N)08:54
mvozyga: yeah, that is the part that worries me, it feels fragile08:54
zygamvo: but if we do that we can use the old text format08:54
zygamvo: because we'd just write two files08:54
zygamvo: one with |N and one without08:54
mvogood point08:54
* zyga greps for |N syntax08:54
mvowell, the seccomp bpf would make us future proof forever(tm)08:55
zygamvo: I agree on that08:55
mvo(needs some research but it looks like bpf is pretty stable as a binary format)08:55
mvozyga: what is weird?08:55
zygamvo: I don't see any |N syntax with quick grep08:56
pedronisChipaca: LookupRefresh ?08:56
zygaare we even using this?08:56
zygamvo: (also it would be faster for startup, which is nice)08:56
mvozyga: let me double check the debdiff08:57
zygamvo: can you grep for anything that uses this08:57
mvozyga: if we are not using it, that would be splendid08:57
* zyga feels sick again 08:57
zygayes :)08:57
zyga(perfect timing, just before a conference)08:57
mvozyga: uh, get some rest if you feel sick, I can work on this08:57
mvozyga: seriously, get well, especially if you need to travel soon08:58
zygamvo: no, I cannot do anything about it :/08:58
mvozyga: meh, ok08:58
zygamvo: I'd rather finish the interface meta-data changes and feel better by doing that08:58
zygamvo: sick as in food-sick, not flu-sick08:58
mvozyga: autsch, ok. all right, I do the investigation on |N while you finish your interface work :)08:59
abeatozyga,  mind unblocking/re-reviewing https://github.com/snapcore/snapd/pull/3353 ?08:59
mupPR snapd#3353: Add support for reboot parameter <Blocked> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>08:59
mvozyga: we use the |S_IFREG in our default template now https://github.com/snapcore/snapd/blob/master/interfaces/seccomp/template.go09:08
mvozyga: I will write a forum topic with some ideas, looks like it is not going to be super simple, but maybe not to hard either09:08
pedronismvo: zyga: one of you should probably review snapd#3350 if we want it in 2.2709:20
mupPR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>09:20
pedronisanyway I suppose 2.27 is delayed by a fair bit because of 2.25 issues?09:21
pedronis*fair bit now09:21
mvopedronis: yeah, there is a slight crisis right now :/09:21
pedronismvo: can't we just change the names of the seccomp profiles ? or start putting them into profiles/something09:22
pedronisand teach 2.26.x snap-confine about new new place09:22
pedroniss/new new/the new/09:23
mvopedronis: probably, there is still this problem that "snap refresh core; snap install daemon; snap revert core" may lead to the same issue we currently having. i.e. the new snapd does only write a new seccomp file but on reboot daemon starts so early that the old snapd does not generate a new seccomp file early enough. but still doing this would probably get us a long way forward09:24
pedronisreverting core after installing new stuff is bound to create troubles anyway in some scenarios09:25
* mvo nods09:26
pedronisI mean can see some non security profiles one09:26
zygamvo: do we use |S_IFREG or just S_IFREG?09:26
zygapedronis: ack09:26
olympionexhas anyone used the snapcraft-preload project?  I'm thinking there is a bug in the preload for the bind method, or possibly there is something i'm not doing.  When creating an AF_UNIX socket, it would seem that it should redirect to a writeable path, but that doesn't seem to be the default behavior, at least for my case.  I have manually patched it on my side and it seems to work, but just wanting to verify.09:27
zygaolympionex: guys who wrote that are in americas so I'd suggest opening a forum topic09:27
mvozyga: the former |S_IFREG09:30
zygamvo: aww, drat09:32
zygamvo: well09:32
zygamvo: plan B09:32
zygamvo: revert that change09:32
zygamvo: like we did before09:32
zygamvo: if it is just one spot it is easier09:33
zygaah, there are a few09:33
zygaall the mknod09:33
zygahmm hmm hmm09:34
mvozyga: yeah09:34
zygamvo: so what is your plan?09:37
morphiszyga: can you merge https://github.com/snapcore/snapd/pull/3371 ?09:38
mupPR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>09:38
mvozyga: I'm still pondering, its tricky. worst case would be to revert the new syntax again, i.e. revert all mknod and keep quotactl via the secompSymbolTable branch. we need jdstrand input here09:39
zygamorphis: done09:39
mupPR snapd#3371 closed: packaging: import packaging bits for opensuse <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3371>09:39
zygamvo: the question is, what do we lose if we do that09:39
zygamvo: was this released in 2.25?09:39
zygaabeato: some feedback09:40
abeatozyga, ok, thanks09:40
abeatozyga, I've answered one of the comments09:48
mvozyga: yeah, the mknod was released in 2.25, I think we need jamies input. but I will also try to find out more09:58
zygamvo: can we replace |foo with a list of rules?09:59
ogra_hmm, so using delta updates on the pi3, the delay is noticeable but not super awful09:59
ogra_i fear that wont be usable on a bbb10:00
mupPR snapd#3388 closed: osutil: add non-blocking flock <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3388>10:00
pedronissorry I did this merge ^ but messed up a bit the commit message, because GH seems very partial on what it remembers or not when you move away and back to a merge in progress10:02
mupPR core#35 closed: move xdg-open to proper paths <Created by ogra1> <https://github.com/snapcore/core/pull/35>10:22
mupPR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>10:22
mupPR core#35 opened: move xdg-open to proper paths <Created by ogra1> <https://github.com/snapcore/core/pull/35>10:23
mupPR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>10:23
Chipacamvo: fgimenez: do you guys have dev access to etcd?10:23
Chipacaactually, i just want to know a revision of etcd that isn't published10:24
Chipacanever mind10:24
fgimenezChipaca: i don't sorry10:24
* Chipaca noticed the store's response10:24
Chipaca$ /tmp/snp install potato --revision 2 --channel whaat10:25
Chipacaerror: snap "potato" not found (at least in channel "whaat/stable" at revision 2)10:25
Chipacaincredible how much work i had to do to get that (at least) there10:25
mupPR snapd#3394 opened: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394>10:27
ogra_mvo, what is linux-armhf ? is that leftover cruft ? https://forum.snapcraft.io/t/issues-while-porting-ubuntu-core-16-image-for-olimex-lime2-platform-board/761 (snap info says its yours)10:31
Chipacathat's an old kernel10:34
Chipacafrom before we could have multiple architectures in the same snap10:34
ogra_i just wonder why it is available10:34
ogra_we did a big cleanup run a while ago10:34
morphiszyga: thanks!10:35
Chipacaogra_: fwiw i can confirm it's in the store10:39
Chipacaat revision 910:39
ogra_Chsure, i wouldnt have pinged if i had not checked it before ;)10:40
ogra_yeah, in all channels10:40
Chipacazyga: gah?10:40
zygaso, interface summary is very confusing to write10:40
zygaas plugs and slots have totally different purpose10:40
zygawhat is a good summary of the "pulseaudio" interface?10:40
zygait's both to be pulseaudio service and to talk to it as a clinent10:41
Chipacazyga: "this interface lets you pulse your audio"10:41
zygashould we have two summary lines per interface? (up to)10:41
Chipacazyga: are both those things available to you when you use it as a slot?10:42
zygaChipaca: no, but this is not about plugs or slots10:42
Chipacazyga: maybe it should be10:42
zygaChipaca: this is about the new "interface" command and interface meta-data10:42
zygaChipaca: what interfaces do you have? (not instances, types)10:42
zygaChipaca: my misery so far10:43
zygaChipaca: maybe "allows operating as or using the pulseaudio service"10:43
Chipacazyga: is the "allows" there something you've agreed to standardize on?10:44
Chipacalooks nasty af10:44
zygano, this is still a prototype10:44
Chipacazyga: how about you drop the allows and verb the thing you have after it?10:44
Chipacazyga: as fireworks10:44
zygaChipaca: yeah, I'm open to suggestions, I'll finish this pass to just have something consistent for each and then propose the bits and pieces10:45
Chipacazyga: i mean: "allows frobbing the plumus" -> "frob the plumbus"10:45
zygathis is just one patch among many and one that I suspect we'll bikeshed the most10:45
zygaChipaca: try this on 5 different real interfaces or it doesn't count10:46
Chipacazyga: i did :-)10:46
zygaChipaca: how about network?10:46
mvoogra_: hm, a very old kernel that I put there for experiments I think, I will unpublish it10:46
Chipacazyga: "access the network"10:46
Chipacazyga: pulsaudio would be, for example, "host or communicate with a pulsaudio server"10:47
ogra_mvo, thanks10:47
mvoogra_: done10:47
Chipacazyga: unity8 would be "aw, bless"10:48
zygaChipaca: kind of like the pulseaudio thing but this is still very confusing IMO, from users POV (no deep insight into plug-vs-slot semantics) there's a lot of difference here10:48
Chipacazyga: remember these are more for orientation and not explanation10:48
Chipacathat is, details at the url10:48
zygayes, that is true10:48
zygathe URL is already in the meta-data10:49
Chipacazyga: a user looking at this list is either refreshing their memory, or wanting to know what to read to learn more10:49
Chipacazyga: so you give them enough information to pare down the list10:49
Chipacaanything networkish, they're probably going to have to look at all the network* things the first time to figure out what they need10:50
Chipacathe second time it'll be enough as is10:50
mupPR snapd#3381 closed: logger (& many more, to accommodate): drop explicit syslog <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3381>10:57
Chipacazyga: hmmm11:02
Chipaca$ snap remove http11:03
Chipacaerror: cannot perform the following tasks:11:03
Chipaca- Remove security profile for snap "http" (x1) (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented)11:03
zygaChipaca: you are using snapd from master but the rest from package11:03
zygaChipaca: just buind and install snap-update-ns11:03
Chipacaah ok11:03
zygaour error stacking sucks11:03
Chipacai'll get there eventually11:03
zygaChipaca: you want discard-ns too11:04
zygaand snap-confine11:04
Chipacazyga: so, make hack11:04
zygaor you may hit weird issues11:04
zygaChipaca: yes, and I need to teach it to build the go parts maybe :)11:04
Chipacanah, those are easy :-)11:04
zygajust 4 left11:06
Chipacaok, i've got to run11:08
Chipacagot physio11:08
zygatake care!11:08
ChipacaI probably won't be back in time for standup11:08
pedronismorphis: is this https://forum.snapcraft.io/t/run-configure-hook-of-core-snap-if-present-runs-seemingly-forever/674/2 the snapctl/bind issue likely, or something else?11:09
Chipacaso: i'm working on "snap refresh core --channel bogus" (which currently, erroneously, works)11:09
Chipacagot a fix already, fixing tests and cleaning it up, should have pr before eod11:09
Chipacaalso, got some work to do on go patch11:09
morphispedronis: it looks different here as from the log output it hangs at "Mount snap"11:11
pedronisso the topic is wrong?11:11
morphispedronis: and the bind() issue shouldn't occur for the core snap as the core snap now plugs network-bind11:11
pedronisit's not about configure11:11
morphispedronis: the first post in that topic is11:11
morphis"[-] Run configure hook of "core" snap if present"11:12
pedronisok, confusion11:12
=== tinwood is now known as tinwood_afk
morphiszyga: https://github.com/snapcore/snapd/pull/3394 is ready for a merge unless you want someone else to have a look11:43
mupPR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394>11:43
zygamorphis: can mvo ack it please?11:43
morphismvo: ^^11:43
=== chihchun_afk is now known as chihchun
=== tinwood_afk is now known as tinwood
* zyga prepares the three banches 13:57
morphiszyga: btw. when you try lxd on suse just don't forget to disable AppArmor for the containers14:00
morphisniemeyer: Spread-32 is now down to 1.3G, ok for you?14:01
zygamorphis: aha14:07
zygamorphis: how do I do that?14:07
Chipacazyga: --with-less-security14:08
Chipacazyga: --make-hackable14:09
Chipacazyga: --wanton-insecurity14:09
Chipacazyga: --make-chipaca-stop14:09
zygaChipaca: sudo make me a sandwitch14:09
mupPR snapd#3395 opened: many: remove interface meta-data from list of connections <Created by zyga> <https://github.com/snapcore/snapd/pull/3395>14:09
* zyga didn't eat anything but breakfast today14:09
cachiofgimenez, how do you usually retriger a ci check when there is a failure which doesn't need any change in the code?14:09
zygaChipaca: ^^ please land that14:09
cachiofgimenez, I got this https://travis-ci.org/snapcore/snapd/builds/235333896?utm_source=github_status&utm_medium=notification14:09
Chipacazyga: you're going off?14:10
morphiszyga: https://github.com/lxc/lxd/issues/309614:12
fgimenezcachio: i can't retrigger on travis sorry, i think only people in the snapd-commiters team can retrigger14:18
fgimenezcachio: usually, if your PR needs to wait, merging master is a good idea in general, that push retriggers the build14:18
morphiszyga: https://github.com/lxc/lxd/issues/334514:22
cachiofgimenez, nice, tx14:27
niemeyermorphis: Any chance we can take it a bit further down?  This will likely be something like ~2G for imaging purposes14:37
* zyga -> car & kids14:38
mupPR snapd#3396 opened: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>14:48
mupPR snapd#3397 opened: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3397>14:50
zyganiemeyer: ^^14:51
niemeyermorphis: Also sent a review on the no-apparmor bind issue.. we should probably have forum conversation about that one.. given the comment is not entirely clear that we're in agreement about what's going on in that case14:55
zygacachio: hey14:57
zygacachio: some failing tests https://travis-ci.org/snapcore/snapd/builds/235657720?utm_source=github_status&utm_medium=notification14:57
zygacachio: please collect the log if you want to keep inspecting it, as I want to restart the test14:57
mupPR snapd#3393 closed: tests: add retry mechanism for snap install command <Created by sergiocazzolato> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3393>14:59
ryebotzyga: I found a workaround for my issue, so I'm no longer blocked, but I added what useful information I could to this bug: https://bugs.launchpad.net/snappy/+bug/168707915:01
mupBug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>15:01
ryebotgood luck!15:01
zygaryebot: thank you!15:02
niemeyercachio: This one might be easy to address: http://paste.ubuntu.com/24644624/15:05
mvoChipaca: silly systemd question, we have this problem currently that when a new snapd boots it will rewrite the apparmor/seccomp profiles. however snap services start in parallel so there is a race condition here and they could start before snapd finished updating the profiles. I wonder if we could use systemd to sync this, i.e. have a way to say for all snap service that they may only start after snapd-regenerate-profiles was run. wdyt?15:06
Chipacamvo: is snapd-regenerate-profiles a systemd service, or is it a task?15:06
Chipaca(the answer is yes either way)15:06
mvoChipaca: it is something that happens in the daemon at startup, so no proper task just a part of the init of snapd15:07
mvoChipaca: I like the "yes" here15:07
Chipacamvo: ok, so it's going to be a little bit of work15:07
Chipacamvo: we need to make systemd be a "notify" daemon15:07
Chipaca(btw, I don't know if this'll work in 14.04)15:08
Chipacai mean we need to make *snapd* be a notify thing15:08
mvoChipaca: aha, there is a branch for that15:08
Chipacathere is? nice15:08
mvoChipaca: but of course that branch can not do much currently except for telling systemd that it is still alive in a crude way15:09
pedronisI think the idea is that snapd wouldn't notify until it has rewritten the profiles15:09
pedronisthat it's started15:09
pedronisI don't know how that vs the watchdog stuff interact though15:10
mvopedronis: aha, maybe I misunderstand, I thought the notify thing was the same socket, let me double check15:10
mvopedronis: i.e. that we can reuse code, but I will double check :)15:11
Chipacathey both do sd_notify15:11
Chipacaone with WATCHDOG=115:11
Chipacaone with WHATUPDOG=115:11
Chipacai mean READY=115:11
Chipacaso, the watchdog code needs rewriting to support this15:12
Chipacaor at least refactoring15:12
Chipacabut relatively easy i think15:13
zygamvo: that thing can be a snap internal command15:14
zygamvo: it would be easier to get this right15:14
zygamvo: essentially a snapd ping of any kind is sufficient15:14
zygamvo: then no need to make snapd notify anything15:14
zygamvo: it's just a "snap ensure-soon" or whatever15:14
zygamvo: and we're done15:14
zygaanother call-for-feedback on https://github.com/snapcore/snapd/pull/339615:15
mupPR snapd#3396: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>15:15
zygaI'd like to land it once green, I'm happy to iterate on the summary lines15:16
zygaonce it lands I can propose the command that uses this and needed plubming15:16
ryebotIs there a way to prevent automatic refreshes occurring?15:16
=== cachio is now known as cachio_afk
zygaryebot: no15:17
zygaryebot: you can set a refresh schedule15:17
zygaryebot: but refreshes are mandatory15:17
ryebotalright, where can I find docs on the refresh schedule?15:17
ryebotnvm, I found a forum post15:18
mvozyga: I'm not sure I understand. all snaps that have services will need to have an After=snapd-regenerated-service in their auto-generated systemd service and we need to emit that when we are finished with the generation. how is this related to an internal command?15:18
mvoChipaca: thanks a bunch for your input, I will start a forum thread about it15:18
Chipacazyga: what do you mean 'no need to make snapd notify anything'?15:19
zygamvo: my point is that that After= can refer to a new unit that just says "snap ping" to wake up snapd15:20
Chipacamvo: AIUI it'd be just After=snapd, with snapd not considered "up" until it's sd_notified of READY=115:20
zygamvo: no need to involve more complex tooling15:20
zygaChipaca: that the more complex solution is probably fine but this feels easier15:20
zygaChipaca: it could just be after=snapd really15:20
ryebotSo, this is a little problematic for my use case. I'm helping the LF build multiple k8s clusters into an image for use in their k8s certification exam. During image build, the k8s bin versions might be something like 1.6.2. During testing (which could be any time, afaict), bam! 1.6.4 comes out and disrupts services etc.15:21
zygaChipaca: I do agree that snapd needs to say "I'm up" to systemd for an "after=snapd" approach15:21
Chipacaagreed about the ping, now that i got you, but it's more hackish, and we want to have the sd_notify thing already15:21
Chipaca(for the watchdog)15:21
Chipacaso might as well do it15:21
zygaChipaca: yes, that's fine15:21
ryebotSo the refresh schedule doesn't actually aid me in this case.15:21
Chipacaryebot: hold on15:22
zygaryebot: can you re-phrase that, are you testing an image with snapd on it or is k8s just a snap of some kind15:22
* zyga is unsure what it is15:22
ryebotWe are building an ami running a bunch of k8s clusters under lxd15:22
ryebotthe k8s clusters use CDK, which use snaps to install the k8s bins/services15:23
* zyga sees techno-babble15:23
zygaami's I grok15:23
zygak8s is that kubernetes?15:23
ryebotyes sorry15:23
Chipacaryebot: what's the problem with the refresh schedule?15:23
* zyga reverses shield polarity and re-reads15:23
ryebotJust that (afaik) people could be taking the test at any time of day, so we can't really pick a time to refresh that we can be sure won't interrupt them.15:24
zygaryebot: can you tell me what is the test?15:25
ryebotkubernetes certification exam15:25
zygaryebot: when would you want them to test old lxd/kubernetes?15:25
zygaI see15:25
ryebotstill in development15:25
ryebotzyga: the version probably won't matter most of the time, so long as it's compatible with the test constraints15:29
zygaryebot: so here's an idea15:29
zygaryebot: just track the stable channel15:30
zygaryebot: and a specific version therein15:30
zygaryebot: sure, you may get updates15:30
zygaryebot: but only within that channel15:30
zygaand the channel can track, say, version 2.x or 2.3.x (numbers are just examples)15:31
ryebotYes, we currently have them track 1.6.x, the problem is that some of these snaps are services, and so the update can interrupt them15:31
matiasbkyrofa, o/ hey, fyi, I'm looking at the r1418 issue with nextcloud, trying to leave it in a consistent/coherent state (just in case you get some emails about state changes); automated review passed, so it should get approved (and then, it will be available through the branch it is released)15:32
kyrofamatiasb, oh thanks, I saw that it got put into the manual review queue, so I rejected it again and was gonna ping someone asking about that :P15:32
kyrofamatiasb, makes sense if you're poking at it15:32
matiasbkyrofa, oops, sorry! give me a min and it should get fixed (and run the review for the newer upload automatically)15:33
kyrofamatiasb, oh no problem15:34
kyrofamatiasb, is this one of the higher rev-count snaps?15:34
matiasbkyrofa, there, r1418 back in track, everything should be ok there15:36
matiasbkyrofa, it is one of the highest, for sure15:36
* mcphail notes kyrofa's nextcloud snap is at revision 1337 :)15:37
zygaleet :)15:37
kyrofamcphail, yes I was convinced that rev was bug-free. Unfortunately I was wrong :(15:38
kyrofamatiasb, thank you!15:38
Chipacaryebot: how urgent is this concern of yours btw?15:38
Chipacaryebot: because there is the idea of being able to tell snapd to not refresh things for a bit, i think (but i'd need to check)15:39
Chipacabut it's not even scheduled afaik15:39
ryebotChipaca: Honestly not sure. I mean, it may never happen, or we could really screw up some candidate's tests. The risk appears high enough that the LF devs brought it up.15:39
ryebotChipaca zyga: crazy idea - would disabling the snapd daemon work? :|15:40
zygaChipaca: yes15:40
zygaryebot: yes15:40
zygaryebot: we also have refresh timer that fires very infrequently15:40
zygaryebot: so you'd have to disable both15:41
ryebotalso a service?15:41
Chipacaryebot: yep, you can even say 'systemctl disable --now snapd.*' and it'd TTRT15:41
ChipacaDDRT even15:41
ryebotthanks guys!!15:41
zygado the evil thing15:41
Chipacanote that * is for systemctl itself, so you might need to protect it from your shell15:41
ryebotgotcha +115:41
Chipacaalternatively systemctl's tab completer is good enough that you can do snapd.<alt *> and it'll complete it for you15:42
ryebotalright great I'm going to try this out :)15:42
zygaChipaca: fancy looking at https://github.com/snapcore/snapd/pull/339615:44
mupPR snapd#3396: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>15:44
zygaChipaca: I'd like to do at most one bikeshed iteration, land it, propose more, than iterate ad-infinitum on the language15:44
zygaChipaca: I essentially want to land the first two patches there15:44
morphisniemeyer: I've already drop most things I could, trying to remove anything further leads to removal of base system components15:54
niemeyermorphis: Can you please paste "rpm -qa" somwhere?15:55
zygascaleway non-compliant "ubuntu" kernel: https://github.com/RocketChat/Rocket.Chat/issues/7000#issuecomment-30366898315:57
mupPR snapd#3395 closed: many: remove interface meta-data from list of connections <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3395>16:11
zygaChipaca: I'll land the branch and change the things as suggested after opening another PR, thus completing the set16:12
zygamvo: what is the state of the CE blocker?16:12
ogra_pedronis, hmm, did the timing of the device initialization on firstboot change recently ? my hummingboard image shows some weird behaviour16:17
ogra_after console-conf:16:17
ogra_ogra@localhost:~$ snap list16:17
ogra_No snaps are installed yet. Try "snap install hello-world".16:17
ogra_ogra@localhost:~$ sudo reboot16:17
ogra_and after the reboot:16:17
ogra_ogra@localhost:~$ snap list16:18
ogra_Name                 Version                   Rev   Developer  Notes16:18
ogra_core                 16-2.26.3+git209.2f19233  2020  canonical  -16:18
ogra_hummingboard-gadget  16.04-1                   x1               -16:18
ogra_hummingboard-kernel  4.1rc                     x1               -16:18
pedronisogra_: nothing that I know of16:18
ogra_i have never seen something like that ... either snap list is broken and stays that way all the time ... or it works right after console-conf16:18
ogra_having it only work after a reboot is very weird16:19
pedronisogra_: snap changes should tell when things happend16:20
ogra_yeah, i just dont know when exactly the reboot happened :P16:20
ogra_ogra@localhost:~$ snap changes16:20
ogra_ID   Status  Spawn                 Ready                 Summary16:20
ogra_1    Done    2017-05-24T16:16:11Z  2017-05-24T16:16:26Z  Initialize system state16:20
ogra_2    Error   2017-05-24T16:16:24Z  2017-05-24T16:16:49Z  Initialize device16:20
ogra_(the error is indeed the serial ... i'm working with --extra-snaps atm)16:21
pedroniswell, it never finished16:21
pedronisif it's in error16:22
pedronisso it probably just retrying again and again16:22
pedronisso sometimes there's no snap16:22
pedronisand sometimes there are some16:22
ogra_yeah, i see change 3 now ... same error16:22
ogra_seems to loop16:22
pedroniswell, it errors16:22
pedronisalso erroring there might also explode16:23
pedronis(which is something I managed to reproduce but need to look into)16:23
ogra_well, the stuff doesnt look unusual16:23
pedronisah, no16:23
pedronisyes, that's expected16:23
pedronisnothing to do with list16:24
pedroniswe are interesting in change 116:24
pedronisnot change 216:24
ogra_i'm not canonical and kernel/gadget are sideloaded16:24
pedroniswhen the bits of change 1 happened16:24
pedroniswhether something was unusually slow there16:24
ogra_OOOH !16:24
ogra_the config hook16:25
* ogra_ seens "namespace" in the error and blames zyga 16:25
morphisniemeyer: hm, lost the instance somehow, do you still see it?16:26
pedronisogra_: anyway the times there look immediate16:26
pedronisbit confused about snap list16:26
niemeyermorphis: If it's around for more than two hours and there's contention for machines, spread will kill it16:26
pedronisogra_: I suppose you to look at those times vs reboots times16:27
pedroniss/to look/have to look/16:27
ogra_i guess i need to start over for that and actually capture timestamps16:27
zygaogra_: which kernel are you on?16:27
ogra_indeed i didnt at the first run16:27
ogra_zyga, "some" kernel ... :P16:27
zygaogra_: 3.x or 4.x?16:27
ogra_zyga, could well be missing some bits16:28
zygaI see16:28
zygalet me know if you need help next week16:28
ogra_will do16:28
* ogra_ is happy to finally have a working gadget ... sanitizing the kernel is next16:28
ogra_getting uboot to DTRT was rally painful this time16:29
ogra_ogra@localhost:~$ htop16:30
ogra_cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied16:30
ogra_yeah, definitely kernel bits missing16:31
zygaogra_: can you look for dmesg | grep DENIED16:31
ogra_May 24 16:16:25 localhost kernel: [   58.405309] audit: type=1400 audit(1495642585.323:10): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=1563 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"16:31
ogra_zyga, dont bother yet ... i havent touched the kernel at all yet and only went with what was there for this board ... i'm actually surprised it works so well16:33
zygaogra_: you can help yourself out by editing /etc/apparmor.d/usr.lib.snapd.snap-confine.real (just copy it)16:34
zygaogra_: you can switch snap-confine to complain mode16:34
zygaogra_: and load it into the kernel with apparmor_parser -r16:35
zygaogra_: let me know if you need the exact syntax of the file16:35
ogra_why does it have that .rela suffix ?16:35
pedroniswar scars16:36
zygabecause dpkg bugs16:36
pedronissome backward incompatibility, dependency issue16:36
zygalooong story16:36
zygaogra_: just add ",complain" after "attach_disconnected16:37
zygaogra_: that should fix it16:37
ogra_zyga, so it does16:39
ogra_htop starts16:39
niemeyermorphis: We seem to have machines available, and Spread-32 is still running with opensuse16:41
niemeyermorphis: Created 8h44 ago16:41
=== grumble2 is now known as grumble
morphisniemeyer: it was 61, need to shift that to next monday, running out of time here17:03
Saviqis it known that cleanbuild is somewhat incompatible with version-script? http://pastebin.ubuntu.com/24645640/17:13
niemeyermorphis: Sorry, I'm getting a bit lost.. you said 32 above, and 32 indeed has opensuse on it..17:20
=== JanC_ is now known as JanC
niemeyer11:01:35 <morphis> niemeyer: Spread-32 is now down to 1.3G, ok for you?17:21
mvozyga: hi, sorry for the slow reply. state of the blocker is that there are two branches up for review, I summarized the short term fix in https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-possible-revert-race-condition/722 - ideally we would have the input from jdstrand on this too. alternatively we could just revert both mknod |N and quotactl and then we just need to merge a single branch not the seccomp-resolver one (hope this explaina17:35
mvotion makes sense?)17:35
jdstrandmvo: as it happens, I'm here today after all17:36
mvojdstrand: aha, were you supposed to be off?17:37
mvojdstrand: please let me know if the above forum post makes sense, there is a bit of a problem with the snap-confine syntax/symbols, its summarzied there17:37
jdstrandmvo: ok, so I can ignore backscroll and only look at the forum?17:38
zygamvo: no worries :)17:38
zygamvo: yes, I'll follow the post shortly17:38
mvojdstrand: thats probably enough17:38
mvojdstrand: unless the post summarizes the problem not well enough :)17:39
jdstrandok, let me read it17:40
jdstrandmvo: oh, I thought there was something in place to say that snapd always needed to start before services. when did that change?17:41
zygajdstrand: we only had that in 15.04 for services AFAIR17:41
mvojdstrand: it got lost along the way, but even if we had it it would still be racy, because snapd needs some (small amount of) time to write the new profiles17:42
jdstrandcommands shouldn't start before snapd if the login session is supposed to start after snapd17:42
mvojdstrand: so we really need something that is ready only after snapd has completed that profile generation17:42
zygamvo: one more idea17:42
zygamvo: is to have snap run ask snapd to do this17:42
zygamvo: if services start after snapd17:43
zygamvo: then there's no need to have snap run not wake snapd up17:43
zygamvo: it's a bit ... well, but it has some good things as well17:43
zygamvo: like we could refresh on demand this way17:43
zygamvo: or warn about CVEs that snapd synced17:43
zygamvo: lots of ideas are possible17:43
mvozyga: yeah, I think we discussed this but we don't want snapd in the critical path for snap run all the time17:43
zygamvo: but we are adding it back now17:43
zygamvo: after=snapd does that already17:43
pedronismvo: but the ordering solution does that anyway17:43
zygamvo: unless I'm mistaken and after=snapd won't start snapd if it doesn't run already17:44
zygamvo: then we have the problem again17:44
zygamvo: (which is interesting in fedora land for instance, where we don't start on boot)17:44
mvozyga, pedronis: yes, for daemons we would add this dependency. true. it would be better to avoid it IMO but I don't see a way currently17:45
mvo(well, seccomp bpf would solve it for seccomp profiles only but that is not a general solution)17:45
pedroniswell, isn't that the plan of having a profiles/current17:45
zygamvo: one more idea is to laizly mount snaps if snap run talks to snapd17:46
pedronisthen the dep is just changing that symlink early17:46
pedronisthat I though was what we discussed the other day17:47
jdstrandok, that was annoying. the power went out17:47
mvopedronis: we did, to me its not fully clear yet if it solves the various cases. but I probably just have not thought enough about it. TBH I like the suggestion of snapd backup-of-state-and-profiles and restore that backup on revert more, at least its clearer in my mind how that would work and what the constrains are17:48
mvozyga: if we put snapd into the snap run path, then yes, it is an interessing idea17:49
mvozyga, pedronis: lets continue in the forum, I need to step out for some minutes and can only reply async17:49
* zyga is preparing for the event17:51
mupPR snapd#3398 opened: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>17:57
=== cachio_afk is now known as cachio
jdstrandmvo: ok, I responded in the forum. ping me when you want to discuss more18:24
mupPR snapd#3396 closed: interfaces: add summary to each interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3396>18:43
mvojdstrand: thank you!19:01
mupPR snapd#3399 opened: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>19:21
zygaChipaca: ^^19:22
kyrofaogra_, are you still around?19:31
Chipacazyga: could you review snapd#3369?19:32
mup_PR snapd#3369: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369>19:32
=== mup_ is now known as mup
zygaChipaca: yes19:43
zygaChipaca: what's going on with GOPATH vs GOHOME?19:54
cachiozyga, do you know how long does it take to retry when it is downloading a snap?19:54
Chipacazyga: GOHOME I made up19:54
Chipacazyga: GOPATH is a PATH, ie a list19:54
Chipacazyga: we were using it wrong19:55
Chipacazyga: so I either had to change all the $GOPATH to ${GOPATH%%:*}19:55
Chipacaor, what i did19:55
Chipaca(%% and not ## because in go the first element in the list is where new stuff goes)19:56
zygaChipaca: done19:58
zygaChipaca: thank you for the review, I tried to make it work well in all cases20:01
zygaChipaca: question about tab completion, where can I test the tab completer returning not only the item but also the description?20:01
cachioChipaca, do you know how long does it take to retry when it is downloading a snap?20:03
zygacachio: we time out after some reasonable time (<< minute)20:03
Chipacacachio: exponential, starting at 200ms20:04
Chipacano sorry starting at 100ms20:04
Chipacaand then 2.5× every time20:04
Chipacacachio: it's in store/retry.go20:04
cachioChipaca, ah, ok, thanks20:05
Chipacazyga: anything you'd like changed, wrt your comments in the pr?20:07
ChipacaI need to repush anyway because of conflicts, so i can tweak something :-)20:08
zygaChipaca: no, it is fine20:09
zygathanks :-)20:09
Chipacazyga: the 32k limit on commandlines is rather dated, but it was bytes not lines of input20:24
Chipacaby-the-way :-p20:24
zygaChipaca: yes, I know20:26
zygaChipaca: but I think it's not dated, is it changed?20:27
Chipacazyga: it's about 2M20:28
pedronisI think it's around 2M20:28
Chipacazyga: unless you have a _lot_ of stuff in your environment20:28
zygaChipaca: aha, I didn't know20:30
* zyga works on slides 20:30
=== sergiusens_ is now known as sergiusens
* Chipaca works on riffs20:39
mupPR snapd#3390 closed: tests: remove additional setup for docker on core <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3390>21:05
morphisniemeyer: problem on my end is that I lost the connection the spread-32, looks like I removed a bit too much21:14
morphisniemeyer: best is if I redo the cleanup on monday and give you a fresh instance to snapshot21:15
morphisniemeyer: lost the connection = it got dropped from .spread-reuse.yaml so I don't have the connection information anymore21:16
mupPR snapd#3369 closed: many: make shell scripts shellcheck-clean <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3369>21:25
Chipacaniemeyer: ping21:26
Chipaca^^ something is or was awry with spread/linode21:26
niemeyerChipaca: Yo21:30
Chipacaniemeyer: just travis weirdness i hope21:31
* zyga -> food21:31
cachioniemeyer, is it any way to run many times the same test with spread?21:42
cachioniemeyer, I mean, using the same node21:43
niemeyerChipaca: Thanks, pretty strange indeed21:45
Chipacazyga: thank you for pointing out the "git log --oneline" thing21:56
Chipacazyga: it's looking better already (far from perfect still)21:56
Chipacaniemeyer: ok to restart that run?22:04
mupPR snapd#3400 opened: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>22:15
niemeyercachio: Other than -reuse, there's no way to retry in a loop right now22:16
niemeyerChipaca: Yeah, no much to do there22:16
niemeyerChipaca: Something awkward seems to have happened.. hard to believe all allocations would fail at the same time silently22:17
Chipacaniemeyer: network hiccup?22:17
niemeyerPerhaps.. or something else made the process stop22:18
niemeyercachio: Btw, we can easily extend spread to repeat the same test over and over until it fails22:33
cachioniemeyer, yes, I'll need that because otherwise I spend to much time retrying manually22:34
cachioniemeyer, I'll make the change here22:35
cachioniemeyer, most of the failures are very difficult to reproduce22:35
niemeyercachio: Thanks, let me know if you need a hand on that22:36
cachioniemeyer, sure22:38
mupPR snapd#3400 closed: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3400>22:56
=== Elleo_ is now known as Elleo
cachioniemeyer, the change worked verywell23:29
cachioniemeyer, I am rexecuting 100 or until the test fails23:30
cachioniemeyer, i could reproduce an error by doing that23:30
cachioniemeyer, I am not sure if you are interested on add that change to the master, are you?23:31
=== cachio is now known as cachio_afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!