/srv/irclogs.ubuntu.com/2019/03/07/#snappy.txt

=== chihchun is now known as chihchun_afk
=== MeiQianChiFan is now known as glibc
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
mborzeckimorning06:06
mborzeckizyga: mvo: https://paste.ubuntu.com/p/JtBVwYzqqH/ seems like the guess from yesterday was correct06:34
mborzeckisnapd snap in mounted at some tmp location, but the code locating snap-seccomp in seccomp backend only picks snapMountDir + .. or distro libexecdir06:35
mvomborzecki: nice find07:07
mvomborzecki: so we just need to make snapd look at its own exe location first?07:07
mvomborzecki: I think that makes sense anyway07:07
mborzeckimvo: yes, we do it already for system-key07:07
mvomborzecki: \o/07:08
mborzeckimvo: anyways, added a unit test and pushing a patch in a minute07:08
mvomborzecki: thank you07:10
zygaGood morning07:15
mvomborzecki: curious why this is failing now - or is the PR doing more than "just" the on-changed compiling of the bpf?07:16
mborzeckimvo: the PR tries to run snap-seccomp to get the version information when the seccomp backend is getting initialized07:17
mvomborzecki: aha, I see07:17
mvomborzecki: that makes sense07:17
mborzeckimvo: afaik we haven't run any of the internal tools until now07:17
zygaAha!07:17
zygamborzecki: interesting07:17
mvomborzecki: yeah, bootstrap is very limited07:19
mvomborzecki: otoh, you could simply ignore seccomp missing, the first snap installed during bootstrap will be snapd and then snapd restarts07:19
zygaComplexity :/07:21
mborzeckipushed a patch07:26
mvocan I interest someone in a second review for 6381? should be straightforward07:30
mborzeckimvo: looking07:38
mborzeckimvo: does it make sense to have a remodel when there are no changes to the kernel and required snaps, so that only set-model task runs?07:56
mborzeckinvm, answered that myself :)07:57
pedronismborzecki: hi, we are still missing bits of snap connections ?   content[foo] is not there yet, right?07:58
mborzeckipedronis: yes, it's not there yet07:59
pedronismborzecki: the idea was to have a followup right after08:00
pedronisright now seems we will ship 2.38 without and 2.39 with?08:00
pedronismvo:  ^08:00
mvopedronis: if its easy we can pull it into 2.38 still08:00
mborzeckipedronis: ah, ok, wanted to address soem feedback in selinux branches, but i can to that bit of connections first08:00
mvopedronis: we are only at ~pre1 yet08:00
pedronismvo: it should be contained08:01
mvoyeah, having the full thing in 2.38 seems desirable08:01
mborzeckiok, will look into that then08:01
mvota08:01
pedronismborzecki: mvo:  from my POV  prioties are "snap connections" because 2.38, we are so close. SELinux because its going on since log. seccomp opts because it's 2.39 stuff anyway and it's an opt08:02
pedroniss/log/long/08:02
pedronismvo: ^, reasonable?08:03
mvopedronis: +108:03
pedronismborzecki: thanks08:06
pstolowskimorning08:06
pedronisthe seccomp PR has grown quite a bit :/ , the direction is good though08:07
zygaBack from walk, I’ll be in the office soon08:11
mborzeckiaand #6485 is green!08:24
mupPR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>08:24
mborzeckineed to gram some coffee08:25
mvohey team - I updated the https://forum.snapcraft.io/t/the-snapd-roadmap/1973 roadmap page for 2.38 - if your favorite thing is missing please do let me know and I add it09:02
zygaThank you!09:04
ograogra@nanopc-t4:~$ lxc launch ubuntu:16.04/armhf snapcraft-armhf09:05
ograTo start your first container, try: lxc launch ubuntu:18.0409:05
* ogra scratches head ... why is it telling me the command i just used :P09:05
mvo6565 is an easy win…09:06
mupPR snapd#6567 closed: overlord/snapstate/backend: make LinkSnap clean up more <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6567>09:07
mupPR snapd#6498 closed: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6498>09:18
zygamvo: https://github.com/snapcore/snapd/pull/6565#pullrequestreview-211672889 is ready09:23
mupPR #6565: snap: remove obsolete license-* fields in the yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/6565>09:23
mvozyga: \o/09:23
mupPR snapd#6565 closed: snap: remove obsolete license-* fields in the yaml <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6565>09:24
zygainteresting feature: https://help.github.com/en/articles/about-pull-requests#draft-pull-requests09:45
=== tobias is now known as Guest35082
mupPR snapd#6574 opened: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>09:51
zygaanother interesting github feature https://help.github.com/en/articles/about-code-owners09:55
mupPR snapd#6381 closed: devicestate: add initial Remodel support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6381>09:58
=== tobias is now known as Guest88232
=== ricab is now known as ricab|bbl
ograsil2100, seems zyga just merged https://github.com/snapcore/pi3-gadget/pull/20 can you make sure we get a release of it into stable ?10:32
mupPR pi3-gadget#20: dots in interface names are not allowed, fix spi <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/pi3-gadget/pull/20>10:33
ogra(this is actualyl one of the files that actually upgrade on gadget upgrades, so it is valuable even without new images)10:33
=== alan_g_ is now known as alan_g
pstolowskipedronis: updated https://github.com/snapcore/snapd/pull/656210:39
mupPR #6562: timings: base API for recording timings in state <Created by stolowski> <https://github.com/snapcore/snapd/pull/6562>10:39
pstolowskipedronis: thanks for another pass on nestedvm PR10:41
sil2100I need to finally sort out the branch ownership, was too busy with the point releases in  the last weeks10:41
sil2100eh10:41
sil2100ogra: will add that to my TODO list, will push it through as soon as possible but there's a lot going on right now10:41
* dot-tobias says hi10:56
pedroniszyga: 6574 is a prereq for 6502 to actually work?11:07
dot-tobiasI can't seem to find an update which snapcraft version is currently used for launchpad builders (latest was https://forum.snapcraft.io/t/launchpad-now-builds-snaps-in-lxd-containers-in-support-of-build-snaps/2002/23 , question asked ~20 days ago in https://forum.snapcraft.io/t/snapcraft-version-used-by-launchpad-and-docker-images/9994)11:08
zygapedronis: correct11:10
pedroniszyga: does it fail, or simply the checks always pass?11:11
pedronisah, the checks are not called yet11:12
pedroniszyga: you should probably concetrate on landing a good chunk of your open PRs, I'm starting to get lost in them :)11:13
zygapedronis: it would say that there are some apps running but it is unable to say which so the check would fail11:13
zygafail as in prevent refresh11:13
zygaack11:14
zygapedronis: I updated https://github.com/snapcore/snapd/pull/6571 jus tnow11:22
mupPR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>11:22
zygaapart from hideous formatting I think it looks okay now11:23
zygapedronis: I also updated the remaining two branches from the invocation work11:32
mborzeckipedronis: for the connection11:36
mborzeckiah, damn, noticed that i switched to -internal with the paste11:36
dot-tobiascjwatson: Can you please tell me the correct syntax for LP builds “Source snap channels for automatic builds” in snap package configuration? I want to use snapcraft from latest/stable and core16 from latest/beta, do I just use the channel name or full track/channel?11:38
pedronismborzecki: we might let you do with --dangerous but is a bit of special case11:39
pedronisif they come from the store content needs to mathc11:39
pedroniseven just for connecting11:39
cjwatsondot-tobias: either "latest/stable" and "latest/beta" or just "stable" and "beta" is fine11:40
cjwatsondot-tobias: but do you really mean core16?  I think you probably mean core11:40
cjwatsondot-tobias: AIUI core16 isn't really a thing yet11:40
dot-tobiascjwatson: Thanks for the clarification! Seems the build errors are in fact because I specified core16 (currently only available on the beta channel), but want "core". Related question: I'm a bit confused by the “Series” radio buttons up top in the same form – stating “Bionic, for Ubuntu Core 16”. Does that mean it'll run a Bionic LXD container which then utilises the “core” snap …?11:44
cjwatsondot-tobias: We'll be cleaning up the confusing "Ubuntu Core 16" bit there in the near future since it doesn't make as much sense as it used to11:47
cjwatsondot-tobias: In most cases now you should just select "Ubuntu Core 16" (without any explicit Ubuntu series) and let LP work out what to do for itself11:47
dot-tobiascjwatson: Will do that, thank you very much!11:48
cjwatsonThat causes it to dispatch to a container based on what "base" in snapcraft.yaml says11:48
cjwatsonSo base: core18 dispatches to a bionic container, otherwise we dispatch to a xenial container11:48
cjwatsondot-tobias: I've committed a patch to allow explicitly setting the channel for core16 (and for that matter core18), but it's not on production yet11:49
cjwatsonAt the moment you can only select channels for core and snapcraft11:49
aleksanderhey! how can I make a confined snap "properly" access a unix abstract socket exposed by a process in the system?11:53
dot-tobiascjwatson: Good to know. My use of “core16” was more due to confusion between core and core16, so I think my snap will be fine with just “core” for now. Only thing keeping me from upgrading to core18 is its reliance on a specific network-manager version11:53
aleksanderabeato: ^? (this is so that fwupd snapd can talk to a modem through the qmi-proxy socket)11:53
zygamvo: I added a small spread test to https://github.com/snapcore/snapd/pull/657411:54
mupPR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>11:54
Chipacaaleksander: what provides the socket?11:55
aleksanderChipaca: the socket is exposed by the "qmi-proxy" process, and the proxy process forwards QMI messages to a USB modem11:56
mvozyga: ta11:56
Chipacaaleksander: but, how do you know that process is there when you install the snap?11:56
aleksanderChipaca: well, that process is there when ModemManager is running11:57
Chipacaaleksander: is modem manager in a different snap?11:57
aleksanderfwupd won't try to use the socket unless MM is running already11:57
aleksanderChipaca: yes, ModemManager may be system-installed or in its own snap I guess11:58
Chipacaaleksander: how does fwupd know mm is running?11:58
aleksanderactually, I'm not sure how libqmi/qmi-proxy are packaged, I guess they may be provided in the same snap as ModemManager? abeato should know11:58
aleksanderChipaca: fwupd talks to MM via DBus11:58
Chipacait sounds like the modem manager interface should allow access to the qmi proxy11:59
aleksanderat the time fwupd talks to the modem through qmi-proxy, ModemManager knows nothing about the modem as fwupd "inhibits" the device12:00
aleksanderand I definitely wouldn't want to make ModemManager allow raw QMI commands anyway...12:01
zygasmall break for 3rd coffee12:01
zygaare you guys also this sleepy lately12:01
zygaor is it just me? :(12:01
zygais is the weather or is that the baby12:02
aleksanderzyga: haha, the newborn syndrome I guess? I feel that12:02
zygaaleksander: I guess I got my answer :)12:02
aleksanderbe prepared for years of sleep deprivation12:02
zygaaleksander: yeah, constant wake-ups at night12:02
Chipacait's not that bad12:02
Chipacait gets better12:02
Chipacai'm told12:02
aleksanderhahaha12:02
zygayeah, I think it is only about three months12:02
aleksanderso I'm told as well, and I haven't had a full night of sleep in 3 years by now12:02
zygawe're already 1/3rd of the way12:03
* Chipaca does some fast maths and reckons 14 years and counting12:03
aleksander:D12:03
zygaaleksander: oh really?12:03
Chipacazyga: it changes in nature12:03
zygain either way, COFFEE12:03
zygaEAGAINCOFEEE12:03
aleksanderat 2.5 years old, the firl started to sleep better, which is when we had the baby boy, and back to square 112:03
aleksanderthe *girl started to sleep better12:04
Chipacaaleksander: you should've paralellised12:04
zygaChipaca: lol12:04
aleksanderChipaca: so back to the issue, is there any way to run this fwupd snap in a way that has access to the system-exposed unix abstract socket?12:12
dot-tobiascjwatson: Just FYI, “core” works fine but for whatever reason the ruby plugin only likes core16/core1812:13
dot-tobias(https://github.com/snapcore/snapcraft/blob/ade7d65f0ba7870add2ed5ba5c016a93db2f88b8/snapcraft/plugins/ruby.py#L77)12:13
Chipacaaleksander: not a priori, no12:14
aleksander:(12:14
Chipacaaleksander: is there already code in the snap that tries to do this?12:16
aleksanderin the fwupd edge snap channel, yes12:16
Chipacawait12:18
zygapedronis: https://github.com/snapcore/snapd/pull/6571 is green12:18
Chipacaaleksander: fwupd is classic12:18
mupPR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>12:18
Chipacaaleksander: i thought you said it was strict?12:19
aleksanderChipaca: does this mean that fwupd as being a classic snap should be able to see abstract unix sockets without issues?12:21
Chipacaaleksander: yes12:21
Chipacaaleksander: 'classic' means 'as in a deb'12:21
aleksanderChipaca: I may have assumed fwupd was confined, I'm still a bit lost on snap world :D (my first day actually, I'm learning...)12:21
Chipacaaleksander: :-)12:22
aleksanderoh, that's fine then I guess? humm.. I wonder why I couldn't make that work12:22
Chipacaaleksander: classic also means it won't work in the pure-snap world, as well as having security implications12:22
dot-tobiaskyrofa: Is there a reason that the ruby plugin only supports core16/core18, but not core as a base? (cf. https://bugs.launchpad.net/snapcraft/+bug/1794800)12:22
mupBug #1794800: Update the ruby plugin to be base aware <18.10-build-vm> <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1794800>12:22
zygaaleksander: hey, I think we've met before, no?12:23
aleksanderChipaca: I believe that's something that is taken for granted for the fwupd package12:24
Chipacaa shame12:24
aleksanderzyga: hummmm not in the real world I think, but we discussed a long ago about a way to avoid MM poke TTYs12:25
ograIIRC theer was work started to eventually have a fwupd interface, no ?12:25
aleksander(IIRC)12:25
zygaaleksander: ahh, that's correct!12:25
zygaaleksander: nice to see you here, welcome! :)12:25
aleksander:D12:25
zygaaleksander: if you have snap questions please ask us anything12:26
aleksanderzyga: we "fixed" the wrong poking of TTYs btw... :P12:26
zygaoh? how does that work now?12:26
aleksanderzyga: only if we're very certain that a TTY belongs to a modem we do poke it, we have some heuristics in place to do that automatically12:27
vidal72[m]is there a way to see which snaps use core18?12:27
aleksanderwe've lost automatic detection of some old modems, but that's fine I guess12:27
pedroniszyga: that series need at least a step 4, right? to pass sc_invocation at least to the functions changed in -3 to take is_normal_mode12:27
zygapedronis: yes, there will be more patches, depending on how big the PRs get12:27
zygapedronis: I'm making sc_invocation public now, so that we can easily pass it around12:28
pedroniszyga: I'm happy to stop there to be clear, I don't think we need to do everything now12:28
pedronisI mean at this step 412:28
zygapedronis: OK12:28
zygapedronis: yeah, this should allow us to return to mvo's branch12:28
pedronisyes12:28
zygapedronis: I'm happy to explore more refactoring and design once you have some interactive time12:29
aleksanderChipaca: ok, I got more details about my issue with the proxy process... so, by the time fwupd wants to talk to the proxy, the proxy doesn't exist any more. fwupd is using libqmi/libmbim and this library is in charge of starting the process if it's not already running, so in this case, it's the fwupd snap the one trying to launch the proxy process, and failing12:41
aleksanderI think I'm going to just prepare a dirty hack to avoid this... :D12:46
abeatoaleksander, hey, just back from lunch12:49
abeatoaleksander, libqmi and libmbim are part of the MM snap12:50
aleksanderabeato: aha, I guessed that, and so the proxies as well?12:50
abeatoaleksander, if you need access to something from HW probably best to do is to modify the MM snapd interface12:50
abeatoaleksander, yes12:50
aleksanderabeato: so if there is any other app that wants to use QMI, it needs to rely on the MM snap somehow?12:51
abeatoaleksander, nope, you could bundle the library in that new snap12:51
aleksanderI have a feeling that the fwupd snap also has libqmi inside actually12:51
abeatoaleksander, in snaps in general we prefer to bundle most dependencies in12:52
aleksanderbut the proxy is not there12:52
zygapedronis: is https://github.com/snapcore/snapd/pull/6571 something you want to review in detail again or are you waiting for the full series to review?12:52
mupPR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>12:52
abeatoaleksander, hm, talking to the proxy from the MM snap could be tricky12:52
aleksanderabeato: and imagine this case: snap fwupd runs, uses libqmi and libqmi starts the proxy, then fwupd exits; what happens with the proxy?12:52
pedroniszyga: I can review it,  it would be good to have also step 4 before starting landing things though12:53
abeatoaleksander, it should be stopped I guess12:53
aleksanderis it kept alive in the system, or no because it was run as part of the snap fwupd?12:53
aleksandershould or will? I mean, what will the snap setup do right now?12:53
abeatoaleksander, it will not do anything special unless instructed12:54
aleksanderoh ok ok12:54
zygapedronis: ok, I'll get that up12:54
abeatoaleksander, what I see is that there is a dependency here, I assume that ideally you will want to use the proxy from the MM snap to do the update12:54
abeatoaleksander, but the fw updater would run from a different snap12:55
aleksanderso I have several ways to fix this issue, I can make the proxy not exit after 30s (if no clients connected) and let it exit e.g. after 300s, and that would allow snap fwupd to do the upgrade properly using the proxy that was already running in the system; or otherwise I could package inside the fwupd snap the proxies as well, and let libqmi/libmbim start the proxies from within the snap if needed12:55
aleksanderat this point, I'm not even looking at the MM snap, I'm assuming there's a system-installed MM, truth be told12:56
aleksanderabeato: is the MM snap confined?12:57
abeatoaleksander, I think it is fine to assume MM is installed. Yes, was about to tell you that - the main issue is to be able to access the proxy from the fwupd12:57
abeatoif both are in different snaps12:58
aleksanderoh, so MM snap is indeed confined and the proxy within the MM snap runtime isn't accessible from other processes?12:58
abeatocorrect12:58
aleksanderouch :)12:58
aleksanderok, won't tell anyone12:58
abeatowe do allow access to MM dBus interface12:58
=== ricab is now known as ricab|lunch
abeatowhich is the interface for the proxy? a socket?12:59
aleksanderyes, abstract unix socket12:59
Chipacaabeato: two things12:59
Chipacaabeato: one is that maybe access to that socket should be made part of the mm interface?12:59
Chipacaabeato: second is that, given fwupd is classic, maybe they can access it anyway12:59
abeatoChipaca, yeah, of a new interface12:59
abeatos/of/or/13:00
Chipacaabeato: of/or?13:00
Chipacaheh13:00
aleksanderChipaca: oh is that possible? can the socket be made part of the mm interface?13:00
Chipacathere's already some qmi stuff in there13:00
Chipacaso, maybe?13:00
Chipacadunno13:00
Chipacais it an interface to access mm, or is it an interface for mm to do its thing?13:00
aleksanderwhere's the mm snap interface defined?13:00
Chipacathat is, is it a mm-client, or a mm-support?13:00
abeatoaleksander, https://github.com/snapcore/snapd/blob/master/interfaces/builtin/modem_manager.go13:01
aleksandermm-support13:01
aleksanderprovides shared access to the QMI port exposed by the kernel13:01
abeatoaleksander, not sure how familiar are you with slots/plugs. See https://docs.snapcraft.io/interface-management/6154 for an intro13:01
Chipacaah, so not that interface :-/13:01
Chipacaabeato: is there a -client interface for mm?13:01
abeatoChipaca, maybe it would make more sense to add a new interface instead of modifying mm's, as usually MM clients don't need direct access to the qmi proxy13:02
mborzeckioff to pick up the kids13:02
abeatoChipaca, yes, used by mmcli and NetworkManager13:02
Chipacaabeato: what interface do mm clients use to talk to mm?13:02
abeatomodem-manager interface13:03
Chipacahmmm13:03
Chipacaabeato: but that's the interface that allows a snap to _be_ modem manager13:04
abeatoChipaca, well, it defines a slot and a plug13:04
abeatoslot for MM, plug for users13:04
Chipacaah, i missed that bit :-)13:04
abeatoand maybe it would make sense to have a new interface, with the slot implemented by MM and the plug used by fwupd13:06
Chipacaabeato: fwupd would need a whole new interface just for all the stuff it needs to do :-)13:08
abeatoChipaca, agreed in deed :)13:10
cachiomvo, hey13:10
cachiohttps://paste.ubuntu.com/p/KXrkfp26WC/13:10
* pstolowski lunch13:11
cachiothis is an error I see in all the core systems13:11
cachiois it intentional or it should exit 1 as it used to?13:11
mvocachio: this was requested by the mir team that apt should error - and it does make sense I think, its not usable afterall. is it causing problems for you?13:15
cachiomvo, no, just a test failing13:17
mvocachio: which one? I though I fixed them13:17
cachiomvo, ubuntu-core-apt13:17
cachioit failed in all the executions yesterday13:18
* mvo looks13:19
zygapedronis: -4 is open https://github.com/snapcore/snapd/pull/657513:39
mupPR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>13:39
pedroniszyga: thank you13:39
zygapedronis: I tweaked sc_invocation a little, there are many more cleanups that can be done on top but I think those are no longer on the critical path13:39
mupPR snapd#6575 opened: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>13:39
zygapedronis: the new patches in that PR start with "cmd/snap-confine: make sc_invocation public"13:40
zygapedronis: please pay special attention to https://github.com/snapcore/snapd/pull/6575/commits/daa62250d09b01e59b66db203c31227202f22bbf13:40
mupPR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>13:40
pedroniszyga: that looks good, the param in the function could be const though no?13:48
pedroniswe just need to modify in enter ?13:48
pedronis*functions13:49
zygapedronis: yes13:54
zygapedronis: though I would prefer to first solve the issue of ubuntu-core13:54
zygapedronis: where we modify the base snap name locally, see if we can make that properly earlier across the whole snap-confine invocation13:55
zygapedronis: or if we can move it away to snap-run13:55
zygapedronis: then we can make it constant with clarity13:55
pedronisI'm doubtful about snap run13:55
pedronisunless we want to do more than a refactoring13:55
pedronisanyway it's clear that ubuntu-core fallback was broken13:56
pedronisin more than one way13:56
pedronisbut is probably a good step to fix it as prep13:56
pedronisanyway13:56
zygapedronis: after I'm done with current branches I can move that fallback earlier, and have it modify the invocation object before we pass the read only to other functions13:57
pstolowskiis google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify failing a known issue / flaky test? i've been seeing it recently from time to time13:59
pedroniszyga: yea14:00
mborzeckipstolowski: the test is a little tricky, maybe some race between systemd/service and logs?14:02
=== chihchun is now known as chihchun_afk
=== ricab|lunch is now known as ricab
mupPR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479,15:26
mupsnapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#249415:26
mupPR snapd#6576 opened: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>15:28
mupPR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479,15:29
mupsnapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#249415:29
Saviqroadmr: hey, do we need one more vote on https://forum.snapcraft.io/t/track-request-multipass-core16/10192 ?15:32
roadmrSaviq: yes, we do :/15:40
mupPR snapcraft#2495 opened: Hide progress bar for dumb terminals - legacy branch <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2495>15:41
zygaSaviq, roadmr: and now you have15:42
Saviqzyga: thanks :)15:44
zygamvo: can you have another look at https://github.com/snapcore/snapd/pull/6574 please - I fixed a typo in the test and confirmed that it passes in qemu15:45
mupPR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>15:45
zyga(the typo was test-snapd.sh instead of test-snapd-sh)15:45
* zyga needs to run an errand15:48
kyrofadot-tobias, have you ever tried that? https://paste.ubuntu.com/p/kBmSrpQ89k/15:57
dot-tobiaskyrofa: No I did not, that's a very valid reason of course. Didn't want to imply an oversight or else, just wondering why a plugin might exclude a certain base (and because I hoped I could streamline my test/build workflow a bit :-) )16:00
kyrofadot-tobias, yeah there's sadly a bit of gap between using bases for core/core16 and using bases for core18. Core isn't seemingly a valid base, core16 isn't stable, so core18 is the only option if you're using a base. If you want to build for core, don't specify a base and you get the old snapcraft behavior16:02
dot-tobiaskyrofa: Will do, thanks for the clarification.16:03
kyrofadot-tobias, sure thing. Regarding your actual question though, we tend to only support bases we've explicitly tested. If Fedora were to make their own, the plugin would need to grow support for it and potentially work a little differently16:04
kyrofamvo, what kind of ETA are we looking at for the switch from core to snapd+core16?16:06
pedronis#6571 needs a 2nd review16:10
mupPR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>16:10
mvokyrofa: is the context bases for snapcraft? we had a discussion about "base: none" during the malta sprint to unblock people16:22
kyrofamvo, indeed, good to know, thank you :)16:22
mvokyrofa: I need to step out for some minutes but maybe someone else from the team can summarize the idea, I can also when I'm back, we have notes and all that :)16:24
Chipacadegville: https://forum.snapcraft.io/t/snap-epochs/1031617:13
degvillethank you Chipaca! I'll take a look.17:13
Chipacanot super happy with it, feels like I should make a little graphic to make it clearer17:14
pedronisChipaca: ping wgrant about it as well17:16
Chipacawgrant: https://forum.snapcraft.io/t/snap-epochs/1031617:18
=== pstolowski is now known as pstolowski|afk
mupPR snapd#6571 closed: cmd/snap-confine: introduce sc_invocation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6571>20:58
zygajdstrand: FYI, replied on https://github.com/snapcore/snapd/pull/657422:10
mupPR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>22:10
King_InuYashaniemeyer, zyga: https://flocktofedora.org/22:23
King_InuYashaFlock 2019 site is up :)22:23
pedroniszyga: when you have time could you push master into -2 etc ?22:35
mupPR snapd#6532 closed: daemon: allow downloading snaps blobs via .../file <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6532>22:47
zygapedronis: sure22:51
mwhudsonhm23:19

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