[05:15] <mborzecki> morning
[06:58] <mborzecki> mvo: morning
[06:59] <mvo> mborzecki: good morning!
[07:00] <mborzecki> mvo: some conflicts in https://github.com/snapcore/snapd/pull/7072
[07:01] <mvo> mborzecki: checking
[07:01] <mvo> mborzecki: aha, I see, will fix
[07:07] <mborzecki> mvo: i think you had some pointers to docs about running spread tests with rspi, can you remind me where they were?
[07:07] <zyga> Good morning
[07:07] <mborzecki> zyga: hey
[07:07] <zyga> Hey everyone
[07:08] <zyga> On Friday I managed to finish the huge test
[07:08] <zyga> I will upstream it today
[07:08] <zyga> I will be starting late today though as we are moving once again
[07:08] <zyga> See you in two hours
[07:09] <pstolowski> mornings
[07:10] <mvo> mborzecki: sure, tests/external-backend.md
[07:10] <mvo> zyga: good morning
[07:10] <mvo> and good morning pstolowski :)
[07:12] <mborzecki> mvo: got it, thanks!
[07:12] <mborzecki> pstolowski: hey
[07:15] <mborzecki> mvo: hm guess that brings me back to the problem i had earlier, is there a way to create a user without console-conf (no display, and no working serial) or user assertion (cannot sign one for canonical signed model)?
[07:16] <mborzecki> mvo: i do use cloud-init for qemu amd64 images, but iirc pstolowski did not manage to get it to work with rspi before
[07:19] <ondra> zyga https://github.com/snapcore/snapd/pull/7074
[07:20] <ondra> zyga first shot, feel free to leave comment if something is missing or something to change
[07:33] <zyga> ondra: thank you
[07:35] <mvo> mborzecki: oh, thats a good one, I am not sure what the best option is
[07:35] <mvo> mborzecki: you could simple add the user by removing the sd card?
[07:35] <mvo> mborzecki: and adding it "offline" ?
[07:50] <zyga> mvo, mborzecki: please have a look at https://github.com/snapcore/snapd/pull/7071 -- I will try to upstream all of the test I wrote last week today
[08:38] <zyga> ondra: you need to change gpio-contorl PR a little to include a change to a spread test
[08:38] <zyga> https://www.irccloud.com/pastebin/wn7CUxZQ/
[08:39] <Chipaca> zyga: do you know the ouid is in an apparmor denial message?
[08:40] <zyga> do you mean if I know what ouid is?
[08:40] <Chipaca> zyga: yes
[08:41] <zyga> object uid
[08:41] <Chipaca> fsuid i presume is the uid of the filesystem thing
[08:41] <Chipaca>     Log: apparmor="DENIED" operation="file_perm" profile="snap.olivia-test.olivia" name="/home/bulld/snap/olivia-test/114/.local/share/org.keshavnrj.ubuntu/Olivia/fifos/1562106609366.fifo" pid=21796 comm="socat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[08:41] <Chipaca> does that ^ mean it's trying to access a fifo owned by the user, as root?
[08:42] <zyga> fsuid is the ID of the user from the point of view of the filesystem AFAIK
[08:42] <zyga> yeah
[08:42] <zyga> I think so
[08:43] <Chipaca> zyga: tks
[08:43] <zyga> pstolowski, mborzecki: I need a review for https://github.com/snapcore/snapd/pull/7071
[08:43] <zyga> more python test code
[08:48] <pstolowski> +1
[08:49] <zyga> pstolowski: thank you!
[08:53] <Chipaca> omg
[08:54] <Chipaca> mborzecki: "cannot install lxd snap" … why would they omit the most relevant bit of info from the title?
[08:54] <Chipaca> "... on WSL"
[08:54] <zyga> Chipaca: don't we detect WSL?
[08:54] <zyga> Chipaca: unless that is on  wsl2
[08:55] <Chipaca> zyga: this guy has patched snapd and is working to get it to work on wsl2
[08:55] <mvo> we do detect it, maybe somehthing changed there (os wsl2)
[08:55] <zyga> Chipaca: oh, cool
[08:55] <zyga> mvo: yeah, wsl2 is quite different
[08:55] <zyga> mvo: I played with it  last week a little, it's interesting
[08:55] <mvo> cool
[08:56] <mborzecki> Chipaca: yeah, figured as much seeing the guy comment in wsl2 topics
[08:56] <zyga> mvo: /init is a bind mount from a plan9 fs from windows VM  that is full of microsoft-style windows symbol names
[08:56] <zyga> mvo: the boot process boots a small container manager on linux, then ubuntu is a container there
[08:57] <zyga> anyone https://github.com/snapcore/snapd/pull/7071 (2nd review only, python test code)
[09:07] <zyga> mborzecki: thank you!
[09:30] <zyga> mborzecki, pstolowski: small tweak on top of the renumbering patch
[09:30] <zyga> https://github.com/snapcore/snapd/pull/7078
[09:47] <mborzecki> mvo: opened a RFC with snap-image https://github.com/snapcore/snapd/pull/7079
[09:48] <mborzecki> mvo: those are cherry-pickings from a work in progress branch, hopefully the spread test works too
[09:56] <pedronis> mborzecki: we'll need to iterate on the commands and name of that tool, I read the forum topic and I'm not sold on the current ones
[09:56] <mborzecki> pedronis: sure, as you probably noticed already i'm terrible at naming things :)
[10:03] <mvo> zyga: nice!
[10:03] <mvo> mborzecki: thanks, will have a look (was in a meeting)
[10:05] <zyga> wow, it is raining
[10:05] <zyga> this soil badly needs water
[10:05] <zyga> I'm  inclined to take a break and just enjoy the rain for a sec
[10:05] <Eighth_Doctor> mborzecki: will this help with making fedora snappy core systems? :)
[10:06] <zyga> Eighth_Doctor: hey :)
[10:06] <mborzecki> Eighth_Doctor: well, you don't need ubuntu-image to build an image anymore
[10:06] <zyga> Eighth_Doctor: what  willhelp?
[10:06] <zyga> ah,ubuntu-image
[10:06] <Eighth_Doctor> well, I saw `snap image`, and I thought, well maybe that might help
[10:06] <Eighth_Doctor> since the whole thing is kinda undefined at the moment
[10:07] <zyga> Eighth_Doctor: but fedora  based core  systems are still a bit away for multiple reasons
[10:07] <Eighth_Doctor> aww
[10:08] <zyga> Eighth_Doctor: mborzecki's work is making the image building much more solid and well tested/defined
[10:08] <zyga> and something snapd can be a part of for core20
[10:14] <mborzecki> zyga: hm that could actually be an interesting experiment just to check how far one could go
[10:14] <zyga> mborzecki: yeah but ENOTIME
[10:14] <zyga> mborzecki: but yeah
[10:14] <zyga> speaking of time
[10:14] <zyga> it's time to look at https://github.com/snapcore/snapd/pull/7080
[10:14] <zyga> and at  https://github.com/snapcore/snapd/pull/7078
[10:15] <zyga> after those two I only have one python change left
[10:15] <zyga> changing renaming order
[10:16] <ogra> Chipaca, I fixed the (WSL) topic for you ;)
[10:36]  * zyga wraps up for late breakfast and walk
[10:36] <mborzecki> hm no way to tell if spread test exited early/was skipped due to some extra checks :/
[10:36] <zyga> mborzecki: nope, no SKIP
[10:36] <mborzecki> i think we discused that but there was no outcome
[10:41] <mborzecki> cannot snap ack test keys on rpi, error: cannot assert: assert failed: cannot find account (testrootorg)
[10:43] <zyga> need to tweak renumbering some more, tmpfs size depends on instance memory and it seems we get one of two sizes
[10:43] <zyga> oh well
[10:43] <zyga> after  lunch
[10:44] <mborzecki> aand cannot use a fakestore with external backend :/
[10:46] <zyga> bbl
[11:06] <popey> kyrofa: is nextcloud-client one of yours? It's private. Does it need work, or handing over to someone active?
[11:10] <zyga> re
[11:16] <zyga> - Download snap "go-example-webserver" (25) from channel "stable" (received an unexpected http response code (503) when trying to download https://canonical-lgw01.cdn.snapcraft.io/download-origin/canonical-lgw01/AXQwkeqxpsWVOF2kUsgT6zJKVW8H9NIm_25.snap?token=1562594400_3c2fed171bc8c205f871d84b418ef6de7625d0f8)
[11:16] <zyga> some CDN woes
[11:16] <zyga> maybe store woes? https://www.irccloud.com/pastebin/qmzSIDds/
[11:18] <zyga> I restarted three runs
[11:18] <mvo> zyga: might be worth checking with the store people
[11:18] <zyga> I checked status.snapcraft.io, all green there
[11:18] <zyga> if this  happens again I'll ping store
[11:20] <mvo> cmatsuoka: hey, good news. I managed to boot a luks enabled uc20 now (with your prs). could you please check https://github.com/snapcore/snapd/pull/7077  ? I made some small tweaks
[11:21] <mvo> cmatsuoka: once that is merged into uc20 the spike-tools from github.com/snapcore/spike-tools should be able to do the full image build, i.e. this should then work end-to-end (when building on bionic)
[11:22] <zyga> mvo: what do you think we should do with  https://github.com/snapcore/snapd/pull/7062
[11:22] <zyga> mvo: 1) scope it to 16.04 so that it passes, close the PR?
[11:24] <cmatsuoka> mvo: awesome! I have some clean-ups in my todo list, mostly debug code related to certain actions requiring a small delay -- did you experience any non-deterministic behavior during your tests?
[11:26] <mvo> zyga: let me look
[11:27] <mvo> cmatsuoka: I added one more sleep before the filesystem creation
[11:27] <mvo> cmatsuoka: and some error checking
[11:27] <ogra> ogra@pi4:~$ snap debug confinement
[11:27] <ogra> strict
[11:27] <ogra> ogra@pi4:~$ uname -a
[11:27] <ogra> Linux pi4 5.1.16+ #1 SMP Mon Jul 8 10:31:01 UTC 2019 armv7l armv7l armv7l GNU/Linux
[11:27] <ogra> \o/
[11:28] <zyga> ondra: can we get 5.2?  :D
[11:28] <zyga> ogra: ^
[11:28] <zyga> sorry :)
[11:28] <ogra> haha ... i know ondra likes to be me :)
[11:28] <zyga> 5.2 has the new mount APIs
[11:29] <cmatsuoka> mvo: yeah, I just saw the extra delay -- I'll try arighi's kernel to see if it behaves better regarding potential races
[11:29] <ogra> zyga, i'll take a look ... thats all very early anway ... we have no u-boot for the pi4 yet ... but i want to get at least a hacked up classic image to work with this kernel and the upstream bootlaoder setup (no initrd)
[11:29] <zyga> ogra: classic is fine :)
[11:30] <ondra> zyga you can just use ondra, ogra has highlight on my nick anyway :P
[11:30] <ogra> well, its "hacked classic"
[11:30] <zyga> hahaha
[11:30] <ogra> (i.e. just a debootstrapped rootfs plus kernel and upstream bootloader)
[11:32] <cmatsuoka> mvo: there was a place where I manually added a bunch of modprobes to make cryptsetup work, now I think I was actually adding minute delays and we may have hit another race there
[11:33] <mvo> cmatsuoka: I see minute waits when booting
[11:34] <mvo> cmatsuoka: should I look into initramfs to see these sleeps?
[11:44] <cmatsuoka> mvo: I'm removing the lines that shouldn't be there and running some tests
[11:44] <cmatsuoka> If these are really required I'll test them again with the new kernel
[11:45] <mvo> ta
[11:58] <zyga> Chipaca: hey
[11:58] <zyga> Chipaca: do you need that WSL2 data?
[12:00] <zyga> Catalog update is doing verbose http logging (it should not).
[12:00] <zyga> hmm
[12:01] <zyga> I'm not lucky with PRs today
[12:02] <Chipaca> zyga: I'd like it, but it's not essential, why?
[12:03] <zyga> Chipaca: I can try to unpack that laptop after lunch and give you the answer
[12:03] <Chipaca> zyga: no rush
[12:03] <zyga> Chipaca: alternatively I can easily give you the answer in the evening
[12:03] <zyga> Chipaca: after we check in
[12:03] <Chipaca> zyga: basically i want to know if the default WSL2 kernel still has Microsoft in /proc/version
[12:04] <Chipaca> zyga: the person in the forum is running their own kernel so anything goes in there :-/
[12:04] <zyga> aha
[12:04] <zyga> there are ways to detect wsl 2
[12:04] <zyga> simple one: /init is a p9 mount
[12:04] <Chipaca> but as this is meant as a "yeah this won't work" aid to users, I'm not worried if they circumvent our checks and then things break
[12:06] <Chipaca> "when I try to change channels it doesn't work and my eyes hurt!" "hitting yourself with the remote is a bad way to change channels, don't do that" "i removed my eyes, trying to change channels no longer hurts, but it still doesn't work!"
[12:07] <Chipaca> *sigh*
[12:07] <zyga> hehe
[12:07] <zyga> in that case
[12:07] <zyga> I'm off for lunch
[12:07] <zyga> if anyone wants to look: two simple python PRs are pending
[12:22] <pedronis> at least 3 of PRs need a review or 2/3 review: 7006, 7020, 7066
[12:42] <pstolowski> looking at 7006
[12:42] <pstolowski> *7066
[12:42] <pstolowski> grr, 7006
[12:56] <ijohnson> morning folks
[12:57] <pedronis> Chipaca: 6977 is probably something you should review (it relates to the refactor)
[12:59] <zyga> Hey ijohnson
[13:00] <ijohnson> hey zyga
[13:00] <zyga> mvo:I will not be able to make it
[13:00] <zyga> Mvo sorry, still finishing lunch
[13:31] <cmatsuoka> uh, it was just me or  something strange just happened in the video call?
[13:36] <jdstrand> Chipaca: ouid is the 'object id' of the thing being referenced in the permission check. so in that case, the fifo (the object) is owned by root and being accessed by non-root (the fsuid)
[13:37] <jdstrand> zyga: hey, why do we have a meeting on pr 7058?
[13:37] <jdstrand> mvo: ^ (hi btw)
[13:41] <mvo> jdstrand: in a meeting right now, I will get back to you in 5min or so
[13:42] <ogra> ouid ? are you sure thats not a french daemon saying yes all the time ?
[13:43] <mvo> jdstrand: I think the idea about hte meeting was to see what (if anything) would break if we enable apparmor on upstream kernels and also what security features will be missing
[13:46] <mvo> jdstrand: it will hopefully be a short meeting :)
[13:47] <jdstrand> mvo: I thought we had that meeting in Lyon :) we don't really know what will break because we haven't run it in strict mode on those distros
[13:47] <jdstrand> well, we'll see. it might sound like I'm rehashing an old argument, but I promise I won't be. I'll just be honest in the assessment
[13:50] <pedronis> jdstrand: we are having a meeting because I was told you were +1 on this change now
[13:50] <pedronis> and wanted to understand the new reasoning
[13:51] <jdstrand> pedronis: it is because in Lyon, where I said that if we were going to make the change, I wanted to be sure everyone understood the cost (maintenance, regression, reputation). people said they understood the cost and wanted to do it
[13:51] <pedronis> jdstrand: I didn't
[13:51] <jdstrand> hmm, you were in the room. ok, does sound like a meeting is warranted
[13:52] <pedronis> yes, that's why we have one, lots of mixed messages
[13:57] <zyga> jdstrand: yes
[13:58]  * zyga misread  the question, reading backlog
[13:58] <zyga> ok, see you all in a minute
[14:54] <mborzecki> pedronis_: updated the big one https://github.com/snapcore/snapd/pull/6890
[14:58] <pedronis> mborzecki: thx, I'll try to go back to those PRs tomorrow
[15:05] <mborzecki> pedronis: great, thank you!
[15:09] <ijohnson> pedronis, mvo: the bug about seeding a classic image I talked about is here: https://bugs.launchpad.net/snapd/+bug/1835795
[15:16] <jdstrand> ackk: re those bugs you asked about, they will be fixed in the upcoming 2.40 release
[15:16] <ackk> jdstrand, thanks, awesome!
[15:16] <jdstrand> ackk: and sorry for the delay, I was on holiday
[15:16] <ackk> jdstrand, np, I figured :)
[15:28] <mvo> I see a lot of red tests, did anyone investigate?
[15:36] <zyga> rre
[15:38] <ondra> zyga I fixed test, still running slow ones, but it's looking way better now
[15:38] <zyga> thanks!
[15:50] <zyga> - Download snap "ubuntu-core" (1797) from channel "stable" (received an unexpected http response code (503) when trying to download https://canonical-lgw01.cdn.snapcraft.io/download-origin/canonical-lgw01/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap?token=1562601600_d9a2f9b4f5f2050b5dfa14ea244831be9b8bfd51)
[15:50] <zyga> noise][: ^ https://status.snapcraft.io says it's all good but I've seen a few of those today
[15:51] <zyga> this was strictly after 2019-07-08 12:58:56
[15:51] <zyga> (not sure which TZ is  that, reported by travis)
[15:53] <diddledan> something appears to have changed, and I can't figure out what - the extra menu items for gnome-twitch aren't visible any more: https://usercontent.irccloud-cdn.com/file/1vAA2qxd/image.png
[15:53] <zyga> diddledan: when did it change?
[15:53] <diddledan> I can't figure out what I've changed
[15:53] <diddledan> no idea
[15:54] <zyga> ijohnson: do you have time for 5 minute reviews today?
[15:54] <diddledan> I've tried rebuilding an ancient copy that I'm ssure was working in the past and it is also showing the empty menu
[15:55] <noise][> zyga: thx, we'll take a look
[15:55] <zyga> noise][: thank you
[15:55] <ijohnson> zyga: sure I can look at some small stuff in my afternoon
[15:55] <diddledan> it's interesting that there's a gap where the items should be, but it's only the size of one extra item when I think there should be more than one item in there
[15:55] <zyga> ijohnson: two simple PRs (with that label) from me
[15:56] <zyga> ijohnson: if you can it would help me move forwarrd
[15:57] <ijohnson> zyga: 7080 and 7078?
[15:57] <zyga> ijohnson: yes
[15:57] <ijohnson> cool I'll take a look in a bit
[15:59] <mvo> sergiusens: silly question, does snapcraft 2.43 not include the pyc files? is that fixed in later snapcraft version? we got a bugreport in the forum that indicates this is the case(?)
[16:07]  * zyga takes a break until next call
[16:09]  * ijohnson lunches
[16:10] <diddledan> I should do that. a few hours late at 17:10.... oops
[16:10] <diddledan> who needs food?!
[16:12] <mvo> sergiusens: hm, I just tried snapcraft 3.6 and in this snap (https://github.com/phocean/volatility-snap) there is no pyc files, is that expected (cc cjp256)
[16:13] <mvo> ?
[16:13] <mvo> (this is a python2.7 snap fwiw)
[16:14] <cjp256> sergiusens is on holiday today, i'll take a look
[16:15] <cjp256> in old versions of snapcraft, did it snap up the pyc files?
[16:15] <mvo> cjp256: no, no pyc files in both new and old
[16:16] <mvo> cjp256: I can (probably) workaround this by adding "python -m compileall ." during the build, I'm trying this now. but my understand was that snapcraft would do that (or something similar) for me automtically(?)
[16:17] <cjp256> ok, i haven't had a reason to look at how the python plugin works yet, but this is as good a reason as any :) i'll get back to you
[16:19] <mvo> cjp256: thanks, no rush, I will add my findings in the forum, its almost EOD here anyway :)
[16:33] <zyga> today is a day lost for travis
[16:39] <cjp256> mvo: fwiw, snapcraft itself compiles pyc files in override-prime: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml#L100
[16:40] <mvo> cjp256: interessting, for some reason that seems to have not worked when I build this example snap, maybe I did something wrong
[16:42] <mvo> cjp256: I can try a fresh build on a different machine tomorrow but for me the pyc files are currently missing
[16:43] <cjp256> did you add anything to the snapcraft yaml?
[16:43] <cjp256> the compileall?
[16:44] <cjp256> i should perhaps clarify: it appears that snapcraft's snapcraft.yaml explicitly does compileall in its override-prime in order to ship pyc files
[16:45] <mvo> zyga: do you know from the top of your head if/how I can disable seccomp in devmode (i.e. I don't even want complain mode, just nothing if possible)
[16:45] <mvo> cjp256: I ran the compileall in the prime dir and used that, its a bit of a tangent for my real investigation, I just happend to notice the pyc files are missing
[16:48] <cjp256> when using pip, it's directed to --no-compile (https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/_python/_pip.py#L352) and appears filtered from snap_fileset  (https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L440) - but that's just a cursory glance and I haven't traced what's happening in this case yet.
[16:51] <mvo> cjp256: the snap is using the "python" plugin: https://github.com/phocean/volatility-snap/blob/master/snap/snapcraft.yaml
[16:51] <zyga> mvo: no, devmode does not disable seccomp
[16:51] <zyga> mvo: you must use classic for that
[16:51] <mvo> zyga: yeah, just @complain - I switched to @unrestricted now
[16:52] <mvo> zyga: for testing
[16:52] <zyga> yeah that will work
[16:52] <mvo> zyga: context is the "Concerns about performance" forum post
[16:53] <zyga> aha
[16:53] <zyga> good thinking
[16:55] <mvo> zyga: updated the post with some more numbers, need to have dinner now
[17:12] <zyga> mvo: danke
[18:31] <plars> ogra: hi, I'm trying to limit ram for some testing on core with rpi using mem= set in the cmdline.txt, but so far it only gets as far as "Starting kernel..." and stops. Is this not possible on pi for some reason you can think of? I've tried 512M and 768M so far
[18:33] <ogra> hmm, it shouldnt block your boot, are you sure you dont have any syntax errors or some such ?
[18:34] <plars> ogra: all I did was add " mem=512M" to cmdline.txt
[18:34] <plars> if I take it out, it boots fine
[18:36] <ogra> weird ... probably related to the pi bootloader though
[18:36] <ogra> since it inits the GPU (and such the videoram) before powering up the arm SoC
[18:40] <ogra> perhaps try setting gpu_mem=16 (default is 64) in your config.txt
[18:41] <ogra> there is also disable_l2cache=1 you could try so the kernel doesnt use L2 from the CPU (but not sure if the kernel can cope without nay L2 at all)
[18:41] <ogra> s/CPU/GPU/
[18:42] <plars> ogra: hmm, not helping so far
[18:51] <plars> ogra: ah, ok I may have found a workaround by setting total_mem in config.txt instead of mem= in cmdline.txt
[18:52] <plars> ogra: thanks for the ideas!
[19:12] <cmatsuoka> what's the best way to build a kernel snap from kernel debs?
[19:28] <ogra> plars, awesome ... good to know (i didnt kow about that option)
[19:28] <ogra> *know