/srv/irclogs.ubuntu.com/2018/11/15/#snappy.txt

mupPR snapcraft#2406 closed: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>01:06
mupPR core18#91 opened: Make /etc/default/swapfile be writable <Created by musicguitar> <https://github.com/snapcore/core18/pull/91>04:43
mborzeckimorning06:03
zygagood morning06:35
zygamore red in tests06:36
zygaoh well06:36
mborzeckizyga: hey06:36
zyga:-)06:36
mborzeckizyga: looking into some opencl stuff from the forum, looks like none of the interfaces allows accessing /etc/OpenCL to read icd files, and then there's libnvidia-opencl which we do not pick up in s-c06:41
zygaoh man06:41
zygaanother file to add06:41
mborzeckii'll rebuild my debugging snap with clinfo and see how far i get there06:41
zygalooking forward to removing that mess06:41
zygagood luck!06:42
mborzeckiidk maybe we should have a 'compute' interace to cover cuda and opengl06:42
zygaopencl?06:42
mborzeckiopencl right06:42
mborzeckitoo many open suffixes :P06:42
mborzeckiprefixes06:42
mborzeckidamn06:42
zygaopen wtf :)06:42
mborzeckishould get coffee06:42
zygaI'll take the dog out and focus on snap-update-ns and snapd feature flag for per user mouts06:42
zygai have plenty of PRs that depend on each other06:43
mborzeckizyga: i'll have some questions about mount and MNT_DETACH that we do06:43
zyganeed to add some leafs :)06:43
zygayes?06:43
zygashoot, I'll answer06:43
mborzeckizyga: we can do HO later06:43
zygaok06:43
zygamborzecki: can we aim for 9:00?06:43
zygafor the talk06:43
mborzeckisure06:43
zygaotherwise I'll be in my pijamas ;)06:44
iceywhere should I take a slightly comical snapcraft.io bug? doesn't hinder functionality but would probably be something we want to get fixed (we call French Guiana France in the map showing snap distribution)06:59
mborzeckihmm 'Download snap "core" (5940) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_5940.snap?token=1542276000_dc14a149f1c3974949f187187a7bfd71ceacfad9)'07:35
mborzeckisnapcraft does not allow layouts?07:50
mvomborzecki: I saw the fastly 503 error in spread, probably something for the store team to look at (cc sparkiegeek maybe?)07:51
mvomborzecki: it looks like layout: was added to git Oct 10 in snapcraft but I doubt this is released yet07:52
* mvo checks07:52
mborzeckimvo: found some info in https://forum.snapcraft.io/t/snap-layouts/720707:52
mvomborzecki: I wish we had the "published-into-channel" metadata already :)07:52
zygaIt allows layouts since 3.x but you must also use a base07:59
mborzeckiso mesa OpenCL implementation is listed by clinfo now08:04
mborzeckiand no denials, that's probably because layouts opens up /etc/OpenCL/vendor08:06
pstolowskimorning08:07
mborzeckipstolowski: hey08:09
Chipacamoin moin08:09
mvohey Chipaca and pstolowski !08:12
pedronismorning (me is up since a bit for a meeting)08:13
pedroniszyga: mborzecki: hi, we should just close #6099 for now? right?08:15
mupPR #6099: cmd/snap-confine: always put the snap process under a device cgroup <β›” Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>08:15
mborzeckipedronis: yes, let me close it08:15
pedronisthx08:15
mupPR snapd#6099 closed: cmd/snap-confine: always put the snap process under a device cgroup <β›” Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>08:17
pedronisChipaca: hi, you are already working on the sanity check for epochs?08:17
pedronisChipaca: I reviewed the send epochs one08:17
Chipacapedronis: I am08:19
Chipacapedronis: saw the review, will circle back in a bit08:19
Chipacagot distracted by the forum08:19
Chipacaand reddit08:20
Chipacahttps://www.reddit.com/r/Ubuntu/comments/9x0b5r/and_this_is_one_reason_why_i_dislike_snaps/08:20
Chipacasomebody asks why we don't use a private mount namespace to hide these08:20
ChipacaI dunno if that'd work, but if it did, and it made people happy, maybe we should08:20
pedronisChipaca: what are these?  (me not sure I want to get lost in reddit right now)08:20
Chipacapedronis: nah, not worth your time, nothing actionable for us beyond the mount namespace question08:21
pedronisChipaca: could you convert the card for the sanity check to doing otherwise I'll do it08:21
Chipacauh, isn't it there already08:21
Chipacai thought i'd put it in doing yesterday during the meeting08:21
Chipacaah no 'send epoch' is doing08:22
Chipacadone08:22
mborzeckizyga: i got opencl & mesa to work, but there's some trouble with opencl and nvidia, i can get the libraries in, but the icd file is /etc/OpenCL/vendor/nvidia.icd in the host filesystem08:23
Chipacadone moving it to doing08:23
Chipacanot done done08:23
mborzeckizyga: though tbh as a workaround a snap could generte the file itself and use layouts to put it under /etc/OpenCL/vendor08:23
pedronisChipaca: thank you08:24
pedronispstolowski: hi, thanks for the checklist, making some cards for hotplug08:31
pstolowskipedronis: sure; i think we're stumbling on each other's feet right now, something unexpected just happend ;)08:31
pedronispstolowski: oops, sorry08:32
pstolowskinp08:32
zygare08:32
zyganow to work :)08:32
pedronismborzecki: I added some info to the "snap connections" card, I will look at plan/review the PR when I have gone through some slightly higher prio stuff08:32
mborzeckipedronis: thanks08:33
zygamborzecki:I like the idea of snapd generating config files for hardware and injecting them in /etc08:33
pstolowskipedronis: can you explain "Doing" lane in the rules.. card? i'm abit unclear on that one (vs upcoming)08:33
Chipacapedronis: I'm not sure I understand your comment on 6142: isn't amend _already_ an "install"?08:34
pedronispstolowski: Doing means you are working on it,  upcoming for things you are planning to do but not working on yet08:34
pedronissome things might go straight to doing08:34
Chipacapedronis: uh, now I see it08:35
Chipacawill fix08:35
pedronisChipaca: :)08:35
mupPR snapd#6151 closed: snapd: allow snap-update-ns to read /proc/version <Simple πŸ˜ƒ> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6151>08:35
pstolowskipedronis: ok, thanks08:35
Chipacapedronis: so the amend check is wrong in store08:35
Chipacaand maybe the amend test is also wrong08:35
Chipacahmm hmm08:35
* Chipaca stashes the checking work08:35
pedronisChipaca: store as in our store package?08:35
pedronisor store store?08:36
pedronisanyway I'm quite sure we want that change08:36
pedronisand the rest should follow08:36
zygaone small trello tip08:36
zygayou can use the menu on the right to filter cards08:36
zygae.g. to show all the cards you are a member of08:36
zygavery useful IMO08:36
pedronisyup08:36
Chipacapedronis: the amend test i added in the store package08:37
Chipacapedronis: sends the snap id (d'oh)08:37
pstolowskipedronis: ok, i created a couple of cards and left some in the checklist for hotplug for the time being08:38
pedronispstolowski: thanks08:38
pedronispstolowski: it looks reasonable, I think it matches what PR you have up etc, but indeed doesn't make sense having too much in doing or also in upcoming08:40
pedronisChipaca: I admit I didn't look super closely at tests in the first pass08:41
pedronisalso because I'm sure we were missing some or something (because of amend)08:41
mborzeckiheh rebuilt my snap with core18 clinfo stopped working :/08:43
mborzeckianyone on 18.04?08:44
zygammm, no, 18.1008:46
mborzeckizyga: can you install clinfo package and run it?08:47
zygasure08:47
zygamvo: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec408:48
mupPR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>08:48
mvozyga: oh, looks like there is a leftover [Install] - thanks for spotting08:49
zygamvo: I left a suggestion to apply08:49
mvozyga: yeah, like it08:49
mvozyga: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4L5 is also wrong, I need to fix/revert this08:50
mupPR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>08:50
zygaoh08:50
zygaI didn't notice08:50
zygayeah08:50
zygamborzecki: clinfo has one line of output08:51
zyga"Number of platforms"08:51
zygawhat did you want from that?08:51
mborzeckihm so it must be one of the libs08:52
zygalinux-vdso.so.1 (0x00007ffda4f1c000)08:52
zygalibOpenCL.so.1 => /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007f45ae00e000)08:52
zygalibdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45ae008000)08:52
zygalibc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45ade1e000)08:52
zyga/lib64/ld-linux-x86-64.so.2 (0x00007f45ae453000)08:52
zygaldd ^08:52
mborzeckizyga: i've installed beignet and pocl opencl implementations in the snap and opencl exits with an error from llvm now :/ probably one of the libs is doing something wrong or loading both of them breaks things08:53
mvozyga: does lp 1786889 is something we fixed recently? I vaguely remember this error08:54
zygamvo: yes08:54
mvozyga: I will set to fix commited then08:54
zyga4.18.0-041800-generi08:54
zygathis is a mainline kernel08:54
mvooh08:54
mvozyga: so this is just not supported?08:54
zyganot exactly, it should work with 2.36.x08:55
zygawe added some extra rules for that08:55
zygasame thing was affecting TW08:55
mvozyga: ta08:55
mborzeckizyga: btw. generating vulkan icd file for nvidia looks tricky, there is an api version listed in the file, need to check if it's required, but from the looks of it the drivers declare different versions (eg. nvidia 1.1.82, intel 1.1.80)08:57
zygait depends on how we generate  them08:58
zygaI think this is something we should take from a driver snap08:58
mborzeckisholud probably summarize the vulkan/opencl/glvnd craziness in a forum topic08:58
mborzeckimvo: have you tried to run core18 base snap apps with --strace ?09:09
mvomborzecki: I don't know - does it fail?09:12
mvomborzecki: never conciously tried it09:12
mborzeckimvo: it's getting stuck, can you try snap install test-snapd-tools-core18 and then snap run --strace test-snapd-tools-core18.echo foo ?09:12
mborzeckimvo: maybe we need to update th list of skipped syscalls09:13
mvomborzecki: let me try that - I bet we need to blacklist one more systemcall :/09:13
mupPR snapd#6082 closed: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug πŸ”Œ> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6082>09:14
mupPR snapd#6146 closed: ifacestate/helpers: added SystemSnapName mapper helper method <Simple πŸ˜ƒ> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6146>09:17
mvomborzecki: fun, when I try to run tests-napd-tools.echo I get "unexpected wait status 0x8b"09:20
mborzeckimvo: adding -e !nanosleep unblocks it here09:20
mvomborzecki: cool! will you do a PR or shall I?09:21
pstolowskiSaviq: hey, it seems that installing/refreshing/removing multipass snap disconnect network for a short moment (or at least NM thinks it does); i suppose it's brige setup or something?09:21
mborzeckimvo: zyga pasted me a log from his run, and teher's no nanosleep there, i'm probably running a newer kernel so maybe something new was added to vdso09:21
mborzeckimvo: i'll open a PR09:21
mvomborzecki: ok09:21
Chipacamborzecki: pedronis: Thank you for your reviews of #6142! I believe I've addressed your concerns.09:27
mupPR #6142: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>09:27
Chipacalet me know if I should pull out any of those commits into their own PR09:27
Chipacaat least Epoch.Unset would stand alone if needed (but it's pretty trivial)09:28
* Chipaca -> more coffee09:29
pedronisChipaca: Unset is like Revision.Unset right? anyway the PR doesn't seem that big even after the changes09:32
mupPR snapd#6155 opened: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6155>09:36
mborzeckimvo: ^^09:36
mvomborzecki: ta09:37
pedroniszyga: is there a easy way to use layouts to turn a read-only directory from the base into a writable directory into which things can get added?09:42
Chipacapedronis: yes, exactly like Revision.Unset semantically09:43
Chipacainternal is different because different09:43
Chipacaalso we had two places already doing that check so it's really less code :-p09:43
zygapedronis: yes09:43
Chipacaanyway. I'd said I was getting more coffee and didn't. I shall now.09:43
zygaThat’s available since improved content interface09:44
pedroniszyga: do you need to actually add a file in the layout? or just need to specify the directory?09:44
mvohrm, it looks like our strace is not compatible with libnss-systemd, when I have this is installed the straced apps will segfault. oh well09:47
zygapedronis: a directory is sufficient09:51
zygaWe support both file and directory layout items09:51
pedroniszyga: apparmor would still need to le us through right, though. I'm thinking something like /etc/foo09:51
pedroniswhere foo exist in the base09:52
Saviqpstolowski: yeah, if NM is dumb enough09:52
zygaYes, though the layout code does that too09:52
Saviqpstolowski: I never noticed it though, care to file a bug please?09:52
pstolowskiSaviq: sure. could as well be a Mate NM indicator thing09:53
Saviqyeah if it doesn't filter the interfaces09:57
Chipacahmmm. ssh -nNT -L ~/.snap/${remote}.snapd:/run/snapd.socket $remote09:58
Chipacahmm09:58
niemeyerGuten Morgen10:00
sparkiegeekmoin moin10:01
pedronisniemeyer: hi10:08
pedronisChipaca: niemeyer: given that you worked/discussed this initially I would be interested in your input on this:  https://bugs.launchpad.net/snapd/+bug/180321210:09
mupBug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>10:09
ondrazyga about avahi, stable is one to use. I made pull request to upstream, but it has not been accepted yet, that's why git commit in version10:09
Chipacapedronis: I think we fixed this recently10:09
pedronisChipaca: ?10:10
pedronisChipaca: fixed which way?10:10
Chipacaah sorry no10:10
ondrazyga and once 2.36 lands, I current beta will go to stable to align it with classic, so clients can works same way on core and classic10:10
Chipacapedronis: we fixed the "snap refresh restarts disabled services" one :-)10:10
Chipacaso close10:10
pedronisheh10:10
pedronisanyway10:10
pedronisI can think about it, but input from original design sources could be useful10:11
niemeyerpedronis: The way we cooked the commands gives a hint about what's reasonable there.. we can start something without it being enabled:10:12
niemeyer      --enable       As well as starting the service now, arrange for it to be started on boot.10:12
Chipacawhy is launchpad so horrible at whitespace10:13
niemeyer... for so long10:13
sparkiegeekChipaca: because HTML, and backwards compatibility is hard?10:13
niemeyerpedronis: So IMO restart should not touch disabled services either10:13
Chipacasparkiegeek: I've never not been frustrated by its handling of whitespace, so at least it's consistent10:14
niemeyersparkiegeek: Given how many systems get this right, I don't buy it10:14
pedronisniemeyer: start should do though?10:15
niemeyerpedronis: If you specifically name it, yes10:15
* Chipaca changes a <div> to a <pre> and is happier10:15
niemeyerpedronis: Sorry, let's explore this better:10:15
pedronisniemeyer: no, we are talking about <snap> here10:15
pedronisnot single services10:15
niemeyerpedronis: If a service is running, it seems reasonable for it to be restarted10:16
niemeyerpedronis: No matter hwat10:16
pedronisI think the issue is what makes sense for restart <snap> vs overall consistency10:16
niemeyerpedronis: Same is true for stop10:16
pedronisniemeyer: what if something is not enabled but running, and one uses stop <snap>10:16
niemeyerpedronis: There's only one option that sounds sane from a user perspective, right?10:17
pedronisstopping it10:17
niemeyerYep10:17
pedronisso we are left with snap start <snap>10:17
niemeyerThat's the slightly tricky one, as there are two potentially valid expectations10:18
pedronisyes10:18
pedronisstart everything (mimic stop), start only enabled10:18
pedronis(more like restart)10:18
niemeyerYeah, except restart clearly makes some sense even for disabled services,  as long as they are running10:19
pedronisyes10:20
pedronisso stop stops everything running10:20
pedronisrestart, restart everything running10:20
pedronisbut start is trickier10:20
niemeyerI think there's way to define it10:21
pedronisnotice also that the user asked for different behavior that these10:21
niemeyerThere's one option which is more reasonable when running "snap stop" + "snap start"10:21
niemeyerWhich is a pretty reasonable pair10:22
niemeyerI think we should make "snap start <snap>" only act on enabled services, and error out if all services are disabled10:23
pedronisok10:23
niemeyerThis way "snap stop <snap>" followed by "snap start <snap>" will tend to do the right thing10:23
niemeyerBut "snap start <snap>.<app>" should work always, since it's a more clear request10:24
pedronisI can write something there, I also need to ask again if the user really meant what he wrote about restart disabled running doing nothing10:24
pedronisyes10:24
niemeyersnapctl should match10:24
niemeyerOtherwise it's error prone10:24
pedronisyea10:24
Chipacashould we add flags for the complimentary option?10:25
Chipacaie snap start --all10:25
Chipacaor sth10:25
Chipacasnap restart --only-the-odd-numbered-ones10:25
Chipaca:)10:25
Chipacacomplementary*10:25
pedronisChipaca: snap start --enable <snap>  will imply all I think10:25
pedronisnot sure it's enough10:26
niemeyerpedronis: What the user is asking for has little bearing unless the argument comes with rationale similar to the discussion we had above10:26
pedronisniemeyer: sorry, I'm not saying we should do what he says, but I just want to dig into the bit where il would diverge10:26
niemeyerpedronis: For example, the very first case suggested in the bug is already breaking reasonable expectations10:26
niemeyerpedronis: With a running service, having "snap restart <snap>" doing nothing is super awkward10:27
niemeyerpedronis: Yeah, makes sense10:27
pedronisChipaca: given you worked on this how complicated would be restart only running ones?10:30
mvomborzecki: when you have a moment I would love to talk about LP: #1791182 - I started a PR but your input would be great as this is something that happend with parallel installs changes10:31
mupBug #1791182: Okular launcher present in Apps menu after removing Okular snap app <apps> <launcher> <menu> <okular> <snap> <snapd:In Progress> <https://launchpad.net/bugs/1791182>10:31
Chipacapedronis: not too hard10:31
Chipacapedronis: TOCTOU prone though10:31
pedronisChipaca: mmh, there's try-restart (oddly named)10:32
pedroniswhich seems to do that10:33
Chipacapedronis: and try-reload-or-restart10:35
Chipacapedronis: this could work, for restart10:35
Chipacaif that's what's wanted :)10:35
pedronisChipaca: just exploring10:36
pedronisno immediate action10:37
pedronisI need to answer/write a bit more in the bug10:37
niemeyerChipaca: Yeah, given the name, try-reload-or-restart sounds like the right thing10:37
niemeyerChipaca: It's the kind of command that likely made an appearance when people realized the default behavior was not the best one10:37
mupPR snapd#6156 opened: [RFC] wrappers: remove all desktop files from a snap on removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/6156>10:37
niemeyerBut it was too late to change get the default10:38
Chipacato be clear: we'd do try-restart or try-reload-or-restart depending on whether --reload was given10:38
Chipacaon the other hand10:39
Chipacaif a service failed10:39
Chipaca'snap restart' will stop starting it up again10:39
pedronismmh10:39
mvozyga: you mentioned you worked on a followup test in 6128 - is that in progress or shall I have a look at this?10:42
mupPR snapd#6127 closed: overlord/ifacestate: setup systemd backend in separate pass <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6127>10:42
mupPR snapd#6128 closed: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>10:42
zygamvo: I'm working on that10:43
zygamvo: just talking to maciej on HO now10:43
mvozyga: cool10:43
pedronisChipaca: restart if running, or enabled but failed doesn't roll on the tongue10:46
Chipacaso it'd be try- only if not specifying services (ie if specifying snaps)10:51
Chipacai guess that's reasonable. We'd have to announce the behaviour change.10:52
pedronisyes10:52
mupPR snapd#6143 closed: cmd: install snap-discard-ns in "make hack" <Simple πŸ˜ƒ> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6143>10:56
Chipacapedronis: https://pastebin.ubuntu.com/p/tcgQXFcvmC/ <- is this something we'd want?10:57
Chipacapedronis: or should we consider adding a column?10:57
pedronisChipaca: I would put it only in info for now10:57
Chipaca(adding a column sounds perilous)10:57
Chipacapedronis: I'd thought maybe add it in notes if != "0"10:58
pedronisit can get complicated/long10:58
Chipacayes10:58
Chipacaalmost arbitrarily long10:58
pedronisyea10:59
pedronisepochs should be fairly transparent to the user in the normal case10:59
pedronisunless one is debugging or it's a db snap or something10:59
pedronisbut then info seems ok10:59
pedronisChipaca: I mean we might end up doing something in list but I wouldn't start there before we have snaps using this around11:01
pedronisto think about11:01
pedronisshowing the whole epoch doesn't seem an option there11:02
Chipacaok11:02
ChipacaFWIW the max epoch currently would have len 24011:02
pedronisChipaca: you are not making your case, if you are making one to put it there :)11:03
Chipacapedronis: no i'm explaining that I understand the problems11:03
pedronisok11:03
Chipacapedronis: today epoch isn't seen by the client at all, fwiw11:03
pedronisa saving grace actually11:04
pedronisso far11:04
pedronisI know11:05
pedronisif we want to show in info we need to change that11:05
Chipaca:)11:08
pstolowskipedronis: described autoconnect difficulties https://forum.snapcraft.io/t/hotplug-autoconnect/8526 ; i only mentioned 3 interfaces as i'm not sure what else that we currently have makes sense for hotplug11:09
pedronispstolowski: thanks11:11
pedronispstolowski: I'll do a pass myself over the interface types and see if I find others relevant to this11:12
mupPR snapd#6157 opened: userd: force zenity width if the text displayed is long <Simple πŸ˜ƒ> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6157>11:14
clobranoHi all :), could anybody tell me whether the "version-script" stage is still supported (even if deprecated)? I'm having a weird Yaru build failure on Travis11:15
mupPR snapcraft#2402 closed: packaging: update requests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402>11:16
clobrano^ here is the log https://travis-ci.org/ubuntu/yaru/builds/45422250511:23
cachiozyga, hey11:27
zygahi11:27
cachioafter the images for bionic and cosmic were updated11:27
cachiosystemd was upgraded11:28
cachioand now we can see the mount issue on those systems too11:28
cachio:(11:28
cachiozyga, most of the red builds are because of that issue11:29
zygaoh fun11:29
zygaI will be busy today11:29
zygathanks for letting me know11:29
mborzeckiyay11:29
zygaI will prioritise this11:29
mborzeckinow we'll have to fix it :)11:29
mvodegville: hi, I subscribed you to bug lp 1745037 - hope you don't mind, looks like a relatively straightforward docs fix11:30
cachiomborzecki, sadly yes11:30
cachio:)11:30
pstolowskipedronis: in theory we could maybe have hotplug for e.g. removable media, but i'm not sure if it makes sense in practice11:33
mupPR snapd#6069 closed: ifacestate/hotplug: removeDevice helper <Hotplug πŸ”Œ> <Simple πŸ˜ƒ> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6069>11:34
Chipacamvo: cachio: do any of our test-snapd- snaps have branches ?11:38
cachiocachio, no11:39
cachioat least mine11:39
cachioChipaca,11:39
Chipacacachio: ta11:39
Chipacacachio: is test-snapd-tools one of yours?11:39
cachioChipaca, no11:39
Chipacacachio: ok11:39
degvillemvo: thanks - I'll take a look!11:40
mupPR snapcraft#2404 closed: cli: handle yaml errors for cleanbuild <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>11:40
mvo5845 is green! a second review would be great (maybe from jdstrand  ?)11:40
mvoChipaca: they are all(?) owned by the canonical account and shared11:41
mvoChipaca: aren't branches not long lived? or is that controlled easily server side?11:41
zygafun11:42
Chipacaum11:42
zygatwo bugs11:42
Chipacamvo: i meant tracks11:42
zygawell, two *new* bugs11:42
Chipacacachio: sorry i meant tracks :-)11:42
zygaone in snap-confine and one in snap-update-ns11:42
mvoChipaca: not afaik - lets create one for test-snapd-tools?11:44
Chipacamvo: +111:45
Chipacamvo: i'm wanting to have something to test epochs from the store with11:45
Chipacaeasiest, other than having a  snap just for that, is adding a track11:45
Chipacaotherwise I could just make a test-snapd-epoch snap11:45
* mvo nods11:46
Chipacamvo: which would you rather?11:46
zygamborzecki: fixed11:52
zygamborzecki: the 2nd bug11:52
zygathe 1st bug will be next shortly11:52
mborzeckizyga: ok, ping me for reviews, i'm keen to try it out on centos11:52
sergiusensicey: you might want to report an issue for the webteam11:53
mvoChipaca: ups, missed the quesiton - either way is fine, sorry. maybe test-snapd-epoch is simpler as we don't need to ask the store for creating of a track11:58
mvocachio: hey, so I would like to write a spread test for {personal,system}-files it needs a snap declaration to connect the interface, do we have test for similar interfaces already that I could use as a blueprint?12:04
zygamborzecki: spread test in flight12:06
mborzeckiare interface hooks supported by snapcraft?12:12
Chipacamvo: can you register test-snapd-epoch and invite me to collaborate on it?12:14
Chipacamvo: (in the Canonical account i mean)12:14
mvoChipaca: sure12:14
Chipacamvo: if you need to push a revision to collaborate, rename tests/lib/snaps/basic :-)12:14
ChipacaI don't intend it to do anything (for now at least)12:14
zygamborzecki: https://github.com/snapcore/snapd/pull/615812:15
zyga2nd bug12:15
zyganow looking at 1st12:15
mupPR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>12:15
mupPR snapd#6158 opened: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>12:15
cachiomvo, and what does it do?12:16
cachiosh?12:16
mvoChipaca: you should have mail12:16
mvocachio: it allows access to files outside of the regular confinmement12:16
mvocachio: e.g. $HOME/.my-folder12:16
cachiook, so you can use the sh snap12:17
cachioone sec12:17
cachiomvo, test-snapd-sh12:17
cachiojust add the app there12:18
cachiowith the plug you want12:18
cachioand that's it12:18
cachiomvo, in the test then you can do test-snapd-sh.<your-app> "ls <path>"12:19
cachioi.e. test-snapd-sh.with-broadcom-asic-control-plug -c "cat /dev/$device"12:19
cachiomvo, does it work for you?12:20
mvocachio: I will look into it some more after lunch, thanks12:23
cachiomvo, ok, I can create the test if you want12:23
cachiomvo, so you can take other stuff12:23
cachioI created many similar tests before12:24
zygamvo: can you please review https://github.com/snapcore/snapd/pull/612312:25
mupPR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>12:25
zyga-402912:25
zyga-402 +8 changes12:25
Chipacamvo: thanks12:26
mvocachio: that would be great, I'm not sure though if "deny-connection: true" will make things more complicated for the test12:26
mvocachio: but either way, help with the spread test would be great12:26
mvozyga: gladly12:26
mvozyga: whats not to like about this amount of "-"12:27
cachiomvo, nice, I'll start with it today12:30
cachiomvo, "deny-connection: true" shouldn't be a problem12:30
zygaif anyone has review time, this is the only feature PR to review from my stuff: https://github.com/snapcore/snapd/pull/614512:51
zyga+87 -10 so not terrible12:51
zygamostly just tests12:51
mupPR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  πŸŽ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>12:51
zygaactually not mostly just tests12:51
zygabut not much anyway :)12:51
mborzeckioff to pick up the kids13:10
pstolowskiChipaca: i'd be happy to approve #6107 when you add the missing test case, then it could land13:34
mupPR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>13:34
pedronispstolowski: I was a bit surprised that it really did show the column, not even name13:37
pedronisI mean 610713:37
pedronisalso the prereq doesn't have two reviews13:40
pedronisChipaca: I left a note in #6107, we should talk a sec on it13:40
mupPR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>13:40
mborzeckire13:41
zygamborzecki: first bug also fixed, spread test took longer to write13:42
zygabut I'm happy with the outcome13:42
mborzeckipstolowski: question about interface hooks, is the hooks executed under the security profile that comes from the interface?13:42
zygamuch better than the original unit test13:42
zygafired it up now, should be ready by standup13:42
mborzeckizyga: thanks for the fixes :)13:42
zygathank you for finding bugs :)13:42
mborzeckiheh13:43
pstolowskimborzecki: depends, prepare-slot-*, prepare-plug-* - are not. connect-plug-*, connect-slot-* yes13:43
pstolowskipedronis: hmm, i see what you mean13:43
mborzeckipstolowski: i'm using connect-plug-opengl, hm maybe i need to look into that further13:44
pstolowskimborzecki: let me know the details if you obseve anything suspicious. you might be the first one to make use of interface hooks..13:47
mborzeckipstolowski: i don't need to declare plugs for interface hooks, do I? i mean it's it's a connect-plug-opengl hook then it runs with opengl plug implicitly, doesn't it?13:48
zygamborzecki: interesting but doubtful13:53
zygamborzecki: the hooks have the snap-level interfaces only13:53
sergiusenszyga: I am getting this cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied when I try to run a snap try inside lxd13:53
zygaanything scoped will *not* affect hooks13:53
zygasergiusens: what's the kernel version and snapd version?13:53
zygasergiusens: please report a bug, I will investigate13:54
pedronismborzecki: there is no code to make that implicit afaik, so either global plug, or the hook needs to list the plug13:54
zygasergiusens: (we're now using bugs for ... bugs) :-)13:54
sergiusenshttps://www.irccloud.com/pastebin/SoCmFTkp/13:54
sergiusenszyga: I do not believe you!13:54
sergiusensI have been conned into reporting bugs before ;-)13:55
zygasergiusens: thank you, the host is ~~~ 18.04 or newer, I presume?13:55
zygasergiusens: and the host is xenial container, right?13:55
sergiusensyes, xenial13:55
sergiusensalso, the snap uses bases13:55
mborzeckipedronis: yup, adding plug explicitly made it work13:55
zygasergiusens: please report it, I'll check it out after writing tests for another fix13:56
pstolowskizyga: one question re 6145, otherwise +113:59
zygalooking13:59
zygapstolowski: replied14:01
zygathank you for the review, this PR is the most important to move other mount stuff forward14:01
pedronisChipaca: standup ?14:02
pedroniszyga: ^14:02
zygaoh, joining14:02
sergiusenszyga: got it to work by installing core...14:03
zygasergiusens: interesting14:03
mupPR snapd#6159 opened: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>14:05
om26erpopey: ping14:14
popeyPONG!14:14
zygaecho echo echo14:15
om26erpopey: the asciinema upstream wants to update its snap to latest version but the snap was uploaded by MarkS, so wanted to know what's the procedure to get that snap uploaded from their official account ?14:15
om26erhttps://github.com/asciinema/asciinema/issues/296#issuecomment-43802508314:16
popeyWimpress is about to be in the same physical location as sabdfl, maybe he could mention it :)14:16
om26erso basically they are willing to move the packaging under their github org and I am committing to maintenance there.14:17
popey(I think transferring the snap upstream is the best course of action)14:17
om26eryep14:17
popeyi have let wimpy know, he's on a plane right now, but I'm sure he'll pass the message on when he gets there :)14:18
popeythanks for letting us know om26er14:18
om26erpopey: sounds good to me, cheers!14:18
mupPR snapd#6160 opened: nvidia, interfaces/builtin: OpenCL fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6160>14:22
* cachio lunch14:57
WimpressAt the airport. I'll mention to Mark.14:58
zygaquick break15:08
* pedronis mostly eods (will be back for some meeting later)15:17
mvomborzecki: heh, I was about to ask about 6160 and if we should pull it into 2.36 and then you added the milestone. thanks for this!15:20
mupPR snapd#6160 closed: nvidia, interfaces/builtin: OpenCL fixes <Simple πŸ˜ƒ> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6160>15:21
mvomborzecki: could you please create a pr based on 2.36 for this? I tried to cherry-pick but the second commit does not apply cleanly15:21
mborzeckimvo: sure15:22
mvota15:22
mborzeckimvo: i think we shoud also pick https://github.com/snapcore/snapd/pull/569615:24
mupPR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>15:24
mvomborzecki: ok, let me see if I can cherry pick this15:24
mborzeckialso that's what 6160 is conflicting with15:25
mvomborzecki: done, this is in 2.36 now15:25
mborzeckimvo: ta15:25
mborzeckimvo: 6160 will now apply cleanly on top of 2.36, do you want to me open a PR?15:26
mvomborzecki: no, thats fine then15:27
mborzeckiok15:27
mvomborzecki: done, thanks again15:28
mborzeckinp15:28
zygare15:57
zygataht was a longer quick break but I did handle both lunch and the dog :)15:57
sparkiegeekate the dog and fed the lunch?15:57
zygaunfortunately no hot-dogs :)15:58
* zyga sighs seeing a test fail on 14.04 15:59
zyga"fun"15:59
zygathey said crying ;)15:59
zygalet's see15:59
pstolowskizyga: #6158 can land?16:01
mupPR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>16:01
zygapstolowski: yes, please16:01
mupPR snapd#6158 closed: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6158>16:01
zygamvo: can we have milestones on launchpad?16:02
zyganow that we have bugs we could do that too :)16:03
mvozyga: yeah16:03
* zyga could use a 2nd review on https://github.com/snapcore/snapd/pull/614516:03
mborzeckizyga: 6158 for 2.36 too?16:03
zygamvo: I looked but I cannot add any16:03
mupPR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  πŸŽ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>16:03
zygamborzecki: so that's a good question, I can make a backport if mvo agrees16:03
zygait's fairly simple and significant16:04
mvozyga: I created one, how do you want to use it?16:04
zygaone sec16:04
mvozyga: backport for what? sorry, miss context16:04
zygamvo: sorry, two topics16:04
zygamvo: one topic: the milestone, on lauchpad, I'd love to be able to set milestone for this bug: https://bugs.launchpad.net/snapd/+bug/180353516:05
mupBug #1803535: Certain layouts cannot be constructed correctly <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1803535>16:05
mvozyga: added the milestone, go wild16:05
zygamvo: topic two, shall I create a backport for this issue and propose it for 2.36 release branch?16:05
zygamvo: I don't have the permission16:05
mvozyga: yes please, also no need for a backport if it can be cherry-picked cleanly16:05
zygamvo: so shall I just push into the release branch?16:05
mvozyga: I created the milestone in LP now, do you need more?16:05
zygait should be clean16:05
mvozyga: yeah, if its clean cherry picks thats fine16:06
zygamvo: yes, I cannot assign the milestone to the bug16:06
zyganot sure which LP permission governs that16:06
mvozyga: I targed it to the series16:06
mvozyga: but you should also be able to do that16:07
zygamilestone column was empty for me16:07
zygathanks for doing that16:07
zygaI see "target to series"16:07
zygaand I can target it for "trunk"16:07
mvozyga: that is confusing, let me check16:09
zygamvo: cherry picked and pushed to the 2.36 release branch16:09
zygamvo: I TG a screenshot of what I see16:09
mborzeckizyga: findmnt in ubuntu 14.04 cannot do --output=PROPAGATION16:10
zygamborzecki: yeah, I just installed it to play16:14
zygablast from the past :)16:14
zygaunity16:14
zygamborzecki: there's RHEL 8 beta!16:15
mborzeckizyga: heh, which kernel version? 3.17? :)16:16
zygahold on :)16:16
zygamborzecki: downloading, I will let you know16:19
mborzeckizyga: hm don't see it on developers.redhat.com16:20
zygayou need to opt into the beta16:21
zygahold on16:21
mborzeckiaah there it is16:21
zygahttps://access.redhat.com/products/red-hat-enterprise-linux/beta?extIdCarryOver=true&sc_cid=70160000000dJVaAAM16:21
zygamborzecki: boot iso or binary dvd?16:22
zygaI'll get both16:22
zygabut weird...16:22
mborzeckizyga: signed up just now16:23
threshat least 4 something cause it says bbr everywhere16:23
=== Pharaoh_Atem is now known as Conan_Kudo
=== Conan_Kudo is now known as Pharaoh_Atem
threshyou need binary16:24
threshat least thats what they say in the mail16:24
mborzeckizyga: hm ppc64le, aarch64 :)16:25
zygamborzecki: and there's a new raspberry pi!16:25
zygaPi 3 A+16:25
zygano eth, just wifi16:25
zyga119PLN16:25
mborzeckino emmc?16:25
ograyeah ... as poorly designed as the b+16:25
zyga512MB ram16:25
zygaWTF16:25
ogra(high speed networking on a USB2 hub)16:25
zygano emmc16:26
ograindeed16:26
zygaI'll pass16:26
ograonly the cm3 has MMC16:26
mborzeckiso still nothing more than a curiosity ;)16:26
ograyeah16:26
mborzeckiwish i could do something useful with my CHIP though16:27
ograport core to it !16:27
mborzeckiiirc there was a gadget for it16:27
zygawhat's the HW inside the chip?16:28
ograthere is a chip inside the chip ;)16:28
zygayes :D16:29
mborzeckizyga: https://en.wikipedia.org/wiki/CHIP_(computer)16:29
mborzeckithe company went belly up :)16:29
zygamaking products for $9 tends to make that happen16:30
zygaI think I know how to use findmnt and not cry a river over 14.0416:31
* zyga tweaks16:31
ograwell, marketing it for $9 and producing it for $30 or so ...16:34
ograwasnt the cleverest strategy :)16:34
mupPR snapcraft#2409 opened: python plugin: process deps before and separately from setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2409>16:35
* zyga -> school 16:43
zygaok, fixed 14.04 tests (hopefully)17:02
mupPR snapd#6155 closed: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6155>17:08
cachiomvo, sorry, is it .dot files interface already merged?17:10
mvocachio: it is still in review, one sec, let me find the pr number17:12
mvocachio: 584517:13
cachiomvo, I just discovered that17:13
cachiothanks17:13
mvoyw17:14
mvothanks for looking into it17:14
cachioI could add the test to that PR, or create a new branch, what do you prefrer?17:15
mupPR snapd#6123 closed: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6123>17:16
zygamvo: I didn't notice https://github.com/snapcore/snapd/pull/6128 is merged!17:25
mupPR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>17:25
zygaI'll push tests to a follow-up17:25
zygacan we get an edge build17:25
zygaand let the customer know17:25
zygaanyone for a 2nd review of https://github.com/snapcore/snapd/pull/6145 ?17:34
mupPR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  πŸŽ> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>17:34
* zyga considers wrapping up17:42
zygamvo: do you think you could look at https://github.com/snapcore/snapd/pull/6111 tomorrow, nothing binding, just tell me what you think17:43
mupPR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>17:43
zygamainly at the makefile path17:43
zygaas spec file is probably not terribly interesting17:43
popeyIs there some env var I need to set for classic snaps to 'find' GL drivers? Where do I point it?19:09
popey(not using desktop helpers)19:09
mupPR snapd#6161 opened: tests: new test suite to run snapd tests on a google remote instance <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6161>20:02
zygapopey: dunno20:22
* zyga came to check on PRs20:22
mupPR snapd#6162 opened: interfaces/greengrass_support: update accesses for GGC 1.6 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6162>21:48

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