| mwhudson | $ snap download --channel=wibble hello | 00:52 |
|---|---|---|
| mwhudson | Fetching snap "hello" | 00:52 |
| mwhudson | error: cannot find snap "hello": snap not found | 00:52 |
| mwhudson | accurate but possibly not maximally helpful | 00:52 |
| niemeyer | mwhudson: Thanks, will have a look tomorrow | 00:54 |
| * niemeyer => bed | 00:55 | |
| mwhudson | niemeyer: good night | 00:55 |
| niemeyer | Night! | 00:55 |
| niemeyer | Or rather, have a good day :) | 00:55 |
| mup | Bug #1773044 opened: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container <Snappy:New> <https://launchpad.net/bugs/1773044> | 01:06 |
| mborzecki | morning | 05:01 |
| zyga | o/ | 05:04 |
| mborzecki | zyga: back from vacation? | 05:14 |
| zyga | yes | 05:15 |
| zyga | hey mvo :-) | 05:15 |
| mborzecki | mvo: morning | 05:15 |
| zyga | we arrived late, plane switching and endless waiting | 05:15 |
| zyga | a bit sleepy | 05:15 |
| zyga | but I managed to fix my machine's snapd by aborting existing changes and refreshing core in isolation | 05:16 |
| mvo | hey zyga and mborzecki | 05:16 |
| mborzecki | zyga: but otherwise the stay in spain was enjoyable? | 05:16 |
| zyga | mborzecki: yes but also very emotional | 05:16 |
| zyga | mborzecki: we have way more close friends there than here | 05:16 |
| zyga | mborzecki: and given the size of the city we met all but one of them, mostly just by bumping into each other, ahead of planned events :) | 05:17 |
| zyga | mborzecki: it's likely we will return there if stars align | 05:17 |
| mborzecki | zyga: haha nice | 05:18 |
| mborzecki | zyga: 2nd thoughts about moving back there? :) | 05:18 |
| zyga | how was the week? | 05:18 |
| zyga | any fires | 05:18 |
| zyga | mborzecki: yes, definitely | 05:18 |
| mup | PR snapd#5193 closed: spread-shellcheck: port to python <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5193> | 05:19 |
| mup | PR snapd#5190 closed: tests: new parameter for the journalctl rate limit <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5190> | 05:24 |
| zyga | Dog time | 05:25 |
| mvo | zyga: when you have a moment (and you are back) a review of 5143 would be great | 05:52 |
| mvo | zyga: you reviewed this already so hopefully simple | 05:53 |
| mvo | we are back to 25 open PRs, yay | 05:53 |
| mvo | a review for 5194 would also be nice (should be pretty trivial) | 06:06 |
| * zyga reviews 5143 | 06:25 | |
| zyga | sorry for the lag, I didn't bring shaving gear with me and I looked like robinson stranded on some island | 06:25 |
| mvo | no worries | 06:26 |
| mborzecki | gdpr emails, getting many of those now that the deadline is tomorrow (?) | 06:39 |
| zyga | mborzecki: yeah, quite a swarm | 06:43 |
| zyga | mborzecki: if I'm a self-emloyed company and I have you in my address book, do I need to send you one too? | 06:43 |
| mborzecki | hahaha | 06:43 |
| mborzecki | well, you'll probably need to keep the business cards in a safe too :) | 06:44 |
| zyga | mvo: done, looking at 5194 | 06:53 |
| mup | PR snapd#5194 closed: interfaces/apparmor: add 'mediate_deleted' profile flag for all snaps <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5194> | 06:57 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | good morning | 07:02 |
| mvo | zyga: thank you | 07:02 |
| mborzecki | pstolowski: hey | 07:06 |
| zyga | hey pawel! | 07:08 |
| mvo | hey pstolowski good morning! | 07:11 |
| BlueShark | How to set an app that was installed using Snap to auto-start on boot? | 07:26 |
| zyga | BlueShark: hey, if the application supports this by itself use internal application settings | 07:27 |
| zyga | BlueShark: otherwise your desktop environment may have something for starting apps on login | 07:27 |
| zyga | BlueShark: if this is a service it will automatically start on boot | 07:27 |
| BlueShark | zyga, It's slack. I enabled auto-start inside Slack settings, but that does not work. It does not start automatically. | 07:27 |
| BlueShark | When I used to install it using the deb file from the wbesite, it used to work perfectly. Now, with Snap though, it's not working. | 07:28 |
| zyga | BlueShark: slack may need a tweak to enable this feature in the snap, it is a new addition | 07:28 |
| BlueShark | (I can't install using the .deb fiile because of some dependency conflict with libcurl4) | 07:28 |
| BlueShark | zyga, no work around possible? | 07:28 |
| zyga | BlueShark: (and I may be wrong that it is still only avialable in the development version of snapd) | 07:28 |
| BlueShark | like something I can add in rc.local or some startup script so that it's executed? | 07:29 |
| zyga | BlueShark: well, as I said, it's a recent addition, once deployed the checkbox you used to use will work again | 07:29 |
| BlueShark | yup, until then, I can use some work around. | 07:29 |
| BlueShark | (if possible.) | 07:29 |
| zyga | not really, those are not compatible with desktop apps | 07:29 |
| zyga | mborzecki: is auto-start for desktop apps released to stable? | 07:29 |
| mborzecki | zyga: yes | 07:29 |
| zyga | ah nice | 07:30 |
| * zyga looks at slack | 07:30 | |
| BlueShark | thanks! | 07:30 |
| zyga | slack is not using this | 07:30 |
| BlueShark | ok, what are they using? | 07:30 |
| zyga | popey: hey, nitpick suggestion about slack, it could ot into the auto-start feature supprt | 07:30 |
| zyga | *support | 07:30 |
| zyga | it should be a one line diff to their snap.yaml now | 07:30 |
| zyga | ahmm | 07:31 |
| zyga | actually | 07:31 |
| BlueShark | File -> Preferences -> Launch app on login - I check this box every time, but when I restart the system, not only does it not start, the checkbox becomes unticked. | 07:31 |
| zyga | slack is using classic confinement | 07:31 |
| zyga | so whatever it is doing should be uninhibited | 07:31 |
| mborzecki | zyga: is it still? | 07:31 |
| mborzecki | i thought they moved to strict | 07:31 |
| zyga | no, they haven't | 07:31 |
| mborzecki | hmmpfff | 07:32 |
| BlueShark | launching /snap/bin/slack from command line seems to work. | 07:34 |
| BlueShark | adding it to a startup script, wouldn't work, zyga? | 07:34 |
| zyga | BlueShark: it looks like auto-start does nothing inside slack | 07:34 |
| zyga | not sure why | 07:34 |
| zyga | BlueShark: define startup script | 07:34 |
| zyga | BlueShark: it would only work if started from your session manager | 07:34 |
| zyga | it would not work from typical system startup | 07:34 |
| mborzecki | zyga: it should drop a desktop file in ~/.config/autostart | 07:35 |
| BlueShark | I was thinking @reboot in crontab | 07:35 |
| zyga | mborzecki: it doesn't | 07:35 |
| zyga | BlueShark: what? | 07:35 |
| zyga | in any case, it would not work :) | 07:35 |
| BlueShark | ok. | 07:35 |
| BlueShark | > it would only work if started from your session manager - is there any way to accomplish this? | 07:35 |
| zyga | popey: I take that back, it would be nice to poke slack about auto-start for their app, it seems to be disabled and it ought to work now | 07:35 |
| zyga | BlueShark: it depends on the session manager but as mborzecki said many of them support reading ~/.config/autostart and looking for desktop files to run there | 07:36 |
| zyga | this book cover: https://twitter.com/mononcqc/status/999471339474968576 :^) | 07:38 |
| BlueShark | zyga, I'm using Ubuntu mATE. | 07:39 |
| zyga | it should work then | 07:39 |
| zyga | but again, it is a bug in slack | 07:39 |
| zyga | so perhaps slack can fix it to just work as it should | 07:39 |
| mborzecki | BlueShark: a workaround, but you could try and symlink /var/lib/snapd/desktop/applications/<slack-desktop-file>.desktop to ~/.config/autostart | 07:43 |
| Chipaca | mood gorning all! | 07:54 |
| zyga | good morning John | 07:54 |
| Chipaca | who is this 'John' person | 07:57 |
| Chipaca | i see only chipacas | 07:57 |
| mvo | Chipaca: hey, good morning! | 07:58 |
| Chipaca | zyga: mvo: good morning :) how's things? | 07:58 |
| zyga | I'm slowly getting back into business | 07:58 |
| zyga | doing reviews now | 07:59 |
| zyga | enjoying the warmth of Poland over the coldness of Spain | 07:59 |
| pstolowski | :) | 08:04 |
| mborzecki | well, it's a nice weather for biking for sure, not too hot, not too cold, bit too windy, but otherwise evening rides are fun :) | 08:05 |
| Chipaca | huh, so my snapd is again stuck in a loop | 08:18 |
| Chipaca | ah... probably need to stop it and rebuild | 08:18 |
| zyga | Chipaca: or abort it and refresh snapd alone | 08:18 |
| zyga | it fixed it for me | 08:18 |
| Chipaca | zyga: it's a dev snapd, no reexec | 08:18 |
| BlueShark | mborzecki, ln -s? | 08:22 |
| mvo | niemeyer: could you please add github.com/snapcore/core18 to mup so that it announces new PRs here? | 08:22 |
| mborzecki | BlueShark: ln -s /var/lib/snapd/desktop/applications/slack_slack.desktop ~/.config/autostart/ | 08:25 |
| Chipaca | pedronis: I just set ensureInterval, pruneInterval, pruneWait and abortWait to time.Second (to force prune my 68MB state.json), and snapd paniced | 08:26 |
| pedronis | Chipaca: that was a bit aggressive | 08:26 |
| Chipaca | pedronis: ikr | 08:26 |
| Chipaca | pedronis: i expected it to be a bit unhappy :-) but a panic seems wrong | 08:27 |
| pedronis | well | 08:27 |
| pedronis | I'm not sure what the invariants are but there are for sure some | 08:27 |
| Chipaca | https://pastebin.ubuntu.com/p/xGTBSswsDD/ if it's of interest to you | 08:27 |
| * Chipaca can't delve into that right now | 08:28 | |
| pedronis | Chipaca: well we are deleting a task that is being run | 08:28 |
| pedronis | or something like that | 08:28 |
| pedronis | not sure | 08:29 |
| pedronis | Chipaca: I see, I think the issue is that changes become ready before they are cleaned up | 08:35 |
| pedronis | Chipaca: I suppose it's a real bug in the sense that the pruning code should wait for the change to be clean, not just ready | 08:36 |
| pedronis | Chipaca: otoh I suppose cleaning might fail and that never happen | 08:41 |
| pedronis | Chipaca: so we would need a cleanWait time | 08:43 |
| pedronis | and a way to stop cleaning itself | 08:44 |
| pedronis | Chipaca: is cleaning on shot? do you remember? | 08:45 |
| Chipaca | pedronis: I don't even remember what cleaning involved :-) | 08:46 |
| Chipaca | pedronis: was that what we hung cleanup from? | 08:46 |
| pedronis | Chipaca: yes, anyway your panic seems related to that | 08:46 |
| Chipaca | k | 08:46 |
| pedronis | and the fact that ready and clean are distinct concept | 08:46 |
| pedronis | but I don't remember how we handle clean errors | 08:47 |
| pedronis | Chipaca: afaict it seems we would try forever | 08:51 |
| pedronis | otoh the only clean we have doesn't return errors (except for state issues) | 08:52 |
| Chipaca | pedronis: there's a cleanup in snapshotmgr | 08:53 |
| Chipaca | pedronis: but it also doesn't error | 08:53 |
| Chipaca | i thought not erroring was cleanups thing | 08:53 |
| pedronis | yea | 08:53 |
| pedronis | Chipaca: though there is still something weird about that panic | 08:57 |
| mborzecki | pedronis: Chipaca: i undestand client.Snap should also carry the list of appstream IDs as top level common-ids? | 09:02 |
| pedronis | think so | 09:03 |
| Chipaca | mborzecki: yah | 09:03 |
| pedronis | Chipaca: so I think the panic as such is an actual bug, the place that does Task(id) should probably not assume that the return will not be nil | 09:04 |
| pedronis | it kinds always not nil, except when it is | 09:05 |
| zyga | https://github.com/snapcore/snapd/pull/5184 is long but interesting if anyone wants to look | 09:11 |
| mup | PR #5184: interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184> | 09:11 |
| pedronis | Chipaca: there's two bugs probably, though one is really relevant only if you set a very low pruneWait | 09:13 |
| pstolowski | pedronis: hey, i've a helper and tentative fix per yesterdays discussion | 09:17 |
| pstolowski | and test is happy | 09:17 |
| pstolowski | preparing PRs | 09:17 |
| pedronis | pstolowski: cool | 09:17 |
| zyga | pstolowski: hey, is the hookapocalypse solved now? | 09:18 |
| pstolowski | not running hooks twice isn't addressed yet, but i'll do that as well i think | 09:19 |
| pstolowski | zyga: it should be yes | 09:19 |
| pedronis | Chipaca: anyway basically pruneWait and abortWait need to be some healthy multiple of ensureInterval | 09:24 |
| * zyga reached his first PR while doing reviews, yay | 09:24 | |
| pedronis | Chipaca: I'll do a small PR about the panic itself | 09:25 |
| Chipaca | pedronis: thanks | 09:25 |
| * zyga small break | 09:27 | |
| Chipaca | waaaait | 09:29 |
| Chipaca | there are only 24 PRs up | 09:29 |
| Chipaca | that's less than a page | 09:29 |
| Chipaca | quick, more PRs! | 09:30 |
| pstolowski | they're coming ;) | 09:40 |
| pedronis | Chipaca: https://github.com/snapcore/snapd/pull/5195 | 09:43 |
| mup | PR snapd#5195 opened: overlord/snapstate: don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <https://github.com/snapcore/snapd/pull/5195> | 09:43 |
| mup | PR #5195: overlord/snapstate: don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <https://github.com/snapcore/snapd/pull/5195> | 09:43 |
| mup | PR snapd#5196 opened: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5196> | 09:44 |
| Chipaca | pedronis: +1 :-) | 09:45 |
| * Chipaca -> physio, probably | 09:45 | |
| upgreydd | hello. Can someone help me with `snap` please? I have problem with access to ports - still getting `access denied`. Ports are unused in hosts machine :( | 09:50 |
| zyga | upgreydd: hey, which ports are you referring to? | 10:01 |
| upgreydd | zyga: 8080, 27017 - they are unused at host -i'm trying to use rocketchat | 10:02 |
| zyga | IP ports? | 10:02 |
| mvo | mborzecki: do we have a forum post about the new watchdog support you added recently? if so, could you please paste hte link? I am updating the 2.33 roadmap page right now. anything else I should mention there that you remember from your side? | 10:05 |
| zyga | upgreydd: well, if you are after network, is your snap using network-bind interface? you need a plug (connected) of that interface to create network services | 10:05 |
| mvo | zyga: same question, anything I should mention (high level) for 2.33 from you? | 10:06 |
| mvo | pstolowski: for 2.33 - interface hooks are in, right? | 10:06 |
| upgreydd | zyga: what are you talking about? :| | 10:06 |
| zyga | upgreydd: can you please give us an overview of your problem? | 10:07 |
| pedronis | mvo: they are not fully usable | 10:07 |
| pstolowski | mvo: we don't have complete feature without now reverted reconnect | 10:07 |
| pedronis | given what we reverted | 10:07 |
| zyga | upgreydd: are you writing some software that binds to network sockets? | 10:07 |
| pstolowski | and without disconnect hooks (PR up, but needs some more work) | 10:07 |
| mborzecki | mvo: i'm afraid there's no separate post about software watchdog, what reminds me i should probably update snap.yaml doc page | 10:08 |
| upgreydd | zyga I've installed package `rocketchat-server` <- it was working before | 10:08 |
| zyga | mvo: I need to check, I think I was only doing bug fixes lately, | 10:08 |
| upgreydd | zyga: when i run `snap start rocketchat-server` only one service is starting, two is not: they are showing errors in journalctl: listen tcp :8090: socket: permission denied | 10:09 |
| zyga | upgreydd: can you run "snap interfaces | grep rocket chat-server" | 10:09 |
| zyga | (skip the space in rocketchat above) | 10:09 |
| upgreydd | zyga: :desktop, :network, :network-bind | 10:10 |
| upgreydd | zyga: there are subservices | 10:10 |
| upgreydd | snap services rocketchat-server Service Startup Current rocketchat-server.rocketchat-caddy enabled inactive rocketchat-server.rocketchat-mongo enabled inactive rocketchat-server.rocketchat-server enabled active | 10:10 |
| zyga | can you now run "dmesg | grep DENIED" | 10:10 |
| upgreydd | zyga: lot of: [ 1055.222607] audit: type=1400 audit(1527156637.606:9658): apparmor="DENIED" operation="ptrace" profile="snap.rocketchat-server.rocketchat-server" pid=7152 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" | 10:11 |
| zyga | can you run | 10:11 |
| zyga | dmesg -c >/dev/null | 10:11 |
| zyga | systemctl restart rocketchat-server # + other services | 10:11 |
| zyga | dmesg | grep DENIED | 10:12 |
| zyga | and pastebin the result | 10:12 |
| upgreydd | zyga: https://pastebin.com/FY9MWcNe | 10:13 |
| popey | cjwatson: https://launchpad.net/~build.snapcraft.io/+snap/20905f58c528ef301b741b624b79dc28-xenial/+build/223942 this build looks wedged, can it be cleaned please? | 10:13 |
| popey | ref: https://forum.snapcraft.io/t/tizonia-store-build-stuck-for-more-than-4-days/5583 | 10:13 |
| === grumblr is now known as grumble | ||
| zyga | upgreydd: can you pastebin /snap/rocketchat-server/current/meta/snap.yaml please | 10:14 |
| upgreydd | zyga: https://pastebin.com/itCDhgLM | 10:15 |
| zyga | can you pastebin /var/lib/snapd/apparmor/profiles/rocketchat-server.rocketchat-caddy | 10:16 |
| zyga | (er, snap.rocketchart-server.rocketchat-caddy) | 10:16 |
| mborzecki | mvo: i've updated https://forum.snapcraft.io/t/the-snap-format/698 | 10:16 |
| upgreydd | zyga: https://pastebin.com/96GzLgnU | 10:18 |
| upgreydd | zyga: is there a way to disable apparmor for whole snap? | 10:19 |
| cjwatson | popey: Yes, I also saw Evan's bug about that, only need one notification | 10:19 |
| zyga | upgreydd: hmm, this is curious | 10:20 |
| popey | I wasn't aware Ev had filed a bug, sorry. | 10:20 |
| zyga | upgreydd: can you run "snap interfaces" and pastebin that again please | 10:20 |
| cjwatson | cancelling, but in general we do cancel stuck builds in bulk every so often | 10:20 |
| upgreydd | zyga: https://pastebin.com/E91MpW5w | 10:21 |
| zyga | hmm hmm hmm | 10:21 |
| zyga | this looks curious | 10:21 |
| zyga | and "snap version"? | 10:22 |
| upgreydd | snap 2.32.8 snapd 2.32.8 series 16 ubuntu 14.04 kernel 4.4.0-127-generic | 10:22 |
| zyga | so | 10:23 |
| upgreydd | as I understand theres a problem with apparmor? Can we just simply override apparmor for this app somehow? | 10:23 |
| zyga | for whatever reason, while snapd claims that the network-bind plug is connected | 10:23 |
| zyga | it is not present in the profile of that app | 10:23 |
| zyga | upgreydd: can you "snap disable rocketchat-server"; snap enable rocketchat-server | 10:23 |
| zyga | that ought to fix it | 10:23 |
| zyga | upgreydd: not per app | 10:23 |
| mborzecki | mvo: and left a note here https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268/45 in case you want to link to it | 10:23 |
| zyga | upgreydd: there's a way to switch apparmor to non-enforcing mode but I think this will fix itself after that last command | 10:24 |
| zyga | I'm worried that it has happened in the first place | 10:24 |
| upgreydd | zyga: your'e right | 10:24 |
| upgreydd | fixed | 10:24 |
| zyga | upgreydd: can you tell me when this started to happen exactly (assuming the disable/enable commands fix it) | 10:24 |
| upgreydd | zyga: after rocketchat autorefresh | 10:25 |
| zyga | can you pastebin snap changes | 10:25 |
| zyga | and then | 10:25 |
| zyga | snap tasks NNN # where NNN is the number of the change you get from the previous command | 10:25 |
| upgreydd | https://pastebin.com/8zdqm1Yj | 10:26 |
| zyga | thanks | 10:27 |
| zyga | nothing that seems to indicate something went wrong :/ | 10:27 |
| zyga | did you reboot your machine? | 10:27 |
| zyga | when this happened | 10:27 |
| zyga | as in <reboot> <stuff is broken> | 10:27 |
| zyga | upgreydd: also in case it has some useful clues as to what went wrong, please pastebin: jounalctl -u snapd | 10:32 |
| upgreydd | zyga: rebooted lot of times | 10:32 |
| mup | PR snapd#5195 closed: overlord/snapstate: don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5195> | 10:32 |
| mvo | mborzecki: thank you! I will link to it | 10:32 |
| upgreydd | zyga: there was some other before me and I don't know what did he did | 10:32 |
| mvo | pstolowski: I move the interface hooks to 2.34 then for now | 10:32 |
| mvo | pstolowski: thank you | 10:32 |
| zyga | mvo: do we have that debian version compare somewhere in the tree? | 10:37 |
| mvo | zyga: we used to, let me see if we still do | 10:38 |
| zyga | I need a function that's similar | 10:38 |
| zyga | thinking about just reusing it | 10:38 |
| mvo | zyga: try strutil.VersionCompare | 10:39 |
| zyga | perfect! | 10:39 |
| zyga | thanks | 10:39 |
| mvo | zyga: if the version numbering is vaguely sane it should work | 10:39 |
| mvo | zyga: what do you need to compare? | 10:39 |
| zyga | mvo: kernel versions | 10:43 |
| zyga | I think this will work perfectly | 10:43 |
| mvo | zyga: yes | 10:47 |
| zyga | mborzecki: hey | 11:10 |
| zyga | - google:ubuntu-14.04-64:tests/main/snapd-notify fails, is that expected? | 11:11 |
| mborzecki | zyga: hmhm? | 11:11 |
| mborzecki | which pr is it? | 11:11 |
| zyga | https://travis-ci.org/snapcore/snapd/builds/383121772 | 11:12 |
| zyga | https://github.com/snapcore/snapd/pull/5196 | 11:12 |
| mup | PR #5196: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5196> | 11:12 |
| * zyga hates packagekit | 11:15 | |
| mborzecki | zyga: not expected, saw it a couple of times, restarting the build helps, intersting bit was journal being empty between cursors | 11:15 |
| zyga | I restarted it already | 11:15 |
| zyga | but maybe bad luck | 11:15 |
| mup | PR snapd#5119 closed: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5119> | 11:15 |
| pedronis | pstolowski: the PR is red | 11:15 |
| mup | PR snapd#5119 opened: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <https://github.com/snapcore/snapd/pull/5119> | 11:16 |
| pstolowski | pedronis: indeed, tests/main/snapd-notify failure, cursor on journal failed | 11:38 |
| pedronis | ah, 14.04 | 11:39 |
| pedronis | mmh | 11:39 |
| jdstrand | pstolowski: hi! it seems https://forum.snapcraft.io/t/supported-snap-hooks/3795 is out of date. it doesn't list connect-{plug,slot}-* and prepare-(plug,slot}-*. are there any others that are missing? I ask because a snap is using a 'refresh' hook (not post-refresh or pre-refresh) | 11:44 |
| jdstrand | pstolowski: I haven't look in the snapd sources yet, but is 'refresh' supported? are there others? | 11:44 |
| jdstrand | looked* | 11:44 |
| pstolowski | pedronis: i'm going to kick the test again and see, but these cursor- based tests seem flaky, we need to revisit them | 11:44 |
| jdstrand | pstolowski: if you don't know otoh, I can read the sources myself | 11:46 |
| pstolowski | jdstrand: hey. i'll take a look at the list; we don't have refresh , only post- and pre- refresh. i'm surprised we see refresh hook somewhere, there was a very brief moment we had this hook (and i think only in edge) and we split/renamed it into pre- and post- very quickly | 11:47 |
| jdstrand | pstolowski: ok, cool, then the tools did their job :) | 11:47 |
| pstolowski | jdstrand: the list looks complete to me in a sense that interface hooks are not fully landed and usable yet, so we shouldn't probably document onnect- and prepare-plug/slot- yet | 11:48 |
| jdstrand | pstolowski: ah, ok. thanks! | 11:49 |
| zyga | jdstrand: hey | 11:52 |
| zyga | jdstrand: question | 11:52 |
| zyga | jdstrand: I'm writing a service that loads snapd-specific apparmor profiles | 11:52 |
| zyga | what kind of guarantees should I put in place, do I need to replicate all the things done by various distro specific helpers | 11:52 |
| zyga | like mounting securityfs and such | 11:52 |
| jdstrand | zyga: if you're unit file does After=apparmor or similar, no. if your unit is meant to be independent, yes. | 11:54 |
| zyga | can I do After=apparmor? | 11:55 |
| zyga | that would definitely simplify it, yes | 11:55 |
| jdstrand | sure, why not? | 11:55 |
| zyga | well, as long as that's portable :) | 11:55 |
| zyga | I'll do it, thanks | 11:55 |
| jdstrand | ./libvirt-bin.service:After=apparmor.service | 11:55 |
| jdstrand | zyga: it is as portable as apparmor.service existing | 11:55 |
| Chipaca | zyga: remember After= isn't Requires= | 11:57 |
| Chipaca | zyga: you can put After=Dziewięćsetdziewięćdziesięciodziewięcionarodowościowego and it'd probably work | 11:58 |
| jdstrand | in this case, After=apparmor.service is probably correct. on distros without apparmor.service, you probably don't have apparmor_parser or the apparmor abstractions. snapd can then proceed in devmode | 12:00 |
| jdstrand | zyga, Chipaca: ^ | 12:01 |
| mup | PR snapd#5197 opened: [WIP] cmd/snap: display a link to the TOS for interactive snap login <Created by pedronis> <https://github.com/snapcore/snapd/pull/5197> | 12:07 |
| mup | PR snapd#5198 opened: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198> | 12:07 |
| zyga | jdstrand: ^ a quick idea | 12:07 |
| zyga | jdstrand: I would subsequently install this on openSUSE | 12:08 |
| cachio | zyga, mvo, #5143 updated | 12:11 |
| mup | PR #5143: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143> | 12:12 |
| cachio | mborzecki, #5143 updated | 12:12 |
| cachio | thanks for reviewing!! | 12:12 |
| zyga | cachio: ack, looking again | 12:12 |
| mvo | cachio: thank you | 12:14 |
| mvo | cachio: looking | 12:14 |
| cachio | mvo, I am re executing this in the boards to validate everything is ok | 12:15 |
| mvo | cachio: cool, thank you. once this is good I will cherry-pick it into 2.33 | 12:16 |
| mvo | cachio: we just need to remember to squash merge it | 12:16 |
| cachio | mvo, perfect | 12:16 |
| zyga | cachio: in 5143, can you please react to existing feedback, I'm not sure if you saw something but chose to ignore it or if an older feedback was acted upon but the lines have changed so the comment is hidden | 12:24 |
| * zyga -> school see you at the standup | 12:25 | |
| mvo | zyga, sil2100 feedback on 10,11 for https://github.com/snapcore/core18/pulls woudl be great (no rush though) | 12:25 |
| cachio | zyga, sure | 12:33 |
| sil2100 | mvo: sure o/ | 12:33 |
| popey | diddledan: I'm told by sergiusens that the new snapcraft should be available in build now, so maybe we can land your gimp 2.10 work? | 12:34 |
| diddledan | \o/ | 12:35 |
| diddledan | click the butten! | 12:35 |
| diddledan | button* | 12:35 |
| diddledan | I'm working on 2.10.2 atm | 12:35 |
| diddledan | this is a problem I'm encountering, which appears to be something with my build rather than snapd? (gimp:17871): GLib-ERROR **: 13:36:13.404: gmem.c:333: overflow allocating 18446744073709551615*18446744073709551615 bytes | 12:36 |
| Chipaca | diddledan: here's a nickle, etc | 12:39 |
| * zyga actually doesn't do school run now, eh | 12:39 | |
| mup | PR snapd#5199 opened: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199> | 12:41 |
| om26er | Chipaca: that https://github.com/torvalds/linux/blob/master/include/math-emu/double.h#L29 ? | 12:43 |
| Chipaca | om26er: which is a reference to http://dilbert.com/strip/1995-06-24 | 12:44 |
| om26er | epic | 12:45 |
| zyga | mborzecki: question on appstream integration | 12:45 |
| zyga | posted on github | 12:45 |
| Chipaca | zyga: search responses don't include app info | 12:47 |
| zyga | ah | 12:47 |
| zyga | I see | 12:47 |
| Chipaca | zyga: but search consumers need to know the ids of the results | 12:47 |
| Chipaca | zyga: so the easiest way is to have it in both places | 12:47 |
| zyga | so this is the client side | 12:48 |
| Chipaca | zyga: all sides | 12:48 |
| zyga | is the store side (that is snapd->store) part ready? | 12:48 |
| Chipaca | zyga: yes, has been for a while now | 12:48 |
| Chipaca | we were lagging | 12:48 |
| Chipaca | i mean | 12:48 |
| Chipaca | the _store_ has been responding with common ids for a while, if asked | 12:48 |
| Chipaca | snapd hasn't been asking | 12:48 |
| zyga | how do we ask? | 12:49 |
| zyga | I see deserialisation things but I don't see something like "gimme common-id" | 12:49 |
| Chipaca | zyga: include it in the 'fields' query | 12:50 |
| Chipaca | zyga: store.Config.DetailFields | 12:50 |
| mborzecki | zyga: that part is magical :) | 12:50 |
| zyga | oh? | 12:50 |
| Chipaca | zyga: ＭＡＧＩＣ | 12:51 |
| zyga | it gets computed from the structs somehow> | 12:51 |
| zyga | ? | 12:51 |
| mborzecki | Chipaca: did you write it? | 12:51 |
| mborzecki | zyga: yes | 12:51 |
| Chipaca | yes | 12:51 |
| zyga | ah, ok | 12:51 |
| zyga | +1 then | 12:51 |
| zyga | this is a major thing, thank you mborzecki | 12:51 |
| Chipaca | no, it's a common thing | 12:51 |
| Chipaca | otherwise it would be major-id | 12:51 |
| * Chipaca runs | 12:51 | |
| mborzecki | haha | 12:51 |
| zyga | Chipaca: is a general-id better than major-id | 12:53 |
| zyga | and is there a private-id | 12:53 |
| * zyga gets back to coding | 12:53 | |
| cachio | zyga, #5143 ready again | 12:56 |
| mup | PR #5143: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143> | 12:56 |
| zyga | mvo: thanks for the question on 5198, replied and removed the code there | 12:56 |
| zyga | cachio: ack, | 12:56 |
| zyga | cachio: thanks, I think only https://github.com/snapcore/snapd/pull/5143#discussion_r190480661 remains | 12:59 |
| mup | PR #5143: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143> | 12:59 |
| zyga | after that +1 | 12:59 |
| zyga | jdstrand: thanks for the quick review, replied and will make the changes | 13:31 |
| mup | PR snapd#5188 closed: tests: ubuntu core abstraction <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5188> | 14:21 |
| jdstrand | zyga: interesting: kernel: [624468.239774] audit: type=1400 audit(1527171830.098:109395): apparmor="DENIED" operation="file_inherit" profile="snap-update-ns.firefox" name="/dev/null" pid=15584 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 14:24 |
| kjackal | What is the process for changing the publisher of a snap? | 14:24 |
| popey | kjackal: The store team can initiate a transfer, Start a thread on the forum in the store category | 14:25 |
| kjackal | thanks | 14:25 |
| cachio | zyga, hey | 14:25 |
| jdstrand | zyga: we should add '/dev/null rw,' to the sun profile | 14:25 |
| zyga | ack | 14:25 |
| cachio | I can add a function to systems.sh like it_is_ubuntu_14 | 14:26 |
| cachio | is_ubuntu_14 | 14:26 |
| cachio | so we can use that in state.sh and leave it as bash | 14:26 |
| cachio | sh | 14:26 |
| cachio | does it make sense? | 14:27 |
| zyga | yes, | 14:27 |
| cachio | I'll just used that method in the state, then I'll update the rest of the code in a new PR | 14:28 |
| cachio | because otherwise it will be huge change | 14:28 |
| cachio | zyga, does it make sense? | 14:29 |
| * zyga needs to take the dog for a walk | 14:34 | |
| jdstrand | roadmr: fyi, https://dashboard.snapcraft.io/snaps/huggle/revisions/1227/ was stuck for what looked like 16 hours. I pressed the 'run the automated review again' button | 14:48 |
| jdstrand | roadmr: hi btw :) | 14:48 |
| roadmr | jdstrand: oh! so is it unstuck now? | 14:49 |
| jdstrand | roadmr: yes | 14:49 |
| roadmr | yes it is! | 14:49 |
| roadmr | ok, I'll check logs to see what may have happened. | 14:49 |
| jdstrand | roadmr: also, can you queue up r1078? not urgent at all. can come after the last request for pull | 15:03 |
| mvo | sil2100, zyga trivial PR https://github.com/snapcore/core18/pull/12 | 15:03 |
| mup | PR core18#12: hooks: trivial rename to make them consistently XXX-name.chroot <Created by mvo5> <https://github.com/snapcore/core18/pull/12> | 15:03 |
| roadmr | jdstrand: sure! | 15:03 |
| zyga | Looking | 15:04 |
| zyga | +1 | 15:05 |
| sil2100 | Yeah, I guess it's much cleaner now | 15:06 |
| jdstrand | roadmr: thanks! | 15:06 |
| mvo | zyga, sil2100 ta | 15:07 |
| pedronis | Chipaca: we usually spell id ID | 15:30 |
| Chipaca | we do | 15:30 |
| Chipaca | oops | 15:31 |
| pedronis | except when we don't, but it's usually ID around snap stuff | 15:31 |
| pedronis | major offender seems some code in state.go | 15:33 |
| pedronis | user.LookupId seems an offender in the stdlib | 15:35 |
| * zyga -> food | 15:36 | |
| mup | PR snapd#5200 opened: interfaces: reconnect, fix for autoconnect/reconnect conflict check <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5200> | 16:00 |
| pedronis | niemeyer: I asked a clarification about common-id here: https://forum.snapcraft.io/t/support-for-appstream-id/2327/24 | 16:32 |
| niemeyer | Looking | 16:32 |
| niemeyer | pedronis: Replied | 16:33 |
| pedronis | niemeyer: does it mean we need validation about repeated common-ids in snapcraft, snapd? | 16:34 |
| pedronis | or it's benign enough, just not expected | 16:35 |
| mborzecki | re | 16:37 |
| pedronis | niemeyer: sorry, I asked here, but the answer to what to do probably should go in the forum | 16:38 |
| niemeyer | pedronis: I think we should enforce it in snapd/snapcraft | 16:38 |
| niemeyer | pedronis: Hmm.. well | 16:38 |
| niemeyer | pedronis: Or maybe it's not a big deal after all | 16:38 |
| niemeyer | pedronis: What'd be the consequences of that? | 16:39 |
| niemeyer | The point is mapping id => snap | 16:39 |
| pedronis | not big | 16:39 |
| niemeyer | If multiple apps have the same, that's still just one id => snap arrow | 16:39 |
| pedronis | but I see snapcraft does thing with common-id and desktop files | 16:39 |
| pedronis | which I'm not sure I understand | 16:39 |
| pedronis | how is impacted | 16:39 |
| mborzecki | fwiw checking for unique common-id within a snap in snap pack --check-skeleton could be easily added | 16:41 |
| pedronis | mborzecki: we are discussing in the forum post as well | 16:42 |
| niemeyer | pedronis: See note | 16:50 |
| cachio | zyga, does it make sense what I proposed for the bash/sh discussion? | 16:52 |
| zyga | cachio: looking now | 17:01 |
| cachio | zyga, tx | 17:01 |
| zyga | cachio: not really :) | 17:03 |
| zyga | cachio: the point was that including is confusing because there are two languages | 17:03 |
| zyga | cachio: if you include systems.sh from bash it works ok | 17:03 |
| zyga | cachio: if you include it from sh it will not work because [[ is not in dash | 17:04 |
| zyga | cachio: the solution is to either use bash everywhere (I made a point that we dont) or use sh compatible code | 17:04 |
| zyga | cachio: (like the one maciej suggested) | 17:05 |
| zyga | does that make sense? | 17:05 |
| cachio | yes, but what is we use bash for everything? | 17:07 |
| cachio | what if | 17:07 |
| zyga | that is fine too | 17:07 |
| zyga | I personally prefer to avoid the need for bash but that's beyond the point | 17:07 |
| cachio | but, all the tests run on bash | 17:08 |
| cachio | so the helpers could too | 17:08 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio_ | zyga, I got disconnected | 17:10 |
| zyga | cachio_: I didn't write more than before, my point is that we need to be consistent as we are not writing separate files that get executed but instead have a swarm of include files | 17:10 |
| cachio_ | zyga, agree with this | 17:11 |
| cachio_ | that's why I propose to move everything to bash | 17:11 |
| cachio_ | as the tests are on bash | 17:11 |
| cachio_ | and those are sourcing most of the scripts | 17:12 |
| cachio_ | I prefer to have just 1 language | 17:12 |
| cachio_ | so we reduce the complexity and it is more robust as well | 17:12 |
| zyga | cachio_: ok, go ahead | 17:13 |
| cachio_ | mvo, mborzecki guys do you agree with that? | 17:14 |
| cachio_ | zyga, should I do it in this PR or create a new one? | 17:16 |
| zyga | cachio_: maybe a small separate PR, although TBH your current PR just needs a tweak to be sh safe in one line and it could land as well | 17:16 |
| cachio_ | zyga, awesome, thanks | 17:17 |
| cachio_ | zyga, shellchecks fixed and pushed | 17:44 |
| zyga | ack | 17:44 |
| cachio_ | now running here on ubuntu core to make extra validation | 17:44 |
| zyga | thanks | 17:45 |
| zyga | approving | 17:45 |
| cachio_ | zyga, thanks!!!! | 17:46 |
| zyga | done | 17:46 |
| zyga | boy, my dog is crazy today | 17:46 |
| zyga | he is so all over me today | 17:46 |
| zyga | after being away for a week he got super lonely | 17:46 |
| zyga | he's literally walking overy my laptop in front of my face for attention | 17:47 |
| cachio_ | hehehe | 17:56 |
| cachio_ | zyga, he needs another walk | 17:56 |
| zyga | jdstrand: can you please have another look at https://github.com/snapcore/snapd/pull/5198 | 18:06 |
| mup | PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198> | 18:06 |
| mvo | zyga, cachio_ I just read backlog - fwiw, we are using bashisms already in our scripts left and right, just "git grep \[\[", including in prepare-restore reset, snaps | 18:32 |
| zyga | mvo: I know, that's fine | 18:32 |
| mvo | zyga, cachio_ so moving "formally" to bash seems to make sense | 18:32 |
| zyga | mvo: I think this just makes sense to do all the way | 18:32 |
| mvo | zyga: aha, ok. maybe I missed parts of the discussion then | 18:32 |
| mvo | zyga: +1 | 18:32 |
| mvo | zyga: yeah, we are (de-facto) already doing it :) | 18:32 |
| zyga | mvo: no, just saying that the point I was after was addressed and I already approved that | 18:32 |
| mvo | I mean, everywhere lib/pkgdb.sh, lib/dbus.sh | 18:32 |
| mvo | zyga: cool, so we are all in agreement | 18:33 |
| cachio_ | mvo, zyga agreed :) | 18:34 |
| cachio_ | mvo, I'll create a PR for tha tchange | 18:36 |
| zyga | sigh | 18:37 |
| mvo | zyga: hm? | 18:37 |
| zyga | The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over). | 18:37 |
| zyga | yet we log src/github.com/snapcore/snapd/interfaces/backend.go and all the other files | 18:37 |
| mvo | cachio_: I think its fine to keep as is and make this a separate PR, the mixing of bash/dash is not a new issue with the PR we already do it, I think it should not block this pr from landing (as long as we fix it properly in a followup). *if* its trivial, then I don't mind if its the same PR of course | 18:38 |
| mup | PR snapd#5201 opened: interfaces/apparmor: use helper to load stray profile <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5201> | 18:44 |
| mvo | zyga: just finished reading the bash/dash comments, sorry that I lacked some context earlier and thank you for raising this (and now it gets fixed :) | 18:45 |
| zyga | mvo: no worries at all :) | 18:45 |
| Pharaoh_Atem | zyga, fwiw, I'm totally okay with explicitly using bash | 19:02 |
| Pharaoh_Atem | I'm not a fan of pure-posix shellscript anyway | 19:02 |
| === r04r is now known as Guest44185 | ||
| === ahayzen is now known as Guest53889 | ||
| === Shibe is now known as Guest78958 | ||
| === mwhudson is now known as Guest32565 | ||
| === braderhart is now known as Guest74533 | ||
| === yofel is now known as Guest51009 | ||
| === Ursinha is now known as Guest40906 | ||
| === BlueShark is now known as Guest36446 | ||
| === tianon is now known as Guest43437 | ||
| === ackk is now known as Guest13403 | ||
| === icey is now known as Guest76648 | ||
| === kirkland is now known as Guest97190 | ||
| === Guest53889 is now known as ahayzen | ||
| === Guest13403 is now known as ackk | ||
| mup | PR snapd#5202 opened: packaging: filter out verbose flags from "dh-golang" <Created by zyga> <https://github.com/snapcore/snapd/pull/5202> | 20:04 |
| zyga | jdstrand: I pathched my system not to load profiles from /var/lib/snapd/apparmor/profiles | 20:56 |
| zyga | jdstrand: and installed the improved snapd.apparmor.service | 20:56 |
| zyga | jdstrand: no issues | 20:56 |
| jdstrand | nice! :) | 20:56 |
| zyga | 173ms snapd.apparmor.service | 20:57 |
| zyga | that's according to systemd-analyze | 20:57 |
| zyga | it is surprisingly fast | 20:57 |
| zyga | I assume that cached hot path (after reboot) must be in effect | 20:58 |
| zyga | or ... my code is a nop ;-) | 20:58 |
| jdstrand | yes. loading from cache is going to be fast | 20:58 |
| zyga | reading the code carefuly I found some things to ask you | 20:59 |
| zyga | 1) skipping in containers and 2) cache invalidation | 20:59 |
| zyga | do I need to concern myself with 2? | 20:59 |
| jdstrand | zyga: 2> no. the parser will do that | 21:00 |
| jdstrand | zyga: since you are using --write-cache | 21:00 |
| zyga | jdstrand: and 1) ? | 21:03 |
| jdstrand | zyga: you need to do that | 21:04 |
| zyga | ack | 21:04 |
| zyga | jdstrand: hmmm | 21:08 |
| zyga | jdstrand: will this break snapd in lxd? | 21:08 |
| zyga | ^ https://www.irccloud.com/pastebin/qV2tRkpA/ | 21:08 |
| jdstrand | zyga: not if you do it right. see /lib/apparmor/profile-load and functions | 21:08 |
| zyga | jdstrand: this is what start does as a check, is that's essentially what we need as well? | 21:09 |
| zyga | the reason I ask is because this check runs first | 21:10 |
| jdstrand | zyga: yes. udevadm info -an /dev/input/js0 is defined in /lib/apparmor/functions on ubuntu. you'd need to steal it | 21:10 |
| zyga | so the more sophisticated check ... wont run | 21:10 |
| jdstrand | wow | 21:10 |
| jdstrand | that was not what I expected in my clipboard | 21:10 |
| jdstrand | zyga: yes. is_container_with_internal_policy is defined in /lib/apparmor/functions on ubuntu. you'd need to steal it | 21:10 |
| zyga | hmm, but how does that code run if apparmor.service exits quickly because the code I pasted returns early? | 21:11 |
| zyga | ah | 21:11 |
| zyga | I'm blind | 21:11 |
| zyga | I didn't see the && | 21:11 |
| zyga | jdstrand: do you think I can source /lib/apparmor/functions | 21:12 |
| zyga | I;d rather not copy that | 21:12 |
| jdstrand | zyga: no. that won't exist every where | 21:12 |
| zyga | ok | 21:12 |
| zyga | thanks! | 21:12 |
| jdstrand | is_container_with_internal_policy is an Ubuntu-ism since no one else had stacking until more recent kernels | 21:12 |
| === Guest44185 is now known as r04r | ||
| zyga | done | 21:21 |
| zyga | it's shellcheck clean too | 21:22 |
| zyga | I will reboot to give it one more test | 21:22 |
| jdstrand | ohh! | 21:27 |
| jdstrand | popey: | 21:27 |
| jdstrand | # evdev joystick | 21:27 |
| jdstrand | KERNEL=="event[0-9]*", SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="1", TAG+="snap_mame_mame" | 21:27 |
| popey | is that good or bad? | 21:28 |
| jdstrand | popey: that is good. that is just a change to joystick.go | 21:28 |
| popey | I agree then, good :) | 21:28 |
| jdstrand | popey: I'm still investigating, but that is super promising | 21:28 |
| * zyga imagines jdstrand playing zelda while explaining "I'm working" at his surprised family members :) | 21:32 | |
| zyga | jdstrand: all good after reboot | 21:32 |
| jdstrand | zyga: it literally already happened | 21:32 |
| jdstrand | I think the quote was: You're doing God's work, aren't you?" | 21:33 |
| jdstrand | it wasn't sarcastic at all! ;) | 21:35 |
| zyga | jdstrand: can you have a look at 5201, it's a tiny cleanup | 21:35 |
| === Guest32565 is now known as mwhudson | ||
| zyga | jdstrand: is adb-support something that is still blocked, maybe I don't understand your prior feedback? | 21:52 |
| mup | PR snapd#5119 closed: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5119> | 21:53 |
| jdstrand | zyga: approved | 22:04 |
| jdstrand | zyga: I haven't gotten back to re-reviewing it. I've added it to my list for tomorrow | 22:05 |
| zyga | thanks :) | 22:16 |
| zyga | I will EOD today | 22:16 |
| zyga | see you tomorrow | 22:16 |
| jdstrand | zyga: take it easy | 22:27 |
| jdstrand | kyrofa: hey, am I remembering right that you wanted evdev joystick support? | 22:28 |
| mup | PR snapcraft#2146 opened: project_loader: process parts in consistent order <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2146> | 22:28 |
| kyrofa | jdstrand, indeed, did you figure it out? | 22:32 |
| jdstrand | kyrofa: yes. PR on its way | 22:33 |
| kyrofa | Lovely! | 22:33 |
| sergiusens | kyrofa: you should add a test using `after` too | 22:36 |
| mup | PR snapd#5203 opened: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5203> | 22:37 |
| jdstrand | kyrofa: ^ there you go (surprisingly simple) | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!