| Caelum | zyga: if you have a lot of stuff to do, I can probably figure out how to rip out the suse go macros | 00:02 |
|---|---|---|
| === ubott2 is now known as ubottu | ||
| Doctor_Nick | is there a way to override $SNAP_USER_COMMON? snapd seems to not like my glusterfs mounted home directory | 03:15 |
| zyga | Good morning | 04:31 |
| zyga | Doctor_Nick: hey, can you please tell me more | 04:31 |
| zyga | Do you have any issues with snaps? | 04:31 |
| zyga | Network file systems may need a special tweak for confinement | 04:32 |
| zyga | Please share any issues you have and I’ll try to help | 04:33 |
| zyga | Caelum: I’m progressing and I should have alpha build soon (perhaps today) | 04:33 |
| Caelum | zyga: nice | 05:06 |
| zyga | School run | 05:09 |
| zyga | Hey mborzecki | 05:22 |
| mborzecki | morning | 05:22 |
| zyga | 6 am wake up time today | 05:22 |
| mborzecki | heh, 630 for me, preping kids to school took a bit longer than anticipated | 05:22 |
| zyga | I’m on the bus :P | 05:22 |
| zyga | Memories of commuting | 05:23 |
| mborzecki | oh, wow :) | 05:23 |
| zyga | (Horrors) | 05:23 |
| mborzecki | is the bus moving? :) | 05:23 |
| zyga | Yes | 05:23 |
| zyga | Barely | 05:23 |
| zyga | I’ll be operational soon | 05:23 |
| zyga | I sent some patches to my branch | 05:24 |
| zyga | Renamed Secure | 05:24 |
| mborzecki | there were some stats regarding traffic jams across the eu, polish cities were in the top tier, iirc lodz was even higher than warsaw :/ | 05:24 |
| mborzecki | go version go1.11 linux/amd64, finally updated | 05:25 |
| zyga | re | 05:43 |
| zyga | mborzecki: in Palamos the only traffic jam was in the alley next to the school when all the parents that drive to school were dropping their kids off | 05:44 |
| zyga | mborzecki: on 9:00 | 05:44 |
| zyga | mborzecki: work starts 9:15 | 05:44 |
| zyga | that's unfair, right? :) | 05:45 |
| === chihchun_afk is now known as chihchun | ||
| Doctor_Nick | zyga: that's exactly it | 05:58 |
| zyga | Doctor_Nick: hey :-) | 05:59 |
| zyga | Doctor_Nick: can you please share 'dmesg | grep DENIED\ | 05:59 |
| zyga | er | 05:59 |
| zyga | 'dmesg | grep DENIED' | 05:59 |
| Doctor_Nick | yeah | 05:59 |
| zyga | I suspect a small tweak will enroll another network filesystem to the extension we did for NFS | 05:59 |
| Doctor_Nick | hmmm | 06:00 |
| Doctor_Nick | it's not showing up | 06:01 |
| Doctor_Nick | cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system | 06:01 |
| Doctor_Nick | that's the error message that I'm getting | 06:01 |
| zyga | what is your $HOME set to? | 06:01 |
| Doctor_Nick | i created a link from ~/snap to /stuff/snap, which is on the local disk | 06:02 |
| Doctor_Nick | /users/nickz | 06:02 |
| zyga | Doctor_Nick: symlinks won't cut it | 06:02 |
| Doctor_Nick | i see | 06:02 |
| zyga | you must create a bind mount from whatever your home directory is to /home/$LOGNAME | 06:02 |
| zyga | and /home/$LOGNAME/snap must be a directory or a bind mount there | 06:02 |
| zyga | sorry, it's a bit complex and symlinks are not transparent to a certain layer | 06:03 |
| Doctor_Nick | yeah | 06:03 |
| zyga | I can show you how to do that if you need to | 06:03 |
| Doctor_Nick | zyga: yeah, i'd appreciate that | 06:05 |
| zyga | Doctor_Nick: we can do a quick test first | 06:08 |
| zyga | Doctor_Nick: then we can make that happen automatically by editing /etc/fstab | 06:08 |
| zyga | Doctor_Nick: you will need root access, do you have that? | 06:08 |
| Doctor_Nick | yup | 06:09 |
| Doctor_Nick | "starbuck:/gv0 /users glusterfs defaults,_netdev,noauto,x-systemd.automount 0 0 | 06:10 |
| zyga | Doctor_Nick: excellent, do you have /home/$LOGNAME on your machine? | 06:10 |
| Doctor_Nick | yeah, I can create it | 06:10 |
| zyga | Doctor_Nick: please do | 06:10 |
| Doctor_Nick | ok | 06:10 |
| zyga | Doctor_Nick: then try this: sudo mount --rbind /users/$LOGNAME /home/$LOGNAME | 06:10 |
| zyga | Doctor_Nick: what does HOME expand to? is it /users/$LOGNAME? | 06:11 |
| Doctor_Nick | yup | 06:11 |
| zyga | ok | 06:11 |
| zyga | I suspect you will need to switch that | 06:11 |
| zyga | but not sure actually | 06:11 |
| zyga | I'm curious why /users and not /home - are some users on this machine local and some remote? | 06:12 |
| Doctor_Nick | yes, that's it | 06:12 |
| zyga | once you do that bind mount, please export HOME to the new value in a shell | 06:12 |
| zyga | and try running a snap from command line | 06:12 |
| zyga | (any simple snap) | 06:12 |
| zyga | Doctor_Nick: thanks, I wish we could support this better out of the box | 06:12 |
| Doctor_Nick | huh | 06:13 |
| Doctor_Nick | it's still using the default home location | 06:13 |
| Doctor_Nick | cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system | 06:13 |
| zyga | Doctor_Nick: aha, it's probably reading your home directory location from /etc/fstab still | 06:14 |
| Doctor_Nick | ok | 06:14 |
| zyga | Doctor_Nick: can you change that for a quick experiment | 06:14 |
| zyga | and try again | 06:14 |
| zyga | (we can change it back if it fails) | 06:14 |
| Doctor_Nick | uhm | 06:15 |
| Doctor_Nick | if I unmount this thing, my system is going to hardlock | 06:15 |
| Doctor_Nick | i've done this before | 06:15 |
| Doctor_Nick | https://pastebin.com/ncju0t4L | 06:16 |
| Doctor_Nick | that's my whole fstab file | 06:16 |
| Doctor_Nick | the setup doesn't jsut mount my home folder, it mounts all the network users who are logged in to /users | 06:17 |
| zyga | right but we don't need to change that | 06:18 |
| Doctor_Nick | ok | 06:18 |
| zyga | I meant your /etc/passwd (or appropriate, whatever holds your user entry) | 06:19 |
| Doctor_Nick | ahhhhh | 06:19 |
| zyga | on your local system we'd change /etc/fstab to have an extra bind mount | 06:19 |
| zyga | from memory that would look like this: | 06:19 |
| zyga | /users/foo /home/foo none bind 0 0 | 06:19 |
| Doctor_Nick | hey, there it goes | 06:19 |
| Doctor_Nick | its working now | 06:20 |
| zyga | once the /users vs /home issue is out of the way | 06:20 |
| zyga | you may run into another issue | 06:20 |
| zyga | but for that one we have a workaround that was made for NFS | 06:20 |
| Doctor_Nick | ok | 06:20 |
| zyga | and I can extend that to glusterfs easily | 06:20 |
| Doctor_Nick | zyga: isn't there away to just override SNAP_USER_COMMON/SNAP_COMMON? | 06:23 |
| zyga | brb | 06:24 |
| zyga | re | 06:29 |
| zyga | Doctor_Nick: so it's not that easy | 06:29 |
| zyga | it's not about changing it really | 06:29 |
| zyga | for instance /home is re-mapped inside the application container | 06:29 |
| zyga | and /users doesn't even exist there | 06:29 |
| zyga | we have a per-user mount namespace where we might be eventually able to do per-user $HOME remapping | 06:29 |
| zyga | but that's not ready yet | 06:30 |
| zyga | the apparmor needs to really really understand where _all_ home directories are | 06:30 |
| Doctor_Nick | ah hah, ok | 06:30 |
| zyga | so even if we allow changing that easily it would not work out of the box | 06:30 |
| zyga | I think that really the only sane solution is doing the remapping internally in the per-snap, per-user mount namespace | 06:31 |
| zyga | and that's something I'm working towards enabling | 06:31 |
| zyga | then you can have any $HOME | 06:31 |
| Doctor_Nick | yeah, that's something we'd like | 06:31 |
| zyga | but at runtime for the snap it would show up as /home/$LOGNAME | 06:31 |
| zyga | and would really be your $HOME in practice | 06:31 |
| zyga | I'll make a note about this, it looks doable in a few weeks | 06:32 |
| zyga | I need to sort out prerequisites first | 06:32 |
| zyga | Doctor_Nick: try making the bind mount permanent by adding a line to /etc/fstab as I suggested | 06:32 |
| zyga | and reboot just in case to test that :) | 06:33 |
| Doctor_Nick | yeah, i'll give that a shot | 06:33 |
| mvo | zyga: good morning! how are the tests looking today? | 06:33 |
| zyga | thank you for sticking with snaps :) | 06:33 |
| zyga | good morning mvo | 06:33 |
| zyga | I pushed some things in the morning, let me look now | 06:33 |
| zyga | last night I saw failures to prepare opensuse | 06:34 |
| mvo | ok | 06:34 |
| zyga | some archive skew, it was complaining about package hash | 06:34 |
| Doctor_Nick | yeah, we're using them to deploy our server packages | 06:34 |
| zyga | that's great :) | 06:35 |
| zyga | are you using private snaps? | 06:35 |
| zyga | that you build yourself | 06:35 |
| zyga | or are those public snaps? | 06:35 |
| zyga | hey sil2100 | 06:36 |
| Doctor_Nick | private snaps | 06:36 |
| zyga | Doctor_Nick: that's awesome! thank you for sharing that | 06:36 |
| zyga | mvo: my PR is progressing, no failures so far | 06:36 |
| zyga | mvo: that's both prepare and execute failures | 06:36 |
| zyga | so fingers crossed :) | 06:36 |
| mvo | nice! | 06:37 |
| Doctor_Nick | we understand that snapcraft.io is going to implement private github support sometime in the future | 06:38 |
| zyga | Doctor_Nick: I think so but I'm not the best person to ask abou tthat | 06:39 |
| sil2100 | zyga: hey! | 06:40 |
| * sil2100 is back from the dead more-or-less | 06:40 | |
| zyga | sil2100: are you okay? | 06:40 |
| sil2100 | zyga: yeah, just fighting a flu this week, but I feel better today | 06:43 |
| zyga | sil2100: honey and tea | 06:43 |
| zyga | (and rum :) | 06:43 |
| zyga | ;-) | 06:43 |
| mborzecki | i'll be pushing a couple of fixes for go 1.11 in a minute | 06:50 |
| zyga | mborzecki: thank you | 06:51 |
| zyga | mborzecki: man, tumbleweed doesn't have go 1.11 yet | 06:52 |
| mborzecki | https://github.com/snapcore/snapd/pull/5766 | 06:52 |
| mborzecki | mvo: any chance of getting this to 2.35? | 06:52 |
| zyga | mborzecki: I'd say: just propose a 2.35 PR | 06:52 |
| mborzecki | wondering if we should run unit tests on arch, or just any other distro but with the latest go release | 06:55 |
| zyga | mvo: my PR is green now, so maybe we're back to good | 06:55 |
| zyga | mborzecki: +1 | 06:55 |
| zyga | I think | 06:55 |
| zyga | mborzecki: can we do a pass over my PR | 06:58 |
| zyga | mborzecki: I can take some parts and propose them and keep shrinking the main one | 06:58 |
| zyga | mborzecki: we could identify some things that could land this way | 06:58 |
| mborzecki | zyga: give me half an hour and we can do HO then | 06:58 |
| zyga | sure, thank you | 06:58 |
| mborzecki | damn, gocode stopped working with go1.11 | 07:00 |
| pstolowski | morning | 07:05 |
| zyga | good morning pawel | 07:11 |
| mvo | mborzecki: I'm looking at snap-failure right now, when it was triggered for your user, did that had any bad consequences | 07:28 |
| mvo | mborzecki: going over the code it seems we want this to be available in classic as well eventually, once we use the snapd snap there its a nice mechanism to recover from bad snapds which will also work on classic | 07:28 |
| zyga | mborzecki: Ill head home, I'll call you from there, it's too noisy here | 07:28 |
| mborzecki | zyga: ack | 07:30 |
| mborzecki | mvo: i'm not sure what systemd did there if OnFailure service failed too, meaning that snapd might have not been restarted at all, i can try it though | 07:32 |
| mvo | mborzecki: oh, interessting, let me look at this | 07:32 |
| mvo | mborzecki: it should handle this gracefully but it sounds like there is a bug | 07:32 |
| mborzecki | mvo: is it restarted? | 07:34 |
| mvo | mborzecki: still looking, need to ensure I got the right version :) | 07:34 |
| mborzecki | haha ack :) | 07:34 |
| mvo | mborzecki: yes it did restart, snapd restarted, snap-failure exited cleanly | 07:36 |
| mvo | mborzecki: would love to learn more if you saw something different | 07:37 |
| mborzecki | mvo: the problem the user had is that snap-failure was not shipped by the package, so snapd.failure.service exited with error | 07:37 |
| mvo | mborzecki: aha, got it | 07:37 |
| mvo | mborzecki: that makes sense | 07:37 |
| mborzecki | mvo: otoh, maybe then i should just ship snap-failure instead of dropping it, but there's no reexec on arch anyway, so chaces of snapd running from the snapd snap are rather low | 07:38 |
| mvo | mborzecki: yeah, it will only do anything if there is a snapd snap availalbe | 07:41 |
| * zyga waits for the bus to leave | 07:44 | |
| ogra | dbus ? | 07:44 |
| zyga | plbus :) | 07:45 |
| zyga | haha | 07:45 |
| ogra | :D | 07:45 |
| mborzecki | ztm :P | 07:45 |
| zyga | indeed | 07:50 |
| zyga | re | 08:18 |
| zyga | mborzecki: I'm available but no rush, working on some stuff | 08:25 |
| zyga | mborzecki: so when you feel like it just ping me | 08:25 |
| mborzecki | zyga: ok, just finishing a thing in snapstate | 08:26 |
| zyga | sure :) | 08:26 |
| mborzecki | almost there, left with 2 panics in api tests | 08:33 |
| mborzecki | btw. we set "seeded": true in the tests, but seed-time is not set | 08:33 |
| mvo | Chipaca: thank you for the review on the gcc thing and yeah the original version was bogus | 08:39 |
| Chipaca | mvo: i think it worked but was frowned on | 08:39 |
| mvo | Chipaca: yeah, it did actually, but go vet in 1.10 started complaining so it was not quite the right fix | 08:40 |
| dot-tobias | Hi everyone. Is there any way to put a symlink in my snap's readonly part (i.e. part directory) that points to the snaps /tmp directory? I guess $TMPDIR would point to the build system's tmp directory, and when I try to create a symlink in my install hook, it aborts with “read-only filesystem”. | 08:48 |
| pedronis | mborzecki: well, very little code cares about seed-time sof ar | 08:49 |
| mborzecki | pedronis: heh noticed that, i'll be opening a RFC with snapstate changes soon, will ping you and Chipaca :) | 08:50 |
| niemeyer | Morning all | 08:50 |
| pedronis | it was added recently to help with the hold logic | 08:50 |
| niemeyer | dot-tobias: That probably won't work.. you can try to make a symlink and pack it inside the snap itself, but I think the reviewing process will flag that as having symlinks pointing outside of the snap | 08:52 |
| niemeyer | dot-tobias: You can try it, though.. | 08:52 |
| pedronis | mborzecki: I'll will try to do reviews in the afternoon | 08:54 |
| dot-tobias | niemeyer Thanks, that's what I feared … My snap is not ready for review yet, but good to know that this would be an additional bump in the road. Root problem is that the framework I'm using for my snapped (web) app has a tmp directory hardcoded at app-root/tmp | 08:54 |
| mborzecki | pedronis: thanks | 08:57 |
| niemeyer | dot-tobias: Hmm | 08:59 |
| niemeyer | dot-tobias: There's a nice solution here: | 08:59 |
| niemeyer | dot-tobias: We have an experimental feature, which is soon leaving the experimental status behind, and allows you to control the mountpoints in more detail | 08:59 |
| niemeyer | dot-tobias: That means you could even have a tmpfs mounted on your read-only space | 08:59 |
| niemeyer | zyga: Do we have good docs for layouts already? | 09:01 |
| zyga | niemeyer: hey | 09:01 |
| niemeyer | dot-tobias: This is the discussion where you can find details of the syntax: | 09:01 |
| niemeyer | dot-tobias: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/45 | 09:01 |
| zyga | niemeyer: we only have the forum post for the layouts we had before; I didn't write anything more | 09:01 |
| dot-tobias | niemeyer that sounds interesting. Thanks :-) Will look into it | 09:01 |
| niemeyer | dot-tobias: The experimental feature is already working on your snapd.. you just need to enable it with "snap set system experimental.layouts=true | 09:02 |
| niemeyer | " | 09:02 |
| zyga | niemeyer: but that page has some extensive discussion and examples that seem like a good starting point | 09:02 |
| niemeyer | zyga: We need a doc page for that | 09:02 |
| zyga | actually | 09:02 |
| Chipaca | niemeyer: when're we dropping the experimental flag on it? | 09:02 |
| zyga | I think we may have one, hold on | 09:02 |
| niemeyer | Chipaca: I'm hoping very soon.. I haven't been hearing much about it lately, which is both good and bad | 09:03 |
| zyga | no, we don't have one | 09:03 |
| zyga | I'll start it now | 09:03 |
| dot-tobias | niemeyer: Does enabling experimental features have any impact on releasing my snap (e. g. only on beta/dev)? | 09:03 |
| niemeyer | dot-tobias: No.. you can release it.. it may get held back by review, but we can pass it if the feature is in a ready-enough state, which is definitely the case for layouts | 09:04 |
| niemeyer | dot-tobias: At installation time, the snap command will warn that this depends on an experimental feature, and won't proceed unless the system acks the support for the feature via the fla | 09:04 |
| niemeyer | flag | 09:04 |
| dot-tobias | niemeyer: Good to hear, thanks! Will try it out and give feedback here / in the forum thread. | 09:05 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | dot-tobias: That's great, thank you. That's exactly the kind of info we need to get this feature out of experimental | 09:05 |
| Chipaca | niemeyer: should we make it so experimental features are always enabled on edge? | 09:06 |
| zyga | Chipaca: oooh | 09:07 |
| zyga | that's neat :) | 09:07 |
| Chipaca | we could even get fancy and decide which ones get auto-enabled on beta/candidate/...stable | 09:07 |
| Chipaca | mborzecki: it took me five re-reads to find the typo you fixed in #5764 | 09:11 |
| Chipaca | keep me away from writing stuff today | 09:11 |
| Chipaca | or maybe from proofreading stuff | 09:11 |
| Chipaca | yeah, the latter | 09:11 |
| mborzecki | gccooo :) | 09:11 |
| === chihchun_afk is now known as chihchun | ||
| niemeyer | Chipaca: No, I think we should still ask the *environment* in which the snap is installed to acknowledge the fact they are using an experimental feature | 09:16 |
| niemeyer | Chipaca: Part of the point of the flag is to tell people "hey, you are using something that can disappear altogether tomorrow" | 09:17 |
| Chipaca | point | 09:17 |
| dot-tobias | niemeyer: Looks like I'm doing something wrong? snapcraft complains about the layout key in snapcraft.yaml – building with snapd 2.35 on ubuntu server 16.04.05 LTS, snap get system experimental returns experimental.layouts true. Using layout as a top-level construct as zyga documented in https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/2 | 09:18 |
| zyga | dot-tobias: hold on | 09:18 |
| zyga | I'm documeting this right now, I already covered that, | 09:18 |
| zyga | I'll share the page in a sec | 09:18 |
| niemeyer | dot-tobias: Not sure about what's the status of snapcraft in that regard.. it should already be accepting it, but apparnetly it isn't? You can get away with that by putting the layouts map inside a "passthrough" map in snapcraft.. that tells it to ignore the syntax and just pass it on to snapd | 09:19 |
| dot-tobias | zyga great, thanks! Brewing fresh coffee in the meantime :-) | 09:19 |
| zyga | *envy* :) | 09:19 |
| niemeyer | dot-tobias: The passthrough map is literally named "passthrough".. that's probably what zyga is about to document | 09:19 |
| zyga | yes :) | 09:20 |
| niemeyer | zyga: Thanks for that | 09:20 |
| zyga | dot-tobias: ok | 09:36 |
| zyga | back? | 09:36 |
| dot-tobias | zyga: Yes, back and trying out the layout feature with passthrough. Getting the same “cannot create writable mimic” error like https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/64?u=tobias | 09:37 |
| zyga | one sec | 09:37 |
| dot-tobias | But I'm probably doing something wrong 😊 | 09:37 |
| zyga | ok | 09:42 |
| zyga | ready | 09:42 |
| zyga | https://forum.snapcraft.io/t/snap-layouts/7207 | 09:42 |
| zyga | please read that, I'll read the error you got | 09:43 |
| zyga | dot-tobias: :) | 09:43 |
| zyga | niemeyer: ^ feedback welocme | 09:45 |
| zyga | *welcome | 09:45 |
| dot-tobias | zyga: Error was: “cannot update snap namespace: cannot create writable mimic over "/": permission denied / snap-update-ns failed with code 1” relevant snapcraft.yaml part: passthrough: | 09:45 |
| dot-tobias | layout: | 09:45 |
| dot-tobias | /mytmp: | 09:45 |
| dot-tobias | symlink: $SNAP_DATA/rails_tmp | 09:45 |
| zyga | dot-tobias: you cannot create a new top-level directory. I'll adjust the error so that it is clear | 09:46 |
| zyga | ogra, pstolowski: IIRC you made some snaps with layouts, can you have a look at https://forum.snapcraft.io/t/snap-layouts/7207 please? | 09:48 |
| Chipaca | niemeyer: I've replied to a few of your comments on #5514, if you could take a look you'd unblock me wholly | 09:50 |
| niemeyer | Chipaca: NIce, thanks.. will be on it in a few mintues | 09:51 |
| zyga | dot-tobias: I assume you don't really need a new directory called /mytmp and that you were just exploring | 09:51 |
| niemeyer | zyga: Thanks, will check | 09:51 |
| pstolowski | zyga: sure, gladly | 09:52 |
| dot-tobias | zyga: Yes, “exploring” or “fumbling around” 😄 I actually need a directory in my snap's app directory that's writable | 09:52 |
| zyga | dot-tobias: that should be doable :) | 09:52 |
| ogra | zyga, an example for the symlink case would be nice ... otherwise it looks good | 09:53 |
| zyga | ogra: +1 | 09:54 |
| zyga | dot-tobias: please let me know if something about layouts is unclear from the documentation or if you are trying to achieve something and it is unclear if layouts help or how they could be used | 09:57 |
| dot-tobias | zyga: First, thanks for the comprehensive writeup! Makes things much clearer. If I understand the “deeply nested paths” section correctly: If my app contains a folder “myfolder” and within that, I want to have a symlink named ”tmp” pointing to $SNAP_DATA/tmp … I would create a layout mapping “myfolder/tmp” with keyword `symlink` to $SNAP_DATA/tmp? | 09:58 |
| zyga | dot-tobias: that limitation only applies to read-only spaces | 09:58 |
| zyga | dot-tobias: inside $SNAP_DATA you can do anything | 09:58 |
| zyga | if you want a symlink $SNAP_DAT/tmp -> (whatever) you can just do that | 09:59 |
| zyga | but | 09:59 |
| zyga | layouts are not usually used to create things in $SNAP_DATA | 09:59 |
| zyga | (you can always do that in your application code or the configure hook) | 10:00 |
| zyga | can you give me a concrete exapmle please? | 10:00 |
| ogra | https://github.com/ogra1/xdmcp-client/blob/master/snap/snapcraft.yaml is an example for symlink | 10:00 |
| dot-tobias | zyga: It's the other way round: I need a symlink pointing from “tmp” in my app's root directory (which is read-only) to $SNAP_DATA/tmp, so that the app can write stuff at the expected path $app_root/tmp. | 10:01 |
| zyga | ah | 10:01 |
| zyga | that's ok | 10:01 |
| zyga | so layout like: | 10:01 |
| zyga | $SNAP/tmp: symlink $SNAP_DATA/tmp | 10:01 |
| zyga | $SNAP/tmp: symlink: $SNAP_DATA/tmp | 10:01 |
| zyga | note that this will _not_ create $SNAP_DATA/tmp | 10:01 |
| zyga | symlink targets are NOT created by laytous | 10:02 |
| zyga | *layouts | 10:02 |
| zyga | you can always use a bind mount for simplicitly | 10:02 |
| zyga | $SNAP/tmp: bind: $SNAP_DATA/tmp | 10:02 |
| dot-tobias | zyga: Ah, that's the missing part. So I would create $SNAP_DATA/tmp in my install hook? Will explore bind mounts right now | 10:02 |
| zyga | just try the bind layout | 10:02 |
| zyga | it's easier | 10:02 |
| zyga | you will not need a hook | 10:02 |
| mborzecki | zyga: ok, going through your PR now | 10:03 |
| zyga | mborzecki: cool, wanna HO? | 10:03 |
| mborzecki | zyga: let me go through it first | 10:03 |
| zyga | +1 | 10:03 |
| niemeyer | mup: you ok? | 10:08 |
| niemeyer | Apparently the channel is still flagging off messages from unauthenticated people | 10:08 |
| niemeyer | mup: now? | 10:09 |
| mup | niemeyer: I apologize. I'm a program with a limited vocabulary. | 10:09 |
| niemeyer | Yeah | 10:09 |
| zyga | haha | 10:10 |
| dot-tobias | zyga: Would the mount be visible when ls -la /snap/my-snap/current/? (it does not, but I'm unsure if that's because of a faulty yaml definition or the bind is only visible within the running snap) | 10:10 |
| zyga | I love those discussions with mup :) | 10:10 |
| zyga | dot-tobias: it's only visible from the running snap | 10:10 |
| zyga | dot-tobias: to see it without any confinement, run your snap (say "foo") and then | 10:10 |
| zyga | dot-tobias: sudo nsenter -m/run/snapd/ns/foo.mnt | 10:10 |
| zyga | dot-tobias: you can always run "snap run --shell foo" but this will be fully confined and you won't be able to explore as freely | 10:11 |
| dot-tobias | zyga: Ok, thanks. That clears things up for me, petty web-developer-turned-snapcrafter :-D | 10:12 |
| Chipaca | niemeyer: well, on signing in to freenode it still says “Due to the persistent ongoing spam, all new connections are being set +R (block messages from unidentified users) and will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified.” | 10:17 |
| niemeyer | Chipaca: I assume that's for private messages.. the channel has its own setting, which apparently isn't on for ours | 10:18 |
| niemeyer | Maybe they just forced it | 10:18 |
| Chipaca | ah | 10:18 |
| Chipaca | niemeyer: yep, +R is about private messages | 10:19 |
| Chipaca | https://freenode.net/kb/answer/usermodes | 10:19 |
| Chipaca | niemeyer: as opposed to channel mode +r | 10:19 |
| niemeyer | I'll need to improve mup to identify itself properly on reconnections | 10:19 |
| niemeyer | It's reasonable anyway | 10:20 |
| Chipaca | /msg chanserv info #snappy | 10:20 |
| Chipaca | ^ to see what modes #snappy has | 10:20 |
| mup | PR snapd#5771 opened: selftest: add test to ensure selftest.checks is up-to-date <Created by mvo5> <https://github.com/snapcore/snapd/pull/5771> | 10:21 |
| Chipaca | bah, chanserv seems busted | 10:21 |
| niemeyer | Yeah, seems off.. I'm assuming they just got tired of all spamming and forced it in code for every channel | 10:21 |
| Chipaca | k | 10:21 |
| niemeyer | zyga: Please ping degville about the doc as well.. he seems off right now | 10:22 |
| === jkridner|pd is now known as jkridner | ||
| zyga | niemeyer: ack | 10:32 |
| pstolowski | zyga: the doc for layouts looks fine; question on the "new entries in the / directory" limitation - is this problematic to handle, or simply not implemented yet? i can imagine this could be interesting for some weird/proprietary software | 10:32 |
| zyga | pstolowski: it's an architectual limitation, it's very hard to pull off and would require some action to happen before we pivot_root | 10:33 |
| zyga | pstolowski: we _could_ do it with a new filesystem eventually | 10:33 |
| zyga | but not now | 10:33 |
| zyga | pstolowski: we could also do it if we had snap-confine make / a tmpfs | 10:33 |
| zyga | and start with a bind mount farm based on the base snap | 10:34 |
| pstolowski | zyga: this doc reminded me i need to play with layouts in my problematic snap again | 10:34 |
| zyga | _that_ would not require a new filesystem | 10:34 |
| zyga | pstolowski: thanks, please share more feedback as you get it :) | 10:34 |
| zyga | pstolowski: and that is something new snap-confine could just do if we choose to implement it | 10:34 |
| zyga | pstolowski: but I haven't seen any demands for that yet | 10:34 |
| niemeyer | Chipaca: Commented on #5514.. I think you're fully unblocked now.. please ping otherwise | 10:38 |
| mup | PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514> | 10:38 |
| Chipaca | niemeyer: i replied to your first reply already :-D | 10:38 |
| pstolowski | zyga: ack, i see. indeed, i cannot think of any particular app needing it | 10:38 |
| niemeyer | Chipaca: I need to type faster... :P | 10:38 |
| Chipaca | niemeyer: the problem with having warnings accumulate args is that now we need to think about expiring the args somehow | 10:39 |
| Chipaca | niemeyer: unless I key on the format, and forget older args | 10:40 |
| Chipaca | that'd work | 10:40 |
| niemeyer | Chipaca: I actually had in mind keeping the exact logic you had | 10:40 |
| Chipaca | (if I keep older args, how are they presented to the user? etc) | 10:40 |
| Chipaca | niemeyer: so not worrying about dupes that much? | 10:40 |
| Chipaca | ok | 10:40 |
| niemeyer | Chipaca: It's just convenience so we don't need to Sprintf ourselves before cooking the message | 10:40 |
| niemeyer | Chipaca: In practice, just Sprintf as first thing, and keep the rest | 10:41 |
| niemeyer | Chipaca: (key is composed message) | 10:41 |
| Chipaca | ok | 10:41 |
| Chipaca | niemeyer: AddWarning -> Warn, and Warnf would be Sprintf version, ok? | 10:42 |
| mborzecki | zyga: btw https://github.com/snapcore/snapd/pull/5760/files#diff-6cdce42a784f927f710f0f5241a8c68dR84 such an opportunity lost :) | 10:42 |
| mup | PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places <Created by zyga> <https://github.com/snapcore/snapd/pull/5760> | 10:42 |
| niemeyer | Chipaca: We do want dupes when the message is indeed different.. e.g. two different broken snaps | 10:42 |
| niemeyer | Chipaca: I'd just have Warnf for now | 10:42 |
| zyga | mborzecki: ? | 10:42 |
| Chipaca | niemeyer: ok | 10:42 |
| niemeyer | Chipaca: Warnf("usual message") would work fine.. only danger is embedding %s on the message | 10:43 |
| * Chipaca nods | 10:43 | |
| Chipaca | the f should have us remembering | 10:43 |
| zyga | mborzecki: ass usual I was reasonable ;) | 10:43 |
| Chipaca | (problem with daemon error handlers was there was no f to remember that) | 10:43 |
| Chipaca | :-) | 10:43 |
| Chipaca | anyway, time for a quick break before a meeting | 10:44 |
| Chipaca | niemeyer: thanks! | 10:44 |
| niemeyer | Chipaca: np! | 10:44 |
| Chipaca | niemeyer: actually, given Warnf(format, args...), i could be extra cautious and only sprintf if len(args) > 0 | 10:45 |
| Chipaca | that'll dtrt errytime | 10:46 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#5772 opened: image: fix incorrect error when using local bases <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5772> | 10:48 |
| zyga | mvo: +1 | 10:53 |
| mvo | zyga: thank you | 10:54 |
| mvo | hrm, tests look unhappy | 10:55 |
| mvo | opensuse? | 10:55 |
| zyga | mvo: what are you seeing? | 11:00 |
| ogra | hmpf ... | 11:01 |
| ogra | apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gnome/ScreenSaver" interface="org.gnome.ScreenSaver" member="SimulateUserActivity" mask="send" name="org.gnome.ScreenSaver" pid=5523 label="snap.qemu-virgil.qemu-virgil" peer_pid=3387 peer_label="unconfined" | 11:01 |
| zyga | opensuse is pretty unhappy | 11:01 |
| zyga | but for other reasons | 11:01 |
| zyga | ogra: there's an interface that deals with screensavers, maybe a bug or extension? | 11:01 |
| zyga | I need to run to pick up my son from school | 11:02 |
| ogra | (screen-inhibit-control is connected ... yet i get this message every 10 sec) | 11:02 |
| zyga | ogra: ah, | 11:02 |
| ogra | i'll wait for jamie to get up | 11:03 |
| zyga | ogra: I can look as well but walking to the bus stop now | 11:03 |
| ogra | looking at the intreface code i think the "path=" line for "# gnome, kde and cinnamon screensaver" is missing bits | 11:05 |
| ogra | it has "path=/{,ScreenSaver}" while i think it should have "path=/{,org/freedesktop/,org/gnome/}ScreenSaver" like the API rule above | 11:06 |
| mup | PR core18#68 opened: Install rsyslog in core18 <Created by sil2100> <https://github.com/snapcore/core18/pull/68> | 11:11 |
| mborzecki | zyga: HO? | 11:20 |
| zyga | Za moment | 11:30 |
| === pstolowski is now known as pstolowski|lunch | ||
| mborzecki | off to pick up the kids | 11:53 |
| jdstrand | zyga: note that snapd could manage apparmor via the home.d mechanism. 'snap set config home=...' or something is totally doable. it's snap-confine that is the real blocker | 11:54 |
| jdstrand | snap set core home=.... whatever the syntax is ;) | 11:55 |
| zyga | jdstrand: I think we could do it magically automatically soon | 12:01 |
| ogra | jdstrand, did you see above ? seems i have issues with screensaver inhibit once again ... | 12:04 |
| === pstolowski|lunch is now known as pstolowski | ||
| mborzecki | re | 12:30 |
| mup | PR snapd#5773 opened: tests: avoid removing core snap on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5773> | 12:32 |
| zyga | re | 12:36 |
| zyga | back from school & lunch | 12:36 |
| zyga | checking your feedback mborzecki :) | 12:36 |
| dot-tobias | What's the best way to move all files of a part into a subdirectory (plugin: dump and source from git repo)? If I use organize: '*': subfolder/ like kyrofa did in https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L140 , I get an infinite recursion as snapcraft copies the part's root folder to the subdirectory again | 12:37 |
| dot-tobias | And feedback for zyga: After some trial and error, bind-ing write-enabled locations into my app works perfectly - huge thanks, will write up my experience with layouts in the thread later. | 12:39 |
| zyga | dot-tobias: I don't know, I'm not very familiar with how organise works actually | 12:39 |
| zyga | dot-tobias: woot, I'm glad I could help :) | 12:39 |
| zyga | dot-tobias: I'm working on a blocker that will allow us to soon move layouts out of beta | 12:40 |
| zyga | kyrofa: do you know the answer to dot-tobias' question? | 12:40 |
| zyga | kyrofa: about organise | 12:40 |
| ogra | i tend to use "plugin: nil" and an "override-build: |" with a simple "cp -av * SNAPCRAFT_PART_INSTALL" usually | 12:42 |
| dot-tobias | zyga: Glad to hear that layouts might soon be stable! Would bring fresh coffee to Spain, but maybe buymeacoffee or similar is faster 😄 Thanks a lot in any case. | 12:45 |
| zyga | dot-tobias: I'm no longer in Spain but I appreciate the gesture :) | 12:46 |
| zyga | (and I miss Spain:) | 12:46 |
| dot-tobias | ogra: Just tried that, gives the same error … RecursionError: maximum recursion depth exceeded 😞 Retrying after a full snapcraft clean right now | 12:47 |
| mup | PR snapd#5772 closed: image: fix incorrect error when using local bases <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5772> | 12:48 |
| dot-tobias | zyga: I should've looked up your Github profile | 12:48 |
| dot-tobias | zyga: …'s location instead of your Twitter profile 😊 Anyway, subbed to your blog. | 12:49 |
| zyga | oh, I should update both | 12:49 |
| zyga | thank you! | 12:49 |
| zyga | dot-tobias: btw, I'm at new.zygoon.plk | 12:49 |
| zyga | I need to redirect from the old blog | 12:49 |
| dot-tobias | check | 12:50 |
| dot-tobias | ogra: cleaning up and your plugin nil + cp -av + organize did the trick. Thanks! | 12:52 |
| mup | PR snapd#5769 closed: partition: remove unused runCommand <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5769> | 12:53 |
| ogra | :) | 12:54 |
| didrocks | hey popey! did you hear anything about the snapcraft docker image issue I mentioned on Monday? (I was hoping to see Sergio around, but seems he isn't) | 13:08 |
| didrocks | (CI on Yaru is still failing, and so, no theme update since Friday) | 13:08 |
| ogra | didrocks, there are a bunch of recent threads in the forum about snapcraft and docker builds | 13:10 |
| didrocks | ogra: oh? I searched for docker and no recent result on first page (but browser search) | 13:11 |
| didrocks | I guess I found it: https://forum.snapcraft.io/t/permission-denied-when-building-with-snapcore-snapcraft/7186 | 13:12 |
| didrocks | ok, switching to stable docker image | 13:13 |
| mup | PR snapd#5774 opened: tests: introduce a helper for installing local snaps with --name <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5774> | 13:16 |
| mborzecki | zyga: ^^ something you requested | 13:17 |
| zyga | mborzecki: thank you | 13:18 |
| didrocks | ogra: thanks a lot! Switching to stable works: https://github.com/ubuntu/yaru/pull/784 | 13:19 |
| mup | PR ubuntu/yaru#784: Use stable docker image <Created by didrocks> <https://github.com/ubuntu/yaru/pull/784> | 13:19 |
| ogra | :) | 13:26 |
| pstolowski | niemeyer: i mean https://github.com/snapcore/snapd/pull/5632 | 13:29 |
| mup | PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632> | 13:29 |
| onyb_fr7 | Hello. I am trying to create a snap for an electron app, that communicates with a Python server via HTTP (yes, I know it's weird). I therefore need my snap to have both Python and NodeJS runtimes. Does anyone know how to achieve this? This is where I am right now: http://paste.debian.net/plainh/46cb69b9 | 13:51 |
| jdstrand | ogra: jeez, everyone accesses the api slightly differently. this is the issue: interface="org.gnome.ScreenSaver" | 13:58 |
| jdstrand | we only allow interface=org.freedesktop.ScreenSaver | 13:59 |
| * jdstrand adds to list | 13:59 | |
| ogra | jdstrand, yeah ... thats what i guessed | 13:59 |
| ogra | i blame qemu :P its their call | 14:00 |
| Chipaca | mborzecki: it's weird because go-8 doesn't choke on https://pastebin.ubuntu.com/p/vsqqK6RDPn/ | 14:02 |
| mborzecki | Chipaca: using `info := &snap.Info{SideInfo: snap.SideInfo{RealName: "foo", Revision: snap.R(12)}}` works too | 14:17 |
| mborzecki | Chipaca: i have go1.10.3 gccgo (GCC) 8.2.1 20180831 linux/amd64 | 14:17 |
| Chipaca | mborzecki: yep | 14:18 |
| Chipaca | mborzecki: but 'go-8 test' in snap/ still fails | 14:18 |
| Chipaca | with that error | 14:18 |
| mup | PR snapd#5775 opened: tests: also run unit/gccgo in 18.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5775> | 14:18 |
| Chipaca | mvo: mborzecki: ^ :-) | 14:18 |
| mvo | Chipaca: neat | 14:19 |
| mvo | Chipaca: ideally we also run on 16.04 | 14:19 |
| mvo | Chipaca: because that is what powerpc uses | 14:19 |
| mborzecki | w8, it works there? | 14:19 |
| mborzecki | on 16.04 i mean | 14:19 |
| Chipaca | mvo: we were running on 16.04, but 16.04 amd64 is go-6 | 14:19 |
| Chipaca | mvo: go-8 is not available for amd64 16.04 | 14:19 |
| Chipaca | powerpc using go-8 in 16.04 is weird :-) | 14:20 |
| mvo | Chipaca: yeah, sorry, what I mean is we should run on both go-6 and go-8 | 14:20 |
| Chipaca | mvo: ah. There is no go-8 for 16.04 amd64 afaik | 14:20 |
| Chipaca | unless there's some weird and wonderful magic to get it :-) | 14:20 |
| Chipaca | mvo: if there is, super easy to fix this test to use both :-) | 14:22 |
| mborzecki | at least you can have go and gccgo, in arch gccgo conflicts with go, you need to choose one :) | 14:22 |
| Chipaca | mborzecki: mbuahaha | 14:23 |
| Chipaca | mborzecki: sorry, i need to go get some biscuits to eat with this schadenfreude | 14:23 |
| mborzecki | heh :) | 14:24 |
| * zyga gets a haircut | 14:33 | |
| Chipaca | Hmmm. https://pastebin.ubuntu.com/p/FMmsYMwYs3/ | 14:49 |
| Chipaca | running the unit tests with go-8 is illuminating | 14:51 |
| Chipaca | in the same sense that a bag over the head is | 14:51 |
| kyrofa | zyga, darn, that was quite a while before I was awake, dot-tobias seems to be gone | 15:10 |
| zyga | No worries | 15:13 |
| zyga | If you explain I will learn and relay next time | 15:13 |
| * cachio lunch | 15:18 | |
| kyrofa | I needed to see the yaml I'm afraid | 15:23 |
| zyga | kyrofa: sure, next time perhaps :) | 15:24 |
| ijohnson | zyga: whenever you get a chance could you take a look at https://forum.snapcraft.io/t/using-snapctl-in-install-hook-to-disable-services/7214 | 15:27 |
| zyga | ijohnson: sure | 15:27 |
| ijohnson | Thanks! The trick you told me about doesn't seem to work quite right :-/ | 15:27 |
| zyga | right, I read your post | 15:28 |
| zyga | pstolowski, Chipaca: I don't suppose you remember if we have a test where a install hook disables a service so that it doesn't auto-start on installation? | 15:28 |
| pstolowski | zyga: 99% sure we don't | 15:29 |
| mvo | Chipaca: haha on the pastebin | 15:36 |
| mup | PR snapd#5764 closed: snap: use snap.SideInfo in test to fix build with gccgo <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5764> | 16:03 |
| mvo | cachio: pr 5776 hopefully helps with the squid issues | 16:24 |
| mup | PR #5776: tests: port proxy test to use python tinyproxy <Created by mvo5> <https://github.com/snapcore/snapd/pull/5776> | 16:24 |
| mup | PR snapd#5776 opened: tests: port proxy test to use python tinyproxy <Created by mvo5> <https://github.com/snapcore/snapd/pull/5776> | 16:25 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio | mvo, great | 16:34 |
| cachio | mvo, thanks for that | 16:35 |
| mup | PR snapcraft#2231 closed: Release changelog for 2.43.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2231> | 16:57 |
| Saviq | jdstrand: hey, so we've hit a snag with the wayland interface on core... /run/user/0 doesn't exist by default... | 17:48 |
| jdstrand | Saviq: yeah, something outside of snapd would ideally create that (eg, systemd), but it doesn't. this is why the wayland interface has this: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/wayland.go#L60 | 17:56 |
| jdstrand | Saviq: ie, the slot side is allowed to create it | 17:56 |
| Saviq | ogra: ↑ | 17:57 |
| ogra | jdstrand, well, that doesnt work here | 17:58 |
| jdstrand | can you elaborate? | 17:58 |
| ogra | Sep 05 14:09:51 localhost.localdomain kernel: audit: type=1400 audit(1536156591.188:26): apparmor="DENIED" operation="mkdir" profile="snap.chromium-mir-kiosk.chromium" name="/run/user/0/" pid=2279 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 17:58 |
| jdstrand | that's the plugs side | 17:58 |
| jdstrand | this is in waylandPermanentSlotAppArmor | 17:59 |
| jdstrand | is chromium perhaps starting before wayland and trying to figure stuff out? | 17:59 |
| Saviq | yeah chromium should never try and mkdir that should it? | 18:00 |
| jdstrand | I mean, it shouldn't, that doesn't mean it doesn't | 18:00 |
| ogra | it should be using the xwaland launcher from https://github.com/MirServer/xwayland-kiosk-helper/blob/wayland-updates/xwayland-preload/xwayland-kiosk-launch | 18:00 |
| Saviq | yeah https://github.com/gerboland/xwayland-kiosk-helper/blob/wayland-updates/xwayland-preload/xwayland-kiosk-launch#L4 is wrong | 18:01 |
| jdstrand | xwayland can create it | 18:01 |
| Saviq | xwayland sits in with chromium | 18:01 |
| ogra | i tried to copy that for wmx-kiosk-session and get the same behaviour | 18:01 |
| Saviq | so it's only mir-kiosk that can | 18:01 |
| ogra | right, XWayland lives in the client snap | 18:01 |
| jdstrand | whatever 'slots: wayland' in the snap can do it | 18:02 |
| Saviq | yes, that | 18:02 |
| ogra | ok, then mir-kiosk must do it | 18:02 |
| Saviq | ogra: and the new version does | 18:03 |
| Saviq | https://github.com/MirServer/mir-kiosk/pull/9/files#diff-1250d6fc0bbea1fda5019f2d7fc66ce4L15 | 18:03 |
| mup | PR MirServer/mir-kiosk#9: Just use wayland interface, remove wayland-socket-dir content interface <Created by gerboland> <https://github.com/MirServer/mir-kiosk/pull/9> | 18:03 |
| Saviq | ogra: did you install mir-kiosk from edge/wayland-interface? | 18:03 |
| ogra | just from edge | 18:04 |
| Saviq | (I will remove mkdir from the wrapper, that's wrong) | 18:04 |
| Saviq | ogra: oh yeah, then that doesn't have that | 18:04 |
| Saviq | jdstrand: ok thanks, that explains things :) | 18:04 |
| ogra | i dont see a edge/wayland-interface in the channels/tracks list of snap info | 18:04 |
| jdstrand | yw | 18:04 |
| Saviq | ogra: branches are not displayed | 18:05 |
| ogra | bah | 18:05 |
| Saviq | that's why I mentioned the name explicitly | 18:05 |
| Saviq | → #mir-server | 18:05 |
| Saviq | hmm are LP snap builders not allowed to access npm? https://launchpadlibrarian.net/386955486/buildlog_snap_ubuntu_xenial_armhf_electron-mir-kiosk-snap_BUILDING.txt.gz | 18:08 |
| ogra | given they are also the backend for build.snapcraft.io builds they definitely should be able | 18:10 |
| ogra | though there might be special magic involved when they run via build.s.io ... cjwatson should know | 18:12 |
| ogra | the error is from npm itself though ... | 18:13 |
| ogra | Saviq, https://forum.snapcraft.io/t/build-fails-behind-proxy-on-build-snapcraft-io/6951 btw ... | 18:40 |
| Chipaca | mvo: that pastebin would be hilarious, if it weren't consistent | 18:56 |
| Chipaca | I mean, woo it's consistent I can debug it, but otoh WTF GCCGO YOU HAD ONE JOB | 18:57 |
| mvo | Chipaca: hehe | 18:57 |
| mvo | Chipaca: yeah | 18:57 |
| mvo | Chipaca: at least the snap/info.go should be fixed now :) | 18:57 |
| Chipaca | yep | 18:57 |
| mvo | hrm and opensuse is unhappy again | 18:58 |
| mvo | oh well | 18:58 |
| Chipaca | mvo: why weren't we running one spread per machine flavour? | 18:59 |
| Chipaca | was it that travis penalises that? | 18:59 |
| Chipaca | it'd be nice to just retry suse if suse failed, for ex | 18:59 |
| mvo | Chipaca: yeah, I think so. you get only a fixed number of slots iirc | 18:59 |
| Chipaca | right | 18:59 |
| mvo | +100 on that | 18:59 |
| sergiusens | Chipaca, mvo: you can "retry" a build by use of the travis API and making use of environment variables to drive this; we have that setup for the store team to be able to run our store tests only before each deployment | 19:05 |
| sergiusens | mvo, Chipaca: slots are 5, and we share them among the org, but it is not really documented | 19:10 |
| Saviq | ogra: thanks | 19:20 |
| luv | hi there ... im wondering sometimes I can see a package gets a security fix in ubuntu but a snap with that package as a dependency is apparently not rebuilt | 19:54 |
| luv | do you guys plan to fix this? | 19:54 |
| Chipaca | luv: packagers get an email when that happens, fwiw | 20:04 |
| Chipaca | luv: alerting them to the issue, so they can plan a rebuild | 20:04 |
| Chipaca | luv: whether a rebuild is needed or not depends; sometimes the issue affects a part of a library that a program doesn't use, for example | 20:05 |
| Chipaca | luv: and that is up to the packager to determine, mostly | 20:05 |
| luv | i see, for example, vlc is using vulnerable ffmpeg | 20:27 |
| luv | ok, seems it has been rebuilt two days ago :) | 20:28 |
| luv | i have found loads and loads effectively exploitable vulnerabilities in dependencies in flatpak, seems like snap taking care of the basic security much better | 20:30 |
| luv | oh and does fcitx work with snap? | 20:31 |
| luv | no, fcitx is not working (testing now in sublime text), that's really lame to be honest, making snap useless for some 2 billion people :) | 20:50 |
| popey | luv: yeah, currently ibus works, fctix doesn't | 20:51 |
| popey | https://forum.snapcraft.io/t/cant-use-input-method-in-snap-apps/4712/29 | 20:51 |
| luv | tho everyone uses fcitx for chinese | 20:52 |
| luv | and yes sublime text has the same vulnerability in deps as is in flatpak | 20:53 |
| luv | and the sandbox is useless | 20:53 |
| luv | and sublime is in the official snap store ... seems as bad as flatpak :(, but let me try the exploit first :) | 20:54 |
| popey | sublime isn't confined | 20:54 |
| luv | yup | 20:55 |
| luv | what about simple stuff like setting a bigger interface font? works only for gnome apps too (like in flatpak)? | 20:57 |
| ExoUNX | afternoon | 21:00 |
| luv | cool, looks like my exploit is not working in snap :) | 21:01 |
| popey | :) | 21:01 |
| ExoUNX | I'm trying to do nextcloud.enable-https custom | 21:01 |
| ExoUNX | and it's a huge pain | 21:01 |
| ExoUNX | it creates a live directory that links to letsencrypt/live | 21:02 |
| ExoUNX | which is fine, but it wont let specify example.com/cert.pem | 21:02 |
| ExoUNX | it just wants to do its own thing T_T | 21:02 |
| luv | how can i see the snap deps to verify it has been fixed? | 21:03 |
| luv | talking about this one https://www.cvedetails.com/cve/CVE-2017-14867/ btw - flatpak runtimes as used on flathub are still vulnerable; i see sublime-text in snap can't be attacked but git version in the snap is 2.11.0 ... i'd like to verify it's something like 2.11.0-ubuntu5 :) | 21:04 |
| popey | the sublime-text snap doesn't contain git | 21:06 |
| ExoUNX | on top of that, apparently the config files are located in /var/snap/nextcloud/current/apache and I see nothing | 21:08 |
| ExoUNX | except for logs | 21:08 |
| luv | oh | 21:09 |
| luv | popey: thanks ... so it comes from core or using git from my distro? | 21:10 |
| popey | likely your distro | 21:10 |
| luv | i guess it's the debian stable git ... that's why i get 2.11 and not vulnerable | 21:10 |
| luv | nice | 21:10 |
| luv | will play around more later | 21:11 |
| popey | have fun! | 21:11 |
| popey | I love hearing about this stuff | 21:11 |
| jdstrand | roadmr: hi! not urgent, but can you pull r1125 whenever convenient? | 21:13 |
| roadmr | jdstrand: sure thing | 21:15 |
| roadmr | ugh I'll probably need to wait for tomorrow to merge it, too close to EOD for me to do QA in time :/ | 21:15 |
| roadmr | but it'll be in the queue | 21:15 |
| jdstrand | roadmr: thanks, totally fine. enjoy your eod :) | 21:16 |
| popey | diddledan: your mycroft snap is stuck in review. Might want to ping a store person tomorrow to unblock | 22:20 |
| diddledan | yeah, I think it was an automated rebuild - I've not pushed anything, but it does look like it's pulled a newer mycroft, so I'll have to test it a bit before releasing widely | 22:21 |
| mup | PR snapd#5777 opened: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777> | 22:29 |
| mup | PR snapd#5773 closed: tests: avoid removing core snap on reset <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5773> | 23:01 |
| mup | PR snapcraft#2243 opened: [WIP] plugin API: support command-chain <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2243> | 23:03 |
| Doctor_Nick | what does snapcraft use the build state for? | 23:51 |
| Doctor_Nick | i see installed packages, installed-snaps, node-packages, etc. | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!