[01:54] <mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[01:54] <mup> PR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2514, snapcraft#2518, snapcraft#2527,
[01:54] <mup> snapcraft#2539, snapcraft#2544, snapcraft#2560, snapcraft#2564, snapcraft#2569, snapcraft#2570, snapcraft#2571, snapcraft#2574, snapcraft#2575, snapcraft#2576
[01:54] <mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[02:04] <mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129
[02:04] <mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
[02:05] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
[02:05] <mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
[02:08] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[02:08] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[02:08] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[02:09] <mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
[02:09] <mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905,
[02:09] <mup> snapd#6909, snapd#6913, snapd#6919, snapd#6922, snapd#6923, snapd#6924
[02:09] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
[02:09] <mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
[02:09] <mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
[06:07] <mborzecki> morning
[06:24] <mborzecki> zyga: when you're around, can you take a look at #6924?
[06:24] <mup> PR #6924: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6924>
[06:30] <zyga> Hey
[06:30] <zyga> Sure
[06:33] <mborzecki> zyga: thanks
[06:33] <mborzecki> zyga: spent a while rebuilding go toolchain and sprinkling soem debug messages around the linker
[06:33] <mborzecki> zyga: actually, quite an interesting exercise
[06:39] <zyga> I'm sure :)
[06:39] <zyga> I'm thinking about taking today off
[06:39] <zyga> I'm not feeling very well
[06:39] <zyga> my back is not happy today
[06:44] <mborzecki> zyga: day off is always a good idea
[06:47] <mborzecki> ok, got some comments to address in my PRs
[06:48] <mup> PR snapd#6924 closed: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6924>
[06:48] <mborzecki> mvo: hi, and thanks!
[06:56] <mvo> mborzecki: hey, good morning and thank *you* :)
[06:56] <mvo> mborzecki: nice fix and it unblocks another pr iirc?
[06:56] <mborzecki> mvo: yes, the one from jdstrand
[06:56] <mborzecki> mvo: about user.LookupGroup()
[06:56] <mvo> mborzecki: ha! two even, how nice is that :)
[06:57] <mborzecki> mvo: other distros build with PIE enabled and that's enough to trigger the use of external linker
[06:58] <zyga> hey mvo
[06:58] <zyga> I'm not feeling good, my back is acting up
[06:58] <zyga> I was thinking about taking that swap day  today if you don't mind
[07:02] <mvo> zyga: sure
[07:02] <mvo> zyga: get well!
[07:02] <zyga> I'll exercise a bit more today, that usually helps
[07:05] <pstolowski> heyas
[07:06] <mborzecki> pstolowski: hey
[07:27] <mup> PR snapd#6909 closed: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6909>
[07:28] <mborzecki> zyga: so, are you off today? :)
[07:30] <mborzecki> pstolowski: fwiw, i keep gofmt from 1.10 around for 'changes' like you had
[07:31] <pstolowski> mborzecki: good idea, thanks
[07:36] <zyga> mborzecki: yeah, though I may send a patch for ! bug now that no blockers remain
[07:45] <mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
[07:45] <mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,
[07:45] <mup> snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923
[07:46] <mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
[07:46] <mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,
[07:46] <mup> snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923
[07:50] <mborzecki> https://paste.ubuntu.com/p/YhDjqdmxnK/ 'Catalog update is doing verbose http logging (it should not).' huh?
[07:51] <mborzecki> a race of some sort?
[07:58] <pstolowski> pedronis: hey, can you merge master in #6841?
[07:58] <mup> PR #6841: overlord: make changes conflict with remodel <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6841>
[07:59] <pedronis> pstolowski: it's now based on 6855, that needs to go in first
[08:02] <pstolowski> ok, looking at it now
[08:18] <mborzecki> pedronis: mvo: do you think we need an experimental flag for gadget update for a while?
[08:22] <mvo> mborzecki: I don't think so, its up to the vendor to use it and they should know what they do (but pedronis may be of a different opinion)
[08:22] <pedronis> mborzecki: is opt in anyway also in most cases there is no user to make that decision per machine
[08:23] <mborzecki> pedronis: mvo: sounds fair
[08:24] <pedronis> mborzecki: if you are worried though about bugs in the opt in logic, we can have a flag for a bit
[08:29] <Chipaca> There was an unexpected problem serving your request // Please try again and contact us if the problem persists including EAC6:168A1:B024F2C:10BFCA12:5CEE42BE in your message
[08:29] <Chipaca> ^^ github OOPSing
[08:29] <Chipaca> fun fun
[08:30] <Chipaca> mvo: I was trying to add a comment to #6804: in all new code we really should be calling Context() on the *http.Request instead of adding context.TODO()s
[08:30] <mup> PR #6804: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>
[08:31] <mvo> Chipaca: oh, thanks, let me fix this
[08:32] <pedronis> yes, github is not having good days
[08:32] <mup> PR snapd#6925 opened: devicestate: disallow removal of snaps used in booting early <Created by mvo5> <https://github.com/snapcore/snapd/pull/6925>
[08:34] <mvo> Chipaca: should I still keep the todo as is or adjust?
[08:34] <Chipaca> mvo: where?
[08:36] <Chipaca> mvo: I meant: in searchStore, instead of ctx := store.WithClientUserAgent(context.TODO(), r.Header.Get("User-Agent")), do ctx := store.WithClientUserAgent(r.Context(), r.Header.Get("User-Agent"))
[08:37] <mvo> Chipaca: yeah
[08:37] <Chipaca> ah ok
[08:37] <mvo> Chipaca: I did that :) mostly wondering about the "//TODO" above
[08:37] <mvo> Chipaca: if that is still accurate (enough)?
[08:37] <Chipaca> mvo: heh :)
[08:38] <Chipaca> mvo: no, it's no longer accurate (if it ever was :) )
[08:38] <mvo> Chipaca: glad that I asked :)
[08:38] <mvo> Chipaca: suggestions? or shall I simply remove it
[08:38] <Chipaca> mvo: what's 'the common layer that calls the handlers'?
[08:38] <Chipaca> maybe i'm misunderstanding something
[08:39] <pedronis> mvo: Chipaca: notice that my proposal was ctx := store.WithClientUserAgent(r.Context(), r)
[08:39] <Chipaca> pedronis: where?
[08:39] <pedronis> Chipaca: my signature is not what mvo implemented
[08:40] <Chipaca> ah
[08:40] <pedronis> Chipaca: mvo: it seems my missed that Request now has Context
[08:40] <Chipaca> pedronis: mvo's is probably a lot easier to test :)
[08:40] <mvo> pedronis: oh, did I misread, let me double check
[08:40] <pedronis> Chipaca: marginally
[08:41] <pedronis> Chipaca: notice that I'm not proposing to make that thing take only Request
[08:41] <mvo> pedronis: indeed, silly me!
[08:42]  * mvo needs more tea
[08:42] <pedronis> Chipaca: mvo: as I was saying, I missed that Request now has Context, so the my other todo is not relevant anymore for now, until there is something we would like to stick everywhere, though UA might be almost that
[08:43] <mvo> pedronis: cool, I will update the PR and also use your suggested signature
[08:44] <pedronis> Chipaca: my todo was about doing something in Command.ServeHTTP
[08:47] <pedronis> we might want to do that anyway
[08:54] <Chipaca> pedronis: ah
[08:56] <Chipaca> pedronis: I didn't know they were your TODOs :)
[08:56] <mvo> pedronis: you mean something like http://paste.ubuntu.com/p/sDv8YcrNBc/ ?
[08:56] <pedronis> mvo: yes, something like that
[08:56] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6926
[08:56] <mup> PR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
[08:57] <mup> PR snapd#6926 opened: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
[08:57] <pedronis> mvo: then the rest of the work would teach store to take more contexts, and use r.Context more
[08:57] <mvo> pedronis: do you think its worth doing the above pastebin with the rest of the work? or do you think we should hold it? either way is fine for me
[08:57] <pedronis> mvo: I don't think it's a blocker for this PR
[08:58] <pedronis> I still think is not the best use of your time to work on this :)
[08:58] <mvo> pedronis: yeah, I know :(
[08:58] <mvo> pedronis: I stop and get to the other things
[09:02] <pedronis> mvo: need to look quickly but this one can problably land and Chipaca can pick up ther others/from there
[09:02] <mvo> pedronis: yeah, that would be cool
[09:29] <mup> PR snapd#6759 closed: osutil: now that we require golang-1.10, use user.LookupGroup() <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6759>
[09:32] <mborzecki> yay
[09:32] <pedronis> pstolowski: Chipaca: mvo: thank for the reviews to my remodel PR, I'll try to clean it and land it today, worst case it will happen on Monday
[09:38] <mvo> pedronis: yeah, its super close, its really nice to see how things fit together. given how complicated this topic is it was a joy to read
[09:46] <Chipaca> pedronis: today is eow for you?
[09:47] <pedronis> Chipaca: yes
[09:47] <Chipaca> pedronis: nice
[09:56] <mup> PR snapd#6804 closed: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6804>
[10:02] <pedronis> Chipaca: so if you need something in particular to be unblocked let me know
[10:10] <Chipaca> pedronis: you self-requested a review on #6848 so if you had the time to do that it'd be nice
[10:10] <mup> PR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>
[10:10] <Chipaca> that'd unblock its followup
[10:11] <pedronis> Chipaca: it's on my list of trying to get to it today
[10:14] <pedronis> Chipaca: worst case  there's the context/snap-client-user-agent stuff to pick up
[10:14] <pedronis> Chipaca: mvo has a couple more PRs open about that, I think there is still a bit more todo
[10:14] <Chipaca> pedronis: and cohort-in-info
[10:14] <pedronis> Chipaca: yes, that too
[10:14] <Chipaca> pedronis: and context-in-all-the-things
[10:15] <Chipaca> :)
[10:15] <Chipaca> pedronis: i'm not going to be bereft of things to do
[10:15] <pedronis> for the latter, it would be best if my PR landed
[10:16] <pedronis> given it has tests/signature changes in snapstate
[10:16] <pedronis> pstolowski: do you have PR  about --startup for timings ?
[10:16] <Chipaca> noted
[10:16] <pedronis> *a PR
[10:17] <mup> PR snapcraft#2577 opened: [cli] Add --destructive-mode to clean <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2577>
[10:18] <pstolowski> pedronis: oh yes i have, forgot to propose it. probably needs some small deconflicting now, will do
[10:18] <pstolowski> thanks for reminding
[10:18] <pedronis> pstolowski: np
[10:21] <pedronis> pstolowski: btw before 2.40 it would be good to have a forum topic with some explanation of snap debug timings and maybe example output from a pi or something
[10:22] <pstolowski> pedronis: yes, i need to repeat my test, have some old samples
[10:22] <pedronis> thank you
[10:47] <zyga> mvo: https://github.com/snapcore/snapd/pull/6926
[10:47] <mup> PR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
[10:47] <zyga> and that's my contribution of the day
[10:47] <zyga> I'm really swapping now
[10:48] <mup> PR snapd#6927 opened: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
[10:51] <mvo> zyga: thank you!
[11:03]  * pstolowski lunch
[11:03] <mborzecki> tests that look at journalctl seem to fail erratically on opensuse 15
[11:10] <mwhudson> mvo: hey i should tell you about the things i had to do to make your "build empty package on powerpc" hack actually work :)
[11:10] <mwhudson> mvo: (mostly this https://github.com/tianon/debian-runc/commit/22d7b5c648bcac9969d6d02067b0eddcc52af4af )
[11:11] <mvo> mwhudson: oh, interessting
[11:12] <mvo> mwhudson: you are using it (or something similar) in some other package ?
[11:12] <mwhudson> mvo: yeah, runc
[11:13] <mwhudson> mvo: i think you also need to fix the build deps
[11:15] <mvo> mwhudson: yeah, just noticed the ftbfs in the ppa, slightly sad about this
[11:15] <mvo> mwhudson: I have a look, should I apply your patches basicly?
[11:16] <mwhudson> mvo: well the things i remember are: check for build-arch as well; fix build deps
[11:16] <mwhudson> mvo: the other stuff i did was add a preinst that yelled at the user but well
[11:18] <mwhudson> mvo: the whole change to build the empty package is https://github.com/tianon/debian-runc/compare/70957b315f82170dc2ab7085d39c23835c0fa996...xenial
[11:18] <mvo> mwhudson: nice, thank you! I check it out and update the snapd packaging
[11:19] <mwhudson> mvo: thanks for the basic idea :)
[11:19] <mvo> mwhudson: my pleasure! hm, `golang-1.10-go [!powerpc]` does not work?
[11:19] <mwhudson> mvo: i think it does actually, i forgot you can do that :)
[11:20] <mvo> mwhudson: cool, thanks! I will give it a go
[11:29] <mup> PR snapd#6928 opened: packaging: fix build-depends on powerpc <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6928>
[11:34] <cachio> mvo, hi
[11:34] <mvo> hey cachio
[11:34] <mvo> cachio: finally, we have 2.39.1 in beta :)
[11:34] <cachio> mvo, yes, finally
[11:34] <cachio> mvo, :)
[11:35] <cachio> about that, changes not generated on https://people.canonical.com/~mvo/core-changes/html/beta/
[11:35] <mvo> cachio: aha, yeah, I think its just slow, let me give it a gentle kick
[11:35] <cachio> mvo, ah, ok, tx
[11:40] <popey_> Chipaca: want a fun bug? :)
[11:40] <popey_> Chipaca: run (exactly as written) snap install go --classic --channel=12/stable
[11:40] <popey_> (a typo, so it presents a list of channels that do actually exist)
[11:41] <popey_> the list is sorted incorrectly, with 1.10 and 1.11 coming before 1.12
[11:42] <popey_> Chipaca: https://paste.ubuntu.com/p/t3Z9kbpMny/
[11:51] <mup> PR snapd#6929 opened: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>
[11:52] <mborzecki> off to pick up the car and heading home
[11:52] <mborzecki> back for standup
[12:00] <zyga> mvo, pedronis: what can cause settle not to converge?
[12:03] <pedronis> zyga: where? it depends, malformed changes, too little timeout and missing EnsureBefore, tasks that retry
[12:04] <zyga> so, there's a test that reliably fails when I build a suse package
[12:05] <zyga> I added some debugging to show tasks and changes,
[12:05] <zyga> all changes and tasks are done:
[12:05] <zyga> the test is managers_test.go:3511: mgrsSuite.TestHappyDeviceRegistrationWithPrepareDeviceHook
[12:06] <zyga> I added this patch as otherwise debugging is pretty hard
[12:06] <zyga> DEBUG patch https://www.irccloud.com/pastebin/hGnLDEOP/
[12:06] <zyga> when the test fails the output is:
[12:06] <zyga> failing test output https://www.irccloud.com/pastebin/PHXiVyeZ/
[12:09] <pedronis> are they clean though?
[12:09] <pedronis> settle wait for clean too
[12:09] <pedronis> not that I remember it should matter here
[12:09] <zyga> good hint, checking
[12:10] <pedronis> also print if you hit the done clause at all
[12:10] <pedronis> or not
[12:14] <zyga> pedronis: curious
[12:14] <zyga> none of the tasks or changes are clean
[12:15] <zyga> so we must be running the cleanups, correct?
[12:18] <zyga> looking at the debug log that contains errors from failed cleanup tasks...
[12:21] <zyga> doh
[12:21] <zyga> it's all a big fluke
[12:21] <zyga> GOPATH messed up
[12:41] <jdstrand> zyga: fyi, I'm not sure about jj's plans, but I got tasked on something with priority today (a USN publication) and will not be looking at the apparmor issue (or other PRs) until that is done (targetting eod today)
[12:43] <zyga> jdstrand: that's okay
[12:43] <zyga> jdstrand: note, thre's no apparmor issue
[12:43] <zyga> jdstrand: it was a bug in our test setup
[12:43] <jdstrand> zyga: oh, does jjohansen know that?
[12:43] <zyga> I said so yesterday but based on what you just said I must have been vague
[12:43] <zyga> jjohansen: ^ please don't look at the apparmor bug jdstrand mentioned, it's not a bug, test setup was wrong
[12:44] <zyga> sorry for not communicating that clearly before
[12:44] <jdstrand> zyga: maybe I was slow on the uptake but jjohansen wasn't. jjohansen, no apparmor issue ^
[12:44] <jdstrand> pinged him just in case
[12:53] <mup> PR snapd#6930 opened: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>
[12:58] <zyga> hmmmmm
[12:58] <zyga> something totally bogus is going on
[12:59] <zyga> TestHappyDeviceRegistrationWithPrepareDeviceHook is not present in 2.39.1
[12:59] <zyga> yet that test fails
[12:59] <zyga> something along the way is getting snapd master?
[13:00] <zyga> mvo: uh
[13:00] <zyga> mvo: 2.39.1 tarballs are wrong?
[13:00] <zyga> mvo: it's master, not a .1 branch
[13:00] <zyga> mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in master
[13:00] <zyga> mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in the 2.39.1 branch
[13:00] <zyga> mvo: and grep for it in the tarball!
[13:00] <zyga> we need a .2
[13:03] <mvo> zyga: I took the tarballs down and will investigate
[13:10] <mvo> zyga: I have had a bit of a heart attack but it seems https://github.com/snapcore/snapd/blob/release/2.39/overlord/managers_test.go#L3511 shows that we have this TestHappyDeviceRegistrationWithPrepareDeviceHook - or are you saying things changed there?
[13:11] <zyga> oh my god, I'm sorry, I was on 2.*29* not 39
[13:11] <zyga> so the bugs I saw are real but the tarbralls are okay
[13:11] <zyga> sorry for the red flag
[13:12] <mvo> zyga: thanks
[13:23] <zyga> pedronis: I debugged the issue now
[13:23] <zyga> osc build sets a proxy and we choke on that
[13:23] <zyga> better debug log https://www.irccloud.com/pastebin/Pws7SmMF/
[13:24] <albertosottile> pedronis: I read your answer about the Syncplay classic confinement
[13:24] <albertosottile> From a technical point of view, we would need access to the binary and to a TCP port on localhost from both VLC and Syncplay
[13:25] <albertosottile> Your solution would rule out mpv and all users that do not use snap VLC, though
[13:30] <zyga> pedronis: this is with this patch https://github.com/zyga/snapd/commit/b6e38391e35d1634375a0675e6050e8192aa2cf6
[13:38] <zyga> mvo: whatever causes this I will adjust the unit tests to run in an offline network namespace
[13:38] <zyga> mvo: so we will not hit this by surprise the next time
[13:39] <mvo> zyga: thank you!
[13:53] <mvo> 6926 is green and needs a second review
[13:55] <pedronis> albertosottile: hi, I understand, but I'm very reluctant to give classic to this, so we are looking at options, there is also a mpv snap I think, but is didn't reach stable yet
[13:58] <albertosottile> pedronis: we understand your concerns, and we also would like to address them
[13:59] <albertosottile> however, we invested a lot of time in preparing a snap for Syncplay and we do not see a way to avoid the use of classic confinement in a short time and/or without noticeable drawbacks...
[14:08] <pedronis> abeato: I understand, but even if we granted classic temporarily (which is not very common), it's definitely the case that a story how to get out of that as soon as possible is valuable. We are really relucant to give classic to anything that serves outside requests, that guideline hasn't really changed/varied
[14:08] <pedronis> sorry, albertosottile ^
[14:09] <pedronis> mvo: did you do something strange with 6899, I got a strange email about it, listing tons of commits
[14:10] <mvo> pedronis: no idea why you got an email but I did update "20" to master and updated this PR to master as well
[14:10] <mvo> pedronis: should be all normal in this PR again though
[14:11] <pedronis> I see, seems github already the merge
[14:11] <pedronis> for this case
[14:11] <pedronis> at least in terms of email
[14:11] <pedronis> s/already/unrolled/
[14:11] <albertosottile> pedronis: to be honest, I did not find this guideline written somewhere in the documentation. The description of the classic confinement basically says that the app would be allowed to run as close as possible as unrestricted
[14:11] <mvo> pedronis: so no harm except this stange email?
[14:12] <albertosottile> I understand your concerns, but Syncplay is a seven years old software with a good user base on Linux
[14:14] <mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
[14:14] <mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:17] <mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
[14:17] <mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[14:19] <Chipaca> pedronis: would it be reasonable to expose snapstate.switchSummary (given it's dupe'd in daemon right now), and if so would that be a reasonable name for it?
[14:21] <mup> PR snapcraft#2576 closed: [legacy] catkin plugin: remove default rosdistro <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2576>
[14:33] <mup> PR snapd#6931 opened: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6931>
[14:44] <pedronis> Chipaca: we could but it's a bit unclear where it should live
[14:49] <Chipaca> pedronis: or I could grab it from the task :-)
[14:51] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/6927 failed building the package on sid
[14:51] <mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
[15:04] <mup> PR snapd#6932 opened: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
[15:11] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[15:11] <mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[15:11] <mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[15:12] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[15:12] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[15:12] <mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[15:13] <pedronis> Chipaca: did a pass on 6848
[15:15] <Chipaca> pedronis: thanks
[15:16] <zyga> mvo: draft https://github.com/snapcore/snapd/pull/6932
[15:16] <mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
[15:16] <zyga> it fails, I'll see what to do about the failures
[15:18] <mvo> zyga: woah
[15:18] <mvo> zyga: nice
[15:19] <mvo> cmatsuoka: re uc20> I pushed a hack that should avoid the stray reboot, with that you should be unblocked for the tmpfs work
[15:19] <mvo> cmatsuoka: its a pr against your core-build git repo
[15:29] <cmatsuoka> mvo: ack, thanks!
[15:32]  * cachio lunc
[15:32]  * cachio lunch
[15:50] <pedronis> pstolowski: looked at #6923
[15:50] <mup> PR #6923: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6923>
[15:51] <zyga> pedronis: FYI, I opened a draft PR that reproduces two unit test failures when network is isolated
[15:51] <pedronis> zyga: thanks, at this point I will look on monday morning
[15:52] <zyga> thanks, hopefully by then it will be all fixed :)
[15:52] <pstolowski> pedronis: thanks!
[15:54] <pedronis> zyga: maybe, anyway please don't hack the tests to much to fix them. At least the one you shown before should have a couple line fix
[15:54] <pedronis> just a matter of finding the right couple lines
[15:54] <zyga> yeah, I'm sure that's true
[15:57] <pedronis> actually not, the code is eager there
[16:07] <pedronis> mmh
[16:07] <mvo> cmatsuoka: mostly fyi - I started with launchpad.net/snap-core20
[16:10] <pedronis> zyga: I commented in the PR about the 2nd
[16:10] <zyga> thanks!
[16:27] <Et0h> Pedronis/jdstrand: Hi, I've been a core Syncplay developer since 2013. We do our best to be responsive to user feedback, and so we've been trying to add Snapcraft support in line with the requests that we have received. It'd be great if you could help make this happen so that our shared userbase who want to use Syncplay via Snapcraft can do so and I am grateful for you exploring this with my
[16:27] <Et0h> colleague albertosottile. As far as I can see the only way to accommodate this functionality would be for Syncplay to be granted Classic status or something equivalent. Anything you can do to progress this matter would be appreciated.
[16:43] <jjohansen> jdstrand, zyga: thanks, I was down the rabbit ole on the other bug I was trying to finish first yesterday, so I didn't spend much time on this yet.
[16:57] <mup> PR snapd#6933 opened: [RFC] snapd: ensure GOMAXPROCS is at least 2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6933>
[17:10] <cachio> mvo, hey https://paste.ubuntu.com/p/t7ZwjJzW6F/
[17:10] <cachio> at some point running beta validation for i386 it starts showing errors saying
[17:11] <cachio> Cannot allocate memory
[17:13] <mvo> cachio: woah, interessting
[17:13] <mvo> cachio: reproducible?
[17:13] <cachio> yes
[17:14] <cachio> mvo, I ran twice the suite
[17:14] <cachio> both times failed with same error
[17:14] <mvo> cachio: woah, ok - who much mem does this vm have?
[17:14] <cachio> but on different tests
[17:14] <cachio> 2GB
[17:14] <cachio> same as usuar
[17:14] <cachio> usual
[17:14] <mvo> cachio: should be plenty
[17:14] <cachio> KiB Mem :  2012832 total,  1218820 free,   272520 used,   521492 buff/cache
[17:15] <cachio> this is the mem after the test
[17:15] <cachio> on debug session
[17:16] <mvo> cachio: can you run something like "snap version" or does that also fail? in the debug shell?
[17:16] <cachio> I'll add some debug info to see the memory when it fails
[17:16] <cachio> it works well now
[17:17] <cachio> the memory is not full anymore
[17:17] <mvo> cachio: thanks. please keep poking, the diff looks innocent bug of course something external might have changed. if its persists, please mail maciej with instructions how to reproduce and ask him to look at this in his morning (cc me just in case)
[17:18] <cachio> mvo, sure, thanks
[17:18] <mvo> cachio: the diff between 2.39 and 2.39.1 looks super harmless so we need to check if something else (like go or gcc or whatnot) have changed
[17:18] <mvo> cachio: thanks, I have dinner now but will read backlog, keep me posted! and thanks for digging into this
[17:18] <cachio> mvo, np, please enjoy dinner
[17:19] <mvo> thanks!
[17:22] <cachio> mvo, https://paste.ubuntu.com/p/m2KsWxNpJ5/
[17:22] <cachio> I can reproduce it even havng more than 1GB of memory free
[17:22] <cachio> :(
[17:48] <jdstrand> jjohansen: phew, glad to hear. I hadn't yet either (and I was planning to do a deep dive)
[17:48] <jjohansen> jdstrand: then again maybe not, that rabbit hole involves no-expr-simplify
[17:48] <jjohansen> :)
[17:53] <mup> PR snapd#6926 closed: tests: stop using ! for naive negation in shell scripts <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6926>
[17:53] <cachio> zyga, hey, about the PR #6930
[17:53] <mup> PR #6930: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>
[17:53] <cachio> did you read my comment?
[18:00] <jdstrand> jjohansen: uh oh :)
[18:41] <mvo> cachio: what version of the kernel do you have?
[18:41] <mvo> cachio: what kernel snap revision?
[18:42] <cachio> mvo, hold on, I need to create the image
[18:42] <mvo> cachio: is it always the apparmor profile where it fails? maybe the kernel changed, last kernel change is ~2 weeks
[18:42] <mvo> cachio: old - in stable - this would match
[18:43] <cachio> allways in apparmor profile
[18:43] <mvo> cachio: the packaging changes also look harmless
[18:43] <cachio> now I am running stable + beta core
[18:45] <mvo> cachio: if you have the kernel revno of the 2.39 validation that might give us clues
[18:45] <mvo> cachio: might also be interessting to test with the beta kernel just for the kicks
[18:46] <mvo> cachio: also the output of cat /proc/meminfo is interessting
[18:46] <cachio> mvo, https://paste.ubuntu.com/p/drGFsBDV2K/
[18:46] <cachio> 0B kernel?
[18:46] <pedronis> mvo: cachio: also reminder that now ubuntu-image stable has --snap support
[18:46] <pedronis> for that kind of tweaking
[18:47] <cachio> pedronis, yes, I am using that
[18:47] <mvo> cachio: I suspect its not really "out-of-memory", I suspect its "out of a certain kind of memory", in the past we had something like "lowmem" in meminfo that we low, everything else was fine
[18:48] <mvo> cachio: would be great to know if the error is kernel dependent
[18:48] <cachio> mvo, ok, I'll continue working with this
[18:48] <mvo> ta
[18:48] <cachio> mvo, sure
[18:48] <cachio> I'll test that
[18:51] <mvo> ta
[19:00]  * cachio afk