| === kalikiana_ is now known as kalikiana | ||
| === zyga_ is now known as zyga | ||
| === cmagina_ is now known as cmagina | ||
| === tai271828_ is now known as tai271828 | ||
| === TinoGuest_ is now known as TinoGuest | ||
| === victorbjelkholm_ is now known as victorbjelkholm | ||
| === pstolowski|afk_ is now known as pstolowski|afk | ||
| === mwhudson is now known as Guest96057 | ||
| === Guest96057 is now known as mwhudson | ||
| === erio|away is now known as erio | ||
| === prime is now known as Guest2033 | ||
| zyga | good morning | 04:58 |
|---|---|---|
| mborzecki | morning | 05:14 |
| zyga | hey | 05:20 |
| mborzecki | zyga: anything on fire today? | 05:21 |
| zyga | nothing apart from my joints | 05:25 |
| zyga | everything hurts as if I had a flu | 05:25 |
| zyga | there's one bug about apparmor but it looks like partial removal of snapd | 05:25 |
| mborzecki | your joints hmm? :) | 05:25 |
| mborzecki | zyga: #177351 ? | 05:27 |
| mup | Bug #177351: evince crashed with SIGSEGV in CairoOutputDev::setCairo() <apport-crash> <evince (Ubuntu):Invalid by desktop-bugs> <https://launchpad.net/bugs/177351> | 05:27 |
| mborzecki | damn, not that one, this one #1773515? | 05:27 |
| mup | Bug #1773515: apparmor fails after removal of snapd <snapd (Ubuntu):New> <https://launchpad.net/bugs/1773515> | 05:28 |
| zyga | mborzecki: yeah, that one | 05:43 |
| zyga | drat | 05:44 |
| zyga | I made an appointment today to replace my phone battery at a service centre | 05:44 |
| zyga | sigh | 05:44 |
| zyga | what a day | 05:44 |
| zyga | well, ok, it's at 10:00 AM, close by, I can just go and work from some place nearby | 05:44 |
| zyga | I will just login home and work this way | 05:45 |
| zyga | I updated to bionic yesterday to have more recent autopkgtest | 05:45 |
| zyga | I find the whole image construction toolkit super fragile | 05:45 |
| zyga | it times out, doesn't say what's going on, etc | 05:45 |
| zyga | I’m going to the service center now | 06:13 |
| zyga | I will install myself there and just work | 06:13 |
| zyga | ETA 30 minutes | 06:13 |
| zyga | I’m close now but man, committing at this time is not fun | 06:24 |
| zyga | re :) | 06:46 |
| zyga | I'm at a starbucks exactly in front of the service center, time to work | 06:47 |
| zyga | mborzecki: mvo will be around later today | 06:47 |
| mborzecki | ok | 06:47 |
| zyga | mborzecki: can you please look at #5231 | 06:49 |
| mup | PR #5231: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5231> | 06:49 |
| zyga | we need to cherry pick it into the release branch as well | 06:49 |
| mborzecki | zyga: to recap, this is to have the device cgroup created always, using a device (/dev/full) that we're sure is present at all times, right? | 06:50 |
| zyga | yes, almost, | 06:50 |
| zyga | we don't make device cgroups unless there's a device tagged with an udev tag that matches the app we're running | 06:51 |
| mborzecki | btw. reading systemd-environment-generators manpages, it's a nice feature of systemd | 06:51 |
| zyga | and if you give broad apparmor permissions (like all of input devices here) | 06:51 |
| zyga | and not tag any dveices | 06:51 |
| mborzecki | yup | 06:51 |
| zyga | then there's no cgroup and you can do anything you want | 06:51 |
| zyga | mborzecki: I know, I talked to zbyszek about it about a year ago when I was trying to figure out how to inject /snap/bin into PATH in a nicer way than we did before | 06:52 |
| zyga | he suggested environment generators but they were not merged back then :) | 06:52 |
| mborzecki | zyga: any idea how far back in systemd versions this feature is available? | 06:52 |
| zyga | it's very recent | 06:52 |
| zyga | this is why I made a remark about it on the PR | 06:53 |
| zyga | I don't know how we plan to use it across the released versions of systemd people are using | 06:53 |
| mborzecki | zyga: why not just always create the device cgroup? i see in the code that we're adding a bunch of static devices iff there are any (other) devices tagged for particular snap | 07:01 |
| zyga | that's my feedback as well | 07:01 |
| mborzecki | oh and i see nvidia ... | 07:01 |
| zyga | nvidia is a special snowflake because they cannot use GPL symbols and udev | 07:01 |
| mborzecki | zyga: there's a chance that device group by default may break some snaps | 07:04 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:04 |
| mborzecki | or at least that's my guess why jdstrand didn't go down this path | 07:05 |
| mborzecki | pstolowski: hey | 07:05 |
| zyga | hey pawel | 07:05 |
| zyga | mborzecki: note that nvidia works with udev tagged devices today | 07:05 |
| zyga | we have special code for taht | 07:05 |
| zyga | in my review I gave a +1 but indicated that we should probably not make mistakes again by simply always doing a cgroup anyway | 07:06 |
| mup | PR snapd#5227 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5227> | 07:07 |
| mup | PR snapd#5228 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors (2.33) <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5228> | 07:07 |
| pedronis | pstolowski: hi, should we chat again? | 07:10 |
| pedronis | zyga: tagging short udev related PRs with "simple" is a bit misleading I think | 07:12 |
| zyga | because it's udev? | 07:12 |
| pedronis | because reviewing quickly to means I should not need to be on alert for subtle issues | 07:14 |
| pedronis | by definition a PR that solves a subtle issue cannot be quick to review | 07:14 |
| mborzecki | zyga: maybe i'll play a bit with that change to snap-confine later today | 07:15 |
| pedronis | zyga: same for the new interface PR | 07:15 |
| zyga | but the issue is very clearly stated there | 07:15 |
| zyga | pedronis: the ones about sensors? | 07:15 |
| pedronis | any of them | 07:16 |
| pedronis | again I don't think they can be simple | 07:16 |
| pstolowski | pedronis: probably, but give me a few moments to collect thoughts | 07:16 |
| pedronis | zyga: you invented the label, but if I need to read the description carefully | 07:16 |
| pedronis | it is also not simple | 07:16 |
| pedronis | zyga: simple is something that can be reviewed before coffee | 07:16 |
| pedronis | otherwise is just a trap | 07:17 |
| pedronis | of mindless +1 | 07:17 |
| zyga | mmm, | 07:17 |
| pedronis | and we should remove the label | 07:17 |
| zyga | I'll apply more restraint | 07:17 |
| zyga | there's certainly the case that everyone is familiar with a specific part of the code more closely | 07:17 |
| zyga | and indeed then the label can be deceptive | 07:17 |
| pedronis | ok, then again it cannot be simple | 07:17 |
| pedronis | (because everybody sees the label) | 07:18 |
| zyga | pedronis: some quick feedback on #5221 | 07:21 |
| mup | PR #5221: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221> | 07:21 |
| Chipaca | pedronis: WDYT of adding a "mounted-from" key to snaps' json, and have that be the EvalSymlinks of the MountFile of all snaps? | 07:22 |
| pedronis | Chipaca: seems ok to me | 07:24 |
| Chipaca | k, i'll push a pr for that soonish | 07:24 |
| pedronis | zyga: I'm sort of tempted to kill the label completely tbh, the fact we don't agree how it should be used it's probaly a sign is a nuisance | 07:27 |
| zyga | pedronis: I'd like to keep the label because it's an encouragement to look at PRs | 07:28 |
| zyga | we should just agree how to use it | 07:28 |
| pstolowski | pedronis: ok, i'm ready when you're | 07:30 |
| mup | PR snapd#5232 opened: interfaces/builltin/tpm: Allow access to the kernel resource manager <Created by yphus> <https://github.com/snapcore/snapd/pull/5232> | 07:30 |
| * zyga notices a ~2K lines changed PR and wonders if 30 minutes is enough time to even look | 07:30 | |
| pedronis | which one? | 07:31 |
| pedronis | pstolowski: joining | 07:32 |
| zyga | spineau: hey, do you have any links about what the TPM resource manager is for? | 07:34 |
| spineau | zyga: I'm collecting them right now | 07:35 |
| zyga | thanks | 07:35 |
| zyga | please add them to the PR | 07:35 |
| mup | PR snapd#5231 closed: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5231> | 07:35 |
| zyga | popey_: https://forum.snapcraft.io/t/is-the-author-of-a-package-verified/5671 | 07:51 |
| zyga | something that well deserves a good answer | 07:51 |
| zyga | ok | 07:54 |
| zyga | Son_Goku: hey | 07:54 |
| * zyga needs to go to the service center | 07:55 | |
| zyga | Son_Goku: please review your PRs, there's feedback and patches but we cannot push to your branch | 07:55 |
| * Son_Goku waves at zyga | 07:55 | |
| Son_Goku | I pushed the patch requested | 07:55 |
| * zyga goes to replace his phone battery now | 07:55 | |
| zyga | ttyl | 07:55 |
| zyga | thanks! I'll check soon | 07:55 |
| mborzecki | Son_Goku: hey, left you a link to a patch that fixes media-sharing in opensuse pr | 07:55 |
| Son_Goku | mborzecki: done already | 07:55 |
| Son_Goku | now we wait forever for spread :D | 07:55 |
| mborzecki | hehe :) | 07:56 |
| mborzecki | forever as in ~30 minutes | 07:56 |
| mup | PR snapd#5233 opened: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <https://github.com/snapcore/snapd/pull/5233> | 08:10 |
| zyga | re | 08:24 |
| zyga | my phone should have a brand new battery by noon | 08:24 |
| zyga | mvo: hey, welcome back | 08:25 |
| mvo | zyga: hello | 08:26 |
| Chipaca | mvo: you're not under water are you? | 08:27 |
| mvo | Chipaca: no, all good | 08:27 |
| Chipaca | mvo: throw one bubble for yes, two bubbles for no | 08:28 |
| * Son_Goku throws three bubbles at Chipaca | 08:29 | |
| * Chipaca starts selling a dragon-based arcade game remake reusing Son_Goku's bubbles | 08:29 | |
| Son_Goku | :D | 08:29 |
| Son_Goku | ahh Spyro :) | 08:30 |
| Chipaca | bubble bobble, you uncultured yob | 08:30 |
| * Chipaca removes his monacle | 08:31 | |
| Chipaca | that thing's evil | 08:31 |
| * zyga wonders what is going on | 08:33 | |
| Chipaca | zyga: an area in the west of germany (but a few km from mvo) is under water | 08:34 |
| zyga | spineau: feedback on your PR | 08:34 |
| Chipaca | zyga: also bubble bobble is a game with dragons that throw bubbles and that makes no sense | 08:35 |
| zyga | Chipaca: because dragons make sense ;-) ? | 08:35 |
| Chipaca | zyga: about as much sense as unicorns | 08:36 |
| Son_Goku | :D | 08:36 |
| * zyga sings "narwhals" | 08:36 | |
| spineau | zyga: thx, I was wondering which one caused the error | 08:36 |
| mvo | Chipaca: yeah, some heavy rain here in the area but where I am its mostly fine | 08:36 |
| * zyga just moved further away from the window becase OMG SO HOT today | 08:36 | |
| zyga | it's weird not to have one's phone around | 08:37 |
| pstolowski | pedronis: ok, i think i nailed the conflict check.. at least the tests seem happy | 08:37 |
| zyga | it's the most important thing to bring in many ways | 08:37 |
| mborzecki | 29C in the shade here | 08:37 |
| mborzecki | zyga: do you want one last look at #5219 ? | 08:37 |
| mup | PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219> | 08:37 |
| zyga | yep, looking | 08:38 |
| pedronis | fun fact, the man page of mount uses both "file system" and "filesystem" at the same time | 08:38 |
| Son_Goku | that's... annoying | 08:39 |
| pedronis | well to be fair, the former only a few times | 08:39 |
| zyga | mborzecki: one question on this https://github.com/snapcore/snapd/pull/5219#discussion_r191685550 | 08:39 |
| mup | PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219> | 08:39 |
| zyga | mborzecki, Pharaoh_Atem do you know what's the tumbleweed version in the RPM macro? | 08:41 |
| zyga | I'm AFK from my home machine to check | 08:41 |
| mborzecki | Son_Goku: there's some fine print note about tumbleweed version right here: https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macros | 08:41 |
| zyga | I mean, it's 1555 | 08:41 |
| mborzecki | zyga: ^^ | 08:41 |
| zyga | but what will happen later | 08:41 |
| zyga | I know, I read that :) | 08:41 |
| zyga | sorry, my question on the PR was worder better than my question here | 08:41 |
| Son_Goku | you can't not rely on it in some fashion | 08:42 |
| zyga | right but I'm trying to guess if the next leap will have all the features we target for tumbleweed today | 08:42 |
| zyga | if so that's even better | 08:42 |
| Son_Goku | but basically if you use it as a checkpoint (that is, don't do 0%{?suse_version} == 1550), you're fine | 08:42 |
| Son_Goku | zyga, well, Leap is branched from Factory | 08:42 |
| Son_Goku | err, SLE is branched from Factory | 08:43 |
| Son_Goku | and Leap is cloned from SLE | 08:43 |
| zyga | and tumble? | 08:43 |
| Son_Goku | and Tumbleweed is regular snapshots of Factory | 08:43 |
| mborzecki | we should be good with >= check then | 08:43 |
| Son_Goku | yes | 08:44 |
| Son_Goku | SUSE has made version checking harder than it should be :/ | 08:44 |
| zyga | +1 then, let's mere it | 08:44 |
| mborzecki | aaand merge | 08:44 |
| mborzecki | (d) | 08:44 |
| Son_Goku | ugh | 08:45 |
| Son_Goku | I hate touching openSUSE packaging sometimes | 08:45 |
| jamesh | mvo: any chance you could approve the two new revisions of the test-snapd-eds snap? (this is just changing interface names based on the review) | 08:45 |
| mborzecki | zyga: do you plan to sync the spec in obs? | 08:45 |
| mup | PR snapd#5219 closed: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5219> | 08:45 |
| zyga | mborzecki: yes but only for the next release | 08:45 |
| mborzecki | zyga: ack | 08:45 |
| mvo | jamesh: sure, let me do that right away | 08:45 |
| jamesh | mvo: thank you! | 08:45 |
| Son_Goku | zyga, don't forget to merge my changes entry into the OBS changes file | 08:45 |
| zyga | .33 is branched, once we are good for release we should do it in OBS as well | 08:45 |
| zyga | Son_Goku: ack | 08:46 |
| mup | PR snapd#5234 opened: [RFC] snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234> | 08:46 |
| Son_Goku | I guess since I'm up already and looking at this | 08:46 |
| Son_Goku | might as well add the %bcond to create the /snap symlink in the spec for amazon linux in the fedora spec | 08:47 |
| Chipaca | May 30 08:17:56 arch snapd[10146]: 2018/05/30 08:17:56.829601 helpers.go:521: cannot retrieve info for snap "test-snapd-content-slot": cannot find installed snap "test-snapd-content-slot" at revision 2: missing file /var/lib/snapd/snap/test-snapd-content-slot/2/meta/snap.yaml | 08:47 |
| Chipaca | who was looking into the disappearing meta/snap.yaml bug? | 08:48 |
| Chipaca | zyga: was that you? | 08:48 |
| zyga | Chipaca: that was perdronis and to a small extent me | 08:48 |
| zyga | is that on your system or in spread? | 08:48 |
| Chipaca | https://api.travis-ci.org/v3/job/385570236/log.txt | 08:48 |
| Chipaca | was wondering whether I should keep that, or just blow it away and retry | 08:49 |
| zyga | hmmm | 08:49 |
| zyga | I'd be much happier from a user report, our tests do so much magic I don't trust some of those failures | 08:49 |
| zyga | - Mount snap "test-snapd-content-slot" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount failed. | 08:50 |
| zyga | mount failed | 08:50 |
| * zyga looks for the journal error | 08:50 | |
| mborzecki | Son_Goku: why the dislike for opensuse packaging? | 08:51 |
| zyga | it timed out https://www.irccloud.com/pastebin/5xyF1sNO/ | 08:51 |
| zyga | Chipaca: interesting, I wonder why it can ever do that | 08:51 |
| Son_Goku | mborzecki, I don't generally have a problem with openSUSE packaging as a whole | 08:51 |
| * zyga scans the log for more clues | 08:51 | |
| Son_Goku | I actually do quite a lot of it these days | 08:51 |
| Son_Goku | but one thing that has annoyed me a lot is that figuring out how to detect what release I'm targeting for a build has become a ton more difficult | 08:51 |
| zyga | woah | 08:51 |
| zyga | protocol error again :) https://www.irccloud.com/pastebin/DNFrcteJ/ | 08:52 |
| Chipaca | zyga: whassat | 08:52 |
| zyga | Chipaca: so, at this stage I'm tempted to get to the bottom of the stack to see what the hell is a protocol error | 08:52 |
| zyga | is that kernel doing barf | 08:52 |
| zyga | systemd doing barf | 08:52 |
| zyga | or something else | 08:52 |
| Chipaca | zyga: if it were the kernel wouldn't something in the journal say so? | 08:52 |
| mborzecki | Son_Goku: heh, that version macros matrix is a bit confusing | 08:52 |
| zyga | Chipaca: because the kernel is known for its impeccable error reporting | 08:52 |
| zyga | ;-) | 08:53 |
| zyga | Chipaca: I wonder if there's some logging going on that we don't show | 08:53 |
| zyga | e.g. stuff in dmesg that doesn't end up in the journal | 08:53 |
| zyga | May 30 08:18:01 arch snapd[10146]: May 30 08:17:59 arch kernel: print_req_error: I/O error, dev loop2, sector 0 | 08:53 |
| Chipaca | there shouldn't be, but ¯\_(ツ)_/¯ | 08:53 |
| zyga | ooh | 08:53 |
| zyga | is our snap corrupt? | 08:53 |
| zyga | that is building and installing the snap in devmode | 08:54 |
| zyga | so we send the snap over a socket | 08:54 |
| zyga | maybe there's a race and we get garbage | 08:54 |
| zyga | Chipaca: how would you feel if we added CRC to side-loaded snaps | 08:54 |
| zyga | for transfer | 08:54 |
| zyga | client and server both compute on the fly | 08:55 |
| zyga | and then the client sends at the end | 08:55 |
| zyga | mm? | 08:55 |
| zyga | more IO errors https://www.irccloud.com/pastebin/lx013vGf/ | 08:55 |
| Chipaca | zyga: if we were looking to do work in that area, I'd look instead at passing a file descriptor | 08:55 |
| zyga | but look, loop1 and loop2 | 08:55 |
| zyga | I wonder what's going on there | 08:55 |
| zyga | I wonder if this is "I cannot read the loop device" | 08:55 |
| sil2100 | mvo: hey! I have a hacky branch that fixes running travis CI on core18 (and non-bionic systems) | 08:56 |
| zyga | or "I read the loop device but man this is not a valid squashfs" | 08:56 |
| sil2100 | mvo: (the CI is failing for it as there are actual failures in the tests now) | 08:56 |
| Chipaca | zyga: what happens if you grab a squashfs, truncate it, and mount it | 08:56 |
| sil2100 | mvo: it's ugly, but besides being ugly currently it shouldn't have any real side-effects | 08:56 |
| Chipaca | zyga: truncate it by a half or sth i mean, not empty | 08:56 |
| zyga | hold on | 08:56 |
| zyga | Chipaca: this is not a side-load | 08:57 |
| zyga | it's from the store | 08:57 |
| zyga | and we apply a delta | 08:57 |
| zyga | it's a delta https://www.irccloud.com/pastebin/6kcddRIr/ | 08:57 |
| zyga | ah, no | 08:57 |
| zyga | I'm blind sorry | 08:57 |
| zyga | it's not a delta | 08:57 |
| zyga | it's a store pull | 08:57 |
| zyga | we check store assertions that they match the downloaded blob, right? | 08:57 |
| Chipaca | zyga: yes | 08:59 |
| zyga | hmm hmm hmm | 08:59 |
| pedronis | yes, that's what validate-snap does | 08:59 |
| zyga | so we have a valid snap | 08:59 |
| zyga | yet the kernel chokes on mounting it | 08:59 |
| zyga | but one out of 100s we tested | 08:59 |
| zyga | and randomly | 08:59 |
| Chipaca | zyga: and if it were a delta, we hashsum the chunks, and then hashsum the resulting squash after applying the delta | 08:59 |
| zyga | because of the validate I don't think the snap is corrput | 09:00 |
| zyga | more like a rare bug in loop devices | 09:00 |
| pedronis | the store doesn't try to mount it though | 09:00 |
| zyga | but this is just guessing | 09:00 |
| pedronis | it should resquash it | 09:00 |
| pedronis | and compare | 09:00 |
| zyga | pedronis: yes but here it's one of the snaps we test dozens of time a day | 09:00 |
| zyga | I bet if the blob arrived safely it is not the content that is at fault | 09:01 |
| zyga | we don't change that snap often | 09:01 |
| zyga | and it mounted and worked fine on all the other tests | 09:01 |
| zyga | (in the same run) | 09:01 |
| Chipaca | zyga: i'm about to hit restart on the test unless you shout | 09:01 |
| mvo | zyga: it might be that the network data is fine but it got corrupted while writing to disk | 09:01 |
| zyga | go | 09:01 |
| zyga | restart | 09:01 |
| zyga | mvo: mmmm, yes, perhaps | 09:01 |
| zyga | mvo: that's interesting | 09:02 |
| zyga | maybe google SSDs are just not what they used to be | 09:02 |
| pedronis | mvo: well we check it again in validate-snap | 09:02 |
| zyga | and once in blue moon we will hit this one bit flip | 09:02 |
| pedronis | but the pastebin doesn't have that bit | 09:02 |
| mborzecki | zyga: there's your failed with result protocol: https://github.com/systemd/systemd/blob/5300857701ff5e87169f3c90c6b570c750379dfb/src/core/mount.c#L1286 | 09:02 |
| mvo | pedronis: right if we read it again from disk, then my theory is bogus | 09:02 |
| zyga | mborzecki: interesting, thank you | 09:03 |
| zyga | mvo, pedronis: unless for whatever reason the kernel gives us some page cache but the loop device tries to read it from somewhere else | 09:03 |
| zyga | I don't know how the caching is layered in the kernel | 09:03 |
| zyga | that is, from userspace the file is ok | 09:03 |
| mborzecki | /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded | 09:04 |
| zyga | but from the loop device's point of view the blocks don't use the same page cache that userspace reading the file is | 09:04 |
| mborzecki | * before we process the SIGCHLD for the mount command. */ | 09:04 |
| mborzecki | heh, nice comment ^^ | 09:04 |
| zyga | mborzecki: yes :) | 09:04 |
| zyga | we also have our own code that goes and check _iff_ the mount was succcesful | 09:04 |
| zyga | but here it would not have a chance to run | 09:05 |
| zyga | if that systemd code is broken | 09:05 |
| mborzecki | right | 09:05 |
| zyga | and the mount really worked | 09:05 |
| zyga | but systemd thinks it did not | 09:05 |
| mborzecki | note that arch has a quite recent kernel | 09:05 |
| zyga | we could add some code to check for that condition | 09:05 |
| zyga | I wonder if we have enough data to see if this happens on a specific kernel more often | 09:05 |
| zyga | or if it's just all over the place but infrequent | 09:05 |
| zyga | I'll write down what I know so far on the forum | 09:06 |
| mborzecki | zyga: was it seen on ubuntu and fedora? | 09:06 |
| zyga | and let's keep watching this | 09:06 |
| zyga | mborzecki: I don't remember | 09:06 |
| pedronis | pstolowski: cool, let me know when I should re-review | 09:06 |
| zyga | I think it was | 09:06 |
| mborzecki | fedora should be running recent kernels too, so if it's related to recent(ish) kernels it should pop up there too | 09:07 |
| * Chipaca toddles off to do physio | 09:11 | |
| Son_Goku | Fedora shipped 4.16.x to all stable releases a few weeks ago | 09:13 |
| Son_Goku | mborzecki, btw, here's my proposed addition to the fedora spec for amazon linux 2: https://github.com/Conan-Kudo/snapd/commit/cb60c53c4c005de8f67dd3095faccde4daf2f518 | 09:13 |
| Son_Goku | I'd actually probably prefer not to support classic snaps for amazon linux 2, because then once I bring snapd into epel, the experience would be consistent across the board | 09:14 |
| Son_Goku | and people can just install snapd from EPEL once I'm happy with the experience and we push it there | 09:14 |
| zyga | mborzecki: https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682 | 09:15 |
| mborzecki | Son_Goku: thanks! i'll look into it, but have to figure out what's the current plan for amzn2 first | 09:15 |
| zyga | that's what I know | 09:15 |
| zyga | please extend that thread | 09:15 |
| Son_Goku | mborzecki: that's why it's not proposed as a PR ;) | 09:15 |
| Son_Goku | mborzecki, but that gives you an idea of how easy it is to extend for more distros | 09:15 |
| zyga | Chipaca: ^ | 09:16 |
| mup | PR snapd#5223 closed: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223> | 09:31 |
| pstolowski | pedronis: pushed | 09:32 |
| pedronis | pstolowski: will look in a litte bit, finishing the forum topic I promised | 09:33 |
| * zyga goes to pick up his phone | 09:35 | |
| popey_ | zyga: thanks for the ping earlier | 09:45 |
| === popey_ is now known as popey | ||
| zyga | popey: pleasure | 09:56 |
| * zyga is picking up his phone and heads home | 09:56 | |
| * thresh just pushed a new stable vlc | 10:05 | |
| thresh | many thanks everyone involved in fixing bugs :-) | 10:05 |
| mvo | thresh: thank you for the new vlc! | 10:06 |
| pedronis | pstolowski: did another pass | 10:16 |
| pstolowski | pedronis: thanks, looking | 10:17 |
| === chihchun_afk is now known as chihchun | ||
| mvo | pedronis: is the cumbersome/fragile bit in 5217 that it does not use the model assertion in SetNextBoot? or is there more to it? | 10:33 |
| zyga | re | 10:34 |
| zyga | phone with new battery, I can take a shower and get back to work | 10:35 |
| pedronis | mvo: it should check if the snap is the device base (using some helper) | 10:36 |
| mvo | pedronis: ok, this is what I read from your review. so snapstate will grow a way to get the model and pass it to the backend | 10:37 |
| sil2100 | mvo: I will be picking up making sure systemctl --failed is clean now if anything o/ I see there's one service failed there still so I'll get to it today | 10:37 |
| mvo | sil2100: thank you | 10:38 |
| mvo | sil2100: I will look at your UID pr after lunch | 10:38 |
| sil2100 | mvo: if you have a moment there are 3 PRs for review, but no haste with that ones | 10:38 |
| sil2100 | s/ones// | 10:38 |
| sil2100 | The travis one is ugly, but it does its job at least | 10:39 |
| mup | PR snapd#5233 closed: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5233> | 10:48 |
| cachio_ | mvo, hey | 11:10 |
| mvo | cachio_: hey | 11:15 |
| cachio_ | mvo, about the reboot issue | 11:15 |
| cachio_ | I think it is ok the reboot | 11:16 |
| cachio_ | the test is forcing a auto refresh | 11:16 |
| cachio_ | and there is a new kernel snap in stable | 11:16 |
| cachio_ | so, the reboot happens after the kernel snap is installed | 11:16 |
| cachio_ | the same happens when the revert test is executed | 11:17 |
| cachio_ | mvo, I still don't understand why it was not happening before | 11:17 |
| cachio_ | mvo, any ideas? | 11:18 |
| mvo | cachio_: maybe pure luck, if before the stable kernel in the image and the store was the same? | 11:21 |
| cachio_ | mvo, this is my guess too | 11:21 |
| cachio_ | I am not sure, but probably there was not any new kernel snap | 11:21 |
| cachio_ | in stable channel | 11:22 |
| * mvo nods | 11:22 | |
| cachio_ | mvo, I am testing a change to skip refreshing the kernel snap | 11:24 |
| cachio_ | mvo I'll create a PR soon | 11:24 |
| === niemeyer_ is now known as niemeyer | ||
| jdstrand | zyga, mborzecki (cc mvo): I think we should add the device cgroup by default now. it *shouldn't* break snaps since we are applying it in many places, *but* I think that is too risky to jam into 2.33 right before release. the code change would be small, but I'd like a full cycle or so to make sure | 11:43 |
| zyga | jdstrand: ack | 11:43 |
| jdstrand | zyga, mborzecki (cc mvo): so I did it this way. I'll prepare another PR for master that does that after I do the PR for the spread test | 11:44 |
| mborzecki | jdstrand: good idea, aiming for 2.34 then? | 11:45 |
| jdstrand | mborzecki: yes | 11:45 |
| mborzecki | ok | 11:45 |
| jdstrand | I'll also comment in the PR | 11:45 |
| jdstrand | I'll prepare the 2.33 PR for 'full' now | 11:47 |
| pedronis | pstolowski: mvo: would like if could do a first reading of https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685 , as first even before the merits, knowning whether the explanations are understable etc, you have both written/touched code discussed there | 11:53 |
| pstolowski | pedronis: thanks, will do! | 11:54 |
| pedronis | thx | 11:55 |
| niemeyer | o/ | 11:56 |
| pstolowski | pedronis: i've addressed your review comments; note, i made on check stricter than before | 11:57 |
| pstolowski | hello niemeyer! | 11:58 |
| niemeyer | Heya | 11:59 |
| zyga | hey gustavo! | 11:59 |
| mvo | pedronis: sure, reading | 12:01 |
| mborzecki | off to pick up the kids | 12:03 |
| cachio_ | mvo, well, I know why it is happening, I changed the test code to restart the device once the core is installed | 12:09 |
| cachio_ | the core from beta | 12:09 |
| cachio_ | but in parallel there is an auto-refresh for the pc-kernel | 12:09 |
| cachio_ | so I should wait until this task is finished to reboot the device | 12:10 |
| Jonas_ | Hi, we are doing a proof-of-concept for a customer using ubuntu-core and snap. We have to mount and unmount cifs shares with our daemon. In strict mode mount works, but umount does not. What would be the best way to be able to do this? As I understood we cannot use the docker-support interface (which grants many permissions) as only the Docker project is allowed to do so. | 12:31 |
| ogra_ | $ snap refresh core --stable | 12:31 |
| ogra_ | 2018-05-30T14:23:27+02:00 INFO Waiting for restart... | 12:31 |
| ogra_ | core 16-2.32.8 from 'canonical' refreshed | 12:31 |
| ogra_ | pedronis, ^^^thats on a classic system, shoujld it really talk about "restart" there ? | 12:32 |
| pedronis | ogra_: it's the restart of snapd itself | 12:33 |
| ogra_ | sure, still a confusing message IMHO | 12:33 |
| ogra_ | "Waiting for snapd restart..." would be a lot clearer | 12:33 |
| pstolowski | niemeyer: can you take a look at https://github.com/snapcore/snapd/pull/5162 ? that would unblock another of my PRs | 12:34 |
| mup | PR #5162: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162> | 12:34 |
| sergiusens | good morning | 12:44 |
| sergiusens | diddledan: hey, when you have time, a misdirected gimp support request https://bugs.launchpad.net/snapcraft/+bug/1773797 | 12:44 |
| mup | Bug #1773797: gimp snap app crashes <crashe> <gimp> <lubuntu> <Snapcraft:New> <https://launchpad.net/bugs/1773797> | 12:44 |
| mborzecki | ogra_: can you check which package /etc/X11/Xsession.d/65snappy comes from? it's not listed here https://packages.ubuntu.com/bionic/amd64/snapd/filelist makes me wonder if this was perhaps shipped by older versions of snapd | 12:45 |
| zyga | Jonas_: hey, can you please give me more details about the mount/umount issue | 12:50 |
| zyga | Jonas_: the best way forward, in general, would be to open a forum thread with the basic requirements (we need to mount/umount cifs) and to indicate if this should be seen only inside your snap or also in the rest of the system | 12:51 |
| Jonas_ | I was thinking about adding an interface supporting only mount/umount cifs but if I understood correctly it is not possible to add interfaces to ubuntu-core easily. One has to fork snapd and open a pull request into the core, right? | 12:51 |
| zyga | based on those requirement and the follow-up discussion we would probably design a new interface | 12:51 |
| Jonas_ | it should only be seen inside our snap | 12:52 |
| Jonas_ | ok I will open a forum post | 12:52 |
| zyga | Jonas_: we could come up with the code ourselves once the requirements are known | 12:52 |
| zyga | Jonas_: yes, to add a new interface you need to alter snapd source code | 12:52 |
| Jonas_ | ok great, I can also try to write a suggestion, as it is in go and the daemon we write is in go as well | 12:52 |
| niemeyer | pstolowski: Will do! | 12:53 |
| ogra_ | mborzecki, added to the forum thread already | 12:54 |
| ogra_ | mborzecki, it might have been dropped when we switched to wayland in 17.04, not sure | 12:55 |
| mborzecki | ogra_: missed that, thanks! | 13:00 |
| niemeyer | I'll be late to the call today, or might not make it, as we have a conflicting meeting | 13:01 |
| zyga | Chipaca, pedronis: how about you? | 13:02 |
| niemeyer | Actually, three of us are here | 13:02 |
| zyga | are you joining the main standup? | 13:02 |
| zyga | ah | 13:02 |
| zyga | ok | 13:02 |
| niemeyer | I suggest skipping today | 13:02 |
| zyga | ok | 13:02 |
| niemeyer | Chipaca, cachio_ ^ | 13:02 |
| niemeyer | pstolowski: ^ | 13:02 |
| niemeyer | mborzecki: ^ :) | 13:02 |
| === cyphermo1 is now known as cyphermox | ||
| Chipaca | niemeyer: we decided to have it anyway so we could talk behind your back | 13:13 |
| niemeyer | Damn! I'm glad I wasn't there then :P | 13:13 |
| Chipaca | yeah, doing a hangout with your back to the computer is awkward | 13:14 |
| zyga | chipaca was even doing tricks with his camera so that I was on screen upside-down for a sec | 13:14 |
| mup | PR snapd#5229 closed: interfaces: add juju-client-observe interface <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5229> | 13:16 |
| mborzecki | zyga: now you know how you'd look like in australia | 13:18 |
| mup | PR snapd#5235 opened: interfacces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5235> | 13:21 |
| zyga | mborzecki: hehe, I just need to add snow ;) | 13:21 |
| mup | PR snapd#5236 opened: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5236> | 13:22 |
| zyga | eh, why is S_MAGIC_FUSEBLK just defined inside coreutils | 13:22 |
| Jonas_ | zyga: I opened this topic in the forum https://forum.snapcraft.io/t/interface-mount-umount-cifs-share-permission/5689 | 13:27 |
| zyga | Jonas_: thank you | 13:27 |
| Jonas_ | zyga: if my approach in general is legitimate I could also try to implement the interface myself and open a pull request. But maybe there is a better way to do what I want to achieve, so I will wait for feedback | 13:28 |
| zyga | Thanks, I will review it in detail, I was surprised you could actually mount anything inside your snap, | 13:28 |
| zyga | which kernel were you running? | 13:28 |
| Jonas_ | 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux | 13:30 |
| mup | PR #153: Add REST APIs for capabilities <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/153> | 13:30 |
| zyga | hmm? | 13:31 |
| zyga | ah, mup just being confused | 13:31 |
| Jonas_ | I thought maybe by the network-control or fuse-support interfaces I was able to mount | 13:31 |
| zyga | Jonas_: fuse-support does allow you to mount fuse filesystems in a number of places, including $SNAP_COMMON | 13:32 |
| zyga | (oddly it doesn't allow unmounting) | 13:32 |
| zyga | is your filesystem a kernel one or a fuse one? | 13:33 |
| Jonas_ | it is the kernel cifs one (I think) installed via cifs-utils package (mount.cifs) | 13:33 |
| zyga | that's interesting, it would look like a bug (or missing feature) in the 4.4 kernel that the rule allows mounting any filesystem because of mount fstype=fuse.* (perhaps fstype is not supported) | 13:34 |
| zyga | jdstrand: ^ | 13:34 |
| zyga | Jonas_: in any case, we have enough information to investigate now | 13:34 |
| Jonas_ | zyga: Ok perfect, thx | 13:35 |
| * zyga needs to finish some paperwork for a flight | 13:35 | |
| mborzecki | really warm now, https://i.imgur.com/XyqGRyN.jpg | 13:41 |
| pstolowski | same here | 13:45 |
| mup | PR snapcraft#2147 opened: recording: expose the version of snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2147> | 13:55 |
| === chihchun is now known as chihchun_afk | ||
| === pstolowski is now known as pstolowski|lunch | ||
| mvo | pedronis: quick "taste" question - do you think boot.SetNextBoot() should grow "SetNextBoot(model)" or should we handle it on the backend level? or just move boot/ into backend? | 14:16 |
| mvo | pedronis: context is that SetNextBoot should only be set for kernel/base as defined in the model | 14:16 |
| pedronis | mvo: let me think a 2nd, we also have many packages | 14:21 |
| mvo | pedronis: yeah, I'm a bit uncertain about the layering now that we need to know the model for the next boot seting | 14:22 |
| pedronis | mvo: yea, I think boot could be merged into snapstate/backend | 14:23 |
| mup | PR snapd#5236 closed: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5236> | 14:23 |
| pedronis | mvo: mmh | 14:23 |
| pedronis | mvo: ah, it's separate because it' used also by image | 14:24 |
| mup | PR snapd#5222 closed: tests: adding fedora-28 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5222> | 14:24 |
| mup | PR snapd#5235 closed: interfaces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5235> | 14:24 |
| pedronis | mvo: so, it's used exactly in one place, I think it could be refactored, no to do the check if the type is right on its own | 14:26 |
| pedronis | mvo: and then indeed dealing with model would live backend | 14:26 |
| mvo | pedronis: sounds good - and backend will get LinkSnap(info, model) (?) | 14:28 |
| pedronis | mvo: yes, given that backend doesn't get state, though looking more, the only piece of boot that is used outside of snapstate | 14:29 |
| pedronis | is ExtractKernelAssets | 14:30 |
| mvo | pedronis: yes | 14:30 |
| pedronis | the question woild become a bit where to put that, if we merge the rest of boot into snapstate/backend | 14:30 |
| pedronis | a package to just hold one function i strange | 14:31 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | pedronis: indeed. we could also leave boot/ as is for now and just teach backend to get a model in LinkSnap | 14:32 |
| pedronis | ? | 14:32 |
| mvo | pedronis: I mean, we don't need to move boot.SetNextBoot() into backend just now, by passing the model from snapstate -> backend things should be ok. backend can check if its a relevant snap for booting and call boot.SetNextBoot. or am I misunderstanding something? | 14:33 |
| pedronis | mvo: no, that's fine | 14:34 |
| mvo | pedronis: thank you, I will work on this (will need some test tweaks I think) | 14:35 |
| pedronis | mvo: my point wsa mostly if we start splitting responsability like this, maybe backend should do the type checks too | 14:36 |
| mvo | pedronis: oh, interessting | 14:36 |
| mvo | pedronis: I like that | 14:36 |
| pedronis | mvo: it's a bit strange how SetNextBoot work, doing nothing if it's the wrong | 14:36 |
| pedronis | type | 14:36 |
| mvo | pedronis: +1 lets make this an error | 14:37 |
| pedronis | yea | 14:37 |
| pedronis | and then backend should take care of this | 14:37 |
| pedronis | I suppose similarly for the other helpers | 14:37 |
| mvo | pedronis: I will make it so | 14:37 |
| pedronis | I mean similar changes to split responsability | 14:37 |
| * mvo nods | 14:38 | |
| sergiusens | jdstrand: did we have a bug report for adding the snapcraft version to manifest.yaml? I see I affected the wrong bug (LP: #1768820) which I will fix shortly | 14:54 |
| mup | Bug #1768820: manifest.yaml does not indicate the release the snap was built on <review-tools:Confirmed for jdstrand> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1768820> | 14:54 |
| mup | PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147 | 15:01 |
| mup | PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147 | 15:04 |
| kyrofa | Huh... Travis seems a little off today | 15:14 |
| kyrofa | I can't view any logs | 15:14 |
| kyrofa | Anyone else having troubles? | 15:15 |
| pedronis | mvo: you are off tomorrow and Fri ? | 15:16 |
| mvo | pedronis: yes | 15:20 |
| pedronis | pstolowski: are you off as well tomorrow? | 15:33 |
| pstolowski | pedronis: yes | 15:33 |
| pstolowski | pedronis: but i'll be working on Fri | 15:34 |
| pedronis | pstolowski: mvo: I owe you both re-reviews, I would do them tomorrow morning, unless you think you need them today | 15:36 |
| sergiusens | kyrofa: no, I have been retriggering your PRs though, hit a couple of lxd and store timeouts | 15:38 |
| sil2100 | mvo: I updated https://github.com/snapcore/core18/pull/15 to only look at removals and now we have our first green travis CI run since a long long time \o/ | 15:40 |
| mup | PR core18#15: Update the dpkg list for the ABI test, switch to only tracking removals <Created by sil2100> <https://github.com/snapcore/core18/pull/15> | 15:40 |
| sil2100 | We probably need more tests in the nearest time | 15:40 |
| mvo | sil2100: \o/ | 15:40 |
| sil2100 | Sometimes travis seems to randomly fail on operations like apt install due to not being able to get the lock | 15:41 |
| sil2100 | Looks like an issue on travis | 15:41 |
| sil2100 | mvo: as for the task 'grub boot menu shows "Ubuntu Core 16" right now, must show "Core 18"' - this seems like something on the gadget side, or do you want to somehow hack the menu entry for core from the core18 snap? | 15:44 |
| mvo | sil2100: this is pretty much done, sorry, let me show the PRs | 15:52 |
| mvo | sil2100: https://github.com/snapcore/snapd/pull/5223 and the gadget updates linked in there should fix it. and a new model assertion | 15:53 |
| mup | PR #5223: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223> | 15:53 |
| mvo | sil2100: would be nice to figure out why console-conf is not working, it seems like it cannot configure its network right now | 15:53 |
| sil2100 | mvo: ok! | 15:57 |
| sil2100 | mvo: yay, thanks o/ | 15:57 |
| sil2100 | mvo: should I remove the updates I made to the package list for the removal script? As per my comment, I left them since I thought that it might be good to update it anyway, but maybe we want to have a smaller list there, with the essentials only | 15:58 |
| sil2100 | s/removal script/removal test/ | 15:58 |
| pstolowski | pedronis: i don't, it still needs 2nd review | 15:58 |
| mvo | sil2100: my gut feeling is that we only should update this list when core18 go to stable | 15:59 |
| mvo | sil2100: I mean, that is the promise, once its in stable we cannot remove it anymore | 15:59 |
| mvo | sil2100: but before we have some freedom :) | 16:00 |
| === pstolowski is now known as pstolowski|afk | ||
| sil2100 | mvo: I moved it to a cleaner PR | 16:24 |
| sil2100 | mvo: eh, ok, I just read that even though xenial is supported as a travis dist:, it seems that the dpkg lock errors are only happening there - looks like something isn't quite stable yet | 16:33 |
| sil2100 | So I'll just prep a PR to switch back to trusty for now... | 16:34 |
| sil2100 | Since on xenial we'd have to re-run the CI tests from time to time | 16:34 |
| jdstrand | sergiusens: I thought so. let me check trello | 16:44 |
| jdstrand | sergiusens: ok, so the *snapcraft* version, no, or at least it isn't something that I reported. the release where stage-packages came from, yes (1768820) | 16:46 |
| jdstrand | sergiusens: thank you for picking that up. that will help us be more accurate | 16:46 |
| * zyga fetches more water, | 16:50 | |
| sergiusens | jdstrand: ok, I can kill the snapcraft version one if it is not useful, I had that on the back of my mind for easier mksquashfs detection | 16:51 |
| sergiusens | I can kill it if it is not useful, it might even have been ev that requested this and I am just losing it :-P | 16:51 |
| sergiusens | jdstrand: is ID and VERSION_ID enough? | 16:52 |
| kyrofa | Hey niemeyer, you available to meet? | 17:05 |
| * cachio_ afk | 17:06 | |
| jdstrand | sergiusens: from os-release? yes, that would be fine | 17:06 |
| jdstrand | sergiusens: I wouldn't worry about the mksquashfs detection at this point wrt mainifest.yaml. not everything will have manifest.yaml so it wouldn't help everywhere; besides, we want everyone squashing the same atm. *maybe* it would be useful some day, but I'd like to understand the use case better, so, afaic, I don't need snapcraft version | 17:09 |
| jdstrand | sergiusens: that said, it isn't a terrible thing to have in there, so if you just wanted it, I wouldn't complain | 17:09 |
| jdstrand | I could imagine it might occassionally be helpful when debugging | 17:10 |
| niemeyer | kyrofa: Ouch, sorry | 17:27 |
| niemeyer | kyrofa: Missed our slot | 17:27 |
| niemeyer | kyrofa: Just off a call with noise][, here if you are | 17:27 |
| Chipaca | something's up with the lxd snap | 18:05 |
| Chipaca | + lxd.lxc exec my-ubuntu dhclient eth0 | 18:06 |
| Chipaca | Cannot find device "eth0" | 18:06 |
| === jkridner|afk is now known as jkridneer | ||
| === jkridneer is now known as jkridner | ||
| kyrofa | Hey niemeyer, I'm available now, sergiusens are you around? | 18:11 |
| sergiusens | sure | 18:12 |
| niemeyer | Cool, let's go then | 18:13 |
| kyrofa | Same room? Alright, hopping in | 18:15 |
| Lin-Buo-Ren | Anyone knows why snapcraft replaces the prefix of pkg-config to $SNAPCRAFT_STAGE$originally_configured_prefix ? | 18:22 |
| kyrofa | sergiusens, yikes, lxd issues in travis | 18:54 |
| kyrofa | Finally got the log to load | 18:55 |
| sergiusens | kyrofa: internet has been slow in general for me today | 18:55 |
| sergiusens | kyrofa: google docs is also playing up | 18:55 |
| kyrofa | can't get anything to pass anymore | 18:56 |
| kyrofa | Time for vacation? | 18:56 |
| kyrofa | Looks like we're using the lxd snap... any chance it just updated? | 18:58 |
| kyrofa | I'll see if I can duplicate locally | 18:58 |
| kyrofa | sergiusens, yep, I can duplicate locally | 19:05 |
| kyrofa | Looks like 3.1 was released | 19:05 |
| kyrofa | I'll chase it down | 19:06 |
| kyrofa | Looks like we don't need to setup that iface | 19:16 |
| mup | PR snapcraft#2148 opened: travis: stop setting up testbr0 for lxd <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148> | 19:23 |
| sergiusens | kyrofa we can also stick to the 3.0 channel | 19:30 |
| sergiusens | and gain the benefits of stability | 19:30 |
| * sergiusens will brb | 19:31 | |
| kyrofa | Oh, that definitely seems like something we'd want in CI | 19:40 |
| kyrofa | Forgot that was available | 19:41 |
| mup | PR snapcraft#2148 closed: travis: stop setting up testbr0 for lxd <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148> | 19:44 |
| mup | PR snapcraft#2149 opened: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149> | 19:47 |
| kyrofa | Dang... looks like 3.0 track was updated to have the same issue :( | 19:53 |
| sergiusens | kyrofa: so for snapcraft#2149 you set the lxd to the 3.0 track but still remove the bridge creation logic, is that desired? | 19:59 |
| mup | PR snapcraft#2149: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149> | 19:59 |
| mup | PR snapd#5237 opened: tests: fix lxd test - in current lxd we get eth1 instead of eth0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5237> | 20:00 |
| kyrofa | sergiusens, it's required, I'm afraid | 20:12 |
| kyrofa | 3.0 still busts the same way as 3.1 | 20:13 |
| kyrofa | But I still think it's worth using 3.0 | 20:13 |
| sergiusens | kyrofa: ok, no worries | 20:26 |
| jdstrand | niemeyer: hi! would you mind commenting on https://forum.snapcraft.io/t/camera-raw-usb-plugs-auto-connect-for-qtchildid/2917/4? (especially since you know the roadmap for dynamic hotplug) | 20:28 |
| niemeyer | jdstrand: Will look, thanks for the ping | 20:29 |
| jdstrand | np | 20:29 |
| kyrofa | sergiusens, bleech... so many concerns leakages between lifecycle and pluginhandler... | 20:35 |
| kyrofa | They even share logging responsibilities :D | 20:35 |
| sergiusens | kyrofa: the pluginhandler should have its cli roots stripped out | 20:36 |
| sergiusens | but we talked about this already, right? | 20:36 |
| kyrofa | sergiusens, I know we've talked about pluginhandler, but I don't recall a conversation about lifecycle | 20:37 |
| sergiusens | kyrofa: we said we wanted to put all new logging in lifecycle and remove things from pluginhandler as time went by, given that anything in pluginhandler is (or should be) triggered by lifecycle | 20:38 |
| kyrofa | Yeah that sounds right. I think I might do a little bit of that here | 20:39 |
| sergiusens | \o/ | 20:44 |
| sergiusens | kyrofa: ok, going to stop for today and re-check on that lxd PR later in the evening/night to update and propose new PRs | 21:39 |
| kyrofa | sergiusens, sounds good. LXD PR look good though? Can I merge if green? | 21:40 |
| sergiusens | kyrofa: oh, let me approve | 21:40 |
| mup | PR snapd#5238 opened: tests: skip appstream-id test for core systems 32 bits <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5238> | 21:40 |
| kyrofa | Excellent | 21:40 |
| mup | PR snapcraft#2141 closed: jhbuild plugin: allow running as 'root' <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2141> | 21:41 |
| diddledan | \o/ | 21:41 |
| sergiusens | kyrofa: after merging, if I don't get to it, please update branch on the top 4 PRs on the list | 21:41 |
| kyrofa | I'll update em all | 21:42 |
| kyrofa | Well, the current ones anyway | 21:42 |
| sergiusens | kyrofa: well, just those 4 please :-P | 21:42 |
| sergiusens | yeah | 21:43 |
| mup | PR snapcraft#2149 closed: travis: use LXD from 3.0 track <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149> | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
