| mup | PR snapcraft#2258 closed: build providers: snapcraft images for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2258> | 02:02 |
|---|---|---|
| mup | PR snapcraft#2256 closed: local source: don't include .snapcraft directory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2256> | 02:05 |
| Doctor_Nick | leeloo dallas multipass | 02:40 |
| Doctor_Nick | one of the posts on the forum says that fine-grained network mediation is on the snapcraft roadmap; does anyone know where the proprosal for this is? | 02:56 |
| Doctor_Nick | https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588 | 03:57 |
| * Doctor_Nick shakes head sadly | 03:57 | |
| mup | Bug #796588: Fine-grained network mediation <aa-feature> <aa-kernel> <kernel-net> <AppArmor:In Progress> <apparmor (Ubuntu):Triaged> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/796588> | 03:57 |
| zyga | Good morning | 04:47 |
| === pbek_ is now known as pbek | ||
| zyga | There is a power outage here. I only have my laptop and phone | 04:47 |
| zyga | Some phases are being turned on and off so I’ll leave my desktop off for now | 04:48 |
| zyga | Some phases are being turned on and off so I’ll leave my desktop off for now | 04:48 |
| mborzecki | morning | 05:06 |
| zyga | Hey | 05:08 |
| mborzecki | zyga: wow, got +1 on mount mappings PR, would you like to do another pass there? | 05:21 |
| zyga | yeah | 05:21 |
| zyga | just breakfasting | 05:21 |
| mborzecki | zyga: wonder if i should pester jdstrand for review there as well | 05:22 |
| zyga | mborzecki: I think Jamie will be back today or perhaps tomorrow | 05:23 |
| zyga | mborzecki: I'll be back soon, there was a power outage last night and I'll work from my laptop doing reviews more than anything | 05:23 |
| mborzecki | zyga: oh, was there a thunderstorm or sth? | 05:23 |
| zyga | no idea | 05:33 |
| zyga | whole street went dark | 05:33 |
| zyga | around after 1AM | 05:33 |
| zyga | I was brushing my teeth when it happened | 05:33 |
| zyga | some parts of AC returned at 3-4AM | 05:33 |
| mborzecki | zyga: maybe it was planned shutdown :) | 05:35 |
| zyga | it broke my print :( | 05:35 |
| zyga | it's going to be another 9 hours | 05:35 |
| mborzecki | zyga: printing weapons of mass destruction? | 05:36 |
| zyga | companion cubes :) | 05:36 |
| mborzecki | hahah | 05:36 |
| mborzecki | damn, don't remember the last time i played portal | 05:36 |
| zyga | I was printing calibration cubes | 05:37 |
| zyga | of increasing size | 05:38 |
| zyga | oh and power is out again | 05:38 |
| zyga | I just switched to LTE from my laptop | 05:38 |
| zyga | man... | 05:38 |
| zyga | I want to see if Z axis is stable | 05:38 |
| zyga | and if there is any wobbling on the printer bed that causes layer misalignment as the print continues | 05:38 |
| mborzecki | heh, some PRs failed yesterday either getting go packages from github or poking the snap store, must have been an outage at some cloud provider | 05:55 |
| mborzecki | zyga: shoud i review #5802 or #5805 first? | 06:00 |
| mup | PR #5802: cmd/snap-update-ns: introduce trespassing state tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/5802> | 06:00 |
| mup | PR #5805: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <https://github.com/snapcore/snapd/pull/5805> | 06:00 |
| zyga | Mmmm | 06:11 |
| zyga | 5802 please | 06:12 |
| zyga | I’ll get to reviews in a moment, my wife forgot her phone to work | 06:12 |
| Doctor_Nick | yeah, that'll be handy for debugging | 06:12 |
| zyga | re, still on LTE but some phases are back so my computer is up :) | 06:30 |
| zyga | mborzecki: which PRs are best to review first? | 06:31 |
| mborzecki | zyga: mine? | 06:31 |
| mvo | heh - s/mine?/mine!!!/ ;) | 06:32 |
| mborzecki | mvo: hey | 06:32 |
| mvo | hey mborzecki | 06:32 |
| mvo | for me github is super slow and right now timing out :/ | 06:32 |
| mborzecki | mvo: that's about right :) | 06:32 |
| zyga | mborzecki: yes | 06:32 |
| zyga | hey mvo :) | 06:33 |
| zyga | mvo: at least you have power :D | 06:33 |
| mborzecki | mvo: had 5570 stuck in build pending status, but the travis job was already green | 06:33 |
| zyga | I spent way too much time last night on selinux | 06:33 |
| zyga | but I think I'm making progress | 06:33 |
| zyga | I'll do reviews today and respond to feedback | 06:33 |
| mvo | mborzecki: aha, let me look (or try to :) | 06:33 |
| zyga | but I will try to fix some selinux issues | 06:33 |
| mborzecki | mvo: restarted it already | 06:33 |
| mvo | mborzecki: if its green I can override it | 06:33 |
| mborzecki | zyga: i only have 2 other prs, #5770, #5785, independent of each other, pick whichever | 06:34 |
| mup | PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770> | 06:34 |
| mup | PR #5785: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5785> | 06:34 |
| mup | PR snapd#5632 closed: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5632> | 06:35 |
| mborzecki | mvo: #5808 also failed because of github/store connectivity issues, i've restarted it earlier | 06:35 |
| mup | PR #5808: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808> | 06:35 |
| mvo | mborzecki: cool, thanks for this | 06:35 |
| zyga | mborzecki: thanks | 06:36 |
| mborzecki | mvo: since you commented on both 5770, 5785, could you take another look? | 06:37 |
| mborzecki | btw. snap list --all bails with parallel installed snaps :P | 06:37 |
| zyga | mborzecki: bails? | 06:38 |
| zyga | what does it do | 06:38 |
| mborzecki | zyga: probably some bad globbing, all you get is https://paste.ubuntu.com/p/TqWXGDFNrJ/ | 06:39 |
| zyga | ah | 06:39 |
| zyga | it tries to find snap by name | 06:39 |
| mborzecki | it's actually poking an incorrect path | 06:39 |
| zyga | but ignoring the instance name | 06:39 |
| zyga | that's ... odd :) | 06:39 |
| zyga | well | 06:39 |
| mborzecki | yup | 06:39 |
| zyga | power is back! | 06:39 |
| mborzecki | fix coming up soon | 06:39 |
| zyga | I restarted my printer, 9 hours left :( | 06:40 |
| mvo | mborzecki: 5785 looks like its not from you | 06:40 |
| mborzecki | mvo: 5758, sorry :) | 06:40 |
| mvo | mborzecki: sure, looking | 06:43 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:12 |
| mborzecki | all right, the parallel installs integration branch has been update with all the PRs so far, the travis job should still be green | 07:12 |
| mborzecki | pstolowski: hey | 07:12 |
| zyga | mborzecki: sorry for making the 2nd branch so big btw | 07:13 |
| zyga | mborzecki: it's tad scary at 1K2 | 07:14 |
| zyga | mborzecki: but at the same time it shows what it takes to lug that state around; maybe there is a better way? | 07:14 |
| mborzecki | zyga: once 5802 lands the other one should 'appear' smaller, right? | 07:15 |
| zyga | yes | 07:15 |
| mborzecki | wish there was a mode in gh where you can view the diff against some other PR | 07:16 |
| mborzecki | i suppose you can fiddle with the url directly, but that's quite inconvenient | 07:17 |
| zyga | yeah | 07:18 |
| zyga | LP had that feature | 07:18 |
| zyga | https://github.com/snapcore/snapd/pull/5808 doesn't want to get geen | 07:27 |
| zyga | green* | 07:27 |
| mup | PR #5808: snapd-env-generator: fix when PATH is empty or unset <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5808> | 07:27 |
| pedronis | mborzecki: some small comment to #5770 | 07:45 |
| mup | PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770> | 07:45 |
| mborzecki | pedronis: thanks, looking | 07:47 |
| mvo | mborzecki: yeah, I like the suggestion of pedronis. its probably me overthinking things, but the fact that we added "salt" felt to me like we make a strong promise about the "strength" of the hash we send to the store. i.e. before it was just a way to sort things, now we protect it actively. I did some back of the envelope calculations and I think we should be fine with the 16 char secret, for peace of mind I would even up | 07:52 |
| mvo | it to 32 but then we should be really fine | 07:52 |
| mborzecki | mvo: refresh-privacy-key sounds good to me too, naming is hard heh :) | 07:55 |
| mvo | mborzecki: it totally is | 07:56 |
| mvo | mborzecki: thank you, I like this name too | 07:56 |
| mvo | pedronis: if you could re-review 5803 that would be great (its the content provider hang fix) | 07:57 |
| pedronis | in a sec | 07:58 |
| mvo | pedronis: no rush, the tests are unhappy anyway :/ | 08:01 |
| pstolowski | zyga: going over your tresspassing PR and asking some naive questions | 08:03 |
| zyga | sure | 08:03 |
| zyga | thank you! | 08:03 |
| zyga | hmmm | 08:05 |
| zyga | go crashes on "go build" | 08:05 |
| zyga | not something I wanted to see in the morning | 08:06 |
| zyga | it crashes in osutil | 08:06 |
| zyga | on golang 1.11 | 08:06 |
| zyga | ah, wait on 1.10.1 | 08:06 |
| niemeyer | Mornings | 08:15 |
| zyga | hey :) | 08:15 |
| niemeyer | mborzecki: Something is not quite right with the "system" alias on the interfaces command | 08:15 |
| niemeyer | mborzecki: "snap info core" stopped working on my machine | 08:15 |
| niemeyer | Sorry, not info | 08:16 |
| niemeyer | interfaecs | 08:16 |
| pstolowski | niemeyer: o/ | 08:16 |
| niemeyer | pstolowski, zyga: Heyas | 08:16 |
| zyga | niemeyer: we're discussing that just now | 08:16 |
| mborzecki | niemeyer: my hunch is that's the remapping that was added in 2.35 and daemon now knowing if client is aware of the change | 08:16 |
| mborzecki | zyga: ^^ | 08:16 |
| niemeyer | zyga: Where? | 08:17 |
| niemeyer | zyga: Don't see it | 08:17 |
| zyga | the "snap interface core" stopped working beause the response is "system:..." and the filtering is done client side | 08:17 |
| zyga | niemeyer: in the internal channel | 08:17 |
| pstolowski | mvo: got FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough after running the tests in a loop for ~1h locally | 08:19 |
| niemeyer | mborzecki: So, we need to do something about this.. | 08:19 |
| pstolowski | mvo: investigating it this morning | 08:19 |
| pedronis | mvo: +1 with some nitpicks | 08:19 |
| niemeyer | mborzecki: We should probably wait until tomorrow as I have a call with them in my late afternoon, so will be able to tell in more detail what else we need, but we definitely need to fix the behavior of "snap interfaces core" | 08:20 |
| mvo | pstolowski: nice, thanks for finding this | 08:21 |
| pstolowski | mvo: well, i haven't found the cause yet :) | 08:21 |
| niemeyer | We originally had some logic that would detect whether the query was made for core, and if so keep the name untouched | 08:21 |
| mvo | pstolowski: heh, thanks for "almost-finding" this then ,) | 08:22 |
| Chipaca | niemeyer: we could make snap interfaces always show the actual snap | 08:34 |
| Chipaca | ie not do the core/core18/fedoracore/snapd -> system translation on the way out | 08:34 |
| Chipaca | core-fedora? fedore? | 08:34 |
| niemeyer | Chipaca: Yeah, I think we should always present the actual name if people requested for that specific name | 08:34 |
| niemeyer | Chipaca: Not sure if that's their issue, though.. that's why I'd like to talk to them first | 08:35 |
| Chipaca | niemeyer: i meant in /v2/interfaces directly | 08:35 |
| Chipaca | niemeyer: agreed, totally | 08:35 |
| Chipaca | we've had too much run-around-and-fix-it due to chinese whispers | 08:35 |
| niemeyer | Chipaca: Right, also mean /v2/interfaces directly | 08:36 |
| Chipaca | niemeyer: in /v2/interfaces, without specifying any select parameter, you get a list of stuff that talks about "system" | 08:37 |
| Chipaca | (this is the legacy interfaces listing) | 08:37 |
| diddledan | eeenteresting: https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests | 08:44 |
| niemeyer | Chipaca: Ah, okay.. so you mean having interfaces never return the alias | 08:45 |
| niemeyer | Chipaca: Sure, that's the revert option | 08:45 |
| niemeyer | Chipaca: We may need to do that depending on how bad their issue is | 08:45 |
| Chipaca | niemeyer: … at least the legacy one | 08:45 |
| niemeyer | Yeah | 08:45 |
| Chipaca | niemeyer: so if we find out they're not using select=, we can do that and not touch the new | 08:46 |
| Chipaca | anyhow, back to coding for me | 08:46 |
| Chipaca | (shout for reviews) | 08:47 |
| niemeyer | Chipaca: Or we just finish that new command | 08:47 |
| niemeyer | ("connections") | 08:47 |
| Chipaca | niemeyer: I suspect they're talking to the socket | 08:47 |
| niemeyer | gopkg.in is down, btw | 08:49 |
| niemeyer | Well, it's not down.. | 08:49 |
| niemeyer | GitHub is blocking it | 08:49 |
| niemeyer | So if anyone has a good contact there, please let me know | 08:49 |
| Chipaca | niemeyer: you could say Microsoft is blocking it, to make it sound more ominous (to me) | 08:49 |
| niemeyer | Chipaca: It's a bit ironic indeed, to be honest | 08:50 |
| niemeyer | It's running for 4 years now | 08:50 |
| diddledan | the empire is blockading it? | 08:50 |
| diddledan | we need rogue one | 08:50 |
| Saviq | hey all, while working on the mir-kiosk tutorials we stepped on a mine of sorts, we have a race between mir-kiosk starting and creating the wayland socket and the app starting and being able to connect to it, what would you say would be the right solution across snaps? obvious one is a loop+timeout in a wrapper, but every app out there would need to include one, is there anything better do you think? | 08:51 |
| Saviq | both mir-kiosk and the kiosk app are snap daemons with restart-condition: always, but systemd bails on the app if it restarts too quickly anyway | 08:51 |
| mup | PR snapd#5810 opened: rfc: restore "core" as the API-level host for implicit slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5810> | 08:52 |
| Chipaca | Saviq: hmm! | 08:53 |
| zyga | Saviq: socket activation :) | 08:53 |
| Chipaca | zyga: are they in the same snap? | 08:54 |
| zyga | but it's tricky unless the socket is in a public space like /var/lib/snapd/$SNAP_NAME/common | 08:54 |
| Chipaca | um | 08:54 |
| Chipaca | Saviq: are they in the same snap? | 08:54 |
| zyga | Chipaca: socket activation would work in all cases | 08:54 |
| Saviq | no, separate snaps | 08:55 |
| Chipaca | zyga: if they were in the same snap, Before= would do the trick | 08:56 |
| Saviq | but we'd need to make mir-kiosk socket-activatable... but you're right that does sound like the right approach | 08:56 |
| zyga | Chipaca: perhaps, only if the snaps also use sd notify | 08:56 |
| zyga | Chipaca: otherwise the socket may not be ready for real | 08:56 |
| Chipaca | zyga: yup | 08:56 |
| Chipaca | Saviq: another thing we could do | 08:57 |
| Chipaca | Saviq: is expose RestartSec | 08:57 |
| Chipaca | Saviq: you could try to see if that'd do the trick; it's how long to sleep before actually restarting | 08:58 |
| Saviq | yeah that would work, but the "we could expose" part is a bit scary in terms of timelines ;) | 08:58 |
| Chipaca | Saviq: agreed :-) | 08:59 |
| Saviq | I think it might actually be easier to make mir-kiosk socket-activatable | 08:59 |
| Chipaca | Saviq: you can fake restartsec by adding 'sleep 1' to the top of your wrapper script though | 08:59 |
| Chipaca | Saviq: which is a lot easier than checking the socket in there :-) | 08:59 |
| Saviq | indeed :) | 08:59 |
| Chipaca | Saviq: the default sleep is 100ms which is probably too low for anything involved, anyway | 09:00 |
| Chipaca | Saviq: mir-kiosk is c++, yes? | 09:00 |
| Saviq | Chipaca: yes | 09:01 |
| Saviq | well, *mir* is, mir-kiosk is just a wrapper around it | 09:01 |
| mborzecki | does gopkg.in has issues or is it github? | 09:01 |
| Chipaca | /o\ it's wrappers all the way down | 09:02 |
| Saviq | :D | 09:02 |
| zyga | mborzecki: I see gopkg.in down | 09:02 |
| Chipaca | mborzecki: https://mobile.twitter.com/gniemeyer/status/1039433916019613696 | 09:02 |
| Saviq | Chipaca: really it's just startup scripts | 09:02 |
| Saviq | that don't really fit in mir proper | 09:02 |
| Chipaca | Saviq: but to make it socket-activatable you'd have to make mir itself be socket-activatable | 09:03 |
| Chipaca | ? | 09:03 |
| Saviq | yes | 09:03 |
| mborzecki | Chipaca: zyga: thx | 09:03 |
| Saviq | which should be easy, as far I can tell | 09:03 |
| Saviq | just "if systemd gives you a socket, use it; otherwise create your own" | 09:03 |
| Chipaca | Saviq: yep, there's example code (in C) for how to cover some corner cases well | 09:04 |
| Chipaca | Saviq: http://0pointer.de/blog/projects/socket-activation.html | 09:04 |
| Chipaca | Saviq: example 3 (at the bottom) | 09:05 |
| Saviq | yeah that's what I was looking at | 09:05 |
| zyga | Chipaca: we just have to use de-vendorized packages while github and gopkg.in is down ;) | 09:05 |
| Chipaca | zyga: brb devendorizing self | 09:06 |
| zyga | chipa.ca/internal/organs ;) | 09:09 |
| * Chipaca cannot get chipa.ca | 09:10 | |
| zyga | I don't understand myself either sometimes | 09:10 |
| Chipaca | zyga: no, i mean, i need to be a canadian business to buy chipa.ca | 09:11 |
| Chipaca | mvo: dunno if you saw https://forum.snapcraft.io/t/snapctl-not-found-in-base-core18-snaps-hooks/7297 | 09:12 |
| zyga | launchpad is not responding to post requests for me | 09:14 |
| mvo | Chipaca: I saw it but it not fully read it yet | 09:17 |
| mvo | Chipaca: I suspect this is a problem with stable | 09:18 |
| mvo | Chipaca: stable core18 | 09:18 |
| Chipaca | mvo: I checked on edge | 09:19 |
| mvo | Chipaca: oh, you did - ok | 09:19 |
| Chipaca | mvo: no snapd installed, snapctl is dangling | 09:19 |
| Chipaca | no snapd snap i mean | 09:19 |
| pedronis | how does that work, a symlink ? | 09:19 |
| Chipaca | yep | 09:19 |
| mvo | Chipaca: oh course | 09:19 |
| pedronis | did we break snap-confine binding | 09:19 |
| pedronis | of those things? | 09:19 |
| Chipaca | mvo: in fact i can't install snapd :-) | 09:19 |
| Chipaca | because i'm not a gadget with a model or sth | 09:20 |
| pedronis | ah | 09:20 |
| pedronis | core18 expects them to come from snapd | 09:20 |
| Chipaca | pedronis: dunno | 09:20 |
| pedronis | but here it's core and core18 | 09:20 |
| pedronis | fun | 09:20 |
| Chipaca | ye | 09:20 |
| pedronis | (too many moving parts problem) | 09:20 |
| mvo | yes | 09:20 |
| pedronis | (not enough tests) | 09:20 |
| Chipaca | it's bind-mountingn the directory from core (i assume) and that's missing snapctl | 09:20 |
| mvo | Chipaca: which is odd, we move it there a while ago | 09:21 |
| mvo | Chipaca: when I ls /usr/lib/snapd/snapctl I see it | 09:21 |
| mvo | Chipaca: but nevermind, I will write a spread test | 09:21 |
| mvo | Chipaca: for this case and that will give us a) an answer b) a regression test | 09:22 |
| mvo | pedronis: about the missing restores in snapstate, I'm working on a PR for this | 09:22 |
| niemeyer | pedronis, pstolowski: This is repeating ad-infinitum here: | 09:22 |
| pedronis | mvo: I'm not sure they are needed to be honest | 09:22 |
| niemeyer | 2018-09-11T09:21:52Z INFO auto-connect of snap "gopkg" will be retried because of "gopkg" - "core" conflict | 09:22 |
| Chipaca | mvo: true, I can see it there in core | 09:22 |
| Chipaca | dunno what's going on | 09:22 |
| niemeyer | Command was | 09:22 |
| niemeyer | snap install ~niemeyer/gopkg_2018.03.27_amd64.snap --dangerous | 09:22 |
| mvo | pedronis: oh, right - we may set on in SetUpTest | 09:23 |
| mvo | pedronis: let me double check that | 09:23 |
| pedronis | the mock is strange | 09:23 |
| pedronis | because the style is a bit different around those tests | 09:23 |
| pedronis | niemeyer: is that pulling in core as well? | 09:23 |
| niemeyer | pedronis: Yeah | 09:23 |
| pedronis | is not sorted | 09:24 |
| niemeyer | gopkg was scheduled before core | 09:24 |
| niemeyer | Yeah | 09:24 |
| niemeyer | pedronis: The strange thing is that core did finish | 09:24 |
| pedronis | ah | 09:24 |
| pedronis | then it's bizarre | 09:24 |
| niemeyer | pedronis: and even then gopkg couldn't get installed | 09:24 |
| niemeyer | Just kept retrying | 09:24 |
| niemeyer | pedronis: We really need those conflict improvements :( | 09:25 |
| niemeyer | installing core independently works of course | 09:25 |
| pedronis | a bit unclear why if core finished is still waiting | 09:25 |
| pedronis | that seems trange | 09:25 |
| mvo | pedronis: happy to make it less strange, I just need some more details what concerns you (not urgent) | 09:26 |
| cjwatson | Anyone familiar with core18 kind of stuff? Does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 sound like a plausible diagnosis from me? | 09:26 |
| mup | Bug #1791907: Cannot build base snaps <launchpad-buildd:New> <https://launchpad.net/bugs/1791907> | 09:26 |
| pedronis | mvo: just that having a full mock function seems overkill | 09:26 |
| pedronis | if we never restore anway | 09:26 |
| niemeyer | pedronis: Yeah, and it retried every 5 secs | 09:27 |
| mvo | pedronis: I just looked and I think we should restore, we don't mock in SetUpTest so this is currently leaking | 09:27 |
| niemeyer | Suspect that's easy to reproduce | 09:27 |
| pedronis | mvo: no, the problem is that the style is mixed | 09:27 |
| mvo | pedronis: otoh I can do a "SetModel" and use that in SetupTest and in the tests without a restore | 09:27 |
| pedronis | mvo: really mockModel are th odd ones | 09:28 |
| niemeyer | pstolowski: Can you dig into that please? It's closely related to the bits you're touching, and worked fine until recently | 09:28 |
| niemeyer | pstolowski: SHould be easy to reproduce.. the local snap file just had network and network-bind plugs | 09:28 |
| niemeyer | No other interfaces | 09:28 |
| pstolowski | niemeyer: yes, looking | 09:29 |
| pedronis | mvo: yes, SetModel would be more in style | 09:29 |
| mvo | pedronis: ok, so SetModel() and no restore? happy to do that | 09:29 |
| pedronis | mvo: again snapstate_test.go is probably getting too big | 09:30 |
| mvo | pedronis: what can we do about it? splitting it into more logical chunks? | 09:30 |
| pedronis | maybe | 09:31 |
| mvo | but yeah, its gigantic :/ | 09:31 |
| pedronis | it's doing odd things | 09:32 |
| mvo | pedronis: I will attack the snapctl on core18 issue now, then look at missing content provider warnings and then I should have time for the SetModel cleanup | 09:32 |
| pedronis | like having a suite in the middle of another for example | 09:32 |
| mvo | pedronis: what odd things in particular? | 09:32 |
| zyga | pstolowski: hey, I replied to your comments on the PR | 09:32 |
| mvo | pedronis: right | 09:32 |
| pedronis | just a sign it's hard to navigate in it | 09:32 |
| pstolowski | zyga: k thx | 09:32 |
| mvo | pedronis: +1 | 09:32 |
| pedronis | mvo: anyway, I think the style there atm is no Mock if the value is a function that is originally nil, just put it back to nil in TearDown | 09:33 |
| mvo | pedronis: +1 | 09:34 |
| pedronis | mvo: this is fun: grep "Suite)" snapstate_test.go, you can see the suites mixed | 09:35 |
| mvo | :/ indeed | 09:37 |
| pedronis | mvo: snapstate_test.go api_test.go and store_test.go are the largest files | 09:38 |
| pedronis | in that order (descending) | 09:38 |
| mborzecki | niemeyer: should this guy put your name in that field? https://github.com/snapcore/snapd/pull/5799#issuecomment-420201428 | 09:41 |
| mup | PR #5799: Install snap-failure binary on Fedora <Created by eyusupov> <https://github.com/snapcore/snapd/pull/5799> | 09:41 |
| niemeyer | mborzecki: Yeah, that's fine | 09:46 |
| niemeyer | mborzecki: Eldar just signed it | 09:59 |
| mborzecki | niemeyer: yup, he posted a note in github too | 09:59 |
| mup | PR snapd#5811 opened: tests: add test that runs snapctl with a core18 snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5811> | 10:11 |
| * Chipaca wonders why the rabbits look so tasty, down their rabbitholes | 10:17 | |
| diddledan | who's in charge of building the docker images? | 10:17 |
| diddledan | snapcraft* | 10:17 |
| diddledan | snapcraft docker images* | 10:17 |
| zyga | diddledan: no idea | 10:17 |
| diddledan | hmm, I don't know what I can do to help this person then: https://forum.snapcraft.io/t/permission-denied-when-building-with-snapcore-snapcraft/7186/20 | 10:18 |
| diddledan | seems the :stable tagged image can't build desktop app snaps (cannot find the desktop-launch script when it has definitely been placed into prime) and the :latest image doesn't include a fix that the person is needing | 10:19 |
| mup | PR snapd#5812 opened: snapstate: refactor tests to use SetModel* <Created by mvo5> <https://github.com/snapcore/snapd/pull/5812> | 10:20 |
| niemeyer | Phew.. | 10:20 |
| niemeyer | gopkg.in is back up now.. GH debugged the issue on their end and deployed changes to fix it | 10:20 |
| niemeyer | It doesn't look like it was actual firewalling | 10:20 |
| diddledan | niemeyer: go forth and pkg in! | 10:21 |
| niemeyer | diddledan: Forth is a bit strange, but quite a unique and interesting language :) | 10:21 |
| diddledan | haha | 10:21 |
| diddledan | I've never seen forth code I think | 10:22 |
| Chipaca | niemeyer: sometime, when you're needinig a break, give Wizard's Bane a read | 10:23 |
| zyga | mborzecki: doing one more pass on https://github.com/snapcore/snapd/pull/5713/files | 10:29 |
| mup | PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 10:29 |
| zyga | but first, more coffee - I'm feeling awake now | 10:29 |
| mborzecki | zyga: thanks | 10:29 |
| pstolowski | niemeyer: so far unsuccessful in reproducing the issue you observed - i tested on a clean xenial with custom snapd (current trunk) and no core, then snap install --dangerous mytestsnap (it has network and network-bind plugs; core gets installed, they get autoconnected). were you testing this on cosmic? | 10:29 |
| mborzecki | zyga: left you some comments in 5802 | 10:30 |
| zyga | thank you! | 10:32 |
| niemeyer | pstolowski: No, 16.04 | 10:32 |
| niemeyer | pstolowski: It was a brand new system | 10:32 |
| zyga | mborzecki: I'll apply all, thanks! | 10:32 |
| niemeyer | pstolowski: And it was the current stable | 10:33 |
| niemeyer | pstolowski: I think mvo landed something recently about sorting which might have affected this issue | 10:33 |
| niemeyer | Chipaca: What's that about? /me googles | 10:33 |
| pstolowski | niemeyer: i think mvo has a fix for hang on content-providers, but it hasn't landed yet | 10:34 |
| niemeyer | Chipaca: Sounds interesting :) | 10:35 |
| niemeyer | Chipaca: I love this review.. "This is what happens when a computer programmer and D&D player attempts to write a book. The result is not pretty." | 10:35 |
| niemeyer | How to blame the book *and* the author *and* every programmer *and* every D&D player, at once! | 10:36 |
| Chipaca | niemeyer: Cook is not a good writer | 10:36 |
| Chipaca | niemeyer: but the story is good | 10:36 |
| mvo | Chipaca: do you know the charles stross laundry series? | 10:42 |
| Chipaca | mvo: nope | 10:42 |
| mvo | Chipaca: the description of the other one sounds like you might like those too https://www.goodreads.com/series/50764-laundry-files | 10:44 |
| tomwardill | they get pretty dark | 10:45 |
| mvo | tomwardill: yeah, especially the later ones | 10:45 |
| tomwardill | the first few are pastiches of various genres, some people hate that | 10:45 |
| tomwardill | but they're good books | 10:45 |
| tomwardill | mvo: reminds me, I think I'm a book behind | 10:46 |
| pstolowski | pedronis: hey, i've accidently stumbled on https://pastebin.ubuntu.com/p/gSjHnr77KX/ - note the return nil; was this intended? assert tests don't seem to excercise this sceneario, snap setup is always there | 10:46 |
| pedronis | pstolowski: no, seems a typo | 10:47 |
| mvo | tomwardill: I'm looking forward to book9 which will happen in some weeks. I like book7 quite a bit | 10:47 |
| pstolowski | pedronis: ok, i'll fix it | 10:48 |
| * mvo goes back to the non-magical coding | 10:48 | |
| Chipaca | mvo: nice. I could get book 1 from a library... but getting to the library costs me more than the amazon book :-) | 10:55 |
| mvo | Chipaca: haha, you could try a excerpt first | 10:56 |
| mvo | Chipaca: (eh, whatever it is called in english to get the first few pages as a sample for free) | 10:57 |
| Chipaca | :-) | 10:57 |
| mvo | what is it actually called? | 11:00 |
| oSoMoN | jdstrand, hi! when you have a moment could you please comment on https://forum.snapcraft.io/t/fido-u2f-authentication-fails-in-chromium-snap-build/6130/4 ? | 11:01 |
| cjwatson | "excerpt" or "sample" sounds fine | 11:02 |
| cjwatson | Amazon calls it a sample I think | 11:02 |
| mvo | thanks cjwatson | 11:03 |
| mborzecki | mvo: pedronis: refresh-privacy-key it is, pushed everything to #5770 | 11:05 |
| mup | PR #5770: many: provide salt for generating instance-key in store requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5770> | 11:05 |
| mup | PR snapd#5813 opened: image: warn on missing default-providers <Created by mvo5> <https://github.com/snapcore/snapd/pull/5813> | 11:06 |
| mvo | mborzecki: nice | 11:07 |
| mup | PR snapd#5814 opened: daemon: fix snap list --all with parallel snap instances <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5814> | 11:13 |
| === Ygramul is now known as Igramul | ||
| mup | PR snapd#5815 opened: client: catch and expose logs errors <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5815> | 11:28 |
| pedronis | pstolowski: the issue wit core and gopkg is confusing, the code is relatively straighforward, go over all tasks that are no ready, but core was done | 11:29 |
| pstolowski | pedronis: yes; i couldn't spot anything in the code, will try some more to reproduce although afaiu it needs a core refresh to be triggered at the same time, so a bit hard. starting from a clean slate (no core installed) pulls core as expected and everything works | 11:32 |
| pedronis | pstolowski: but even a core refresh from another task would hit the find symmetric logic, no? | 11:36 |
| pstolowski | pedronis: that's correct, we don't care about same changes | 11:39 |
| pstolowski | pedronis: are you suggesting to manually invoke core refresh, then install the snap at the same time? | 11:39 |
| pedronis | maybe, but still don't undestarnd, to hit that logging we need to not have a pending autoconnect task on gopkg or core, and have a pending task on core | 11:41 |
| pedronis | of link-snap or setup-profiles kind | 11:41 |
| pedronis | pstolowski: also if they were installed together and there was not core, a core refresh would conflict (those conflicts are based on the entire change not a part/lane) | 11:43 |
| mup | PR snapd#5816 opened: overlord/assertstate: propagate TaskSnapSetup error <Created by stolowski> <https://github.com/snapcore/snapd/pull/5816> | 11:45 |
| pedronis | pstolowski: what I fear more is that something added installing core twice ? | 11:45 |
| pstolowski | pedronis: ^ can you take a look? | 11:45 |
| pstolowski | oh | 11:45 |
| pedronis | we had a bug like that at some point | 11:45 |
| pedronis | I think John fixed it | 11:45 |
| pstolowski | we would see something in snap changes right? | 11:46 |
| pedronis | yes | 11:46 |
| pedronis | snap changes would be good to have | 11:46 |
| pstolowski | niemeyer ^ can you grab a copy of state.json and share? | 11:47 |
| pedronis | pstolowski: there might also be a silly bug about checking from the wrong name/snap somewhere | 11:47 |
| pedronis | that we don't see | 11:47 |
| pedronis | or core/system confusion | 11:47 |
| Chipaca | gah | 11:53 |
| * Chipaca ~> lunch | 11:53 | |
| * zyga experiments with snap instances for review | 11:54 | |
| Chipaca | zyga: can we talk about 'snap interfaces potato'? | 12:05 |
| mup | PR snapcraft#2260 opened: build providers: allow setting ram and disk size <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2260> | 12:15 |
| zyga | Chipaca: yes | 12:34 |
| zyga | wanna HO? | 12:34 |
| Chipaca | zyga: having lunch, so not really :-) | 12:34 |
| Chipaca | bah | 12:34 |
| zyga | sure | 12:35 |
| Chipaca | i'm happier typing with my mouf full | 12:35 |
| zyga | anytime after standup unless clashing meeting | 12:35 |
| zyga | :D | 12:35 |
| zyga | :[%#] | 12:35 |
| Chipaca | zyga: my problem is that "snap interfaces some-rando-string" does not error | 12:35 |
| zyga | :[%#] & | 12:35 |
| zyga | drat! | 12:35 |
| zyga | mmm | 12:35 |
| zyga | indeed, that's counter intuitive | 12:35 |
| Chipaca | you pick that up sir, i didn't spend all morning cleaning for you to through your food all over the place | 12:35 |
| zyga | maybe "error: cannot find interfaces matching some-random-string" | 12:36 |
| Chipaca | zyga: ok | 12:36 |
| Chipaca | zyga: which takes me to problem #2 | 12:36 |
| ahasenack | mvo: hi, should this sru be stopped? https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1786438 | 12:36 |
| mup | Bug #1786438: [SRU] 2.35 <verification-needed> <verification-needed-bionic> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):New> <snapd (Ubuntu Xenial):New> <snapd (Ubuntu Bionic):Fix Committed> <https://launchpad.net/bugs/1786438> | 12:36 |
| Chipaca | zyga: it starts printing stuff before knowing :-) | 12:36 |
| ahasenack | because of https://bugs.launchpad.net/cloud-images/+bug/1791691 | 12:36 |
| mup | Bug #1791691: PATH broken in systemd units <block-proposed> <cloud-images:Confirmed> <snapd (Ubuntu):In Progress> <snapd (Ubuntu Bionic):In Progress> <snapd (Ubuntu Cosmic):In Progress> <https://launchpad.net/bugs/1791691> | 12:36 |
| zyga | Chipaca: that's easy to fix | 12:36 |
| mvo | ahasenack: yes, we will do a .2 hopefully today. we had some trouble with github being down though but still hopefully today | 12:38 |
| Chipaca | zyga: which takes me to problem #3 | 12:38 |
| Chipaca | zyga: that thing's messy :-) | 12:38 |
| zyga | oh boy | 12:38 |
| zyga | allice is still falling | 12:38 |
| zyga | you tell me that :D | 12:38 |
| zyga | but please be specific, messy how/ | 12:38 |
| Chipaca | zyga: what's your easy fix for #2? | 12:38 |
| Chipaca | zyga: the easy fix is usually either, accumulate into an array, check length of array before printing the header, *or*, have a flag and check before printing whether you'd printed the headers | 12:39 |
| zyga | Chipaca: I think we can just print once we fully know, that should be easy | 12:39 |
| Chipaca | zyga: both of those are made harder because of #3 :-) it's not a simple loop-check-print thing, it does lots of little decisions | 12:40 |
| Chipaca | zyga: so | 12:40 |
| Chipaca | zyga: can i refactor it to accumulate? it'll probably change quite a bit | 12:40 |
| zyga | may I just say that we want to kill that thing entirely | 12:40 |
| zyga | and do snap connections? | 12:40 |
| zyga | that may be nicer | 12:40 |
| zyga | and less magic | 12:40 |
| zyga | so what's 3? :) | 12:40 |
| Chipaca | zyga: er, we can't kill it, it's already depended on by people :-) | 12:41 |
| zyga | we can deprecate it | 12:41 |
| zyga | it would be a new API call for sure | 12:41 |
| Chipaca | even deprecated, i'd still want to address this | 12:41 |
| zyga | I cannot wait for warnings to say "you used a deprecated command, use ... instead" | 12:41 |
| zyga | sure | 12:41 |
| abeato | sergiusens, hey, I dug more into that issue I mentioned about debug info in binaries, it turns out this is what is happening: https://bugs.launchpad.net/snapcraft/+bug/1791946 | 12:42 |
| mup | Bug #1791946: Default autotools CFLAGS are overriden in some cases <Snapcraft:New> <https://launchpad.net/bugs/1791946> | 12:42 |
| ahasenack | mvo: any quick workaround available for cosmic lxd containers? Some file to edit? | 12:42 |
| Chipaca | zyga: ok, i'll refactor it (in a bit) | 12:43 |
| zyga | Chipaca: are you changing it? | 12:43 |
| Chipaca | zyga: unless you'd rather do it yourself, yes | 12:43 |
| zyga | Chipaca: let's talk at the standup, it should be easy | 12:49 |
| zyga | I just want to agree on what we want :) | 12:49 |
| zyga | mborzecki: I'm back to sorting | 12:49 |
| zyga | doing it more scientifically than before | 12:49 |
| mvo | ahasenack: you can probably just rm the generator | 12:51 |
| ahasenack | mvo: which file is it? | 12:51 |
| mvo | ahasenack: one sec, let me find it | 12:51 |
| mborzecki | zyga: can't tell if that's good or a bad thing | 12:51 |
| ahasenack | ok | 12:51 |
| mborzecki | zyga: what are you sorting? | 12:51 |
| zyga | mborzecki: it's good, we want to be correct | 12:52 |
| zyga | mborzecki: the fstab entries | 12:52 |
| mborzecki | aah | 12:52 |
| zyga | mborzecki: a sorting algorithm that understands both source -and- target | 12:52 |
| mvo | ahasenack: /usr/lib/systemd/system-environment-generators/*snapd* | 12:52 |
| ahasenack | thanks, will give it a try | 12:52 |
| mvo | snapd-env-generator is the exact filename | 12:52 |
| mvo | ahasenack: sorry for the trouble, if github stops acting up and tests are back I can do the upload so hopefully later today things should be good again | 12:53 |
| ahasenack | mvo: ok, then tomorrow's cloud image should have the fix | 12:53 |
| ahasenack | mvo: I think it worked, after the rm and a reboot, the container seems to have started up correctly | 12:53 |
| ahasenack | | c1 | RUNNING | 10.0.100.248 (eth0) | | PERSISTENT | 0 | | 12:53 |
| ahasenack | yep, ssh is working, etc | 12:54 |
| ahasenack | thanks! | 12:54 |
| mvo | ahasenack: good! and sorry for the trouble | 12:59 |
| Saviq | jdstrand: hey, one question about the x11 plug/slot situation for XWayland (https://github.com/snapcore/snapd/pull/4545) - any idea why it's not necessary to connect them (as a reminder, the same snap provides the slot and connects back to itself)? is it that the slot itself has the required permissions and those get applied without connection? | 13:23 |
| mup | PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4545> | 13:24 |
| zyga | pstolowski: reviewing that huge PR now | 13:28 |
| zyga | well, after HO | 13:28 |
| pstolowski | zyga: thx | 13:29 |
| sergiusens | thanks abeato | 13:30 |
| abeato | yw | 13:32 |
| zyga | pstolowski: have a look | 13:38 |
| niemeyer | pstolowski: Just sent the state.json to your email | 14:13 |
| pstolowski | niemeyer: got it, thanks | 14:18 |
| * zyga -> meal (unfair to call lunch now) | 14:19 | |
| ogra | linner (thats like an afternoon brunch) | 14:22 |
| ogra | (or lupper if you are british ;) ) | 14:23 |
| mvo | 5803 needs a second review please | 14:30 |
| pstolowski | mvo: looking | 14:33 |
| mup | PR snapcraft#2261 opened: build providers: inject the base for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2261> | 14:40 |
| mvo | thanks pstolowski | 14:56 |
| stevenm | hey what can I do about this stupid 'snap' directory in my $HOME | 15:20 |
| stevenm | it just sits there looking all very stupid and lowercase | 15:21 |
| stevenm | essentially out of place | 15:21 |
| stevenm | can I reconfigure so it is at least .snap or something? | 15:21 |
| popey | stevenm: not currently | 15:24 |
| zyga | stevenm: hey, we are working towards being able to move it but this is not possible yet | 15:29 |
| ogra | stevenm, echo "snap" >~/.hidden | 15:48 |
| ogra | stevenm, that will a least hide it from the file manager | 15:48 |
| ogra | (you might to re-login afterwards to make it take effect ... or restart nautilus or whatnot) | 15:49 |
| MattJ | >> rather? | 15:49 |
| zyga | niemeyer: gopkg.in /github are acting up again | 15:50 |
| ogra | MattJ, indeed, thats safer in case the file exists already (it rarely does though) | 15:50 |
| * cachio afk | 15:59 | |
| Dmitrii-Sh | hi, is there any specific list of people who should be @mentioned on the forum to get a review for a classic snap? | 15:59 |
| Chipaca | Dmitrii-Sh: not really, as long as it's followed the process it should be picked up | 16:00 |
| Chipaca | Dmitrii-Sh: why? | 16:00 |
| popey | Dmitrii-Sh: do link us to it, in case we missed it | 16:00 |
| Dmitrii-Sh | Chipaca, popey: https://forum.snapcraft.io/t/classic-confinement-review-request/7226/2 | 16:01 |
| Dmitrii-Sh | We're basically doing a rally + tempest snap for field engineering purposes | 16:01 |
| Dmitrii-Sh | popey, Chipaca: the classic side of it is there because of python multiprocessing | 16:01 |
| Dmitrii-Sh | SHM paths are inaccessible because of apparmor | 16:02 |
| Chipaca | Dmitrii-Sh: snaps have access to (namespaced) shm | 16:02 |
| ogra | isnt there @reviewers ? | 16:02 |
| popey | That's unfortunate | 16:02 |
| Dmitrii-Sh | Chipaca: yes, but python2 multiprocessing doesn't use that (the cpython lib itself) | 16:03 |
| popey | I see there's a suggestion to use a patched python. I don't know it well enough to know the impact of that | 16:03 |
| ogra | (to ping the review team) | 16:03 |
| Chipaca | ogra: yes, but it's rude to do so unless they've been dragging their feet :-) | 16:04 |
| Dmitrii-Sh | popey: the patch is not upstream yet. Do you suggest building cpython2 and adding that to the snap? | 16:04 |
| ogra | :) | 16:04 |
| Dmitrii-Sh | that'll take some time we do not have currently unless there is a well-defined path | 16:04 |
| pstolowski | pedronis: ok, i think i understand what happened with that issue that niemeyer hit | 16:05 |
| popey | Sorry, I don't know python enough. | 16:05 |
| Dmitrii-Sh | popey: I see that python3.4 has the right patch https://github.com/python/cpython/commit/e943697750a5828c0b4937ab28a301001700ad84 . The problem is that we have to stick to python2 for this snap as rally itself has some python3 support issues | 16:07 |
| ogra | just rewrite it in go ;) | 16:08 |
| Dmitrii-Sh | I tried to make it work and even patched it in the snap after pulling but during test runs some errors come up which do not on python2 | 16:08 |
| Dmitrii-Sh | hah! | 16:08 |
| Dmitrii-Sh | yes | 16:08 |
| ogra | :) | 16:08 |
| mvo | xnox: the fix for the env generator got reviews and we will land it as soon as github is back to being normal | 16:08 |
| * ogra always has the helpful comments ... especially after long workdays | 16:09 | |
| mvo | xnox: sorry for the delay, my plan was to get this done in my morning but then gitub exploded | 16:09 |
| xnox | ha | 16:09 |
| mup | PR snapd#5817 opened: snapstate/tests: serialize all appeneds in fake backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/5817> | 16:12 |
| Dmitrii-Sh | popey: I could move the repo under https://github.com/openstack-snaps and have it there for our specific use-case | 16:12 |
| pstolowski | mvo: ^ run it for 2 hours, 4 instances, didn't fail | 16:12 |
| pedronis | pstolowski: yes? | 16:18 |
| pstolowski | pedronis: it's two things: we're dealing with "old" state and injecting "auto-connect" task for gopkg from doLink() snap handler. but we also have "setup-profiles" with core-phase-2 for gopkg. it's arranged to be run after "link-snap" and "auto-connect". In the autoconnect conflict check we conflict with ourselves because of that setup-profiles phase 2. The message about conflict with core is bogus, it's just resulting | 16:23 |
| pstolowski | from iterating over candidates (and trusting that we don't conflict with own link/unlink/setupprofiles tasks) | 16:23 |
| pstolowski | normally we would never conflict with self because link-snap and setup-profiles run before auto-connect, so they are Done | 16:26 |
| pedronis | pstolowski: ah, is the old fallback logic for old snapd ? | 16:26 |
| pstolowski | pedronis: yes | 16:26 |
| pedronis | s/old/ first | 16:26 |
| pedronis | pstolowski: why do we have the 2nd setup-profiles for gopkg though? it's not a core | 16:28 |
| pstolowski | I guess I couldn't reproduce because I was running snapd from trunk | 16:28 |
| pstolowski | pedronis: yeah. https://paste.ubuntu.com/p/Bxd4sZyNJt/ | 16:29 |
| pstolowski | pedronis: and i see most (if not all) of the phase-2 logic is gone now | 16:29 |
| pstolowski | (but that's a side note) | 16:29 |
| pedronis | ah, this is dangerous ? | 16:30 |
| pstolowski | pedronis: yes | 16:30 |
| pedronis | that's why, old snapd didn't detect the type for dangerous | 16:30 |
| pstolowski | ah | 16:30 |
| pedronis | so the 2nd setup-profiles | 16:31 |
| pedronis | but i thought we would inject auto-connect from the 2nd setup-profile if there are two | 16:31 |
| pedronis | are we injecting auto-connect twice ? | 16:31 |
| pedronis | in that case | 16:31 |
| pstolowski | pedronis: no. we only inject from doLinkSnap (and we inject only if we see unlink-snap and setup-profiles in same change) | 16:33 |
| pstolowski | (and if we don't see auto-connect in the change already) | 16:34 |
| pedronis | pstolowski: yes, but the question is where we inject it if there are two setup-profiles ? | 16:34 |
| pedronis | after the first, after the 2nd ? | 16:34 |
| pedronis | the issue is that we inject after the first ? | 16:34 |
| pstolowski | pedronis: we always inject from doLinkSnap, after link-snap task (so, after first setup-profiles, but before 2nd setup-profiles) | 16:35 |
| pedronis | I see | 16:36 |
| pstolowski | we basically ignore the fact that there might be 2nd setup-profiles | 16:36 |
| pedronis | it's not the best placement | 16:36 |
| pedronis | for core or this corner case | 16:36 |
| pedronis | pstolowski: why can core finish though? | 16:36 |
| pedronis | it would have the same problem no? | 16:37 |
| pedronis | ah, because there's no old core tasks | 16:37 |
| pedronis | no | 16:37 |
| pedronis | mmh | 16:37 |
| pedronis | pstolowski: how does core itself avoid getting stuck ? | 16:37 |
| pstolowski | pedronis: that's a good question. i see everything is undone, so it's hard to say what happened. I only see repeated 'retry' messages on gopkg auto-connect task | 16:38 |
| pedronis | pstolowski: because core hits the find symmetric logic ? | 16:39 |
| pedronis | anyway | 16:39 |
| pstolowski | pedronis: for core i only get " "2018-09-11T09:21:48Z INFO Requested daemon restart.", | 16:39 |
| pstolowski | "2018-09-11T09:23:40Z INFO Requested daemon restart (undo classic initial core install)" | 16:39 |
| pstolowski | " | 16:39 |
| pstolowski | from link-snap | 16:39 |
| pstolowski | pedronis: right, probably that | 16:40 |
| pedronis | pstolowski: anyway, it seems we need to make the logic robust against self-blocking but we also need to rethink whether we can move where we put the auto-connect | 16:40 |
| pedronis | in these cases | 16:40 |
| pstolowski | pedronis: indeed, i'll work on the latter tomorrow morning | 16:43 |
| pstolowski | and probably conflict/retry messages should be tweaked to actually point at the real cause | 16:45 |
| === pstolowski is now known as pstolowski|afk | ||
| ijohnson | It seems like this is the case, but the github issue is what's affecting gopkg.in, correct? (I can't run snapd unit tests cause I need to update the dependencies, which fails on gopkg.in packages) | 16:55 |
| mvo | pstolowski|afk: nice one, thank you | 17:03 |
| Chipaca | $ snap list bofh | 17:08 |
| Chipaca | Name Version Rev Tracking Publisher Notes | 17:08 |
| Chipaca | bofh 0.1 1 latest chipaca - | 17:08 |
| Chipaca | WARNING: There are 1 new warnings. See 'snap warnings' | 17:08 |
| zyga | oh, my :) | 17:09 |
| Chipaca | and with that, I EOD | 17:09 |
| zyga | watch out Chipaca ;) | 17:09 |
| * zyga hugs Chipaca | 17:09 | |
| zyga | Chipaca: and ngettext :/ | 17:09 |
| Chipaca | obvs | 17:09 |
| mup | PR snapcraft#2260 closed: build providers: allow setting ram and disk size <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2260> | 17:18 |
| mup | PR snapcraft#2257 closed: meta: take charge of environment used to run commands <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2257> | 17:21 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/5818/files | 17:32 |
| mup | PR #5818: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818> | 17:32 |
| mup | PR snapd#5818 opened: cmd/snap: handle "snap interfaces core" better <Created by zyga> <https://github.com/snapcore/snapd/pull/5818> | 17:33 |
| mup | PR snapd#5810 closed: rfc: restore "core" as the API-level host for implicit slots <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5810> | 17:37 |
| xnox | mvo, hey | 18:06 |
| xnox | mvo, i think implementing that generator in C is all nice and dandy | 18:06 |
| xnox | mvo, but clearly no worky | 18:06 |
| xnox | mvo, my examples are were in shell..... and i'm got tricked by this | 18:07 |
| xnox | # unset PATH; echo $PATH; echo ${PATH}; /bin/sh -c 'echo ${PATH}' | 18:08 |
| mup | PR snapcraft#2262 opened: schema: add "legacy" adapter type <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2262> | 19:34 |
| xnox | mvo, so i think we need to make generator to print nothing if PATH is not set | 19:36 |
| xnox | mvo, cause otherwise it cleans it. | 19:36 |
| xnox | mvo, /bin/sh has a built-in PATH which may or may not be right ( https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1792004 ) | 19:37 |
| mup | Bug #1792004: built-in PATH seems to have sbin and bin out of order; and inconsistent <apt (Ubuntu):New> <bash (Ubuntu):New> <busybox (Ubuntu):New> <dash (Ubuntu):New> <dpkg (Ubuntu):New> <pam (Ubuntu):New> <systemd (Ubuntu):New> <bash (Debian):Unknown> <https://launchpad.net/bugs/1792004> | 19:37 |
| xnox | mvo, and i.e. built-in paths are broken in /bin/sh on e.g. suse. | 19:37 |
| xnox | mvo, and i need to fix systemd, to pass manager->environmnet and call envrionment generators with execve rather than just execv | 19:37 |
| mvo | xnox: ok, thats fine | 19:59 |
| mvo | xnox: so the advice is - no PATH if path is unset? thats also not ideal because then the aim of the generator is not reached | 20:00 |
| mvo | xnox: shouldn't we make it use a default path in that case (maybe the one from /etc/environment)? but I guess the problem is then that not all distros agree on the default path | 20:00 |
| mup | PR snapcraft#2261 closed: build providers: inject the base for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2261> | 20:01 |
| mvo | xnox: anyway, this is a can of worms, I guess the safest option for now is to not print anything is PATH is unset and wait until the dust settles. but I need to call it a day, lets talk tomorrow | 20:06 |
| xnox | mvo, yeah, talk tomorrow | 20:08 |
| xnox | mvo, i hope to fix systemd.... | 20:09 |
| mvo | xnox: so the plan is: fix systemd, until then our generator just does nothing on an unset path? | 20:09 |
| xnox | mvo, yeap | 20:09 |
| mvo | xnox: sounds good to me | 20:09 |
| mvo | xnox: is there a open systemd bug that I can refer to in my commit? | 20:11 |
| xnox | mvo, not yet | 20:16 |
| mvo | xnox: ok, I updated the pending PR with the suggested fix (to print nothing) we can sync up further tomorrow but that should fix the worst damage and on non-lxd systems things should be improving with that | 20:19 |
| mvo | xnox: but need to gtg now, see you tomorrow | 20:19 |
| xnox | hahahhaha | 20:19 |
| xnox | * mvo has quit (Quit: Ex-Chat) | 20:19 |
| xnox | * smoser (~smoser@23.28.108.176) has joined #snappy | 20:19 |
| smoser | :-( | 20:19 |
| xnox | just missed him | 20:19 |
| NickZ | kyrofa: hey, we are using snaps in production now and all of our backend is snapped and is being orchestrated through juju | 21:58 |
| kyrofa | NickZ, hey, that's amazing! | 23:27 |
| kyrofa | Sounds like case-study material! | 23:28 |
| NickZ | kyrofa: yeah, we'd be down for that when we launch | 23:30 |
| NickZ | snapcraft is still missing a few features that I'd like to see, like being able to run daemons as an unprivileged user, and granular network permissions; I know that the former is on the roadmap | 23:36 |
| NickZ | the latter seems to be blocked by this very old bug in apparmor: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588 | 23:37 |
| mup | Bug #796588: Fine-grained network mediation <aa-feature> <aa-kernel> <kernel-net> <AppArmor:In Progress> <apparmor (Ubuntu):Triaged> <linux (Ubuntu):Triaged> <https://launchpad.net/bugs/796588> | 23:37 |
| mup | PR snapd#5815 closed: client: catch and expose logs errors <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5815> | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!