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