[03:00] <mup> PR snapcraft#2408 closed: multipass: avoid stdin where possible <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2408>
[06:08] <mborzecki> morning
[07:14] <mborzecki> mvo: morning
[07:19] <mvo> hey mborzecki - good morning
[07:34] <zyga> Hey
[07:34] <zyga> Oh boy, winter is coming
[07:36] <zyga> mborzecki: RHEL 8 has very recent kernel
[07:37] <mborzecki> zyga: and a very far relase date :)
[07:57] <zyga> What is the release date?
[08:00] <mborzecki> zyga: when it's ready
[08:00] <mborzecki> zyga: i don't think they've annouced anything yet
[08:00] <zyga> Mmm
[08:03] <pstolowski> morning
[08:05] <mborzecki> pstolowski: hey hey
[08:10] <mborzecki> 2.36 branch is failing all the time
[08:10] <mborzecki> the travis job
[08:13] <mborzecki> google:opensuse-42.3-64:tests/main/interfaces-openvswitch-support is failing, i'd be surprised if it's https://bugzilla.opensuse.org/show_bug.cgi?id=1115168
[08:29] <mup> PR snapd#6152 closed: spdx: update licenses to current data <⛔ Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6152>
[08:30] <mborzecki> there's something messed up with our opensuse-42.3 images, they are not 43.2 but leap 15.0, https://paste.ubuntu.com/p/ZYFc8Rkjq4/
[08:31] <mborzecki> i guess cachio is the only one who can fix it?
[08:33] <mvo> mborzecki: yeah, I think so - we can set opensuse to manual though to unblock us
[08:36] <pedronis> mvo: hi, I closed the spdx PR for now, it needs some more thoughts, we also need to check what we did about licenses in our oldest releases out (debian? 16.04 active images?)
[08:36] <mup> PR snapd#6163 opened: interfaces: tweak deny-auto-connect policy tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6163>
[08:36] <mvo> pedronis: yeah, thats fine
[08:36] <mvo> pedronis: I agree this needs more work
[08:38] <pedronis> mvo: the personal/system-files PR needs a jdstrand re-review, right?  I haven't really done a review myself yet, just gone over some bits, also sorry, not sure if I put some comments at the wrong place, or the code changed under them
[08:38] <mvo> pedronis: your comments were useful, I addressed them now
[08:39] <mvo> pedronis: yeah, jdstrand should look at this again, I added the allow-install: false now
[08:39] <pedronis> yes, saw that
[08:39] <pedronis> thanks
[08:41] <pedronis> zyga: mvo: I saw we put some bug cards (with landed PR) in the Done column, shouldn't they go in the cur release column?
[08:41] <mvo> pedronis: I think so, this may require a 2.36 colum now that we have backported some of the bugfixes
[08:42] <pedronis> or a backport label
[08:42] <pedronis> but yes
[08:42] <mvo> pedronis: yeah, or that :)
[08:44] <pedronis> mvo: were they backported already?
[08:44] <mvo> pedronis: yes, let me double check but yes, we pulled into 3 PRs into 2.36 yesterday
[08:45] <pedronis> one doesn't have a card
[08:45] <pedronis> (it's ok)
[08:45] <pedronis> mvo: yet, another approach is indeed two columns, and copy the cards
[08:47] <mvo> pedronis: or we put the card just in 2.36 and assume that whatever bugfix we did there automatically is also in all higher versions (which is generally true because we always cherry-pick from master)
[08:47] <pedronis> yes, that's usually the case
[08:47] <pedronis> let's try that
[08:47] <mvo> great
[08:48] <pedronis> mvo: does it look right now?
[08:53] <mvo> pedronis: yeah - looks good, I would switch the order 2.36 and 2.37 (so that its from lower to higher) but thats a) nitpick b) personal preference
[09:00] <zyga> pedronis: re, I think you may be right, let me re-read the trello rules post
[09:01] <zyga> pedronis: thank you for moving them to the appropriate lanes
[09:03] <pedronis> zyga: I'm not sure the rules explain the done lanes
[09:03] <pedronis> I can add that
[09:08] <zyga> tumblweed moved to 4.19
[09:08] <pedronis> mvo: zyga: I added a para about the done lanes into the rules
[09:08] <pedronis> hope it makes sense (I hope it makes a bit also without reading them tough)
[09:16] <pstolowski> zyga: i've just did snap run --shell gnome-calculator and got this:
[09:17] <pstolowski> https://www.irccloud.com/pastebin/TVwffLQo/
[09:17] <pstolowski> zyga: expected?
[09:17] <zyga> nope
[09:17] <zyga> some of those are bugs in the theme
[09:17] <zyga> that are quite unexpected since they were reported months ago
[09:17] <zyga> but the last few are certainly unexpected
[09:17] <zyga> is this on master?
[09:18] <pstolowski> zyga: i'm on edge, 2.36.1+git1017.fdb9926~ubuntu16.04.1
[09:18] <zyga> thank you, I will check this out
[09:19] <zyga> "fun" (not)
[09:19] <pstolowski> zyga: gnome stuff is from stable
[09:19] <mborzecki> pstolowski: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540/1
[09:19] <zyga> pstolowski: can you file the bug about /snap/
[09:20] <pstolowski> zyga: sure
[09:20] <mborzecki> $SNAP/share/sounds is missing entirely, and Saru icon theme is a symlink
[09:20] <zyga> rebooting and jumping into this
[09:21] <mborzecki> pstolowski: there's a github issue as well https://github.com/snapcrafters/gtk-common-themes/issues/16 can you add it to the topic?
[09:23] <zyga> oho
[09:23] <zyga> 4.19 is not working too great with snaps
[09:23] <mborzecki> zyga: 4.19.1-arch1-1-ARCH, didn't notice anything special, what does not work in your setup?
[09:24] <zyga> type=AVC msg=audit(1542360228.183:306): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/tmp/snapd.quirks_fAGbSk/" pid=4922 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
[09:24] <zyga> zyga@yantra:~> snap run gnome-calculator
[09:24] <zyga> cannot create temporary directory for /var/lib/snapd mount point: Permission denied
[09:24] <mborzecki> hm, profile update?
[09:24] <pedronis> is that the kernel really? or selinux?
[09:25] <pedronis> zyga: also if it's hairy can you take a note and look more later?
[09:25] <zyga> pedronis: sure
[09:25] <zyga> I wonder if this is because I have been hacking on this machine
[09:25] <zyga> probably so, let me just reinstall the package
[09:25] <zyga> pedronis: on suse there's just apparmor, no selinux
[09:25] <pedronis> ok
[09:26] <zyga> yes :)
[09:26] <zyga> uff
[09:26] <zyga> I didn't have the permission to do quirks because I was hacking on quirks removal here
[09:26] <zyga> all is good
[09:26] <zyga> looking at the theme issue
[09:30] <Chipaca> pedronis: morning. Do I understand correctly that you think having the 0 epoch (or rather, anything that serialises back to "0") deserialise to unset is the best approach?
[09:30] <Chipaca> pedronis: (I think I agree, but wanted to confirm before implementing it -- in the same pr?)
[09:30] <pstolowski> zyga: not sure if i described it correctly, but here you go: https://bugs.launchpad.net/snapd/+bug/1803687
[09:30] <mup> Bug #1803687: snap run --shell gnome-calculator gives a series of errors <snapd:New> <https://launchpad.net/bugs/1803687>
[09:31] <pedronis> Chipaca: yes, if we basically say internal unset [09:31] <pedronis> Chipaca: can be a follow up tough
[09:31] <pedronis> that PR is around since a while
[09:32] <pedronis> (relatively speaking, is not ancient in snapd PR terms)
[09:32] <Chipaca> pedronis: 8 days old, if you count the original homonymous pr, yes
[09:33] <Chipaca> pedronis: anything else I should do on this one and not the followup?
[09:38] <pedronis> Chipaca: you are asking because it's green ? :)
[09:40] <pedronis> Chipaca: there's the amend test revision to change, it's ok for a follow up if it doesn't get lost
[09:41] <zyga> thank you pawel
[09:43] <zyga> reproduced
[09:44] <pstolowski> great!
[09:47] <pedronis> mvo: do we have a edge build now for https://bugs.launchpad.net/tillamook/+bug/1802581 ?
[09:47] <pedronis> to announce
[09:47] <zyga> pedronis: I believe so, I can test on my device quicklyl
[09:48] <Chipaca> pedronis: was asking because the tests were green, and it's got a 'changes requested' from you :-)
[09:48] <zyga> refreshing to edge, i'll know in 3 minutes
[09:48] <mvo> pedronis: yeah, build 5h ago and landed last night but if its not trouble for zyga to double check lets wait for that first
[09:48] <pedronis> yes, that's fine
[09:51] <zyga> rebooting pi3-1
[09:53] <zyga> testing now
[09:54] <zyga> confirmed
[09:54] <zyga> edge allows to disable and enable the snap that previously reproduced the issue
[09:56] <zyga> mvo, pedronis: +1
[10:02] <pedronis> mvo: zyga: I'm writing something in the bug
[10:02] <zyga> thank you
[10:03] <pedronis> done
[10:05] <pedronis> Chipaca: I wrote what we discussed yesterday about restart SNAP etc here: https://bugs.launchpad.net/snapd/+bug/1803212
[10:05] <mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
[10:05] <mborzecki> zyga: if you have a rhel instance, can you `yum --enablerepo=epel-testing install snapd` and report feedback here https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b240f3418f ?
[10:06] <zyga> mborzecki: I don't have one handy now
[10:06] <zyga> mborzecki: actually, maybe I'm wrong
[10:06] <zyga> one sec
[10:06] <zyga> nope
[10:06] <zyga> I think I killed it
[10:08] <mborzecki> ah ok, nvm, i've given +1, snapd installs and runs on 7.6
[10:11] <pedronis> Chipaca: I have a remark, it seems all the store tests use either "0" or nil, no test with something a bit more interesting
[10:11] <pedronis> in epoch
[10:11] <pedronis> I also don't know if the change we plan affects that
[10:12] <Chipaca> pedronis: there is one snap.E("1*") in the store tests (for the amend case)
[10:13] <pedronis> Chipaca: yes, but nothing for context
[10:13] <Chipaca> hmmm
[10:13] <Chipaca> i'll see how things change with this
[10:13] <pedronis> I made a remark
[10:14] <zyga> pstolowski: ah
[10:14] <zyga> pstolowski: I think it's not terrible
[10:14] <zyga> I was worried this is a regression
[10:14] <zyga> I improved logging of trespassing events
[10:15] <pedronis> Chipaca: gave a +1 assuming you'll work through my wonderings :)
[10:15] <pedronis> in the follow up
[10:15] <Chipaca> mbuahaha
[10:15] <Chipaca> i mean, "yes of course"
[10:15] <Chipaca> :-p
[10:15] <zyga> pstolowski: quick question, was it failing to start in your case?
[10:15] <zyga> for me it starts ok
[10:15] <zyga> (as in, runs)
[10:16] <zyga> https://www.irccloud.com/pastebin/lBeg5CYb/
[10:16] <pstolowski> zyga: no, no, it worked (i used --shell)
[10:16] <zyga> look at line 1
[10:16] <zyga> this is really telling us this
[10:16] <zyga> the snap gnome-calculator
[10:17] <zyga> was trying to write to /snap/gtk-common-themes/808/share/sounds/Yaru
[10:17] <zyga> and that was refused
[10:17] <zyga> it was trying to write there because of a content connection
[10:17] <zyga> that's the "remote" end
[10:17] <zyga> but it is absent (not really in the snap)
[10:17] <zyga> so the code tried to make it
[10:17] <zyga> but it wasn't allowed to
[10:17] <zyga> that's all
[10:17] <zyga> interesting
[10:18] <zyga> I mean, we could allow writes to /snap/*/ except for /snap/bin
[10:18] <zyga> but I really think this is a bug in the desktop themes snap
[10:18] <zyga> I don't quite understand what is the thing going on there
[10:19] <zyga> I mean
[10:19] <zyga> it's totally bogus
[10:20] <zyga> sound themes exposed by gtk-common-themes https://www.irccloud.com/pastebin/1T1cK5k0/
[10:20] <zyga> the share/sounds directory is not even in the snap!
[10:20] <mup> PR snapd#6142 closed: overlord/snapstate, store: always send epochs <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6142>
[10:21] <zyga> kenvandine: ^ should we escalate that, it feels like stable version of gtk-common-themes is missing files
[10:22] <mborzecki> zyga: https://forum.snapcraft.io/t/gtk-common-themes-bind-mount-sources-are-symlinks-missing-sounds/8540 heh
[10:22] <zyga> heh, thank you for reporting this maciek
[10:22] <mborzecki> pinged popey and kenvandine there ;)
[10:22] <zyga> with enough eyeballs :)
[10:23] <zyga> wat
[10:24] <zyga> the snap is on gnome gitlab
[10:25] <zyga> k, done
[10:25] <zyga> good :)
[10:25] <zyga> back to features
[10:27] <pstolowski> zyga: i see, good :)
[10:29] <pstolowski> zyga, mborzecki thanks for reporting it
[10:32] <mborzecki> zyga: can we do a HO about mounts & rhel/centos? wanted to discuss something
[10:32] <zyga> sure
[10:32] <zyga> let me join
[10:33] <zyga> can we "meet" instead?
[10:33] <zyga> https://meet.google.com/sri-fdeu-yur?authuser=0
[10:33] <zyga> just had this open now
[10:34] <pstolowski> zyga: is there anything new re mount issue that's also reported here https://bugs.launchpad.net/snapd/+bug/1772016 ?
[10:34] <mup> Bug #1772016: Mount snap "snapcraft" (1591) ([start snap-snapcraft-1591.mount] failed with exit status 1: <snapd:Triaged> <https://launchpad.net/bugs/1772016>
[10:34] <zyga> pstolowski: I'll check after the call with mborzecki
[10:38] <pstolowski> Chipaca: was https://bugs.launchpad.net/snapd/+bug/1767445 fixed already in snapd?
[10:38] <mup> Bug #1767445: Uninstalled snaps show most recent channel version, not version to be installed by default <amd64> <apport-bug> <bionic> <verification-done> <verification-done-bionic> <verification-done-xenial> <snapd:New> <Snap Store:New> <gnome-software (Ubuntu):Fix Released> <gnome-software
[10:38] <mup> (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu Bionic):Fix Released> <gnome-software (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1767445>
[10:39]  * Chipaca looks
[10:39] <mup> PR snapd#6164 opened: wrappers: rename the desktop file to their apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6164>
[10:40] <Chipaca> pstolowski: no, there was nothing to fix in the current api
[10:40] <Chipaca> bah
[10:41] <Chipaca> pstolowski: yeah, that
[10:41] <pstolowski> Chipaca: can be closed in snapd then? or it's for the future?
[10:43] <Chipaca> pstolowski: I mean, as described in the attached forum post, snapd could workaround things, but it's mostly up to the store to return the most stablest revision or not, there
[10:44] <Chipaca> pstolowski: i'd go with a "Won't fix" on snapd side though, with the rationale that (a) look in the channel map if you want to know what you'll get in stable, and (b) store can change what's returned outside the channel map, which we'd forward on
[10:45] <pstolowski> Chipaca: allright, thanks, it wasn't clear where the things are since that topic is 5 months old
[10:46] <zyga> pstolowski: looking
[10:47] <zyga> ah
[10:47] <zyga> this is the issue we know about
[10:47] <zyga> it's bound to be fixed this cycle
[10:49] <pstolowski> pedronis: what do you think about adding a pre-remove script? one of the bug reports request that we have a remove hook that runs before stop-snap-services, not after. we kina expected this when remove hook was introduced, but just wanted feedback and people actually starting to use hooks
[10:49] <pstolowski> zyga: great, thanks for updating it
[10:50] <zyga> kjackal: hello
[10:50] <zyga> kjackal: do you have a moment to talk about microk8
[10:50] <pedronis> pstolowski: can you point me to the actual bug?
[10:50] <kjackal> hi zyga, yes go ahead
[10:50] <kjackal> whats up?
[10:50] <zyga> I'm looking at https://bugs.launchpad.net/snapd/+bug/1802332
[10:50] <zyga> and I'd like to reproduce it locally
[10:50] <mup> Bug #1802332: Apparmor complains in strict confinement with base: core18  <snapd:Incomplete by zyga> <https://launchpad.net/bugs/1802332>
[10:50] <zyga> is the snap something you built locally or can I get it somewhere?
[10:50] <pstolowski> pedronis: https://bugs.launchpad.net/snapd/+bug/1777121
[10:50] <mup> Bug #1777121: Remove is called after snap services are stopped  <snapd:Triaged> <https://launchpad.net/bugs/1777121>
[10:51] <pedronis> pstolowski: thanks, I'll put in my queue of things to look at
[10:51] <kjackal> the snap is patched, let me find the branch
[10:51] <zyga> kjackal: can you send me the snap please
[10:51] <zyga> perhaps via wormhole :)
[10:52] <pedronis> zyga: what's the status of per-user mounts?  wating o reviews?
[10:52] <kjackal> Ah it is on the ticket https://github.com/ubuntu/microk8s/tree/feature/strict
[10:52] <zyga> pedronis: yes, I really need to land the current set
[10:52] <kjackal> zyga: ^
[10:52] <zyga> pedronis: it's bound with several dependencies but it should all be landable
[10:52] <zyga> kjackal: so I just need to take that snap, build it, and run it?
[10:52] <kjackal> yes
[10:53] <kjackal> zyga: for building the snap I went to snapcraft, version 3.0+git13.g04f18f5
[10:54] <zyga> kjackal: let me try, I'll bug you if I cannot get it somehow
[10:55] <kjackal> thank you
[10:56] <pedronis> zyga: do nag people for reviews a bit :) , given I'm sprinting next week I will not dive into that
[10:57] <zyga> pedronis: ay ay sir!
[10:57] <zyga> mborzecki: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6145
[10:57] <zyga> that's the first one to go in
[10:57] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[11:14] <zyga> mvo: or you perhaps? ^
[11:14] <zyga> this unclogs the pipe :)
[11:33] <mup> PR snapd#6165 opened: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
[11:40] <mup> PR snapd#6157 closed: userd: force zenity width if the text displayed is long <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6157>
[11:40]  * Chipaca afk for a bit
[11:44] <zyga> hmm
[11:44] <zyga> where does snapcraft 3.0 drop built snaps?
[11:46] <mborzecki> zyga: pwd?
[11:46] <mborzecki> cwd
[11:46] <zyga> nope :)
[11:46] <zyga> not for me
[11:46] <zyga> I forked microk8s and built it with snapcraft and multipass
[11:47] <zyga> no snaps found
[11:49] <zyga> I'll clean and try again
[11:49] <zyga> but ... wtf
[11:49] <zyga> no errors or anything
[11:53] <zyga> sergiusens:
[11:53] <zyga> sergiusens: halp
[11:53] <zyga> snapcraft 3.0
[11:54] <zyga> build works for a while
[11:54] <zyga> then nothing
[11:54] <zyga> error code 0
[11:54] <zyga> last messages are:
[11:54] <zyga> https://www.irccloud.com/pastebin/V8knVrdk/
[11:58] <zyga> oh boy :)
[11:59] <zyga> I need snapcraft, not snapcraft build
[11:59]  * zyga facepalms
[12:07] <cachio> mvo, hey
[12:07] <cachio> https://paste.ubuntu.com/p/CwM7k7ntvW/
[12:10] <sergiusens> zyga: help no longer required I assume?
[12:10] <zyga> yes :)
[12:10] <zyga> sergiusens: my only comment would be to auto-match the number of cores in qemu to the cores on the host
[12:10] <zyga> 6 core machine had 4 cores idle
[12:11] <zyga> it matters in the last step (compression)
[12:11] <mborzecki> cachio: hey, we have a problem with opensuse-42.3 images, they are in fact leap 15.0 images
[12:11] <mvo> cachio: hm, hm, is it connected? I assume so
[12:11] <sergiusens> zyga: oh, you can do that manually, but we were killing the machines because you need to also assign around at least 1G of RAM per core
[12:11] <mborzecki> cachio: that's why 2.36 branch is failing on travis
[12:12] <cachio> mborzecki, checking
[12:12] <sergiusens> zyga: it was the original design, moved away from it after some testing and agreements with Saviq
[12:12] <zyga> 1G ram per core? why
[12:12] <mborzecki> cachio: https://paste.ubuntu.com/p/ZYFc8Rkjq4/ this was on release/2.36 branch
[12:13] <sergiusens> zyga: SNAPCRAFT_BUILD_ENVIRONMENT_CPU=8 SNAPCRAFT_BUILD_ENVIRONMENT_MEMORY=8G snapcraft (for a fresh project)
[12:14] <sergiusens> given that 8 is the most common amount of RAM out there (I have one of those configurations) and that I usually barely manage to have 2G of free RAM I thought this conservative approach would be best for the wider audience
[12:16] <cachio> mborzecki, it seems that the last automatic update did it
[12:17] <mborzecki> cachio: can you fix it?
[12:18] <cachio> mborzecki, yes
[12:18] <cachio> I am on that
[12:18] <mborzecki> cachio: thank you!
[12:19] <cachio> mborzecki, np
[12:19] <cachio> mvo, yes, it is connected
[12:32] <zyga> simple review for https://github.com/snapcore/snapd/pull/6165
[12:32] <mup> PR #6165: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6165>
[12:34] <ogra> jdstrand, i see some very weird behaviour with the kvm interface ... when i switch qemu-virgil into --devmode i all of a sudden get "qemu-system-x86_64: failed to initialize KVM: Operation not permitted" ... switching back to --jailmode makes it work again
[12:35] <cachio> mborzecki, I am creating the new image
[12:35] <ogra> (nothing is printed in journalctl when that happens)
[12:36] <mborzecki> cachio: did the automatic update tool pick the wrong name the last time?
[12:36] <cachio> mborzecki, the change was caused because opoensuse project changed hte default image from 42.3 to 15
[12:36] <cachio> and we build based on that
[12:36] <cachio> mborzecki, I just changed to point to a specific 42.3 image
[12:40] <mup> PR snapd#6165 closed: cmd/snap-update-ns: extra debugging of trespassing events <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6165>
[12:40] <zyga> thank you :)
[12:43] <pstolowski> #6100 needs 2nd review
[12:43] <mup> PR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>
[12:43] <pstolowski> and has nice PR number ;)
[12:45] <zyga>  haha, nice
[12:45] <zyga> looking
[12:46] <mup> PR snapcraft#2407 closed: build providers: preset the timezone <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2407>
[12:46] <cachio> mvo, this is interesting https://paste.ubuntu.com/p/Fx48q9phRR/
[12:50] <Saviq> zyga: https://bugs.launchpad.net/snapcraft/+bug/1795666
[12:50] <Saviq> and https://github.com/CanonicalLtd/multipass/issues/420
[12:50] <jdstrand> ogra: that is weird. when you go to --devmode, is that an remove/install --devmode or something else?
[12:51] <jdstrand> s/an/a/
[12:51] <zyga> Saviq: using 4 cores on a 2 core system is certainly wrong
[12:51] <ogra> jdstrand, a refresh
[12:51] <zyga> Saviq: not sure about using 6 cores on a 6 core system
[12:51] <zyga> also not sure how ram relates
[12:51] <zyga> is there really a kvm correlation between ram and cores?
[12:52] <jdstrand> ogra: I suspect it would work right with a remove/install. I bet something isn't right with the device cgroup when refreshing to devmode. that probably deserves a forum topic
[12:52] <ogra> jdstrand, with qemu-virgil normally installed i did "sudo snap refresh qemu-virgil --edge --devmode" and "sudo snap refresh qemu-virgil --stable --devmode"
[13:04] <pedronis> jdstrand: hi, is re-reviewing #5845 in your queue?
[13:06] <pedronis> pstolowski: I left some comments in the hotplug-disconnect PR, we probably need to be a bit more careful about conflicts there
[13:07] <pstolowski> pedronis: yep, just noticed, thanks!
[13:08]  * pstolowski lunch
[13:15] <cachio> mborzecki, new opensuse image ready
[13:16] <cachio> mvo, snapd[30158]: task.go:303: DEBUG: 2018-11-16T11:53:56Z INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "
[13:16] <cachio> I see this error too
[13:17] <mborzecki> cachio: thanks, let me restart the travis jobs and see if it's ok now
[13:18] <zyga> hum hum
[13:18] <zyga> I need to run an errand now
[13:18] <zyga> I may miss the standup
[13:22] <cachio> mborzecki, nice, sorry about that issue but this leap image is not under our control
[13:22] <cachio> mborzecki, I'll see if I can create a copy to our project and then use it
[13:22] <mborzecki> cachio: so you mean it's some other project that's changed the image?
[13:23] <cachio> mborzecki, yes
[13:23] <mborzecki> cachio: yeah, copy sounds like a good idea
[13:23] <cachio> mborzecki, for some oss I get the images from other projects
[13:24] <cachio> i.e. opensuse, debian, etc
[13:28] <mvo> cachio: interessting error, I look at it
[13:31] <cachio> INFO snap "test-snapd-sh" has bad plugs or slots: personal-files (cannot add personal-files plug: "$HOME" must start with "$HOME")
[13:31] <cachio> this is the full message
[13:33] <zyga> https://github.com/snapcore/snapd/pull/6150 is the next branch in the chain
[13:56] <kenvandine> zyga: the Suru symlink issue is fixed in a Yaru PR by jamesh, I think
[13:58] <kenvandine> zyga: indeed the sounds are missing
[14:02] <mvo> zyga: standup?
[14:07] <zyga> kenvandine: and the sound theme issue?
[14:08] <kenvandine> zyga: working on it
[14:08] <zyga> I cannot join
[14:08] <zyga> mvo: sorry, cannot join
[14:09] <mvo> zyga: ok
[14:12] <zyga> My update is short, bug fixes and nagging for reviews
[14:13] <zyga> Call with Maciej about mount issues
[14:13] <zyga> No new bugs so happy
[14:13] <zyga> Working on tests
[14:13] <zyga> Master very flaky with testing
[14:13] <zyga> On 1000 cuts of random stuff breaking
[14:13] <zyga> mvo: ^
[14:14] <zyga> Cannot wait for 2.36.1 to be released
[14:19] <pstolowski> popey: hey, i asked you in some of your old bug reports to re-check if the problems can still be reproduced, hope you don't mind
[14:19] <popey> I got the mails :)
[14:21] <pstolowski> popey: good. i expected this :)
[14:29] <ogra> jdstrand_, if you wouldnt mind ... https://dashboard.snapcraft.io/snaps/opencv-demo-ogra/revisions/19/
[14:30] <Saviq> zyga: that's not really "cores" though - it's CPU threads, so with HT, that's what snapcraft was doing originally
[14:31] <Saviq> it was matching the number of threads available on the host, but without a sane amount of memory for each core
[14:31] <Saviq> so I recommended $threads * 1GB
[14:32] <Saviq> still, with the cgroup approach we want to apply we might reduce that limit since it will be obvious what happened
[14:32] <Saviq> without it things just get stuck, OOM never kicked in
[14:33] <cachio> mvo, https://paste.ubuntu.com/p/cr2cbCtDHN/
[14:34] <cachio> also failing with $HOME/
[14:34] <cachio> both things are conflicting
[14:34] <mvo> cachio: interessting
[14:47] <mvo> mborzecki: http://paste.ubuntu.com/p/3yfgGjqXGY/
[14:47] <mvo> mborzecki: that was my attempt to reproduce using plain mount
[14:48] <mborzecki> mvo: thanks, i'll extend it with mount units and daemon-reload like we talked about
[14:49] <mborzecki> mvo: i recall there were some concerns about daemon-reload in the context of packaging and post install tasks
[14:54] <mborzecki> cachio: mvo: release/2.36 branch finally green
[14:54] <mvo> mborzecki: awesome
[14:56] <Son_Goku> mborzecki, can you please CC me on https://bugzilla.redhat.com/show_bug.cgi?id=1650582
[14:57] <Son_Goku> I can't see the bug report otherwise
[14:57] <mborzecki> Son_Goku: done
[14:58] <Chipaca> pedronis: https://forum.snapcraft.io/t/snapctl-status/8313/7?u=chipaca fwiw
[14:59] <Son_Goku> mborzecki, thanks
[14:59] <cachio> mborzecki, :)
[14:59] <mborzecki> Son_Goku: the good news is that rhel8 looks fine
[14:59] <Son_Goku> I'm not surprised
[15:00] <mborzecki> Son_Goku: as you said before, alt kernels on ppc64el and aarch64 are probably fine too
[15:00] <Son_Goku> yeah
[15:00] <Son_Goku> those on rhel7 are based on 4.14 kernel
[15:02]  * Chipaca goes afk for a another bit
[15:22] <cachio> mvo,  personal-files test working in case I don't specify $HOME
[15:23] <cachio> it is the only scenario where it failed
[15:31] <kenvandine> zyga: the sound theme issue is fixed in candidate
[15:37] <kenvandine> sparkiegeek: i'd like to promote gtk-common-themes to stable today
[15:37] <kenvandine> sparkiegeek: any concerns with the store?
[15:40] <roadmr> kenvandine: the store seems happy, I think you could go ahead. However, the earlier the better for us; in case things get wobbly, it's easier for us to handle when some in the store team still have most of the day ahead
[15:41] <roadmr> kenvandine: which revision(s) are you planning on promoting? the ones currently on candidate?
[15:41] <kenvandine> 818
[15:41] <kenvandine> currently on candidate
[15:41] <kenvandine> just need to finish a round of testing
[15:41] <roadmr> awesome
[15:42]  * cachio lunch
[16:07] <mvo> 6156 is ready for a review now
[16:43] <roadmr> kenvandine: hey a question, gtk-common-themes is *not* baked/shipped preinstalled on Ubuntu images, is it? (I see it's not on 18.04, maybe it is on 18.10?)
[16:44] <kenvandine> it is
[16:44] <kenvandine> also in 18.04
[16:44] <kenvandine> there are snaps that use it which pulls it in
[16:44] <kenvandine> all the seeded snaps in 18.04 use it
[16:45] <kenvandine> roadmr: i'm really close to being ready to release it to stable
[16:45] <roadmr> kenvandine: hm, I don't see it on a fresh 18.04, but I'm using the live cd image
[16:45] <roadmr> kenvandine: awesome
[16:45] <kenvandine> ah, it wasn't on the actual iso
[16:45] <kenvandine> but everyone that installed 18.04 has gotten it installed since
[16:46] <kenvandine> as the seeded snaps now mount content from it
[16:46] <roadmr> kenvandine: yes, that's the question; because if so, I need to generate the deltas from whichever version is shipped in the ISO to the one you're about to release
[16:47] <roadmr> kenvandine: but if it was never shipped on an iso then I don't need to do anything special; just let me know when it gets released so I can keep an eye on our metrics
[16:47] <roadmr> when you release the new version, one of two things can happen:
[16:47] <kenvandine> it was on the 18.10 iso
[16:47] <roadmr> people who had the previous stable will get a delta (the store auto-generates these, yay)
[16:47] <roadmr> and people who didn't have it get a full download anyway
[16:48] <roadmr> kenvandine: oh! 18.10, then I should totally generate the delta. Do you by chance know which revision shipped with 18.10? fine if not, I can find out but it'll take me a few mins
[16:48] <kenvandine> actually it would have also been on the 18.04.1 iso
[16:48] <kenvandine> i do not know which revision
[16:49] <roadmr> kenvandine: ok, not a problem, I can find all that out
[16:49] <kenvandine> roadmr: i'm release to release it to stable, should i wait a few?
[16:49] <roadmr> kenvandine: and while it's better to pre-generate the deltas, I can also gen them post-facto which is not a huge setback
[16:51] <roadmr> kenvandine: if you're ready to release let's go ahead with tht
[16:51] <kenvandine> roadmr: cool, releasing now
[16:52] <roadmr> woohooo!
[16:52] <roadmr> kenvandine: btw many thanks for giving us a heads-up, it allows us to be on the lookout for issues and provide a better experience to end users
[16:53] <kenvandine> roadmr: no problem
[16:53] <kenvandine> roadmr: done
[16:53] <roadmr> yay :)
[17:34] <roadmr> kenvandine: we found the revisions that shipped with 18.04.1 (319) and 18.10 (701) and built deltas from those to the one you just released. This way, people booting from those images will get a nice small delta
[17:57] <jdstrand_> ogra: sure
[18:06] <kenvandine> roadmr: awesome
[18:30] <mvo> cachio: could you please look at 5845? the new tests are failing it seems
[18:39] <cachio> mvo, sure
[18:50] <cachio> mvo, I fixed the issue for personal-files
[18:50] <cachio> I am testing it
[18:50] <cachio> the errors on system-files seem to be real
[18:51] <cachio> I manually tested and the snap cannot see under the dir /tmp/.testdir1
[18:51] <mvo> cachio: thanks, well, could be because of /tmp being special, can you test if its also an issue with non-tmp?
[18:52] <cachio> mvo, sure
[23:40] <AuroraAvenue> e-what is the cli-instrn to install (pop) prnce of persia?