| erio | hello | 01:00 |
|---|---|---|
| sergiusens | erio: `source-branch` should do the trick | 01:33 |
| sergiusens | joc: mind looking into https://travis-ci.org/snapcore/snapcraft/jobs/435246430#L1574 during your morning? | 01:33 |
| erio | whoa | 01:41 |
| erio | hey sergiusens | 01:41 |
| erio | thanks | 01:42 |
| erio | if you ever find time, I really really need help doing this snap https://github.com/ericoporto/ags-snap | 01:43 |
| erio | I can't find a way to consistently build it on my computer vs on build.snapcraft.io | 01:45 |
| erio | a ton of my adventure is reported here: https://forum.snapcraft.io/t/need-help-to-snapcraft-alsa/7647 | 01:46 |
| erio | and here: https://github.com/ericoporto/ags-snap/issues/4 | 01:46 |
| erio | the whole source of bugs is alsa | 01:47 |
| erio | I couldn't figure out how to make parts being built to link and include each other in a way it works | 01:49 |
| erio | I've been online trying to make this for 40h already, gotta sleep. | 01:49 |
| cwayne | sergiusens: joc is off next week FYI | 02:02 |
| mborzecki | morning | 05:14 |
| * Son_Goku waves | 05:14 | |
| Son_Goku | I'm finally heading to sleep | 05:14 |
| Son_Goku | mborzecki, I'm working on a rollback patch for snapd packaging in Fedora so that the SELinux policy compiles again on EL7 | 05:18 |
| mborzecki | Son_Goku: yay, thank you! | 05:18 |
| mborzecki | Son_Goku: need any help? | 05:18 |
| Son_Goku | at the moment I'm fine | 05:18 |
| Son_Goku | just tired and sick | 05:18 |
| Son_Goku | the confirmation that I can't get around the dumb issue with glibc-static is what made me give up on trying to workaround it while preserving hardening flags | 05:19 |
| Son_Goku | mborzecki, could you also file a bug report about that against RHEL 7? | 05:19 |
| mborzecki | Son_Goku: ok | 05:20 |
| Son_Goku | mborzecki: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=glibc&version=7.5 | 05:20 |
| Son_Goku | feel free to CC me on the bug after you file it | 05:20 |
| Son_Goku | that works by email address, so use my regular gmail address (it's the one I commit in snapd as) | 05:21 |
| mborzecki | Son_Goku: on friday i ran into more issues, though with mounts this time, spent some time debugging it with zyga, 3.10x seems particularly picky about unmounting stuff | 05:21 |
| Son_Goku | yeah, there's a lot of weird things going on there | 05:21 |
| mborzecki | Son_Goku: sure, will do | 05:21 |
| Son_Goku | it'd be ironic if things worked better on the kernel-alt variant for ppc64le and s390x simply because that's kernel 4.14 | 05:21 |
| mborzecki | oh | 05:22 |
| Son_Goku | the two arches I can't test at all :P | 05:22 |
| Son_Goku | RHEL 7 uses 3.10 kernel for the arches it launched with | 05:22 |
| Son_Goku | but all the newer arches use a 4.14 kernel | 05:22 |
| mborzecki | that'd be fun | 05:24 |
| Son_Goku | yep | 05:24 |
| Son_Goku | aarch64, s390x, ppc64le use 4.14 kernel now | 05:24 |
| Son_Goku | x86_64 uses 3.10 kernel | 05:24 |
| Son_Goku | s390x and ppc64le give you the choice of kernels | 05:25 |
| mborzecki | Son_Goku: maybe i'll just open a PR with centos today to keep track of what's happening there | 05:25 |
| Son_Goku | PR with centos? | 05:25 |
| Son_Goku | how are you going to do that? | 05:25 |
| Son_Goku | centos doesn't patch or change the sources from RHEL | 05:25 |
| Son_Goku | if you have a patch to fix the issue, propose it and attach to the RHEL bug | 05:25 |
| mborzecki | Son_Goku: i mean i'd open a PR to snapd with centos added to spread suite | 05:25 |
| Son_Goku | ah | 05:25 |
| Son_Goku | that's probably not a good idea right now, given how broken it is | 05:26 |
| Son_Goku | but we do need spread images with centos+epel enabled | 05:26 |
| Son_Goku | afaik, those don't currently exist | 05:26 |
| mborzecki | Son_Goku: whcih packages from epel you're insterested in? | 05:28 |
| Son_Goku | squashfuse | 05:28 |
| Son_Goku | kyrofa maintains it in Fedora and EPEL | 05:29 |
| mborzecki | mhm | 05:29 |
| Son_Goku | also, golang is probably going to move to epel once it is dropped from RHEL | 05:30 |
| mborzecki | Son_Goku: they're dropping golang? | 05:30 |
| Son_Goku | RHEL is planning to replace the golang package with the go-toolset SCL, which provides golang SCLized | 05:31 |
| Son_Goku | https://developers.redhat.com/blog/2017/10/31/getting-started-go-toolset/ | 05:31 |
| mborzecki | ah, so software collections basically? | 05:31 |
| Son_Goku | yep | 05:31 |
| Son_Goku | scls will be updated each year with the latest version of those stacks from stable Fedora | 05:32 |
| Son_Goku | so that means golang 1.10 or 1.11 will show up | 05:32 |
| Son_Goku | and once golang is out of RHEL, it can be reintroduced in EPEL | 05:32 |
| Son_Goku | and kept up to date with Fedora, just as rust is | 05:33 |
| mborzecki | mhm, makes sense | 05:34 |
| mborzecki | amzn will then be affected too, unless they keep their go packages | 05:34 |
| Son_Goku | Amazon is likely basing their go stack on Fedora | 05:35 |
| mborzecki | (and update) | 05:35 |
| Son_Goku | I believe their Rust packages are also derived from ours | 05:35 |
| mborzecki | heh, mix & mash all the bits | 05:36 |
| mborzecki | i guess whatever works for them and their customers :) | 05:36 |
| Son_Goku | sure | 05:38 |
| Son_Goku | most large EL users wind up using large portions of Fedora for their purposes anyway | 05:38 |
| Son_Goku | EPEL is ridiculously popular :) | 05:38 |
| mborzecki | Son_Goku: zyga mentioned some stats that were shown during flock | 05:39 |
| Son_Goku | yeah | 05:40 |
| mborzecki | Son_Goku: did you get an email from rhbz? | 05:45 |
| mborzecki | Son_Goku: bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1634486 | 05:46 |
| Son_Goku | yep | 05:46 |
| Son_Goku | yep, got it | 05:46 |
| zyga | good morning | 06:33 |
| * zyga is grumpy but happy | 06:34 | |
| zyga | well | 06:34 |
| zyga | happy because the day is nice, it's very cold but sunny | 06:34 |
| zyga | grumpy because apple resellers suck | 06:34 |
| zyga | hey mborzecki | 06:36 |
| mborzecki | zyga: they didn't replace the mbp? | 06:41 |
| zyga | well, it's more than that | 06:41 |
| zyga | first of all, I don't have it yet | 06:41 |
| zyga | they don't respond to email | 06:41 |
| zyga | I guy in another ispot said that apple NACKed the DOA claim because it was more than 5 days after purchase | 06:41 |
| mborzecki | but the laptop was paid for already? | 06:41 |
| zyga | and the service NACK the nack and ... nothing | 06:41 |
| zyga | yes | 06:41 |
| zyga | so nobody wants to fix it | 06:42 |
| zyga | and nobody bothered to tell me | 06:42 |
| zyga | I'll go there today for a refund or a new unit | 06:42 |
| zyga | it's just %@!#!@ that I have to bother | 06:42 |
| mborzecki | and you didn't get it back? | 06:42 |
| zyga | no, it's still "in service" | 06:42 |
| zyga | because they don't know what to do with it | 06:42 |
| mborzecki | daamn | 06:42 |
| zyga | yeah | 06:42 |
| mborzecki | customer service | 06:42 |
| zyga | anyway, I'll know more later | 06:42 |
| zyga | real apple service is better | 06:42 |
| zyga | it's just reseller adding the complexity that suck | 06:43 |
| zyga | and real apple service told me to contact them if this fails | 06:43 |
| zyga | really, the only thing missing is proper apple store somewhere in .pl | 06:43 |
| zyga | because reseller quality varies | 06:43 |
| zyga | and is not that controlled | 06:43 |
| zyga | oh | 06:43 |
| zyga | and the "service" broke the LCD | 06:43 |
| zyga | so... | 06:43 |
| zyga | I'm very very grumpy | 06:43 |
| zyga | do they even train their staff? | 06:44 |
| zyga | (where service is reseller-service) | 06:44 |
| zyga | not apple | 06:44 |
| zyga | hmm | 06:47 |
| zyga | odd | 06:47 |
| zyga | I have a shellcheck failure | 06:47 |
| zyga | on _one_ system only (18.04) | 06:47 |
| zyga | as if shellcheck was updated there now | 06:47 |
| zyga | ah wait, that's not the case | 06:47 |
| zyga | it's just confusing output of shellcheker | 06:47 |
| zyga | mborzecki: the spellchecking script for yaml should really not spam about 1000s of things it doesn't consider as fatal errors | 06:48 |
| zyga | how am I supposed to find the one it complained about? | 06:48 |
| mborzecki | spread-shellcheck <file> | 06:48 |
| zyga | no, from the log | 06:49 |
| mborzecki | ther's a summary at the end | 06:49 |
| zyga | I know I can re-run the experiment and see | 06:49 |
| zyga | ERROR:root:validation failed for the following non-whitelisted files: | 06:49 |
| zyga | - tests/main/layout-symlink-bind-revert/task.yaml | 06:49 |
| mborzecki | yup, there you go | 06:49 |
| zyga | but the actual error is buried in that full log | 06:49 |
| zyga | well, I know that's the only file I added | 06:49 |
| mborzecki | well, that's because we have'nt landed everything yet | 06:49 |
| zyga | I'm arguing that it should not show the other output at all in this mode | 06:50 |
| zyga | it's just noise | 06:50 |
| mborzecki | what reminds me i should probably revisit that branch again now | 06:51 |
| zyga | yeah, perhaps we can just land it all quickly | 06:51 |
| pstolowski | mornings | 07:05 |
| zyga | hey pawel | 07:05 |
| === mborzeck1 is now known as mborzecki | ||
| zyga | hmmm | 07:18 |
| zyga | syscall.Unlinkat has different signature than what the kernel claims | 07:19 |
| zyga | there's no flags :/ | 07:19 |
| mup | PR snapd#5884 closed: overlord/snapshotstate: store the SnapID in snapshot, block restore if changed <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5884> | 07:31 |
| zyga | I sent a PR with a test in it, I'm working on fixing the issues but if anyone wants to read it and merge it please be my guest https://github.com/snapcore/snapd/pull/5883 | 07:44 |
| mup | PR #5883: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5883> | 07:44 |
| mvo | pedronis: good morning! it looks like 5878 is good to go except for the one "NoStore" test that jamie asked for(?) | 07:47 |
| mvo | pedronis: we can do that test in a followup if you prefer it this way btw (to avoid another spread-wait-for-green cycle) | 07:50 |
| zyga | I'd say I'm freezing but it's not quite sub-zero yet | 07:53 |
| zyga | but it's not warm anymore either | 07:53 |
| pedronis | mvo: he asked some other things if possible, I'll look a bit and decide whether to them there or follow up | 08:02 |
| mvo | pedronis: thanks | 08:02 |
| Chipaca | mo'in | 08:05 |
| pedronis | mvo: seems he was explicit about wanting the test before merging, otoh the other stuff is problaby later follow up material, it will touch preexisting tests | 08:06 |
| mvo | pedronis: ok | 08:06 |
| pedronis | (more comments, remove vestigial code, maybe rename CheckInterfaces) | 08:07 |
| pedronis | mvo: pushed, thanks for the review btw | 08:14 |
| mup | PR snapd#5892 opened: tests: shellchecks part 9 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5892> | 08:31 |
| mvo | mborzecki: nice, thanks for more shellcheck fixes | 08:47 |
| niemeyer | Morning all | 08:51 |
| * zyga fires spread and goes to warm up with tea | 08:55 | |
| zyga | hey everyone new :) | 08:55 |
| mvo | hey niemeyer , good morning | 08:56 |
| mup | PR snapd#5878 closed: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5878> | 09:01 |
| mborzecki | how do you remove apparmor profile withouth a file? | 09:02 |
| zyga | ? | 09:02 |
| zyga | ah | 09:03 |
| zyga | heh | 09:03 |
| zyga | I understand your question | 09:03 |
| zyga | you cannot | 09:03 |
| pedronis | niemeyer: hi | 09:03 |
| zyga | because a profile "file" is just a definition of arbitrarily named actual profiles | 09:03 |
| zyga | you can remove those if you know their name | 09:03 |
| zyga | but the "customary" way of doing that is to parse the profile again and remove the actual profiles from the kernel based on the parsed data | 09:03 |
| pedronis | mborzecki: I went grepping around, it seems indeed we have cover the SnapID usages that were problematic already, and aliases code seems to use local snap names already, so it looks like it should work but test would be useful | 09:04 |
| zyga | to remove an actual profile you just write its name to a special file in sysfs | 09:04 |
| mborzecki | pedronis: thanks, i'll write a test for aliases nontheless | 09:04 |
| pedronis | mborzecki: yea, we need a test about installing a 2nd version of a snap with auto-aliases and what happens with install, install --unaliases, and then prefer | 09:05 |
| mborzecki | pedronis: agreed | 09:05 |
| zyga | mborzecki: what prompted this? | 09:05 |
| mborzecki | zyga: apparmor package landed in community, so i rebooted with appamor enabled and some profiles were loaded, but aa-status output could not account for all of them, so i went fishing, and for instane when i removed a snap i saw a profile getting loaded, but once remove was done the profile was still there (?) | 09:07 |
| zyga | oh? | 09:07 |
| zyga | maybe we have a bug | 09:07 |
| mborzecki | zyga: idk, still looking, that's why i wanted to remove all the snap.* profiles that are there but should not be :) | 09:08 |
| === chihchun is now known as chihchun_afk | ||
| zyga | mborzecki: go to sysfs | 09:08 |
| zyga | then to apparmor part of that | 09:08 |
| zyga | there's a bunch of dot files there | 09:08 |
| zyga | you can enumerate profiles | 09:08 |
| zyga | and remove them as I explained | 09:08 |
| mborzecki | mhm, trying | 09:09 |
| zyga | mborzecki: perhaps we remove the file before removing the profiles from the kernel? | 09:12 |
| zyga | mborzecki: on top of that we must see the old text in them | 09:12 |
| zyga | mborzecki: before they are changed | 09:12 |
| zyga | mborzecki: youck | 09:12 |
| zyga | mborzecki: if this is the case we need to change some things to make that possible | 09:14 |
| zyga | mborzecki: I'll wrap this up and we can talk | 09:15 |
| mvo | niemeyer: when you have a moment (not urgent) could you please add "github.com/snapcore/pi-gadget" to the things that mup watches? | 09:17 |
| === chihchun_afk is now known as chihchun | ||
| niemeyer | mvo: Of course, will do | 09:18 |
| mvo | ta | 09:20 |
| pedronis | niemeyer: it would be good if could review #5882 (it has a +1 from jamie already) | 09:21 |
| mup | PR #5882: many: support and consider store friendly-stores when checking device scope constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5882> | 09:21 |
| niemeyer | pedronis: Sweet, thank you | 09:21 |
| pstolowski | if anyone has external usb camera - https://forum.snapcraft.io/t/have-a-pluggable-usb-camera-help-me-collect-some-data/7654 | 09:37 |
| zyga | yay, the leftover placeholders are gone now | 09:37 |
| zyga | now just to patch the affected unit tests | 09:37 |
| zyga | pstolowski: actually, any internal camera should be fine | 09:38 |
| zyga | they are usually attached via usb, no? | 09:38 |
| zyga | pstolowski: as such they go though the entire hot plug event system | 09:39 |
| pstolowski | zyga: how can i see remove event for it? in any case, i'd like samples anyway, i'd like to see vendor/products/serials and other attrs | 09:41 |
| zyga | pstolowski: unplug it | 09:41 |
| pstolowski | zyga: ah, indeed, udevadm trigger -c remove /dev/video0, nice, thank you | 09:44 |
| pstolowski | zyga: anyway... i'm interested in more smaples.. i see an anomaly with lime sdr, wonder if it happens to other devices | 09:45 |
| * zyga nods | 09:45 | |
| pstolowski | devices i tried so far report a wealth of attributes when removed - including serial numbers - basically mirroring what i get when i plug them. but lime sdr for some reason only reports a subset when removed, in particular serial number is not reported even though it is present on 'add' | 09:48 |
| zyga | pstolowski: interesting | 09:49 |
| zyga | perhaps proprietary udev thing like Nvidia? | 09:49 |
| pstolowski | yep.. | 09:49 |
| pstolowski | zyga: don't know about nvidia, can you tell me more? | 09:50 |
| zyga | pstolowski: yeah, it's not registered in udev | 09:50 |
| zyga | pstolowski: because GPL symbols and what not, I don't recall the details | 09:50 |
| zyga | pstolowski: but presumably because it doesn't register in sysfs | 09:51 |
| pstolowski | zyga: ack. it's weird, on remove i'm getting vendor and product names from udev db, just not serial... as long as device is plugged udevadm info reports all the nice data, i really don't get the logic behind this | 09:58 |
| zyga | pstolowski: look at /run | 09:58 |
| zyga | see if the serial is written there | 09:58 |
| zyga | remove can only report what is there | 09:58 |
| zyga | and what the kernel says | 09:58 |
| pstolowski | https://www.irccloud.com/pastebin/WeQxnDRO/ | 09:59 |
| pstolowski | appears to be there | 09:59 |
| pstolowski | zyga: ^ | 09:59 |
| zyga | hmmm :D | 10:00 |
| zyga | then yeah, now I'd jump at udev | 10:00 |
| zyga | as in, read the source | 10:00 |
| pstolowski | :) | 10:00 |
| mup | PR snapd#5893 opened: interfaces/apparmor: report apparmor support level and policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5893> | 10:13 |
| mborzecki | zyga: ^^ | 10:13 |
| zyga | reading | 10:14 |
| niemeyer | pstolowski: Reviewed #5759.. the key is a bit too simplistic atm.. we'll need to get something slightly better there | 10:21 |
| mup | PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759> | 10:21 |
| zyga | brb | 10:24 |
| pstolowski | niemeyer: thanks. yes, the second part of your comment (versioning) crossed my mind at some point | 10:25 |
| niemeyer | pstolowski: Yeah, this is a real issue.. without something along those lines we cannot ever improve on the keying logic | 10:26 |
| pstolowski | niemeyer: yep, that's valid concern indeed. | 10:26 |
| niemeyer | pstolowski: #5782 reviewed too, with two suggestions | 10:38 |
| mup | PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782> | 10:38 |
| zyga | re | 10:39 |
| mborzecki | zyga: https://paste.ubuntu.com/p/D6Fz5Fw3pb/ yeah, so the files are removed early, then apparmor_parser --remove has nothing to remove, but does not error out (?) | 10:39 |
| zyga | uh | 10:40 |
| zyga | I think it'd be nice if we remembered (in the state perhaps?) what was set up | 10:40 |
| zyga | the name of the actual profiles | 10:40 |
| pstolowski | niemeyer: by the way, a (random) remark about these keys: they are not "global" across interfaces, they are grouped by interface type at higher level of hotplug logic, so they need to be unique only within given interface; so, say key "1234" of "serial-port" interface might be different than "1234" of "camera" interface. this doesn't change any aspect of what you commented on, just mentioning becuase it's not apparent from | 10:40 |
| pstolowski | that PR | 10:40 |
| zyga | in either case we must have visibility into profile names | 10:41 |
| niemeyer | pstolowski: That's awkward | 10:41 |
| pstolowski | niemeyer: i can explain | 10:41 |
| niemeyer | pstolowski: At least it's the initial gut feeling | 10:41 |
| pstolowski | niemeyer: that goes back to what we discussed about the ability for any interface to provide own HotplugDeviceKey method | 10:41 |
| zyga | mborzecki: we can ask apparmor_parser for the names stored in a file | 10:42 |
| niemeyer | pstolowski: I can understand the key generation being unique, but seems suspect to have the storage of those keys being done at the interface level | 10:42 |
| zyga | mborzecki: apparmor_parser --names <fname> | 10:42 |
| zyga | mborzecki: the question is how to sequence that into the current framework | 10:42 |
| niemeyer | pstolowski: Or do you mean the keys are still centrally managed, but that the central map includes the type as part of the key? | 10:43 |
| niemeyer | pstolowski: That would be nice | 10:43 |
| mborzecki | zyga: heh, i'm looking what we have avaialbe in the handlers, and it's only snapsup :/ | 10:43 |
| zyga | mborzecki: can you expand on that idea, what were you hoping to find? | 10:44 |
| mborzecki | zyga: checking if there's snap.Info avaialble anywhere near there | 10:44 |
| zyga | mborzecki: and then? | 10:44 |
| pstolowski | niemeyer: no, storage is not done at interface level. hotplug machinery uses either the device key computed by the method from my PR, or - if interface has own method - it takes interface-calculated key string instead. and yes, that's centrally managed, basically interface type name becomes part of the internal map as well. | 10:44 |
| niemeyer | pstolowski: I still don't quite understand the picture.. it says storage is done at interface level, but then it says that it's centrally managed | 10:45 |
| niemeyer | pstolowski: What is done at the interface level, and how is it centrally managed then? | 10:46 |
| mborzecki | zyga: then you have apps, so you know the file names, security tags etc. but that's not really helping this particular case | 10:47 |
| mborzecki | zyga: how does it work on ubuntu when profile files are removed? | 10:47 |
| zyga | one sec | 10:49 |
| niemeyer | pstolowski: I do understand that the key is created by the interface, per our agreements.. that's sensible | 10:49 |
| zyga | mborzecki: you mean as in regular packages? | 10:49 |
| pstolowski | niemeyer: interface can implement HotplugDeviceKey method which returns a string representing a key, made of attributes od the device event, that's all. the returned key string is then used by hotplug machinery in internal maps, but interface type name is used together with the key | 10:49 |
| zyga | mborzecki: that's a good question, I _think_ it's handled by apparmor debhelper things | 10:50 |
| zyga | mborzecki: and because those files are shipped in /etc they are confffiles | 10:50 |
| zyga | mborzecki: so probably not removed until you purge | 10:50 |
| zyga | mborzecki: so perhaps that's how it works | 10:50 |
| zyga | or just nobody noticed if the profiles stay in the kernel after removal | 10:50 |
| niemeyer | pstolowski: Aha, okay.. sorry for not getting it. That's great. | 10:50 |
| mborzecki | zyga: and how about snaps? the code clearlyl removes profile files before attemptint to call apparmor_parser --remove | 10:50 |
| zyga | mborzecki: well, it clearly does not work | 10:51 |
| mborzecki | :P | 10:51 |
| zyga | it's just that the fact that the profile are in the kernel is not immediately obvious or problematic | 10:51 |
| zyga | so nothing was reporting any issues | 10:51 |
| pstolowski | niemeyer: thinking about your comment re devicekey, i wonder if it shouldn't become a proper object, rather than a loose string | 10:52 |
| niemeyer | pstolowski: If we use a digest, we might just prepend a "0" to the output so we know that's version zero.. this allows us to evolve the logic of keying later so we take into account current keys | 10:52 |
| mborzecki | ll | 10:52 |
| niemeyer | pstolowski: I'd try to keep it simple while we can | 10:53 |
| pstolowski | niemeyer: okay | 10:53 |
| pstolowski | niemeyer: btw, lime sdr has an annoying quirk that i discussed earlier this morning ^ | 10:53 |
| pstolowski | niemeyer: well, it can be udev quirk | 10:54 |
| mup | PR snapd#5877 closed: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5877> | 10:58 |
| mvo | reviews for https://github.com/snapcore/pi-gadget/pulls would be great, should be pretty trivial | 11:05 |
| zyga | mvo: done | 11:07 |
| mvo | zyga: \o/ | 11:07 |
| * zyga runs some more spread tests before proposing another fix | 11:16 | |
| diddledan | netplan is passé? https://www.phoronix.com/scan.php?page=news_item&px=nettools-new-linux-network | 11:17 |
| zyga | diddledan: https://github.com/c-util/c-list/blob/dda36d30c7d655b4d61358519168fa7ce0e9dae9/src/c-list.h | 11:19 |
| zyga | I feel happy now | 11:19 |
| zyga | it's not just me ;-) | 11:19 |
| zyga | (it's referenced from n-dhcp-...) | 11:19 |
| * zyga returns to spread | 11:20 | |
| mup | PR snapd#5889 closed: make run-checks --static pass again w/shellcheck installed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5889> | 11:27 |
| Chipaca | mvo: if you want to see the stages in operation, https://travis-ci.org/snapcore/snapd/builds/435555961 is on | 11:28 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | Chipaca: nice | 11:41 |
| sergiusens | cwayne: anyone who can cover for that thing that broke on plainbox? | 11:41 |
| Chipaca | mborzecki: my comment to mvo, or my comment to you about journalctl -o json? | 11:41 |
| Chipaca | mborzecki: either way, thanks :-) | 11:41 |
| mborzecki | Chipaca: hah, the stages | 11:41 |
| Chipaca | mborzecki: stealing ideas (and tests!) from snapcraft | 11:42 |
| mborzecki | mhm | 11:42 |
| Chipaca | mborzecki: just don't tell sergiusens or his head'll grow | 11:42 |
| Chipaca | (let's call it "cross-pollination", as snapcraft is also picking up some ideas from our test suite) | 11:43 |
| sergiusens | Chipaca: hah. | 11:44 |
| diddledan | Sergio, Sergio, he's our man, if he can't be bothered, Kyle can :-p | 11:46 |
| diddledan | msdos 2.0 is on github: https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-MS-DOS-GitHub | 11:47 |
| diddledan | PRs welcome? | 11:47 |
| Chipaca | diddledan: licensing is unclear tho | 11:47 |
| diddledan | yeah | 11:47 |
| Chipaca | also we already have a dosbox part, right? | 11:48 |
| Chipaca | right? | 11:48 |
| diddledan | according to the repo LICENSE.md file it's MIT now... | 11:48 |
| diddledan | ref: https://github.com/Microsoft/MS-DOS/blob/master/LICENSE.md | 11:48 |
| Chipaca | diddledan: https://github.com/Microsoft/MS-DOS/issues/2 | 11:48 |
| mborzecki | pedronis: quick question, i've installed test-snapd-auto-aliases_foo, now when doing snap install --unaliased test-snapd-auto-aliases_1.snap it fails complaining it cannot enable automatic aliases for test-snapd-auto-aliases because those are already enabled for _foo, but i passed --unaliased, so i'd expect it to install the snap nonetheless | 11:49 |
| diddledan | oic | 11:49 |
| pedronis | mborzecki: ok, sounds like there is something to fix then | 11:55 |
| mborzecki | pedronis: after a quick look, checking for conflicts with enabled aliases does not look at the --unaliased of the snap being installed, but checks AutoAliasDisabled of snaps that are already present | 11:57 |
| pedronis | mborzecki: that sounds strange | 11:58 |
| pedronis | can't be the full picture | 11:58 |
| mborzecki | pedronis: yeah, i'm more than likely to miss something, anyways, need to dig into the code | 11:59 |
| Nafallo | hiya! :-) | 12:00 |
| === pstolowski is now known as pstolowski|lunch | ||
| mup | PR snapd#5782 closed: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5782> | 12:02 |
| Nafallo | I noticed a bunch of three loop mounts in nautilus this morning, which turned out to be lxd snaps. a bit more investigation and it turned out to be loop mounts where the backend file had been removed. looks like the loops didn't get teared down during the refresh or something? | 12:02 |
| Nafallo | I had to reboot just now, which obviously removed the issue :-/ | 12:03 |
| Nafallo | there might be something in logs though, if anyone feel up for a debugging session... | 12:04 |
| pedronis | mborzecki: afaict unaliased set snapst.AutoAliasDisabled of the being installed snap to false and then checks the conflicts | 12:06 |
| pedronis | considering that value | 12:06 |
| popey | pstolowski|lunch: how many reports about webcams are you after? We can post on the snapcraft socials, drawing people into that post | 12:07 |
| popey | pstolowski|lunch: given it's a really easy way for people to contribute, might be nice to promote? | 12:07 |
| pstolowski|lunch | popey: just a few is really all i need for now, but thanks for asking! | 12:08 |
| popey | no worries | 12:08 |
| ogra | Nafallo, they go away after a reboot, i told stgraber about it a while ago | 12:09 |
| ogra | (i think i had three lxd updates since my last reboot ... they pile up in the launcher :) ) | 12:10 |
| mborzecki | off to pick up the kids | 12:10 |
| Nafallo | ogra: so a known one. excellent :-) | 12:11 |
| ogra | well, i didnt file a bug iirc | 12:12 |
| Nafallo | ogra: gogogog ;-) | 12:13 |
| diddledan | audacity 2.3.0 just went to the stable channel | 12:14 |
| popey | woooo | 12:17 |
| popey | diddledan: shame the version string is a bit verbose | 12:18 |
| diddledan | yeah, that's because I didn't trim the git tag - I wanted to use a portable script that any repo can use | 12:19 |
| diddledan | note the `$SNAPCRAFT_PROJECT_NAME` to allow it to work on any project https://www.irccloud.com/pastebin/nvi3aI7B/ | 12:20 |
| diddledan | I don't like the comment wording though. it confuses me. I stole the script from wormhole | 12:21 |
| popey | hm, just looks a bit nasty having the version number in the snap info | 12:22 |
| popey | (the name in the version number obv) | 12:22 |
| diddledan | surely we want the version number :-p it's the name we don't want :-p | 12:23 |
| diddledan | yeah that ↑ | 12:23 |
| ogra | hmm, i have some very weird behavious of a configure hook | 12:42 |
| ogra | #! /bin/sh | 12:42 |
| ogra | set -e | 12:42 |
| ogra | IP="$(snapctl get serverip)" | 12:42 |
| ogra | [ -n "$IP" ] && echo "setting Server IP to $IP" | 12:42 |
| ogra | thats all thats in there ... | 12:42 |
| ogra | it automatically rolls back my snap when i try to install it | 12:43 |
| ogra | is snapctl automatically exiting 1 when there is no value set ? | 12:43 |
| ogra | (so that the set -e kills the hook ) | 12:43 |
| diddledan | ogra: does snapctl require the snap name? | 12:44 |
| ogra | shouoldnt when used inside a hook | 12:44 |
| diddledan | ok | 12:45 |
| ogra | fun fact .... it uploads an oops to errors.ubuntu.com with completely useless content | 12:45 |
| ijohnson | ogra: I've had it where the snapctl symlink isn't set up and so my configure script killed the install because it couldn't find snapctl | 12:45 |
| diddledan | that'll annoy someone trying to triage :-D | 12:45 |
| Chipaca | ogra: I love that you're using these things in ways we haven't tested | 12:45 |
| ijohnson | ogra: Did you by chance disable re-exec? | 12:45 |
| Chipaca | ogra: I hate that your testing is not producing bugs we can action | 12:46 |
| ogra | ijohnson, i'm running in a core vm | 12:46 |
| ijohnson | ogra: okay nvm not the same issue I ran into then | 12:46 |
| ogra | Chipaca, https://errors.ubuntu.com/oops/b35c50a6-c576-11e8-92cf-fa163ee63de6 | 12:46 |
| ogra | run-hook: Error | 12:46 |
| ogra | ERROR run hook "configure": exit status 1 | 12:46 |
| ogra | not sure what i should report as bug here ... | 12:46 |
| mvo | ogra: did you had a reply? I did not read all backlog but for me:[ -n "$IP" ] && echo "setting Server IP to $IP" ; echo $? | 12:47 |
| mvo | 1 | 12:47 |
| mvo | 12:47 | |
| * ogra removes set -e from the script | 12:47 | |
| mvo | ogra: i.e. if $IP is empty the script will fail | 12:47 |
| mvo | ogra: instead of removing set -e just put it inside an if condition | 12:47 |
| ogra | oh | 12:47 |
| mvo | ogra: if [ -n "$IP]; then echo... | 12:47 |
| ogra | well | 12:47 |
| ogra | or changing && to || | 12:48 |
| diddledan | good catch mvo | 12:48 |
| ogra | yeah, thanks ! | 12:48 |
| diddledan | if the test fails then the return code will be 1 so the whole script will die | 12:48 |
| mvo | ogra: your choice, I personally find the "if .." easier to read but then I don't do much shell (if I can help it ;) | 12:48 |
| ogra | sad is that the oops is really useless in this case | 12:48 |
| mvo | diddledan: thank you | 12:48 |
| mvo | ogra: yeah | 12:48 |
| diddledan | you can either replace with an `if [ -n` or do `[ -n .. ] && foo || bar` | 12:49 |
| ogra | right | 12:50 |
| diddledan | oh, or `[ -z .. ] || foo` | 12:50 |
| ogra | actually i dont even need that line at all | 12:50 |
| ogra | was just for debugging | 12:50 |
| diddledan | haha | 12:50 |
| diddledan | debugging breaks the script | 12:51 |
| ogra | (in fact i wouldnt even need a hook if i could just call snap set without one ... ) | 12:51 |
| diddledan | I like those | 12:51 |
| ogra | but snap set checks first if a configure hook exist | 12:51 |
| diddledan | it does? | 12:51 |
| ogra | i dont realyl use the hook but use the value in a startup script ... | 12:51 |
| ogra | so the hook in itself is totally pointless cruft here | 12:51 |
| diddledan | I thought it would just add the config and then exit if there's no configure hook | 12:52 |
| ogra | (startup wrappers can directly call snapctl get ... so if you dont write a config file but read it directly a hook is moot) | 12:52 |
| diddledan | that was my theory, too | 12:52 |
| ogra | ogra@localhost:~$ snap set dashkiosk-browser serverip=192.168.2.70 | 12:53 |
| ogra | error: cannot perform the following tasks: | 12:53 |
| ogra | - Run configure hook of "dashkiosk-browser" snap (snap "dashkiosk-browser" has no "configure" hook) | 12:53 |
| ogra | so you need an empty hook script and it works | 12:53 |
| diddledan | well fooey | 12:53 |
| diddledan | I call shenanigans! | 12:53 |
| Chipaca | diddledan: touch configure; chmod +x configure | 12:53 |
| ogra | ogra@localhost:~$ cat chromium.launcher | 12:53 |
| ogra | #! /bin/sh | 12:53 |
| ogra | # get the IP from setting | 12:53 |
| ogra | IP="$(snapctl get serverip)" | 12:53 |
| ogra | ... | 12:53 |
| Chipaca | literally an empty configure script | 12:53 |
| Chipaca | (I don't think we support that inside a strictly confined snap, sadly -- the empty executable being true is cool) | 12:54 |
| === pstolowski|lunch is now known as pstolowski | ||
| mup | PR snapd#5892 closed: tests: shellchecks part 9 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5892> | 13:01 |
| mup | PR snapd#5894 opened: many: enable AppArmor on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5894> | 13:04 |
| mborzecki | pedronis: fun fact, we're not even sending --unaliased when installing from file | 14:03 |
| Chipaca | mvo: a silly question for you sir | 14:03 |
| pedronis | mborzecki: I'm not surprised, is a bit of a corner case, and we didn't think about it | 14:04 |
| Chipaca | mvo: in https://travis-ci.org/snapcore/snapd/jobs/435622042 if you expand the "build-dep" install step, there's a lot of progress noise despite me saying --quiet | 14:04 |
| pedronis | mborzecki: I would be more suprised if it was done half-way | 14:04 |
| mborzecki | pedronis: i'll at it along with some tests, need this workaround for spread tests | 14:04 |
| Chipaca | mvo: how do I tell it --no-really-i-dont-want-progress-bars? | 14:05 |
| mvo | Chipaca: I believe so but let me look, its been a while since I did that feature | 14:06 |
| Chipaca | mvo: :-D | 14:06 |
| mvo | Chipaca: try "apt install -o Dpkg::Progress-Fancy=false ...." (or apt-get will also turn this off) | 14:11 |
| Chipaca | mvo: ta | 14:21 |
| cachio | zyga, hey, https://forum.snapcraft.io/t/error-removing-snaps-after-refresh-core-snap/7632 | 14:22 |
| cachio | zyga, could be related to namespaces? | 14:23 |
| zyga | on the phone | 14:25 |
| Chipaca | cachio: that test that's failing on core, how do you know the thing has rebooted? | 14:25 |
| cachio | we call revert | 14:26 |
| cachio | then it waits until ssh is not available | 14:26 |
| cachio | and then tries to connect | 14:26 |
| cachio | Chipaca, the core is reverted | 14:26 |
| cachio | Chipaca, but I am not explicity chacking the reboot was done | 14:27 |
| cachio | I could add an extra ckeck | 14:27 |
| Chipaca | cachio: maybe I'm misunderstanding something, let me dig a bit more first | 14:28 |
| zyga | cachio: what were you expecting to see? | 14:30 |
| zyga | (still on the phone) | 14:32 |
| Chipaca | hmm | 14:33 |
| Chipaca | The contributor stolowski@gmail.com has not signed the CLA. | 14:33 |
| Chipaca | hmm | 14:34 |
| zyga | blasphemy ;-) | 14:34 |
| Chipaca | I'll change the checker to also check the canonical group | 14:34 |
| Chipaca | right now it just checks for canonical email | 14:34 |
| cachio | zyga, well, it should not fail to remove the snap | 14:35 |
| pedronis | mvo: sorry for the slight FUD in the standup, I'm also worried that of the current processes (that we want to replace) assume that seed is writable | 14:35 |
| mvo | pedronis: no worries, it was good feedback. I will write down what we would have to do but I think gustavo is right, we can always add it later | 14:38 |
| zyga | - Stop snap “lxd” services ([start snap.lxd.daemon.service] failed with exit status 5: Failed to start snap.lxd.daemon.service: Unit snap.lxd.daemon.service not found. | 14:47 |
| zyga | cachio: ^ this is unexpected, is it stopping or starting, the error message is inconclusive | 14:48 |
| cachio | zyga, well, it should be stopping because it fails when we do "snap remove lxd" | 14:49 |
| cachio | zyga, but in the errror tries to start it | 14:50 |
| cachio | zyga, it is also happening with other snaps, not just lxd | 14:51 |
| mup | PR snapd#5895 opened: client, daemon: support passing of 'unaliased' option when installing from local files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5895> | 14:52 |
| mborzecki | pedronis: the client/daemon part ^^ | 14:52 |
| niemeyer | mvo: Had a conversation with Bret | 15:05 |
| mvo | niemeyer: nice, what is the outcome? | 15:05 |
| niemeyer | mvo: We may end up going with something in between.. splitting up the kernels based on visibility and using tracks within those | 15:06 |
| niemeyer | mvo: It's a reasonable compromise.. it doesn't offer full reusability, but means no further implementation time either | 15:06 |
| mvo | niemeyer: ok - so what does it mean for the kernels I care about right now? pi-kernel, pc-kernel and dragonboard-kernel? how will those be handled? | 15:06 |
| niemeyer | mvo: It'll be unfortunately only in those cases where we might actually reuse a kernel for a different customer | 15:06 |
| niemeyer | mvo: Think core18 kernel on Brand X devices | 15:07 |
| mvo | ok | 15:08 |
| niemeyer | mvo: We may end up with a "pi-kernel", with tracks named as before inside it | 15:08 |
| mvo | niemeyer: that works for me, thanks for the followup on this one | 15:08 |
| mup | PR snapd#5893 closed: interfaces/apparmor: report apparmor support level and policy <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5893> | 15:08 |
| pedronis | mborzecki: ack | 15:08 |
| mvo | niemeyer: is there further discussion needed or can I go ahead with asking for tracks for the "pi-kernel" ? | 15:09 |
| niemeyer | mvo: Same for the others | 15:09 |
| niemeyer | mvo: noise][1 was going to give some further thought and post comments in the thread, so perhaps best to wait a bit to see whether others will comment furthr | 15:09 |
| niemeyer | further | 15:09 |
| mvo | niemeyer: ok, so pc-kernel with 18-{i386,amd64} and dragonboard-kernel with just 18 (there are no variants for this one (yet))? | 15:09 |
| mvo | niemeyer: ok, I will wait then :) thanks again for chasing this! | 15:10 |
| niemeyer | mvo: There's an interesting question on that one | 15:10 |
| niemeyer | mvo: Do we need the i386/amd64? | 15:10 |
| niemeyer | mvo: Note that we already split up arch internally | 15:10 |
| mvo | niemeyer: indeed | 15:10 |
| mvo | niemeyer: yeah, for those we don't actually need it | 15:10 |
| niemeyer | mvo: It's curious that we cannot do the same on the pi | 15:10 |
| mvo | niemeyer: I guess its all the same arch for the pi so that (neat) trick does not work. or am I misunderstanding what you have in mind? | 15:11 |
| mvo | zyga: one more trivial review for snapcore/pi-gadget if you want | 15:11 |
| zyga | mvo: sure | 15:11 |
| * zyga just returned with fresh coffee | 15:11 | |
| roadmr | ogra: tools r1129 are now in the store | 15:12 |
| * ogra hugs roadmr | 15:13 | |
| mup | PR snapcraft#2306 opened: setup: remove broken setup dirs done on import <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2306> | 15:13 |
| niemeyer | mvo: No, that's it indeed | 15:23 |
| niemeyer | mvo: It's just curious because i386 and amd64 have a similar relationship | 15:24 |
| mvo | niemeyer: indeed | 15:28 |
| mup | PR snapcraft#2306 closed: setup: remove broken setup dirs done on import <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2306> | 15:34 |
| mup | PR snapcraft#2307 opened: setup: improve dir setup for when running in legacy mode <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2307> | 15:37 |
| mup | PR snapd#5876 closed: selftest: rename selftest.Run() to sanity.Check() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5876> | 15:38 |
| pstolowski | niemeyer, zyga got hotplug removal sorted out per you suggestion regarding sysfs paths, work great \o/. and startup enumeration and its delta is based around device keys, no challenge there. my mistake for trying to implement 'remove' in a way that required computation of device key. | 15:42 |
| ogra | jdstrand, hmm, so browser-support disallows daemon ? ... how do i get around that for a browser based kiosk client app ? | 15:42 |
| zyga | pstolowski: glad to hear that :) | 15:42 |
| diddledan | ogra: jdstrand: if browser-support kills daemon then these instructions need to be revised: https://tutorials.ubuntu.com/tutorial/electron-kiosk#2 | 15:43 |
| ogra | diddledan, well, prehaps i'm missing something ... thats what build.s.io gave me in return after building my dashkiosk-client-browser snap | 15:44 |
| jdstrand | diddledan: I don't see 'daemon: ???' in there | 15:44 |
| ogra | yeahm there is no daemon | 15:45 |
| jdstrand | ogra: there is a way to override that in the store | 15:45 |
| diddledan | jdstrand: next page has it | 15:45 |
| niemeyer | pstolowski: No worries, and thanks zyga for the progress | 15:45 |
| niemeyer | pstolowski: What was the trick? | 15:45 |
| diddledan | I lunked (past tense of linked) the wrong page | 15:45 |
| ogra | jdstrand, would be lovely, what do i need to do ? send boxes of beer your way ? | 15:45 |
| diddledan | https://tutorials.ubuntu.com/tutorial/electron-kiosk#3 | 15:45 |
| jdstrand | ogra, diddledan: we should continue to override until we have privilege dropping. browser-support as root allows a few scary things | 15:45 |
| ogra | yeah | 15:46 |
| jdstrand | ogra: what snap? | 15:46 |
| ogra | jdstrand, dashkisk-client-browser | 15:46 |
| ogra | *dashkiosk | 15:46 |
| ogra | it is essentially chromium with a wrapper and doesnt have any desktop'y plugs in use ... (though it uses wayland for mir-kiosk) | 15:47 |
| pstolowski | niemeyer: well, just maintain an in-memory lookup based on sysfs paths, for the purpose of handling hotplug removal - rather than trying to compute device key from attributes of 'remove' udev event (which turned out to be incomplete sometimes, for lime sdr at least) | 15:48 |
| niemeyer | pstolowski: So a sys path => device key? | 15:49 |
| diddledan | in fact that electron-kiosk tutorial is confusing - it has a comment in the yaml that you can't have "identical plug/slot name in same yaml" so the author created a plug called `x11-plug` with interface `x11`, but I don't see any other usage of `x11` in that yaml at all | 15:49 |
| ogra | diddledan, it uses a loopback to itself | 15:50 |
| Chipaca | niemeyer: mvo: https://travis-ci.org/snapcore/snapd/builds/435647396 <- finishing spread after 30 minutes of previous tests, no timeouts | 15:50 |
| diddledan | if all the plug definition is doing is stating that it is interface `x11` with no further config (which is what the yaml says) then surely just `plugs: [x11]` will do the same thing | 15:50 |
| pstolowski | niemeyer: more-less yes, it's sysfs path => interface name => device key(s) | 15:50 |
| diddledan | ogra: there's no definition of any slots anywhere in that yaml | 15:51 |
| niemeyer | pstolowski: Hmmm.. that doesn't make much sense I guess | 15:51 |
| diddledan | oh wait | 15:51 |
| ogra | diddledan, the thing is that XWayland is shipped and run by the same snap ... | 15:51 |
| diddledan | now I see it | 15:51 |
| diddledan | hidden in the apps: stanza | 15:51 |
| ogra | to connect to XWayland you need the x11 interface | 15:51 |
| niemeyer | pstolowski: The sysfs path can't map to the interface name alone as we wouldn't know which device it is still | 15:51 |
| ogra | so the snap provides the plug to itself in a loopback | 15:51 |
| pstolowski | niemeyer: sorry, i mistyped, i mean sysfs path maps to (interface name, device key) - possibly more than one if multiple interfaces created slots for a single device | 15:56 |
| niemeyer | pstolowski: Aha, gotcha, that makes sense | 15:57 |
| vidal72[m] | how core18 is going? :) | 15:59 |
| zyga | vidal72[m] I think it's going good | 15:59 |
| vidal72[m] | :)) | 16:00 |
| mvo | Chipaca: nice! | 16:05 |
| niemeyer | Chipaca: Nice indeed, what's the full time now? | 16:09 |
| Chipaca | niemeyer: without the extra "wait 30 minutes just to see if the whole thing times out"? | 16:09 |
| Chipaca | niemeyer: about 11 minutes from unit tests & etc, and 34 minutes from spread | 16:10 |
| niemeyer | Cool | 16:10 |
| niemeyer | I guess it's a good deal still | 16:10 |
| Chipaca | we gained about 1 minute by moving static into unit | 16:11 |
| Chipaca | we can probably shave 5 minutes off the unit test by skipping (or fixing! ha ha crazy talk) the slow ones | 16:11 |
| niemeyer | :) | 16:14 |
| Chipaca | ok, time for a break, bbl | 16:20 |
| === pstolowski is now known as pstolowski|afk | ||
| * zyga break while my daughter needs my desk to build something | 16:47 | |
| mup | PR snapcraft#2307 closed: setup: improve dir setup for when running in legacy mode <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2307> | 18:41 |
| mup | PR snapcraft#2308 opened: plugins: remove the copy plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2308> | 18:44 |
| mup | PR snapcraft#2309 opened: snap: improve early base detection logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2309> | 20:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!