| mojibake | Can someone help me with a problem. On 16.04(Unity). I like to lock apps to the launcher. However I have noticed for snaps everytime a snap (such as firefox) updates, I lose it off the launcher and my muscle memory is disrupted. Any workarounds, or known issue? | 01:33 |
|---|---|---|
| === ahasenack is now known as Guest4879 | ||
| === kirkland is now known as Guest54596 | ||
| === tyhicks is now known as Guest8831 | ||
| mborzecki | morning | 05:13 |
| mup | PR snapd#5697 closed: overlord/snapstate: fix UpdateMany() to work with parallel instances <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5697> | 05:52 |
| mvo | zyga: you have (good) feedback on 5307 | 06:05 |
| mborzecki | mvo: hey, left a small suggestion in 5704 | 06:13 |
| mvo | mborzecki: ta, looking | 06:13 |
| mup | PR snapd#5708 closed: snapstate: use new "snap.ByType" sorting <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5708> | 06:13 |
| mborzecki | uh and obviously forgot to +1 : ) | 06:15 |
| mvo | mborzecki: ta, I like your suggestion a lot, pushed. lets hope tests are less unhappy than yesterday | 06:23 |
| mborzecki | mvo: yeah, i think it was better towards the evening | 06:23 |
| mup | PR snapd#5673 closed: ifstate: extra common code into checkAutoConflicts() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5673> | 06:39 |
| zyga | good morning :)\ | 06:54 |
| mborzecki | zyga: hey | 06:56 |
| zyga | jdstrand: thank you for the reviews! I know you are very busy so I'm extra grateful that you did so :) | 06:59 |
| * zyga has feedback on two updated PRs and jumps into iteration :) | 07:00 | |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:08 |
| mborzecki | pstolowski: hey | 07:17 |
| mborzecki | wow, didn't know that sigrok is packaged as snap | 07:39 |
| mvo | mborzecki: what is it? | 07:41 |
| mborzecki | mvo: it's for logic analyzers, dumping, viewing the traces and so on | 07:41 |
| mborzecki | mvo: sigrok can also do basic protocol analysis, eg i2c or spi | 07:42 |
| mborzecki | wonder if they ship the firmware for open source selae ripoffs too :) | 07:42 |
| mvo | nice | 07:44 |
| zyga | mborzecki: do you have any hardware like that? | 07:44 |
| zyga | I managed to boot my opensuse insallation | 07:45 |
| zyga | I don't know if it will work after reboot | 07:45 |
| mborzecki | zyga: yeah, the low end 8 channel selae ripoff is < $5 on aliexpress, got 2 of those | 07:45 |
| zyga | but it's closer than before | 07:45 |
| zyga | I'm rebalancing btrfs now, apparently, so I'll leave it be | 07:45 |
| mborzecki | on a side note, the 'new' selae analyzers can do analog signals too and iirc those were not supproted by sigrok at all | 07:46 |
| zyga | mborzecki: nice | 07:46 |
| zyga | mborzecki: I used to have an Agilent scope but I sold it as I didn't have time to really use it the way I wanetd | 07:46 |
| zyga | *watned | 07:46 |
| zyga | *wanted | 07:46 |
| mborzecki | we also had some lecroy analyzers, but those had windows only software, because 'professioanl', the pricing was also 'professional' level, sigh | 07:47 |
| mvo | zyga: I added a comment to 5621 - please have a look, I think the whole attempt to support this strange apparmor lxd setup is fruitless, I will go with a selftest instead | 07:54 |
| mvo | zyga: a selftest that will simply error | 07:55 |
| zyga | Ack, looking | 07:56 |
| zyga | hmmm | 08:00 |
| zyga | yeah, it looks like Alice is still falling | 08:00 |
| mvo | zyga: I ran out of ideas | 08:01 |
| mvo | zyga: which is sad, I had hoped to make it work | 08:01 |
| mvo | zyga: but if we can't run snap-update-ns because of outside strange interferences not much left we can do, can we? | 08:01 |
| zyga | yeah, I'm surprised how that happens | 08:02 |
| zyga | I need to read the fine details | 08:02 |
| zyga | but I think that doesn't change the outcome | 08:02 |
| zyga | it's all hopeless at that point | 08:02 |
| mvo | zyga: *despair* | 08:02 |
| zyga | hey, despair is when the sky falls down | 08:02 |
| zyga | this is just something we made :) | 08:02 |
| mvo | zyga: well, at least we will now give a clear error message (well, not now but *soon*) | 08:02 |
| zyga | yeah | 08:02 |
| zyga | +1 for a self-test | 08:03 |
| zyga | if we can make a reliable one | 08:03 |
| mvo | zyga: I think we can | 08:03 |
| mvo | zyga: I mean, we can just use the same detection we would have used otherwise | 08:03 |
| niemeyer | Good morning! | 08:16 |
| mup | PR snapd#5715 opened: selftest: detect if apparmor is unusable and error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5715> | 08:17 |
| mup | PR snapd#5621 closed: release: detect when apparmor is available but not usable <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5621> | 08:18 |
| mvo | hey niemeyer ! good morning | 08:30 |
| mvo | zyga: I also added a forum post about this, feel free to add details, I wonder if I should link to it from the error message in the selftest | 08:31 |
| zyga | yeah, anything that helps people google it | 08:31 |
| mvo | zyga: +1 | 08:31 |
| mvo | zyga: I was actually thinking that the selftests should provide data to snap (the command) as well, let me try to sketch something out | 08:32 |
| zyga | hmm | 08:32 |
| zyga | so snap version | 08:32 |
| zyga | can say "but not functional"\ | 08:32 |
| zyga | ? | 08:32 |
| zyga | but selftest makes the daemon stop | 08:32 |
| mvo | zyga: something like "snap install foo" would return "snap cannot talk to snapd because: selftest-message" | 08:32 |
| zyga | aha | 08:33 |
| mvo | zyga: yeah, it needs to life in e.g. /run/snapd/selftest-fail or something | 08:33 |
| zyga | we could drop a file in /run/snapd/selftest | 08:33 |
| zyga | haha | 08:33 |
| zyga | nice ;D | 08:33 |
| zyga | we thought about the same idea :) | 08:33 |
| mvo | zyga: *or* we could go into degrated mode in the daemon but that seems overkill | 08:33 |
| * mvo hugs zyga | 08:33 | |
| zyga | yeah, I agree, I think the file is sufficient | 08:33 |
| mvo | zyga: I wonder if thats a good or a bad sign ;) I mean group-think and allthat | 08:33 |
| zyga | and we need to unlink that file if snapd starts :) | 08:33 |
| mvo | zyga: thanks, I add a quick PR | 08:33 |
| zyga | :) | 08:33 |
| zyga | I think it's good because it is simple | 08:34 |
| mvo | zyga: yeah - we could also only look for it if we can't talk to the daemon but unlink is even easier | 08:34 |
| zyga | oh, good idea | 08:34 |
| zyga | yeah | 08:34 |
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 08:49 |
| mup | PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 08:49 |
| mup | PR core#93 closed: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93> | 08:49 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 08:50 |
| mup | PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 08:50 |
| mup | PR core#93 opened: hooks: unwind /etc/alternatives <Created by mvo5> <https://github.com/snapcore/core/pull/93> | 08:50 |
| mup | PR snapd#5716 opened: tests: spread test for parallel-installs desktop file handling <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5716> | 09:04 |
| mborzecki | there's a forum topic about docker from snap and LD_LIBRARY_PATH and it looks a bit weird, https://forum.snapcraft.io/t/ld-library-path-in-snapped-docker/6903/4 the problem seems to appear on ubuntu only, arch, opensuse, debian are fine | 09:11 |
| mup | PR snapd#5700 closed: tests: significantly reduce execution time for managers test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5700> | 09:20 |
| mup | PR snapd#5717 opened: snapd: go into degraded mode when the selftest fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/5717> | 09:39 |
| zyga | mvo: reviewed | 09:47 |
| zyga | mborzecki: hmm | 09:50 |
| zyga | mborzecki: LD_LIBRARY_PATH is managed by apparmor | 09:50 |
| mvo | zyga: thanks, thats good stuff | 09:50 |
| zyga | mborzecki: it's one of the special flags managed by AT_SECURE | 09:50 |
| mup | PR snapd#5718 opened: overlord/ifacestate: remove "old-conn" from connect/undo connect handlers <Created by stolowski> <https://github.com/snapcore/snapd/pull/5718> | 09:50 |
| mvo | zyga: fwiw, I tried the /run/snapd/selftest.err first but it was more convoluted | 09:50 |
| zyga | mborzecki: in essence, it doesn't traverse setuid-rooot binaries | 09:51 |
| zyga | mvo: this is nice :) | 09:51 |
| niemeyer | pstolowski: #5618 reviewed | 10:00 |
| mup | PR #5618: overlord: instantiate UDevMonitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5618> | 10:00 |
| mborzecki | zyga: thanks for leaving a note under the topic ;) | 10:02 |
| pstolowski | niemeyer: great, thank you! | 10:03 |
| mborzecki | #5716 is an easy win if anyone's interested | 10:04 |
| mup | PR #5716: tests: spread test for parallel-installs desktop file handling <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5716> | 10:04 |
| niemeyer | I'm 100 PRs behind that still, in #5623 now :) | 10:05 |
| mup | PR #5623: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/5623> | 10:05 |
| mborzecki | zyga: pushed an update to #5713 | 10:06 |
| mup | PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5713> | 10:06 |
| zyga | mborzecki: added small review | 10:12 |
| mborzecki | zyga: aa haha ok | 10:15 |
| mup | PR snapd#5719 opened: strutil: add new ParseValueWithUnit <Created by mvo5> <https://github.com/snapcore/snapd/pull/5719> | 10:46 |
| === Guest4879 is now known as ahasenack | ||
| mborzecki | zyga: on arch with linux-hardened kernel and apparmor userland bits: https://paste.ubuntu.com/p/FQ9TyxXkjB/ | 10:57 |
| zyga | mborzecki: nice | 10:57 |
| zyga | mborzecki: but not fully enabled (since we only do the fully enabled apparmor-in-snapd in tumblweed) | 10:57 |
| mborzecki | zyga: yup, will need to tweak that a little | 10:58 |
| mborzecki | [ 336.086774] audit: type=1327 audit(1535108348.381:97): proctitle=61707061726D6F725F706172736572002D2D7265706C616365002D2D77726974652D6361636865002D4F006E6F2D657870722D73696D706C696679002D2D63616368652D6C6F633D2F7661722F63616368652F61707061726D6F72002D2D736B69702D726561642D6361636865002F7661722F6C69622F736E6170642F617070 | 11:00 |
| mborzecki | wow, not very useful | 11:00 |
| niemeyer | pstolowski: Enumeration reviewed as well | 11:03 |
| * niemeyer => lunch | 11:03 | |
| pstolowski | niemeyer: ty! | 11:04 |
| zyga | mborzecki: yeah, processes put garbage there | 11:05 |
| zyga | that's seccomp though | 11:05 |
| zyga | do you have more ? | 11:05 |
| mborzecki | zyga: the profiles appear to be loaded https://paste.ubuntu.com/p/3VGgW5bwRQ/ | 11:07 |
| zyga | mborzecki: no, I mean, the error is from seccomp | 11:07 |
| zyga | not from apparmor | 11:07 |
| mborzecki | zyga: ther was just some STATUS following that | 11:08 |
| zyga | can you paste more please? | 11:08 |
| mvo | pedronis: did I read your comment in 5606 right that you prefer a download options parameter instead of using the context? I can kill the context entirely when using the download options, it will just be a bit noisy because of the test updates | 11:13 |
| mborzecki | zyga: https://paste.ubuntu.com/p/cK3FG7WJP4/ | 11:13 |
| zyga | mborzecki: this is interesting: [ 928.212558] audit: type=1300 audit(1535108940.553:100): arch=c000003e syscall=1 success=yes exit=2953 a0=6 a1=f980dd043a0 a2=b89 a3=0 items=0 ppid=3853 pid=3854 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="apparmor_parser" exe="/usr/bin/apparmor_parser" subj==unconfined key=(null) | 11:14 |
| zyga | that's seccomp telling us that write is okay? | 11:14 |
| jdstrand | zyga: seccomp is type=1326 (unless that recently changed?) I wonder if auditd is installed with rules to log writes to all files | 11:16 |
| zyga | ahh | 11:16 |
| zyga | thank you! so it's not seccomp at all | 11:17 |
| zyga | I was confused by arch and syscall numbers | 11:17 |
| zyga | I was confused by arch and syscall numbers | 11:17 |
| jdstrand | mvo: fyi, I approved 5715 (thanks!). that is indeed a weird configuration and am happy with the new approach | 11:17 |
| jdstrand | mvo: did you see my question yesterday about the -18 gadgets? do you want me to adjust the review tools for those? | 11:18 |
| zyga | niemeyer: I'm using the spread snap and while google works now I was wondering if you could special case running from a snap and use $SNAP_COMMON to look for qemu images. I don't know if there are other dependencies (interfaces) for this at this time (probably) | 11:20 |
| mvo | jdstrand: I did see it and I thought I had replied. apparently not :) sorry for that, please wait a little bit with the update of the review tools, we will discuss this today (or Monday). I think we want bases for gadgets in the new world but we could also simply always assume gadgets use the model.base. so its a bit of a policy decision if we want implicit or explicit bases for gadgets | 11:22 |
| pstolowski | oh my, travis is like rolling a dice nowadays | 11:23 |
| === pstolowski is now known as pstolowski|lunch | ||
| mvo | pstolowski|lunch: yeah, its rather annoying | 11:24 |
| * mvo lunch | 11:24 | |
| mborzecki | zyga: jdstrand: https://paste.ubuntu.com/p/WWb3rXGskG/ well, hello-world.evil does not seem to be getting policed by apparmor, the profile is http://paste.ubuntu.com/p/8czF54H45C/ | 11:36 |
| zyga | mborzecki: because we don't enable apparmor | 11:36 |
| mborzecki | aah damn | 11:36 |
| mborzecki | right | 11:36 |
| zyga | mborzecki: you need to patch apaparmor/backend.go | 11:36 |
| mborzecki | zyga: that's the first pase | 11:36 |
| mborzecki | zyga: but i still need to rebuild s-c | 11:36 |
| zyga | no, I think you are OK | 11:36 |
| zyga | s-c no longer plays any role | 11:36 |
| zyga | unless you built it without apparmor entirely ;) | 11:37 |
| mborzecki | zyga: yeah, i did :P it's a default install, i'm replacing the binaries i need | 11:37 |
| jdstrand | mborzecki: what is the output of 'sudo aa-status'? | 11:40 |
| mborzecki | jdstrand: http://paste.ubuntu.com/p/2f42M3D5Zv/ | 11:40 |
| jdstrand | mborzecki: can you run 'snap run --shell hello-world_foo.evil' in one terminal, then while that shell is open, run aa-status and see if a process is add to the profile (ie, look at the bottom of the output)? | 11:42 |
| jdstrand | mborzecki: or do it with the non-_foo one | 11:44 |
| mborzecki | jdstrand: zyga: wohoo, had to install s-c profile and load it, hello-world.evil is not getting blocked https://paste.ubuntu.com/p/Hn8tCkcxQs/ | 11:44 |
| mborzecki | s/not/now/ | 11:45 |
| jdstrand | yeah, I figured snap-confine was not performing the transition | 11:45 |
| jdstrand | fyi, this could've been used to confirm the kernel was working right: aa-exec -p snap.hello-world.evil -- /snap/hello-world/current/bin/evil | 11:45 |
| jdstrand | but you don't need that now of course | 11:46 |
| mborzecki | jdstrand: zyga: i'll put that bit for interfaces/apparmor/backend.go up for review and post a topic in the forums | 11:46 |
| mborzecki | anything else i could try here? | 11:46 |
| zyga | mborzecki: is this a default config for arch now? | 11:46 |
| zyga | mborzecki: run spread ;) | 11:47 |
| mborzecki | zyga: no, it's linux-hardened kernel, it's not the default, but it is avaialble in community repo, i only had to grab apparmor from aur | 11:47 |
| zyga | ooooh | 11:48 |
| zyga | I fixed my opensuse install :) | 11:48 |
| zyga | woooot | 11:48 |
| zyga | and learned a lot while doing that :0 | 11:48 |
| zyga | :) | 11:48 |
| jdstrand | mborzecki: it does seem like there is a problem though. whatever happened on that system it was failing open | 11:49 |
| jdstrand | mborzecki: normally we see the 'snap-confine is running with elevated privileges but without and apparmor profile" (or whatever) | 11:49 |
| jdstrand | an* | 11:50 |
| mborzecki | jdstrand: 'snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks' this? | 11:50 |
| jdstrand | yes | 11:50 |
| jdstrand | as I understand what you did to make it work, you loaded the snap-confine profile | 11:51 |
| mborzecki | jdstrand: i go that before i dropped snap-confine in /etc/apparmor.d (it wasn't there before) | 11:51 |
| jdstrand | I would've expected that message if the profile wasn't loaded. instead, hello-world.evil ran without the profile change to the apparmor profile | 11:51 |
| zyga | I think what happened is that we load the permissive profile | 11:52 |
| mborzecki | jdstrand: hm it didn't run after i got that message | 11:52 |
| zyga | you probably didn't rebuild snapd with the fix | 11:52 |
| cachio | mvo, hey | 11:52 |
| cachio | mvo, https://paste.ubuntu.com/p/sFhhhBzkQh/ | 11:52 |
| jdstrand | mborzecki: ok, so you didn't have the profile at all, then you got the message and it failed to run? if so, 'good' | 11:52 |
| cachio | the output got from dragonboard | 11:53 |
| mborzecki | jdstrand: i rebuilt snapd with the fix, but s-c was not rebuilt with apparmor and there was no profile for it (basically the default build on arch), then in rebuilt s-c but forgot the drop the profile in /etc/apparmor.d (that's when it got blocked) and last thing i did is to copy the profile and load it, and that's where .evil got blocked and so on | 11:53 |
| pedronis | mvo: are you going to work on landing #5234 ? it has +1s but has conflicts and needs some tweak | 11:53 |
| mup | PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234> | 11:53 |
| jdstrand | mborzecki: ok, that makes sense and it sounds like there is no snapd problem. that was a 'packaging problem', if you will | 11:54 |
| mborzecki | jdstrand: yes | 11:54 |
| jdstrand | mborzecki: thanks for confirming that | 11:54 |
| pedronis | mvo: yes, I prefer a download options, context is not really meant to replace function arguments, it's more to cross unrelated layers or deal with cross-cutting concerns | 11:59 |
| mup | PR snapcraft#2222 closed: lxd: support new style snap injection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2222> | 12:14 |
| mup | PR snapd#5720 opened: interfaces/apparmor: do not downgrade confinement on arch with linux-hardened 4.17.4+ <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5720> | 12:18 |
| mborzecki | zyga: jdstrand: ^^ | 12:18 |
| zyga | done | 12:19 |
| mvo | pedronis: I'm updating 5234 (and the others) now that they all have reviews, no new PR from me until the others are landed, promised | 12:21 |
| pedronis | mvo: :) | 12:21 |
| pedronis | thx | 12:21 |
| mvo | pedronis: thank you for the review(s) | 12:22 |
| mvo | cachio: meh, that lookds not encouraging | 12:22 |
| pedronis | mvo: I think Chipaca added some helper to show Publisher now | 12:23 |
| pedronis | related to #5234 | 12:23 |
| mup | PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234> | 12:23 |
| cachio | mvo, yes | 12:24 |
| cachio | mvo, similar problem than the last time | 12:25 |
| mvo | pedronis: yeah, also the verified publishers ansi and all that, that pr needs some serious work | 12:25 |
| mvo | pedronis: I'm working through my pile, at least this one has clarity now | 12:25 |
| mvo | cachio: I will have to dig into it | 12:26 |
| mborzecki | heh, super dark outside, huuge storm coming my way | 12:28 |
| zyga | mborzecki: oh | 12:28 |
| mborzecki | zyga: it seems to be going east, so you're next :) | 12:29 |
| ackk | hi, I have a json-schema question (asking here sice snapcraft uses it): does anyone know if it possible to define constants for the patterns used in patternProperties? | 12:29 |
| zyga | mborzecki: yeah | 12:29 |
| zyga | ackk: constants as in what? | 12:29 |
| mborzecki | zyga: http://pogodynka.pl/polska/radary | 12:29 |
| zyga | default values | 12:29 |
| zyga | or what? | 12:29 |
| * zyga is somewhat familiar with JSON schema | 12:29 | |
| ackk | zyga, I have the same value for the regexp used in patterProperties used in different objects, is there a way to avoid repeating it? | 12:30 |
| zyga | mborzecki: I'm considering skipping standup to go for that one last bike ride this week | 12:30 |
| zyga | ah | 12:30 |
| sergiusens | does anyone know if chipaca is back next week? | 12:30 |
| zyga | ackk: I see, last time I checked there was no other way than $ref | 12:30 |
| mvo | sergiusens: he will be back tuesday iirc | 12:30 |
| ackk | zyga, yeah but ref doesn't work in a key | 12:30 |
| zyga | so if you can use types/refs (however that was called) to somehow define what you want | 12:30 |
| zyga | otherwise no | 12:30 |
| ackk | zyga, I see, that's what I thought but I was hoping I was wrong :) | 12:31 |
| ackk | zyga, thanks | 12:31 |
| mborzecki | zyga: did ~35km yday and ~27km day before that :) it's a pity it's getting dark around 8pm now | 12:32 |
| === pstolowski|lunch is now known as pstolowski | ||
| mborzecki | and it's gonna be worse only | 12:32 |
| zyga | mborzecki: I did just 23km yesterday and 14 the day before | 12:34 |
| zyga | I would like at least a 10km minimal run :( | 12:34 |
| zyga | but once it rains that's out of the question | 12:34 |
| zyga | ackk: if you find out otherwise do let me know :) | 12:34 |
| ackk | zyga, the little I found on the internet seems to confirm you can't | 12:35 |
| zyga | ackk: it's like with css, people invent ${extra_letter}css to add variables and then compile it to css using piles of javascript ;) | 12:35 |
| ackk | heh | 12:35 |
| niemeyer | zyga: Sounds reasonable.. we might just check if $SNAP_COMMON is set and if so use that path in addition to the default location | 12:37 |
| zyga | yeah | 12:37 |
| zyga | and also a very nice use of $SNAP_COMMON :) | 12:37 |
| zyga | exactly the sort of data we don't want to repeat | 12:37 |
| niemeyer | zyga: Yeah.. let's just be careful to use a subpath there, instead of assuming the snap is necessarily spread | 12:38 |
| niemeyer | Since people can embed spread in their own snaps | 12:38 |
| zyga | mmm | 12:38 |
| sergiusens | niemeyer: hey there. Wanted to ask if we can move today's meeting to Monday | 12:54 |
| mup | PR snapd#5638 closed: interfaces: basic spread test for udev monitor <Blocked> <Hotplug> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5638> | 12:59 |
| niemeyer | sergiusens: Sure thing | 12:59 |
| niemeyer | sergiusens: Morning | 13:00 |
| sergiusens | thanks, this will give us time to prepare better for a couple of discussion points. | 13:00 |
| sergiusens | niemeyer: and good afternoon for you! | 13:00 |
| zyga | mborzecki: hmm | 13:01 |
| zyga | mborzecki: can you checkout master and then go test ./... in interfaces | 13:01 |
| zyga | I get errors related to the new file checker | 13:01 |
| zyga | but they are clearly bogus | 13:01 |
| zyga | the checker is used as in Not(testutil.FileContains) | 13:02 |
| zyga | c.Assert(profile+".src", Not(testutil.FileContains), "# complain mode logging unavailable\n") | 13:02 |
| zyga | so we just want to check that something is not in the file | 13:02 |
| mborzecki | zyga: works fine | 13:02 |
| zyga | and then it says "failed" | 13:02 |
| zyga | but the searched string is _not_ in the file | 13:02 |
| mborzecki | zyga: you need to update vendored deps | 13:02 |
| zyga | aaah | 13:03 |
| zyga | thanks | 13:03 |
| mborzecki | zyga: that's a bug in go-check that's fixed in master and included in the version we vendor | 13:03 |
| zyga | nice | 13:03 |
| mup | PR snapd#5721 opened: interfaces: retain order of inserted security backends <Created by zyga> <https://github.com/snapcore/snapd/pull/5721> | 13:04 |
| zyga | standup! | 13:05 |
| zyga | sorry | 13:05 |
| mup | PR snapd#5593 closed: tests: new test for hostname-control interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5593> | 13:09 |
| mborzecki | zyga: why doesn't it boot? | 13:48 |
| zyga | it was using a snapshot to load grub modules | 13:48 |
| zyga | a btrfs subvolume snapshots | 13:49 |
| zyga | and that snapshot is corrupted | 13:49 |
| zyga | the rest is ok :D | 13:49 |
| mborzecki | heh, nice feature btw | 13:49 |
| zyga | it was reliably failing even after I fixed it | 13:49 |
| zyga | for a reason :D | 13:49 |
| zyga | haha | 13:49 |
| mborzecki | i still think it's crazy to use btrfs by default, but whatever ;) | 13:49 |
| zyga | for _grub_ | 13:49 |
| zyga | anyway | 13:49 |
| zyga | I'm happy now | 13:49 |
| zyga | I need to fix this but it's clear why it is broken | 13:49 |
| mborzecki | did snapper complain at least? | 13:50 |
| diddledan | can I get some tests of gimp from the edge channel please? I want to push stable if it is working fine | 13:50 |
| zyga | snapper used all the space | 13:50 |
| zyga | snapper didn't care | 13:50 |
| diddledan | ping @popey @Wimpress ^^^^^ | 13:50 |
| mborzecki | gib me all your space ;) | 13:50 |
| popey | oooh | 13:51 |
| popey | diddledan: 2.10.6? | 13:52 |
| diddledan | popey: I've added a banner image to the gimp store listing, so it can be a big-banner-featured at some point :-) | 13:52 |
| diddledan | yup 2.10.6 | 13:52 |
| popey | \o/ | 13:52 |
| popey | diddledan: full screen splash intentional? | 13:54 |
| diddledan | have you got a low-res screen? :-p | 13:54 |
| diddledan | I've not changed anything regarding the splash | 13:54 |
| diddledan | so that'll be whatever gimp does normally? | 13:54 |
| diddledan | looks like the splash image from upstream is 1920x1080 | 13:55 |
| popey | ah, i'm 1080p :) | 13:56 |
| diddledan | I've got 1080p and it doesn't go fullscreen for me :-/ | 13:57 |
| diddledan | https://usercontent.irccloud-cdn.com/file/SzjUD61N/Screenshot_20180824_145404.png | 14:00 |
| zyga | I need a small break to walk the dog and eat something | 14:05 |
| mvo | jdstrand: yeah, please allow bases for gadgets | 14:24 |
| mvo | jdstrand: we just discussed this and agreeded its the right approach | 14:25 |
| Wimpress | diddledan: gimp 2.10.6 "worked for me" | 15:00 |
| diddledan | yey, thankyou | 15:00 |
| zyga | re | 15:04 |
| zyga | my dog is much happier now | 15:04 |
| zyga | as am I :) | 15:04 |
| zyga | good food, nice walk | 15:04 |
| * zyga welcomes rain | 16:04 | |
| mup | PR snapd#5655 closed: snap,snap-exec: support command-chain for hooks <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/5655> | 16:31 |
| danieru98 | how can i install a snap in my home directory? | 16:43 |
| popey | We don't support that. | 16:48 |
| danieru98 | is installation for only one user possible? | 16:51 |
| popey | Not currently, no. | 16:52 |
| danieru98 | would be nice if snaps supported that, is that feature planned for the future? should i suggest that feature in Launchpad? | 16:54 |
| mup | PR snapd#5722 opened: tests: test for the hostname interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5722> | 16:55 |
| popey | danieru98: probably something to discuss on the forum, I think? | 16:56 |
| mup | PR snapd#5723 opened: cmd: remove --skip-command-chain from snap run and snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5723> | 16:58 |
| kyrofa | niemeyer, ^ there you go | 17:00 |
| danieru98 | popey, ok i'll create a thread explaining my use case and why snaps won't work for me without this feature. | 17:01 |
| * cachio afk | 17:07 | |
| om26er | can anyone tell why this snap review failed https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/1/ ? | 17:37 |
| om26er | popey: ^ | 17:38 |
| om26er | jdstrand: Hi! | 18:17 |
| mup | PR snapcraft#2224 opened: snapcraftctl: run in isolation mode <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2224> | 18:26 |
| om26er | https://forum.snapcraft.io/t/my-snap-failed-needs-manual-review/7044 | 18:34 |
| niemeyer | kyrofa: Thanks! | 18:40 |
| niemeyer | om26er: Heya | 18:40 |
| om26er | niemeyer: hey | 18:41 |
| niemeyer | om26er: jdstrand is a bit overwhelmed in the last few days, but he'll get to it for sure | 18:41 |
| om26er | niemeyer: sure, no problem. The dashboard seems to have regressed (or this is a special case), previously it did mention the reason for automatic review' failure. | 18:42 |
| niemeyer | om26er: It doesn't look like it failed the automated review | 18:43 |
| niemeyer | om26er: It says not completed from what I can see | 18:43 |
| niemeyer | om26er: It's definitely supposed to mention, but it seems to say the review hasn't finished yet for this case | 18:43 |
| niemeyer | Which is a bit atypical given it's been there for an hour | 18:44 |
| niemeyer | nessita, noise][: Anything you can see from your end here? ^ | 18:44 |
| noise][ | roadmr: nessita: there was an issue earlier with reviews timing out, likely related | 18:47 |
| roadmr | ohai | 18:49 |
| jdstrand | niemeyer: thanks for that | 18:50 |
| roadmr | om26er: this looks consistent with what we saw earlier; reviews are bumping against a too-strict timeout and end up being retried and eventually fail. We're tuning the timeout and I'll re-autoreview your snap once it's ready | 18:50 |
| om26er | roadmr: sounds good, thanks | 18:51 |
| jdstrand | whoops, I just pressed 'perform automated review again' | 18:51 |
| om26er | well maybe it won't timeout this time ;) | 18:51 |
| jdstrand | roadmr: ^ fyi | 18:51 |
| roadmr | jdstrand, om26er : well maybe - if it makes it under the X-second threshold it'll be ok, but if not... pain :( | 18:52 |
| roadmr | which is why we're increasing the timeout, so it's not such a race against fate | 18:52 |
| jdstrand | roadmr: iirc, this is a new thing related to the xenial upgrade? | 18:53 |
| jdstrand | or rather, it is aggravated by the xenial upgrade? | 18:54 |
| roadmr | jdstrand: there're two causes | 18:54 |
| * jdstrand listens | 18:54 | |
| roadmr | jdstrand: the first is the l1tf mitigations cutting our servers' performance in half :( yay it's like it's 2006 and we're all running on Intel Core 32-bit 1st-gen :) | 18:54 |
| roadmr | jdstrand: but interestingly - we're seeing this because matiasb *fixed* things - if he hadn't, those reviews would end up in limbo | 18:55 |
| roadmr | jdstrand: before, when a review hit the timeout, it would just end up stuck and need manual intervention from us | 18:55 |
| jdstrand | ah, yes. I recall that is was like we were time warping. I think I used 2010, hehe :) | 18:55 |
| roadmr | jdstrand: now, it hits a *soft* timeout, so it gets retried in hopes it'll pass this time | 18:55 |
| roadmr | if it consistently fails up to X number of retries, it gets flagged for manual review | 18:55 |
| roadmr | which is at least an actionable state | 18:56 |
| jdstrand | I'm glad to hear about those fixes | 18:56 |
| roadmr | jdstrand: this was deployed today but unfortunately it coincided with the world becoming a slower place for VMs :( | 18:56 |
| jdstrand | sounds good and a good data point | 18:56 |
| jdstrand | oh boo | 18:56 |
| jdstrand | roadmr: well, thanks for taking the time to describe it to me. I guess you have twice as much idle time to chat now that computers take twice as long to do things ;P | 18:57 |
| roadmr | haha I type just as fast, so poor computer has twice as much trouble keeping up with me :D | 18:57 |
| jdstrand | hehe | 18:57 |
| roadmr | jdstrand: I think it's a conspiracy theory to boost sales, since conveniently the only true fix is to buy new hardware | 18:58 |
| jdstrand | roadmr: I know, right? it's a great strategy. put flaws in, fix them to make things slow, buy new hardware that will only get slower. buy new hardware that has cpu fixes to not be vulnerable to old flaws, but introduce new flaws. rinse and repeat | 19:02 |
| jdstrand | we should be hardware guys :) | 19:02 |
| om26er | well, ok the review failed again. Lets wait for the actual fix :) | 19:05 |
| nessita | om26er, what's the snap? | 19:07 |
| om26er | nessita: https://dashboard.snapcraft.io/snaps/xbr-dashboard/revisions/1/ | 19:07 |
| roadmr | jdstrand: yes we're in the wrong business. | 19:10 |
| roadmr | nessita: I have it on a list of snaps to retry | 19:10 |
| om26er | nessita: now it seem the review actually run | 19:12 |
| diddledan | planned obsolescence for the win! | 19:12 |
| nessita | roadmr, sorry I did not know, I retried it | 19:16 |
| jdstrand | nessita: hehe, I did the same thing :) | 19:16 |
| om26er | well this time there is a warning, so "progress" :) | 19:16 |
| om26er | that brings me to the question: If automatic review gets back up, will I be able to push my snap with that pending warning ? | 19:17 |
| om26er | "desktop interfaces (x11) specified without a corresponding meta/gui/*.desktop file..." | 19:18 |
| jdstrand | om26er: no. you need to ship a desktop file | 19:18 |
| jdstrand | then it will pass review (assuming no other errors/warnings) | 19:19 |
| roadmr | nessita: not a problem! with these new softtimeout things, retrying should be harmless | 19:19 |
| jdstrand | roadmr: not at all urgent, but can you schedule pulling in r1121 of the review tools? | 19:35 |
| roadmr | jdstrand: sure thing! | 19:36 |
| jdstrand | cachio: that has the cifs-mount addition ^ | 19:36 |
| jdstrand | cachio: I'll go approve the snap now | 19:36 |
| cachio | jdstrand, thanks | 19:36 |
| roadmr | om26er: I think your snap is unwedged now, though you still need to take care of the desktop file thing. | 19:52 |
| om26er | roadmr: working on the desktop file, almost there :) | 19:52 |
| roadmr | \o/ once it's ready, it should auto-review nicely | 19:52 |
| roadmr | jdstrand: hi! so :( I had to disable resquashfs enforcement, because the extra time needed to process that was causing a lot of snaps to go over threshold and fail automated review. | 19:59 |
| roadmr | jdstrand: do you mind if I leave it off during the weekend? we'll have a closer look on Monday | 19:59 |
| mup | PR snapcraft#2225 opened: build providers: environment setup for projects <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2225> | 20:29 |
| jdstrand | roadmr: well, if that is the best option considering the time, 'ok'. I definitely want to get out of the habit of turning them off | 20:38 |
| * jdstrand realizes it is friday and I don't want to make people work over the weekend for this | 20:38 | |
| jdstrand | but, (and I know we're in sync on this point), I'd like to get to the point where we never turn them off again | 20:39 |
| roadmr | jdstrand: yes, I recognize it's not ideal :( but we know for sure it makes things take longer, and we are seeing these odd timeouts, so it seemed like the only way to cut review times | 20:55 |
| roadmr | jdstrand: this is abnormal, for sure: it was all working mostly OK, so next week we'll have a closer look and turn this back on as soon as feasible | 20:55 |
| jdstrand | roadmr: I understand. as a member of the security team I had to say something :) | 21:02 |
| jdstrand | but it's fine | 21:02 |
| roadmr | indeed :) | 21:03 |
| jdstrand | roadmr: I'm going eow, so if you need something, holler and I'll check back later | 21:03 |
| roadmr | sure thing! enjoy your weekend | 21:03 |
| tyhicks | rescanning all unscanned snaps might be a good idea next week | 21:03 |
| mup | PR snapcraft#2226 opened: templates: reimplement templates as python classes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2226> | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
