| eraserpencil | 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:26 |
|---|---|---|
| mwhudson | eraserpencil: snaps are distributed as squashfses, so those are the mount points for them | 03:45 |
| mborzecki | morning | 05:04 |
| zyga | Good morning | 06:02 |
| mborzecki | zyga: hey | 06:03 |
| zyga | How arę things | 06:04 |
| zyga | Arę, omg :-) | 06:05 |
| mborzecki | heh | 06:05 |
| zyga | Quick brekfast and reviews, reviews | 06:05 |
| mborzecki | 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:06 |
| mborzecki | 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 |
| zyga | Holly Caro | 06:07 |
| zyga | This sucks, | 06:07 |
| mborzecki | spent 3h waiting for the police to come to write the report and secure monitoring footage | 06:07 |
| zyga | But they should have her plate on camera | 06:07 |
| zyga | Excellent | 06:07 |
| zyga | Well | 06:07 |
| zyga | Considering | 06:07 |
| zyga | I hope she is caught quickly | 06:08 |
| mborzecki | yeah, me too | 06:08 |
| zyga | BMW is always something nasty in practice :-( | 06:08 |
| mborzecki | on a side note, i really hate going to manufaktura, it's always super crowded | 06:08 |
| zyga | I haven’t been there yet | 06:10 |
| zyga | I need to plan a trip to Łódź :-) | 06:11 |
| mborzecki | need to go to the hospital for a checkup, be back in ~2h | 06:27 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 06:57 |
| pstolowski | mborzecki: crap... good luck with that, i hope it won't take long to get resolved | 06:58 |
| pedronis | 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:42 |
| pstolowski | pedronis: i didn't, i'm about to do it today | 07:43 |
| pedronis | thx | 07:45 |
| Chipaca | moin moin | 08:16 |
| mvo | 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 |
| mvo | Chipaca: hey | 08:17 |
| popey | diddledan: reckon we should push gimp rev 37 to stable? | 08:18 |
| ogra_ | mvo, edit cmdline.txt, drop the console=tty0 | 08:18 |
| mvo | ogra_: ta | 08:19 |
| mvo | ogra_: much better now :) | 08:20 |
| ogra_ | :) | 08:20 |
| pedronis | pstolowski: I did a first pass over 4510 | 08:35 |
| pstolowski | pedronis: thanks | 08:36 |
| mborzecki | re | 08:47 |
| mborzecki | 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 |
| Chipaca | pedronis: if you could give the comments on #4790 a once-over just to make sure, I'd appreciate that | 08:48 |
| mup | PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 08:48 |
| * Chipaca updates the description there | 08:48 | |
| pedronis | Chipaca: yes, one sec | 08:49 |
| mborzecki | i still don't get how it's possible to pull shit like this with all the parking assitance, sensors, cameras etc. | 08:49 |
| pstolowski | mborzecki: unbeliveable | 08:49 |
| Chipaca | mborzecki: what happened? | 08:55 |
| pedronis | 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 |
| mborzecki | Chipaca: a lady in a large white bmw knocked down a give way sign and hit my car, then she took off | 08:55 |
| pedronis | Chipaca: I see � | 08:56 |
| Chipaca | pedronis: yes | 08:56 |
| Chipaca | pedronis: I mean, I wrote a � | 08:56 |
| mborzecki | Chipaca: all in a parking lot of a go-to shopping plaza in lodz, so lots of industrial cameras etc | 08:56 |
| Chipaca | mborzecki: so they've got you covered? ie the plaza security people? | 08:57 |
| pedronis | Chipaca: is that special? | 08:57 |
| mborzecki | 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 | |
| Chipaca | pedronis: maybe I should write “� (U+FFFD)”? | 08:57 |
| Chipaca | mborzecki: :-/ were you stuck there alone? | 08:58 |
| pedronis | Chipaca: you remove the charatecter that usually means something else couldn't process things? | 08:58 |
| pedronis | just so I understand | 08:59 |
| Chipaca | pedronis: pretty much, yes | 08:59 |
| Chipaca | pedronis: the strings are supposed to be valid utf8, so it shouldn't happen | 08:59 |
| Chipaca | pedronis: and in fact they have to be, per json | 08:59 |
| Chipaca | pedronis: so the only reason U+FFFD appears is if somebody intentionally put it there | 08:59 |
| pedronis | Chipaca: ok, then yes a paranthesis (U+FFFD, aka replacement character) would be useful | 09:00 |
| Chipaca | and putting a character that means "something broke", intentionally, is not cool | 09:00 |
| mborzecki | Chipaca: nah, i was meeting with some mates before, so we stayed in the parking lot chatting and waiting for the police :) | 09:00 |
| Chipaca | mborzecki: "we waited, chatting and having a few beers" | 09:01 |
| Chipaca | :_D | 09:01 |
| pedronis | Chipaca: because otherwise somebody looking at that code will be confused about the replacement character showing up just as itself :) | 09:01 |
| pedronis | as I was, maybe | 09:01 |
| mborzecki | Chipaca: technically they had a few, i only had a soda and a tea :) | 09:01 |
| Chipaca | pedronis: … and that's why it's disallowed :-) | 09:01 |
| Chipaca | mborzecki: :-) | 09:02 |
| Chipaca | pedronis: there | 09:04 |
| niemeyer | Morning folks | 09:11 |
| pedronis | Chipaca: thx | 09:13 |
| Chipaca | pedronis: now to wait for it to green | 09:13 |
| pstolowski | pedronis: https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 ; let me know if I missed something | 09:15 |
| mup | PR snapd#4983 closed: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4983> | 09:15 |
| mborzecki | Chipaca: you make my heart break ^^ | 09:16 |
| Chipaca | mborzecki: ikr | 09:17 |
| mborzecki | Chipaca: runuser it is then? | 09:17 |
| Chipaca | mborzecki: runuser + dd + mv + sync, probably | 09:18 |
| Chipaca | for the write case | 09:18 |
| ogra_ | 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 |
| Chipaca | mborzecki: arch doesn't use a weird dd or sync does it? | 09:18 |
| Chipaca | mborzecki: i mean, all from coreutils? | 09:18 |
| mborzecki | Chipaca: woo, nice combo, iirc in case we ever need it runuser suppors switching selinux contexts too (or maybe some other tool?) | 09:19 |
| Chipaca | should I give up and just hand it off to /bin/sh | 09:19 |
| Chipaca | grmbl | 09:20 |
| mborzecki | Chipaca: nothing weird with dd or sync here | 09:20 |
| Chipaca | k | 09:20 |
| mvo | 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:21 |
| mborzecki | 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:23 |
| mvo | 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:24 |
| mvo | mborzecki: what is super annoying is that its really hard to recover once there is this corrupted file on disk | 09:25 |
| mborzecki | mvo: running fsck does not fix it right? | 09:28 |
| mvo | 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:28 |
| mvo | mborzecki: which is super annyoing nice that was got delete in my fixup script | 09:29 |
| zyga | mvo: will we use the repair assertion? | 09:30 |
| mvo | mborzecki: this is the only way that worked so farhttps://paste.ubuntu.com/p/ySvHbxRVH9/ - slightly terrible though | 09:30 |
| mvo | zyga: interessting idea | 09:30 |
| mvo | zyga: fixing this oob might not be a bad option | 09:30 |
| mvo | zyga: my goal was to fix in initramfs but its harder than I anticipated | 09:30 |
| zyga | what will we do about affected devices? | 09:31 |
| zyga | they are "bricked" right? | 09:31 |
| mborzecki | mvo: do you think there's a chance the file could have been there in the original image that was shipped with the devices? | 09:32 |
| === pstolowski is now known as pstolowski|bbiab | ||
| mvo | 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 |
| mup | PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove on auto_rename() <Created by mvo5> <https://github.com/dosfstools/dosfstools/pull/83> | 09:33 |
| mvo | mborzecki: we run fsck.vfat on mount for /boot | 09:34 |
| mvo | 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 |
| mvo | mborzecki: maybe I should write what I found in the forum to ensure everyone knows what is going on | 09:35 |
| mborzecki | mvo: fwiw uboot ENV_IS_IN_FAT is a questionable idea | 09:39 |
| mvo | mborzecki: what can we do to fix that? | 09:40 |
| pedronis | 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 |
| mborzecki | mvo: it'll be risky for devices that are already deployed | 09:40 |
| mvo | mborzecki: yeah :/ | 09:41 |
| mborzecki | 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:41 |
| mborzecki | mvo: and instead of parsing uboot's env manually, work with fw_printenv/fw_setenv instead | 09:42 |
| zyga | offtopic | 09:43 |
| zyga | have you guys seen "checks" | 09:43 |
| zyga | https://github.com/snapcore/snapd/pull/5144/checks for example | 09:43 |
| mup | PR #5144: tests: update bionic release image on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5144> | 09:43 |
| mvo | 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:45 |
| mborzecki | mvo: yeah, setting up fw_env.config is quite funny :) | 09:46 |
| mvo | 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 |
| mvo | (or grudgingly accept it) | 09:47 |
| mborzecki | mvo: experimentation is key :) | 09:49 |
| mborzecki | otoh, pull a power plug on rpi and there's a chance it's not coming back up | 09:50 |
| mvo | mborzecki: yeah | 09:51 |
| * Chipaca despairs and switches branches for a bit | 09:56 | |
| pstolowski|bbiab | pedronis: thanks | 10:02 |
| mup | PR snapd#5073 closed: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5073> | 10:06 |
| popey | om26er: https://github.com/snapcrafters/android-studio/issues/23 :) | 10:12 |
| niemeyer | mvo: +1 for following up in the forum | 10:16 |
| mup | PR snapd#4387 closed: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Blocked> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4387> | 10:31 |
| diddledan | popey: yeah, everyone who's tested gimp 37 has reported back positively. let's ship it | 10:36 |
| Chipaca | mvo: I feel you're missing a 'GOTO 4' in your sequence of events | 10:38 |
| mvo | Chipaca: good point, I added a 10 which is not quite GOTO but close | 10:40 |
| Chipaca | :-) | 10:42 |
| diddledan | popey: I've just done it | 10:45 |
| diddledan | popey: prepare for the hoards of complaints :-p | 10:45 |
| popey | WoooHooo! | 10:45 |
| popey | Thanks diddledan ! | 10:45 |
| ogra_ | 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:46 |
| ogra_ | mvo, i was wanting to write a prototype for this but customer work is eating my time | 10:47 |
| diddledan | 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 |
| ogra_ | mvo, we'd only need to maintain grub.cfg and porters can use u-boot as-is from their BSP | 10:48 |
| ogra_ | (no patching at all) | 10:49 |
| ogra_ | (along with that you get the full UEFI secureboot setup for free ) | 10:50 |
| mup | PR snapd#5145 opened: boot: clear "snap_mode" when needed <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5145> | 10:51 |
| mvo | Chipaca: someone with a fresh and sharp mind should look at 5145 | 10:51 |
| Chipaca | mvo: we should hire somebody like that | 10:51 |
| mvo | Chipaca: this should give us the first line of defense, i.e. no more bricking but also no more refreshes | 10:51 |
| mvo | Chipaca: lol | 10:52 |
| Chipaca | mvo: where does "trying" come into the picture | 10:53 |
| Chipaca | ? | 10:53 |
| ogra_ | 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:54 |
| mborzecki | ogra_: thanks, will take a look | 10:56 |
| mborzecki | ogra_: wow ..sabrelite, brings back bad memories | 10:56 |
| ogra_ | haha, yeah, i still have one running here with a 15.04 core install | 10:56 |
| ogra_ | (i still love the full SATA it has) | 10:57 |
| === pstolowski|bbiab is now known as pstolowski | ||
| mvo | 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:05 |
| pedronis | mvo: is the state sequence try -> trying -> "" ? | 11:07 |
| mvo | pedronis: correct | 11:08 |
| mvo | pedronis: I can write something in the forum if you want, seems like this should be documented better | 11:08 |
| zyga | mvo: should snapd remove all the uboot.env files and write a new one to "recover"? | 11:09 |
| mvo | pedronis: snapd sets to "try", bootloader from "try" to "trying" and snapd (after reboot) from trying to "" if things went well | 11:09 |
| zyga | (recover FAT) | 11:09 |
| Chipaca | mvo: would detecting the breakage and re-writing the boot partition be doable? | 11:09 |
| pedronis | mvo: yes, I see only a not very complete comment in partition/bootloader.go | 11:09 |
| mvo | Chipaca, zyga yes, remove and rewrite seems to work | 11:09 |
| zyga | mvo: as in while uboot.env exits, remove it // tricky | 11:10 |
| mvo | Chipaca, zyga not very atomic but give this is already a holly-crap situation maybe an acceptable workaround | 11:10 |
| mvo | pedronis: sure, will do | 11:10 |
| zyga | this is somewhat less nuclear than repartitioning /boot | 11:10 |
| * zyga -> coffee | 11:10 | |
| mvo | zyga: yeah, let me try something like that | 11:11 |
| pedronis | we also should consolidate this code at some point, is a bit spread around partiation snapstate etc | 11:11 |
| mvo | pedronis: good point | 11:11 |
| pedronis | anyway | 11:11 |
| pedronis | mvo: I think this also shows the issue that we need to detect reboot vs restart | 11:12 |
| pedronis | which is a TODO pending since a bit | 11:12 |
| mborzecki | pedronis: restart as in restart due to a failure? | 11:18 |
| pedronis | yes | 11:18 |
| pedronis | anyway I looked at the PR and it's probably less urgent than I thought | 11:19 |
| mvo | pedronis: at what PR did you look? | 11:19 |
| pedronis | your new PR | 11:19 |
| mvo | pedronis: less urgent? how so? | 11:20 |
| pedronis | mvo: your new code seems correct either way | 11:20 |
| mvo | pedronis: aha, yes | 11:20 |
| pedronis | mvo: aynway at some point you should review my #4497 | 11:21 |
| mup | PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497> | 11:21 |
| mvo | 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 |
| mvo | pedronis: yes, once the fires are out :) the next big fire for today is the snapd.seeded.service thing | 11:21 |
| niemeyer | mvo: Let me know if/when you want to discuss it | 11:24 |
| pedronis | niemeyer: I commented in the PR to your suggestion | 11:31 |
| niemeyer | pedronis: I've seen it, but not sure I'm reading your point completely | 11:32 |
| pedronis | 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:32 |
| niemeyer | pedronis: Right, that was the idea.. I think waiting for a state on the snap sounds generally useful | 11:33 |
| niemeyer | pedronis: snapd and otherwise | 11:34 |
| pedronis | 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 |
| mup | PR core-build#29 closed: ubuntu-core-rootfs: deal with leftover fsck files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core-build/pull/29> | 11:34 |
| pedronis | niemeyer: it will need to fit in in schemas as well when we get there | 11:34 |
| niemeyer | pedronis: Not sure there's much to add in terms of schema | 11:35 |
| pedronis | 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 |
| niemeyer | pedronis: Config is state.. can't see it otherwise | 11:35 |
| pedronis | I mean read-only from outside the snap | 11:36 |
| pedronis | or at least the snap should have that choice | 11:36 |
| niemeyer | 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 |
| niemeyer | pedronis: For seeded it makes sense too | 11:36 |
| pedronis | indeed, that would fit into schemas | 11:36 |
| mup | PR snapd#5146 opened: tests: fix user mounts test for external systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5146> | 11:36 |
| mborzecki | zyga: Chipaca: updated 5141 | 11:38 |
| pedronis | 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 |
| zyga | ack | 11:38 |
| niemeyer | pedronis: The question seemed fine.. I was just concerned about missing some deeper underlying point | 11:39 |
| mvo | niemeyer: probably after the standup, still working on mitigation on the vfat bug | 11:39 |
| hi | Hi every one | 11:40 |
| === hi is now known as Guest57528 | ||
| pstolowski | niemeyer: hey, i've documented https://forum.snapcraft.io/t/disconnect-hooks-howto-undo-connect-hooks/5339 , we should discuss the options | 11:40 |
| Guest57528 | i just want to know the command in snap.yaml file | 11:40 |
| zyga | mborzecki: +1 | 11:42 |
| mup | PR snapcraft#1064 closed: pluginhandler: collide with directories and symlinks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1064> | 11:43 |
| peter___ | HELP | 11:43 |
| peter___ | Any one tell me the command line process inside the snap.yaml file | 11:44 |
| diddledan | huh? | 11:45 |
| peter___ | (App: Command: )in snap.yaml | 11:45 |
| zyga | peter___: can you explain what you mean by that? | 11:45 |
| * cachio_ afk | 11:46 | |
| peter___ | I am not clear with (Command: Path to executable (relative to snap base) and arguments to use)? | 11:47 |
| zyga | peter___: it is the command you want to associate with a given application | 11:47 |
| zyga | peter___: any shell command you want to run | 11:47 |
| peter___ | I am new to snap. | 11:48 |
| === alan_g_ is now known as alan_g | ||
| pstolowski | mvo: do you need more eyes on #5095? it has +2 and could be merged | 11:49 |
| mup | PR #5095: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/5095> | 11:49 |
| pedronis | pstolowski: it says explicitly it's missing spread tests | 11:51 |
| pstolowski | pedronis: ah, right, should be marked blocked then | 11:52 |
| pedronis | yea, doing that | 11:52 |
| pstolowski | we did at the same moment ;) | 11:53 |
| pedronis | :) | 11:54 |
| pedronis | I see alot of branches failing spread tests today? | 11:54 |
| zyga | I see timeouts | 11:54 |
| pedronis | Chipaca: your safejson PR for example | 11:54 |
| jdstrand | niemeyer: hi! I responded in https://github.com/snapcore/snapd/pull/4387 | 11:55 |
| mup | PR #4387: interfaces/gpg-keys: force use of '--no-random-seed-file' via explicit deny <Blocked> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4387> | 11:55 |
| Chipaca | pedronis: yes, timeouts downloadin core from the store | 11:57 |
| Son_Goku | meeep | 11:57 |
| niemeyer | jdstrand: Responded | 11:59 |
| niemeyer | pstolowski: Thanks for the post! | 11:59 |
| newbee | my project developed in netbeans how to create snapcraft.ymal for this, please assist | 12:01 |
| * Chipaca ~> lunch | 12:04 | |
| pedronis | 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 |
| newbee | 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:11 |
| newbee | in this snapcraft.ymal file how to mention the hellowrold program | 12:12 |
| zyga | hmm | 12:15 |
| zyga | cat: write error: No space left on device | 12:15 |
| zyga | that's on opensuse | 12:16 |
| zyga | Chipaca: could slow / failed / retried downloads fill the disk of a VM? | 12:16 |
| zyga | newbee: hey, have you seen: https://snapdocs.labix.org/the-snap-format/698 ? | 12:16 |
| pedronis | 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:18 |
| newbee | zyga: thanks, we have go through the snapcraft.io documents in ubuntu core site, will try this too.. | 12:19 |
| pedronis | 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:20 |
| zyga | pedronis: ah, great point, I'll add that | 12:21 |
| newbee | pedronis: yes its creating .jar file, but in that we confused what are the commands should we use. | 12:22 |
| zyga | pedronis: done | 12:23 |
| pedronis | zyga: I think we just discovered that discourse has no conflicts checks | 12:25 |
| zyga | pedronis: indeed, my changes are gone | 12:25 |
| zyga | what did you do? | 12:25 |
| pedronis | zyga: I did an edit too, it seems your changes are not there | 12:25 |
| pedronis | I edited the last section about get-base-declaration | 12:25 |
| pedronis | sorry :/ | 12:26 |
| zyga | no worries | 12:26 |
| zyga | I'll add the edits back | 12:26 |
| * zyga holds the forum lock ;-) | 12:26 | |
| * zyga drops the forum lock | 12:28 | |
| newbee | pedronis / zyga : sorry for the intruption, do you got my question.. | 12:29 |
| zyga | newbee: whatever commands are appropriate to run a jar file | 12:29 |
| zyga | java -jar ... probably | 12:29 |
| * zyga needs to take the dog out | 12:29 | |
| zyga | ttyl | 12:29 |
| newbee | also want to know does the snap can be decompile ? | 12:31 |
| pedronis | newbee: it's not compiled, is just a compressed filesystem | 12:33 |
| pedronis | if you care about obfuscation you need to add it at the level of compiling/producing the jar | 12:34 |
| newbee | is there any other sites to refer to create snapcraft.ymal file...? | 12:36 |
| newbee | also please share example snapcraft.ymal file for java application ... | 12:36 |
| zyga | It should be all documented | 12:37 |
| zyga | Did you google for that? | 12:37 |
| pedronis | newbee: here's is an example for a jar: https://github.com/snapcore/snapcraft/blob/master/demos/gradle/snap/snapcraft.yaml | 12:38 |
| jdstrand | niemeyer: responded | 12:38 |
| newbee | pedronis: ok, will try with this.. | 12:39 |
| pedronis | newbee: what java plugin are you using? | 12:39 |
| sergiusens | 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:39 |
| pedronis | newbee: you can do snapcraft prime and look around in prime to see what gets built, where things are | 12:40 |
| newbee | @pedronis : we are using netbeans default plugin - ant | 12:42 |
| pedronis | ok | 12:42 |
| niemeyer | 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 |
| pedronis | newbee: this one example is using ant: https://github.com/snapcore/snapcraft/blob/master/demos/java-hello-world/snap/snapcraft.yaml | 12:43 |
| ogra_ | 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:45 |
| sergiusens | niemeyer: +1 on design tag | 12:46 |
| Chipaca | ogra_: maybe device should be a tag instead of a category? | 12:47 |
| newbee | @pedronis: Thanks, please clarify my understanding , in the command i have to mention the java path and the project path .. | 12:47 |
| ogra_ | Chipaca, dunno, would people still use it then ? the category is pretty visible which is helpful | 12:47 |
| ogra_ | 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 |
| niemeyer | ogra_: No, one per post only | 12:48 |
| ogra_ | niemeyer, ok, thanks | 12:48 |
| mvo | pstolowski: if pedronis is happy with 5095 then I would say we should merge it | 12:49 |
| mvo | pstolowski: aha, spread tests, nevermind | 12:50 |
| pedronis | mvo: I haven't checked it carefully but indeed spread tests | 12:50 |
| niemeyer | sergiusens: done | 12:52 |
| mup | PR snapd#5147 opened: snapd.core-fixup.sh: add workaround for corrupted uboot.env <Created by mvo5> <https://github.com/snapcore/snapd/pull/5147> | 12:53 |
| pedronis | 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 |
| pedronis | *things inside the snap or provided by the core snap | 12:54 |
| newbee | @pedronis- ok will try, thanks | 12:58 |
| niemeyer | Hey, just heating up some water.. will be with you in a moment | 13:00 |
| Chipaca | pstolowski: https://www.reddit.com/r/AskReddit/comments/7r1395/besides_bmw_which_car_has_the_douchiest_drivers/ | 13:08 |
| sergiusens | thanks for the tag! | 13:08 |
| pstolowski | Chipaca: ty :) | 13:08 |
| * diddledan twiddles his thingies until alsa-project.org comes back online | 13:22 | |
| um1b0zu | is snap core down? | 13:36 |
| pstolowski | 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 |
| um1b0zu | I've been trying to install a few packages and also just search the website | 13:36 |
| pstolowski | um1b0zu: store is having issues today, yes | 13:37 |
| um1b0zu | and I keep getting 500 and timeout errors | 13:37 |
| um1b0zu | ok. so it's not a me problem | 13:37 |
| um1b0zu | thanks! | 13:37 |
| Chipaca | um1b0zu: https://status.snapcraft.io | 13:37 |
| Chipaca | um1b0zu: down: very yes | 13:37 |
| Chipaca | um1b0zu: although it might be coming back :-) | 13:37 |
| pstolowski | and also https://forum.snapcraft.io/t/intermittent-outage-on-snap-downloads-and-uploads/5342 | 13:37 |
| um1b0zu | nbd I just figured I'd ask | 13:38 |
| * zyga is back home now | 13:50 | |
| Shmam | Will snap packages use the same gtk settings? | 14:08 |
| zyga | a storm is coming here | 14:20 |
| ogra_ | was that a trump reference ? | 14:21 |
| zyga | it's a hot day, who knows ;) | 14:22 |
| ogra_ | :D | 14:24 |
| cwayne | ogra: he said a storm, not a stormy | 14:27 |
| ogra_ | cwayne, didnt he qoute SNL ? | 14:28 |
| ogra_ | *quote | 14:28 |
| cwayne | ogra_: oh dunno, didn't see it yet | 14:28 |
| ogra_ | heh | 14:28 |
| ogra_ | dont want to spoil ya then :) | 14:28 |
| cwayne | lol | 14:29 |
| === rsalveti is now known as rsalveti__ | ||
| === rsalveti__ is now known as rsalveti | ||
| zyga | I think in US the weather is officially "shit storm" | 14:40 |
| zyga | here it's just rain | 14:40 |
| zyga | and warm air 😃 | 14:40 |
| popey | s/weather// | 14:51 |
| kjackal_ | 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:21 |
| zyga | kjackal_: hey, perhaps I can help you | 15:37 |
| zyga | what is the denial that you see? | 15:37 |
| kjackal_ | Hi zyga, it is a permission denied from a docker deamon trying to sent signal kill 15 to a container | 15:38 |
| zyga | kjackal_: can you please paste the denial | 15:38 |
| kjackal_ | let me see if i can spot it, give me a moment | 15:39 |
| zyga | kjackal_: dmesg | grep DENIED might help | 15:39 |
| kjackal_ | zyga: let me ping you in a few minutes. I need to redeploy, just a sec | 15:41 |
| zyga | sure | 15:42 |
| kjackal_ | zyga: are you still there? https://pastebin.ubuntu.com/p/d9pgT6sFXj/ | 15:56 |
| zyga | sure | 15:56 |
| kjackal_ | last couple of lines | 15:57 |
| kjackal_ | 4 lines | 15:57 |
| zyga | kjackal_: thanks, can you dmesg | grep DENIED | 15:57 |
| zyga | and pastebin that | 15:57 |
| zyga | 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 |
| zyga | but I want to make sure we're not missing something | 15:57 |
| zyga | what is interesting is that this is the profile for docker, not for the snap, that is in the way | 15:57 |
| kjackal_ | https://pastebin.ubuntu.com/p/6bhqbBjKVQ/ | 15:58 |
| kjackal_ | zyga: How does it get decided which profile to be used? | 15:58 |
| kjackal_ | is there some kind of pattern matching? | 15:59 |
| kjackal_ | If I rename the snapped docker daemon to something else would the right profile be used? | 15:59 |
| zyga | kjackal_: this profile (docker-default) comes from docker, not from snap world | 16:00 |
| zyga | it looks like a bug in docker | 16:00 |
| zyga | I'm not a docker person, just googled for this and found https://docs.docker.com/engine/security/apparmor/ | 16:00 |
| kjackal_ | For reference here is the snapcraft yaml https://github.com/juju-solutions/microk8s/blob/master/microk8s.yaml | 16:00 |
| zyga | again, this is not related to snaps | 16:01 |
| zyga | this is a profile generated by docker that doesn't allow container processes to be signalled | 16:01 |
| zyga | it probably allows them to be signal by unconfined peers | 16:01 |
| zyga | but not by confined peers | 16:01 |
| zyga | please report this to docker | 16:02 |
| kjackal_ | zyga: How does devmode work? Do snaps in devmode apply their own apparmor profiles? | 16:03 |
| zyga | devmode doesn't affect this | 16:03 |
| zyga | the profile is that of docker, not snaps, docker snap or anything | 16:04 |
| zyga | devmode works by using advisory confinement | 16:04 |
| zyga | but again | 16:04 |
| zyga | this is not related to devmode or snaps, look at the profile="..." string there | 16:04 |
| zyga | if this were a snap profile it would say profile="snap.something" | 16:04 |
| kjackal_ | This is why I am asking, on all other snapped daemons the snap.samthing profile was used but not in the case of the snapped docker. I read at the docs of docker I could provide my own apparmor profile. I was wondering if in devmode one such profile already exists | 16:06 |
| zyga | kjackal_: docker apparently generates its own profiles | 16:06 |
| zyga | and has permissions to break out of confinement | 16:06 |
| zyga | I don't know enough about docker to tell you more, I would suggest that you seek help with docker developers to ask about changing the automatically generated profile to allow it to send signals to confined processes | 16:07 |
| kjackal_ | zyga: question on snap created profiles. Where can I find the apparmor profiles applied in the case of devmode? | 16:09 |
| kjackal_ | Are there any files generated somewhere? | 16:09 |
| zyga | in the same place as other profiles, they are all in /var/lib/snapd/apparmor/profiles | 16:10 |
| kjackal_ | awesome thanks | 16:10 |
| kjackal_ | will try that zyga, thanks | 16:10 |
| zyga | good luck | 16:11 |
| vidal72[m] | are snap packages and components builded with same flags as normal deb packages in ubuntu? i.e. are security related flags enabled by default (pie,ssp,rerlo,bindnow, fortify)? | 16:31 |
| zyga | vidal72[m]: not necessarily | 16:33 |
| zyga | noise][: is the store running again? | 16:33 |
| noise][ | zyga: yes, we are just waiting for a bit more stability time before updating announcements | 16:34 |
| zyga | thanks! | 16:34 |
| vidal72[m] | zyga: why? | 16:34 |
| vidal72[m] | nowadays all major distro harden building packages, if snap doesn't then installing snap is a step back in this aspect | 16:36 |
| zyga | vidal72[m]: because snaps don't mandate how software is built | 16:36 |
| zyga | vidal72[m]: you can certainly harden your snap but there's no requirement that everyone does that or enforcement of that | 16:37 |
| vidal72[m] | zyga: opt-in security? | 16:37 |
| zyga | I don't know what you mean by that | 16:38 |
| vidal72[m] | zyga: if snap creator doesn't care about hardening build then it won't be hordened... | 16:39 |
| zyga | vidal72[m]: do you have a well defined definition of hardening and a reliable way to check? | 16:39 |
| zyga | vidal72[m]: don't get me wrong, it's nice to improve stuff but this is not an easy task | 16:40 |
| zyga | vidal72[m]: people find packaging hard as-is | 16:40 |
| zyga | vidal72[m]: and distributions don't agree on hardening concepts or use same defaults or toolchain versions and patcehs | 16:40 |
| zyga | *patches | 16:40 |
| vidal72[m] | zyga: things which I mentioned are enabled by default in fedora,debian,ubuntu,archlinux,gentoo and probably more... | 16:41 |
| zyga | vidal72[m]: can you be specific, which things | 16:42 |
| vidal72[m] | zyga: pie,ssp,rerlo,bindnow, fortify | 16:43 |
| vidal72[m] | see links included in https://github.com/flathub/flathub/issues/353 | 16:43 |
| zyga | and how do you verify that those are set? | 16:43 |
| zyga | vidal72[m]: what I'm trying to point out is that while an individual snap may be as hardened as you want, in general snaps don't come with source or build instructions and there's no way to require hardening | 16:44 |
| zyga | vidal72[m]: we can improve snapcraft and the defaults used there | 16:44 |
| zyga | vidal72[m]: and I would gladly support that | 16:44 |
| zyga | vidal72[m]: I was just trying to explain my point | 16:45 |
| vidal72[m] | zyga: there should be some way to pass some defaults to gcc during build | 16:46 |
| zyga | vidal72[m]: we can improve snapcraft and the defaults used there <- I know | 16:47 |
| vidal72[m] | flatpak | 16:47 |
| vidal72[m] | zyga: sounds good | 16:47 |
| vidal72[m] | zyga: flatpak is going to set in in runtimes (sdk) | 16:48 |
| zyga | vidal72[m]: and is Spotify flatpak hardened? no because it's not using that | 16:49 |
| vidal72[m] | zyga: https://github.com/flatpak/flatpak-builder/pull/142 | 16:49 |
| mup | PR flatpak/flatpak-builder#142: Load libdir and flags from SDK configuration file <Created by valentindavid> <Closed by alexlarsson> <https://github.com/flatpak/flatpak-builder/pull/142> | 16:49 |
| zyga | kalikiana,sergiusens: ^ what is the hardening story in snapcraft? | 16:50 |
| vidal72[m] | zyga: almost nothing (except runtimes) are hardened in flatpak yet. Spotify isn't builded from source so it isn't target for hardening. | 16:52 |
| sergiusens | vidal72[m]: zyga I am all for it, but I would defer to the security team on that. If CFLAGS and such are already exported it is already achievable | 16:56 |
| kyrofa | Yeah it wouldn't be hard, but it will obviously depend on the plugin being used | 16:58 |
| === pstolowski is now known as pstolowski|afk | ||
| tomwardill | zyga (and everyone): store is back and operating normally, FYI | 17:01 |
| zyga | thank you! | 17:01 |
| vidal72[m] | PIE and SSP can be enabled in gcc config. Probably they are enabled in ubuntu gcc package already. | 17:02 |
| popey | tomwardill: thanks! | 17:02 |
| mvo | pedronis, niemeyer I updated 5124 based on the feedback. it lacks some more unit tests but I would love to get a first look to ensure naming/approach is in line with what we discussed and I also need dinner :) | 17:14 |
| pedronis | mvo: I don't like seed.done for what is worth | 17:28 |
| mvo | pedronis: ok, just leave a comment for niemeyer I have no strong opinion about the particular name | 17:28 |
| * zyga prefers the original "seeded" | 17:28 | |
| kyrofa | sergiusens, this diff allows classic snaps to be built on trusty... but I'm not sure why we're doing that in the first place: https://pastebin.ubuntu.com/p/jmnJCtpP75/ | 17:28 |
| kyrofa | LD_LIBRARY_PATH seems odd for classic | 17:29 |
| kyrofa | Will this break other things? Or is that old? | 17:30 |
| pedronis | mvo: did you discuss it with him already? | 17:30 |
| kyrofa | Especially given that the host was already determined to be compatible with the core snap. Might as well just let it build against its own | 17:31 |
| pedronis | mvo: it sounds very unenglish as well, it would have to be seeding.done | 17:31 |
| pedronis | seed as name is not an action afaik | 17:32 |
| kyrofa | sergiusens, also, I'm fixing a conflict here but it could use another pass when you're able: https://github.com/snapcore/snapcraft/pull/2122 | 17:32 |
| mup | PR snapcraft#2122: many: introduce variables for part src and build <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122> | 17:32 |
| zyga | jdstrand: is that what you expected: https://github.com/snapcore/snapd/pull/5107/commits/bfdd7caca6dfb81df6fe7e218d3bd4d93dc08a87 | 17:40 |
| mup | PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5107> | 17:40 |
| mup | PR snapcraft#2127 closed: delta: properly search for in-snap xdelta3 <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2127> | 17:45 |
| sergiusens | kyrofa that is there to be able to find libraries from the base when doing the elf search | 17:52 |
| kyrofa | sergiusens, what happens if we don't do that? We build against the host, but then fix all the rpaths when priming to use the base | 17:57 |
| kyrofa | Is that bad? | 17:57 |
| jdstrand | zyga: that looks like a nice choice, yes | 17:58 |
| jdstrand | kjackal_ (cc zyga): so, the issue is that signal rules have two sides: the sender and the receiver. the sender needs to be able to send to the receiver and the receiver needs to be able to receive from the sender | 18:00 |
| zyga | jdstrand: ack, here the profile created by docker for the container doesn't allow this | 18:00 |
| jdstrand | kjackal_ (cc zyga): so while microk8s is allowed to send to the receiver because of devmode, the receiver (in this case the process running under the 'docker-default' apparmor profile) is not allowed to receive the signal from microk8s | 18:01 |
| jdstrand | kjackal_ (cc zyga): this is a variation of https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/2 | 18:03 |
| jdstrand | kjackal_: it seems like microk8s is trying to talk to docker install via a deb. is this accurate? | 18:04 |
| jdstrand | installed* | 18:04 |
| kjackal_ | jdstrand: yes, we deploy dockerd from docker.io | 18:05 |
| zyga | that last link is very interesting, thank you for sharing | 18:05 |
| kjackal_ | jdstrand: is there another option? | 18:05 |
| zyga | jdstrand: just as a quick check in #5090 is there a deeper issue or are you just after the comment changes? | 18:07 |
| mup | PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090> | 18:07 |
| jdstrand | kjackal_: honestly, I thought that microk8s would ship its own docker and plugs 'docker-support' | 18:07 |
| jdstrand | kjackal_: you *could* use a deb or other docker, but you would *not* be able to send signals directly to those processes, because those docker's don't know about microk8s and to add the signal receive rule | 18:09 |
| jdstrand | kjackal_: you *could* instead of sending signals directly use the docker socket to manage the containers though | 18:09 |
| jdstrand | kjackal_: even more honestly, I thought k8s used its own runc and didn't use dockerd, but I'm not up on the current implementation | 18:10 |
| jdstrand | zyga: yes-- all comments. based on your answer for returning the changes, I requested a comment there too | 18:12 |
| sergiusens | kyrofa: as we everything classic, we will need to try it out.... this is mostly for the ldd story (if memory serves correctly), so there might be side-effects | 18:13 |
| wililupy | I'm trying to use the layout feature in snapcraft but I am getting the following error: Issues while validating None: Additional properties are not allowed ('layout' was unexpected) | 18:13 |
| zyga | wililupy: I think that for now you must use passthrough for that | 18:13 |
| sergiusens | wililupy: use passthrough for that | 18:13 |
| wililupy | so instead of bind: $SNAP/usr use passthrough: $SNAP/usr? | 18:14 |
| zyga | wililupy: put all of the layout section under passthrough: | 18:14 |
| zyga | intent it one level deeper | 18:15 |
| wililupy | Ok. I'll try that. Thanks zyga and sergiusens | 18:15 |
| kyrofa | sergiusens, alright, I'll propose and create a snap of it. See if we can break it | 18:16 |
| mvo | 5147 also needs a careful review | 18:16 |
| zyga | mvo: question about 8. | 18:24 |
| zyga | do you remove both files and write one new one | 18:24 |
| zyga | mvo: or do you remove one at random (whatever kernel chooses) | 18:24 |
| zyga | mvo: and if the answer is the latter, how do you know you removed the right file for uboot? | 18:25 |
| zyga | mvo: ah, I see the diff now | 18:27 |
| zyga | this is interesting | 18:27 |
| zyga | and linux picks up the non-corrupt one | 18:27 |
| zyga | mvo: the grep is incorrect | 18:28 |
| zyga | mvo: it will trigger when boot.env.GARBAGE is there | 18:28 |
| zyga | or uboot.env.save | 18:28 |
| zyga | or whatever | 18:28 |
| wililupy | so I tried to install my snap and it says error: cannot install snap file: cannot use experimental 'layouts' feature, set option 'experimental.layouts' to true and try again so I use snap set experimental.layouts=true and get the following: error: the required argument `<conf value> (at least 1 argument)` was not provided. | 18:29 |
| wililupy | Is there any documentation on this? | 18:29 |
| zyga | wililupy: yes, please see | 18:29 |
| zyga | https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/63?u=zyga | 18:30 |
| zyga | in short: snap set core experimental.layouts=true | 18:30 |
| zyga | let me know of any issues you find | 18:30 |
| zyga | I know of three issues that have pending fixes but are not in edge yet | 18:30 |
| zyga | (though two will soon be) | 18:30 |
| wililupy | zyga: thank you! | 18:31 |
| zyga | better yet, please add your observations to that thread | 18:31 |
| niemeyer | pedronis: The "seed" name is the path towards options related to seeding.. much like we have "proxy", for instance | 18:34 |
| niemeyer | (not proxyign) | 18:34 |
| niemeyer | pedronis: We also have /var/lib/snapd/seed, for similar reasons | 18:34 |
| niemeyer | pedronis: The goal was having something that we might use when we need more seed-related options | 18:34 |
| zyga | niemeyer: have you seen https://github.com/snapcore/snapd/pull/5141/checks ? | 18:41 |
| mup | PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141> | 18:41 |
| zyga | (the PR number is not relevant) | 18:41 |
| niemeyer | zyga: Ohhh, nice! | 18:42 |
| zyga | it seems we can now pay for travis and get more slots | 18:43 |
| zyga | and it feels like we want to have snapcraft there :) | 18:47 |
| * cachio_ afk | 19:06 | |
| pedronis | niemeyer: I understand but /var/lib/snapd/seed is a "seed", and a proxy proxies, but a seed doesn't seed and cannot be done | 19:08 |
| niemeyer | Hmmm.. my messages didn't go through | 19:10 |
| niemeyer | Trying again.. | 19:10 |
| niemeyer | pedronis: The "seed" directory has plenty of content inside it too, so we could organize things there | 19:10 |
| niemeyer | pedronis: I was driving for something similar here | 19:10 |
| niemeyer | refresh, proxy, seed, ... would be top documents inside the system configuration | 19:10 |
| niemeyer | pedronis: The "seed" directory has plenty of content inside it too, so we could organize things there | 19:10 |
| niemeyer | pedronis: I was driving for something similar here | 19:10 |
| niemeyer | refresh, proxy, seed, ... would be top documents inside the system configuration | 19:10 |
| niemeyer | Heh, thanks IRC | 19:11 |
| niemeyer | pedronis: "done" is less important, though.. we could use something else there maybe? | 19:11 |
| zyga | pstolowski|afk: can you please merge master into your PRs after 4358 got merged | 19:12 |
| pedronis | niemeyer: the problem is the relationship of seed noun and seed verb, you seed a seed, seed is the object is seed the verb, while proxy can be the subject of proxy the verb, and refresh is action of refresh the verb | 19:12 |
| niemeyer | pedronis: Sure, but that doesn't sound like an issue.. we have proxy and refresh as top documents, and seed would be no different | 19:14 |
| niemeyer | It's clearly not an issue for the directory under snapd/ | 19:14 |
| zyga | jdstrand: not sure if you registered this, it has two +1s and I'm inclined to merge it https://github.com/snapcore/snapd/pull/5126 | 19:14 |
| mup | PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126> | 19:14 |
| pedronis | niemeyer: because that directoriy is a "seed" | 19:14 |
| niemeyer | pedronis: Yep.. the configuration too | 19:14 |
| niemeyer | pedronis: seed/*, seed.* | 19:15 |
| jdstrand | zyga: I did not see it. looking | 19:16 |
| pedronis | niemeyer: you would need to spell "seed.processed" not "seed.done" though | 19:16 |
| niemeyer | pedronis: That sounds fine to me.. any other good alternatives, just for brainstorm purposes? | 19:17 |
| * niemeyer synonyms | 19:17 | |
| zyga | seed.achieved? | 19:17 |
| pedronis | seed.installed | 19:17 |
| zyga | seed.completed | 19:17 |
| zyga | seed.up-to-date | 19:17 |
| pedronis | seed.seeded (but that's too repetitive) | 19:17 |
| zyga | (in case seed changes) | 19:18 |
| zyga | seed.ed (too geeky) | 19:18 |
| pedronis | zyga: the linguistic problem of those is that seed is not an action, is the object of an action | 19:18 |
| zyga | not sure, we call it "seeding" too | 19:19 |
| zyga | English is too flexible it seems | 19:19 |
| pedronis | zyga: the action indeed is seeding | 19:19 |
| niemeyer | primed | 19:19 |
| zyga | https://www.macmillandictionary.com/dictionary/british/seed_2 | 19:19 |
| zyga | "to put seeds in the ground so that they can grow" | 19:20 |
| pedronis | zyga: yes, but indeed seed is already a name, so you cannot take the verb and nominalize it | 19:20 |
| pedronis | the seed is primed, the seed is installed, the seed is processed sounds all okish | 19:21 |
| jdstrand | zyga: approved | 19:21 |
| niemeyer | loaded | 19:21 |
| zyga | jdstrand: thank you! | 19:22 |
| pedronis | niemeyer: loaded also works | 19:22 |
| zyga | seed.planted? :D | 19:22 |
| pedronis | the seed is achieved or the seed is completed sounds stranger | 19:22 |
| mup | PR snapd#5126 closed: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5126> | 19:22 |
| zyga | seed.sprouted | 19:23 |
| niemeyer | planted is not bad either | 19:23 |
| niemeyer | Follows the analogy | 19:23 |
| zyga | remember that small version of ubuntu on some dell machines? | 19:24 |
| zyga | what was t hat name | 19:24 |
| zyga | light? | 19:24 |
| niemeyer | placed, planted | 19:24 |
| pedronis | anyway atm our terminology follows both seed as of a plant and seed as of a crystal | 19:25 |
| niemeyer | pedronis: primed works well for the crystal | 19:25 |
| niemeyer | priming also has the connotation of making it ready which fits well in this case | 19:26 |
| zyga | I'm unfamiliar with that term, is is the act of growing a crystal from a single attachment point? | 19:26 |
| pedronis | zyga: seed for crystal? | 19:26 |
| pedronis | yes | 19:27 |
| zyga | yes | 19:27 |
| niemeyer | pedronis: Pick one.. :) primed, planted, loaded | 19:27 |
| pedronis | I'm ok with either loaded or primed | 19:27 |
| zyga | I'd go for planted as it is most simple for English non-natives | 19:27 |
| pedronis | planted is doubling down on the metaphor a bit too much for my taste | 19:27 |
| pedronis | also a planted seed is not fully grown yet | 19:27 |
| pedronis | zyga: it's a bit misleading metaphor wise tough | 19:28 |
| zyga | sprouted? | 19:29 |
| zyga | is this about the systemd service name? :D | 19:29 |
| * kyrofa breaks out the chemistry book to understand snapd's code | 19:29 | |
| pedronis | no, the flag | 19:29 |
| niemeyer | seed.primed sounds nice | 19:29 |
| zyga | what does it mean to prime a seed? | 19:29 |
| niemeyer | Let's go with that then.. | 19:29 |
| zyga | to start growing it? | 19:29 |
| niemeyer | zyga: Installs the snaps in the system and configure the whole system appropriately.. ;) | 19:30 |
| pedronis | nothing in particular | 19:30 |
| zyga | and does it relate to prime/ directory in snapcraft? | 19:30 |
| pedronis | but that's not too bad, as I said our metaphor is already ambiguous and breaks down if you look too close | 19:30 |
| niemeyer | zyga: Right, the motivation for the word is the same there | 19:30 |
| niemeyer | zyga: "snapcraft prime" makes the snap ready for packing | 19:31 |
| niemeyer | seed.primed means the seed was processed | 19:31 |
| zyga | as long as it is documented :) | 19:31 |
| zyga | I think it will raise eyebrows as it doesn't sound natural but if it is documented and consistent then +1 | 19:32 |
| niemeyer | This is also something pretty much nobody will look into, other than system hackers, so it's good enough I think | 19:32 |
| niemeyer | zyga: seeds are very natural :) | 19:32 |
| zyga | niemeyer: I mean the prime part | 19:32 |
| zyga | prior to this moment I didn't consider that a word I'd associated with seeding (prime) | 19:32 |
| niemeyer | zyga: 3. To prepare; to make ready; to instruct beforehand; to | 19:32 |
| niemeyer | post; to coach; as, to prime a witness; the boys are | 19:32 |
| niemeyer | primed for mischief. [Colloq.] --Thackeray. | 19:32 |
| niemeyer | [1913 Webster] | 19:32 |
| zyga | as I said, it's just my familiarity with the word | 19:34 |
| niemeyer | ack | 19:34 |
| mvo | once there is agreement I guess we also need to rename the systemd unit(?) | 19:34 |
| pedronis | niemeyer: mmh, to be fair prime works best with snapcraft because after prime there is pack | 19:37 |
| pedronis | niemeyer: prime seems to have more the sens of make ready for something else, but for seed is a bit open/unclear wht the something else after is | 19:37 |
| niemeyer | pedronis: seed.loaded is fine too | 19:38 |
| pedronis | I think it would be less unclear | 19:38 |
| niemeyer | Cool, let's go with that then | 19:38 |
| niemeyer | mvo: ^ | 19:38 |
| zyga | As a non-native speaker I only know the word "prime" from movies and games where it usually only refers to primed explosive | 19:38 |
| niemeyer | :P | 19:39 |
| niemeyer | mvo: Heya :) | 19:39 |
| mvo | niemeyer: sorry, it irc client crashed | 19:39 |
| niemeyer | Isn't that like 10pm for you guys? | 19:39 |
| pedronis | zyga: yea, it means prepare/make ready for detonation | 19:39 |
| mvo | niemeyer: it is :( | 19:39 |
| pedronis | in that context | 19:39 |
| mvo | niemeyer: seed.loaded it is then? | 19:40 |
| niemeyer | mvo: Yeah | 19:40 |
| mvo | niemeyer: also - snapd.seed-loaded.service for the unit? | 19:40 |
| bashfulrobot | Quick question all. I am not sure why I can;t find it in the docs. Is it possibel to remove all revisions from a channel? | 19:40 |
| bashfulrobot | Quick question all. I am not sure why I can't find it in the docs. Is it possible to remove all revisions from a channel? | 19:40 |
| niemeyer | mvo: snapd.seeded still sounds nicer I think | 19:40 |
| bashfulrobot | darn - edits duplicate. | 19:40 |
| mvo | niemeyer: so snapd.seeded and not snapd.seed-done ? happy with that | 19:40 |
| zyga | bashfulrobot: you can close a channel, yes | 19:40 |
| pedronis | bashfulrobot: snapcraft help close | 19:41 |
| zyga | niemeyer: curious observation, unrelated to seeding | 19:41 |
| niemeyer | mvo: Yeah, for the unit we don't have the same benefits of nesting as we do in the documentation | 19:41 |
| zyga | niemeyer: I'm just installing windows 10 on an old netbook | 19:41 |
| niemeyer | erm.. in the configuration I mean | 19:41 |
| bashfulrobot | pedronis: ah ok - didn;t realise closing the channel was the same thing | 19:41 |
| zyga | the latest version that's been released last week | 19:41 |
| zyga | it asks for every wifi connection if this is a metered connection | 19:41 |
| zyga | (offers to make it so) | 19:41 |
| mvo | niemeyer: great, I updated the PR comment - once the rest is reviewed I will push the fixes, I will see what i can do about the upload of .7, its getting late here, maybe tomorrow morning | 19:42 |
| bashfulrobot | thank you both zyga and pedronis | 19:42 |
| niemeyer | mvo: Yeah, definitely.. some rest is due | 19:43 |
| niemeyer | Oh, wait, and tomorrow is a holiday isn't it? /o\ | 19:43 |
| pedronis | mvo: systemd.special unit are a bit of a zoo, most are NAME.target/service with a few ADJECTIVE.target/service, but I don't see anything like foo-done there | 19:43 |
| mvo | fwiw, the image with the corrupted uboot.env rerfreshed itself out of misery after I (manually) run the core-fixup.sh and the double uboot.env was gone. so one revert but on the next auto-refresh it went to the right revision | 19:43 |
| mvo | pedronis: yeah, it was just a strawman, snapd.seeded.service is the current agreement with niemeyer which sounds fine to me | 19:44 |
| pedronis | and sorry for being annoying about names but given this is part of the packaging and an interface we will be stuck with them for a while | 19:45 |
| niemeyer | pedronis: Thanks for worrying, actually! | 19:45 |
| zyga | mvo: https://twitter.com/oheather1337/status/993993156793221120 | 19:45 |
| niemeyer | pedronis: The options we discussed are much better than the quick name I suggested | 19:45 |
| zyga | names are hard, we should go back to magic numbers | 19:48 |
| zyga | this can be feature 42 | 19:48 |
| zyga | (voice from the side) but I like the number 64 better | 19:48 |
| mup | PR snapd#5107 closed: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5107> | 19:51 |
| mup | PR snapd#5141 closed: tests: shellchecks, part 1 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5141> | 20:01 |
| mup | PR snapd#5144 closed: tests: update bionic release image on gce <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5144> | 20:01 |
| mup | PR snapd#5082 closed: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5082> | 20:16 |
| zyga | jdstrand: #5116 has 2 +1s and I'm inclined to merge when green | 20:19 |
| mup | PR #5116: interfaces: move host font update-ns AppArmor rules to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5116> | 20:19 |
| zyga | it is a simple refactor of how we share fonts | 20:19 |
| jdstrand | zyga: approved | 20:26 |
| zyga | thank you! | 20:26 |
| mup | PR snapd#4790 closed: jsonutil/safejson: introducing safejson.String & safejson.Paragraph <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4790> | 20:31 |
| zyga | jdstrand: having read the wiki page do you have any suggestions on the new debug command? | 20:33 |
| zyga | jdstrand: I renamed it to "sandbox-features" and added a way to use it for scripting (return true/false if a set of features is available) | 20:33 |
| zyga | otherwise I feel it is ready | 20:33 |
| jdstrand | zyga: not otoh. I like the name change to sandbox-features | 20:44 |
| zyga | thanks, I was wondering if I should add one for apparmor that's not from the kernel but I think for now it's fine | 20:44 |
| zyga | it will help me with experiments | 20:44 |
| jdstrand | we can always add stuff | 20:45 |
| mvo | zyga: I slightly tweaked the test for 5147 | 20:58 |
| zyga | Just now? | 20:58 |
| zyga | I just approved it | 20:58 |
| mvo | zyga: like 2min ago, please have another look, very much like before but tests a bit more | 20:58 |
| zyga | ok | 20:58 |
| mvo | zyga: not the actual recover unfortunately, I need to think how to do that, we could try to build a broken image somehow but not tonight | 20:59 |
| zyga | the test looks nice | 20:59 |
| zyga | note, there's a shorter way to test the size of a file, if it is zero | 21:00 |
| mvo | zyga: hm, test -s was what I had in mind but that is >0 iirc | 21:00 |
| zyga | ah, indeed, I though there's a "exits but empty" test as well | 21:00 |
| zyga | +1 :) | 21:00 |
| mvo | thanks zyga ! | 21:01 |
| mvo | pedronis, niemeyer thanks for your input on 5124! | 21:03 |
| zyga | jdstrand: I'll handle the rest of your feedback tomorrow, I need to sleep now | 21:04 |
| zyga | good night everyone | 21:04 |
| jdstrand | zyga: good night :) | 21:38 |
| bashfulrobot | Forthose that pop up in the AM... How long does the channel stable/ubuntu-18.10 Need to exist before closing to seed snaps on an ISO? Or do they need to exist for all ISO builds? And they exist until you are no longer building that ISO version? I seem to remember reading that it just had to be opened once with a revision, then could be closed immediately. I had set it up a while ago, and I am updating my personal docs... Plus since there | 22:51 |
| bashfulrobot | is no meantion of these details, I would likely also add to https://wiki.ubuntu.com/UbuntuSeededSnaps | 22:51 |
| bashfulrobot | TA | 22:51 |
| mup | PR snapcraft#2128 opened: project_loader: stop setting LD_LIBRARY_PATH <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2128> | 23:02 |
| mwhudson | is there any way to tell snapd about a proxy without restarting it? | 23:15 |
| mwhudson | oh _looks_ like it can be set with core config | 23:23 |
| mup | PR snapcraft#2116 closed: storeapi: handle 5xx error codes for all store endpoints <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2116> | 23:35 |
| mup | PR snapcraft#2122 closed: many: introduce variables for part src and build <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2122> | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
