[06:08] morning [07:02] mborzecki: hi, is this known https://bugs.launchpad.net/snapd/+bug/1853512 ? [07:02] Bug #1853512: snapd can't be installed on Centos 8 [07:21] pedronis: that would be unexpected, thought snapd would be rebuilt automatically [07:22] Eighth_Doctor: wouldn't snapd get and automatic rebuild when selinux-policy-base gets a bump? [07:27] pedronis: i need to prep an update to 2.42.2 so we'll get a rebuild anyway [07:27] ok [07:28] mborzecki: I assigned it to you [07:28] pedronis: ok [07:33] Bug #1484641 changed: snappy config command does not restart service after setting the configuration [07:34] mborzecki: no [07:35] Eighth_Doctor: it's because the snapd-policy is outside of EPEL right? [07:35] no [07:35] it's because the Fedora build system can't do that [07:35] it can't auto-submit a rebuild [07:36] Eighth_Doctor: meh :P where do i submit the PRs? [07:41] mborzecki: mvo: https://api.travis-ci.org/v3/job/615952834/log.txt gadget-update-pc seems to have a real issue [07:41] pedronis: should be a quick fix [07:48] good morning === pstolowski|afk is now known as pstolowski [08:00] morning [08:02] hey Paweł [08:04] pstolowski: hi, what's blocking the preseed PRs, lack of reviews ? [08:05] pedronis: yes [08:11] pedronis: #7706 and #7658 are closest to be landdable i think [08:11] PR #7706: overlord/snapstate: install task edges [08:11] PR #7658: cmd/snap-preseed: add snap-preseed executable [08:11] pstolowski: I will switch to do more reviewing this week [08:11] mborzecki: are you working on fixing that gadget-update-pc issue? [08:12] pstolowski: a 2nd review for #7774 would be great [08:12] PR #7774: seed: proper support for optional snaps for Core 20 models [08:14] pedronis: sure, looking at it [08:15] thx [08:15] pedronis: yes [08:16] thank you [08:31] PR snapd#7774 closed: seed: proper support for optional snaps for Core 20 models [08:32] 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] Bug #1851480: Hooks are not included in slot/plug label expressions [08:37] 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] mborzecki: pc for 18 has a track, pc latest is really 16 [08:39] so that part of the tests is right [08:40] pedronis: right, 18/edge contains some extra entries that aren't in latest [08:40] might need to talk with mvo/foundations about them [08:41] brb, 2nd coffee needed [08:41] pedronis: the test should account for that, so as far as i'm concerned the test needs fixing [08:41] mborzecki: sounds it need different reference info for 18 vs 16 ? [08:44] pedronis: pyyaml is in core*, [08:44] pedronis: so i might just generate gadget.yaml's on the fly [08:47] pstolowski: reviewed 7706, let me know if the comment abou edge names make sense [09:03] pedronis: yes, i get your point, makes sense, thx [09:10] pstolowski: I did another pass on 7658, minor things [09:10] thank you! [09:20] PR snapd#7782 opened: osutil: handle "rw" mount flag in ParseMountEntry === alan_g is now known as alan_g_ [09:34] PR snapd#7727 closed: tests: improve TestDoPrereqRetryWhenBaseInFlight to fix occasional flakiness [09:37] brb, coffee break [09:47] PR snapd#7783 opened: osutil/mount: add {Unm,M}outFlagsToOpts helpers [09:48] PR snapd#7770 closed: testutil, many: make MockCommand() create prefix of absolute paths [09:54] PR snapd#7784 opened: cmd/snap-update-ns: adjust debugging output for usability [09:57] mborzecki: are you onto that master-broken thing? [09:57] zyga: yes, opening it in a bit [09:58] great, thank you [10:07] PR snapd#7785 opened: tests/main/gadget-update-pc: use a program to modify gadget yaml [10:07] zyga: pedronis: ^^ should unbreak master [10:08] * zyga looks too [10:08] wish there was a way for pyyaml to preserve the structure of the document [10:10] mborzecki: reformat with black please [10:10] it's a good default [10:10] and seems to be adopted across canonical now [10:12] mborzecki: thanks, reviewed [10:17] zyga: pedronis: thanks, i'll push those in a followup if you don't midng [10:28] not at all [10:50] PR snapcraft#2815 closed: minor developer env/doc updates [10:56] mborzecki: it's fine, as I as much in the review [10:56] s/as I as/I said as/ [10:56] * Chipaca sets up a synchrotron in a cave to make antichampagne [11:06] Chipaca: lol [11:08] PR snapcraft#2803 closed: snap: add license to snapcraft.yaml === mborzeck1 is now known as mborzecki === alan_g_ is now known as alan_g [11:53] 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] PR #7773: cmd/snap-update-ns: fix overlapping, nested writable mimic handling <⚠ Critical> <⛔ Blocked> === ComradeCrocodill is now known as Crocodillian [11:54] 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] pedronis: wdyt? [11:55] 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] mvo: I would like to understand what we think makes it not safe [11:57] it's a fairly global change, so if it's not safe, it's probably not safe very generally [12:00] pedronis: I think mvo's concern was that it will have extremely limited testing [12:01] pedronis: and for the point release it would be safer to put it behind a feature flag [12:01] pedronis: so that it can be exposed to the customer that needs to use it [12:01] pedronis: the next regular release can enable the feature flag if unset [12:01] pedronis: so that it goes through regular testing [12:01] something doesn't add up for me [12:01] pedronis: yeah, it's fine for master but I'm a bit concerned that it's too invasive for a point release === mdeslaur_ is now known as mdeslaur [12:03] pedronis: can you be more specific? [12:04] 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] 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] 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] 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] 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] pedronis: and given that it will be tested over a cycle, we can release that with more confidence [12:08] 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] at least that's how I understood mvo's concerns [12:08] pedronis: that's fine, we understand how to make that possible, it's just larger in scope [12:09] pedronis: note that ignoring the error is only safe when both patches are used [12:10] mborzecki: what's the status of #7732 ? [12:10] PR #7732: [PoC] many: extracted snaps mode [12:11] pedronis: we can close it, it was a temporary hack for ijohnson to try [12:12] PR snapd#7732 closed: [PoC] many: extracted snaps mode [12:12] 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] pedronis: I see [12:13] heh, #7785 is red, i can push a followup patches there anyway now [12:13] PR #7785: tests/main/gadget-update-pc: use a program to modify gadget yaml [12:13] I wonder if we could avoid that entirely with a snapd-from-branch [12:13] so that the customer could use snapd from a branch and upgrade to stable on the regular cycle [12:13] is that possible today? [12:14] in principle yes [12:17] pstolowski: given that #7320 and 7744 are related, you should probably pick up the former from John [12:17] PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces [12:18] pedronis: you meant 7744? [12:18] heh, not I meant 7740 [12:18] phew :) [12:23] pedronis, Chipaca: sure, i can take it === ricab is now known as ricab|lunch [12:47] PR snapd#7777 closed: snap-confine: suppress noisy classic snap file_inherit denials [13:01] PR snapd#7785 closed: tests/main/gadget-update-pc: use a program to modify gadget yaml [13:02] master should be unblocked now [13:06] mborzecki: great, thanks [13:12] PR snapd#7786 opened: many: make ValidateBasesAndProviders signature simpler/canonical [13:13] that's a small tweak ^ [13:14] #7775 is also ready for review (been rebased) [13:14] PR #7775: seed: support extra snaps on top of Core 20 dangerous models [13:29] mborzecki, hey [13:29] cachio: hey, what's up ? [13:29] I see the test gadget-update-pc is failing [13:29] the pc-gadget.yaml on the test seeems to need an update [13:30] mborzecki, https://travis-ci.org/snapcore/snapd/jobs/616564112#L3392 [13:31] mborzecki, can you confirm that? [13:31] cachio: the fix landed half an hour ago :) [13:32] mborzecki, ahhh, nice [13:41] brb [13:41] thank you for fixing master mborzecki [14:05] PR snapd#7721 closed: gadget: add support for hybrid partitioning schemas <⛔ Blocked> [14:08] PR snapcraft#2821 opened: meta: remove __dict__ usage in Snap === ricab|lunch is now known as ricab [14:45] 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] ijohnson: the deeper reason is: we didn't anticipate it I guess [14:46] ijohnson: as for the 200 ms optimization [14:46] ijohnson: I think it's worth it for reliability and simplicity [14:46] yah I don't think it's worth it right now [14:46] ijohnson: also, we could change the way themes are used using tmpfs layout instead of mimic [14:47] just something I wanted to bring up mostly so we don't forget about it later :-) [14:47] one layout, many content connections == more explicit and obvious as to what is going on [14:47] hmm interesting point about the many themes [14:47] 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] yeah but it's all one thing [14:48] not two things [14:48] if we can change $anything to avoid the need to use mimics it will both be simpler to understand and faster [14:48] 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] yes agreed [14:48] mimics == complicated and slow [14:49] (relatively speaking) [14:50] yes [15:22] * cachio lunch [15:37] roadmr: hi! can you pull 20191125-1519UTC? note, I'm off Wed-Fri [15:37] 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] roadmr: monday rollout seems reasonable since we are off [15:48] 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] (short answer: mu) [15:54] ijohnson: hey, would you find a moment for \https://github.com/snapcore/snapd/pull/7740 ? [15:54] PR #7740: overlord/ifacestate: report bad plug/slots with warnings on snap install [16:03] PR snapcraft#2818 closed: project: pivot `info` from ProjectInfo to Snap [16:12] PR snapd#7744 closed: snap-bootstrap: set expected filesystem labels [16:17] * Chipaca shakes fist at universe and goes for a cuppa tea [16:19] a 2nd review for #7786 would be great (it's small) [16:19] PR #7786: many: make ValidateBasesAndProviders signature simpler/canonical [16:21] pedronis: https://github.com/snapcore/snapd/pull/7780 can land [16:21] PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place [16:22] PR snapd#7786 closed: many: make ValidateBasesAndProviders signature simpler/canonical [16:22] thx [16:22] pedronis: +1 [16:22] heh, that [16:23] cachio: can you give a quick look at #7780 fyi [16:23] PR #7780: tests: cleanup most test snaps icons, they were anyway in the wrong place [16:24] PR snapd#7781 closed: seed: fix confusing pre snapd dates in tests [16:25] PR snapd#7780 closed: tests: cleanup most test snaps icons, they were anyway in the wrong place [16:26] PR snapd#7753 closed: po: sync translations from launchpad [16:28] yay, below 70! [16:28] PR snapd#7740 closed: overlord/ifacestate: report bad plug/slots with warnings on snap install [16:33] PR snapd#7787 opened: many: share single implementation to list needed default-providers [16:41] pstolowski: sure it's on my queue, should get to it in my PM [16:42] pstolowski: hmm seems I was too slow and mvo already approved/merged it :-) [16:42] ijohnson: hah, indeed, mvo was faster :) [16:42] anyway, thanks, both of you :) [16:57] my pleasure === pstolowski is now known as pstolowski|afk [17:16] PR snapd#7788 opened: overlord/snapstate: pick up system defaults when seeding the snapd snap <⚠ Critical> [17:17] pedronis: ^^ [17:17] 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] is it correct, the the build base here is core20 ? https://github.com/snapcore/core20/blob/master/snapcraft.yaml [18:02] Just found, how to build an image: https://discourse.ubuntu.com/t/building-multipass-images-with-packer/12361 [18:03] Hope i will find the source, for the core20 multipass image... 😶 [19:30] hey diddledan, you around? got a question for you about https://github.com/diddlesnaps/supertuxkart/blob/master/libopenh264-helper/libopenh264/library-exports [20:21] ugh github is being slow/is down [20:36] sdhd-sascha: what are you trying to do with core20? [21:00] 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] i mean, add sway as stage-package and do a black box comparison. Chipaca: [21:05] Chipaca: ;-) [21:11] 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] inside of core18. Maybe a apt-build... [21:13] have also considered sway linking static, then the LD_LIBRARY_PATH does not matter. [21:18] 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] 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] Chipaca: and so on ... :-D [21:20] ah, the weird compositor that needs crazy capabilities [21:20] o...k :) [21:20] * Chipaca isn't running that any time soon [21:23] 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] But, is ok. I could also figure it out, sometime [22:28] 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] PR CanonicalLtd/multipass#1192: add core20 image urls [22:35] * cachio afk