[06:10] <mborzecki> morning
[07:04] <zyga> Good morning
[07:21] <mborzecki> zyga: hey
[07:21] <mborzecki> zyga: do you know who controls strace-static snap?
[07:22] <mborzecki> is it only mvo?
[07:22] <zyga> I believe so
[07:22] <zyga> What do you need?
[07:23] <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:27] <zyga> Mmm
[07:28] <zyga> Is 4.24 compatible with other distributions?
[07:32] <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:34] <mborzecki> one last spread run and i'll be opening a PR with Fedora 29
[07:50] <zyga> Ok
[07:51] <zyga> I will be around in 30 minutes
[07:53] <zyga> As usual, worked late last night
[08:12] <pstolowski> heyas
[08:20] <mborzecki> pstolowski: hey
[08:35] <zyga> back now
[08:35] <zyga> good morning pawel
[08:36] <zyga> how are you guys?
[08:39] <zyga> sorry for being sleepy, I was pushing some things last night
[08:40] <zyga> are we still affected by the issue where our logs are too long for travis?
[08:45] <mup> PR snapd#6264 opened: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
[08:47] <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:50] <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:51] <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:52] <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:53] <zyga> mborzecki: when snap-confine, reexecuting, is linked to libc not present in core16
[08:54] <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:55] <zyga> as other tools will still execute on the outside
[08:55] <zyga> thanks
[08:57] <mborzecki> zyga: that shebang being rewritten from #!/bin/sh to #!/usr/bin/sh is probably some usr-merge thing again
[08:58] <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:59] <zyga> so perhaps something failed earlier on and the script nonetheless advanced
[08:59] <zyga> though I still don't grasp the details
[09:04] <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:05] <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:15] <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:16] <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:19] <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:20] <mborzecki> pstolowski: were there any rules in place when iptables-save was called?
[09:22] <pstolowski> mborzecki: no (and in such case iptables-save creates a kind empty file with empty chains)
[09:23] <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:24] <pstolowski> mborzecki: yes
[09:24] <pstolowski> zyga: interesting theory
[09:25] <pstolowski> trying without iptables save/restore now, if it works i'm gonna leave it like that
[09:30] <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:45] <mborzecki> damn, hitting unrelated errors in the PRs
[09:45] <mborzecki> appstream-id, refresh-all :/
[09:45] <mborzecki> and mount thing obviously too
[09:50] <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
[10:09] <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:10] <pstolowski> k
[10:17] <mborzecki> zyga: about that xdg-desktop-portal: https://paste.ubuntu.com/p/nkFc5FJ3Qc/
[10:18] <zyga> mmm
[10:18] <mborzecki> but i don't see what requires that really
[10:18] <zyga> we require it
[10:19] <mborzecki> zyga: well, it's not listed anywhere in the spec
[10:20] <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:21] <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:22]  * zyga -> tea
[10:24] <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:25] <mborzecki> zyga: heh i can actually remove xdg-desktop-portal and none of snapd components are removed
[10:42] <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:49] <mborzecki> pstolowski: if you could do this one too: https://github.com/snapcore/snapd/pull/6260
[10:50] <mup> PR #6260: spread, tests: use checkpoints when dumping audit log <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6260>
[10:51] <mborzecki> zyga: no clue what's happening with dependencies there, left a note in the PR for now
[10:51] <zyga> sounds good
[10:57] <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:58] <mborzecki> heh
[11:01] <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:08] <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:20] <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:21] <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:24] <mborzecki> pstolowski: thanks!
[11:27] <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:28] <cachio> which found that error
[11:28] <cachio> which still fail
[11:29] <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:31] <zyga> cachio: that's fine, unless you want me to
[11:32] <cachio> ok, I'll explain more during the standup
[11:51] <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:52] <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:53] <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:54] <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:56] <zyga> mborzecki: any action needed on F29 PR in light of the weak dependency fact?
[11:57] <mborzecki> zyga: i'm running the fix under spread right now
[11:57] <zyga> ok
[12:01] <mborzecki> that umask thing keeps popping up
[12:01] <zyga> hmmm
[12:01] <zyga> tests leaking
[12:01] <zyga> or something else?
[12:02] <mborzecki> zyga: the test that passed on travis and locally before failed right now
[12:04]  * cachio afk
[12:04] <zyga> I'm back to debugging set -e bug
[12:11] <zyga> waaat?!!?
[12:17] <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:18] <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:19] <jamesh> zyga: there is no reference test-snapd-dbus-service in the tests/ directory of snapd master
[12:19] <zyga> ok
[12:20] <jamesh> it originates from mvo's old abandoned PR
[12:22] <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:23] <jamesh> zyga: I don't think so.
[12:23] <zyga> ok, I'll merge it manually then
[12:24] <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:25] <zyga> hopefully more reviews will resume next week
[12:26] <jamesh> I'm sure there's still problems to discover once my spread tests run on all distros
[12:32] <zyga> hmm
[12:32]  * zyga doesn't recall bzr specific weirdness
[12:32] <zyga> jamesh: I _think_ it is merged
[12:33] <zyga> yep
[12:43] <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:58] <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:59] <mborzecki> omg, damn, it is
[13:03] <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:06] <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:31] <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:34] <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:42] <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:43] <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:51] <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:53] <pstolowski> zyga: ok, will do
[14:16] <mborzecki> zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
[14:24] <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:25] <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:30] <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:31] <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:32] <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:33] <zyga> cachio: may I ask how you checked the version of systemd that you observed?
[14:34] <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:35] <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:36] <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:37] <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:38] <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:40] <cachio> so, we build core18 snap we use the deb snapd.deb we already created
[14:41] <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:42] <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:43] <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:44] <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:45] <cachio> zyga, what I did is to enable proposed on this instance
[14:46] <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:47] <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:48] <zyga> My understanding is that the core18 snap is coming from the store
[14:48] <zyga> And that it contains systemd
[14:49] <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:51] <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:52] <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:53] <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:54] <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:56] <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:59] <diddledan> who can kick the store review thingy for me? gog-galaxy-wine revision 62 is stuck
[15:01] <cachio> zyga, at least core is not built from proposed
[15:01] <cachio> zyga, I can't see the recipy for core18
[15:02] <jlorenzo> oSoMoN: got it! thank you very much for the help :)
[15:03] <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:06] <zyga> re
[15:06] <zyga> cachio: no, build core18 with systemd from proposed
[15:06] <zyga> cachio: snapd.snap version is irrelevant
[15:07] <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:08] <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:11] <cachio> zyga, sure, comment left
[15:11] <zyga> super, thank you
[15:11] <cachio> zyga, thanks for the help
[15:23] <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:29] <zyga> xnox: who builds the core18 images now, is that foundations?
[15:29] <zyga> sorry, I was imprecise, I meant core18.snap
[15:31] <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:32] <cachio> zyga, I searched on launchpad and couldn't find it
[15:32] <cachio> at least in our projects
[15:33] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:45] <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:47] <xnox> zyga, cachio - even if foundations build it, it's not built with proposed on..... i don't think.....
[15:48] <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:54] <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:57] <cachio> zyga, great, thanks
[16:00] <zyga> cachio: ok, I have a core18 now
[16:00] <zyga> cachio: can you try this locally please:
[16:01] <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:02] <zyga> sed -i -e 's/current/pending/g' Makefile
[16:03] <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:05] <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:06] <zyga> cachio: then you can run a test against that
[16:08] <cachio> nice
[16:08] <cachio> on that
[16:09] <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:13] <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:14] <zyga> cachio: you can verify the manifest to be sure as well
[16:14] <cachio> zyga, yes,
[16:19] <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:21] <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:22] <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:23] <zyga> let me know if you have issues
[16:23] <zyga> I can probably build a kvm image and test locally
[16:32] <zyga> pstolowski: can you explain what you meant on https://github.com/snapcore/snapd/pull/6251#discussion_r239132132 ?
[16:33] <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:38] <zyga> pstolowski: more errors
[16:38] <pstolowski> zyga: uhm, thanks, checking
[16:38] <zyga> https://www.irccloud.com/pastebin/Bg0hqSL4/
[16:39] <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:40] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <zyga> we'll  be at 39 PRs soon
[16:54]  * cachio lunch
[17:02] <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:18] <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:34] <kyrofa> Content interface question: can the default provider include a specific track?
[17:35] <kyrofa> (zyga I suppose that's a question for you)
[17:47] <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:48] <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:57] <cachio> zyga, works
[17:57] <cachio> :)
[17:57] <cachio> https://paste.ubuntu.com/p/z4Vjz2jYYG/
[17:58] <cachio> xnox, hey, I confirm that the fix works
[17:58] <cachio> I'll add steps to reproduce the test in the lp
[17:59] <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.
[18:00] <cachio> xnox, good, already adding that info
[18:00] <cachio> thanks
[18:05] <cachio> xnox, please tell me if it is ok the validation steps which I added
[18:16] <cachio> xnox, now I am gonna run the whole test suite to check there are no regressions
[18:51] <pitfd> join /galliumos
[19:26] <zyga> Thank you cachio!
[19:26] <cachio> zyga, np
[20:27] <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:52] <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
[21:08] <zyga> sergiusens: cool, thank you for sharing that
[21:09] <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:12] <zyga> jdstrand: hello
[21:12] <zyga> jdstrand: I saw the feedback, thank you :)
[21:15] <zyga> jdstrand: I left some ideas for discussion
[23:46] <zyga> jdstrand: hey, pushed again, I think this time is it :)
[23:46] <zyga> it is it :)
[23:48] <zyga> now we clarly differentiate things with 0 features from not having things