[05:31] <mborzecki> morning
[06:09] <mborzecki> google:ubuntu-18.04-64:tests/main/uc20-snap-recovery seems to fail randomly
[06:38] <mup> PR snapd#7650 opened: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>
[06:45] <mup> PR snapd#7651 opened: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7651>
[06:51] <pedronis> mborzecki: hi, should we disable temporarely google:ubuntu-18.04-64:tests/main/uc20-snap-recovery it seems indeed flaky
[06:52] <mborzecki> pedronis: i'll try to find out what's going on there
[06:52] <pedronis> ok
[06:53] <mborzecki> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/7643 ? should be easy to land, it's just moving the code around into separate files
[06:53] <mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[06:53] <pedronis> mborzecki: yes, finishing something else and then I will look
[06:54] <mborzecki> pedronis: cool, thank you
[07:00] <pstolowski> morning
[07:00] <zyga> Hey
[07:00] <zyga> Overslept
[07:00] <zyga> Including kids
[07:01] <zyga> Sorting out stuff
[07:05] <mborzecki> hey guys
[07:06] <mvo> hey mborzecki
[07:09] <mborzecki> mvo: quick question about uc20-snap-recovery test, lsblk is wrapped by retry-tool, the comment says it's a race with udev, i've also seen it fail randomly in the travis runs
[07:09] <mborzecki> mvo: the race is in udev noticind the new partitions and creating device nodes, while lsblk picks them up, right?
[07:12] <mup> PR snapd#7652 opened: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652>
[07:12] <mvo> mvo: yeah, I think so, we could call udevadm I guess
[07:12] <mvo> mborzecki:
[07:12] <mvo> mborzecki: I'm doing a spread run right now to validate this
[07:15] <pedronis> mvo: all greedy plugs PRs are up now
[07:15] <mvo> pedronis: \o/
[07:15] <pedronis> pstolowski: hi, I asked you a review in #7650, that's definitely an area you worked on/touched
[07:15] <mup> PR #7650: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>
[07:16] <pstolowski> pedronis: sure, will do
[07:16] <pedronis> thx
[07:19] <mborzecki> mvo: heh, obviously spread -repeat=20 did not catch this
[07:19] <mborzecki> mvo: repeated that a couple of times, same thing
[07:19] <mborzecki> mvo: wonder if maybe there's some cross test interaction after all
[07:21] <mvo> mborzecki: could be, I can also just mount the partitions directly in the test and not rely on lsblk
[07:22] <mborzecki> mvo: hm, otoh, the nodes under /dev are created by the kernel now
[07:22] <mborzecki> mvo: not all though, but /dev/loop*p* probably is
[07:30] <pedronis> it failed again fwiw also in 7650
[07:31] <mvo> meh, I change from lsblk to mount for now
[07:31]  * mvo does that right away
[07:31] <mvo> sorry guys
[07:37] <mborzecki> pedronis: restarted the job in 7650, there's nothing new in the log, tests that ran earlier don't seem to be related
[07:41] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7647 ?
[07:41] <mup> PR #7647: gadget: skip structures with MBR role during remodel <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>
[07:42] <pedronis> mborzecki: reviewed #7643
[07:43] <mup> PR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[07:45] <mborzecki> pedronis: thanks! i think we could return to making the split nicer once gadget remodel (and maybe base remodel) land
[07:46] <pedronis> yea, I would also like to clean up some stuff in managers_test.go but yes, after more remodel stuff lands seems the right call
[07:46] <pstolowski> mborzecki: sure
[07:54] <mborzecki> zyga: tiny suggestion under https://github.com/snapcore/snapd/pull/7623 also the test caught something
[07:54] <mup> PR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>
[07:54] <mborzecki> zyga: probably needs a master merge too
[08:03] <zyga> mborzecki: tests caught real bug, it is discussed in the PR
[08:04] <mup> PR snapd#7653 opened: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>
[08:14] <mborzecki> mvo: left a little comment https://github.com/snapcore/snapd/pull/7653#discussion_r338436144
[08:14] <mup> PR #7653: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>
[08:15] <mvo> mborzecki: oh, nice! we probably want both, i.e. know we can mount it but also get all this nice information that file provides
[08:16] <mborzecki> mvo: surprisingly there's not that many methods for probing the fs type of a block device :/
[08:16] <mvo> mborzecki: yeah, I'm also puzzled why lsblk is not reliable, I try to look at the code of lsblk
[08:54] <mborzecki> Chipaca: updated my old store-url branch
[08:54] <mborzecki> Chipaca: will be pushing that out soonish
[08:55]  * zyga -> tea
[08:58] <Chipaca> mborzecki: neat
[09:24] <mborzecki> Chipaca: hm haven't added it to aux info though, we have a website and media list there
[09:27] <dot-tobias> jdstrand: Ping re https://bugs.launchpad.net/snapd/+bug/1849291/comments/2 – can I be of any help to get this into snapd soon(ish)? Sorry for nagging, but our snap pipeline is currently blocked for pressing updates, I'd need to revert a slew of NM-related changes or cherry-pick to another build branch until core allows Introspectable access for NM.
[09:27] <mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>
[09:27] <dot-tobias> (Note to self: Don't assume NM access works on Core when working fine on Classic desktop 🙈)
[09:31] <mup> PR snapd#7654 opened: cmd/snap, store: include snapcraft.io page URL in snap info output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7654>
[09:31] <mborzecki> Chipaca: ^^
[09:49] <Chipaca> mborzecki: yeah that'd be better,but could be a follow-up
[09:53] <ijohnson> pedronis, mvo sorry for not getting to #7595 yesterday, but I'm looking at it now, is there a design doc for the things there I should be looking at it? is the model assertion doc the only thing?
[09:53] <mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
[10:00] <pedronis> ijohnson: there's that and there's a picture from a sprint, let me turn it into a doc quickly
[10:01] <ijohnson> ok thanks
[10:09] <ijohnson> also could someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 again for me? it failed on store 403s again :-/
[10:16] <Chipaca> ijohnson: done
[10:16] <ijohnson> \o/
[10:17] <Chipaca> ijohnson: you don't have travis permission to restart?
[10:17] <ijohnson> I used to but it went away yesterday, I am still a GitHub member of snapcore but Travis doesn't think so anymore
[10:17] <Chipaca> ijohnson: maybe you need to log back in?
[10:17] <ijohnson> hmm I could try clearing the cache too I suppose
[10:18] <Chipaca> heh
[10:18] <ijohnson> signing out and back in doesn't do anything unfortunately
[10:19] <Chipaca> i recently got told to clear all my cookies to debug some website
[10:19] <Chipaca> "hahaha no"
[10:19] <ijohnson> "ALL your cookies are belong to us now"
[10:19] <Chipaca> there's so much state in dem biscuits
[10:19] <ijohnson> huh well now it works when I go sign in fresh to another browser
[10:21] <mborzecki> quick errand, back in 30
[10:23] <ijohnson> also Chipaca does the meeting time I sent out today work for you?
[10:24] <Chipaca> ijohnson: both of 'em work :-) but yes
[10:24] <Chipaca> ijohnson: i didn't check, is pedronis also there?
[10:25] <ijohnson> Chipaca yes and pedronis accepted the most recently sent invitation
[10:26] <Chipaca> ijohnson: are you saying i should actually click accept on the invite
[10:26] <Chipaca> psh
[10:26] <Chipaca> RSVPs is for frenchies
[10:27] <ijohnson> next time I'll mail you a physical invite so you can't decline it
[10:27] <Chipaca> you underestimate my power
[10:31] <Chipaca> can I enjoy some schadenfreude over the "FIREFOX UPDATED WITHOUT MY KNOWLEDGE AND STOPPED RESPONDING THIS IS TERRIBLE WILL YOU PLEASE FIX IT oh wait it was the apt version never mind" thing
[10:43] <mborzecki> re
[10:49] <mup> PR snapd#7655 opened: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>
[10:50] <zyga> dot-tobias: ^
[10:52] <mup> PR snapd#7646 closed: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7646>
[10:54] <mup> PR snapd#7643 closed: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>
[10:55] <mup> PR snapd#7656 opened: tests: verify host is not affected by mount-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>
[10:57] <Chipaca> zyga: pstolowski: is either of you aware of / working on #1848516 and #1849564 ?
[10:57] <mup> Bug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>
[10:57] <mup> Bug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:New> <https://launchpad.net/bugs/1849564>
[10:57] <zyga> Chipaca: I'm aware of the first one, working on neither
[10:57] <zyga> checking the second one
[10:57] <Chipaca> mvo: with the pulsaudio transition in progress, these bugs are going to bite
[10:58] <Chipaca> zyga: variation thereof
[11:03] <mvo> Chipaca: uh, thanks for raising this
[11:16] <Chipaca> zyga: you commented on this, so I ask you: what other projects have bugs for us? I'm adding them all to the triage doc
[11:16] <zyga> Chipaca: that's a great question, let me think
[11:17] <ijohnson> yassss finally silly spread tests passed
[11:17] <mup> PR snapd#7597 closed: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>
[11:17] <Chipaca> zyga: I'm stepping outside for a while, feel free to edit the doc :-) hopefully it makes sense wrt where to add
[11:17] <zyga> Chipaca: I will
[11:17] <zyga> enojy
[11:18] <zyga> enjoy*
[11:23] <zyga> pstolowski: we should look at those connections bugs
[11:24] <zyga> pstolowski: let me wrap something up first though
[11:26] <zyga> I see some searching and apt-hooks failures
[11:26] <pstolowski> zyga: interesting, I will investigate later today
[11:26] <zyga> 403 store side
[11:26] <mvo> I see a bunch of (random?) systemctl restart systemd-journald.service failures. anyone  else is seeing this in the tests?
[11:27] <ijohnson> mvo: yes I see this constantly
[11:27] <ijohnson> cachio has a PR which should fix this
[11:27] <zyga> snap recovery failures
[11:27] <zyga> mvo: all the time
[11:27] <mvo> zyga: I'm trying to fix those
[11:27] <zyga> mvo: as in every day for as long as I can remember
[11:27] <zyga> mvo: thank you so much
[11:27] <mvo> zyga: but now I see failures in the other ones
[11:27] <mvo> zyga: so I can't land my fix :/
[11:27] <ijohnson> mvo: https://github.com/snapcore/snapd/pull/7605 is what cachio had to fix that I think
[11:27] <zyga> reliability of the test suite is such an important part of snapd
[11:27] <mup> PR #7605: tests: configure the journald service for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7605>
[11:27] <mvo> zyga: 7653 fwiw
[11:28] <ijohnson> mvo: you always see it in ubuntu-core right?
[11:28] <ijohnson> or elsewhere?
[11:28] <ijohnson> I always only see it on ubuntu core
[11:28] <mvo> ijohnson: correct
[11:30] <mvo> ijohnson: lookng now
[11:31] <mvo> ijohnson: the PR from sergio needs a core update to writable path or some other mean to set this :/
[11:32] <ijohnson> ah darn, is there anyway we could hack around that?
[11:32] <pstolowski> zyga: i suspect a problem around reloadConnections, afair it is not robust enough. I’ll check later, need to wrap up first pare-Bakun PR
[11:32] <zyga> mvo: assuming https://bugs.launchpad.net/snapd/+bug/1849291 is fixed now, should it be targeting 2.43?
[11:32] <mup> Bug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1849291>
[11:32] <pstolowski> *pre-bake
[11:32] <zyga> some old milestones on launchpad ought to be closed
[11:32] <zyga> I'll do that
[11:35] <zyga> yay
[11:35] <zyga> two milestones left
[11:35] <zyga> mvo: and if so, what is the estimated release for 2.42 and 2.43?
[11:36] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7614
[11:36] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[11:36] <mup> PR snapd#7585 closed: spread.yaml: drop exclude list, use .gitignore <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7585>
[11:36] <zyga> It'd like to start moving this forward a little
[11:37] <mup> PR snapd#7657 opened: snap: fix default-provider in seed validation <Created by mvo5> <https://github.com/snapcore/snapd/pull/7657>
[11:38] <mvo> ijohnson: is the restart issue only happening on core18?
[11:38] <mvo> ijohnson: or did you see it on core16 as well?
[11:38] <zyga> mborzecki: also https://github.com/snapcore/snapd/pull/7656 is very simple and could land soon
[11:38] <mup> PR #7656: tests: verify host is not affected by mount-ns tests <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>
[11:39] <zyga> mvo: I saw this issue (journal service restart) on pretty much all systems, but this is an unscientific assertion]
[11:40] <ijohnson> mvo: pretty sure I've seen it on core16 as well
[11:41] <mvo> ijohnson: yeah, I'm just going over the last couple of failures and there it is
[11:44] <pedronis> I remember I have a note about the fact that we should simply drop some connections
[11:44] <pedronis> on refresh
[11:44] <mvo> ijohnson: let me see if I can fix sergios pr
[11:47] <zyga> core 20 recovery fails
[11:47] <zyga> is that fixed or shall we disable it
[11:48] <zyga> pedronis: yes, we never implemented transitions in any way, where a snap can rename a plug or slot or actual dropping of a plug or slot where that is removed from the state
[11:48] <zyga> I need some coffee, it's such a sleepy day
[11:48] <zyga> sorry, brb
[11:50] <dot-tobias> zyga, jdstand, mvo: Hearty thank you for the fast help + fix re: NM Introspectable! One more thing to look forward to in the 2.43 release 😊
[11:50] <dot-tobias> *jdstrand ^
[11:51] <mvo> ijohnson: I pushed a PR to core
[11:52] <mup> PR core#109 opened: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <https://github.com/snapcore/core/pull/109>
[11:59] <ijohnson> ack mvo will take a look today then
[12:03] <zyga> dot-tobias: a pleasure :)
[12:03] <zyga> mvo: once that lands I need to adjust mount-ns test to compensate
[12:07] <mup> PR snapd#7658 opened: cmd/snap-start-pressing: add snap-start-preseed executable (1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[12:08] <mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/7630
[12:08] <mup> PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>
[12:09] <pstolowski> ijohnson: hey, 7431 has conflicts
[12:32] <pedronis> mborzecki: addd to my queue
[12:32] <mborzecki> thx!
[12:37] <ijohnson> pstolowski: yes I finally just merged the dependent one, will resolve asap after my meetings this morning
[12:42] <mborzecki> Chipaca: pushed changes to aux data too
[12:52] <Chipaca> mborzecki: reviewed changes to aux data too
[12:52] <mborzecki> Chipaca: cool, thanks!
[12:53] <mborzecki> Chipaca: something i haven't checked, when is the aux info refreshed? bc if the store were to change the urls for any reason, would this end up being out of date?
[12:54] <Chipaca> mborzecki: currently it's bumped on refresh, although my plan is to do it on checking for refreshes also
[12:54] <mborzecki> Chipaca: so it should be fine then
[12:55] <Chipaca> mborzecki: that is: the refresh action fetches a bunch of data that we currently completely ignore for snaps that aren't actually refreshed, but that can and should change
[12:55] <Chipaca> mborzecki: we need to run the numbers but it's quite possible it'll be less expensive to get minimal data on refresh, and do separate info calls for what actually changed
[12:56] <Chipaca> but that's something to do when we have free time
[12:56]  * Chipaca looks at work mapped out to 2040
[12:56] <Chipaca> … yeah, someday
[12:57] <ogra> is there a forum thread so we can put our wishlist items on your 2040 schedule ?
[13:02] <pedronis> ogra: ?
[13:03] <ogra> pedronis, i was reacting to Chipaca's snarky joke :)
[13:03] <pedronis> ah
[13:03] <ogra> didnt mean to scare you :)
[13:05] <Chipaca> snarky? me?!?
[13:30]  * zyga goes for lunch
[13:44] <mup> PR snapd#7653 closed: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7653>
[13:47] <mvo> mborzecki: 7640 is ready for a second review
[13:56] <ogra> jdstrand, the new daemon user is hardcoded to "snap_daemon" ? (i.e. i can not set a random username here ?)
[14:01] <ijohnson> ogra: yes
[14:03] <joedborg> morning all! I've been seeing some odd snapcraft errors since late last week.  They seem to point at missing libraries, but I get different results part to part and for different libraries.  Could anyone lend their eyes please?  It's blocking some work.
[14:03] <jdstrand> ogra: you may only use snap_daemon at this time
[14:04] <Chipaca> joedborg: maybe #snapcraft ?
[14:04] <Chipaca> joedborg: or are they snapd-related?
[14:05] <joedborg> thanks, i'll try there. i guess it's snappy as it's happening at build time
[14:06] <mborzecki> off to pick up the kids
[14:11] <jdstrand> dot-tobias: it might make sense to verify the changes in that PR are enough to solve your issue. the way to do that would be a) install the two snaps b) in /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager add the receive rule from the PR, substituting the plug's name (eg, snap.mirros-one.hook.post-refresh)
[14:11] <jdstrand> dot-tobias: c) in /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh add the send rule from the PR, substituting the slot's name (eg, snap.network-manager.networkmanager)
[14:12] <jdstrand> dot-tobias: d) load the profiles into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.network-manager* /var/lib/snapd/apparmor/profiles/snap.mirros-one*
[14:14] <zyga> re
[14:15] <zyga> hello jamie :)
[14:15] <zyga> I'll push forward with bugfixes tonight
[14:16] <zyga> (spread permitting, sigh)
[14:23] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/7655 updates as requested
[14:24] <mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>
[14:25] <doko> sergiusens: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/u/ubuntu-image/20191022_062343_f039f@/log.gz
[14:25] <doko> this needs updating for 20.04?
[14:25] <doko> mvo: ^^^ ?
[14:26] <mvo> doko: looks like it, yes - sergiusens will have a look, he is in a meeting right now
[14:26] <sergiusens> doko: I worked that out on #ubuntu-release already, or is this a trigger after that?
[14:27] <doko> sergiusens: is it already fixed?
[14:28] <mup> PR core#109 closed: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/109>
[14:30] <sergiusens> doko: a retrigger should fix it if sil2100 or infinity haven't done so yet
[14:31] <sergiusens> doko: I reported my side of the fix one hour and 20 minutes ago on #ubuntu-release ... I cannot retrigger tests for ubuntu-image
[14:33] <mvo> zyga, cachio new core with fix for journal.d is building
[14:33] <cachio> mvo, perfect
[14:35] <jdstrand> zyga: hi and thanks!
[14:36] <zyga> mvo: thank you, I will prepare the fix for mount-ns test
[14:41] <pedronis> pstolowski: I skimmed the preseed PR,  it looks good overall, my main comment will probably be naming related
[14:42] <pstolowski> pedronis: ty!
[14:48] <sil2100> mvo: hello! Once you find a few cycles today, could you formally sign-off on the uc20 u-i spec in the doc? ;)
[14:49] <sil2100> Since I'm getting poked about that constantly, especially now that I want to land the changes
[14:59] <mvo> sil2100: yes, today is meeting crazy, I try
[15:01] <sil2100> mvo: thank you!
[15:03] <pedronis> mvo: I made a suggestion comment in #7649
[15:03] <pedronis> related to what we discussed
[15:03] <mvo> pedronis: thank you!
[15:03] <mup> PR #7649: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>
[15:09] <pedronis> sil2100: mvo: I could probably look at it an sign it off instead of mvo if that helps
[15:10] <mvo> pedronis: that would be great
[15:10] <mvo> pedronis: *if* you have some minutes, but hopefully straightforward
[15:13] <mvo> mborzecki: any news on the f30 xerrors backport?
[15:13] <mborzecki> mvo: nope, filed a ticket, pinged the guy irc, but haven't heard back
[15:14] <sil2100> pedronis: I'd be +1 on that too ;)
[15:14] <ijohnson> pedronis: left an initial review on #7595, need to finish reviewing the tests in a followup review I will submit later this morning
[15:14] <mup> PR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>
[15:14] <pedronis> sil2100: I made two additions, as suggestions, do they match our last understanding
[15:14] <pedronis> ?
[15:15] <sil2100> pedronis: yes, approved those o/
[15:15] <sil2100> Thanks for adding them
[15:20] <pedronis> ijohnson: thanks, I'll answer some of your questions in my morning
[15:20] <ijohnson> sounds good, have a nice evening (also I scheduled a meeting with you tomorrow morning re: performance things)
[15:22] <pedronis> sil2100: I filled in the table at the top with my +1, let me know if I should put in something else, not sure how you do this
[15:25] <sil2100> pedronis: that's perfect, thanks a lot o/ I'll inform my manager and land the u-i bits tomorrow - we can always follow up with fixes later when we're able to test it properly
[15:30]  * zyga is sleepy and goes to bed
[15:45] <pedronis> ijohnson: I did a pass of answering already
[15:45] <ijohnson> pedronis: ack will take a look
[15:48] <mup> PR snapcraft#2767 opened: rust plugin: add rustup profile <Created by dalance> <https://github.com/snapcore/snapcraft/pull/2767>
[15:55]  * cachio lunch
[16:06] <ogra> ppisati, so i just tried to roll a kernel snap from the raspi2 tree of eoan ... using the rsapi2 defconfig (to use it on my pi4 core images) ... and i notice that i end up with an ~800MB snap !! lookinng inside (unsquashed it is even 2GB) i see 976M in modules !
[16:09] <ogra> do we really need all this on a pi ?
[16:10] <ogra> (and how did it grow so much since bionic ?)
[16:12] <ogra> $ snap info rpi-iptv-player
[16:12] <ogra> Killed
[16:12] <ogra> bah !
[16:14] <om26er> @saviq is there a way to tell multipass to use all available instead of using a single core ?
[16:14] <Saviq> om26er: --cpu `nproc` when launching
[16:14] <ogra> jdstrand, do we suddenly have auto-rebuilds enabled for outdated snaps ?
[16:14] <Saviq> om26er: snapcraft has a hidden env var for it, too
[16:15] <om26er> Saviq, cool that was going to be my second question :-)
[16:15] <Saviq> https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_multipass/_multipass.py#L99
[16:15] <Saviq> om26er: vote on https://github.com/CanonicalLtd/multipass/issues/756 to have a setting for the defaults ;)
[16:15] <om26er> hmm, it seems to default to 2 apparently
[16:16] <ogra> jdstrand, i just looked at one of my pi's and had an update this morning of one of my packages that i definitely havent touched in more than a month ... and snap info also shows "edge:      0.2 2019-10-24 (56) 42MB -"
[16:16] <Saviq> om26er: that's threads, not necessarily cores
[16:16] <Saviq> (i.e. with HT that might end up just one core)
[16:17] <om26er> Saviq thanks for info, I'll subscribe to that issue
[16:17] <ppisati> ogra: i don't work on ARM kernels anymore -- juergh and hwang4 are taking care of rpi kernels now
[16:18] <ogra> ppisati, ah ..
[16:18] <ogra> well, let me just express that i'm slightly shocked then ... seeing my kernel snaps triple up in size :)
[16:18] <ppisati> ogra: while shrirang and jesse work on snapdragon
[16:18] <ppisati> ogra: eh, i see what you mean
[16:19] <ppisati> ogra: we can probably reduce the size / number of kmods
[16:19] <ogra> yeah i guess so
[16:19] <ppisati> ogra: thow a bug in LP about that, and we can take a look
[16:19] <ogra> will do ... not urgent indeed, i believe official pi4 core support is only on schedule for core20 anyway
[16:30] <mvo> zyga: do you think you could give a second review to 7640 ?
[16:30] <ogra> $ snap stop lxd
[16:30] <ogra> error: cannot communicate with server: Post http://localhost/v2/apps: dial unix /run/snapd.socket: connect: connection refused
[16:30] <ogra> GRRRR !!!
[16:36] <ijohnson> zyga: when you get back I have some bad news for you :-( https://github.com/snapcore/snapd/pull/7547#issuecomment-546001237
[16:36] <mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
[16:37] <ijohnson> I'm looking into it and I'm hoping there's an easy way out for this
[16:38]  * Chipaca takes a break
[16:47] <pedronis> mvo: I reviewed some of your PRs
[17:02] <jdstrand> roadmr: hey, can you pull 20191024-1700UTC?
[17:02] <roadmr> jdstrand: sure!
[17:03] <jdstrand> roadmr: thanks :)
[17:04] <roadmr> 1700 how precise ;)
[17:04] <jdstrand> roadmr: just overrides and a change to the README. I used the new debian/changelog methodology as discussed before
[17:04] <jdstrand> roadmr: yeah :)
[17:04] <roadmr> thanks! jdstrand fwiw the guys who had complained about that said having the changelog from source was fine, so yay
[17:05] <jdstrand> roadmr: cool :)
[17:07] <jdstrand> ogra: if something is rebuilding that, it isn't something I am aware of
[17:09] <ogra> jdstrand, yeah, i just learned that build.s.io adds automatic watches for *any* "source:" line in snapcraft.yaml ... not just for the repo that carries the snapcraft.yaml
[17:10] <ogra> so myth solved .. the package uses two external GH trees ... i had the impression only changing the tree itself triggers rebuilds
[17:11] <ogra> (i wonder how many of my snaps are actually broken because the initial build used some source: entry to a foreitgn trunk tree that was stable at the time i created the initial snap)
[17:12] <ogra> thats probably a "feature" we should make people more aware of ... i certainly didnt knwo this
[17:12] <ogra> *know
[17:19] <cjwatson> Not any source: line, just ones that refer to repos on github
[17:20] <ogra> indeed
[17:20] <ogra> still though, i'm not even sure how many of my snaps use trunk links that might have completely fallen over after i created the snap
[17:21] <ogra> (simply bcause ... well .. development trees instead of stable ...)
[17:21] <ogra> +e
[17:31] <zyga> mvo: sure
[17:31] <zyga> ijohnson|lunch: uh
[17:31] <zyga> ijohnson|lunch: there was a similar case before
[17:34] <ijohnson|lunch> zyga: yeah I think I remember, but this is different because what I'm thinking right now is that we put dockerd inside a cgroup and it tries to mount things underneath that group and that doesn't work because those subsystems, i.e. devices are not mounted there they are mounted in the normal system one
[17:34] <ijohnson|lunch> this should only affect things that need to create containers and manage cgroups
[17:35] <ijohnson|lunch> anyways I will keep looking after lunch and let you know via the PR what I find
[17:49] <jdstrand> ogra: oh, interesting
[17:55] <zyga> jdstrand: do you want to review https://github.com/snapcore/snapd/pull/7632 -- it's the fix for the memory bug
[17:55] <mup> PR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>
[17:55] <zyga> jdstrand: it has +2 but I can wait if you want to go through it carefulyl
[17:55] <zyga> *carefully
[18:09] <mup> PR snapcraft#2766 closed: project: truncate project directory hash <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2766>
[18:43] <cachio> niemeyer, hey, I am makes a POC related to github actions
[18:43] <cachio> and I need a sa to store in the secrets to run the tests
[18:44] <cachio> niemeyer, could you please create one similar to the one we use for travis
[18:44] <cachio> with expiration: 1 week
[18:44] <cachio> so I can test it?
[18:46] <om26er> If that is of interest for anyone, I wrote a snap example that uses python3.8 and instead of bundling pycache files as part of the snap package, it generates them post-install. Reducing the size of the snap substantially (and in rare cases improves startup time as well) https://github.com/om26er/post-refresh-bytecompile-snap
[18:49] <jdstrand> zyga: I do. as you can see from forum traffic, I'm a bit swamped
[18:49] <jdstrand> zyga: I will review it before any other PRs
[19:18] <zyga> jdstrand: no worries, thank you
[19:21]  * cachio afk
[20:00] <mup> PR snapcraft#2763 closed: "snap debug validate-seed" fails if the slot is specified in the default-provider <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2763>
[22:44] <zyga> jdstrand: hey
[22:44] <zyga> jdstrand: I just ran into a curious bug
[22:44] <zyga> jdstrand: https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/13868
[22:44] <zyga> jdstrand: XDG_RUNTIME_DIR breaks wayland
[22:44] <zyga> cc kenvandine
[22:44] <zyga> but when snap uses classic confinement, we should not set it at all IMO
[22:44] <jdstrand> zyga: I just approved 7632, but please see my comments for a follwoup
[22:46] <zyga> jdstrand: I will, thank you
[22:47] <mup> PR snapd#7659 opened: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>
[22:49] <mup> PR snapcraft#2765 closed: remote-build: initial Windows support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2765>
[22:49]  * kenvandine looks
[22:52] <zyga> jdstrand: note, command time, is running /usr/bin/time, it's just that it's rarely installed
[22:52] <zyga> jdstrand: I'll fix that in a follow up
[22:53] <zyga> jdstrand: command foo performs PATH lookup and skips shell built-ins
[22:53] <zyga> jdstrand: but GNU time is not installed anywhere outside of ubuntu
[22:54] <jdstrand> zyga: I understand that about the lookup except bash behaves different. try it :)
[22:54] <zyga> jdstrand: bash vs dash?
[22:54]  * zyga tries
[22:54] <jdstrand> zyga: yes, as my comment mentioned with hello-world.sh
[22:55] <zyga> jdstrand: what I am doing wrong? https://www.irccloud.com/pastebin/uG75D2rs/
[22:55] <jdstrand> zyga: anyway, how you fix it doesn't matter, just having it everywhere makes sense
[22:55] <zyga> jdstrand: I think it only depends on /usr/bin/time being present or not, it's not in core
[22:55] <zyga> (core 16 or 18, one of those has it AFAIR)
[22:55] <jdstrand> zyga: you aren't in hello-world.sh?
[22:55] <zyga> right, it's not in core so it's not there
[22:55] <zyga> not on path
[22:55] <jdstrand> bash-4.3$ command -v time
[22:55] <jdstrand> time
[22:55] <jdstrand> bash-4.3$ /bin/sh
[22:55] <jdstrand> $ command -v time
[22:55] <jdstrand> $
[22:55] <zyga> no, I was on a 19.10
[22:56] <zyga> oh
[22:56] <zyga> that's weird
[22:56] <zyga> it says that there's no time at all
[22:56] <zyga> not even built-in
[22:56] <jdstrand> zyga: it isn't in path in hello-world.sh bash either:
[22:56] <zyga> I see now
[22:56] <jdstrand> bash-4.3$ which time
[22:56] <zyga> I understand the mistake now
[22:56] <jdstrand> bash-4.3$
[22:56] <zyga> thanks!
[22:56] <jdstrand> np
[22:56] <zyga> jdstrand: as for xdg runtime dir
[22:56] <zyga> I think we need to fix wayland for strict
[22:56] <zyga> but for classic I would argue that we did something wrong and need to back out
[22:57] <zyga> even if there is some frictoin
[22:57] <zyga> yes, each snap can fix it by itself
[22:57] <zyga> but I would argue it's our bug
[22:57] <zyga> *friction
[22:57] <jdstrand> we can discuss that in the topic
[22:57] <zyga> sure, sorry for splitting the conversation
[22:57] <jdstrand> as for strict, that is a longer discussion. the symlinks were never supposed to be a longterm solution
[22:57] <jdstrand> but resources what they are...
[22:58] <zyga> I think nobody noticed this because it really manifests itself when you have fractional scaling
[22:58] <zyga> and suddenly you go via xwayland
[22:58] <zyga> and that just scales a bitmap
[22:58] <jdstrand> as someone who uses hidpi, that would be annoying
[22:59] <jdstrand> ok, I gotta run. I'm getting the side eye, but wanted that PR review out the door
[23:00] <jdstrand> zyga: talk to you later
[23:00] <zyga> jdstrand: sure, o/
[23:00] <zyga> jdstrand: thank you for the review!
[23:00] <zyga> I know you are super busy now
[23:00] <jdstrand> zyga: np, sorry for the delay. I think I am through all the reviews/forum backlog (finally-- 2 days!! :\ )
[23:01] <zyga> :)
[23:01] <jdstrand> so, more PR reviews tomorrow
[23:01] <jdstrand> ok, bye! :)
[23:02] <mup> PR core-build#55 closed: Drop abootimg support, not used anymore <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core-build/pull/55>