| mup | PR snapcraft#2360 closed: plainbox-provider plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2360> | 00:20 |
|---|---|---|
| mup | PR snapd#5957 closed: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots πΈσ > <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5957> | 00:49 |
| mwhudson | what's the story with libseccomp and trusty and arm64 and ppc64el? | 02:11 |
| mwhudson | snapd is stuck in trusty-proposed because of this | 02:11 |
| mwhudson | oh wait no that's not why | 02:12 |
| mborzecki | morning | 05:06 |
| zyga | Hey | 05:34 |
| zyga | Did | 05:34 |
| zyga | Haha | 05:34 |
| zyga | My phone just fell and wrote this | 05:34 |
| mborzecki | zyga: hey | 05:37 |
| mborzecki | must be ai | 05:37 |
| zyga | Hey mvo | 06:17 |
| mborzecki | mvo: hey | 06:17 |
| mvo | hey zyga and mborzecki | 06:17 |
| mvo | how is life today? | 06:18 |
| mborzecki | mvo: all red | 06:18 |
| mvo | urgh | 06:18 |
| mvo | do we know why? | 06:19 |
| * mvo looks | 06:20 | |
| zyga | It is all red because summer is over | 06:21 |
| mborzecki | mvo: random stuff afaict, there was some store hiccup yday too, maybe somewhat related | 06:21 |
| zyga | Well, that is one theory | 06:21 |
| zyga | Store was broken | 06:21 |
| zyga | So perhaps that is why | 06:21 |
| * mvo nods | 06:22 | |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | didn't we disable gccgo? | 06:37 |
| mvo | we can now, we got agreement we no longer need to support it | 06:38 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | https://api.travis-ci.org/v3/job/442894803/log.txt the gccgo unit tests died in most mysterious way here | 06:40 |
| mborzecki | this PR https://github.com/snapcore/snapd/pull/5989 | 06:41 |
| mup | PR #5989: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989> | 06:41 |
| mborzecki | uhh, restarted the job, the log is gone :/ | 06:42 |
| mwhudson | mvo: golang-1.10 is in proposed everywhere now \o/ | 06:47 |
| mvo | mwhudson: awesome, thank you so much! | 06:50 |
| pstolowski | mornings | 07:03 |
| pstolowski | mvo: thank you for getting to the bottom of decoding issue! i've left a comment | 07:04 |
| pedronis | pstolowski: is normalize enough though, any number ends up out of state as float, no? | 07:06 |
| mvo | pstolowski: thank you! also to pedronis for his comments. I figured this would need more discussion :) | 07:08 |
| mvo | pstolowski: if you know what to do, feel free to just take my PR (or just cherry pick the commit if its useful) and go wild | 07:08 |
| pstolowski | pedronis: hmm but not with json.DecodeWithNumbers as mvo proposed? | 07:09 |
| pedronis | pstolowski: indeed, but we still need to massage that | 07:09 |
| pedronis | I mean there is still a missing link | 07:10 |
| pedronis | one approach would be to teach normalize about json.Number I suppose | 07:11 |
| pstolowski | mvo: sure, i'll dig into it | 07:11 |
| zyga | pedronis: yeah, I think we should do exactly that | 07:11 |
| pedronis | we probably want to call normalize before NewConnection though | 07:11 |
| pstolowski | it's annoying this is a second instance of such issue (first was around configuration afair) | 07:11 |
| mup | PR classic-snap#22 closed: make snapcraft.yaml architecture specific <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/22> | 07:11 |
| pedronis | carrying around Numbers | 07:12 |
| pedronis | is a bit strange | 07:12 |
| mvo | pedronis: yeah, I was thinking that (normalize learns about json.Number), I have something local but its so trivial that I'm not sure its worth pushing | 07:12 |
| mvo | (on top of the UseNumbers PR) | 07:13 |
| zyga | mvo: shall I merge https://github.com/snapcore/snapd/pull/6012 ? | 07:14 |
| mup | PR #6012: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6012> | 07:14 |
| zyga | do you want it squashed? | 07:14 |
| mborzecki | damn, was checking out a problem with apparmor profiles not being loaded on arch, turns out i forgot to enable snapd.apparmor.service | 07:14 |
| mvo | zyga: I get the feeling we will need it squashfs yes | 07:16 |
| mvo | zyga: please do | 07:16 |
| mup | PR snapd#6012 closed: interfaces: fix NormalizeInterfaceAttributes, add tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6012> | 07:17 |
| mvo | zyga: thanks, I will cherry-pick into 2.36 | 07:18 |
| zyga | thank you! | 07:18 |
| mvo | thank *you* | 07:19 |
| mvo | pstolowski: keep me updated please, I will go back to core18 (unless you want me to help of course) | 07:19 |
| mup | PR snapd#6009 closed: cmd: use relative file names in locking APIs <Simple π> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6009> | 07:20 |
| pstolowski | mvo: will do, thanks | 07:21 |
| pstolowski | mvo, pedronis we could maybe make getAttribute reflect check smarter, if you convert to int if that's what caller requested, wdyt? | 07:27 |
| pstolowski | sorry, mistyped | 07:27 |
| pstolowski | we could maybe make getAttribute reflect check smarter and convert to int if that's what caller requested | 07:27 |
| pedronis | pstolowski: it's a bit too different from what we do everywhere else | 07:28 |
| pedronis | pstolowski: I think the result of getConns | 07:28 |
| pedronis | needs to be sane | 07:28 |
| pstolowski | i see, fair point | 07:28 |
| pedronis | pstolowski: btw, do we have a similar problem with dynamic attributes? | 07:29 |
| pedronis | I know we normalize but is a bit unclear if that's enough | 07:29 |
| pedronis | pstolowski: we can reboot in the middle of an op and then dynamic attributes would also come from state on disk | 07:29 |
| pstolowski | pedronis: i'm not sure anymore tbh, possibly yes, i trusted normalization but missed that json decoding/encoding problem | 07:30 |
| pedronis | pstolowski: we might want to write some kind of test about that | 07:30 |
| pstolowski | pedronis: yes, this what i'm aiming at first | 07:31 |
| pedronis | needs to serialize and unserialize state with dynamic attrs | 07:31 |
| pedronis | in it | 07:31 |
| mup | PR classic-snap#20 closed: port classic to UC18 and put into "18" branch <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/20> | 07:54 |
| mup | PR snapd#6015 opened: tests/unit/gccgo: drop gccgo unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6015> | 07:54 |
| mvo | hey sil2100 - happy release day | 07:59 |
| sil2100 | mvo: hey! Happy release day o/ | 08:02 |
| zyga | is today 18.10 day? | 08:04 |
| mup | PR snapd#6016 opened: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016> | 08:10 |
| mborzecki | pedronis: hi, the snap name split proposal ^^ | 08:11 |
| zyga | mborzecki: did you see https://forum.snapcraft.io/t/snapd-2-35-2-error-run-hook-configure-cannot-set-core-schedule-unsupported-system-option/8051 | 08:37 |
| mborzecki | zyga: core.schedule? | 08:37 |
| zyga | mborzecki: didn't look at this more than "looks like something you might know" | 08:40 |
| mup | PR classic-snap#23 opened: create,classic: make the classic snap work on classic distributions (for 18) <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/23> | 08:45 |
| mborzecki | opensuse mirrors at it again :( | 08:57 |
| mvo | zyga: I updated classic snap PR (21) you commented about. I will do shellcheck next and tests after that (need to think a bit about the tests) | 09:08 |
| zyga | mvo: can we use classic to run a script? | 09:09 |
| mvo | zyga: now we can | 09:09 |
| zyga | so that we could test "running scripts inside classic" via spread? | 09:09 |
| mvo | zyga: it was broken before | 09:09 |
| zyga | apt-get install && run something would be useful :) | 09:09 |
| zyga | perhaps a cli and a service? | 09:09 |
| mvo | zyga: sounds good, services are not supported (deliberately) but that needs a test too | 09:10 |
| zyga | ah I see | 09:10 |
| Chipaca | mvo: not supported as in won't install, or won't start? | 09:12 |
| Chipaca | did we come to an agreement about having 'install' not error if a service didn't start? | 09:13 |
| Chipaca | actually, before i get carried away: i need to go get a new phone :-( | 09:13 |
| zyga | oh | 09:13 |
| zyga | what happened? | 09:13 |
| mvo | Chipaca: correct, not starting | 09:13 |
| Chipaca | screen cracked, including the touchscreen, so no unlocking, so no 2fa | 09:13 |
| mvo | Chipaca: it will install fine (the service) but there will be a message that it won't run | 09:13 |
| Chipaca | mvo: nice | 09:13 |
| niemeyer | Chipaca: There's a Go app that generates the 2fa if you can still login.. it's quite convenient | 09:20 |
| niemeyer | Moins | 09:21 |
| mvo | good morning niemeyer | 09:23 |
| niemeyer | I'm a bit under the weather today, but feeling better compared to the night.. my voice just sounds like someone that shouldn't try to sing did some really hard singing | 09:23 |
| mup | PR classic-snap#24 opened: add shellcheck and fix warnings <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/24> | 09:24 |
| zyga | mborzecki: hey, do you have a second | 09:27 |
| mborzecki | zyga: hm? | 09:27 |
| zyga | I'm looking at a bit of shell and not sure why it is structured like that | 09:27 |
| zyga | mborzecki: please look at snap-mgmt.sh.in, line 122 | 09:27 |
| zyga | mborzecki: why do we do first a find | 09:28 |
| zyga | and then a for loop over a what looks like identical glbo | 09:28 |
| zyga | *glob | 09:28 |
| zyga | why not just iterate over find results? | 09:28 |
| zyga | is this fixing something? | 09:28 |
| mborzecki | zyga: don't know, i see it's the same in postrm in debian packaging, probable made its way from there | 09:30 |
| pedronis | zyga: probably the find and the glob fail differently | 09:36 |
| pedronis | zyga: it has a note in the postrm that some bits of that might not be mounted | 09:38 |
| pedronis | zyga: try for a in /nonexisting/* ; do echo $a ; done for example | 09:39 |
| zyga | right but the find would behave correctly? | 09:39 |
| zyga | could we not just iterate over results from find? | 09:39 |
| pedronis | zyga: the find fails too | 09:40 |
| pedronis | but the wc -l | 09:40 |
| pedronis | makes it work | 09:40 |
| zyga | ah, I see | 09:40 |
| zyga | right | 09:40 |
| zyga | because set -e is not active for pipe chains | 09:40 |
| zyga | makes sense, thank you pedronis | 09:40 |
| pedronis | but yes, maybe those needs for comment | 09:41 |
| pedronis | is usual shell fun | 09:41 |
| zyga | yes :) | 09:41 |
| pedronis | s/for/more/ | 09:41 |
| mborzecki | the whole block should use find, `for mnt in $(find /run/snapd/ns -maxdepth 1 -name '*.mnt'); do ... done` or just find with -exec | 09:45 |
| mborzecki | heh, actually find is used properly in the file in some places, just not everywhere | 09:47 |
| mvo | mborzecki: yeah, I think it was just a suboptimal fix, looking at git history | 09:50 |
| mvo | mborzecki: go ahead and make it great :) | 09:50 |
| pedronis | mborzecki: ? | 09:51 |
| pedronis | mborzecki: that doesn't work if /run/snapd/ns doesn't exist | 09:52 |
| zyga | pedronis: I tested it just now | 09:52 |
| pedronis | zyga: ? | 09:52 |
| pedronis | do you have /run/snapd/ns ? | 09:52 |
| zyga | for i in $(find /nonexistent); do echo $i; done. | 09:52 |
| zyga | it says that the directory doesn't exist but exits successfully because of the sub-shell | 09:53 |
| pedronis | yea, that error is not nice though | 09:53 |
| zyga | yeah, I think we can make it better still, let me experiment | 09:53 |
| pedronis | anyway not sure it's the best time spent | 09:53 |
| pedronis | at this moment | 09:53 |
| pedronis | the current code is weird but not wrong or insane | 09:54 |
| zyga | I'm looking because I got a odd failure in that area | 09:54 |
| mborzecki | test -d .. && for .. ? | 09:54 |
| zyga | but perhaps 14.04 specific | 09:54 |
| zyga | it seems a symlink confused the inner parts of the loop | 09:54 |
| Chipaca | niemeyer: wrt #5906, what about: we keep the old behaviour, but also add a zeroth implementation of fields=, just to cover media? | 10:14 |
| mup | PR #5906: snap, client, daemon, store: use and expose "media" more <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5906> | 10:14 |
| Chipaca | niemeyer: e.g. fields=+media | 10:14 |
| Chipaca | niemeyer: this assumes media is the end game tbh, which i'm not sure is what you meant | 10:15 |
| Chipaca | niemeyer: but I got conflicting messages yesterday as to whether it was the shape, or the duplication that you objected to | 10:16 |
| Chipaca | maybe it's both Β―\_(γ)_/Β― | 10:17 |
| niemeyer | Chipaca: It's both the shape and the duplication.. my concern is that we can't change our minds regularly once we have an API in the wild.. the best scenario is that the API is self-consistent, so we have a line of design that we can be truthful towards.. | 10:18 |
| niemeyer | Chipaca: I wish we had media on day one, but we don't.. even if we agree this is the way to go, adding the field means being neither here nor there. If we keep this kind of design mindset, soon this will be a huge mess. | 10:19 |
| Chipaca | niemeyer: which is the design mindset you object to? | 10:20 |
| niemeyer | Chipaca: The mindset that it's okay to make the API inconsistent with itself everytime an idea that looks better than the prior one shows up | 10:20 |
| Chipaca | niemeyer: ok | 10:20 |
| greyback | quick qn: I have qemu-kvm installed but spread still fails for me with: https://pastebin.ubuntu.com/p/WxVpFGrJwD/ (selected qemu image exists and was created using adt-buildvm-ubuntu-cloud). Any idea what I'm doing wrong? | 10:20 |
| Chipaca | niemeyer: how do we evolve the api, then? is the only way to have big versioned jumps? | 10:21 |
| Chipaca | greyback: is 'kvm' actually in PATH? | 10:21 |
| greyback | Chipaca: yes | 10:22 |
| pedronis | Chipaca: we need to design how to evolve the api | 10:22 |
| niemeyer | Chipaca: Yeah, that's generally what I try to do in other cases that resembled that kind of evolution. Learn, write down potential ideas, and once there is a great reason to break up, introducing a whole new API, and then reset the idea of what the current design is | 10:22 |
| Chipaca | greyback: all spread does is exec.Command("kvm", ...), which looks for "kvm" in $PATH | 10:22 |
| pedronis | Chipaca: I don't think keeping its shape as it is is tenable for much longer either | 10:22 |
| greyback | Chipaca: the $PATH specified in the spread.yaml? | 10:23 |
| niemeyer | pedronis: What's the potential deal breaker | 10:23 |
| niemeyer | ? | 10:23 |
| niemeyer | I haven't observed many complaints about the API yet | 10:23 |
| niemeyer | (which doesn't mean they don't exist) | 10:23 |
| pedronis | niemeyer: we already had to introduce duplication | 10:24 |
| pedronis | niemeyer: the flat top-level that mixes namespaces we don't fully control or have to control for not the best is not great either | 10:24 |
| niemeyer | pedronis: If the duplication you mention is developer/publisher, these are not actually duplicated, in the sense they were supposed to potentially represent different people.. we do have a problem which is not using the same structure for both, so indeed an inconsistency | 10:26 |
| niemeyer | pedronis: What's the flat top-level about? | 10:26 |
| pedronis | niemeyer: I understand that you think we can keep under control but an api that has at top level , left-corner-hero-icons is not great | 10:27 |
| niemeyer | pedronis: Sorry, I'm still missing what you really mean. If we can't keep the API under control, we're in the wrong business. :) What's left-corner-hero-icons? | 10:38 |
| Chipaca | greyback: I don't think so, that's the one 'inside'; it uses the outside path to find that | 10:39 |
| Chipaca | greyback: e.g. i have ~/bin/kvm because I like to monkey with the args (adding -smp 4 for ex) | 10:39 |
| Chipaca | greyback: and that just works | 10:39 |
| Chipaca | niemeyer: adding a toplevel entry per media type | 10:40 |
| greyback | Chipaca: ack. I'm reading spread code now, I see what you mean. I think my issue is permissions and kvm, trying to sort that out | 10:40 |
| Chipaca | niemeyer: will end up with e.g. left-corner-hero-icons at the top level | 10:40 |
| pedronis | or not | 10:40 |
| niemeyer | Chipaca: Only if that's how we design it | 10:40 |
| Chipaca | well, but that's what we're proposing now isn't it? | 10:40 |
| niemeyer | Chipaca: That sounds like a pretty terrible design | 10:40 |
| pedronis | we should not be designing that | 10:41 |
| pedronis | we have lots of thinks to design | 10:41 |
| Chipaca | we're saying: don't do media, let's just have a toplevel per media type | 10:41 |
| niemeyer | Chipaca: That's why I one of the first things I asked is what are the media types we have | 10:41 |
| pedronis | niemeyer: btw there are a meeting about exactly desiging those types, and nobody of us has been invited | 10:42 |
| Chipaca | niemeyer: there's a meeting next week to decide that | 10:42 |
| niemeyer | Chipaca: If we have several icons, we can have an "icons" field | 10:42 |
| pedronis | niemeyer: I let you meditate on that, I have zero energy for this | 10:42 |
| pedronis | (which is sort of the point) | 10:42 |
| Chipaca | i just don't get why we care. the consumers of our api need something, the providers of the data we consume offer that something, why would we not funnel it across untouched | 10:43 |
| Chipaca | i mean, i get that we don't want duplication | 10:44 |
| Chipaca | and we don't want it to be ugly | 10:44 |
| niemeyer | Chipaca: Alternatively, we can have a plan to obsolete the other fields.. we'll need to figure who uses them and what events we need to wait for in order to kill them | 10:44 |
| pedronis | which was my point | 10:44 |
| pedronis | we need to think how to evolve | 10:44 |
| pedronis | the api | 10:44 |
| Chipaca | but that just means we have a chat to make sure we're on the same page (i thought we were) and just pass it through | 10:44 |
| pedronis | non-evolving it | 10:44 |
| pedronis | is not a path either | 10:45 |
| niemeyer | Chipaca: My main complaint here is the lose way to evolve the API | 10:45 |
| niemeyer | loose | 10:45 |
| Chipaca | i thought your main complaint was the shape and the duplication | 10:46 |
| pedronis | I'm happy to have a conversation how not-loosely evolve the api, I'm less api to be forced to be in all conversation because our api is too set in its way | 10:46 |
| Chipaca | sigh | 10:46 |
| Chipaca | niemeyer: i thought fields= gave us a way to evolve the api | 10:47 |
| pedronis | Chipaca: on that I agree with niemeyer, is too flaky | 10:47 |
| pedronis | annoying | 10:47 |
| pedronis | I mean it can be part of the picture | 10:47 |
| pedronis | but cannot be the whole solutions | 10:47 |
| pedronis | also because we have zero control on when we can drop stuff | 10:47 |
| pedronis | that way | 10:47 |
| Chipaca | i haven't heard a proposal that gives us any amount of control on when we can drop stuff | 10:48 |
| niemeyer | Chipaca: That is my main complaint... the shape and the duplication are symptoms of a loose API | 10:48 |
| niemeyer | "Chipaca: Yeah, that's generally what I try to do in other cases that resembled that kind of evolution. Learn, write down potential ideas, and once there is a great reason to break up, introducing a whole new API, and then reset the idea of what the current design is" | 10:48 |
| pedronis | Chipaca: we can discuss some | 10:49 |
| pedronis | maybe | 10:49 |
| Chipaca | niemeyer: introducing a whole new api is not what i thought of as evolving the api | 10:49 |
| niemeyer | and | 10:49 |
| niemeyer | "Chipaca: Alternatively, we can have a plan to obsolete the other fields.. we'll need to figure who uses them and what events we need to wait for in order to kill them" | 10:49 |
| pedronis | niemeyer: that works only if you control all the pieces around the api | 10:49 |
| niemeyer | Chipaca: Both of these are proposals for how to keep an API tight while allowing for changes over time | 10:49 |
| niemeyer | Chipaca: Incompatible changes, that is.. changing is easy | 10:50 |
| Chipaca | and saying we can have a plan is not a plan :-) | 10:50 |
| pedronis | Chipaca: one idea is to have versions for different consistent views of/on a snap | 10:50 |
| pedronis | (views = set of fields if you want) | 10:50 |
| niemeyer | Chipaca: Heh.. I'm not sure how to satisfy that kind of snarky request for plans. | 10:51 |
| Chipaca | apologies if I'm coming across as grumpy or overly confrontational | 10:51 |
| niemeyer | Chipaca: I've been trying to explain what the main issue in my view is, and what potential ideas for solving it could be | 10:51 |
| pedronis | anyway at the moment we have two solutions that are problematic, don't care duplications, and forcing something that is loose into the top-level | 10:51 |
| Chipaca | niemeyer: it's ok to admit we don't have a plan and that we need one | 10:51 |
| pedronis | both *are* problematic | 10:52 |
| pedronis | and one will also create potentially tensions | 10:52 |
| pedronis | for which is unclear we have time to spend | 10:52 |
| niemeyer | Chipaca: I don't know what you want, honestly. I'm offering two alternatives, both of them are real ways to work together and evolve the API. Just repeating that you want a plan or want people to admit to not have a plan is completely irrelevant. | 10:52 |
| pedronis | I want a plan to be able to obsolete fields | 10:53 |
| niemeyer | pedronis: The only way to do that is to evaluate the impact... once we stop providing a field, we break people that depend on that field being there. | 10:53 |
| mup | PR classic-snap#25 opened: Add simple spread tests <Created by mvo5> <https://github.com/snapcore/classic-snap/pull/25> | 10:54 |
| pedronis | so this is much easier on servers, but we there should be a way for us to track field | 10:54 |
| pedronis | usage without being nosy | 10:54 |
| niemeyer | pedronis: The alternative of reving up the API allows us to have a consistent new API without breaking the old one. It won't remove the old one, but it does obsolete the field as a side effect. | 10:54 |
| niemeyer | pedronis: Right | 10:55 |
| pedronis | yes, of which a variant is to rev the response format only | 10:55 |
| pedronis | if that's is enough | 10:55 |
| niemeyer | pedronis: Right.. that's the /v3/ | 10:55 |
| pedronis | or using Accept | 10:55 |
| pedronis | or something | 10:55 |
| pedronis | we do have options | 10:55 |
| pedronis | not sure we can find a solution today and tomorrow | 10:56 |
| pedronis | but we do have options | 10:56 |
| niemeyer | pedronis: Yeah.. as mentioned earlier, in those situations I try to pack up a few high-profile changes that are clear reasons for the effort of breaking the API apart between vN and vN+1 | 10:57 |
| Chipaca | so, I want two things: I want to not block gnome software from getting the media they need today, and I want to be able to ditch the current response format entirely soon after we move to v2 search | 10:57 |
| Chipaca | a clear reason for breaking the api is that we're moving to not conflating per-revision and per-snap information | 10:57 |
| Chipaca | and our current structure does not allow for it | 10:57 |
| niemeyer | Chipaca: Is there a place I can read more about the second issue? | 10:58 |
| Chipaca | niemeyer: not sure if there's info on the issue; there's info on the solution | 10:59 |
| * Chipaca looks | 10:59 | |
| zyga | mvo: reviewed | 10:59 |
| * pedronis needs to have lunch + errand | 11:00 | |
| niemeyer | Chipaca: That's a big document.. is there a particular issue or header I should be looking at? | 11:02 |
| Chipaca | niemeyer: yeah, and as I say it doesn't describe the issue, just the solution, under the "Response" header | 11:03 |
| Chipaca | niemeyer: there's a "snap" object with per-snap members, and at the same level a "channel-map" list with per-revision objects | 11:04 |
| niemeyer | Chipaca: If we don't have a clear problem being solved, in general I'd be tempted to not introducing the breaking API change | 11:04 |
| niemeyer | Chipaca: and instead pack it next to other ideas for the time it's rev'd up | 11:05 |
| Chipaca | niemeyer: the problem is that we conflate per-snap and per-revision, so for example 'snap info' lies (to the best of its ability) | 11:05 |
| Chipaca | of course one could argue that lying in this way is the only sane approach | 11:06 |
| niemeyer | Chipaca: Yeah, I remember these discussions when we redesigned the original API.. but I have memories of the issue going beyond the representation of the result, and into actual usability, in the sense it's convenient for the user to have "snap info foo" doing the right thing | 11:07 |
| niemeyer | Chipaca: Right, what you just said | 11:07 |
| Chipaca | :) | 11:07 |
| Chipaca | niemeyer: I've got to move on to other things now | 11:09 |
| zyga | mborzecki: I added debug, doesn't reproduce :) | 11:11 |
| zyga | same seed | 11:11 |
| zyga | same tree | 11:11 |
| zyga | two runs in parallel | 11:11 |
| zyga | I hope I can get to the bottom of this | 11:11 |
| mvo | zyga: thanks for the review | 11:12 |
| niemeyer | Chipaca: Me too.. tasty things | 11:14 |
| * zyga -> walk | 11:24 | |
| * pstolowski lunch | 11:32 | |
| zyga | mborzecki: ha | 11:34 |
| zyga | reproduced that same behavior | 11:34 |
| zyga | mborzecki: I think I know what's going on | 11:34 |
| zyga | and it does look exactly like the centos case | 11:34 |
| zyga | let me spawn a more regular VM and try | 11:34 |
| mborzecki | mhm | 11:34 |
| mborzecki | centos was failing in the same place when calling snap-mgmt purge | 11:35 |
| zyga | EBUSY https://www.irccloud.com/pastebin/1eVl6UTk/ | 11:35 |
| zyga | mborzecki: look at that please | 11:35 |
| zyga | waoh wait | 11:35 |
| zyga | it's ever more mysterious!!! | 11:35 |
| zyga | that makes totally no sense! | 11:36 |
| zyga | feels more and more like a kernel bug? | 11:36 |
| zyga | + umount -l /run/snapd/ns/test-snapd-tools.mnt | 11:36 |
| zyga | umount: /run/snapd/ns/test-snapd-tools.1000.mnt: not found | 11:36 |
| zyga | I'll add more debug, I wonder if there are some interesting processes running in parallel with postrm | 11:41 |
| zyga | and what's the full content of that directory before we loop over it | 11:41 |
| Chipaca | why would 'common' not get created, on opensuse and fedora? | 11:41 |
| mborzecki | Chipaca: just common? which test? | 11:42 |
| Chipaca | actually opensuse might be a different issue | 11:43 |
| Chipaca | mborzecki: https://api.travis-ci.org/v3/job/442964462/log.txt | 11:43 |
| Chipaca | mborzecki: second failure there | 11:43 |
| Chipaca | mborzecki: sorry, third | 11:43 |
| Chipaca | first is shellcheck, second opensuse, third fedora | 11:43 |
| Chipaca | snapshot fails if common is missing | 11:44 |
| Chipaca | and, common is missing, wtf | 11:44 |
| greyback | Chipaca: I had permission errors with kvm, which caused the issue. Binary was there, just failing. Working now. Thanks for the help | 11:44 |
| Chipaca | greyback: np | 11:44 |
| Chipaca | greyback: was the error misleading, or was that what the os was reporting? | 11:45 |
| mborzecki | Chipaca: selinux? | 11:45 |
| mborzecki | Chipaca: there were some changes in creating snap dirs, but we have tests that verify that those are present iirc | 11:45 |
| Chipaca | mborzecki: it's not consistently reproducible | 11:45 |
| greyback | Chipaca: misleading error. strace showed me the kvm binary was being run, but printing an error | 11:45 |
| zyga | Small break | 11:46 |
| Chipaca | greyback: what was the error? | 11:46 |
| greyback | Chipaca: "need to run as root or suid" | 11:46 |
| Chipaca | greyback: ah, not an error from exec? | 11:47 |
| greyback | Chipaca: right | 11:47 |
| greyback | I'll log a bug | 11:47 |
| Chipaca | greyback: looks like a bug in go | 11:48 |
| Chipaca | greyback: is that because you weren't in the kvm group or something? | 11:49 |
| greyback | Chipaca: essentially yeah (modulo some other group error I'd made) | 11:49 |
| Chipaca | greyback: do you happen to have the strace? | 11:51 |
| greyback | Chipaca: unfortunately not, sorry. I'll see if I can repro, once my spread run finishes | 11:52 |
| Chipaca | greyback: thank you. I tried to repro locally and couldn't. | 11:58 |
| Chipaca | greyback: (running spread as "nobody" just hangs, which is weird but different) | 11:59 |
| Chipaca | #6007 could use reviews | 12:02 |
| mup | PR #6007: tests/lib: add an @mozilla.com exception to the CLA checker <Simple π> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6007> | 12:02 |
| mborzecki | off to pick up the kids | 12:15 |
| mup | PR snapcraft#2363 closed: {make,cmake,autotools} plugin: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2363> | 12:30 |
| jdstrand | mvo: ok, after *many* retries I finally got PR 6002 to pass spread. continuing to mash restart restart for PR 5989 | 12:30 |
| mup | PR #6002: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002> | 12:30 |
| mup | PR #5989: interfaces/system-key: add parser mtime and only discover features on write <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5989> | 12:30 |
| mvo | jdstrand: thank you | 12:31 |
| jdstrand | I'm not sure what is going on. the failures are timeouts in some dbus code (totally unrelated to my PR) | 12:31 |
| jdstrand | anyway, will continue to keep mashing | 12:31 |
| jdstrand | mvo: if there was time, it would be great to get 5981 and 5982 reviewed and in trunk (cc zyga). if not, I understand | 12:33 |
| mvo | jdstrand: let me have a look | 12:36 |
| * zyga is a bit indisposed now, sorry :| | 12:36 | |
| zyga | mvo: is 2.36 today? | 12:37 |
| zyga | I will review it but I need to break for some time, food poisoning :( | 12:37 |
| zyga | mvo: my update for today: I updated adb interface again, worked on snap-update-ns per-user support, which is looking good, expect PRs today, digging into the weird issue with unmount I talked to mborzecki about | 12:38 |
| zyga | jdstrand: https://www.irccloud.com/pastebin/1eVl6UTk/ FYI | 12:38 |
| zyga | jdstrand: carefully read lines 26 and 27 | 12:39 |
| mup | PR classic-snap#23 closed: create,classic: make the classic snap work on classic distributions (for 18) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/23> | 12:39 |
| zyga | this is on a 4.5 kernel | 12:39 |
| * zyga goes away again | 12:39 | |
| Chipaca | mvo: see my note on #6013 being a blocker for 2.36 | 12:43 |
| mup | PR #6013: Revert "snap, client, daemon, store: use and expose "media" more (#5906)" <β Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6013> | 12:43 |
| mvo | Chipaca: 'k | 12:44 |
| mvo | Chipaca: we have at least one more blocker | 12:44 |
| jdstrand | mvo: speaking of blockers. I know we discussed the bug, and I think it was implied, but PR 6002 should be a blocker too | 12:44 |
| mup | PR #6002: interfaces/system-key: add parser mtime and only discover features on write - 2.36 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6002> | 12:44 |
| mvo | jdstrand: +1 | 12:53 |
| ackk | hi, I'm having an issue with a snap that stages jq from the deb. it seems snapcraft stopped pulling in libjq1.so, so jq doesn't work anymore | 13:10 |
| ackk | (I'm using snapcrafat edge) | 13:10 |
| ackk | *snapcraft | 13:10 |
| ackk | https://github.com/CanonicalLtd/candid/blob/master/snap/snapcraft.yaml is the snapcraft config | 13:15 |
| ackk | ah, n/m I figured it out | 13:25 |
| Chipaca | mborzecki: polish is hard, let's do roadmap planning | 13:32 |
| mborzecki | heh :) | 13:32 |
| zyga | mborzecki: I know what is was! | 13:39 |
| mborzecki | zyga: umounts? | 13:40 |
| zyga | yes | 13:40 |
| zyga | I'll share after meeting | 13:40 |
| mborzecki | ok | 13:41 |
| Chipaca | #5955 is green; plz review | 14:00 |
| mup | PR #5955: cmd/snap, tests: snapshots for all <Snapshots πΈσ > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955> | 14:00 |
| zyga | brb | 14:03 |
| zyga | mborzecki: I have a fix | 14:03 |
| mborzecki | zyga: diff? | 14:04 |
| ppisati | ogra: FYI - https://lists.ubuntu.com/archives/kernel-team/2018-October/096147.html | 14:17 |
| * cachio lunch | 14:27 | |
| mvo | zyga, cachio thanks for your classic snap review(s) - I updated 25 | 14:30 |
| zyga | mborzecki: I just tested it manually, the fix is to avoid lib mount in a test I changed | 14:36 |
| zyga | mborzecki: I'll ping you for review :) | 14:36 |
| pstolowski | mvo: i've pushed my additions to json issue fix to https://github.com/stolowski/snapd/pull/new/fix-conn-attributes-numbers ; i've added normalization, one more test and updated hooks spread test. would you like to merge this into your PR or shall I re-propose a new one? | 14:41 |
| mvo | pstolowski: either way is fine | 14:42 |
| greyback | Chipaca: aaand naturally I cannot reproduce the bug now | 14:42 |
| pstolowski | mvo: ok i'll propose a new PR | 14:42 |
| mvo | pstolowski: ok | 14:44 |
| mup | PR snapd#6017 opened: interfaces: fix decoding of json numbers for static/dynamic attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/6017> | 14:49 |
| zyga | pstolowski: sent a quick comment there | 14:54 |
| pstolowski | zyga: yep, ty | 14:54 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR core18#85 opened: Add wpa-supplicant to the list of installed packages <Created by sil2100> <https://github.com/snapcore/core18/pull/85> | 15:00 |
| mup | PR core18#85 closed: Add wpa-supplicant to the list of installed packages <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/85> | 15:22 |
| zyga | jdstrand, niemeyer: cool interaction observation: on macOS doing find $HOME triggers an interactive question from the system "terminal wants to access your contacts" - rejecting that I get a denial to enter a particular folder on disk; that would be an interesting way to manage system connections | 15:29 |
| niemeyer | zyga: If only the kernel offered us a way to make these decisions... | 15:30 |
| zyga | yes, that's true | 15:31 |
| zyga | I was just surprised to see this | 15:31 |
| Chipaca | zyga: niemeyer: we did have a plan to almost get there | 15:32 |
| Chipaca | but it was a lot of work, and not prioritised | 15:32 |
| zyga | I could use a coffee | 15:35 |
| zyga | but let me wrap one thing up first... | 15:35 |
| jdstrand | zyga, niemeyer: fyi, the apparmor prompting work is still being worked on. jjohansen made a good bit of progress | 15:46 |
| zyga | mborzecki: I fired another round of tests now, with the fix in place | 15:48 |
| slvn_ | slvn | 16:12 |
| slvn_ | hi, I have an issue with snapcraft.io | 16:12 |
| slvn_ | the website does not seem to take care of categories | 16:13 |
| slvn_ | hence the search engine is not working correctly | 16:13 |
| slvn_ | I have 10 snaps games that are published for a while. Only two of them appear in the listing of snapcraft.io when searching in "Games", but appears in "All snaps". | 16:14 |
| noise][ | slvn_: we have some upcoming feature work to allow for publishers to self-select categories, but in the meantime if you can provide a list of your game snaps that need to be categorized in a forum post I can get someone from our advocacy team to review and get them associated to the category | 16:24 |
| slvn_ | ok great ! | 16:40 |
| mup | PR classic-snap#25 closed: Add simple spread tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/25> | 17:06 |
| niemeyer | mvo: classic-snap#20 already went in, but fwiw thanks for the explanation. Sounds reasonabe | 17:10 |
| mup | PR classic-snap#20: port classic to UC18 and put into "18" branch <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/classic-snap/pull/20> | 17:10 |
| cyphermox | mvo: ping | 17:17 |
| cyphermox | mvo: I have just tested rev 445 of core18; adding wpasupplicant fixes the wifi connection issues (I can connect fine now) | 17:17 |
| cyphermox | (this is armhf+raspi3) | 17:17 |
| zyga | cyphermox: if you have an image I can test the dragon board | 17:23 |
| cyphermox | zyga: it was pre-testing, sil2100 will kick off a real build to get you a dragon image. | 17:26 |
| zyga | cool, sil2100 just let me know | 17:26 |
| sil2100 | Will be kicking off a new image soonish | 17:27 |
| zyga | great, just let me know (with the URL, I never remember those) | 17:33 |
| sil2100 | zyga: sure! | 17:35 |
| === Pharaoh_Atem is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Pharaoh_Atem | ||
| mvo | cyphermox: yay, thank you | 17:40 |
| sil2100 | mvo: strange, I was sure we had that installed, but then I checked and we only *discussed* it being installed on the forums | 17:43 |
| zyga | mborzecki: back | 17:43 |
| zyga | mborzecki: the fix is https://github.com/snapcore/snapd/pull/6010/commits/b803e1c62350e76e7f62fd937ea443191cc496f7 | 17:43 |
| mup | PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010> | 17:43 |
| zyga | and man, 14.04 :) | 17:43 |
| === Pharaoh_Atem is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Pharaoh_Atem | ||
| === Pharaoh_Atem is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Pharaoh_Atem | ||
| cachio | kyrofa, hey | 18:04 |
| cachio | kyleN, could you take a look to the nested suite? | 18:04 |
| kyrofa | Hey there cachio! I looked at the PR you linked. Am I correct in thinking that in order to get spread using an image with nested virt enabled you need to set those environment variables? | 18:06 |
| cachio | no env variables needed | 18:17 |
| cachio | kyrofa, those env variables are to configure our test suite | 18:17 |
| cachio | which kind of vm do you want to start? | 18:17 |
| cachio | I didnt try with kvm acceleration | 18:18 |
| kyrofa | cachio, multipass, actually | 18:18 |
| kyrofa | Have you tried that? | 18:18 |
| cachio | no | 18:18 |
| cachio | which on did you try? | 18:18 |
| kyrofa | cachio, I haven't tried at all after seeing that GCE link I shared saying that it needed to be enabled | 18:19 |
| kyrofa | cachio, so to be clear, are you saying you've already done that, or are you saying that you've got nested virt working without kvm? | 18:19 |
| cachio | yes | 18:19 |
| kyrofa | Hahaha, which one? | 18:19 |
| cachio | we run everyday that | 18:20 |
| cachio | ubuntu core, ubuntu 16, ubuntu 18 | 18:20 |
| cachio | using qemu | 18:20 |
| cachio | 2gb of memory | 18:21 |
| kyrofa | cachio, but you didn't do https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances ? Wonder if you're getting a software version, then (this is not my area of expertise) | 18:21 |
| cachio | kyrofa, I see, this is if you want to use the gce tooling | 18:24 |
| cachio | kyrofa, in fact they are describing a process really similar to what we do | 18:26 |
| kyrofa | cachio, interesting, so this may already work. I'm testing now | 18:26 |
| cachio | but they show how to create your image and use a gce image for the nested vm | 18:26 |
| cachio | and we create the image as part of the test | 18:26 |
| kyrofa | cachio, yeah it was more the "Enabling nested virtualization on an instance" section that I was referring to | 18:27 |
| kyrofa | Makes it sound like by default this won't work unless you take that action to add that licenses thing | 18:28 |
| kyrofa | cachio, yeah, looks like multipass needs KVM: | 18:29 |
| kyrofa | # multipass launch xenial | 18:30 |
| kyrofa | failed to launch: CPU does not support KVM extensions. | 18:30 |
| kyrofa | # grep -cw vmx /proc/cpuinfo | 18:31 |
| kyrofa | 0 | 18:31 |
| kyrofa | cachio, looks like we indeed need "the special license key required for virtualization." | 18:32 |
| cachio | in that case we need to create an image with kvm enabled | 18:32 |
| cachio | kyrofa, let me check a bit more about enabling kvm on gce | 18:32 |
| kyrofa | cachio, would there be a downside to just enabling that in all the images we're using? | 18:33 |
| kyrofa | cachio, excellent, thank you | 18:33 |
| cachio | kyrofa, dont have enough permissions for that | 18:59 |
| cachio | I'll request them and I'll try again | 19:00 |
| kyrofa | Alright cachio, thank you! | 19:00 |
| cachio | kyrofa, np | 19:02 |
| * cachio afk | 19:04 | |
| mup | PR snapcraft#2364 opened: maven plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2364> | 19:13 |
| * zyga EODs | 19:22 | |
| === Pharaoh_Atem is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Pharaoh_Atem | ||
| mup | PR snapcraft#2365 opened: multipass: change default CPU value <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2365> | 19:52 |
| mup | PR snapcraft#2366 opened: qmake plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2366> | 20:25 |
| * cachio afk | 21:00 | |
| mup | PR snapcraft#2264 closed: Fix issue where Rust cross compile target is ignored <Created by eberkund> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2264> | 21:46 |
| mup | PR snapcraft#2365 closed: multipass: change default CPU value <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2365> | 21:49 |
| mup | PR snapcraft#2367 opened: tests: add spread test exercising multipass build VMs <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2367> | 22:10 |
| mup | PR snapcraft#2368 opened: {kbuild,kernel} plugin: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2368> | 22:52 |
| mup | PR snapcraft#2366 closed: qmake plugin: add support for bases <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2366> | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!