| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 06:10 |
|---|---|---|
| zyga | Good morning | 07:04 |
| mborzecki | zyga: hey | 07:21 |
| mborzecki | zyga: do you know who controls strace-static snap? | 07:21 |
| mborzecki | is it only mvo? | 07:22 |
| zyga | I believe so | 07:22 |
| zyga | What do you need? | 07:22 |
| mborzecki | well, it doesn't work on fedora, something about unexpected wait status value, i believe it's the recent kernel that's causing this | 07:23 |
| mborzecki | the edge version is 4.23 and stil not good enough | 07:23 |
| mborzecki | fedora ships strace 4.24 and that one works | 07:23 |
| mborzecki | i've worked around it in the spread suite, but we'll need to update the snap at some point | 07:23 |
| zyga | Mmm | 07:27 |
| zyga | Is 4.24 compatible with other distributions? | 07:28 |
| mborzecki | zyga: we'll see when we end up using it in the spread suite | 07:32 |
| mborzecki | zyga: fwiw i have 4.25 in arch | 07:32 |
| mborzecki | one last spread run and i'll be opening a PR with Fedora 29 | 07:34 |
| zyga | Ok | 07:50 |
| zyga | I will be around in 30 minutes | 07:51 |
| zyga | As usual, worked late last night | 07:53 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | heyas | 08:12 |
| mborzecki | pstolowski: hey | 08:20 |
| zyga | back now | 08:35 |
| zyga | good morning pawel | 08:35 |
| zyga | how are you guys? | 08:36 |
| zyga | sorry for being sleepy, I was pushing some things last night | 08:39 |
| zyga | are we still affected by the issue where our logs are too long for travis? | 08:40 |
| mup | PR snapd#6264 opened: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264> | 08:45 |
| zyga | mborzecki: what is your stance on the repackaging issue? | 08:47 |
| zyga | I have not read the PR yet so if it is stated there please refer me instead | 08:47 |
| mborzecki | zyga: imo it's benign as long as we don't reexec on those system, i think we could easily not repack the core snap on such systems | 08:50 |
| zyga | why is it related to reexec? | 08:50 |
| zyga | like it happened with snap-device-helper, some things are always used from core | 08:50 |
| mborzecki | zyga: oh, w8, it's not, right reexec would still pull the libs from host so that's fine | 08:51 |
| zyga | or am I mistaken, that the issue was that repackaged, incompatible script was used | 08:51 |
| pstolowski | zyga: the spread test for dns error (#6222) is driving me crazy.. been trying a couple of tweaks yesterday evening. sounds crazy, but it looks like iptables-save+restore on debian doesn't actually restore the rules sometimes - some other test fails and when poking around in the system after failure i see the rule is active.. | 08:51 |
| mup | PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222> | 08:51 |
| mborzecki | zyga: so it's probably only snapctl at this point | 08:51 |
| mborzecki | which we could easily build statically | 08:51 |
| zyga | mborzecki: would the issue also surface on future ubuntu 20.04 distribution testing a core16 snaps? | 08:52 |
| zyga | pstolowski: can you dump the rules to compare them in text form? | 08:52 |
| zyga | mborzecki: when snap-confine, reexecuting, is linked to libc not present in core16 | 08:53 |
| mborzecki | zyga: afaict only tools that are executed inside snap mount ns would be affected, those are snapctl and snap-device-helper, snap-update-ns (but that's already linked statically) | 08:54 |
| zyga | indeed | 08:54 |
| zyga | that's a good observation | 08:54 |
| mborzecki | snapctl can be linked statically, it's go :) | 08:54 |
| zyga | as other tools will still execute on the outside | 08:55 |
| zyga | thanks | 08:55 |
| mborzecki | zyga: that shebang being rewritten from #!/bin/sh to #!/usr/bin/sh is probably some usr-merge thing again | 08:57 |
| zyga | yes | 08:58 |
| pstolowski | zyga: iptables-save dumps them in txt form; let me actually inspect that when some other test fails | 08:58 |
| zyga | pstolowski: yeah, just dump them in prepare and restore | 08:58 |
| zyga | and compare what we get | 08:58 |
| zyga | guys, I'm almost convinced there's something seriously broken | 08:58 |
| zyga | so consider, when inspecting magic failures, that set -e is indeed not working | 08:58 |
| zyga | so perhaps something failed earlier on and the script nonetheless advanced | 08:59 |
| zyga | though I still don't grasp the details | 08:59 |
| mborzecki | pstolowski: silly thought, maybe we should start our own dns server for that test | 09:04 |
| pstolowski | mborzecki: hmm but we would need to modify the test environment anyway, so potentially effect something else? | 09:04 |
| pstolowski | mborzecki: it seems like a primitive approach with just iptables -I .., followed by iptables -D ... works. or maybe i'm just lucky. | 09:05 |
| mborzecki | hehe :) if it works then it's fine | 09:05 |
| pstolowski | mborzecki, zyga: ha, reproduced. run all spread tests. a radom test failed (not the one that messes up with iptables). the rules dump file created by iptables-save is empty, but iptables has the dns reject rule | 09:15 |
| zyga | intriguing, how do you save and observe the tables? | 09:16 |
| zyga | and where do you store the dump? | 09:16 |
| pstolowski | mborzecki, zyga grr, ignore me. the rules should be empty :D | 09:16 |
| zyga | ah | 09:16 |
| pstolowski | mborzecki, zyga apparently iptables-restore didn't work or wasn't invoked | 09:16 |
| pstolowski | hmm, ok, not even that. rules dump is empty (as completely empty), but it should actually have some iptables-save noise | 09:19 |
| pstolowski | weird... | 09:19 |
| zyga | how do you dump the rules? | 09:19 |
| mborzecki | pstolowski: were there any rules in place when iptables-save was called? | 09:20 |
| pstolowski | mborzecki: no (and in such case iptables-save creates a kind empty file with empty chains) | 09:22 |
| zyga | is the file overwritten somewhere? | 09:23 |
| mborzecki | pstolowski: hm empty? shouldn't there be a timestamp and a list of all chanins (all empty) | 09:23 |
| pstolowski | mborzecki: yes | 09:24 |
| pstolowski | zyga: interesting theory | 09:24 |
| pstolowski | trying without iptables save/restore now, if it works i'm gonna leave it like that | 09:25 |
| mborzecki | #6264 is green :) | 09:30 |
| mup | PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264> | 09:30 |
| mborzecki | damn, hitting unrelated errors in the PRs | 09:45 |
| mborzecki | appstream-id, refresh-all :/ | 09:45 |
| mborzecki | and mount thing obviously too | 09:45 |
| zyga | yes | 09:50 |
| zyga | bane of random failures | 09:50 |
| zyga | eh :/ | 09:50 |
| zyga | I really encourage everyone to attack them | 09:50 |
| zyga | they are crippling our ability to make progress | 09:50 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6261 ? | 10:09 |
| mup | PR #6261: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6261> | 10:09 |
| mborzecki | it's finally green | 10:09 |
| pstolowski | k | 10:10 |
| mborzecki | zyga: about that xdg-desktop-portal: https://paste.ubuntu.com/p/nkFc5FJ3Qc/ | 10:17 |
| zyga | mmm | 10:18 |
| mborzecki | but i don't see what requires that really | 10:18 |
| === chihchun_afk is now known as chihchun | ||
| zyga | we require it | 10:18 |
| mborzecki | zyga: well, it's not listed anywhere in the spec | 10:19 |
| zyga | hmm | 10:20 |
| zyga | perhaps I was mistaken | 10:20 |
| pstolowski | #6222 green as well; kicking it again to double check | 10:20 |
| zyga | but I recall something like that | 10:20 |
| mup | PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222> | 10:20 |
| zyga | pstolowski: ack | 10:21 |
| mborzecki | zyga: https://paste.ubuntu.com/p/Yf3bRmcjBr/ | 10:21 |
| zyga | pstolowski: is it safe to merge or do you anticipate tests breaking in the future? | 10:21 |
| zyga | hm | 10:21 |
| zyga | mborzecki: then I have no idea | 10:21 |
| * zyga -> tea | 10:22 | |
| pstolowski | zyga: the test is dead simple and doesn't shouldn't have any side-effects, but you never know. i'll give it one more run to see. if it causes problem in the future i'll disable it | 10:24 |
| zyga | ok | 10:24 |
| mborzecki | zyga: heh i can actually remove xdg-desktop-portal and none of snapd components are removed | 10:25 |
| mup | PR snapd#6261 closed: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6261> | 10:42 |
| mborzecki | pstolowski: if you could do this one too: https://github.com/snapcore/snapd/pull/6260 | 10:49 |
| mup | PR #6260: spread, tests: use checkpoints when dumping audit log <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6260> | 10:50 |
| mborzecki | zyga: no clue what's happening with dependencies there, left a note in the PR for now | 10:51 |
| zyga | sounds good | 10:51 |
| pstolowski | random mount failure on 6222 - Mount snap "test-snapd-tools_instance" (7) ([start snap-test\x2dsnapd\x2dtools_instance-7.mount] failed with exit status 1: Job for snap-test\x2dsnapd\x2dtools_instance-7.mount failed. | 10:57 |
| mborzecki | heh | 10:58 |
| zyga | on whihc system? | 11:01 |
| zyga | *which system | 11:01 |
| zyga | moved downstairs to the office | 11:01 |
| zyga | sorry, I don't feel well today | 11:01 |
| pstolowski | zyga: google:ubuntu-18.04-64:tests/main/refresh-all | 11:08 |
| zyga | 18.04 | 11:08 |
| zyga | mmm | 11:08 |
| zyga | has anyone seen this on 18.10? | 11:08 |
| mup | PR snapd#6265 opened: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265> | 11:20 |
| mup | PR snapd#6260 closed: spread, tests: use checkpoints when dumping audit log <Simple 😃> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6260> | 11:21 |
| mborzecki | pstolowski: thanks! | 11:24 |
| cachio | zyga, hey, I tested the systemd fix but still failing | 11:27 |
| pstolowski | yw | 11:27 |
| cachio | there is a test interfaces-hostname-control | 11:27 |
| cachio | which found that error | 11:28 |
| cachio | which still fail | 11:28 |
| zyga | cachio: can you report on the SRU bug please | 11:29 |
| zyga | cachio: and talk to xnox about the details | 11:29 |
| cachio | sure | 11:29 |
| zyga | thank you | 11:29 |
| cachio | zyga, np | 11:29 |
| cachio | I have a branch with the change I did to check that | 11:29 |
| ackk | hi, is there a "hook" to do stuff like push files/configs to the multipass VM snapcraft uses? | 11:29 |
| cachio | if you want to take a look just tell me | 11:29 |
| zyga | cachio: that's fine, unless you want me to | 11:31 |
| cachio | ok, I'll explain more during the standup | 11:32 |
| pstolowski | #6222 is green again, merging | 11:51 |
| mup | PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222> | 11:51 |
| mup | PR snapd#6222 closed: cmd/snap: handle DNS error gracefully <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6222> | 11:52 |
| zyga | jdstrand: 6244 is read | 11:53 |
| zyga | *ready | 11:53 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/6251 needs a 2nd review | 11:53 |
| mup | PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251> | 11:53 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/6149 needs a partially second review | 11:54 |
| mup | PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns 🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149> | 11:54 |
| mborzecki | k, looking | 11:54 |
| zyga | thank you :) | 11:54 |
| zyga | mborzecki: any action needed on F29 PR in light of the weak dependency fact? | 11:56 |
| mborzecki | zyga: i'm running the fix under spread right now | 11:57 |
| zyga | ok | 11:57 |
| mborzecki | that umask thing keeps popping up | 12:01 |
| zyga | hmmm | 12:01 |
| zyga | tests leaking | 12:01 |
| zyga | or something else? | 12:01 |
| mborzecki | zyga: the test that passed on travis and locally before failed right now | 12:02 |
| * cachio afk | 12:04 | |
| zyga | I'm back to debugging set -e bug | 12:04 |
| zyga | waaat?!!? | 12:11 |
| jamesh | zyga: would it be possible to get this change merged? https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/360118 -- this test package isn't currently used in snapd master, and I needed to update it a bit for the new version of the dbus activation changes | 12:17 |
| zyga | looking | 12:17 |
| zyga | if this is merged and published to the store, would snapd tests be affected straight away? | 12:18 |
| zyga | I mean, would any tests that used to pass start to fail? | 12:18 |
| jamesh | zyga: there is no reference test-snapd-dbus-service in the tests/ directory of snapd master | 12:19 |
| zyga | ok | 12:19 |
| jamesh | it originates from mvo's old abandoned PR | 12:20 |
| zyga | jdstrand: is there a merge service running against that BZR branch? | 12:22 |
| zyga | er | 12:22 |
| zyga | jamesh: ^ | 12:22 |
| zyga | sorry, bad tab completion | 12:22 |
| jamesh | zyga: I don't think so. | 12:23 |
| zyga | ok, I'll merge it manually then | 12:23 |
| jamesh | thank you. I think I'm getting close to being able to remove that "WIP" tag from my PR | 12:24 |
| jamesh | (and I understand it might take a while to get reviewed) | 12:24 |
| zyga | hopefully more reviews will resume next week | 12:25 |
| jamesh | I'm sure there's still problems to discover once my spread tests run on all distros | 12:26 |
| zyga | hmm | 12:32 |
| * zyga doesn't recall bzr specific weirdness | 12:32 | |
| zyga | jamesh: I _think_ it is merged | 12:32 |
| zyga | yep | 12:33 |
| zyga | mborzecki: can you re-review https://github.com/snapcore/snapd/pull/6259/files | 12:43 |
| zyga | the set -e mystery is solved | 12:43 |
| mup | PR #6259: tests: reduce verbosity around package installation <Simple 😃> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6259> | 12:43 |
| zyga | I was so stuck looking at why dpkg-query failure was ignored | 12:43 |
| zyga | it was not | 12:43 |
| zyga | it was never executed | 12:43 |
| zyga | the exit above made sure of that | 12:43 |
| zyga | so the test would fail but it was returning early | 12:43 |
| mborzecki | zyga: something fishy about tests, i have no idea how that fedora 29 pr is green | 12:58 |
| zyga | haha | 12:58 |
| zyga | in which sense | 12:58 |
| zyga | maybe it is manual? | 12:58 |
| mborzecki | omg, damn, it is | 12:59 |
| mup | PR snapd#6250 closed: data: set KillMode=process for snapd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6250> | 13:03 |
| zyga | advice welcome on https://github.com/snapcore/snapd/pull/6190 | 13:06 |
| mup | PR #6190: overlord/configstate,features: expose features to snapd tools <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190> | 13:06 |
| zyga | is that good as is | 13:06 |
| zyga | or should I iterate on some aspect | 13:06 |
| zyga | should I split some parts out to land quicky | 13:06 |
| mup | PR snapd#6259 closed: tests: reduce verbosity around package installation <Simple 😃> <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6259> | 13:31 |
| mup | PR snapd#6266 opened: tests: make security-device-cgroups-{devmode,jailmode} work on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6266> | 13:31 |
| zyga | updated https://github.com/snapcore/snapd/pull/6149#discussion_r239058308 | 13:34 |
| mup | PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns 🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149> | 13:34 |
| zyga | mborzecki: do you mean to make F29 non-manual in https://github.com/snapcore/snapd/pull/6264 | 13:42 |
| mup | PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264> | 13:42 |
| mborzecki | zyga: yes, running with the latest batch of fixes, i'll label the PR as blocked for now | 13:43 |
| zyga | thank you | 13:43 |
| mup | PR snapd#6267 opened: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267> | 13:43 |
| zyga | mborzecki, pstolowski: I pushed a very simple PR to shrink my other feature PR, could you guys please look ^ | 13:43 |
| zyga | pstolowski: need a 2nd review on https://github.com/snapcore/snapd/pull/6149 :) | 13:51 |
| mup | PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns 🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149> | 13:51 |
| zyga | feel that this is finally moving forward :) | 13:51 |
| pstolowski | zyga: ok, will do | 13:53 |
| mborzecki | zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b | 14:16 |
| zyga | xnox: hey, what going to happen now that the SRU verification of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 is failed? | 14:24 |
| mup | Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936> | 14:25 |
| cachio | zyga, https://github.com/sergiocazzolato/snapd/tree/tests-validate-lp-1778936 | 14:30 |
| zyga | cachio: can you add a note to that bug please, that explains how to reproduce the results of that test | 14:30 |
| zyga | cachio: specifically how to build a system image with core18 which contains systemd from proposed | 14:31 |
| cachio | ok | 14:31 |
| zyga | thank you :) | 14:31 |
| zyga | cachio: I'm not sure how what you changed there tests systemd form proposed | 14:32 |
| zyga | since our testing process doesn't involve unpacking systemd into the repackaged core18 snap | 14:32 |
| zyga | cachio: so you would still get the vanilla core18 from the store | 14:32 |
| zyga | which has systemd from stable | 14:32 |
| zyga | (well, from the archive) | 14:32 |
| zyga | cachio: may I ask how you checked the version of systemd that you observed? | 14:33 |
| zyga | cachio: in the effective image built with ubuntu-image? | 14:34 |
| cachio | when the test fails | 14:34 |
| cachio | zyga, it is possible to check systemd version in a debug session | 14:34 |
| zyga | mhm | 14:34 |
| zyga | and what is the version you saw? | 14:34 |
| cachio | 237-3ubuntu10.10 | 14:35 |
| zyga | and how does that relate to the version in main and in proposed? | 14:35 |
| cachio | in main is 237-3ubuntu10.7 | 14:35 |
| cachio | irrc | 14:35 |
| zyga | the version that is mentioned in the bug report as containing the fix is different | 14:35 |
| zyga | it is 239-7ubuntu7 | 14:36 |
| cachio | basically, what I do it to enable proposed and refresh systemd during the project preparation | 14:36 |
| zyga | or 237-3ubuntu10.8 in bionic | 14:36 |
| cachio | Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.10 | 14:36 |
| zyga | cachio: but that changes the starting throwaway image | 14:36 |
| zyga | not the core18 image you build | 14:36 |
| zyga | I don't see how the changes you did affect the core18 _snap_ that is used to build the image where tests execute | 14:37 |
| zyga | it may be that this is correct | 14:37 |
| zyga | but I don't understand it yet | 14:37 |
| zyga | and I want to since the verification failed and this is an urgent issue | 14:37 |
| cachio | let me create a debug session | 14:38 |
| cachio | zyga, perhaps it works | 14:38 |
| cachio | to understand better | 14:38 |
| zyga | you can create one but can you argument how this is expected to work | 14:38 |
| zyga | I want to see how the proposed package ends up in the core18 snap | 14:38 |
| === chihchun is now known as chihchun_afk | ||
| cachio | so, we build core18 snap we use the deb snapd.deb we already created | 14:40 |
| zyga | how do we build the core18 snap? can you show me please? | 14:41 |
| cachio | zyga, sure, 1 sec | 14:41 |
| zyga | thanks | 14:41 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/6244 is ready, if you have some time to look at the last patch I would love to land that and have that bug fixed :) | 14:42 |
| cachio | https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L339 | 14:42 |
| mup | PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244> | 14:42 |
| cachio | zyga, ~ | 14:42 |
| zyga | cachio: looking | 14:42 |
| zyga | so | 14:43 |
| zyga | we unpack the _snapd_ snap | 14:43 |
| zyga | right? | 14:43 |
| cachio | yes | 14:43 |
| zyga | does the snapd snap contain systemd? | 14:43 |
| zyga | AFAIK systemd is inside the core18 snap | 14:44 |
| zyga | unless we are repackaing that one elsewhere, and based on the package from the host | 14:44 |
| zyga | I don't see how this was testing proposed | 14:44 |
| cachio | zyga, what I did is to enable proposed on this instance | 14:45 |
| cachio | and add a dependency on snapd.deb to the package on proposed | 14:46 |
| zyga | Sorry, in which instance? | 14:46 |
| cachio | so then if we build the image based on out .deb | 14:46 |
| cachio | instance is the ubuntu-18.04-64 that we use to create the image | 14:46 |
| zyga | The test was checking snapd on core18 or on Ubuntu 18.04? | 14:46 |
| cachio | zyga, the test checks on core 18 instance | 14:47 |
| cachio | which is build on the fly using a ubuntu bionic image | 14:47 |
| zyga | So explain how the choice of the host instance affects the system image built with Ubuntu image that is eventually tested? | 14:47 |
| zyga | My understanding is that the core18 snap is coming from the store | 14:48 |
| zyga | And that it contains systemd | 14:48 |
| jlorenzo | kenvandine: oSoMoN: hi guys! a mozilla employee found an odd behavior regarding assertions (even though he installed the snap with `--dangerous`). He left more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1297531. Would you know who would be suited to help him out? | 14:49 |
| zyga | And because we do not alter it in the test, that is the core18 snap is as-is from the store then the changes ran against the same systemd version as before | 14:49 |
| cachio | mmm, I see in the code that we modify the snapd snap to use what we have in the snapd.deb | 14:49 |
| zyga | Yes | 14:49 |
| zyga | But snapd snap does not contain systemd | 14:49 |
| kenvandine | hey jlorenzo | 14:49 |
| oSoMoN | hey jlorenzo | 14:51 |
| oSoMoN | reading that bug | 14:51 |
| cachio | I though that by setting a dependency for the snapd.deb to use the systemd from proposed is enough to force the image gets this systemd | 14:51 |
| cachio | but based on the code I am not 10% sure | 14:51 |
| cachio | 100% | 14:51 |
| zyga | It would if this was using apt | 14:52 |
| zyga | But we unpack just snapd.deb | 14:52 |
| zyga | Still | 14:52 |
| zyga | I believe you saw the right version of systemd | 14:52 |
| zyga | Can you tell me which channel of core18 was used in the test | 14:52 |
| zyga | Was it edge? | 14:53 |
| zyga | And is core18 edge using main or proposed? | 14:53 |
| cachio | we use edge | 14:53 |
| zyga | Perhaps you tested the SRU despite making changes that have no effect on the produced image | 14:53 |
| kenvandine | oSoMoN: thanks | 14:53 |
| zyga | Can you please check the core18 edge snap recipe | 14:54 |
| zyga | It should have this information | 14:54 |
| cachio | sure | 14:54 |
| zyga | Thank you :-) | 14:54 |
| oSoMoN | jlorenzo, no need for an assertion, for local tests the browser-support interface can be manually connected, I'll comment on the bug to explain | 14:56 |
| diddledan | who can kick the store review thingy for me? gog-galaxy-wine revision 62 is stuck | 14:59 |
| cachio | zyga, at least core is not built from proposed | 15:01 |
| cachio | zyga, I can't see the recipy for core18 | 15:01 |
| jlorenzo | oSoMoN: got it! thank you very much for the help :) | 15:02 |
| oSoMoN | jlorenzo, you're welcome | 15:03 |
| cachio | zyga, so, I'll try to build a snapd.snap with systemd from proposed | 15:03 |
| cachio | zyga, that should work right? | 15:03 |
| zyga | re | 15:06 |
| zyga | cachio: no, build core18 with systemd from proposed | 15:06 |
| zyga | cachio: snapd.snap version is irrelevant | 15:06 |
| zyga | cachio: can you ask foundations for help, they should be able to point you to the recipe | 15:07 |
| cachio | zyga, great, thanks | 15:07 |
| cachio | I'll try that | 15:07 |
| zyga | sure, let me know if you cannot find the recipe, I can look as well | 15:07 |
| zyga | cachio: and please add a comment to the bug report that testing is still ongoing | 15:08 |
| zyga | so that xnox doesn't take action on incomplete information | 15:08 |
| cachio | zyga, sure, comment left | 15:11 |
| zyga | super, thank you | 15:11 |
| cachio | zyga, thanks for the help | 15:11 |
| xnox | cachio, if you give me something i can boot in a VM, i'm happy to validate things =) | 15:23 |
| xnox | w.r.t. etc-writable stuff. | 15:23 |
| zyga | xnox: who builds the core18 images now, is that foundations? | 15:29 |
| zyga | sorry, I was imprecise, I meant core18.snap | 15:29 |
| zyga | xnox: looking at the core18 snap in edge, it ships with systemd 237 | 15:31 |
| zyga | but it doesn't have a manifest that I can look at | 15:31 |
| cachio | xnox, still trying to build the correct image, I'll let you know when the image is ready for validation | 15:31 |
| cachio | zyga, I searched on launchpad and couldn't find it | 15:32 |
| cachio | at least in our projects | 15:32 |
| cachio | so, foundations should be creating it, or mvo in same place | 15:33 |
| cachio | zyga, the last core18 images which I tested were share by mvo | 15:33 |
| cachio | zyga, I see this in the store -> core18 – Shared by canonical (snaps@canonical.com) | 15:35 |
| cachio | so foundations should be creating them | 15:35 |
| zyga | I found this repository: https://launchpad.net/snap-core18 | 15:35 |
| zyga | but not sure if that's used | 15:35 |
| zyga | sil2100: hey | 15:36 |
| zyga | sil2100: can you shed some light on core18 snap | 15:36 |
| cachio | https://code.launchpad.net/~ubuntu-core-service/+snap/core18 | 15:36 |
| zyga | do you know where the source repository is and where the build recipe is (if it is built with a snap recipe)? | 15:37 |
| zyga | cachio: nice, looking | 15:37 |
| zyga | https://code.launchpad.net/~ubuntu-core-service/+snap/core18 says it is using primary archive for ubuntu | 15:37 |
| zyga | so that doesn't look like it uses proposed | 15:37 |
| zyga | and the publised snap goes to beta and edge | 15:38 |
| zyga | this is using the updates pocket | 15:38 |
| zyga | so not proposed | 15:38 |
| zyga | so we need to repeat the test | 15:38 |
| zyga | cloning that recipe | 15:38 |
| cachio | zyga, is it possible to unpack core18 and manually replace systemd? | 15:38 |
| zyga | cachio: yes but for correctness we should just rebuild it with different archive | 15:38 |
| zyga | that's supposedly easy | 15:38 |
| zyga | cjwatson: hey, could you please help us with one thing, we'd like to build https://code.launchpad.net/~ubuntu-core-service/+snap/core18 but switch the archive to proposed | 15:39 |
| zyga | what's the easiest way to do that? | 15:39 |
| zyga | we don't need to upload it to the store (though uploading to edge is ok) | 15:40 |
| zyga | ideally edge could be out of proposed for real but we are after one-off test | 15:40 |
| cjwatson | zyga: I'm on holiday today and tomorrow. You should be able to work that one out from the apidoc though, I think | 15:45 |
| zyga | thanks, looking! | 15:45 |
| zyga | enjoy the holidays and don't worry :) | 15:45 |
| xnox | zyga, cachio - even if foundations build it, it's not built with proposed on..... i don't think..... | 15:47 |
| xnox | but it is not I =/ | 15:48 |
| zyga | xnox: yeah, I checked, it's built with updates | 15:48 |
| zyga | xnox: trying to build it now | 15:48 |
| cachio | zyga, do you have a way to build it? | 15:54 |
| zyga | yes, I think so | 15:54 |
| zyga | building now | 15:54 |
| zyga | I will share what I did if this works | 15:54 |
| cachio | zyga, great, thanks | 15:57 |
| zyga | cachio: ok, I have a core18 now | 16:00 |
| zyga | cachio: can you try this locally please: | 16:00 |
| mup | PR snapd#6268 opened: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268> | 16:01 |
| zyga | git clone -b master https://git.launchpad.net/snap-core18 | 16:01 |
| zyga | sed -i -e 's/current/pending/g' Makefile | 16:02 |
| zyga | use snapcraft from the debian pacakge | 16:03 |
| zyga | not from the snap: | 16:03 |
| zyga | sudo snapcraft | 16:03 |
| zyga | once built you can use that core18 snap to build an image | 16:03 |
| zyga | after building you inspect the file dpkg.list found in /usr/share/snappy/dpkg.list | 16:05 |
| zyga | for me it contains: | 16:05 |
| zyga | ii systemd 237-3ubuntu10.10 amd64 system and service manager | 16:05 |
| zyga | this corresponds to the proposed update that xnox wanted tested | 16:05 |
| zyga | xnox: ^ can you please confirm that systemd 237-3ubuntu10.10 is the version that is under SRU? | 16:05 |
| zyga | cachio: using that snap just build and boot a KVM image | 16:05 |
| zyga | cachio: then you can run a test against that | 16:06 |
| cachio | nice | 16:08 |
| cachio | on that | 16:08 |
| zyga | excellent, thank you! | 16:09 |
| zyga | sergiusens: question about snapcraft the deb vs the snap | 16:09 |
| zyga | I got a failure where snapcraftctl was not on PATH and the build failed | 16:09 |
| zyga | is that expected with 3.x? | 16:09 |
| zyga | should I file that as a bug | 16:09 |
| zyga | the snap in question is core18 from the repository mentioned above | 16:09 |
| cachio | zyga, in the building logs I see systemd is downloading from proposed | 16:13 |
| cachio | so far no errors | 16:13 |
| cachio | it is still building | 16:13 |
| zyga | cachio: you can verify the manifest to be sure as well | 16:14 |
| cachio | zyga, yes, | 16:14 |
| zyga | pstolowski: some failures on that hotplug PR | 16:19 |
| zyga | https://www.irccloud.com/pastebin/vcIZiRRm/ | 16:19 |
| zyga | https://github.com/snapcore/snapd/pull/6268 | 16:19 |
| mup | PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268> | 16:19 |
| pstolowski | zyga: ok, interesting, looking | 16:19 |
| zyga | pstolowski: if you can please review https://github.com/snapcore/snapd/pull/6267 | 16:21 |
| mup | PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267> | 16:21 |
| pstolowski | zyga: will do; just finishing 6251 | 16:21 |
| zyga | thanks :) | 16:21 |
| cachio | zyga, ii systemd 237-3ubuntu10.10 amd64 system and service manager | 16:21 |
| zyga | cachio: great | 16:21 |
| zyga | that's the new version | 16:21 |
| zyga | right? | 16:22 |
| cachio | yes | 16:22 |
| cachio | thanks | 16:22 |
| cachio | I am running the test now | 16:22 |
| cachio | using the core18 snap just built | 16:22 |
| cachio | zyga, it is gonna take time because it needs to upload 47 MB | 16:22 |
| zyga | let me know if you have issues | 16:23 |
| zyga | I can probably build a kvm image and test locally | 16:23 |
| zyga | pstolowski: can you explain what you meant on https://github.com/snapcore/snapd/pull/6251#discussion_r239132132 ? | 16:32 |
| zyga | ah | 16:33 |
| mup | PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251> | 16:33 |
| zyga | I see it on the 3rd comment :) | 16:33 |
| zyga | thanks, I'll add an explanation of SNAPD_DEBUG=x :) | 16:33 |
| pstolowski | zyga: sorry :) | 16:33 |
| zyga | nothing to be sorry about :) | 16:33 |
| zyga | thank you | 16:33 |
| zyga | pstolowski: more errors | 16:38 |
| pstolowski | zyga: uhm, thanks, checking | 16:38 |
| zyga | https://www.irccloud.com/pastebin/Bg0hqSL4/ | 16:38 |
| zyga | pstolowski: if you can review https://github.com/snapcore/snapd/pull/6149 before EOD it would make my day, | 16:39 |
| zyga | more progress on user mounts than all of last week :) | 16:39 |
| mup | PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns 🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149> | 16:39 |
| zyga | jdstrand: hey | 16:40 |
| zyga | jdstrand: not sure if you are sprinting this week, I just need a quick look at https://github.com/snapcore/snapd/pull/6244/commits/29301fca5a7a465305421e4633b9488b64942adc which I believe implements spirit of what you asked for in https://github.com/snapcore/snapd/pull/6244#discussion_r238677532 | 16:40 |
| mup | PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244> | 16:40 |
| pstolowski | interesting it doesn't panic locally, yet clearly its missing locking | 16:42 |
| zyga | huh | 16:42 |
| zyga | that's odd | 16:42 |
| zyga | that lock panic should be deterministic? | 16:42 |
| zyga | are you missing anything from master? | 16:42 |
| pstolowski | yes, if this code was not hit then the asserts around order would fail at the end of the test | 16:43 |
| pstolowski | anyway, pushed a fix | 16:43 |
| zyga | thanks | 16:44 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/6262 needs a 2nd review | 16:44 |
| zyga | small trivial branch from jamie | 16:44 |
| mup | PR #6262: apparmor: allow snap-update-ns access to common devices <Simple 😃> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6262> | 16:44 |
| zyga | and I'd love a review on this one https://github.com/snapcore/snapd/pull/6267 | 16:45 |
| mup | PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267> | 16:45 |
| zyga | +9,-5 :) | 16:45 |
| pstolowski | 6149 +1 | 16:45 |
| zyga | woot, thanks | 16:45 |
| pstolowski | reviewed it yesterday and forgot to conclude | 16:45 |
| mup | PR snapd#6149 closed: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns 🐎> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6149> | 16:45 |
| mup | PR snapd#6262 closed: apparmor: allow snap-update-ns access to common devices <Simple 😃> <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6262> | 16:46 |
| zyga | we'll be at 39 PRs soon | 16:47 |
| * cachio lunch | 16:54 | |
| xnox | zyga, yes. | 17:02 |
| zyga | xnox: great | 17:02 |
| zyga | xnox: cachio is confirming this, we should get the result today | 17:02 |
| xnox | zyga, whoop whoop | 17:02 |
| zyga | :-) | 17:02 |
| === pstolowski is now known as pstolowski|afk | ||
| ackk | hi, I'm hitting an issue with the python plugin. I have a dependency in the requirements.txt which is pulled from a git repo. so pip complains about finding stuff in the src/ dir, which I so far had workarounded with "rm -rf $SNAPCRAFT_STAGE/../src/*" in override-pull. This doesn't seem to work anymore when building in multipass as the srcdir is in a different location. is there a way to handle both cases? | 17:18 |
| kyrofa | Content interface question: can the default provider include a specific track? | 17:34 |
| kyrofa | (zyga I suppose that's a question for you) | 17:35 |
| zyga | kyrofa: I don't think so, it's not as unified yet | 17:47 |
| zyga | I'm afk now (grocery) but I can check for sure later | 17:47 |
| kyrofa | Thanks zyga | 17:47 |
| zyga | kyrofa: seems sensible to say default-provider: foo=edge | 17:47 |
| zyga | or something like that | 17:47 |
| zyga | we have that syntax (new syntax) in one place and will probably grow it | 17:48 |
| kyrofa | Or foo/edge ;) | 17:48 |
| kyrofa | Yeah... I know | 17:48 |
| zyga | no, the syntax is really foo=edge | 17:48 |
| zyga | not foo/edge | 17:48 |
| kyrofa | Haha, I know | 17:48 |
| zyga | ok :) | 17:48 |
| cachio | zyga, works | 17:57 |
| cachio | :) | 17:57 |
| cachio | https://paste.ubuntu.com/p/z4Vjz2jYYG/ | 17:57 |
| cachio | xnox, hey, I confirm that the fix works | 17:58 |
| cachio | I'll add steps to reproduce the test in the lp | 17:58 |
| xnox | cachio, cool, state so / comment on the bug report, including the version number of systemd that is included in your self-built core18 snap. | 17:59 |
| xnox | cachio, sru team want that there. | 17:59 |
| cachio | xnox, good, already adding that info | 18:00 |
| cachio | thanks | 18:00 |
| cachio | xnox, please tell me if it is ok the validation steps which I added | 18:05 |
| cachio | xnox, now I am gonna run the whole test suite to check there are no regressions | 18:16 |
| pitfd | join /galliumos | 18:51 |
| zyga | Thank you cachio! | 19:26 |
| cachio | zyga, np | 19:26 |
| sergiusens | zyga we do not support the Deb anymore. Maintenance mode only, do not expect new features there. I was off today and will be off tomorrow too so light weight answers is what you get 😂 | 20:27 |
| katamo | ha, so I'm feeling defeated today trying to move from the dump plugin to the proper python plugin. Error complains the executable in the bin/ directory does not exist | 20:52 |
| zyga | sergiusens: cool, thank you for sharing that | 21:08 |
| mup | PR snapd#6251 closed: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6251> | 21:09 |
| zyga | jdstrand: hello | 21:12 |
| zyga | jdstrand: I saw the feedback, thank you :) | 21:12 |
| zyga | jdstrand: I left some ideas for discussion | 21:15 |
| zyga | jdstrand: hey, pushed again, I think this time is it :) | 23:46 |
| zyga | it is it :) | 23:46 |
| zyga | now we clarly differentiate things with 0 features from not having things | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!