[05:22] <mborzecki> morning
[06:02] <mborzecki> mardy: hey'
[06:04] <mardy> mborzecki: hi!
[06:06] <mardy> mborzecki: I'm struggling with writing a unit test. I don't understand how to do mocking in Go... and on the interwebs I can't find anything useful
[06:06] <mardy> I found this: https://stackoverflow.com/questions/36688872/golang-test-mock-functions-best-practices, but still doesn't answer the main question (if you search for "mardy" in the page you'll find the question I just added)
[06:07] <mardy> they all explain how to mock a function or an interface, but not how to mock a package
[06:11] <mborzecki> mardy: quich chat maybe?
[06:11] <mborzecki> and you can share your screen then
[06:14] <mardy> oh, thanks, sure
[06:16] <mardy> mborzecki: sent you an invite
[06:30] <mborzecki> mvo: hey
[06:32] <mvo> good morning mborzecki 
[06:46] <zyga-mbp> good morning
[06:46] <zyga-mbp> mvo: hey :-)
[06:46] <zyga-mbp> how are you doing?
[06:46] <mvo> good morning zyga-mbp ! I'm good, thank you
[06:48] <zyga-mbp> mvo: I'm working on something that could be useful for you when completed: a way to run spread tasks against a lava installation
[06:48] <zyga-mbp> mvo: lava supports quite a lot of devices for automation, so it might be an alternative to test flinger 
[06:49] <zyga-mbp> mvo: we should have it working in a week or two
[06:49] <mvo> zyga-mbp: nice! do we use that in our cert lab too?
[06:50] <zyga-mbp> mvo: I don't know, even if it's really apt-get install away to get working, there's some initial config (admin user, register devices) but it could be something to consider especially if the target board is supported already
[06:50] <zyga-mbp> mvo: and plars has long linaro history so it's not entirely foreign
[06:51] <zyga-mbp> mvo: anyway, for us it's a way to have one infra layer for linux and zephyr 
[06:51] <mvo> zyga-mbp: cool, I guess I shall talk to plars (?)
[06:51] <zyga-mbp> mvo: while being able to use spread locally during development and in CI 
[06:51] <mvo> zyga-mbp: neato
[06:51] <zyga-mbp> mvo: for linux at least, zephyr is a big unknown for now :)
[06:51] <zyga-mbp> mvo: cool, I'll let you guys know when it's working
[06:52] <zyga-mbp> mvo: if you want to see any of the patches and have a chance to review we can do that too, but I don't know if you have the time to invest in that activity 
[06:52] <zyga-mbp> mvo: we literally just have the first two patches up for review
[06:53] <mborzecki> zyga-mbp: prs to spread upstream?
[06:54] <zyga-mbp> mborzecki: sure but I'm still waiting on the small PR to unbreak tests
[06:54] <zyga-mbp> I have patches that fix go 1.6 support, make go vet happy
[06:54] <zyga-mbp> I can all post those but really, someone has to review 
[06:54] <mvo> zyga-mbp: I organized a review meeting for monday, I hope to land some of the pending spread PRs then
[06:54] <zyga-mbp> mvo: oh that's cool
[06:54] <zyga-mbp> mvo: next monday?
[06:54] <zyga-mbp> I can post more then
[06:54] <mvo> zyga-mbp: let's see how this goes
[06:54] <zyga-mbp> cool, thank you for organizing that!
[06:55] <zyga-mbp> I will post everything I have that's relevant 
[06:55] <mvo> zyga-mbp: my pleasure
[06:55] <zyga-mbp> woot, that's great
[07:05] <pstolowski> morning
[07:13] <mvo> good morning pstolowski 
[07:15] <zyga-mbp> good morning pedronis :)
[14:37] <cachio_> mborzecki, hi, tumbleweed is failing to build https://github.com/snapcore/snapd/pull/10367/checks?check_run_id=2794258646#step:5:3568
[14:37] <cachio_> any idea about how to fix it?
[14:59] <mborzecki> cachio_: hm looks weird, the builds on OBS are green, although the last rebuild was 3 days ago
[15:08] <mborzecki> pedronis: opened https://github.com/snapcore/snapd/pull/10377 which should be fairly easy to land
[15:10] <pedronis> mborzecki: thx
[16:02]  * cachio_ lunch
[16:07] <pedronis> ijohnson[m]: https://github.com/snapcore/snapd/pull/10266 is ready for re-reviews I think
[16:08] <ijohnson[m]> pedronis: ack will add it back to my queue
[16:12] <pedronis> thx
[16:18] <mvo> could someone do a quick double check at 10378, I need a +1 for merging
[16:18] <ijohnson[m]> mvo: looking now
[16:18] <mvo> ta
[16:20] <ijohnson[m]> mvo: approved
[16:31] <dob1> hi, hy a snap application cannot enter a directory mounted via autofs ?  it gives me permission problem with all snap applications while I have no problem to access that dir with my user via terminal/other application
[16:31] <dob1> I get this error  Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)
[16:35] <dob1> ah because snap apps can only access home dir?
[16:36] <dob1> https://askubuntu.com/a/1033617     why this limitation?  it makes no sense....
[16:36] <ijohnson[m]> dob1: snaps need to be given permission to access files through interfaces, the mount-observe interface would give access to /proc/self/mountinfo IIRC
[16:37] <dob1> ijohnson[m], and how?
[16:38] <ijohnson[m]> dob1: are you building your own snap or are you using someone else's snap ?
[16:38] <dob1> someone else
[16:38] <ijohnson[m]> dob1: you can check if the snap has the mount-observe interface plug defined with `snap connections <name-of-snap>`, if it shows up then all you need to do is `snap connect <snap-name>:mount-observer`
[16:39] <ijohnson[m]> s/mount-observer/mount-observe
[16:40] <dob1> ijohnson[m], it's not
[16:40] <dob1> let me say, not to critic the work of someone else, but it's so complicated ... why ? in 2021 I just want to access a file other that my home dir....
[16:42] <ijohnson[m]> dob1: then you need to ask the publisher to add that connection to their snap, you should be able to contact them if you look at `snap info <snap-name> | grep contact`
[16:53] <dob1> ijohnson[m], why there is a such limitation by default?
[16:55] <ogra> dob1, because everyone can upload and create snaps in the store the apps run in a confined space 
[16:56] <ogra> dob1, the interfaces allow you as a user to decide if you trust the app enough to give it permissions to access info, hardware or places of your system
[16:57] <ogra> (imagine IOS or android apps)
[16:57] <dob1> well it's not the same
[16:58] <ogra> sadly the author of your app did not add the interface plug you need here 
[16:58] <dob1> ios and android apps (more ios ones) are checked by apple and google before user can use them from app/play store
[16:58] <ogra> the same happens with snap apps
[16:58] <ogra> they run through a ton of automatic checks on upload
[16:58] <dob1> that's fine then
[16:59] <ogra> the difference is that n IOS or android you get a popup asking you for the permissions when the app tries to access i.e. your GPS
[16:59] <ogra> snaps do not have that integration yet 
[16:59] <ogra> so you need to come here and ask 🙂
[17:00] <ogra> and then ask the snap developer to add the missing plug 
[17:00] <RzR> the other option would be to let user define forbiden interfaces and let the application deal with this
[17:00] <dob1> this application is a mp3 player, it makes sense that I want to load my mp3s from another location than my home.... 
[17:00] <ogra> eventualy snaps will also ask about the permissions interactively ....
[17:01] <RzR> or let user define granted paths for app (ie: ~/Music by default)
[17:01] <ogra> well, most player apps tat need this have the removable-media plug ... if yu connect it it will give you access to /mnt and /media where i.e. usb disks get automounted
[17:02] <ogra> does "snap connections <the app you have>" list removable-media  ?
[17:02] <dob1> ogra, it lists this one
[17:03] <ogra> try mounting your disk in media or mnt ... and use snap connect to connect the interface 
[17:03] <ogra> that should get you going
[17:03] <ogra> RzR, ~/Music is included in the home interface 
[17:03] <dob1> ogra, I installed another app in the meanwhile, no problem.  I was just considering how this system works.  I am used to just apt 
[17:04] <ogra> yeah 🙂
[17:04] <ogra> snaps are closer to mobile or tablet apps than to apr/rpm 
[17:04] <ogra> *apt
[17:04] <RzR> ogra, but maybe user want to not expose ~/Documents 
[17:04] <ogra> also incuded in home
[17:05] <ogra> oh that ...
[17:05] <ogra> yeah ... we dont have such fine grained management yet
[17:05] <dob1> ogra, the idea of permissions make sense, it's not as you said user friendly but as RzR said it would be nice that the user can add any permission he wants
[17:06] <ogra> well, snaps do support xdg portals ... with that you can access anything on the filesystem the user has read access to 
[17:06] <ogra> but it requires the app developer to implemet it 
[17:06]  * cachio_ afk
[17:06] <ogra> not all apps have that 
[17:08] <dob1> can I read more about the checks on the apps?
[17:08] <dob1> do you have some link?
[17:08] <ogra> https://code.launchpad.net/review-tools should have some of it 
[17:09] <ogra> they are also packaged as a snap 😉
[17:09] <ogra> so you can "snap install review-tools" and run them at home
[17:09] <dob1> to be honest this is the part that worried me most
[17:09] <ogra> to check a snap before uploading
[17:10] <ogra> there is also a CVE checker builtin to check for known security vulnerabilities ... in case you want to check other peoples snaps yu have installed
[17:10] <dob1> ogra, where is is?
[17:10] <ogra> i just gave you the link above 🙂
[17:11] <ogra> (or the command to install the binary)
[17:11] <dob1> I take a look, thanks
[17:12] <RzR> I think there is at least 2 roles regardings such policies
[17:12] <RzR> what developer wants
[17:12] <RzR> and what user is ready to give
[17:12] <ogra> well, my mom doesnt care ... 
[17:13] <RzR> i care of my mom :)
[17:13] <ogra> she just wants to use the SW ... and wants to be safe .... i.e. not have her gmail passwords stolen by an mp3 player app
[17:14] <RzR> an other option would be to have pre-defined settings approved by some trusty org like EFF
[17:14] <ogra> and TBH the majority of ubuntu users is on a technical level of my mom
[17:14] <ogra> uh, what has the EFF to do with packaging software ?
[17:15] <RzR> maybe not EFF itself
[17:16] <RzR> but they can approve that some policies are trustworthy or not
[17:16] <RzR> this mean policies should be in other channels
[17:16] <ogra> so can the ubuntu security team 
[17:16] <RzR> like adblockers's black/white lists for the web
[17:16] <RzR> sorry if i am unclear
[17:17] <RzR> but I would be eager to apply to my systems some rules that will restrict the applications I use
[17:17] <ogra> you need to be deeply into the implementation to understand implications of what an interface does or doesnt allow 
[17:17] <RzR> instead of writing then myself
[17:17] <ogra> i dont think comparing it to URL list of adblockers is a good analogy
[17:17] <RzR> your MP3 player is a good example
[17:18] <RzR> what is reasonable and what is not
[17:18] <ogra> well, the philosophy of snap security is "less is more" ... meanings to be as locked down as pssible .... and then open peice by piece
[17:18] <RzR> but it's clear for me that it can't be done only by one entity 
[17:19] <RzR> good philosophy
[17:19] <RzR> well there are several problem here
[17:19] <ogra> so as requirements come in, interfaces are added and extended
[17:19] <ogra> but effectively the decision should lie at the user
[17:19] <RzR> but I wish a system that can be hardened user's side
[17:20] <ogra> it can 
[17:20] <RzR> good
[17:20] <ogra> you can always disconnect interfaces
[17:20] <RzR> this is valuable feature
[17:55] <pedronis> ijohnson[m]: I reviewed https://github.com/snapcore/snapd/pull/10347
[23:47] <mwhudson> does anyone have any idea why my snap build is failing with
[23:48] <mwhudson> /root/parts/subiquity/install/usr/bin/python3: No module named pip
[23:55] <mwhudson> and after snapcraft clean, multipass is complaining about the "snacraft remote" not working?
[23:59] <mwhudson> oh ssl errors in the logs grunk