[03:26] when i "df -h" on my ubuntu machine, I get a lot of /snap/core/xxxx. what are these and why cant i remove them? [03:45] eraserpencil: snaps are distributed as squashfses, so those are the mount points for them [05:04] morning [06:02] Good morning [06:03] zyga: hey [06:04] How arę things [06:05] Arę, omg :-) [06:05] heh [06:05] Quick brekfast and reviews, reviews [06:06] went to manufaktura yday, to meet some friends, left the car in the parking lot and came back to this: https://i.imgur.com/2Pis8il.jpg [06:07] apparently some lady in her grand white bwm had trouble maneuvering the parking lot, knocked down 'give way' sign, hit my car and took off [06:07] Holly Caro [06:07] This sucks, [06:07] spent 3h waiting for the police to come to write the report and secure monitoring footage [06:07] But they should have her plate on camera [06:07] Excellent [06:07] Well [06:07] Considering [06:08] I hope she is caught quickly [06:08] yeah, me too [06:08] BMW is always something nasty in practice :-( [06:08] on a side note, i really hate going to manufaktura, it's always super crowded [06:10] I haven’t been there yet [06:11] I need to plan a trip to Łódź :-) [06:27] need to go to the hospital for a checkup, be back in ~2h === pstolowski|afk is now known as pstolowski [06:57] mornings [06:58] mborzecki: crap... good luck with that, i hope it won't take long to get resolved [07:42] pstolowski: hi, are you working on the post about disconnect/undo and interface hooks? or did you already and am I not seeing it? [07:43] pedronis: i didn't, i'm about to do it today [07:45] thx [08:16] moin moin [08:17] ogra_: can I make the pi2 boot output everything on the serial terminal somehow? currently I only get "booting kernel" and thats it [08:17] Chipaca: hey [08:18] diddledan: reckon we should push gimp rev 37 to stable? [08:18] mvo, edit cmdline.txt, drop the console=tty0 [08:19] ogra_: ta [08:20] ogra_: much better now :) [08:20] :) [08:35] pstolowski: I did a first pass over 4510 [08:36] pedronis: thanks [08:47] re [08:48] pstolowski: heh, notice the dark spot just in front of the car? https://i.imgur.com/nyDMOOQ.jpg this is where the sign was [08:48] pedronis: if you could give the comments on #4790 a once-over just to make sure, I'd appreciate that [08:48] PR #4790: jsonutil/puritan: introducing puritan.String & etc [08:48] * Chipaca updates the description there [08:49] Chipaca: yes, one sec [08:49] i still don't get how it's possible to pull shit like this with all the parking assitance, sensors, cameras etc. [08:49] mborzecki: unbeliveable [08:55] mborzecki: what happened? [08:55] Chipaca: looks good, but if you put an emoji in those comments my browser cannot or github is doing something that doesn't render it properly [08:55] Chipaca: a lady in a large white bmw knocked down a give way sign and hit my car, then she took off [08:56] Chipaca: I see � [08:56] pedronis: yes [08:56] pedronis: I mean, I wrote a � [08:56] Chipaca: all in a parking lot of a go-to shopping plaza in lodz, so lots of industrial cameras etc [08:57] mborzecki: so they've got you covered? ie the plaza security people? [08:57] Chipaca: is that special? [08:57] Chipaca: yeah, i called the police, waited 3h for them to get there, write a report and secure the footage [08:57] * pedronis is likely missing something [08:57] pedronis: maybe I should write “� (U+FFFD)”? [08:58] mborzecki: :-/ were you stuck there alone? [08:58] Chipaca: you remove the charatecter that usually means something else couldn't process things? [08:59] just so I understand [08:59] pedronis: pretty much, yes [08:59] pedronis: the strings are supposed to be valid utf8, so it shouldn't happen [08:59] pedronis: and in fact they have to be, per json [08:59] pedronis: so the only reason U+FFFD appears is if somebody intentionally put it there [09:00] Chipaca: ok, then yes a paranthesis (U+FFFD, aka replacement character) would be useful [09:00] and putting a character that means "something broke", intentionally, is not cool [09:00] Chipaca: nah, i was meeting with some mates before, so we stayed in the parking lot chatting and waiting for the police :) [09:01] mborzecki: "we waited, chatting and having a few beers" [09:01] :_D [09:01] Chipaca: because otherwise somebody looking at that code will be confused about the replacement character showing up just as itself :) [09:01] as I was, maybe [09:01] Chipaca: technically they had a few, i only had a soda and a tea :) [09:01] pedronis: … and that's why it's disallowed :-) [09:02] mborzecki: :-) [09:04] pedronis: there [09:11] Morning folks [09:13] Chipaca: thx [09:13] pedronis: now to wait for it to green [09:15] pedronis: https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 ; let me know if I missed something [09:15] PR snapd#4983 closed: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json [09:16] Chipaca: you make my heart break ^^ [09:17] mborzecki: ikr [09:17] Chipaca: runuser it is then? [09:18] mborzecki: runuser + dd + mv + sync, probably [09:18] for the write case [09:18] mvo, regarding your uboot.env research, you might also want to take a look at what systemd does to the partition (i think it runs an fsck too before mounting) [09:18] mborzecki: arch doesn't use a weird dd or sync does it? [09:18] mborzecki: i mean, all from coreutils? [09:19] Chipaca: woo, nice combo, iirc in case we ever need it runuser suppors switching selinux contexts too (or maybe some other tool?) [09:19] should I give up and just hand it off to /bin/sh [09:20] grmbl [09:20] Chipaca: nothing weird with dd or sync here [09:20] k [09:21] ogra_: yes, we do that (we set the fstab line to fs_passno to 2). it looks like this is part of the problem, fsck.vfat corrupts more than it fixes :( [09:23] mvo: meanwhile, patching u-boot would be nice too, if you upload the boot partition somewhere i could take a stab at it over the weekend [09:24] mborzecki: sounds good, I will send you the link to the corrupted image. I think the upper/lower case is a bit of a red-herring, it comes down to "lfn" (long-file-name) directory entries [09:25] mborzecki: what is super annoying is that its really hard to recover once there is this corrupted file on disk [09:28] mvo: running fsck does not fix it right? [09:28] mborzecki: it claims it does, but I think it leaves the directory entires on disk in a state that confuses uboot so next write uboot will pick up the wrong file (short name fsck0000.000) again [09:29] mborzecki: which is super annyoing nice that was got delete in my fixup script [09:30] mvo: will we use the repair assertion? [09:30] mborzecki: this is the only way that worked so farhttps://paste.ubuntu.com/p/ySvHbxRVH9/ - slightly terrible though [09:30] zyga: interessting idea [09:30] zyga: fixing this oob might not be a bad option [09:30] zyga: my goal was to fix in initramfs but its harder than I anticipated [09:31] what will we do about affected devices? [09:31] they are "bricked" right? [09:32] mvo: do you think there's a chance the file could have been there in the original image that was shipped with the devices? === pstolowski is now known as pstolowski|bbiab [09:33] mborzecki: that is possible. however my theory is that our fsck created it. from looking at the code there it seems to rename files under some cirumstances but keep the lfn (long-file-name) the same, my theory is explained inhttps://github.com/dosfstools/dosfstools/pull/83 but no feedback yet [09:33] PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove on auto_rename() [09:34] mborzecki: we run fsck.vfat on mount for /boot [09:35] mborzecki: even more annoying we don't have enough modules in initrd to mount as vfat and copying stuff around there is jjust terrible, i.e. this will be totally broken when the power is cut at the wrong point. so I'm still looking for options [09:35] mborzecki: maybe I should write what I found in the forum to ensure everyone knows what is going on [09:39] mvo: fwiw uboot ENV_IS_IN_FAT is a questionable idea [09:40] mborzecki: what can we do to fix that? [09:40] pstolowski: seems to capture the problem, made a comment of a possible variant, I suppose we need to discuss with niemeyer the options [09:40] mvo: it'll be risky for devices that are already deployed [09:41] mborzecki: yeah :/ [09:41] mvo: but i'd recomment ENV_IS_IN_MMC, and put it somewhere at the boundary of 2 separate erase block sizes (you'd really know what the size is with mmc but you can try and do an educated guess, or side channel benchmarks to find out) [09:42] mvo: and instead of parsing uboot's env manually, work with fw_printenv/fw_setenv instead [09:43] offtopic [09:43] have you guys seen "checks" [09:43] https://github.com/snapcore/snapd/pull/5144/checks for example [09:43] PR #5144: tests: update bionic release image on gce [09:45] mborzecki: the idea ENV_IN_MMC sounds good, we should talk about this after the fire is over. portability comes to mind. the fw_printenv stuff we did initially but it had its own set of problems, I need to dig into git history (and memory) to remember those. [09:46] mvo: yeah, setting up fw_env.config is quite funny :) [09:47] mborzecki: I think we actually are more careful with our writes than fw_setenv (but I'm biased so happy to accept that I'm wrong) [09:47] (or grudgingly accept it) [09:49] mvo: experimentation is key :) [09:50] otoh, pull a power plug on rpi and there's a chance it's not coming back up [09:51] mborzecki: yeah [09:56] * Chipaca despairs and switches branches for a bit [10:02] pedronis: thanks [10:06] PR snapd#5073 closed: set up journal streams in user session application autostart (2.32) [10:12] om26er: https://github.com/snapcrafters/android-studio/issues/23 :) [10:16] mvo: +1 for following up in the forum [10:31] PR snapd#4387 closed: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny [10:36] popey: yeah, everyone who's tested gimp 37 has reported back positively. let's ship it [10:38] mvo: I feel you're missing a 'GOTO 4' in your sequence of events [10:40] Chipaca: good point, I added a 10 which is not quite GOTO but close [10:42] :-) [10:45] popey: I've just done it [10:45] popey: prepare for the hoards of complaints :-p [10:45] WoooHooo! [10:45] Thanks diddledan ! [10:46] mborzecki, mvo, the only proper solution is to use u-boot only as SPL for a UEFI grub boot ... get rid of all u-boot patching, completely de-couple the OS by simply chainloading grub-UEFI ... redhat and opensuse only support that model nowadays and we should too (i had quite some discussions with the maintainers of both distros during embeddedworld) [10:47] mvo, i was wanting to write a prototype for this but customer work is eating my time [10:48] running snapcraft in an i386 container (lxd) on an amd64 host I'm getting: "sudo: main: unable to allocate memory" when it tries to install apt packages [10:48] mvo, we'd only need to maintain grub.cfg and porters can use u-boot as-is from their BSP [10:49] (no patching at all) [10:50] (along with that you get the full UEFI secureboot setup for free ) [10:51] PR snapd#5145 opened: boot: clear "snap_mode" when needed [10:51] Chipaca: someone with a fresh and sharp mind should look at 5145 [10:51] mvo: we should hire somebody like that [10:51] Chipaca: this should give us the first line of defense, i.e. no more bricking but also no more refreshes [10:52] Chipaca: lol [10:53] mvo: where does "trying" come into the picture [10:53] ? [10:54] mborzecki, mvo in case one of you wants to take a look, http://download.opensuse.org/ports/armv7hl/factory/images/ has all images using this setup (not sure if the RH images are public, but it is a well maintained setup nowadays and has active upstreams) [10:56] ogra_: thanks, will take a look [10:56] ogra_: wow ..sabrelite, brings back bad memories [10:56] haha, yeah, i still have one running here with a 15.04 core install [10:57] (i still love the full SATA it has) === pstolowski|bbiab is now known as pstolowski [11:05] Chipaca: trying is usually cleared by the snapd boot code, i.e. it switches to "". it is only used so that uboot knows it tried to boot and things did not work at all in which case it reverts back to the good core/kernel [11:07] mvo: is the state sequence try -> trying -> "" ? [11:08] pedronis: correct [11:08] pedronis: I can write something in the forum if you want, seems like this should be documented better [11:09] mvo: should snapd remove all the uboot.env files and write a new one to "recover"? [11:09] pedronis: snapd sets to "try", bootloader from "try" to "trying" and snapd (after reboot) from trying to "" if things went well [11:09] (recover FAT) [11:09] mvo: would detecting the breakage and re-writing the boot partition be doable? [11:09] mvo: yes, I see only a not very complete comment in partition/bootloader.go [11:09] Chipaca, zyga yes, remove and rewrite seems to work [11:10] mvo: as in while uboot.env exits, remove it // tricky [11:10] Chipaca, zyga not very atomic but give this is already a holly-crap situation maybe an acceptable workaround [11:10] pedronis: sure, will do [11:10] this is somewhat less nuclear than repartitioning /boot [11:10] * zyga -> coffee [11:11] zyga: yeah, let me try something like that [11:11] we also should consolidate this code at some point, is a bit spread around partiation snapstate etc [11:11] pedronis: good point [11:11] anyway [11:12] mvo: I think this also shows the issue that we need to detect reboot vs restart [11:12] which is a TODO pending since a bit [11:18] pedronis: restart as in restart due to a failure? [11:18] yes [11:19] anyway I looked at the PR and it's probably less urgent than I thought [11:19] pedronis: at what PR did you look? [11:19] your new PR [11:20] pedronis: less urgent? how so? [11:20] mvo: your new code seems correct either way [11:20] pedronis: aha, yes [11:21] mvo: aynway at some point you should review my #4497 [11:21] PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it [11:21] pedronis: thats a nice aspect about it, it also fixes the case when we snap refresh new-core, snap refresh current-core without a in-between reboot [11:21] pedronis: yes, once the fires are out :) the next big fire for today is the snapd.seeded.service thing [11:24] mvo: Let me know if/when you want to discuss it [11:31] niemeyer: I commented in the PR to your suggestion [11:32] pedronis: I've seen it, but not sure I'm reading your point completely [11:32] niemeyer: I'm just trying to double check that we are doing this because we think snap wait snap key will be generally useful, we will promote it [11:33] pedronis: Right, that was the idea.. I think waiting for a state on the snap sounds generally useful [11:34] pedronis: snapd and otherwise [11:34] niemeyer: ok, but this state is config right? I mean snapd itself is already using bits of config to expose state, I'm just making sure we think that's the way to go also for other snaps [11:34] PR core-build#29 closed: ubuntu-core-rootfs: deal with leftover fsck files [11:34] niemeyer: it will need to fit in in schemas as well when we get there [11:35] pedronis: Not sure there's much to add in terms of schema [11:35] niemeyer: well, we want to make this things read-only no? I don't think we want a user to do snap set system seeded false [11:35] pedronis: Config is state.. can't see it otherwise [11:36] I mean read-only from outside the snap [11:36] or at least the snap should have that choice [11:36] pedronis: Yeah, I think this depends on the use case at hand.. properties that are read-only outside the snap is definitely sensible [11:36] pedronis: For seeded it makes sense too [11:36] indeed, that would fit into schemas [11:36] PR snapd#5146 opened: tests: fix user mounts test for external systems [11:38] zyga: Chipaca: updated 5141 [11:38] niemeyer: and maybe my questions were redudant but we have already so many concepts flying around, I wanted to make sure the plan was what it looked like [11:38] ack [11:39] pedronis: The question seemed fine.. I was just concerned about missing some deeper underlying point [11:39] niemeyer: probably after the standup, still working on mitigation on the vfat bug [11:40] Hi every one === hi is now known as Guest57528 [11:40] niemeyer: hey, i've documented https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 , we should discuss the options [11:40] i just want to know the command in snap.yaml file [11:42] mborzecki: +1 [11:43] PR snapcraft#1064 closed: pluginhandler: collide with directories and symlinks [11:43] HELP [11:44] Any one tell me the command line process inside the snap.yaml file [11:45] huh? [11:45] (App: Command: )in snap.yaml [11:45] peter___: can you explain what you mean by that? [11:46] * cachio_ afk [11:47] I am not clear with (Command: Path to executable (relative to snap base) and arguments to use)? [11:47] peter___: it is the command you want to associate with a given application [11:47] peter___: any shell command you want to run [11:48] I am new to snap. === alan_g_ is now known as alan_g [11:49] mvo: do you need more eyes on #5095? it has +2 and could be merged [11:49] PR #5095: snapstate: support getting new bases/default-providers on refresh [11:51] pstolowski: it says explicitly it's missing spread tests [11:52] pedronis: ah, right, should be marked blocked then [11:52] yea, doing that [11:53] we did at the same moment ;) [11:54] :) [11:54] I see alot of branches failing spread tests today? [11:54] I see timeouts [11:54] Chipaca: your safejson PR for example [11:55] niemeyer: hi! I responded in https://github.com/snapcore/snapd/pull/4387 [11:55] PR #4387: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny [11:57] pedronis: yes, timeouts downloadin core from the store [11:57] meeep [11:59] jdstrand: Responded [11:59] pstolowski: Thanks for the post! [12:01] my project developed in netbeans how to create snapcraft.ymal for this, please assist [12:04] * Chipaca ~> lunch [12:11] newbee: for java we have these docs: https://docs.snapcraft.io/build-snaps/java , and snapcraft plugins has maven, gradle and ant plugins for dealing with java projects [12:11] i have installed snapd and snafcraft snap on my linux mint 18. in netbeans IDE8 i have created a java helloworld program. after that i created a snapcraft build and snapcraf.ymal file is generated [12:12] in this snapcraft.ymal file how to mention the hellowrold program [12:15] hmm [12:15] cat: write error: No space left on device [12:16] that's on opensuse [12:16] Chipaca: could slow / failed / retried downloads fill the disk of a VM? [12:16] newbee: hey, have you seen: https://snapdocs.labix.org/the-snap-format/698 ? [12:18] newbee: what does the build produce a jar ? something else? in that doc example the command goes into apps: freeplan: command: (see the Apps section there) [12:19] zyga: thanks, we have go through the snapcraft.io documents in ubuntu core site, will try this too.. [12:20] zyga: your new doc page mentions a command that is not there yet? it should probably list in which versions the various commands appeared [12:21] pedronis: ah, great point, I'll add that [12:22] pedronis: yes its creating .jar file, but in that we confused what are the commands should we use. [12:23] pedronis: done [12:25] zyga: I think we just discovered that discourse has no conflicts checks [12:25] pedronis: indeed, my changes are gone [12:25] what did you do? [12:25] zyga: I did an edit too, it seems your changes are not there [12:25] I edited the last section about get-base-declaration [12:26] sorry :/ [12:26] no worries [12:26] I'll add the edits back [12:26] * zyga holds the forum lock ;-) [12:28] * zyga drops the forum lock [12:29] pedronis / zyga : sorry for the intruption, do you got my question.. [12:29] newbee: whatever commands are appropriate to run a jar file [12:29] java -jar ... probably [12:29] * zyga needs to take the dog out [12:29] ttyl [12:31] also want to know does the snap can be decompile ? [12:33] newbee: it's not compiled, is just a compressed filesystem [12:34] if you care about obfuscation you need to add it at the level of compiling/producing the jar [12:36] is there any other sites to refer to create snapcraft.ymal file...? [12:36] also please share example snapcraft.ymal file for java application ... [12:37] It should be all documented [12:37] Did you google for that? [12:38] newbee: here's is an example for a jar: https://github.com/snapcore/snapcraft/blob/master/demos/gradle/snap/snapcraft.yaml [12:38] niemeyer: responded [12:39] pedronis: ok, will try with this.. [12:39] newbee: what java plugin are you using? [12:39] niemeyer: morning, hope the trip back home was good. Pinging you to see if we can get an rfc (request for comment) tag on the forum, to be used to specs and user stories of the work ahead so we can easily find them later. [12:40] newbee: you can do snapcraft prime and look around in prime to see what gets built, where things are [12:42] @pedronis : we are using netbeans default plugin - ant [12:42] ok [12:43] sergiusens: Sounds reasonable, but request-for-comment and spec is not the same thing.. user stories is also not a spec.. how about a more general "design" tag? [12:43] newbee: this one example is using ant: https://github.com/snapcore/snapcraft/blob/master/demos/java-hello-world/snap/snapcraft.yaml [12:45] niemeyer, oh, while sergio brings this up, does discourse have a way to allow more than one category for a post (a config option etc) .. . i often have posts that would benefit from being able to be in more than one category (specifcally in the device section) [12:46] niemeyer: +1 on design tag [12:47] ogra_: maybe device should be a tag instead of a category? [12:47] @pedronis: Thanks, please clarify my understanding , in the command i have to mention the java path and the project path .. [12:47] Chipaca, dunno, would people still use it then ? the category is pretty visible which is helpful [12:48] it just happens often enough that i think "hmm, tis happens on core but would benefit from more attention via the snapd category" ... [12:48] ogra_: No, one per post only [12:48] niemeyer, ok, thanks [12:49] pstolowski: if pedronis is happy with 5095 then I would say we should merge it [12:50] pstolowski: aha, spread tests, nevermind [12:50] mvo: I haven't checked it carefully but indeed spread tests [12:52] sergiusens: done [12:53] PR snapd#5147 opened: snapd.core-fixup.sh: add workaround for corrupted uboot.env [12:54] newbee: I'm not sure what you mean with project path, the command can refer only to things inside the snap, as I said, if you run "snapcraft prime" and look into the created "prime" dir you should see what is inside and where [12:54] *things inside the snap or provided by the core snap [12:58] @pedronis- ok will try, thanks [13:00] Hey, just heating up some water.. will be with you in a moment [13:08] pstolowski: https://www.reddit.com/r/AskReddit/comments/7r1395/besides_bmw_which_car_has_the_douchiest_drivers/ [13:08] thanks for the tag! [13:08] Chipaca: ty :) [13:22] * diddledan twiddles his thingies until alsa-project.org comes back online [13:36] is snap core down? [13:36] Chipaca: on that note, we have a joke - since they generally don't use turn indicators here: the guy shows up at a car service saying his front light broke as it's blinking all the time [13:36] I've been trying to install a few packages and also just search the website [13:37] um1b0zu: store is having issues today, yes [13:37] and I keep getting 500 and timeout errors [13:37] ok. so it's not a me problem [13:37] thanks! [13:37] um1b0zu: https://status.snapcraft.io [13:37] um1b0zu: down: very yes [13:37] um1b0zu: although it might be coming back :-) [13:37] and also https://forum.snapcraft.io/t/intermittent-outage-on-snap-downloads-and-uploads/5342 [13:38] nbd I just figured I'd ask [13:50] * zyga is back home now [14:08] Will snap packages use the same gtk settings? [14:20] a storm is coming here [14:21] was that a trump reference ? [14:22] it's a hot day, who knows ;) [14:24] :D [14:27] ogra: he said a storm, not a stormy [14:28] cwayne, didnt he qoute SNL ? [14:28] *quote [14:28] ogra_: oh dunno, didn't see it yet [14:28] heh [14:28] dont want to spoil ya then :) [14:29] lol === rsalveti is now known as rsalveti__ === rsalveti__ is now known as rsalveti [14:40] I think in US the weather is officially "shit storm" [14:40] here it's just rain [14:40] and warm air 😃 [14:51] s/weather// [15:21] Hi jdstrand. I am working on microk8s and it seems I am hitting a permission denied from AppArmor when trying to terminate a pod. However I am on devmode. [15:37] kjackal_: hey, perhaps I can help you [15:37] what is the denial that you see? [15:38] Hi zyga, it is a permission denied from a docker deamon trying to sent signal kill 15 to a container [15:38] kjackal_: can you please paste the denial [15:39] let me see if i can spot it, give me a moment [15:39] kjackal_: dmesg | grep DENIED might help [15:41] zyga: let me ping you in a few minutes. I need to redeploy, just a sec [15:42] sure [15:56] zyga: are you still there? https://pastebin.ubuntu.com/p/d9pgT6sFXj/ [15:56] sure [15:57] last couple of lines [15:57] 4 lines [15:57] kjackal_: thanks, can you dmesg | grep DENIED [15:57] and pastebin that [15:57] what I see is May 9 09:18:03 jackal-VGN-FZ11M kernel: [ 2699.709975] audit: type=1400 audit(1525846683.188:298601): apparmor="DENIED" operation="signal" profile="docker-default" pid=23021 comm="containerd" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.microk8s.daemon-docker" [15:57] but I want to make sure we're not missing something [15:57] what is interesting is that this is the profile for docker, not for the snap, that is in the way [15:58] https://pastebin.ubuntu.com/p/6bhqbBjKVQ/ [15:58] zyga: How does it get decided which profile to be used? [15:59] is there some kind of pattern matching? [15:59] If I rename the snapped docker daemon to something else would the right profile be used? [16:00] kjackal_: this profile (docker-default) comes from docker, not from snap world [16:00]