[06:08] <mborzecki> morning
[07:02] <pedronis> mborzecki: hi, is this known https://bugs.launchpad.net/snapd/+bug/1853512 ?
[07:02] <mup> Bug #1853512: snapd can't be installed on Centos 8 <snapd:New> <https://launchpad.net/bugs/1853512>
[07:21] <mborzecki> pedronis: that would be unexpected, thought snapd would be rebuilt automatically
[07:22] <mborzecki> Eighth_Doctor: wouldn't snapd get and automatic rebuild when selinux-policy-base gets a bump?
[07:27] <mborzecki> pedronis: i need to prep an update to 2.42.2 so we'll get a rebuild anyway
[07:27] <pedronis> ok
[07:28] <pedronis> mborzecki: I assigned it to you
[07:28] <mborzecki> pedronis: ok
[07:33] <mup> Bug #1484641 changed: snappy config command does not restart service after setting the configuration <Snappy:Won't Fix> <https://launchpad.net/bugs/1484641>
[07:34] <Eighth_Doctor> mborzecki: no
[07:35] <mborzecki> Eighth_Doctor: it's because the snapd-policy is outside of EPEL right?
[07:35] <Eighth_Doctor> no
[07:35] <Eighth_Doctor> it's because the Fedora build system can't do that
[07:35] <Eighth_Doctor> it can't auto-submit a rebuild
[07:36] <mborzecki> Eighth_Doctor: meh :P where do i submit the PRs?
[07:41] <pedronis> mborzecki: mvo:  https://api.travis-ci.org/v3/job/615952834/log.txt  gadget-update-pc seems to have a real issue
[07:41] <mborzecki> pedronis: should be a quick fix
[07:48] <zyga> good morning
[08:00] <pstolowski> morning
[08:02] <zyga> hey Paweł
[08:04] <pedronis> pstolowski: hi, what's blocking the preseed PRs, lack of reviews ?
[08:05] <pstolowski> pedronis: yes
[08:11] <pstolowski> pedronis: #7706 and #7658 are closest to be landdable i think
[08:11] <mup> PR #7706: overlord/snapstate: install task edges <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7706>
[08:11] <mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
[08:11] <pedronis> pstolowski: I will switch to do more reviewing this week
[08:11] <pedronis> mborzecki: are you working on fixing that gadget-update-pc issue?
[08:12] <pedronis> pstolowski: a 2nd review for #7774 would be great
[08:12] <mup> PR #7774: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7774>
[08:14] <pstolowski> pedronis: sure, looking at it
[08:15] <pedronis> thx
[08:15] <mborzecki> pedronis: yes
[08:16] <pedronis> thank you
[08:31] <mup> PR snapd#7774 closed: seed: proper support for optional snaps for Core 20 models <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7774>
[08:32] <pstolowski> dot-tobias: hello! was that you who reported and intended to work on a fix for https://bugs.launchpad.net/snapd/+bug/1851480 ?
[08:32] <mup> Bug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>
[08:37] <mborzecki> heh, so core18 gadget-update test fixed, but fails on core16 now, because core18 uses pc=18, but core16 just pc, perhaps the update of gadget.yaml should be done in yaml-aware way, rather than by swapping the text file
[08:38] <pedronis> mborzecki: pc for 18 has a track, pc latest is really 16
[08:39] <pedronis> so that part of the tests is right
[08:40] <mborzecki> pedronis: right, 18/edge contains some extra entries that aren't in latest
[08:40] <pedronis> might need to talk with mvo/foundations about them
[08:41] <zyga> brb, 2nd coffee needed
[08:41] <mborzecki> pedronis: the test should account for that, so as far as i'm concerned the test needs fixing
[08:41] <pedronis> mborzecki: sounds it need different reference info for 18 vs 16 ?
[08:44] <mborzecki> pedronis: pyyaml is in core*,
[08:44] <mborzecki> pedronis: so i might just generate gadget.yaml's on the fly
[08:47] <pedronis> pstolowski: reviewed 7706, let me know if the comment abou edge names make sense
[09:03] <pstolowski> pedronis: yes, i get your point, makes sense, thx
[09:10] <pedronis> pstolowski: I did another pass on 7658, minor things
[09:10] <pstolowski> thank you!
[09:20] <mup> PR snapd#7782 opened: osutil: handle "rw" mount flag in ParseMountEntry <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7782>
[09:34] <mup> PR snapd#7727 closed: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7727>
[09:37] <Chipaca> brb, coffee break
[09:47] <mup> PR snapd#7783 opened: osutil/mount: add {Unm,M}outFlagsToOpts helpers <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7783>
[09:48] <mup> PR snapd#7770 closed: testutil, many: make MockCommand() create prefix of absolute paths <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7770>
[09:54] <mup> PR snapd#7784 opened: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
[09:57] <zyga> mborzecki: are you onto that master-broken thing?
[09:57] <mborzecki> zyga: yes, opening it in a bit
[09:58] <zyga> great, thank you
[10:07] <mup> PR snapd#7785 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[10:07] <mborzecki> zyga: pedronis: ^^ should unbreak master
[10:08]  * zyga looks too
[10:08] <mborzecki> wish there was a way for pyyaml to preserve the structure of the document
[10:10] <zyga> mborzecki: reformat with black please
[10:10] <zyga> it's a good default
[10:10] <zyga> and seems to be adopted across canonical now
[10:12] <pedronis> mborzecki: thanks, reviewed
[10:17] <mborzecki> zyga: pedronis: thanks, i'll push those in a followup if you don't midng
[10:28] <zyga> not at all
[10:50] <mup> PR snapcraft#2815 closed: minor developer env/doc updates <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2815>
[10:56] <pedronis> mborzecki: it's fine, as I as much in the review
[10:56] <pedronis> s/as I as/I said as/
[10:56]  * Chipaca sets up a synchrotron in a cave to make antichampagne
[11:06] <mvo> Chipaca: lol
[11:08] <mup> PR snapcraft#2803 closed: snap: add license to snapcraft.yaml <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2803>
[11:53] <pedronis> mvo: zyga: https://github.com/snapcore/snapd/pull/7773 will the feature flag be only for 2.42 ? did you discuss that again?
[11:53] <mup> PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <Needs Samuele review> <⚠ Critical> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7773>
[11:54] <mvo> pedronis: if everyone feels its safe to include it in 2.42 as is I'm fine with that - otherwise I think we want this behind a feature flag
[11:54] <mvo> pedronis: wdyt?
[11:55] <pedronis> mvo: my main input is that the feature flag doesn't make sense on master, it's fix that we want to test
[11:56] <pedronis> mvo: I would like to understand what we think makes it not safe
[11:57] <pedronis> it's a fairly global change, so if it's not safe, it's probably not safe very generally
[12:00] <zyga> pedronis: I think mvo's concern was that it will have extremely limited testing
[12:01] <zyga> pedronis: and for the point release it would be safer to put it behind a feature flag
[12:01] <zyga> pedronis: so that it can be exposed to the customer that needs to use it
[12:01] <zyga> pedronis: the next regular release can enable the feature flag if unset
[12:01] <zyga> pedronis: so that it goes through regular testing
[12:01] <pedronis> something doesn't add up for me
[12:01] <mvo> pedronis: yeah, it's fine for master but I'm a bit concerned that it's too invasive for a point release
[12:03] <zyga> pedronis: can you be more specific?
[12:04] <pedronis> zyga: the change has two parts, one is turning keeping into unmount/mount, either we are ok with that or we aren't ?
[12:05] <pedronis> the other ignoring some errors, that is more worrying, but it's a bit unclear if a feature flag will help with that or not. what sanity/safety are we losing here?
[12:06] <zyga> pedronis: I think we are fine with both of those (the error is ignored for a specific reason) but the fact that it will get limited testing before hitting stable (AFAIK 2 days) is why mvo wanted to avoid the chance that we missed something and it is indeed unsafe.
[12:06] <zyga> pedronis: as for testing, I will work to make sure that both unit and spread tests cover both variants for now
[12:07]  * mvo is in a meeting, sry!
[12:07] <zyga> pedronis: and for the next release we can change the default-if-unset to true so that everyone gets the new, improved behavior
[12:07] <zyga> pedronis: and given that it will be tested over a cycle, we can release that with more confidence
[12:08] <pedronis> zyga: will need also to disuss another rewrite of update-ns, I'm not a fan of the ignoring the error bit going forward
[12:08] <zyga> at least that's how I understood mvo's concerns
[12:08] <zyga> pedronis: that's fine, we understand how to make that possible, it's just larger in scope
[12:09] <zyga> pedronis: note that ignoring the error is only safe when both patches are used
[12:10] <pedronis> mborzecki: what's the status of #7732 ?
[12:10] <mup> PR #7732: [PoC] many: extracted snaps mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7732>
[12:11] <mborzecki> pedronis: we can close it, it was a temporary hack for ijohnson to try
[12:12] <mup> PR snapd#7732 closed: [PoC] many: extracted snaps mode <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7732>
[12:12] <pedronis> zyga: I'm worried of the added messiness in terms of tests and code of the flag, that's why I'm not a fan of having it on master
[12:13] <zyga> pedronis: I see
[12:13] <mborzecki> heh, #7785 is red, i can push a followup patches there anyway now
[12:13] <mup> PR #7785: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[12:13] <zyga> I wonder if we could avoid that entirely with a snapd-from-branch
[12:13] <zyga> so that the customer could use snapd from a branch and upgrade to stable on the regular cycle
[12:13] <zyga> is that possible today?
[12:14] <pedronis> in principle yes
[12:17] <pedronis> pstolowski: given that #7320 and 7744 are related, you should probably pick up the former from John
[12:17] <mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
[12:18] <Chipaca> pedronis: you meant 7744?
[12:18] <pedronis> heh, not I meant 7740
[12:18] <Chipaca> phew :)
[12:23] <pstolowski> pedronis, Chipaca: sure, i can take it
[12:47] <mup> PR snapd#7777 closed: snap-confine: suppress noisy classic snap file_inherit denials <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7777>
[13:01] <mup> PR snapd#7785 closed: tests/main/gadget-update-pc: use a program to modify gadget yaml <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7785>
[13:02] <mborzecki> master should be unblocked now
[13:06] <pedronis> mborzecki: great, thanks
[13:12] <mup> PR snapd#7786 opened: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
[13:13] <pedronis> that's a small tweak ^
[13:14] <pedronis> #7775 is also ready for review (been rebased)
[13:14] <mup> PR #7775: seed: support extra snaps on top of Core 20 dangerous models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7775>
[13:29] <cachio> mborzecki, hey
[13:29] <mborzecki> cachio: hey, what's up ?
[13:29] <cachio> I see the test gadget-update-pc is failing
[13:29] <cachio> the pc-gadget.yaml on the test seeems to need an update
[13:30] <cachio> mborzecki, https://travis-ci.org/snapcore/snapd/jobs/616564112#L3392
[13:31] <cachio> mborzecki, can you confirm that?
[13:31] <mborzecki> cachio: the fix landed half an hour ago :)
[13:32] <cachio> mborzecki, ahhh, nice
[13:41] <zyga> brb
[13:41] <zyga> thank you for fixing master mborzecki
[14:05] <mup> PR snapd#7721 closed: gadget: add support for hybrid partitioning schemas <Simple 😃> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7721>
[14:08] <mup> PR snapcraft#2821 opened: meta: remove __dict__ usage in Snap  <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
[14:45] <ijohnson> zyga: thanks for the response on that post, just read it and it all makes sense, I just wasn't sure if there was some deeper reason to that limitation or not
[14:46] <zyga> ijohnson: the deeper reason is: we didn't anticipate it I guess
[14:46] <zyga> ijohnson: as for the 200 ms optimization
[14:46] <zyga> ijohnson: I think it's worth it for reliability and simplicity
[14:46] <ijohnson> yah I don't think it's worth it right now
[14:46] <zyga> ijohnson: also, we could change the way themes are used using tmpfs layout instead of mimic
[14:47] <ijohnson> just something I wanted to bring up mostly so we don't forget about it later :-)
[14:47] <zyga> one layout, many content connections == more explicit and obvious as to what is going on
[14:47] <ijohnson> hmm interesting point about the many themes
[14:47] <ijohnson> I don't have the numbers with me, but IIRC when I tested the various permutations of layouts and themes, the big time we spend right now for these snaps is in the layouts, not in the themes
[14:48] <zyga> yeah but it's all one thing
[14:48] <zyga> not two things
[14:48] <zyga> if we can change $anything to avoid the need to use mimics it will both be simpler to understand and faster
[14:48] <ijohnson> the themes results in a lot of mounts, but not a lot of computation (i.e. total speedup from removing themes wasn't measurable, but removing the mimics was)
[14:48] <ijohnson> yes agreed
[14:48] <ijohnson> mimics == complicated and slow
[14:49] <ijohnson> (relatively speaking)
[14:50] <zyga> yes
[15:22]  * cachio lunch
[15:37] <jdstrand> roadmr: hi! can you pull 20191125-1519UTC? note, I'm off Wed-Fri
[15:37] <roadmr> jdstrand: sure! so am I, heh, so no guarantees it'll be rolled out before Monday, but I'll try to leave everything merged and QAd so someone else can action that
[15:38] <jdstrand> roadmr: monday rollout seems reasonable since we are off
[15:48] <Chipaca> saw a tweet just now and thought "ooh, they're using snaps at nasa?"  … https://www.theregister.co.uk/2019/11/25/space_roundup/
[15:48] <Chipaca> (short answer: mu)
[15:54] <pstolowski> ijohnson: hey, would you find a moment for \https://github.com/snapcore/snapd/pull/7740 ?
[15:54] <mup> PR #7740: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7740>
[16:03] <mup> PR snapcraft#2818 closed: project: pivot `info` from ProjectInfo to Snap <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2818>
[16:12] <mup> PR snapd#7744 closed: snap-bootstrap: set expected filesystem labels <uc20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7744>
[16:17]  * Chipaca shakes fist at universe and goes for a cuppa tea
[16:19] <pedronis> a 2nd review for #7786 would be great (it's small)
[16:19] <mup> PR #7786: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <https://github.com/snapcore/snapd/pull/7786>
[16:21] <pstolowski> pedronis: https://github.com/snapcore/snapd/pull/7780 can land
[16:21] <mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
[16:22] <mup> PR snapd#7786 closed: many: make ValidateBasesAndProviders signature simpler/canonical <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7786>
[16:22] <pedronis> thx
[16:22] <Chipaca> pedronis: +1
[16:22] <Chipaca> heh, that
[16:23] <pedronis> cachio: can you give a quick look at #7780 fyi
[16:23] <mup> PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <https://github.com/snapcore/snapd/pull/7780>
[16:24] <mup> PR snapd#7781 closed: seed: fix confusing pre snapd dates in tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7781>
[16:25] <mup> PR snapd#7780 closed: tests: cleanup most test snaps icons, they were anyway in the wrong place <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7780>
[16:26] <mup> PR snapd#7753 closed: po: sync translations from launchpad <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7753>
[16:28] <mvo> yay, below 70!
[16:28] <mup> PR snapd#7740 closed: overlord/ifacestate: report bad plug/slots with warnings on snap install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7740>
[16:33] <mup> PR snapd#7787 opened: many: share single implementation to list needed default-providers <Created by pedronis> <https://github.com/snapcore/snapd/pull/7787>
[16:41] <ijohnson> pstolowski: sure it's on my queue, should get to it in my PM
[16:42] <ijohnson> pstolowski: hmm seems I was too slow and mvo already approved/merged it :-)
[16:42] <pstolowski> ijohnson: hah, indeed, mvo was faster :)
[16:42] <pstolowski> anyway, thanks, both of you :)
[16:57] <mvo> my pleasure
[17:16] <mup> PR snapd#7788 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7788>
[17:17] <mborzecki> pedronis: ^^
[17:17] <mborzecki> wrapping it up, need to go and pick up the kids from some extra classes and help out with the homwork a bit
[17:26] <sdhd-sascha> is it correct, the the build base here is core20 ? https://github.com/snapcore/core20/blob/master/snapcraft.yaml
[18:02] <sdhd-sascha> Just found, how to build an image: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361
[18:03] <sdhd-sascha> Hope i will find the source, for the core20 multipass image... 😶
[19:30] <ijohnson> hey diddledan, you around? got a question for you about https://github.com/diddlesnaps/supertuxkart/blob/master/libopenh264-helper/libopenh264/library-exports
[20:21] <ijohnson> ugh github is being slow/is down
[20:36] <Chipaca> sdhd-sascha: what are you trying to do with core20?
[21:00] <sdhd-sascha> just want to see if the eoan 19.10 packages from sway, would run inside of a snap. I know i could create a squash, or use the same patches, etc... I figured out, that the core18 is the same as ubuntu-core-18-amd64.img... Know i need to know how to add the image into multipass. Then i found that inside _multipass.py:46 is core18 and core...
[21:05] <sdhd-sascha> i mean, add sway as stage-package and do a black box comparison. Chipaca:
[21:05] <sdhd-sascha> Chipaca: ;-)
[21:11] <sdhd-sascha> The problem is that sway, with sys_cap_admin and suid inside the snap, do so many fork's and execv.. calls, that somewhere the environment goes away (LD_LIBRARY_PATH). And "strace -f" hangs if sway is started with this privileges. But the current version of eoan (debian) has some patches, where no suid and no "setcap" is needed. So i would just try if the eoan packages would work. I don't want to do a dist-upgrade
[21:11] <sdhd-sascha> inside of core18. Maybe a apt-build...
[21:13] <sdhd-sascha> have also considered sway linking static, then the LD_LIBRARY_PATH does not matter.
[21:18] <sdhd-sascha> yesterday i build wlroots as meson-subprojects, which has the affect, that systemd was recognized. (didn't tested to start sway over systemd yet... this should work without cap's)
[21:18] <sdhd-sascha> And i experiment with dbgsym's inside of's snap's because at some stage the my kms/drm drivers crashed on start from tty.
[21:18] <sdhd-sascha> Chipaca: and so on ... :-D
[21:20] <Chipaca> ah, the weird compositor that needs crazy capabilities
[21:20] <Chipaca> o...k :)
[21:20]  * Chipaca isn't running that any time soon
[21:23] <sdhd-sascha> Well, back to my question. Did i need patch snapcraft or multipass? Or can i just add the daily cloud-images from ubuntu.com somewhere and install snapcraft-edge ...
[21:23] <sdhd-sascha> But, is ok. I could also figure it out, sometime
[22:28] <sdhd-sascha> Chipaca: I have to go the other way yet. Unless I want to build the ubuntu-core images myself. 'Cause the CI/CD doesn't produce the needed images for multipass... https://github.com/CanonicalLtd/multipass/pull/1192
[22:28] <mup> PR CanonicalLtd/multipass#1192: add core20 image urls <Created by sd-hd> <https://github.com/CanonicalLtd/multipass/pull/1192>
[22:35]  * cachio afk