| mup | PR snapd#5826 opened: tests: refactor for nested suite and tests fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5826> | 01:41 |
|---|---|---|
| mborzecki | morning | 05:01 |
| zyga | Yawn, hey hey | 06:19 |
| mborzecki | zyga: hey hey | 06:22 |
| mvo | hey zyga and mborzecki | 06:25 |
| mborzecki | any interesting reviews to look at? | 06:28 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | heyas | 07:02 |
| mvo | pstolowski: good morning | 07:02 |
| mup | Issue core18#4 closed: Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD)) <Created by EndrII> <Closed by EndrII> <https://github.com/snapcore/core18/issue/4> | 07:02 |
| zyga | there's going to be an interesting change | 07:04 |
| zyga | to seccomp | 07:04 |
| zyga | hopefully it won't be painful | 07:04 |
| mborzecki | zyga: what kind of change? | 07:08 |
| mborzecki | something in upstream? | 07:08 |
| zyga | a "one liner" | 07:09 |
| zyga | we need to support statx | 07:09 |
| zyga | I'm on it | 07:09 |
| mborzecki | ack | 07:22 |
| pedronis | mborzecki: I reviewed #5778 a bit closer, is not super clear that all removes and undo cases have been replaced, basically I tried looked at all the call paths to the removed os.Remove and seen if they grew a matching call to some new remove, it might also mean we miss some tests | 07:59 |
| mup | PR #5778: snap-update-ns: remove deadcode <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5778> | 07:59 |
| pedronis | mborzecki: sorry, I meant #5758 | 08:00 |
| mup | PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5758> | 08:00 |
| mborzecki | pedronis: thanks | 08:01 |
| mborzecki | pedronis: the removes in undosetupsnap had to go one level higher to the caller, because you don't know whether it's ok to remove the directory in the cleanup code path | 08:02 |
| pedronis | mborzecki: I know but there are other cases, removeDirs that you changed was called from a lot of places for example | 08:02 |
| pedronis | not super clear they are all covered now | 08:02 |
| pedronis | including undo cases | 08:03 |
| mborzecki | pedronis: i see, so undoCopySnapData and doCopySnapData need a further fix, i'm not sure about cleanupSnapData, is cleanup executed only in success path? | 08:26 |
| mup | PR snapd#5827 opened: ifacestate/autoconnect: do not self-conflict on setup-profiles if core-phase-2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/5827> | 08:28 |
| pstolowski | pedronis: ^ i didn't manage to recreate the case with spread (tried coming from snapd 2.0.2, 2.33.1, 2.23.9). i'm pretty sure the conflict check is the culrpit as discussed, but there might be a factor in reproducing that I missed | 08:30 |
| mup | PR snapd#5765 closed: store: move download tests into downloadSuite <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5765> | 08:48 |
| ogra | pedronis, any idea why the assertion importer talks aout a model that doesnt exist in https://forum.snapcraft.io/t/porting-ubuntu-core-to-imx6-am335x-issue/7089/20 ? | 08:53 |
| ogra | (the model name of the image seems to be "advantech" not "rsb4220") | 08:54 |
| ogra | *about | 08:55 |
| pstolowski | zyga, mborzecki : responded to your comments to https://github.com/snapcore/snapd/pull/5807 and fixed gofmt oddities | 08:57 |
| mup | PR #5807: interfaces: extra argument for static attrs in NewConnectedPlug/NewConnectedSlot <Created by stolowski> <https://github.com/snapcore/snapd/pull/5807> | 08:57 |
| pstolowski | mvo: would you mind taking a look at https://github.com/snapcore/snapd/pull/5762 ? | 08:59 |
| mup | PR #5762: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5762> | 09:00 |
| mvo | pstolowski: sure, will do in a bit | 09:00 |
| pstolowski | mvo: also, your https://github.com/snapcore/snapd/pull/5813 could land i think? | 09:01 |
| mup | PR #5813: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813> | 09:01 |
| mvo | pstolowski: yeah, I think its good - was wonder if samuele wanted to peek at it but its probably fine as is | 09:08 |
| mup | PR snapd#5818 closed: cmd/snap: handle "snap interfaces core" better <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5818> | 09:17 |
| zyga | thanks! | 09:17 |
| Chipaca | thursday before the sprint, and me without a haircut yet | 09:28 |
| Chipaca | morning all | 09:28 |
| mvo | Chipaca: hey! yeah, I'm scrambling to get osme things sorted as well | 09:33 |
| Chipaca | mvo: I don't know what osme is, but it sounds serious | 09:34 |
| Chipaca | mvo: today's my dad's birthday, as well. And I've got an interview with people from one of the boys' potential schools. | 09:34 |
| Chipaca | and, I've got tests to write | 09:34 |
| Chipaca | :-) | 09:34 |
| mvo | Chipaca: sounds like a full day! | 09:34 |
| mvo | Chipaca: *cough* osme -> some :( | 09:35 |
| Chipaca | and a washing day! because the sun is out | 09:35 |
| mvo | Chipaca: clear sign that I need to get better at typing | 09:35 |
| pedronis | mvo: left a couple of non-blocking comments on #5813 for you to consider | 09:35 |
| mup | PR #5813: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813> | 09:35 |
| mvo | pedronis: \o/ thank you | 09:35 |
| pstolowski | oh right, haircut /o\, thanks for reminder! | 09:35 |
| pstolowski | getting repeated failures today on google:ubuntu-18.04-64:tests/main/lxd | 09:36 |
| pedronis | pstolowski: gave a +1 to the fix PR but it's red atm | 09:36 |
| pstolowski | pedronis: yes everything is terrible atm | 09:36 |
| pstolowski | pedronis: and thanks btw | 09:36 |
| Chipaca | actuall, this thing is already nearly 900 lines. I'll split it, and then write the tests | 09:37 |
| niemeyer | zyga, mvo: I think we should do a bit better for that fix | 09:37 |
| Chipaca | y | 09:37 |
| niemeyer | But good mornings, first :) | 09:38 |
| mvo | niemeyer: what fix in particular? and good morning :) | 09:38 |
| niemeyer | mvo: The one about interfaces core | 09:38 |
| mvo | ok | 09:38 |
| zyga | niemeyer: hello | 09:39 |
| zyga | what kind of improvement are you looking for? | 09:39 |
| niemeyer | zyga: Heya | 09:39 |
| niemeyer | zyga: It would be nice if it is possible, anyway.. let's see | 09:40 |
| pstolowski | good morning niemeyer! | 09:40 |
| niemeyer | zyga: Do we ever send the snap name to the server end? | 09:40 |
| zyga | no | 09:40 |
| pstolowski | mvo: thanks for the review of wait-for-core pr | 09:40 |
| niemeyer | zyga: Hmm :/ | 09:40 |
| zyga | niemeyer: otherwise I would have implemented a server side fix | 09:41 |
| niemeyer | zyga: and I guess we don't actually print the snap name either, when it's system/core | 09:41 |
| zyga | that's correct | 09:41 |
| niemeyer | zyga: Ok, sorry, the fix is great then, thanks | 09:41 |
| niemeyer | zyga: The only other alternative I can think of is reverting the change, making it "core" again, and adding an explicit "nicknames" field | 09:42 |
| zyga | I had a branch that does the revert, if we add the nicknames field we would indeed be 100% backwards compatible | 09:42 |
| zyga | we could do that, that's an interesting idea | 09:43 |
| zyga | let me check one thing really fast | 09:43 |
| zyga | niemeyer: so in all cases we _can_ add a field | 09:43 |
| zyga | so yeah, we could do that | 09:44 |
| niemeyer | zyga: The thing that bothers me a bit about that approach is that we have a significant number of connections to core | 09:44 |
| niemeyer | obviously | 09:44 |
| niemeyer | zyga: So this will become super repetitive | 09:44 |
| zyga | indeed :/ | 09:44 |
| zyga | but this is the best we can do without breaking the compatibility | 09:44 |
| niemeyer | zyga: Perhaps we could add some metadata at the outer level | 09:44 |
| niemeyer | zyga: So it stops being repetitive | 09:44 |
| niemeyer | zyga: "nicknames": {"system": "core"} | 09:44 |
| zyga | phone | 09:44 |
| niemeyer | zyga: Not sure.. "phone" doesn't feel like a great nickname in this case | 09:45 |
| zyga | i m on z call | 09:46 |
| mvo | zyga: z ? | 09:46 |
| zyga | I'm on a call | 09:46 |
| mvo | heh :) | 09:46 |
| mvo | ok sorry | 09:46 |
| niemeyer | mvo: He's not getting jokes today :P | 09:48 |
| mvo | niemeyer: heh | 09:49 |
| * mvo hands zyga some more coffee | 09:49 | |
| niemeyer | "I'm on z call" feels so german somehow | 09:49 |
| zyga | re | 09:50 |
| zyga | ok | 09:50 |
| zyga | so yeah, we could do that | 09:50 |
| zyga | give me an hour to wrap this up | 09:51 |
| niemeyer | I just got a reply to my flight re-request saying "Sorry for not responding earlier, we work 10:00-18:00.." .. the request was on Monday... | 09:51 |
| zyga | I can reopen my branch, add the nickname there and see what we get | 09:51 |
| niemeyer | zyga: There where? | 09:51 |
| zyga | to the top-level of the response | 09:51 |
| zyga | because we have space for that | 09:52 |
| zyga | as in, the types are set up so that it is not hard to do | 09:52 |
| zyga | niemeyer: we may even use this to fix another issue | 09:52 |
| zyga | niemeyer: that the client doesn't know the type of the snap | 09:52 |
| niemeyer | zyga: Yeah, I think we have a place specific for metadata in the response already | 09:52 |
| zyga | to know that "core" or "snapd" are special | 09:52 |
| zyga | and can be abbreviated | 09:52 |
| zyga | and we could do it all in a way that is 100% backwards compatible | 09:53 |
| mborzecki | off to pick up the kids | 09:53 |
| niemeyer | zyga: Yeah | 09:53 |
| niemeyer | mborzecki: o/ | 09:54 |
| mup | PR snapcraft#2267 closed: build providers: refresh packages on bring up <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2267> | 09:55 |
| pstolowski | "building microservices with go" ebook available for free today at www.packtpub.com today (follow 'Free learning...' button at the bottom) | 09:59 |
| mup | PR snapcraft#2266 closed: integration tests: disable tests using snaps in bionic container <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2266> | 10:01 |
| pstolowski | mvo: hey, i've added real device samples to https://github.com/snapcore/snapd/pull/5759 per your comment | 10:29 |
| mup | PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759> | 10:29 |
| pstolowski | everything fails terribly on lxd spread test now (18.04). seems to be something fundamental - /var/snap/lxd/common/lxd/unix.socket is missing | 10:32 |
| zyga | pstolowski: lxd is socket activated now | 10:33 |
| zyga | perhaps the socket has moved? | 10:33 |
| ogra | zyga, it isnt anymore | 10:33 |
| zyga | no? | 10:33 |
| ogra | (while it gets switched to the snap by default) | 10:33 |
| zyga | can you tell me more? | 10:33 |
| ogra | https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040487.html | 10:34 |
| ogra | Note that at this time, the LXD snap isn't using socket activation yet. | 10:34 |
| ogra | We have code in place for that in the edge channel but want to do more | 10:34 |
| ogra | tests on it before we roll it out to all our users. This means that | 10:34 |
| ogra | starting on Monday, LXD will be starting up unconditionally on 18.10 | 10:34 |
| ogra | images. This is a temporary situation and will be corrected by release. | 10:34 |
| ogra | so better ping stephane, that might be a transition bug or some such | 10:35 |
| ogra | (since i dont know if it should actually apply to 18.04 too) | 10:36 |
| pstolowski | zyga: should we get rid of wait_for_lxd? | 10:36 |
| zyga | pstolowski: I'm not very familiar with the details | 10:37 |
| pstolowski | me neither | 10:37 |
| pstolowski | we basically keep polling for /var/snap/lxd/common/lxd/unix.socket before actual tests | 10:38 |
| mvo | pstolowski: cool | 10:38 |
| mborzecki | re | 10:40 |
| zyga | pstolowski: I'm deep in another task, can we discuss this in some time once I'm done | 10:41 |
| pstolowski | zyga: sure, in the meantime i'm experimenting with this test a little bit | 10:42 |
| mvo | pstolowski: nice, the updated tests give me a much better idea what it will look like in the real world | 11:06 |
| Chipaca | pedronis: niemeyer: I've got three options, and they're three somewhat unpalatable, and I thought maybe you guys might help me decide (or find a fourth) | 11:35 |
| Chipaca | if you recall, every successful command needs to check the warnings summary and report about it | 11:35 |
| Chipaca | the three options I see: 1. have everything from client return a ResultInfo, that contains the wanring summary, and have every command check that once it succeeds. This is the one I wrote, but it has two problems: it's a massive diff :-) and it's very easy to forget to check for warnings on success of a command | 11:35 |
| Chipaca | 2. have the client hang on to the relevant info, and pass the client into the checker. Smaller diff, just as easy to forget to do | 11:35 |
| Chipaca | 3. in cmd/snap have a single client instace instead of a Client() method, and have main itself check the warnings. Small diff, single point checking (as long as no command calls os.Exit directly on success, which should be easier to catch), but it's a global. Globals are bad, right? | 11:35 |
| Chipaca | 3b. like 3, but change all commands so the client is passed in. | 11:35 |
| Chipaca | pedronis, niemeyer: thoughts? | 11:35 |
| pedronis | Chipaca: the part about the client keeping state is what we did for restarts fwiw, but there were fewer places that cared | 11:56 |
| pedronis | Chipaca: so on that expect there is precedent, see Client.Maintenance | 11:57 |
| Chipaca | yep | 11:57 |
| Chipaca | pedronis: but here, every single command cares | 11:58 |
| Chipaca | (with two exceptions: the warnings-related commands themselves don't care) | 11:58 |
| pedronis | Chipaca: how would you pass in a client btw ? | 11:59 |
| pedronis | Execute is part of go-flags contract | 12:00 |
| menace | ahoi, is there a possibility for minikube to get the source recipe? there is a very old version of minikube installed, i'd like to try to update it on the current version | 12:00 |
| Chipaca | pedronis: ah, drat, you're right | 12:00 |
| Chipaca | cmars: ^ see menace's q | 12:00 |
| pedronis | Chipaca: same with the output | 12:01 |
| Chipaca | pedronis: the output? | 12:02 |
| niemeyer | pstolowski: A few comments in #5782... nitpicks mostly (sorry) | 12:02 |
| mup | PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782> | 12:02 |
| pedronis | I mean you can't change either input or output of that | 12:02 |
| Chipaca | pedronis: if this is 3b, that'd be every command doing checkWarnings(client) on success | 12:02 |
| Chipaca | ah no | 12:03 |
| Chipaca | pedronis: no it wasn't | 12:03 |
| Chipaca | pedronis: so i don't follow, no | 12:03 |
| Chipaca | pedronis: ah, maybe this: idea was you pass the client in, and then run does the checkWarnings(client) (client would presumably have warning info after the command was done with it) | 12:03 |
| niemeyer | Chipaca: As pedronis mentioned, it sounds analogous to Maintenance | 12:03 |
| niemeyer | pedronis, Chipaca: I think our Execute is already higher-level | 12:04 |
| Chipaca | nop | 12:04 |
| niemeyer | Or that's what my faulty mind reminds | 12:04 |
| Chipaca | or yep | 12:04 |
| Chipaca | niemeyer: no, the Execute from commands isn't run directly by us, but via flags.Parse() | 12:05 |
| Chipaca | niemeyer: it's similar, except Maintenance is only checked in two places (in wait, ie for all async commands, and in cmd_changes) | 12:06 |
| pedronis | maybe it's time to think of a cheap way to sit in between go-flags and Execute, we do have some control in addCommand | 12:06 |
| pedronis | so we could do something, the question is how cheap/clean that could be | 12:06 |
| Chipaca | it's high time we thought about moving on from flags, but that's a longer-term thing | 12:07 |
| menace | i have to go, i will come back later... | 12:07 |
| Deknos | re | 12:08 |
| Deknos | sorry. | 12:08 |
| Deknos | i have still time to the next track | 12:08 |
| Chipaca | pedronis: ah, i see what you mean, yes | 12:08 |
| Deknos | did anyone answer my minikube source recipe question? :> | 12:08 |
| Chipaca | Deknos: you were menace a moment ago | 12:08 |
| Chipaca | Deknos: the snap author is in TX, it's 7am there, check back in a few hours | 12:09 |
| === Deknos is now known as menace | ||
| menace | ah, okay, thanks | 12:09 |
| Chipaca | menace: is the thing about it being old also true about the edge version? | 12:09 |
| menace | Deknos is just an older handle which i used on other network.. because of that i want to use it here now, too | 12:09 |
| === menace is now known as Deknos | ||
| Deknos | how can i choose the edge channel/version? | 12:10 |
| Deknos | i am new to snap =) | 12:10 |
| Chipaca | Deknos: ah. Look at 'snap info minikube' to see more | 12:10 |
| pedronis | Chipaca: there should be a way to have ExecuteExt and some wrapping that would expose an Execture calling ExecuteExt | 12:11 |
| Chipaca | Deknos: and 'snap install --edge minikube' if you want that | 12:11 |
| Chipaca | Deknos: (note edge is typically unstable) | 12:11 |
| Chipaca | pedronis: you'd rather this to approach, then? | 12:12 |
| Chipaca | should be straightforward, but I'd do it in two steps | 12:12 |
| Deknos | how can i check which version is in the snap channel without installing it? | 12:12 |
| pedronis | Chipaca: I doubt is straightforward | 12:12 |
| Chipaca | Deknos: did you look at 'snap info' | 12:12 |
| pedronis | but possible | 12:12 |
| Deknos | ah, edge is 0.24.1, but current is 0.28 | 12:12 |
| pedronis | Chipaca: you need to keep go-flags reflection happy | 12:12 |
| Chipaca | pedronis: I have a code axe. Everything is straightforward with enough violence. | 12:13 |
| Deknos | then my question still stands :) | 12:13 |
| pedronis | Chipaca: said that it still make sense the other path, make warnings state on client | 12:13 |
| pedronis | Client | 12:13 |
| pedronis | s/path/part/ | 12:13 |
| Chipaca | pedronis: on client the package, not client.Client? | 12:13 |
| Chipaca | mborzecki: suggested the same | 12:13 |
| pedronis | Chipaca: ? | 12:14 |
| pedronis | Chipaca: like Maintenance so client.Client | 12:14 |
| Chipaca | ah, right | 12:14 |
| pedronis | not global in client | 12:14 |
| Chipaca | pedronis: and have the check be in each command? | 12:14 |
| pedronis | please not that | 12:14 |
| pedronis | Chipaca: no have check in Execute wrapping ExecuteExt | 12:14 |
| Chipaca | ah | 12:14 |
| Chipaca | mmkay | 12:14 |
| pedronis | maybe | 12:15 |
| pedronis | you need to write | 12:15 |
| Chipaca | if we had go 1.7 it'd be super easy | 12:15 |
| pedronis | and ssee how it looks | 12:15 |
| Chipaca | i can build structs using reflect, there :-) | 12:15 |
| pedronis | heh | 12:15 |
| Chipaca | metaprogramming \o/ | 12:15 |
| Chipaca | anyway. I'll go make lunch and think. | 12:16 |
| Chipaca | pedronis: thanks | 12:16 |
| Chipaca | niemeyer: and you | 12:16 |
| niemeyer | o/ | 12:16 |
| niemeyer | Chipaca: Btw, I think it's easy to wrap around the builder() | 12:16 |
| niemeyer | Chipaca: But you probably already figured as muc | 12:17 |
| niemeyer | h | 12:17 |
| pstolowski | niemeyer: thanks for the review! | 12:24 |
| niemeyer | pstolowski: np | 12:27 |
| * pstolowski quick lunch | 12:36 | |
| alexlarsson | jamesh: what is the status of backporting x-d-p in bionic? | 13:08 |
| Deknos | (kpom | 13:10 |
| Deknos | arg, sry | 13:10 |
| cmars | hi menace, the source to minikube is here: https://github.com/cmars/minikube-pkg | 13:17 |
| cmars | note the unsupported note there -- microk8s is a far better solution for my needs, uses less resources, so I've dropped it | 13:18 |
| cmars | menace: however, if you want to take it over, i'm happy to assign the snap ownership over to you | 13:18 |
| Deknos | cmars, well first i want to be sure i am able to do such stuff | 13:24 |
| Deknos | i'll look at the repository :) if i am able to, i can maintain it. | 13:25 |
| mup | PR snapd#5828 opened: snap-confine: make /lib/modules optional <Created by mvo5> <https://github.com/snapcore/snapd/pull/5828> | 13:30 |
| zyga | alexlarsson: while James is probably away now in 18.10 we have 1.0.2-1 | 13:35 |
| zyga | alexlarsson: not sure if that helps | 13:35 |
| alexlarsson | Well, that is kinda expected | 13:35 |
| alexlarsson | The issue is about the bionic flatpak ppa | 13:36 |
| zyga | I don't know the status of the back porting effort though | 13:36 |
| alexlarsson | should i update x-d-p in it | 13:36 |
| alexlarsson | I waited with that a bit, but people are starting to complain | 13:36 |
| zyga | I don't know | 13:37 |
| zyga | perhaps just email James | 13:37 |
| alexlarsson | yeah, will do | 13:37 |
| Deknos | cmars, do i understand that right that microk8s does not need a virtual machine, but it could be run within a virtualmachine? | 13:37 |
| cmars | Deknos: yes, that's correct | 13:38 |
| cmars | Deknos: i'm currently running a microk8s cluster in a multipass bionic VM, works great | 13:38 |
| Deknos | .. nice. i have windows and macos developers.. and though vagrant/virtualbox works there, minikube is a pain in the ass.. having the local developer kubernetes cluster in a virtual machine with ubuntu would help massively... | 13:39 |
| Deknos | nonetheless first i have to look into your minikube repo. | 13:40 |
| Deknos | cmars, when you built the last minikube version (0.23) did you build it for ubuntu 16.04 or ubuntu 18.04? because i do not know to see the base dependency in snap for your edge package :) | 13:41 |
| cmars | Deknos: i think it was just 16.04 | 13:42 |
| Deknos | since i am reading your readme and it mentions that libvirt interface was not released with snap... is that still the issue or should i try to convert it to a libvirt interface if i understood the normal packaging and able to recreate it? | 13:44 |
| cmars | Deknos: ah, the readme is stale. the libvirt interface landed in snapd, so the KVM driver binary should work with that plug | 13:46 |
| cmars | Deknos: so this minikube snap is designed to run minikube on linux.. that's probably not going to work out too well for your windows/macos users | 13:48 |
| cmars | Deknos: the minikube snap will use docker-machine-kvm2 to create another VM. a VM in a VM is not great | 13:48 |
| pstolowski | https://www.irccloud.com/pastebin/NR6enGKq/ | 13:48 |
| pstolowski | mvo: ^ re lxd test, that's the issue i'm getting now | 13:49 |
| mvo | pstolowski: yeah, thats what I see | 13:49 |
| mvo | pstolowski: I pushed a small PR to test this | 13:49 |
| mvo | pstolowski: 5828 | 13:49 |
| cmars | Deknos: https://microk8s.io is probably going to be a better fit for your needs | 13:49 |
| Deknos | i know that miniknube snap will not work on windows/macos. but i hate to do the curl-calls. and i suppose, others, too. therefore, if it is really easier than deb packaging i would want to maintain minikube for snap | 13:53 |
| Deknos | microk8s is then another tool for my toolbox. but people already know minikube (on linux) | 13:53 |
| cmars | gotcha | 13:55 |
| pstolowski | mvo: ah, nice, thanks. i wonder about socket check though | 13:56 |
| mvo | pstolowski: the socket check I'm not sure about, it looks like this works (after some time) on master but if there is a nicer way by all means, we should switch to the nicer way | 14:04 |
| pstolowski | mvo: okay, i'll see if my change works on older systems | 14:04 |
| pstolowski | mvo: you PR passed | 14:13 |
| pstolowski | *your | 14:14 |
| mvo | pstolowski: yay | 14:16 |
| mborzecki | pstolowski: did your PR with fake backend appends land? | 14:16 |
| pstolowski | mborzecki: no, because of lxd test failures | 14:17 |
| mborzecki | aah | 14:17 |
| mup | PR snapcraft#2269 closed: Provider decides on the image <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2269> | 14:17 |
| mborzecki | pstolowski: cause i'm running a test with UpdateMany() and then every some runs i get bs data in fakebackend ops | 14:17 |
| pstolowski | mborzecki: right.. yeah i hope to land my fix very soon | 14:18 |
| pstolowski | zyga: can you ack mvo's #5828 ? | 14:25 |
| mup | PR #5828: snap-confine: make /lib/modules optional <Created by mvo5> <https://github.com/snapcore/snapd/pull/5828> | 14:25 |
| pstolowski | it's green (it's refreshing to see green after all-day red ;)) | 14:26 |
| mvo | pstolowski: \o/ | 14:29 |
| mvo | zyga: I reported the https://github.com/seccomp/libseccomp/issues/129 | 14:29 |
| mvo | zyga: seccomp issue | 14:29 |
| mup | PR snapd#5828 closed: snap-confine: make /lib/modules optional <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5828> | 14:33 |
| mborzecki | pstolowski: eh found where the bug was, fakestore is collecting data by snap-id :/ | 14:43 |
| Chipaca | ok, 'm off to that meeting | 14:43 |
| Chipaca | wish me luck :-) | 14:43 |
| mborzecki | Chipaca: good luck | 14:43 |
| pstolowski | mborzecki: so is it another problem, or the actual problem (and we don't need locking)? | 14:44 |
| mborzecki | pedronis: turns out mine was not locking related after all | 14:44 |
| mborzecki | pstolowski: ^^ | 14:44 |
| jdstrand | mborzecki: re https://github.com/seccomp/libseccomp/issues/129> nice report and idea. looking forward to the response | 14:44 |
| mborzecki | pstolowski: but caused by map iteration, so randomish hence giving bs results | 14:44 |
| pstolowski | mborzecki: k | 14:44 |
| pstolowski | mborzecki: i see | 14:45 |
| pedronis | mborzecki: multi snap tests are hard in snapstate (or you need to be flexible checking results) | 14:45 |
| pedronis | because order is not guaranteed by various pieces not can they | 14:45 |
| mborzecki | pedronis: yeah, i was pulling my hair out on this | 14:46 |
| mup | PR snapd#5829 opened: tests: use lxd's waitready instead of custom polling around lxd s… <Created by stolowski> <https://github.com/snapcore/snapd/pull/5829> | 14:47 |
| kyrofa | mvo, snapd has some sort of system health check these days, doesn't it? Is this system sane/can it run snaps type thing? | 14:56 |
| kyrofa | mvo, is that something an external caller (say, snapcraft) could use? | 14:56 |
| mvo | kyrofa: it has a mechanism, yes. its not very sophisticated though. its currently a) kernel version too old b) squashfs mountable c) appamror usable (lxd) | 14:58 |
| mvo | kyrofa: its not available via a call currently but that would be trivial to do | 14:58 |
| kyrofa | mvo, that would be quite useful. If you point me in the right direction I'd be happy to do it | 15:00 |
| mvo | kyrofa: the selftest/ pkg | 15:00 |
| mvo | kyrofa: in snapd, you could just wire it to a (hidden) command | 15:00 |
| mvo | kyrofa: to a hidden snap command - selftest.Run() error iirc is the external API | 15:01 |
| kyrofa | mvo, e.g. snap selftest? | 15:01 |
| Deknos | cmars, you forked the docker_machine_kvm repository? is there anything in there which is still not in the repository of dhiltgen? | 15:01 |
| kyrofa | mvo, or a new binary not in the standard PATH? | 15:03 |
| Deknos | cmars: at least i see no pull from you to him... | 15:07 |
| Deknos | bbl | 15:07 |
| kyrofa | mvo, I'll work toward `snap selftest`, let me know if you prefer something different | 15:08 |
| mvo | kyrofa: thats fine | 15:13 |
| mvo | kyrofa: yes, snap selftest and it should error differently when not run as root | 15:14 |
| mvo | kyrofa: the mount selftest needs to be root | 15:14 |
| menace | re | 15:16 |
| menace | cmars, did you answer my docker-machine-kvm repo question? had to reboot because of bios update | 15:16 |
| cmars | menace: yes. i think i had a PR into that project, but it may have never landed | 15:17 |
| cmars | menace: i think it was something to do with libvirt version compatibility, but it's been awhile. | 15:18 |
| cmars | dhiltgen might have since updated docker machine with the reqd changes | 15:19 |
| cmars | gotta go afk for now | 15:19 |
| menace | i will look into it. dhiltgen and others put the project under a new umbrella, but not much activity. thanks for your help | 15:21 |
| om26er | Wimpress: hello | 15:34 |
| om26er | Wimpress: this needs you review https://github.com/snapcrafters/android-studio/pull/28 -- Its inspired by your prior work on sublime-text | 15:36 |
| mup | PR snapcrafters/android-studio#28: Embed autodownloads <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/28> | 15:37 |
| ogra | wowzer ! | 15:43 |
| ogra | so accidentially not adding CONFIG_DEBUG_INFO=n to a kernel snap build actually results in an 1GB kernel snap | 15:44 |
| ogra | ppisati, ^^^ couldnt we make that a default so that you need to add CONFIG_DEBUG_INFO=y if you explicitly want debug info built in ? | 15:44 |
| ogra | (took me a while to find out why ubuntu-image and dd suddenly started taking so long :P ) | 15:45 |
| mup | PR snapd#5817 closed: snapstate/tests: serialize all appends in fake backend <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5817> | 15:57 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapcraft#2270 opened: catkin, rosdep: stop using FileNotFoundErrors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2270> | 18:35 |
| mup | PR snapcraft#2271 opened: reporting: fail gracefully on submit errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2271> | 18:53 |
| bedna | hello all, please add support to snapd for systemd free distros, thanks. | 19:07 |
| popey | bedna: hello. which distros in particular? | 19:08 |
| popey | We have had a request for one, I wondered if your request was for the same or another. | 19:08 |
| bedna | popey, antiX | 19:08 |
| popey | Thanks | 19:09 |
| bedna | popey, same? | 19:09 |
| popey | no | 19:09 |
| popey | I'd not heard of antix before now. | 19:09 |
| bedna | popey, antiX is same as MX Linux, but MX Linux more userfriendly | 19:10 |
| bedna | popey, users from MX Linux have same problem. MX Linux on Distrowatch have 3th position in last month https://distrowatch.com/dwres.php?resource=popularity | 19:16 |
| popey | Distrowatch is a measure of distributions with poor SEO, not a measure of users :) | 19:16 |
| bedna | popey, OK, but what is better? | 19:17 |
| popey | Steam survey, wikimedia foundation, netcraft survey etc. | 19:17 |
| popey | I'm not saying MX Linux is bad. :). Just that distrowatch isn't a measure of a distribution's popularity. | 19:18 |
| bedna | popey, OK | 19:18 |
| pedronis | seems we have a test not mocking and actually writing to $HOME/snap/snapname | 19:38 |
| mup | PR snapcraft#2272 opened: meta: friendlier message for incorrect app command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2272> | 20:05 |
| NickZ | doot doot | 20:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!