[04:59] <mborzecki> morning
[05:16] <zyga> Good morning
[05:16] <mborzecki> zyga: hey
[05:19] <zyga> hey, how are you doing
[05:19] <zyga> it's gotten pretty cold :/
[05:20] <mborzecki> zyga: yeah, it could rain a bit though, so far it's been rather dry
[05:21] <mborzecki> hmm somehow arch package of 2.39 is 4M smaller than 2.38 :/
[05:22] <zyga> mborzecki: it was raining almost daily here
[05:22] <zyga> mborzecki: perhaps something changed from a copy to a link?
[05:22] <zyga> mborzecki: worth du-ing though
[05:24] <mborzecki> zyga: s-u-n is half the size
[05:24] <zyga> that is unusual!
[05:24] <zyga> perhaps we stopped importing something big
[05:24] <zyga> but half the size is very surprising
[05:27] <mborzecki>  12M -rwxr-xr-x 1 maciek maciek  12M 05-06 07:27 sun-2.38
[05:27] <mborzecki> 6.1M -rwxr-xr-x 1 maciek maciek 6.1M 05-06 07:26 sun-2.39
[05:27] <mborzecki> hm
[05:31] <mborzecki> wow, how the hell did image end up in s-u-n
[05:32] <mborzecki> zyga: image as in this one https://godoc.org/image
[05:32] <zyga> LOL
[05:32] <zyga> golang linking magic
[05:32] <zyga> how are you inspecting the binary?
[05:34] <mborzecki> zyga: looking at readelf output, i'm not aware of any other go friendly way
[05:34] <mborzecki> zyga: package is included in symbol names
[05:34] <zyga> I spent all of previous-work-day in readelf/strace/ltrace
[05:34] <zyga> we should add support for snap run --ltrace
[05:34] <mborzecki> yeah, ltrace would be nice
[05:35] <mborzecki> oh, and an up to date strace-static snap :P
[05:35] <zyga> yeah
[05:35] <zyga> maybe something to try to get to this week though I haven't set my priorities yet
[05:36] <zyga> man, resuming a virtual machine from hdd is super painful
[05:36] <zyga> (ram dumps)
[05:40] <mborzecki> zyga: http://paste.ubuntu.com/p/xypbbFqtd7/ quite a bit of packages gone in s-u-n 2.39
[05:40] <zyga> mborzecki: perhaps go linking changed?
[05:40] <zyga> for real
[05:41] <zyga> I was joking before but maybe it's not a joke
[05:41] <mborzecki> zyga: same go version
[05:41] <zyga> perhaps something did import the image package before but not anymore?
[05:41] <zyga> dunno, it's a bit magic
[05:42] <mborzecki> zyga: hmm snapd in 2.38 also includes image :P
[05:42] <zyga> batteries and image processing included, that's the motto ;)
[05:49] <mborzecki> zyga: asserts pulls in golang.org/x/crypto/openpgp/packet which in turn imports image
[05:50] <zyga> what... the...
[05:50] <zyga> lol
[05:50] <zyga> so how did we end up dropping that from sun?
[05:51] <mborzecki> zyga: we dropped asserts, which probably was a dep of some other package
[05:52] <zyga> good find,
[05:52] <zyga> if you can automate enough it would be nice to have a tool that dumps, roughly, the imported go packages of a given binary
[05:56] <mborzecki> well, so probably nothing we can do about that import
[05:56] <mborzecki> at least i can proceed with the update now that we know where the 4MB went
[06:02] <zyga> mborzecki: indeed
[06:23] <zyga> hello mvo
[06:23] <mvo> hey zyga
[06:23] <mvo> zyga: good morning!
[06:42] <mborzecki> mvo: hey
[06:43] <Eighth_Doctor> ugh
[06:43] <Eighth_Doctor> I think I finally did it
[06:43] <Eighth_Doctor> and yay, I can sign into snapcraft forum again
[06:44] <mvo> hey mborzecki !
[06:44] <mborzecki> mvo: did you know we can do image processing in snapd? :D
[06:47] <mborzecki> need to run a quick errand, back in 30
[06:52] <mvo> mborzecki: image processing?
[06:57] <Eighth_Doctor> snapd 2.39 is currently held up due to https://pagure.io/fedora-infrastructure/issue/7762
[07:00] <zyga> mvo: snapd was linking to the go imaging package
[07:00] <zyga> mvo: because reasons
[07:00] <zyga> mvo: mborzecki went investigating why snapd suddenly is 4MB smaller
[07:00] <zyga> that's why
[07:01] <pstolowski> mornings!
[07:02] <mvo> zyga: woah, nice job mborzecki
[07:02] <mvo> hey pstolowski
[07:03] <zyga> mvo: on similar spirit, did you know that opengl on the linux desktop requires libtinfo for terminal control sequences?
[07:07] <pedronis> mvo: morning
[07:09] <mvo> hey pedronis
[07:09] <mvo> zyga: I had no idea :)
[07:23] <zyga> brb
[07:35] <zyga> re
[07:41] <mborzecki> re
[07:41] <mborzecki> pstolowski: pedronis: hey
[07:41] <pstolowski> o/
[07:44] <pedronis> mborzecki: pstolowski: zyga: hi
[07:44] <pedronis> mvo: I made a couple more comments on your remodel PRs
[07:45] <mvo> pedronis: thanks, working on this now
[07:45] <pedronis> mvo: also (still WIP) but this is were my own efforts or re-reg etc are heading:  https://github.com/pedronis/snappy/commit/bd6908d1c5a87f7ceb1c51bf9b4b4bedb3f7a0af#diff-57a9337573ecc46801d40ff4e140872cR32  probably worth a quick look to get a sense of things
[07:45] <mvo> pedronis: ok
[07:46] <mborzecki> Eighth_Doctor: that's somewhat unexpected
[07:46] <mborzecki> Eighth_Doctor: but it's epel only?
[07:46] <Eighth_Doctor> yep
[07:48] <mborzecki> Eighth_Doctor: maybe some update didn't land for ppc64le just yet
[07:49] <Eighth_Doctor> probably
[07:55] <mborzecki> Eighth_Doctor: did you have any issues with snapd selinux transition in 2.39? (aside from the reboot to patch the mount units)
[07:55] <Eighth_Doctor> 🤷
[07:56] <Eighth_Doctor> on the clean machines I have, no
[07:56] <Eighth_Doctor> but that doesn't tell me anything
[08:11] <Eighth_Doctor> mborzecki: https://fedoramagazine.org/use-udica-to-build-selinux-policy-for-containers/
[08:12] <mborzecki> Eighth_Doctor: interesting, didn't we look at this a year ago or so?
[08:12] <Eighth_Doctor> we looked at CIL, I think
[08:12] <Eighth_Doctor> I don't remember if we looked at udica
[08:16] <mborzecki> or maybe i was browsing wrabcak's projects :P
[08:17] <pedronis> mvo: tried to answer in 6775
[08:17] <pedronis> let me know if it's still unclear
[08:20] <Eighth_Doctor> mborzecki: heh
[08:20] <pedronis> mvo: I'm mostly trying us to have to refactor the refactor later, but don't want to make a time sink for you either
[08:20] <pedronis> s/to have/to not have/
[08:20] <Eighth_Doctor> wow, I really haven't gotten any sleep at all
[08:20] <Eighth_Doctor> this is terrible
[08:24] <mborzecki> zyga: void is 111 instead of 000, i guess i need to update it in the fs otherwise things will blow up?
[08:25] <Eighth_Doctor> the package should update this...
[08:31] <Eighth_Doctor> mborzecki: the selinux-policy issue should be fixed in the next half hour or so
[08:31] <Eighth_Doctor> so I'll try building snapd then and go from there
[08:32] <pedronis> mborzecki: pstolowski: I did some first pass review on some of your PRs
[08:32] <pedronis> mborzecki: pstolowski: also I have a long chain of refactory PRs (related to remodeling and rereg) that need review
[08:32] <pstolowski> pedronis: yep, thank you, i'm working on the ensure timings stuff
[08:33] <mborzecki> pedronis: thx
[08:33] <mborzecki> pedronis: 6821 is the first one in your batch?
[08:33] <pedronis> mborzecki: no it actually starts with 6810
[08:34]  * pedronis has 6 open PRs and more coming
[08:34] <pedronis> mvo should review those, but they will need 2nd reviews
[09:15] <mup> PR snapd#6824 closed: release: 2.39 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6824>
[09:22] <zyga> mborzecki: yes
[09:23] <zyga> mborzecki: the PKGBUILD change was insufficient?
[09:23] <mborzecki> zyga: pacman only issues a warning that the local permission bits are different
[09:41]  * dot-tobias says hi
[09:41] <mborzecki> mvo: left some comments under 6825, played with this locally and i think handling this from Go will be super tricky
[09:43] <zyga> mvo: offtopic-ish: I'd love to see snap run ltrace
[09:44] <zyga> perhaps doing per-tool hacks could be changed to a some sort of special hook (which could be a shell script) that allows us to add tools at ease?
[09:54] <mvo> mborzecki: thanks, in a meeting right now - does that mean the approach is doomed?
[09:56] <mborzecki> mvo: i don't think it's doomed, we just need to figure out a way how to make gdb, inferion and snap run not fight for the terminal
[09:59]  * mvo nods
[10:51] <zyga> mborzecki, mvo: https://forum.snapcraft.io/t/gpu-support-proposal/11247
[10:53] <zyga> Brb
[10:56]  * pstolowski lunch
[10:57] <mborzecki> pedronis_: answered some of your questions under https://github.com/snapcore/snapd/pull/6750 maybe we could have chat with mvo after the standup
[10:57] <mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
[11:12] <mup> PR snapd#6830 opened: interfaces/dbus: fix unit tests when default snap mount dir is not /snap <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6830>
[11:13] <mborzecki> super simple PR ^^
[11:20] <mup> PR snapd#6765 closed: tests: add security-seccomp to verify seccomp with arg filtering <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6765>
[11:30] <pedronis> mborzecki: yes, we should have a chat with mvo
[11:31] <pedronis> mborzecki: this was fun btw:  https://github.com/snapcore/snapd/pull/6828/commits/88b5794137a15266c7751ef865272402b26a8dd8 :)
[11:31] <mup> PR #6828: many: use a fake assertion model in the device contexts for tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/6828>
[11:34] <mborzecki> pedronis: nice
[11:42] <mborzecki> pedronis: mvo: after standup then?
[11:43] <pedronis> mborzecki: could work if it's not too long, we have a meeting after
[11:43] <mborzecki> pedronis: ok, otherwise tomorror morning maybe?
[11:43] <pedronis> yes
[11:45] <mborzecki> ack
[12:02] <mborzecki> off to pick up the kids
[12:04] <jdstrand_> mborzecki: thanks for keeping an eye on that PR
[12:51] <mup> PR snapd#6830 closed: interfaces/dbus: fix unit tests when default snap mount dir is not /snap <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6830>
[12:52] <pedronis> pstolowski: thanks for looking at my PRs
[12:57] <pstolowski> np
[13:52] <zyga> drat, the forum does not support SVG images
[13:59] <roadmr> :(
[14:07] <mborzecki> zyga: github does (kind of), maybe if you link to it?
[14:07] <zyga> I will link to a repo with the .dot files, for now the image is enough
[14:07] <zyga> mborzecki: fyi https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250
[14:08] <zyga> mborzecki: isn't that image nice? :)
[14:08] <mborzecki> zyga: that's from strace logs?
[14:08] <zyga> mborzecki: yep
[14:08] <zyga> mborzecki: + some tooling
[14:09] <zyga> mborzecki: + love :)
[14:09] <mborzecki> zyga: nice!
[14:09] <zyga> mborzecki: I have much more, just finally nailed how I want the FS access to look like
[14:50]  * zyga updated https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250 and goes for lunch
[15:05] <zyga> hey ijohnson
[15:05] <ijohnson> hey zyga
[15:06] <zyga> ijohnson: I've added https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250 and I will soon make a post like that about openGL (which will be much much longer as there is far more data and complexity there)
[15:07] <ijohnson> zyga: nice, I saw your post there! BTW, not sure if you're aware but I also created a snap with cuda samples from the SDK that bundles libcuda inside the snap, not sure if that would be useful to you or not
[15:08] <zyga> ijohnson: I think I saw that a while ago, the snap itself is interesting but I followed a simple cuda tutorial on the nvidia website, I mainly itererated on the tooling and analysis of what is going on at runtime so that I can form some kind of vision about how to support GPUs in snapd better
[15:09] <zyga> ijohnson: I have 4 GPUs on my desk and I've been experimenting with various drivers for a few days
[15:11] <ijohnson> zyga: I may be mistaken, but using CUDA with multi-GPU setups may use different accesses (not libraries but like /dev) - if you're able it might be worth trying to setup your machine with multiple nvidia GPUs that are compatible (I think as long as your GPUs aren't more than 5 years old they should work) with multi-GPU CUDA and then you can try to run the multi-GPU samples from my snap
[15:12] <zyga> ijohnson: there are more /dev/nvidia{1,2,3} entries for sure, I only have one quadro card but your remark is spot on. I will look for a few more cards to buy before Lyon
[15:13] <ijohnson> I have a discrete GPU in my desktop and another discrete in my laptop but unfortunately haven't been able to get ahold of 2 discrete cards I can plug into my desktop
[15:13] <zyga> ijohnson: the magic of olx.pl (like craigslist, I guess) and my mobo-on-desk setup  :)
[15:16] <ijohnson> nice :)
[15:33]  * cachio lunch
[15:41] <albertosottile> Hi guys, what are usually the times needed for a classic confinement approval request?
[16:36] <zyga> I'll EOD now
[16:36] <zyga> albertosottile: hey, it  usually takes a few days, sometimes longer when holidays or a longer backlog intervene
[16:37] <albertosottile> zyga: thanks, we have been waiting for 5 days but there was a weekend in between, so it might be that
[16:44] <mup> PR snapcraft#2555 opened: extensions: block direct use of private extensions <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2555>
[16:46] <zyga> jdstrand: FYI https://forum.snapcraft.io/t/hello-world-cuda-analysis/11250
[17:27] <jdstrand> zyga: nice writeup
[17:57] <AlexPortable> Can someone help me creating a snap for a wine application?
[17:58] <AlexPortable> I used this https://github.com/mmtrt/notepad3 as a basis, but i'm stuck at the copying of the file, it says can't find the file (in the original script it uses wget)
[17:58] <AlexPortable> should I start over from scratch?
[18:00] <mup> PR snapd#6810 closed: many: do without device state/assertions accessors based on state only outside of devicestate/tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6810>
[18:04] <pedronis> I rebased on #6817 on master, it's ready for reviews (it's not too big)
[18:04] <mup> PR #6817: overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/6817>
[18:57] <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>
[18:57] <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>
[18:58] <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>
[18:58] <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>
[21:37] <mup> PR snapd#6831 opened: tests: retry govendor sync to minimize the number of connection errors on prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6831>
[22:45] <mup> PR snapcraft#2556 opened: cli: snapcraft promote <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2556>
[23:00] <mup> PR snapcraft#2557 opened: ci: remove dependency on LXD from travis tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2557>