[03:31] <ghostnik11> hi i have a question about snap and getting firefox updated to the latest version? how can i, b/c apt and snap don't talk to each other and i want to have firefox updated to version 67 but in snap its only at 66
[03:39] <ghostnik11> okay i found the clue was to run command: sudo snap refresh
=== jkridner|pd is now known as jkridner_
=== jkridner_ is now known as jkridner
[05:33] <mborzecki> morning
[05:39] <mborzecki> brb, new kernel
[05:42] <mborzecki> and back
=== morphis5 is now known as morphis
[06:36] <zyga> mwhudson: perhaps, though I haven't seen any lately
[06:38] <zyga> good morning mborzecki
[06:38] <mborzecki> zyga: hey
[06:53] <zyga> brbr
[06:59]  * zyga dog walk and coffee
[06:59] <zyga> hey mvo
[07:01] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7091
[07:01] <mborzecki> mvo: morning
[07:01] <zyga> mborzecki: shall I split that ;D
[07:02] <zyga> and with that, I'll be back in 20
[07:04] <zyga> mborzecki: perhaps I should add one sub-variant first?
[07:06] <mvo> good morning mborzecki and zyga
=== pstolowski|afk is now known as pstolowski
[07:07] <pstolowski> hey
[07:09] <mborzecki> pstolowski: hey
[07:14] <zyga> back
[07:15] <zyga> good morning mvo, good morning pawel
[07:16] <zyga> mborzecki: perhaps I should really split the PR into something people won't run away from
[07:16] <mborzecki> zyga: hmm maybe start with core16 or 18 first and drop qemu
[07:16] <zyga> mvo: *the* test https://github.com/snapcore/snapd/pull/7091/files
[07:16] <zyga> mborzecki: +1
[07:16] <zyga> mborzecki: good idea on qemu
[07:16] <zyga> it's x2 the data with qemu
[07:17] <mborzecki> zyga: the tool doesn't support comments in mountinfo dumps, wonder whether it'd be useful to add some annotation to the expected outputs
[07:17] <zyga> mborzecki: hmmm, that would be pretty easy
[07:21] <mborzecki> zyga: prbably the test should include backends: [-autopkgtest] too ?
[07:21] <zyga> good idea, I was thinking about how to block backends for qemu
[07:24] <jamesh> zyga: could you restart this CI run for me?  It looks like it got stuck some how.  https://travis-ci.org/snapcore/snapd/builds/557127004
[07:24] <zyga> sure
[07:25] <zyga> done
[07:25] <jamesh> it'd be nice if Travis let regular users restart jobs associated with their own PRs
[07:28] <zyga> mborzecki: done, only google is used now
[07:56]  * zyga does reviews
[08:44] <mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/7087 is probably harmless to land, the gadget code uses noop updaters, so we'll at least have the edition and checks logic executed at this point
[08:46] <mborzecki> pedronis_: i can tweak the existing spread test for gadget update to only go through updating the snap, without verifying whether the content was updated, and add it to the PR
[08:47] <pstolowski> mvo: re what we discussed yesterday evening - https://github.com/snapcore/snapd/pull/7092
[08:48] <mvo> pstolowski: thanks, looking
[08:48] <mvo> pstolowski: I'm reviewing your patch PR now btw
[08:48] <pstolowski> mvo: no pressure, this needs to wait for other stuff anyway
[08:48] <mvo> (finally, sry for the delay)
[08:48] <pstolowski> no worries
[08:54]  * zyga fixes leaky tests
=== pedronis_ is now known as pedronis
[08:57] <pedronis> mborzecki: sorry, not sure I follow, anyway chasing other things atm
[08:57] <pedronis> mvo: pstolowski: seems we all forgot about this code:  https://github.com/snapcore/snapd/blob/master/snap/info_snap_yaml.go#L243
[08:57] <mborzecki> pedronis: ok, np, we can sync later
[08:58] <zyga> but must me my "lucky" time, I ran this many times on all the suites and it didn't fail
[08:58] <zyga> I propose my PR and WHAM
[08:58] <zyga> but that's ok :)
[08:58] <zyga> one test seems to leak netns mount
[08:58] <zyga> should be easy
[09:00] <pstolowski> pedronis: i removed it in 7083 with the assumption that it's either set correctly by us or comes correct from the store, does it make sense?
[09:01] <pedronis> pstolowski: I think it will should be removed when we add type: snapd to snapcraft.yaml
[09:02] <pstolowski> pedronis: so maybe #7092 should land first (once new snapcraft is in stable)?
[09:02] <ackk> jdstrand, hi, would it be possible to get a new deb (or snap if it's easier) for the patched snapd with users support, based on the current master? it'd help us testing the fixes to interfaces you recently landed (like running systemd-detect-virt and accessing /proc/sys files)
[09:03] <pedronis> pstolowski: maybe,  it would avoid this: https://github.com/snapcore/snapd/pull/7083/files#diff-556bb7431481e375713ea3e0883a771a
[09:03] <pstolowski> pedronis: indeed
[09:04] <pedronis> but I don't want to block John either
[09:06] <Chipaca> 👋
[09:15] <pstolowski> sergiusens: hey, what's the timeframe for "snapd" type support in snapcraft to hit "stable"?
[09:22] <popey_> pstolowski: what does that mean?
[09:22] <pstolowski> zyga: woah @ 7091
[09:23] <pstolowski> popey_: i've landed a small enhancement in snapcraft to support "type:snapd", we need it in stable to proceed with symmetric changes in snapd code
[09:23] <zyga> pstolowski: it's half the size as in the morning :)
[09:23] <popey_> neat
[09:25] <pstolowski> zyga: nice. i finally get the big picture of all the python PRs i looked at recently ;)
[09:26] <zyga> pstolowski: it's not over yet, now to combat leaky tests
[09:29] <pstolowski> zyga: looking at it, this looks super nice (i hope it's not going to surprise us with unexpected failures)
[09:29] <zyga> pstolowski: I'm sure it will a little, I just fixed a leaky netns test
[09:30] <zyga> but I hope not that  many
[09:30] <zyga> I'm looking at changing spread.yaml to ensure leaky tests are "caught"
[09:30] <zyga> but yeah, took some pain to get to the point where it generally works okay and when it fails, it can be reliably said to show something being wrong elsewhere
[09:32] <zyga> pstolowski: the only "late" addition is classic, since we want to start changing classic confinement I thought those extra tests would be useful
[09:33] <pstolowski> zyga: i see, indeed, sounds like a good plan
[09:37] <sergiusens> pstolowski wrapping up a couple of uc20 related PRs and doing a release. I am off today and tomorrow, so most likely next week and once tagged and in candidate the speed depends on how fast people respond to the call for testing (and how out more exhaustive tests go)
[09:38] <pstolowski> sergiusens: sounds good, thank you. fwtw i tested yesterday's snapcraft from edge with snapd and type:snapd
[09:57] <pstolowski> zyga: reviewed
[09:59] <zyga> pstolowski: thanks!
[10:05] <pstolowski> zyga: replied
[10:13] <zyga> thanks
[10:13] <zyga> I'm running all tests in a loop and just got another clean pass, hopefully the netns one was a one-off
[10:14] <zyga> and having fixed that test we will not see other tests resurface
[10:17] <pstolowski> nice
[10:18]  * pstolowski early lunch & an errand
[10:21] <mvo> pstolowski: silly question, in an ideal world where we have all the information, when would we do the reset of the sublevel for level60? the old code checked for revno 5332, does that mean (in an ideal world with all the data) we would only reset the sublevel if we come from something older than 5332? if we are on a newer revno, would we ever need to reset the sublevel?
[10:35] <mvo> pstolowski: replied in the pr, if you don't mind I would like to squash 7016 and cherry pick to 2.40
[10:53] <zyga> brb
[11:12] <zyga> re
[11:36] <zyga> I'm merging the mount-ns test with the MS_SHARED branch locally, on very quick inspection the mount namespaces actually look good!
[11:36] <zyga> :)
[11:36] <zyga> I haven't moved to core yet, just classic for now
[11:37] <zyga> I will probably write a new test as well, to show how specific things are set up (e.g. /home across all three) to show that propagation is good (in a manner more readable then the full dump)
[11:51] <zyga> interfaces-contacts-service test failing https://www.irccloud.com/pastebin/LoVplaZj/
[11:54] <pedronis> cachio mentioned there's a timing issue there and was looking into that
[11:58] <jdstrand> ackk: sure. I'll be spending some time on that pr today so will give it to you after that
[12:00] <ackk> jdstrand, thanks!
[12:02] <mborzecki> zyga: this PR from cachio: https://github.com/snapcore/snapd/pull/7088 through i'm not certain about the fix
[12:04] <zyga> mborzecki: interesting, looking
[12:04] <zyga> hey jdstrand
=== ricab is now known as ricab|lunch
[12:37] <zyga> the new test is fantastic
[12:38] <zyga> MS_SHARED causes quarter of mount points to go away
[12:38] <zyga> on core16
[12:39]  * zyga goes to analyze why
[12:44] <Eighth_Doctor> zyga, mborzecki: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/
[12:45] <Eighth_Doctor> zyga, mborzecki: this is kind of a crappy thing to wake up today
[12:45] <mborzecki> Eighth_Doctor: heh
[12:45] <mborzecki> pedronis: mvo: ^^
[12:45] <Eighth_Doctor> I didn't know you guys were planning on discontinuing effort on g-s-snap
[12:46] <Eighth_Doctor> I wish I had been told about this ahead of time so that I could have had a contingency plan for this...
[12:46] <pedronis> Wimpress: willcooke: ^
[12:47] <mborzecki> Eighth_Doctor: thanks for the heads up anyway!
[12:47] <Eighth_Doctor> a number of my friends and colleagues actually use snaps through g-s, since Fedora Workstation is the main variant people use
[12:47] <willcooke> We are going to continue to maintain the g-s snap plugin
[12:47] <Eighth_Doctor> and whenever folks installed snapd in Fedora, it would auto-install the plugin, giving people a seamless experience :(
[12:48] <willcooke> kenvandine, ^
[12:48] <Eighth_Doctor> what am I supposed to do for GNOME people now?
[12:48] <zyga> brb
[12:48] <Eighth_Doctor> willcooke: can someone _please_ reply to this thread on devel@ so that they know that, because right now this looks kind of bad... and I just started working on my presentation for Flock on snaps too :(
[12:49] <zyga> Eighth_Doctor: I wasn't aware of this until a few days ago
[12:49] <Eighth_Doctor> the worst part is I'm finding this out because of Phoronix
[12:49] <Eighth_Doctor> https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Software-Dropping-Snap
[12:50] <Chipaca> Eighth_Doctor: FWIW I found out because of askubuntu :-|
[12:50] <Eighth_Doctor> wtf 😕
[12:51]  * Chipaca always reads that as "as kubutu" and then is disappointed
[12:51] <Chipaca> Eighth_Doctor: sorry i meant omgubuntuwtfbbq
[12:51] <Chipaca> Eighth_Doctor: https://www.omgubuntu.co.uk/2019/07/devs-want-to-drop-snap-support-from-gnome-software
[12:51] <Eighth_Doctor> ah that site
[12:51] <Chipaca> Eighth_Doctor: frain bart
[12:51] <Eighth_Doctor> oh god
[12:51] <Chipaca> Eighth_Doctor: don't read the comments
[12:51] <Chipaca> Eighth_Doctor: just, don't
[12:52] <Chipaca> zyga did and he is lost to us now
[12:53] <pedronis> Chipaca: zyga: mvo and me have a different meeting that clashes with the standup today
[12:53] <Chipaca> holidays for everybody \o/
[12:54] <Eighth_Doctor> Chipaca: damn it, I hate people now
[12:54]  * Chipaca hugs Eighth_Doctor 
[12:54] <zyga> pedronis: ack
[12:56] <Chipaca> Eighth_Doctor: when did we promise sandboxing support, btw?
[12:56] <willcooke> kenvandine, can you ask Robert to reply to that thread? ^
[12:57] <Eighth_Doctor> Chipaca: from the beginning, I think? though it hasn't worked in Fedora until very recently
[12:57] <Eighth_Doctor> though non-Ubuntu snap sandboxing is much more rudimentary than Ubuntu snap sandboxing
[13:01] <zyga> Chipaca: are you coming?
[13:01] <kenvandine> willcooke: Will do
[13:05] <Chipaca> zyga: nah, i'm good
[13:05] <Chipaca> :-p
[13:21] <jdstrand> hey zyga :)
[13:28] <cachio> Chipaca, hey, about the snap pack option, what is that?
[13:30]  * zyga quick lunch
[13:31] <Chipaca> cachio: which is the test in question?
[13:31] <cachio> Chipaca, failover
[13:32] <Chipaca> cachio: tests/main/failover, or tests/core18/snapd-failover?
[13:32] <cachio> Chipaca, tests/main/failover
[13:33] <Chipaca> cachio: so, to see if it fixes the issue, we'd change the 'snap pack' to a mksquashfs
[13:33] <cachio> Chipaca, ah, ok
[13:33] <Chipaca> cachio: if it does, we can then look into a low-mem 'snap pack'
[13:33] <cachio> I'll try it
[13:33] <cachio> thanks
[13:33] <Chipaca> cachio: you know all the mksquashfs flags needed?
[13:33] <cachio> Chipaca, no
[13:34] <Chipaca> 1 sec :)
[13:34] <Chipaca> cachio: it's packing core, yes?
[13:39] <cachio> yes
[13:41] <cachio> Chipaca, ~
[13:41] <Chipaca> cachio: give me a bit
[13:42] <cachio> Chipaca, sure
[13:44] <zyga> Chipaca: we repackage core in tests
[13:44] <zyga> Chipaca: in prepare
[13:44] <zyga> Chipaca: just don't pass -comp xz
[13:46] <Chipaca> zyga: exactly
[13:48] <Chipaca> cachio: /snap/core/current/usr/bin/mksquashfs "$BUILD_DIR/unpack" "./core_<something something>.snap" -noappend -comp gzip -no-fragments -no-progress
[13:48] <cachio> Chipaca, perfect, thank you very much
[13:49] <Chipaca> cachio: I *think* the "./core_<...>.snap" is just "failing.snap" (and you skip the mv)
[13:49] <cachio> Chipaca, yes
[13:50] <Chipaca> cachio: following zyga's lead, note you could also instead load lib/snaps.sh and use mksnap_fast
[13:52] <cachio> Chipaca, nice, I'll try that also
[13:52] <cachio> and see which works better
[13:52] <cachio> also I need to velidate that on the boards because there we have just 1 gb of RAM
[14:53] <zyga> re, back from calls
[15:12]  * cachio afk
[15:25] <ijohnson> hey zyga are there any more mountinfo-tool PR's you need me to look at? or is the MS_SHARED PR ready to use those changes?
[15:25] <zyga> ijohnson: no, that's all
[15:26] <ijohnson> zyga: ack I'm just gonna focus on the snapctl netplan-apply stuff today then
[15:26] <zyga> ijohnson: ack, thank you
[15:54] <mvo> Eighth_Doctor: hey, sorry I am in meetings but I was unware of what was happening I will figure out what happend
=== pstolowski is now known as pstolowski|afk
[16:35] <roadmr> jdstrand: the tools update from yesterday is now in prod \o/
[16:55] <Eighth_Doctor> mvo: thanks
[17:48] <jdstrand> roadmr: thanks! :)
[17:48] <jdstrand> roadmr: that was fast :)
[18:01] <zyga> re
[18:01]  * zyga goes to debug leaky test
[18:13] <mvo> sergiusens: I get ""snapcraft-josm:/var/cache/snapcraft/snaps" is already mounted" when running snapcraft pull - how can I fix this? any suggestions? I tried to stop the multipass machine but that was not enough
[18:18] <sergiusens> mvo might need to Snapcraft clean first but would appreciate if the state before that is discussed with Saviq or ChrisTownsend
[19:45] <cachio> zyga, hey
[21:01] <zyga> cachio: hey
[21:06] <cachio> zyga, quick question
[21:06] <zyga> yeah?
[21:07] <cachio> running the test base-migration
[21:07] <cachio> I run test-snapd-core-migration.sh -c "cat /usr/lib/os-release"
[21:07] <cachio> and it is not creating the file /run/snapd/ns/snap.test-snapd-core-migration.info
[21:07] <cachio> on ubuntu core on rpi
[21:08] <zyga> is the version of snapd in sync with the test?
[21:08] <zyga> cachio: the .info file is created unconditionally
[21:08] <zyga> cachio: so I suspect it's just old snapd/core
[21:08] <zyga> cachio: running against "new" tests
[21:08] <cachio> core from beta
[21:08] <cachio> this fails running beta validation
[21:08] <zyga> I don't know if this is recent enough
[21:09] <cachio> 2.40
[21:09] <zyga> all I'm saying is that it indicates snap-confine is just  older than the test
[21:09] <cachio> zyga, ah
[21:09] <cachio> weird because I use the beta branch
[21:10] <cachio> for the test
[21:10] <zyga> 77e3ff647bd40764a0ab366cb0b4cfdc8157ff3f
[21:10] <zyga> this is the merge commit for the feature
[21:10] <zyga> if you can check that it is present in the build you can know
[21:11] <zyga> you can also look for this debug message visible when SNAP_CONFINE_DEBUG=yes is set:
[21:11] <zyga> debug("saved mount namespace meta-data to %s", info_path)
[21:12] <cachio> zyga, https://paste.ubuntu.com/p/hQkM4cvXBm/
[21:13] <zyga> yeah, this looks good
[21:13] <cachio> zyga, ok, I'll check if the variable is set
[21:13] <zyga> you can run "strings" on snap-confine to check
[21:15] <cachio> how could I run it ?
[21:19] <zyga> cachio: re
[21:19] <zyga> cachio: just "strings"
[21:19] <zyga> it's a command name
[21:19] <zyga> just run it on the snap-confine binary
[21:19] <zyga> if it shows something similar to the debug message I pasted then that binary has that patch
[21:20] <zyga> if it doesn't it is not the right snap-confine
[21:20] <zyga> maybe the build system is stuck?
[21:21] <cachio> test@localhost:~$ /usr/lib/snapd/snap-confine strings
[21:21] <cachio> Usage: snap-confine <security-tag> <executable>
[21:21] <cachio> executable name was not provided
[21:21] <zyga> cachio: the binary is strings
[21:21] <zyga> strings  /path/to/snap-confine
[21:21] <cachio> ahh
[21:21] <zyga> don't run strings through snap-confine :)
[21:23] <cachio> external:ubuntu-core-16-arm-32 .../tests/main/base-migration# sudo /snap/core/7345/usr/share/bash-completion/completions/strings /usr/lib/snapd/snap-confine
[21:23] <cachio> sudo: /snap/core/7345/usr/share/bash-completion/completions/strings: command not found
[21:23] <zyga> cachio: copy the binary to another system?
[21:23] <cachio> ok
[21:26] <cachio> zyga, no output running in my machine
[21:27] <cachio> I copied both binaries
[21:27] <zyga> cachio: what do you mean no output? nothing at all?
[21:27] <zyga> cachio: both?
[21:27] <cachio> nothing
[21:27] <cachio> zyga,  yes both
[21:27] <zyga> cachio: that's unexpected, there are surely other strings there
[21:27] <zyga> do you mean that nothing when piped through grep?
[21:27] <zyga> or entirely nothing?
[21:27] <cachio> nothing nothing :)
[21:28] <zyga> cachio: is the file empty?
[21:28] <zyga> you can look at the snap-confine binary yourself to assure yourself that it is full of text
[21:28] <zyga> so something must be fishy
[21:28] <cachio> https://paste.ubuntu.com/p/pcJQDyWwQp/
[21:28] <zyga> zyga@yantra:~/snapd> strings /usr/lib/snapd/snap-confine  | wc -l
[21:28] <zyga> 1100
[21:29] <zyga> how did you copy strings?
[21:29] <zyga> or actually
[21:29] <zyga> scratch that
[21:29] <cachio> scp
[21:30] <zyga> can you not copy strings but actually just snap-confine from the device under test
[21:30] <zyga> and then run strings on your system against that binary
[21:30] <zyga> look at what I pasted above ^
[21:30] <zyga> it has over a thousand strings recognized
[21:30] <zyga> so either your binary is empty
[21:30] <cachio> using the strings comman on my machine
[21:31] <zyga> or you didn't run the same strings command I did
[21:31] <cachio> and the snap-confine from the rpi3
[21:31] <cachio> I get 1240
[21:31] <zyga> ah, so it's not nothing?
[21:31] <zyga> so what changed, I'm confused
[21:31] <cachio> I used the strings command on my machine
[21:31] <zyga> but that's what you did before, no?
[21:31] <zyga> aynway
[21:31] <zyga> can you grep for that debug message please?
[21:32] <cachio> sure
[21:33] <cachio> sergio@cachiomachine:~/workspace/validator/images$ strings ./snap-confine | grep SNAP_CONFINE_DEBUG
[21:33] <cachio> SNAP_CONFINE_DEBUG
[21:33] <zyga> don't grep for SNAP_COFNINE_DEBUG
[21:33] <zyga> grep for the debug message that was added the merge patch
[21:34] <zyga> debug("saved mount namespace meta-data to %s", info_path)
[21:34] <cachio> zyga, that one does not appear
[21:34] <zyga> in that case the build is out of sync with the tests
[21:35] <cachio> zyga, ok, that explains everything
[21:35] <cachio> I'll talk to mvo tomorrow about that
[21:35] <cachio> zyga, thanks for the support
[21:36] <zyga> happy to help, good luck!
[21:50] <cachio> zyga, the weird part is that it works well on pc-amd64 and pc-i386
[21:50] <zyga> is that debug message present there?
[21:50] <cachio> not sure yet
[21:50] <cachio> I am creating the image agin
[21:50] <cachio> again
[22:12] <cachio> zyga, I think the problem is that the test was merged into release/2.40 after the beta core was created and before the tests were executed
[22:13] <cachio> zyga, I'll continue tomorrow with that one
[22:13] <cachio> see you
[22:24] <jdstrand> ackk: fyi, https://people.canonical.com/~jamie/snapd-daemon-user/