| diddledan | if it's a known issue, is there a plan to, or has it been, solve(d)? | 00:00 |
|---|---|---|
| ali1234 | snapcraft seems to have trouble with non-ascii | 00:03 |
| === cwayne_ is now known as cwayne | ||
| diddledan | yeah. that's crazy considering that 90% of the population aren't English | 00:04 |
| diddledan | of course 87% of all statistics are made up on the spot, but you get my point | 00:05 |
| nacc | lol | 00:05 |
| ali1234 | 502 proxy error? | 00:31 |
| diddledan | hmm? | 00:35 |
| ali1234 | probably https://bugs.launchpad.net/launchpad/+bug/1683819 | 00:35 |
| mup | Bug #1683819: Continuous 502 proxy error on snap upload to store <Launchpad itself:New> <https://launchpad.net/bugs/1683819> | 00:35 |
| ali1234 | diddledan: https://bugs.launchpad.net/snapcraft/+bug/1662456 | 00:58 |
| mup | Bug #1662456: snapcraft fails if desktop file included "ascii" cannot decode byte <isv> <Snapcraft:Triaged> <https://launchpad.net/bugs/1662456> | 00:58 |
| diddledan | ah, thankyou | 00:58 |
| * diddledan clicks that it affects me | 00:58 | |
| ali1234 | so now i get: desktop interfaces (x11) specified without meta/gui/*.desktop. Please provide a desktop file via setup/gui/*.desktop if using snapcraft or meta/gui/*.desktop otherwise. It should reference one of the 'apps' from your snapcraft/snap.yaml. | 00:59 |
| ali1234 | i have no idea what this means | 00:59 |
| nacc | ali1234: does your yaml refer to the desktop interface? | 00:59 |
| ali1234 | no? | 00:59 |
| ali1234 | it refers to x11 | 01:00 |
| nacc | ali1234: right, that's what the above messages says is "desktop interfaces" | 01:00 |
| ali1234 | okay but what is setup/gui/*.desktop? | 01:00 |
| nacc | ali1234: a .desktop file for yoru application | 01:00 |
| ali1234 | what is the setup/gui part? | 01:00 |
| nacc | ali1234: i'm guessing a path in your snap's source | 01:01 |
| ali1234 | its nothing to do with anything i am trying to build | 01:01 |
| nacc | ali1234: hrm? you're tyring to use an interface that apparently requires .desktop files | 01:02 |
| nacc | ali1234: so ... absolutely has to do with wha tyou're building (a snap) | 01:02 |
| ali1234 | it doesn't require them, the snap works fine when i build and install it locally | 01:02 |
| diddledan | setup is a snapcraft-specific thing that if desired needs to be a folder along-side your yaml file | 01:02 |
| nacc | ali1234: could be a disagreement about the version of snapcraft you're using and the one the builder is using? | 01:03 |
| ali1234 | so it is telling me to create setup/gui/pulseview.desktop, and then put it in the snap somehow? | 01:03 |
| nacc | ali1234: you put it in the repository containing your yaml | 01:03 |
| diddledan | it'll put it in there automatically | 01:03 |
| nacc | ali1234: at that path | 01:03 |
| nacc | ali1234: and it will dtrt | 01:03 |
| ali1234 | so i just create it? | 01:04 |
| ali1234 | how does it know what filename to look for? | 01:04 |
| diddledan | let me screenie my tree | 01:04 |
| diddledan | https://usercontent.irccloud-cdn.com/file/I0ALdl5B/ | 01:04 |
| ali1234 | so i do have to make the directories? | 01:04 |
| nacc | ali1234: presumably via the application name that is using the interface? | 01:04 |
| ali1234 | and what is your app called? | 01:04 |
| nacc | ali1234: yes, you ahve to make the directories | 01:04 |
| nacc | ali1234: it's telling you, you need a file at setup/gui/<app>.desktop | 01:05 |
| ali1234 | the app is called pulseview but it shows up as sigrok.pulseview when installed, because the snap has two apps | 01:05 |
| nacc | ali1234: so of course you need the directgories | 01:05 |
| nacc | ali1234: how else would you create the file in the directories? | 01:05 |
| ali1234 | well, i would use dump plugin with a line like organize: pulseview.desktop: setup/gui/pulseview.desktop | 01:05 |
| ali1234 | that's how you normally get a file into the snap | 01:06 |
| nacc | ali1234: this is not into the snap | 01:06 |
| nacc | ali1234: this is in the 'source' | 01:06 |
| ali1234 | the error comes from store review of the built snap | 01:06 |
| nacc | ali1234: the same place your yaml lives | 01:06 |
| nacc | ali1234: right, so you put in the source and snapcraft will put it in the right place | 01:06 |
| ali1234 | so i would expect it means it wants the file in the snap | 01:06 |
| nacc | that's my reading | 01:06 |
| diddledan | it's an automatic thing | 01:07 |
| diddledan | you don't do anything with it other than create it | 01:07 |
| nacc | ali1234: i don't think you do anything with teh built snaps | 01:07 |
| nacc | that's all snapcraft's job | 01:07 |
| ali1234 | you build them | 01:07 |
| diddledan | i.e. don't try to put it in the build process | 01:07 |
| nacc | except maybe organize them | 01:07 |
| diddledan | snapcraft handles the setup/ folder automatically | 01:08 |
| ali1234 | so what did you put in the .desktop file? | 01:08 |
| ali1234 | ahi found an example | 01:08 |
| nacc | diddledan: right that makes sense, it's like custom parts | 01:09 |
| diddledan | I'm getting closer to finally achieving a custom gtk build | 01:21 |
| diddledan | corebird 1.5 (released a few days ago) requires more recent gtk deps than xenial provides so my snap needs custojobby | 01:21 |
| diddledan | I have managed a complete compile but I'm still working out the right stuff to force into the snap | 01:22 |
| === chihchun_afk is now known as chihchun | ||
| abeato | ogra_, it looks like --extrausers is not working for chfn command in latest core snap (for armhf at least), which prevents "snap create-user" to work, is that a known issue? | 07:12 |
| morphis | abeato: we found that yesterday and ogra_ created a new core snap which should fix that problem | 07:41 |
| morphis | abeato: that should be fixed in edge | 07:41 |
| abeato | morphis, great... the perils of using edge ;) | 07:43 |
| morphis | abeato: yes :-) | 07:43 |
| mup | PR snapd#3281 opened: tests: add test for empty snap name on revert <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3281> | 07:55 |
| zyga | re | 08:13 |
| zyga | good morning | 08:13 |
| pstolowski | morning zyga ! | 08:19 |
| Chipaca | good morning peeps! | 08:23 |
| ali1234 | morning | 08:24 |
| ali1234 | all that stuff last night about meta gui? turns out its just a warning, not an error | 08:25 |
| ali1234 | so now i have 6 versions of the same snap pending review in the store | 08:25 |
| zyga | Chipaca: hey hey :) | 08:25 |
| zyga | pstolowski: good morning! | 08:25 |
| morphis | morning! | 08:25 |
| * zyga coundn't help it and had to take a walk in the morning | 08:25 | |
| zyga | morphis: o/ | 08:26 |
| morphis | zyga: can you give https://github.com/snapcore/snapd/pull/3274 another look? I've added more test cases and printing a warning whenver a confinement check is ignored | 08:26 |
| mup | PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274> | 08:26 |
| zyga | morphis: I already am, I'm mid way through the new commit | 08:26 |
| morphis | great | 08:26 |
| mup | PR snapcraft#1295 closed: recording: record build packages installed in the snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1295> | 08:40 |
| Chipaca | fgimenez: do we use travis oauth tokens? | 08:44 |
| Chipaca | fgimenez: (good morning, also :-) ) | 08:45 |
| fgimenez | Chipaca: hey :) if you mean github oauth tokens from travis nope we let travis interact with github | 08:51 |
| Chipaca | fgimenez: ah alright | 08:52 |
| Chipaca | asking because of https://blog.travis-ci.com/2017-05-08-security-advisory | 08:52 |
| Chipaca | but if we don't, great :-) | 08:52 |
| Chipaca | “Various GitHub OAuth tokens and secure environment variables that users included in their builds were accidentally exposed via inclusion in build logs on Travis CI.” | 08:52 |
| fgimenez | Chipaca: yep, no problem for us, we push to gh, but from our side of the vpn | 08:52 |
| zyga | morphis: quick suggestion, perhaps the skip part could be a function that we source so that we don't have to copy-paste the same line for consistency in behavior | 08:57 |
| morphis | zyga: you mean the snap forced-devmode check? | 08:58 |
| zyga | morphis: otherwise looks ok, I was doing some other things but I'll +1 it (again) in a moment | 08:58 |
| zyga | morphis: yeah, something about that, it's tricky because it's simetimes if ... then exit; but sometimes not | 08:58 |
| morphis | zyga: I was thinking about that before but actually like this to be really explicit and as it might be used in different combinations | 08:58 |
| zyga | morphis: yeah, I understand | 08:59 |
| morphis | lets leave it lets see how complex the logic gets into the future | 09:00 |
| morphis | I will have multiple changes for fedora too which makes things more complicate and might refactor a few of these tests again | 09:00 |
| pstolowski | zyga, hey, wrt to the problem of hanging configure hook on debian; I found out (by examining and comparing strace for that hook on both debian ubuntu) that a posible suspect is: "bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = ? " | 09:00 |
| pstolowski | zyga, i'm not familiar with ipv6 peculiarities, any idea what may be different in that aspect on debian? | 09:01 |
| zyga | pstolowski: hey | 09:01 |
| morphis | pstolowski: isn't that what jdstrand found when initially looking at the bug? | 09:02 |
| pstolowski | morphis, oh, where did he mention that? | 09:04 |
| morphis | https://bugs.launchpad.net/snappy/+bug/1674193/comments/16 and https://bugs.launchpad.net/snappy/+bug/1644573 | 09:04 |
| mup | Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193> | 09:04 |
| mup | Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573> | 09:04 |
| morphis | pstolowski: the thing is that there was a fix merged in 2.23.6 merged which broke with 2.24 again | 09:04 |
| morphis | pstolowski: verified once ago that this problem was fixed with 2.23.6: https://bugs.launchpad.net/snappy/+bug/1674193/comments/25 | 09:05 |
| pstolowski | morphis, oh, wonderful! thanks for these links | 09:07 |
| morphis | pstolowski: they* are on your forum post already :-) https://forum.snapcraft.io/t/tests-broken-in-master/457/8 | 09:07 |
| pstolowski | morphis, oh indeed.. | 09:08 |
| * pstolowski embarassed | 09:08 | |
| morphis | happens :-) | 09:08 |
| ali1234 | so i finally have an approved snap in the store. do i just click release now? | 09:08 |
| Chipaca | ali1234: as you wish :-) | 09:17 |
| ali1234 | what does the release button do? | 09:18 |
| ali1234 | what is the difference between releasing and publishing? | 09:18 |
| Chipaca | ali1234: if my memory serves, the release button takes you to a page where you choose which channels to publish it to | 09:19 |
| ali1234 | oh | 09:20 |
| ali1234 | so it has a terrible name | 09:20 |
| Chipaca | ali1234: the button? | 09:21 |
| ali1234 | and it should just say "edit channels" | 09:21 |
| Chipaca | ali1234: you don't edit channels with it though | 09:21 |
| ali1234 | really? | 09:21 |
| Chipaca | ali1234: editing a channel means changing the channel itself | 09:21 |
| ali1234 | why does it show a form labelled channels: which i can edit then? | 09:21 |
| ali1234 | "Select the channels to release current revision." | 09:21 |
| Chipaca | yep | 09:22 |
| ali1234 | no, you mean publish | 09:22 |
| mup | PR snapcraft#1297 closed: sources: validate unknown source-type in yaml <Created by EduardoVega> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1297> | 09:22 |
| ali1234 | "Select the channels to [publish] current revision [in]." | 09:22 |
| Chipaca | ali1234: i'd suggest you open a forum topic about this | 09:22 |
| Chipaca | it's possible the store uses publish and release inconsistently | 09:22 |
| Chipaca | but i don't know; there might be nuance | 09:23 |
| ali1234 | if you have a button with a verb on it i expect clicking it will do that verb | 09:23 |
| Chipaca | but it's definitely not "edit a channel"; it's editing a channel assignment, which seems to be called releasing | 09:23 |
| Chipaca | ali1234: as i say, please open a forum topic | 09:23 |
| Chipaca | unless you're just ranting, that is :-) | 09:23 |
| Chipaca | ranting is fine btw | 09:23 |
| ali1234 | i can rant on the forum if you want | 09:24 |
| Chipaca | ali1234: forum is for constructive, long-term engagement | 09:24 |
| Chipaca | well, long-term in internet time :-p | 09:24 |
| Chipaca | rants are fine here | 09:24 |
| ali1234 | okay. where do i go to just report a list of problems? | 09:24 |
| ali1234 | i am not interested in long term engagement. i will just come back in another 9 months and see if you have fixed all the problems | 09:25 |
| Chipaca | ali1234: the forum is fine to just report a list of problems | 09:25 |
| Chipaca | ali1234: (the 'long-term' side of that kind of post comes from the people going through the list and addressing them) | 09:25 |
| Chipaca | maybe a better term would be 'asynchronous' actually | 09:26 |
| Chipaca | vs irc that is synchronous | 09:27 |
| ali1234 | should i create one topic for each issue? | 09:27 |
| ali1234 | or just make one long rant post? | 09:27 |
| Chipaca | ali1234: just one long one is probably easier for you | 09:27 |
| Chipaca | ali1234: i believe moderators can then split it up | 09:27 |
| ali1234 | yeah but we both know they won't | 09:28 |
| Chipaca | dude | 09:28 |
| ali1234 | someone will come along and address one of the problems (probably by saying "that isn't in scope of the project") and then the rest will be ignored | 09:28 |
| ali1234 | that's what happened yesterday | 09:28 |
| Chipaca | ali1234: where? | 09:28 |
| ali1234 | https://forum.snapcraft.io/t/trying-to-build-sigrok-snap/503 | 09:29 |
| Chipaca | ali1234: that looks like the opposite | 09:30 |
| ali1234 | really? i was told to use launchpad, which addresses exactly one of the four problems i raised | 09:31 |
| Chipaca | it's not being ignored; you even got ev following up a day later | 09:31 |
| Chipaca | which was less than an hour ago | 09:31 |
| ogra_ | Chipaca, mind giving a second thumbs up on https://github.com/snapcore/core/pull/37 ? (trivial changes) | 09:32 |
| mup | PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37> | 09:32 |
| * ogra_ hugs Chipaca | 09:33 | |
| mup | PR core#37 closed: install keyring (LP: #1670475), update pkglists <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/37> | 09:34 |
| Chipaca | ali1234: about the snapcraft.yaml in the root of the repo, I *think* (but am not sure) that you can also make it .snapcraft.yaml, or snap/snapcraft.yaml | 09:35 |
| ali1234 | you can | 09:35 |
| ali1234 | upstream will put it at cross-compile/snap/snapcraft.yaml because that is how their repository is organized | 09:35 |
| juanrubio | Hi, I'm trying to create a snap of my app (https://github.com/tizonia/tizonia-openmax-il) and I'm currently facing problems with pulseaudio. The snap I've created installs correctly in Fedora 25 but it can't access pulseaudio (Access Denied)...is there any good reference or tuturial on how to create snaps that need access to pulseaudio? | 09:36 |
| Chipaca | juanrubio: is it using the pulseaudio interface? | 09:36 |
| morphis | Chipaca: we don't ahve any confinement on Fedora so the interface is useless unless its a seccomp issue | 09:36 |
| morphis | juanrubio: can you give us the exact error message? | 09:37 |
| juanrubio | yes, plugs section contains 'pulseaudio' | 09:37 |
| morphis | juanrubio: is the plug connected? | 09:37 |
| Chipaca | morphis: point | 09:37 |
| juanrubio | the error message is coming from my app | 09:37 |
| * Chipaca goes back to work | 09:37 | |
| morphis | juanrubio: is there an error in dmesg or journalctl? | 09:38 |
| juanrubio | "Access denied" (which comes from pulseaudio's api) | 09:38 |
| juanrubio | i can't seen any errors in journalctl's output | 09:38 |
| morphis | juanrubio: and you're running your app with the same user you're logged into the system | 09:39 |
| juanrubio | morphis: i thought the plug would be automatically connected? | 09:39 |
| juanrubio | yes, same user | 09:40 |
| morphis | juanrubio: is it connected or not? | 09:40 |
| juanrubio | if I connect the plug with 'sudo snap connect tizonia:pulseaudio :pulseaudio' i get the same result | 09:41 |
| Chipaca | juanrubio: can you share the .yaml? | 09:41 |
| Chipaca | oh it's there in tools/snapcraft.yaml | 09:42 |
| juanrubio | yes, in tools | 09:42 |
| juanrubio | I created my snap in Ubuntu 16.04 and Fedora 25 runs on a Virtualbox VM | 09:44 |
| Chipaca | juanrubio: and does it work in ubuntu 16.04? | 09:45 |
| juanrubio | actually, I have not tried it in ubuntu | 09:45 |
| Chipaca | please do | 09:45 |
| juanrubio | ok, let me give it a try in an 16.04 VM i have over here | 09:46 |
| zyga | pstolowski: re | 09:48 |
| zyga | pstolowski: sorry, I was in a call | 09:48 |
| mup | PR snapd#3282 opened: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282> | 09:48 |
| zyga | pstolowski: so the problem is snapctl and golang's network stack that checks if you have ipv6 connectivity/support by creating that socket | 09:49 |
| zyga | pstolowski: as you know on ubuntu & linode we disable ipv6 (as there was some problem with routing, historically) | 09:49 |
| zyga | pstolowski: but I don't think we disable that on debian | 09:49 |
| zyga | pstolowski: we may thus hit a confinement issue where seccomp kills part of snapctl | 09:49 |
| zyga | pstolowski: I think in addition the actual hook, before it tries snapctl, checks something else which on ubuntu is blocked by apparmor | 09:50 |
| zyga | pstolowski: so when the plug (core-support-plug) is disconnected, the hook exits gracefully | 09:50 |
| zyga | juanrubio: hey | 09:52 |
| fgimenez | hi zyga, i've filed this bug https://bugs.launchpad.net/snappy/+bug/1689332 wrt the issue with the 2.25 ubuntu-core snap and the hardcoded snap-confine path | 09:53 |
| mup | Bug #1689332: internal error with any command using ubuntu-core snap on classic <Snappy:New> <https://launchpad.net/bugs/1689332> | 09:53 |
| zyga | juanrubio: intersting, what is your snap doing with audio? just playback or something more? | 09:53 |
| zyga | fgimenez: thank you! I'll assign it to myself | 09:53 |
| pstolowski | zyga, my understanding - after looking at comments from jdstrand and later morphis - is that yes, it's ipv6 reatlated, Jamie recommended a specific policy rule. the problem was fixed but by mistake not included in the 2.24 release, but according to morhpis it's in the new release (https://forum.snapcraft.io/t/tests-broken-in-master/457/8?u=pstolowski) | 09:54 |
| ogra_ | morphis, https://github.com/snapcore/pi3-gadget/pull/6 | 09:54 |
| mup | PR pi3-gadget#6: make pi-bluetooth name more generic <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/6> | 09:54 |
| fgimenez | zyga: great thanks! :) do you think this issue should block the 2.25 sru? | 09:54 |
| zyga | pstolowski: I'm not sure I understand, what do you aim to achieve in the end? | 09:54 |
| mup | Bug #1689332 changed: internal error with any command using ubuntu-core snap on classic <snapd:New> <https://launchpad.net/bugs/1689332> | 09:54 |
| zyga | fgimenez: well, hard to say, it only affects people that are on ubuntu-core (not just core) | 09:55 |
| pstolowski | zyga, and i've just proposed a PR to have a default timeout in case we have a task created by old snapd with no timeout set | 09:55 |
| mup | PR snapcraft#1288 closed: store: collaboration UI for snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1288> | 09:55 |
| juanrubio | zyga: audio playback | 09:55 |
| zyga | fgimenez: I think it is not so critical but perhaps my view is just too optimistic | 09:55 |
| fgimenez | zyga: ok thanks, we can talk later in the meeting | 09:56 |
| zyga | juanrubio: so fedora 25 may have a more recent version of pulseaudio than ubuntu 16.04 but I bet that pulseaudio still supports the older protocol | 09:56 |
| zyga | juanrubio: and even on fedora 26 I saw snaps play audio | 09:56 |
| zyga | juanrubio: could you please open a forum topic for this (on forum.snapcraft.io), perhaps other people are facing the same issue and even if not we can try to help you there | 09:57 |
| zyga | juanrubio: if your snap is public I could try it on my f26 machine | 09:57 |
| zyga | juanrubio: and try to debug it there | 09:57 |
| juanrubio | zyga: these are my first steps with snaps, so I'm sure I'm missing something | 09:57 |
| zyga | juanrubio: does it work on ubuntu? if so, it should work on fedora too | 09:57 |
| fgimenez | zyga: i think there's another issue with https://github.com/snapcore/snapd/pull/3218/files, i'm getting "Bad system call" trying to use systemd-cat from a snap, will file a bug about this too | 09:57 |
| mup | PR snapd#3218: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3218> | 09:57 |
| juanrubio | zyga: I'm currently updating a 16.04 VM that I have here. I will try it out in 16.04 in a few minutes | 09:58 |
| ogra_ | morphis, thx | 09:58 |
| morphis | ogra_: np | 09:58 |
| zyga | fgimenez: in lxc? | 10:04 |
| fgimenez | zyga: nope, on a regular classic vm | 10:04 |
| juanrubio | I'm opening a forum topic for this, which category 'snap' or 'snapcraft'? | 10:05 |
| zyga | hmm | 10:08 |
| zyga | fgimenez: what was the system call? do you have the error message? | 10:08 |
| zyga | juanrubio: snap please | 10:08 |
| fgimenez | zyga: sure, [ 910.074185] audit: type=1326 audit(1494320944.576:31): auid=1000 uid=12345 gid=12345 ses=1 pid=30704 comm="systemd-cat" exe="/usr/bin/systemd-cat" sig=31 arch=c000003e syscall=48 compat=0 ip=0x7fcdee899987 code=0x0 | 10:08 |
| zyga | fgimenez: 48 is "shutdown" | 10:09 |
| zyga | fgimenez: hmm, probably closing some socket | 10:09 |
| morphis | hm, did anyone run into this one with spread already: in test-snapd-tools.channels: extra keys: {'latest/candidate', 'latest/beta'} | 10:09 |
| zyga | fgimenez: where did that fail? was it a specifi test? | 10:09 |
| morphis | that is for tests/main/snap-info | 10:09 |
| fgimenez | morphis: yep on it | 10:09 |
| morphis | fgimenez: great! | 10:10 |
| zyga | morphis: nope, but Chipaca wrote that so I bet he groks he messages | 10:10 |
| Chipaca | where what? | 10:10 |
| * Chipaca reads up | 10:10 | |
| morphis | Chipaca: https://travis-ci.org/snapcore/snapd/builds/230270742?utm_source=github_status&utm_medium=notification | 10:10 |
| fgimenez | zyga: not yet, i was adding it while reviewing the 2.25 changelog https://github.com/snapcore/snapd/compare/master...fgimenez:spread-interfaces-default?expand=1#diff-e2f8bc979b0f080a4b32db7b71057b46R9 | 10:11 |
| Chipaca | morphis: that looks like a snap/snapd version mismatch | 10:11 |
| Chipaca | as in, snapd sending track/channel, snap expecting channel | 10:12 |
| Chipaca | but let me look at it a moment | 10:12 |
| fgimenez | morphis: Chipaca probably related, i just uploaded an updated version of test-snapd-tools and the snap-info test started failing, reverted back to the previous version and keep failing | 10:13 |
| Chipaca | fgimenez: it might be that the test expects it to be only in certain channels | 10:13 |
| Chipaca | and you published it to more of them | 10:13 |
| Chipaca | it'd look like this, also | 10:13 |
| Chipaca | i.e. it used to only be in stable and edge, and now it's also in candidate and beta | 10:14 |
| fgimenez | Chipaca: i tried to keep the same channels, rev 3 was in stable, candidate and beta (as it is now) | 10:14 |
| fgimenez | Chipaca: aha, let me try to remove it from candidate and beta | 10:15 |
| Chipaca | so, yes, the snap-info test expects it only in stable and edge | 10:16 |
| Chipaca | morphis: found the problem :-) | 10:16 |
| Chipaca | ("channels", check, | 10:16 |
| Chipaca | ("latest/stable", matches, verRevNotesRx("-")), | 10:16 |
| Chipaca | ("latest/edge", matches, verRevNotesRx("-")), | 10:16 |
| Chipaca | ), | 10:16 |
| Chipaca | that will fail if the channels key has more entries than those two | 10:17 |
| juanrubio | actually, I said before that journalctl didn't show any messages, but actually i didn't realise that the older messages were at the top.. so yes I see a bunch of errors, not sure I understand much... what should I look for? | 10:18 |
| Chipaca | juanrubio: anything with 'audit' in it | 10:19 |
| morphis | juanrubio: can you paste those somewhere? | 10:19 |
| juanrubio | I've pasted some of it here: https://gist.github.com/juanrubio/d7ed44344ef2e7a659dede5f788d07f5 | 10:22 |
| mup | PR snapd#3280 closed: configstate: return error if patch is invalid <Created by kyrofa> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3280> | 10:22 |
| zyga | permissive=0 is curious, | 10:23 |
| Chipaca | ogra_: remind me, how long does the prepare-device hook take on the bbb, worst case? | 10:23 |
| ogra_ | Chipaca, i havent tested in a while but it should not take long anymore | 10:24 |
| ogra_ | it used to be 10-15min in the wrst times | 10:25 |
| ogra_ | *worst | 10:25 |
| juanrubio | and this are the steps I'm following to install the snap on Fedora 25 : https://gist.github.com/juanrubio/4ca10f5a6468fc12bcbed6bf01a7d8f7 | 10:25 |
| fgimenez | Chipaca: now i begin to rant about the release page too :) do you know if i can unpublish a released revision from a channel somehow? | 10:25 |
| Chipaca | fgimenez: yes, you click on the channels and edit the map as you please | 10:26 |
| ogra_ | fgimenez, i dont think you can "unrelease" but you can release a former version | 10:26 |
| Chipaca | fgimenez: i think i should be able to do it | 10:26 |
| * Chipaca looks | 10:26 | |
| mup | PR snapd#3276 closed: tests: additional setup in docker test for core systems <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3276> | 10:26 |
| morphis | juanrubio: why do you had to do $ mkdir -p ~/snap/tizonia/x1/.config/tizonia ? | 10:26 |
| ogra_ | iirc the store spills an error if you just try to unrelease | 10:27 |
| morphis | juanrubio: was that just because of ~/snap/tizonia/x1/.config missing or did even ~/snap/tizonia/x1/ not exist? | 10:28 |
| fgimenez | Chipaca: releasing a former version leaves the candidate and beta channels in snap-info's output http://paste.ubuntu.com/24542209/ not sure if the test would pass with this? | 10:28 |
| Chipaca | that looks like a bug | 10:30 |
| Chipaca | noise][: are you around? | 10:30 |
| juanrubio | morphis: my app needs this 'tizonia.conf' located in $HOME/.config/tizonia | 10:30 |
| Chipaca | fgimenez: i mean, what looks like a bug is the not being able to remove channels | 10:30 |
| morphis | juanrubio: so ~/snap/tizonia/x1/ was automatically created? | 10:30 |
| Chipaca | maybe it's always been this way but i thought not | 10:30 |
| juanrubio | so I currently copy this manually | 10:31 |
| juanrubio | ~/snap/tizonia/x1 is automatically create | 10:31 |
| juanrubio | ~/snap/tizonia/x1 is automatically created | 10:31 |
| morphis | ok | 10:31 |
| Chipaca | the idea of opening a channel, having a snap in it, and then closing it has existed forever | 10:31 |
| fgimenez | Chipaca: yep i think so, the message from the release page is clear though "Released channels cannot be removed." | 10:33 |
| fgimenez | Chipaca: this fixes the tests http://paste.ubuntu.com/24542214/ should i propose it? | 10:35 |
| ogra_ | right, thats the typüical message | 10:35 |
| Chipaca | fgimenez: if it can wait a bit, i'd rather first determine whether the store is broken in this way | 10:37 |
| Chipaca | or if it's how it should be, in which case yes let's fix the test | 10:37 |
| fgimenez | Chipaca: ok | 10:38 |
| ogra_ | Chipaca, it has always been like this (at least with the web UI) | 10:38 |
| Chipaca | fgimenez: if determining this takes more than an hour, let's fix the tests | 10:38 |
| ogra_ | the above is the message you get when unticking the channel checkbox ... but ticking it on an older version will override and release that version instead | 10:39 |
| fgimenez | Chipaca: ok sounds good | 10:39 |
| ali1234 | hmm something wrong with my snap. i now have both meta/gui and setup/gui | 10:45 |
| juanrubio | My 16.04 is taking a bit long to update. I've uploaded the snap package to this location, in case someone might want to give it a try on Fedora 25 or 26: http://www.juanrubio.me/tizonia/tizonia_0.7.0_amd64.snap | 10:45 |
| ali1234 | actually it looks like it dumped everything from the source repo into the snap | 10:45 |
| zyga | pstolowski: hey, I read https://github.com/snapcore/snapd/pull/3282/files and it looks OK but I recall you said it didn't work, do I remember that correctly? | 10:46 |
| mup | PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282> | 10:46 |
| pstolowski | zyga, I said that, yes, but later I figured out (correct me if I'm wrong) that the test I was using in qemu re-execs into new snapd from core image, so I wasn't really testing my change at that time | 10:50 |
| zyga | pstolowski: I think you were, because the "new" snapd was the one from the package | 10:51 |
| zyga | pstolowski: and the package is built | 10:51 |
| zyga | pstolowski: I mean we re-write the core snap | 10:51 |
| Chipaca | juanrubio: getting a 404 | 10:51 |
| Chipaca | juanrubio: ah now it worked | 10:52 |
| fgimenez | Chipaca: anyway, something strange has happened with test-snapd-tools, it seems that beta and candidate have been used since rev 1 http://paste.ubuntu.com/24542284/ (i actually checked the channels used by rev 3 before releasing rev 6, and those included candidate and beta), how was snap-info test passing before? | 10:53 |
| juanrubio | I've created a forum topic: https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25/519 | 10:53 |
| Chipaca | juanrubio: what do i do to run it? | 10:54 |
| * Chipaca knows nothing about tizonia | 10:54 | |
| Chipaca | fgimenez: ¯\_(ツ)_/¯ | 10:54 |
| Chipaca | fgimenez: let's see what facu says | 10:55 |
| ogra_ | fgimenez, the pi2-kernel in edge is pretty outdated, i'll sync the newer one from beta into it (runs fine here, just FYI in case any tests start to misbehave in edge) | 10:56 |
| fgimenez | ogra_: ok thanks! i'll give it i try | 10:59 |
| pstolowski | zyga, hmm.. ok, i'm confused. i understand what you're saying, just not sure about my findings anymore. I could manually kill -9 the hanging configure script and this is what we do in hookmgr. | 11:00 |
| * Chipaca hugs Facu | 11:02 | |
| Chipaca | juanrubio: the help output for tizonia talks about ~/.config/tizonia/tizonia.conf, which is wrong | 11:02 |
| zyga | pstolowski: I could try your branch and experiment | 11:02 |
| ogra_ | morphis, hmm, who owns the wifi-ap snap ? seems i cant run the setup wizard anymore ... http://paste.ubuntu.com/24542320/ | 11:03 |
| juanrubio | Chipaca: I was using it with my Spotify account, but the pulseaudio problem should be seen while trying to play a local mp3 file | 11:03 |
| juanrubio | Chipaca: why do you say the help output is wrong? | 11:03 |
| morphis | ogra_: we do | 11:04 |
| Chipaca | juanrubio: because a snap won't be able to read ~/.config/tizonia/tizonia.conf | 11:04 |
| ogra_ | /find nikc "we" | 11:04 |
| ogra_ | *nick | 11:04 |
| ogra_ | :P | 11:04 |
| Chipaca | juanrubio: apps usually set XDG_CONFIG_DIR (or whatever it was) to something inside ~/snap/ | 11:04 |
| morphis | ogra_: you ping'ed the right one :-) | 11:04 |
| pstolowski | zyga, feel free to if you have a few moments | 11:04 |
| morphis | ogra_: which syscalls are denied? | 11:04 |
| ogra_ | morphis, werll, seems "socket" | 11:04 |
| juanrubio | Chipaca: right now I am only concerned about making it work on Fedora as a test, will deal with those other things later | 11:05 |
| morphis | ogra_: are all plugs connected? | 11:05 |
| Chipaca | XDG_CONFIG_HOME, actually | 11:05 |
| Chipaca | juanrubio: ok fair enough | 11:05 |
| ogra_ | that worked before i reinstalled the image ... all auto-connect ones are | 11:05 |
| Chipaca | juanrubio: fedora doesn't have apparmor confinement so it's less picky :-) | 11:05 |
| morphis | ogra_: can you paste $ snap interfaces wifi-ap | 11:05 |
| Chipaca | juanrubio: another question, why do you use the alsa plug? | 11:05 |
| ogra_ | morphis, http://paste.ubuntu.com/24542331/ | 11:06 |
| Chipaca | juanrubio: and yet another question, how do i play a local mp3 :-) | 11:06 |
| juanrubio | Chipaca: tizonia can render audio with alsa and pulseaudio | 11:06 |
| ogra_ | morphis, and i'm only calling "sudo wifi-ap.setup-wizard" | 11:06 |
| ogra_ | nothing fancy | 11:06 |
| morphis | but that will talk with the service over a local socket | 11:07 |
| juanrubio | you could play an mp3 like : tizonia my-mp3.mp3 | 11:07 |
| Chipaca | juanrubio: ok. Just note that pulseaudio is connected by default, but alsa isn't (because it lets you do nasty things) | 11:07 |
| morphis | ogra_: hm | 11:07 |
| ogra_ | morphis, well, whatever it does ... it worked 100 times for me before ... | 11:07 |
| Chipaca | juanrubio: all it ever does is complain about a missing tizonia.conf | 11:07 |
| ogra_ | (probably only 87 ... i'm exaggerating ;) ) | 11:07 |
| morphis | ogra_: can you check if the socket syscall is in the seccomp profile? | 11:08 |
| juanrubio | Chipaca: yes, please go to my post on snapcraft.io.. I've posted the files tizonia.conf and .log4crc | 11:08 |
| juanrubio | https://forum.snapcraft.io/t/pulseaudio-access-denied-accessing-pulseaudio-for-audio-playback-in-fedora-25/519 | 11:09 |
| Chipaca | juanrubio: wait, it doesn't work in --devmode either? | 11:09 |
| * zyga spends a moment on improving some tests | 11:09 | |
| zyga | pstolowski: I'll check your branch just after that | 11:10 |
| ogra_ | morphis, looks fine to me http://paste.ubuntu.com/24542345/ | 11:10 |
| Chipaca | juanrubio: anyway, thanks for those files, looking | 11:10 |
| juanrubio | Chipaca: thanks for your time | 11:11 |
| morphis | ogra_: yeah .. | 11:11 |
| morphis | ogra_: which snapd version are you running? | 11:11 |
| ogra_ | ogra@pi3:~$ snap version | 11:12 |
| ogra_ | snap 2.25+201705082317.git.3ff5a56~ubuntu16.04.1 | 11:12 |
| ogra_ | snapd 2.25+201705082317.git.3ff5a56~ubuntu16.04.1 | 11:12 |
| ogra_ | series 16 | 11:12 |
| ogra_ | kernel 4.4.0-1051-raspi2 | 11:12 |
| morphis | so edge | 11:12 |
| morphis | can you try with beta? | 11:12 |
| ogra_ | edge ... from 2h ago or so | 11:12 |
| ogra_ | refreshing ... | 11:12 |
| morphis | I fear that the seccomp arg filtering jdstrand landed recently might be the problem here | 11:12 |
| ogra_ | well, see line 525 of the profile paste ... | 11:13 |
| ogra_ | "# FIXME: remove this after LP: #1446748 is implemented" | 11:13 |
| zyga | offtopic, I'd *love* to merge https://github.com/snapcore/snapd/pull/3026 | 11:13 |
| mup | Bug #1446748: implement seccomp filtering by argument <application-confinement> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1446748> | 11:13 |
| mup | PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026> | 11:13 |
| Chipaca | juanrubio: tizonia dies with "Unable to verify the component list." (and leaves the terminal in a bad state) | 11:13 |
| morphis | ogra_: hm | 11:13 |
| morphis | ogra_: lets verify first if this a regression | 11:14 |
| Chipaca | fgimenez: btw did 'snapcraft close' work? | 11:14 |
| ogra_ | i wonder if all snaps in the store that use this workaround have to be updated in the store | 11:14 |
| ogra_ | morphis, yeah ... rollback to beta works | 11:14 |
| morphis | ogra_: ok, then we have a regression, can you open a bug about that? | 11:15 |
| ogra_ | yep | 11:15 |
| morphis | ogra_: that is then a blocker for 2.25 | 11:15 |
| zyga | pstolowski, Chipaca: https://github.com/snapcore/snapd/pull/3283 | 11:17 |
| mup | PR snapd#3283: overlord/hookstate: remove unused Context.timeout <Created by zyga> <https://github.com/snapcore/snapd/pull/3283> | 11:17 |
| mup | PR snapd#3283 opened: overlord/hookstate: remove unused Context.timeout <Created by zyga> <https://github.com/snapcore/snapd/pull/3283> | 11:17 |
| Chipaca | yuss | 11:17 |
| ogra_ | morphis, well ... | 11:18 |
| ogra_ | ogra@pi3:~$ snap version | 11:18 |
| ogra_ | snap 2.25 | 11:18 |
| ogra_ | snapd 2.25 | 11:18 |
| ogra_ | series 16 | 11:18 |
| ogra_ | kernel 4.4.0-1051-raspi2 | 11:18 |
| juanrubio | Chipaca: you need to install tizonia.conf as posted in the forum topic | 11:18 |
| Chipaca | juanrubio: done that | 11:18 |
| ogra_ | morphis, i'd rather say it blocks 2.26 :) | 11:18 |
| Chipaca | juanrubio: until I did, all tizonia did was complain about that missing file | 11:18 |
| juanrubio | Chipaca: ok, then could you please check that you have this in the config file? 'component-paths = /var/lib/snapd/snap/tizonia/x1/lib/tizonia0-plugins12;' | 11:19 |
| Chipaca | uhhh | 11:19 |
| mup | PR snapcraft#1302 opened: lxd: Mount project folder via sshfs in case of a remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1302> | 11:19 |
| Chipaca | juanrubio: that's not right | 11:19 |
| juanrubio | aha? | 11:19 |
| Chipaca | juanrubio: that's the path from "outside" the snap | 11:20 |
| Chipaca | juanrubio: (and only when that is where the snaps are installed) | 11:20 |
| Chipaca | in ubuntu, snaps are installed in /snap/ | 11:20 |
| Chipaca | and not /var/lib/snapd/snap | 11:20 |
| fgimenez | Chipaca: looks like it went fine http://paste.ubuntu.com/24542381/ running the test now | 11:20 |
| Chipaca | juanrubio: but in any case, inside the snap, it's always /snap/ | 11:20 |
| juanrubio | Chipaca: I see | 11:20 |
| Chipaca | editing the file now | 11:20 |
| morphis | ogra_: ah right, getting confused ... | 11:21 |
| Chipaca | juanrubio: also, you have a /home/joni in that file | 11:21 |
| juanrubio | Chipaca: with that path, tizonia can locate the plugins (decoders, sources, renderers etc) and the proceed to do some playback | 11:21 |
| Chipaca | juanrubio: do you know if tizonia supports using environment variables in its config? | 11:21 |
| Chipaca | juanrubio: what is the 'resource manager database'? | 11:22 |
| ogra_ | Bug #1689536 | 11:23 |
| mup | Bug #1689536: snapd 2.25+201705082317.git.3ff5a56~ubuntu16.04.1 breaks seccomp handling <snapd:New> <https://launchpad.net/bugs/1689536> | 11:23 |
| ogra_ | jdstrand, morphis ^^^ | 11:23 |
| juanrubio | Chipaca: uhm.. let me see, it is a db used to figure out what plugins can be accessed by tizonia in some cases, but not relevant here | 11:24 |
| Chipaca | yeah, noticed it's got enabled=false | 11:24 |
| juanrubio | correct | 11:24 |
| Chipaca | juanrubio: from a quick check it looks like tizonia doesn't support using environment variables in its config (but i haven't read the code to make sure) | 11:24 |
| Chipaca | juanrubio: so you're going to have to generate the file (e.g. from a wrapper) | 11:24 |
| juanrubio | Chipaca: that is correct, env vars are not supported right now | 11:25 |
| Chipaca | juanrubio: but, on ubuntu, when not installed with devmode, you get | 11:25 |
| Chipaca | juanrubio: [196128.136517] audit: type=1400 audit(1494329031.902:417): apparmor="DENIED" operation="connect" profile="snap.tizonia.tizonia" pid=22296 comm="audio_renderer" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined" | 11:25 |
| Chipaca | why is a music app trying to talk to X? | 11:26 |
| Chipaca | (a music app that doesn't ask for the x11 interface, as well) | 11:26 |
| zyga | Chipaca: it may talk to X to get the pulseaudio auth cookie | 11:27 |
| zyga | Chipaca: (beacause) | 11:27 |
| juanrubio | Chipaca: in my Fedora VM, I've got to the point where I can load the spotify plugin, and the pulseaudio plugin. Spotify works but audio rendering fails with pulseaudio access denied error | 11:27 |
| zyga | Chipaca: ah | 11:27 |
| zyga | juanrubio: which desktop environment are you using? | 11:27 |
| zyga | I think that the pulse cookie is in /tmp | 11:27 |
| juanrubio | awesome wm | 11:27 |
| zyga | morphis: we may need | 11:27 |
| zyga | juanrubio: here you go | 11:27 |
| zyga | this is why it doesn't work, | 11:28 |
| zyga | morphis: we may need someting quite like xauthority support for puslseaudio cookie | 11:28 |
| juanrubio | zyga: are you saying it would work on Gnome desktop? | 11:28 |
| zyga | juanrubio: yes | 11:28 |
| zyga | juanrubio: because it depends on how you initialize pulseaudio in the system | 11:28 |
| zyga | juanrubio: and some peculiar ways snapd works | 11:28 |
| juanrubio | zyga: let me log into gnome | 11:29 |
| juanrubio | zyga: heyy... it works! | 11:30 |
| juanrubio | really nice! | 11:30 |
| zyga | juanrubio: yes, it's really annoying as well but at least we know what we're standing on :) | 11:31 |
| juanrubio | zyga: so, is there anything I can do to workaround the cookie issue? | 11:31 |
| zyga | juanrubio: and it's a bug in snapd | 11:31 |
| zyga | juanrubio: just one that doesn't affect the default configuration for many | 11:31 |
| zyga | juanrubio: so we didn't bump into it yet | 11:31 |
| zyga | juanrubio: but it's just a bug, it'll get fixed | 11:32 |
| zyga | juanrubio: no, it's nothing you can fix | 11:32 |
| zyga | juanrubio: (in a snap) | 11:32 |
| juanrubio | zyga: is there a launchpad issue? | 11:32 |
| zyga | juanrubio: it's something that needs to be fixed in snapd/snap-confine pair | 11:32 |
| zyga | juanrubio: I don't think so, please file a bug about it | 11:32 |
| zyga | morphis: can you look at that bug please? | 11:32 |
| morphis | zyga: really? | 11:32 |
| zyga | morphis: ? | 11:32 |
| morphis | why are those things in /tmp .. | 11:32 |
| zyga | morphis: there are different ways to auth with pulse | 11:33 |
| fgimenez | Chipaca: yes, the snap-info test is passing now | 11:33 |
| fgimenez | morphis: ^ | 11:33 |
| zyga | morphis: and I think on ubuntu we use the cookie attached to the root window | 11:33 |
| morphis | zyga: I know but /run exists to store those things | 11:33 |
| zyga | morphis: but then if you for whatever reason cannot get that cookie | 11:33 |
| zyga | morphis: auth looks for the next thing | 11:33 |
| zyga | morphis: and I think that's somewhere inaccesislbe, maybe run but maybe not (perhaps $HOME somewhere) | 11:33 |
| zyga | morphis: I don't know | 11:34 |
| Chipaca | morphis: the x11 socket is in /tmp, not in /run, for instance | 11:34 |
| morphis | yeah, I know what pulse does pretty well, caused my quite some headache to get that right for U-Core and the pulseaudio snap | 11:34 |
| Chipaca | and the xim socket | 11:34 |
| fgimenez | Chipaca: however this is superconfusing, from the test-snapd-tools page in the store i can see that rev 6 is released to beta, candidate and stable | 11:34 |
| zyga | oh drat | 11:34 |
| zyga | my wife is killing me with irresistible smell downstairs :) | 11:34 |
| * zyga runs, bbl :) | 11:34 | |
| Chipaca | zyga: sometimes i wish i had your problems | 11:35 |
| Chipaca | :-) | 11:35 |
| juanrubio | Chipaca: I don't mind creating the defect, although you might be able to record the details more accurately than me... | 11:36 |
| morphis | zyga, Chipaca: how are we sharing the X11 socket from /tmp with the snaps today? | 11:37 |
| morphis | zyga: normal location of the cookie on a desktop is $HOME/.config/pulse/cookie | 11:39 |
| Chipaca | morphis: I think all we do is copy .Xauthority to /run/user/etc | 11:40 |
| morphis | Chipaca: right, that is what I added recently | 11:40 |
| Chipaca | ah :-) | 11:40 |
| morphis | however for the pulse cookie that gets harder | 11:41 |
| morphis | juanrubio: can you file a bug about this on https://bugs.launchpad.net/snapd/+filebug , I will take it from there | 11:42 |
| juanrubio | morphis: filed it here -> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1689539 | 11:44 |
| mup | Bug #1689539: Pulseaudio "Access Denied" on Fedora 25 with Awesome WM as desktop environment <snapd (Ubuntu):New> <https://launchpad.net/bugs/1689539> | 11:44 |
| morphis | juanrubio: thanks | 11:44 |
| juanrubio | thanks guys, that was very helpful... my wife also has some smells dowstairs! | 11:45 |
| ogra_ | morphis, erm ... isnt the pulse cookie in $HOME usually ? | 11:55 |
| morphis | ogra_: yes | 11:56 |
| morphis | .config/pulse/cookie | 11:56 |
| morphis | or its set via X11 | 11:56 |
| ogra_ | right | 11:56 |
| ogra_ | and the pulse interface should give you access to ~/.config/pulse afaik | 11:56 |
| ogra_ | yeah ... owner @{HOME}/.config/pulse/cookie rk, | 11:57 |
| morphis | ogra_: right, but in this case it seems to be different, will look into that | 11:58 |
| Chipaca | morphis: ogra_: some apps may just go to the x11 root window by default | 12:02 |
| Chipaca | dunno | 12:02 |
| ogra_ | well, i see libboost in the error logs | 12:03 |
| ogra_ | and looking at the snapcraft.yaml it seems to pull in a good bunnch of other stuff https://github.com/tizonia/tizonia-openmax-il/blob/master/tools/snapcraft.yaml | 12:04 |
| ogra_ | dbus-x11 | 12:04 |
| ogra_ | there you go .... | 12:04 |
| ogra_ | that pulls in athe whole x11 stack through deps | 12:05 |
| ogra_ | (at least the libs) | 12:05 |
| ogra_ | and the app uses mpris as well | 12:06 |
| ogra_ | so it is actually deeply hooked into X11 and should use the x11 interface | 12:07 |
| Chipaca | mpris and dbus probably means it needs the unity7 one (for lack of a better match) | 12:14 |
| zyga | Chipaca: I always joke that my wife and I should switch roles; we'd get thinner instantly :) | 12:19 |
| zyga | morphis: no idea | 12:20 |
| zyga | morphis: there must be another way to connect | 12:20 |
| morphis | zyga: to connect to pulse you need the socket and the cookie | 12:21 |
| zyga | morphis: I must say that the modern desktop stack is pretty complex | 12:21 |
| morphis | and the cookie comes either from the fs or from X11 | 12:21 |
| morphis | it is | 12:21 |
| morphis | zyga: I will look into this problem | 12:21 |
| zyga | morphis: thank you! | 12:21 |
| zyga | morphis: I have no idea but I'd love to help if you figure out what needs doing | 12:21 |
| morphis | zyga: will ping you | 12:30 |
| jdstrand | ogra_: don't worry about line 525. it is referring to socketcall. that is something different | 12:30 |
| jdstrand | ogra_: I also answered in the bug | 12:30 |
| ogra_ | jdstrand, ok ... well, it dies on "socket" | 12:30 |
| ogra_ | ok | 12:31 |
| * jdstrand is wondering if there is an AF_ that this kernel has that isn't in generic | 12:31 | |
| zyga | jdstrand: you mean custom address family? | 12:32 |
| jdstrand | if it was netlink, I would expect needing a 'network netlink' apparmor rule and I checked all those (I could've missed something) | 12:32 |
| ogra_ | jdstrand, well, the kernel doesnt seem to matter, it is the core that breaks it | 12:32 |
| jdstrand | zyga: yes | 12:32 |
| jdstrand | ogra_: I understand that | 12:33 |
| ogra_ | ah, k | 12:33 |
| jdstrand | ogra_: oh, for the strace. add 'socket' to the seccomp policy, then strace and show me all the socket calls | 12:33 |
| jdstrand | if you don't allow it in the policy there won't be anything to trace :) | 12:34 |
| ogra_ | do we have strace in the toolbelt snap ? | 12:34 |
| zyga | ogra_: no | 12:34 |
| ogra_ | bah | 12:34 |
| zyga | ogra_: it's just busybox | 12:34 |
| zyga | ogra_: but I could add it | 12:34 |
| ogra_ | yeah, that might make sense given how often we use it | 12:35 |
| jdstrand | ogra_: https://code.launchpad.net/~jdstrand/+git/debug-tools | 12:35 |
| jdstrand | ogra_: if using that snap. install it then run 'debug-tools' and it will tell you how to invoke | 12:39 |
| jdstrand | ogra_: though with strace, you literally can scp the binary and it will work | 12:39 |
| Chipaca | these days maybe not so well though | 12:40 |
| Chipaca | because of go being hard to strace | 12:40 |
| jdstrand | /path/to/strace -o ./trace -D -f -vv -e '!select <thing to strace> | 12:40 |
| jdstrand | whoops | 12:41 |
| jdstrand | /path/to/strace -o ./trace -D -f -vv -e '!select' <thing to strace> | 12:41 |
| jdstrand | that works pretty well | 12:41 |
| Chipaca | pstolowski: https://travis-ci.org/snapcore/snapd/builds/230295130#L3172 | 12:41 |
| Chipaca | jdstrand: i'll grep for this the next time i need it, thanks :-) | 12:42 |
| Chipaca | pstolowski: is that something we should worry about? | 12:42 |
| pstolowski | looking | 12:43 |
| pedronis | pstolowski: hi, is snapd#3282 something we want soon/for 2.26? I answered something there | 12:43 |
| mup | PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282> | 12:43 |
| mup | PR snapd#3283 closed: overlord/hookstate: remove unused Context.timeout <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3283> | 12:46 |
| pstolowski | pedronis, I think it would be nice to have but not critical | 12:46 |
| pstolowski | Chipaca, econnreset test failure, is that what you mean? | 12:46 |
| Chipaca | pstolowski: yep | 12:47 |
| Chipaca | pstolowski: the link should've taken you to the line, but maybe it fails with the slow async loading of the log | 12:47 |
| pstolowski | Chipaca, it showed me the last summary line, yes, just wasn't sure | 12:47 |
| pstolowski | Chipaca, this test had some when Michael introduced it and I remember he fixed it... or so he thought ;) | 12:48 |
| pstolowski | s/some/some flakiness/ | 12:48 |
| Chipaca | pstolowski: so i should just re-run it? | 12:58 |
| Chipaca | pstolowski: actually rather than re-run it, as it seems i was wrong about device-hook, could you revert that edit? | 12:59 |
| pstolowski | Chipaca, re-run, yes, I'd say so. you mean you were wrong in the light of what pedronis said? | 13:00 |
| Chipaca | yeh | 13:00 |
| zyga | pstolowski: I have something for you to review | 13:01 |
| zyga | https://github.com/snapcore/snapd/pull/3284 | 13:01 |
| mup | PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284> | 13:01 |
| mup | PR snapd#3284 opened: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284> | 13:01 |
| zyga | Chipaca: ^^ you too as you have better go insight than I did | 13:01 |
| zyga | Chipaca: (I wanted to do this without introducing reflection in non-test code) | 13:01 |
| zyga | Chipaca: and without making definers public | 13:01 |
| morphis | fgimenez: do you got the CI fixed? | 13:01 |
| zyga | s/did/do/ ;) | 13:01 |
| ogra_ | zyga, stop slacking ... standup ;) | 13:01 |
| fgimenez | morphis: yes, should be working now | 13:01 |
| zyga | this is an old branch that I wanted to resurrect | 13:01 |
| zyga | ogra_: oh | 13:01 |
| zyga | sorry | 13:01 |
| niemeyer | zyga, fgimenez : stand up? | 13:02 |
| ogra_ | :) | 13:02 |
| zyga | coming | 13:02 |
| jdstrand | ogra_: let me try on my pi2 | 13:03 |
| morphis | fgimenez: thanks | 13:03 |
| ogra_ | jdstrand, not sure that works since you dont have a wlan device on it | 13:07 |
| jdstrand | fgimenez: re /dev/meminfo> it is allowed by the base abstraction, so, yes, it will be allowed everywhere | 13:07 |
| ogra_ | jdstrand, i'll collect the info after our team standup ... | 13:07 |
| jdstrand | I actually have a usb wlan I can plug in | 13:07 |
| jdstrand | the device isn't rebooting into 1876 though... | 13:08 |
| ogra_ | you could try (if that can work in ap mode) | 13:08 |
| jdstrand | 'Setup snap "core" (1876) security profiles (phase 2)' | 13:08 |
| * jdstrand taps fingers | 13:08 | |
| ogra_ | ctrl-C if you dont want to wait for the auto reboot | 13:08 |
| ogra_ | and just sudo reboot | 13:08 |
| jdstrand | ah | 13:09 |
| ogra_ | (it wont return) | 13:09 |
| jdstrand | ok | 13:09 |
| jdstrand | that seems odd, but... unblocked | 13:09 |
| ogra_ | yes, is odd | 13:09 |
| fgimenez | jdstrand: great thanks, then do we need this rule https://github.com/snapcore/snapd/blob/master/interfaces/builtin/system_observe.go#L53 ? | 13:10 |
| jdstrand | fgimenez: no, we don't, ar it should at least be commented | 13:10 |
| jdstrand | or* | 13:10 |
| jdstrand | fgimenez: I took a note to do one of those things | 13:10 |
| fgimenez | jdstrand: ok thank you! :) | 13:11 |
| jdstrand | ogra_: fyi, not having the wlan is enough to trigger it | 13:14 |
| * jdstrand takes over | 13:14 | |
| ogra_ | ah, nice | 13:16 |
| pedronis | jdstrand: yes, that waiting command was the result of a quick bug fix, we know we have to improve the UX, it's on my todo list for soon | 13:25 |
| Chipaca | hmm | 13:26 |
| pedronis | Chipaca: hmm? | 13:27 |
| Chipaca | niemeyer, fgimenez: i do still see the right reply from the store for snap info | 13:27 |
| Chipaca | so maybe we broke something? | 13:27 |
| pedronis | Chipaca: we switched to use it afaik (2.24 was still using the hack) | 13:27 |
| Chipaca | this is wrt the "^" channels | 13:27 |
| pedronis | so maybe we are using it wrong | 13:27 |
| Chipaca | oh wait let me make sure i'm using the right snap + snapd first :-) | 13:27 |
| pedronis | and didn't notice | 13:28 |
| fgimenez | Chipaca: not sure, this is from 2.25 http://paste.ubuntu.com/24542694/ and this from 2.24.1 http://paste.ubuntu.com/24542709/ 2.25 doesn't show the closed channels | 13:29 |
| Chipaca | fgimenez: right, that means we've got a bug wrt closed channels | 13:29 |
| jdstrand | pedronis: nice! | 13:30 |
| Chipaca | fgimenez: which we've actually written into the tests | 13:30 |
| Chipaca | i wonder how this slipped past me :-) | 13:30 |
| * Chipaca knows how this could slip by | 13:30 | |
| Chipaca | anyway, i'll push a branch for this | 13:31 |
| fgimenez | Chipaca: :) is it on snapd side then? Facu suggested to file it under https://bugs.launchpad.net/snapstore/ | 13:31 |
| pstolowski | Chipaca, reverted prepare-device timeout change | 13:31 |
| Facu | Chipaca, no, wait, which bug you mean? | 13:36 |
| === om26er is now known as om26er1 | ||
| === om26er1 is now known as om26er | ||
| Chipaca | fgimenez: yes, snapd side | 13:37 |
| Chipaca | Facu: what | 13:37 |
| Chipaca | Facu: we've got a bug in the way 'snap info' formats its output | 13:38 |
| Chipaca | Facu: this is not a launchpad bug | 13:38 |
| Facu | Chipaca, it should say (for the fgimenez example) "candidate: closed" (same for beta), right? | 13:38 |
| Facu | (at first I thought something else was broken, then I understood, and I just want you to NOT work twice) | 13:39 |
| Chipaca | Facu: candidate: ^ | 13:42 |
| jdstrand | socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE) | 13:42 |
| jdstrand | ogra_: ^ | 13:42 |
| Chipaca | jdstrand: la que te recontra por las dudas | 13:42 |
| * Chipaca runs | 13:43 | |
| jdstrand | Chipaca, ogra_: fyi, updated strace command for armhf (for grepping backscroll :) -- sudo ./strace -o /tmp/trace -D -f -vv -e '!_newselect,select,clock_gettime' -- /usr/bin/snap run --shell wifi-ap.automatic-setup | 13:43 |
| Chipaca | nice | 13:44 |
| jdstrand | on x86 you need to !select, but on armhf need to also not trace _newselect and clock_gettime otherwise it hangs | 13:44 |
| Facu | Chipaca, no, it should say "candidate: closed" and "beta: closed" (that's why CPI returns "null" for those channels, not "tracking" or something, see Mark's answer to my specific question about this in https://bugs.launchpad.net/snappy/+bug/1628640 | 13:44 |
| mup | Bug #1628640: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Fix Released by facundo> <https://launchpad.net/bugs/1628640> | 13:44 |
| Chipaca | pstolowski: i thought you'd just 'git reset --hard HEAD^ && git push --force', but yours is much more polite | 13:44 |
| pstolowski | Chipaca, yeah, I wasn't sure if github likes rewritten history | 13:45 |
| Chipaca | Facu: oh. Hm. There might be conflicting info here. | 13:46 |
| Facu | Chipaca, HO? | 13:47 |
| jdstrand | ogra_: the simple instructions are that automatic-setup needs to 'plugs: network-bind', but don't do that yet. let me review my notes on NETLINK_ROUTE, maybe I should just add it to network | 13:47 |
| Chipaca | Facu: nah, let me find things | 13:47 |
| jdstrand | ogra_: (which it already plugs) | 13:47 |
| Chipaca | Facu: either my memory plays tricks, or different people have different opinions on this and they need to settle it between themselves before we go off and implement it :-) | 13:47 |
| Facu | Chipaca, no problem! note we modeled server behaviour around that specific Mark's answer, we may need to change stuff if that changes | 13:48 |
| zyga | Chipaca: is the snap-info failure that's affecting PRs something you are on top of now? | 13:50 |
| jdstrand | ogra_: what you could do is add to /var/lib/snapd/seccomp/profiles/snap.wifi-ap.automatic-setup at the end: socket AF_NETLINK - NETLINK_ROUTE | 13:50 |
| Chipaca | zyga: the snap-info failure is resolved | 13:50 |
| jdstrand | ogra_: and let me know if that fixes it for you | 13:50 |
| Chipaca | zyga: it is no longer affecting PRs, since a while before the standup | 13:51 |
| jdstrand | ogra_: you'll have to service snap.wifi-ap.automatic-setup stop, then start | 13:51 |
| jdstrand | if I do that, I don't see the seccomp denial | 13:51 |
| jdstrand | but I don't have the wlan plugged in | 13:52 |
| * jdstrand goes to find it | 13:52 | |
| zyga | Chipaca: aha | 13:53 |
| zyga | Chipaca: thanks! | 13:53 |
| zyga | pstolowski: why are you doing the get/set thing? https://github.com/snapcore/snapd/pull/3282/files#diff-3a26c6cd9ed243bb3b102f2d9589ba30R300 | 13:54 |
| mup | PR snapd#3282: hooks: default timeout <Created by stolowski> <https://github.com/snapcore/snapd/pull/3282> | 13:54 |
| zyga | pstolowski: specifically the set? | 13:54 |
| Chipaca | fgimenez: do we have any test-snapd- snap that is not in stable? | 13:55 |
| jdstrand | ogra_: huh, seems like it worked | 13:55 |
| pstolowski | zyga, ah, good catch, it's unneeded, copy/paste from other test | 13:55 |
| fgimenez | Chipaca: i think so, lately we have been releasing only to edge, let me check | 13:55 |
| jdstrand | ogra_: $ sudo wifi-ap.status | 13:55 |
| jdstrand | ap.active: true | 13:55 |
| Chipaca | Facu: in the "snap and snapcraft ux" doc there's a ^ in 'snapcraft status' (with a comment elsewhere of 'snap info' having the same layout as that) | 13:55 |
| jdstrand | ogra_: ok, so, yes, please test that, and I'll do a little research | 13:56 |
| fgimenez | Chipaca: test-snapd-openvswitch-consumer | 13:56 |
| Chipaca | Facu: where a closed channel that doesn't have a tracking thing shows "-", but closed-but-tracking is "^" | 13:56 |
| Chipaca | fgimenez: thanks! | 13:57 |
| pstolowski | zyga, updated | 13:57 |
| Chipaca | niemeyer: ping, if you're around | 13:58 |
| niemeyer | Chipaca: pongus | 13:58 |
| Facu | Chipaca, can you give me the doc url, please? | 13:58 |
| Chipaca | if you're not around, also ping, but ¯\_(ツ)_/¯ | 13:58 |
| Facu | :) | 13:59 |
| zyga | pstolowski: thank you | 13:59 |
| Chipaca | niemeyer: so i have conflicting specs for 'snap info', one from "make the channel map like 'snapcraft status'", which uses ^ or - to indicate closed channels (depending on whether they're tracking something or not), and a later comment in bug#1628640 that says they should show <channel>: closed | 14:00 |
| Chipaca | bug #1628640 | 14:00 |
| mup | Bug #1628640: Add 'snap info' command showing publisher, channel map <Snappy:Fix Released by chipaca> <Software Center Agent:Fix Released by facundo> <https://launchpad.net/bugs/1628640> | 14:00 |
| jdstrand | ogra_: where is the source code for bin/client? | 14:00 |
| Chipaca | mup, you so confusing with "snapd#foo" and "bug #foo" :-) | 14:00 |
| mup | Chipaca: I really wish I understood what you're trying to do. | 14:00 |
| * zyga goes to take the garbage out | 14:01 | |
| jdstrand | morphis: maybe you know. where is the source code for bin/client in the wifi-ap snap? | 14:01 |
| ogra_ | jdstrand, lp:~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap | 14:01 |
| jdstrand | ah, thanks | 14:01 |
| jdstrand | morphis: nm | 14:01 |
| Chipaca | niemeyer: personally I think the ^/- communicates more than just "closed" | 14:01 |
| Chipaca | and I think there is value in it being similar to 'snapcraft status' | 14:02 |
| Chipaca | niemeyer: (right now we don't do either, because of a bug, which is why i'm bothering you with this :) ) | 14:02 |
| niemeyer | Chipaca: Can we have a forum topic for this? | 14:03 |
| Chipaca | niemeyer: forum topics don't just grow on trees, you know | 14:04 |
| * Chipaca creates | 14:04 | |
| Facu | Chipaca, niemeyer, I personally think that "^/-" is better, that's why I asked Mark specifically about that, and Mark said "<channel>: closed" (in that bug ↑) | 14:04 |
| niemeyer | Chipaca: I know.. that's why I bother people to create them :) | 14:04 |
| Chipaca | Facu: yeah, i'm suspecting that was a miscommunication / thinko | 14:05 |
| Chipaca | Facu: but let's settle it one way or t'other | 14:05 |
| niemeyer | That's exactly the sort of topic we should keep in the forum | 14:05 |
| Facu | Chipaca, for me it's settled, in the bug :) | 14:05 |
| Chipaca | Facu: either way you're good | 14:05 |
| Chipaca | Facu: bug is all my end | 14:05 |
| niemeyer | Let's please move the thread there so we have track record and rationale well kept | 14:05 |
| Chipaca | yep yep | 14:06 |
| Chipaca | on it | 14:06 |
| Facu | Chipaca, not really, the store should not answer "null" for those tracks, otherwise you'd need to start doing algorithms in the client to see if the channels is tracking or nothing is really released into it | 14:06 |
| niemeyer | Facu: Even if the bug isn't in your end, please join the thread with the details you have | 14:06 |
| Chipaca | niemeyer: in our defense all this wandering and wondering comes from before the forum was a thing :-) | 14:06 |
| Facu | Chipaca, the store should say "tracking" for you to present "^" and "null" for "-" | 14:07 |
| Chipaca | Facu: you and your nullable strings | 14:07 |
| Facu | Chipaca, this is what we're doing for snapcraft, anyway, so logic for channel interactions are defined in one place only (server side) | 14:07 |
| Facu | niemeyer, of course | 14:07 |
| Chipaca | now hush, i'm creating a forum topic :-p | 14:07 |
| niemeyer | Chipaca: Yeah, no worries or blame assigned.. just trying to get ourselves (certainly including myself) into the practice of organizing these exchanges | 14:07 |
| Chipaca | niemeyer: none implied either, just explaining how we got here | 14:07 |
| Chipaca | and yes, agreed | 14:08 |
| niemeyer | 👍 | 14:08 |
| zyga | Facu: now that you said it ↑ looks better than ^ | 14:08 |
| Facu | zyga, :) | 14:09 |
| zyga | jdstrand: question about https://github.com/snapcore/snapd/pull/3051 -- did you have a chance to look at the kernel to see if this interface can land; I'm asking to know if I should spend effort trying to get it to be mergable today or should I just look at another PR | 14:12 |
| mup | PR snapd#3051: interfaces: add consoles interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3051> | 14:12 |
| jdstrand | zyga: please look at another PR | 14:13 |
| jdstrand | zyga: this requires extensive investigation to make sure we dtrt | 14:13 |
| jdstrand | and it is behind a lot of other work atm | 14:13 |
| jdstrand | zyga: in fact, please add the blocked tag | 14:13 |
| * jdstrand commented in the pr already that it is in the queue, but behind other things | 14:14 | |
| Chipaca | niemeyer: the more I write in the description of this, the more it feels like a 1-minute conversation with mark would resolve it :-) | 14:15 |
| Chipaca | anyhow, nearly done | 14:15 |
| niemeyer | Chipaca: Mark is the forum too.. | 14:17 |
| Chipaca | good point! | 14:17 |
| * Chipaca calls him out | 14:17 | |
| bdx | hey everyone, how can I list the available config params for a snap? | 14:22 |
| Chipaca | Facu: niemeyer: https://forum.snapcraft.io/t/snap-info-channel-map-format/521 | 14:22 |
| niemeyer | Thanks! | 14:22 |
| Chipaca | bdx: I don't think you can | 14:23 |
| ogra_ | well, you can dig into the hook script usually | 14:23 |
| Chipaca | bdx: not sure if that's intentional or not-gotten-around-to-it yet | 14:23 |
| Facu | Chipaca, gracias | 14:23 |
| Chipaca | Facu: niemeyer: de nada caez's | 14:23 |
| ogra_ | (unless the package provides some binary config hook) | 14:23 |
| Chipaca | caez'ns* | 14:23 |
| Chipaca | zyga: ↑ vs ^ TBD (when we have something that knows whether it's writing to something UTF-8 friendly or not | 14:24 |
| zyga | jdstrand: OK | 14:24 |
| Chipaca | ) | 14:24 |
| zyga | will do | 14:24 |
| Chipaca | niemeyer: is it intentional that 'snap get' doesn't let you list all config keys? | 14:25 |
| mup | PR snapcraft#1303 opened: kernel plugin: slightly improve the messaging of check_config() <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1303> | 14:25 |
| Chipaca | niemeyer: e.g. 'snap get foo' dumping the whole config (vs 'snap get foo bar' just getting bar) | 14:25 |
| Chipaca | also why does snap get return json instead of yaml /o\ | 14:26 |
| Chipaca | so many questions :-) | 14:26 |
| pedronis | Chipaca: that would be part of having a schema, at the moment we could only list the currently set ones | 14:34 |
| Chipaca | pedronis: https://forum.snapcraft.io/t/snap-get-config-dump/522/1 | 14:34 |
| Chipaca | :-) | 14:34 |
| pedronis | that's not an official answer, you need niemeyer for that | 14:34 |
| Chipaca | pedronis: 🐔 | 14:35 |
| Chipaca | :-) | 14:35 |
| ogra_ | ogra@pi3:~$ snap get core system | 14:35 |
| ogra_ | error: snap "core" has no "system" configuration option | 14:35 |
| ogra_ | ogra@pi3:~$ snap set core system.power-key-action=halt | 14:35 |
| ogra_ | ogra@pi3:~$ snap get core system | 14:35 |
| ogra_ | { | 14:35 |
| ogra_ | "power-key-action": "halt" | 14:35 |
| ogra_ | } | 14:35 |
| ogra_ | the error is also definitely a lie | 14:36 |
| ogra_ | (i guess adding "set" at the end of the error text would be enough though) | 14:36 |
| Chipaca | pedronis: i think getting the set ones would be fine, at least until we have schemas (if a snap cares about this, all they need to do is set the defaults on first config call) | 14:39 |
| niemeyer | Chipaca: I feel like a broken record, but can you open a forum topic to discuss those points? | 14:45 |
| ogra_ | write an IRC macro! | 14:46 |
| Chipaca | niemeyer: way ahead of you dude | 14:46 |
| ogra_ | ;) | 14:46 |
| Chipaca | niemeyer: in fact you already replied to one of them | 14:46 |
| om26er | niemeyer, I tried to subscribe to snapcraft mailing list a few days ago, it said to be waiting for moderation from you. Can you please add me ? | 14:46 |
| niemeyer | Chipaca: So are you just trying to confuse me? :P | 14:46 |
| Chipaca | niemeyer: which makes me think you've been using the wrong flask to top up your mate | 14:47 |
| niemeyer | om26er: Heya | 14:47 |
| Chipaca | niemeyer: :) | 14:47 |
| niemeyer | om26er: Per the note at the front of the subscription page, we've integrated the mailing list into the forum | 14:47 |
| Chipaca | niemeyer: i said those things on irc, then created the topics; i think you just read them here later | 14:47 |
| niemeyer | Chipaca: You win | 14:47 |
| niemeyer | :) | 14:47 |
| * Chipaca takes the rest of the day off to celebrate | 14:48 | |
| niemeyer | om26er: So all conversations previously in the list are now landing directly into the forum | 14:48 |
| niemeyer | om26er: You can still use it via email, if that's your preference | 14:48 |
| niemeyer | om26er: https://forum.snapcraft.io | 14:48 |
| om26er | niemeyer, interesting, will make finding old conversations easier. | 14:48 |
| niemeyer | om26er: Yeah, quite a few things get nicer | 14:49 |
| * om26er creates a new account. | 14:49 | |
| ogra_ | and if you insist in email, you can actually use the email frontend to the forum ;) | 14:50 |
| Chipaca | niemeyer: http://pastebin.ubuntu.com/24543228/ OK? | 14:54 |
| Chipaca | zyga: ^ | 14:54 |
| Chipaca | or should i say zyga: 👆 | 14:54 |
| Chipaca | (i'm only kidding about the 👆; changed it back to ^ already) | 14:55 |
| niemeyer | LOL | 14:55 |
| om26er | are the release announcements also made on the forum now ? | 14:55 |
| niemeyer | @Chipaca To be honest, it does look more clear than ^ :) | 14:55 |
| nothal | niemeyer: No such command! | 14:55 |
| om26er | 1 month and it all looks different already ;) | 14:55 |
| Chipaca | mostly because 👆 is very hard to tell apart from 🖕 | 14:55 |
| niemeyer | @nothal You should ignore it then | 14:55 |
| nothal | niemeyer: No such command! | 14:55 |
| niemeyer | Chipaca: ROTFL | 14:55 |
| niemeyer | Chipaca: Depending on the situation the second one might be more appropriate | 14:56 |
| Chipaca | (but also, technically, because our output path does not know whether it's writing to something that likes UTF-8) | 14:56 |
| niemeyer | Chipaca: Like.. "No stable, 🖕" | 14:56 |
| Chipaca | oooh | 14:56 |
| Chipaca | so one instead of -, the other instead of ^ | 14:56 |
| Chipaca | makes sense | 14:56 |
| Chipaca | super easy to read :-p | 14:56 |
| Chipaca | http://pastebin.ubuntu.com/24543243/ | 14:58 |
| zyga | Chipaca: looking | 14:59 |
| zyga | Chipaca: haha | 15:00 |
| zyga | Chipaca: well.. | 15:00 |
| zyga | Chipaca: if it gracefully degrades in ASCII-only terminals then +1 | 15:00 |
| Chipaca | TODO on this front: | 15:00 |
| zyga | lol | 15:01 |
| Chipaca | 1. patch yaml to not revert to binary mode when it finds printable non-ascii characters | 15:01 |
| zyga | should we display 💩 instead of edge? | 15:01 |
| Chipaca | [...lots more points...] | 15:01 |
| Chipaca | 42. profit! | 15:01 |
| Chipaca | 43. detect UTF-8 console | 15:02 |
| zyga | Chipaca: that's spelled … | 15:02 |
| Chipaca | Facu: wrt having "tracking" in the json from the store, that wouldn't really help us at the moment | 15:03 |
| Chipaca | Facu: ¯\_(ツ)_/¯ | 15:04 |
| Chipaca | Facu: changing subjects: can a snap have a track with no open channels? | 15:04 |
| noise][ | Chipaca: I believe that would be the default state when we first create a track | 15:08 |
| Chipaca | noise][: do you know of any snap with such a track in the store right now? | 15:08 |
| Chipaca | wanting to see what it looks like in 'snap info' | 15:08 |
| noise][ | i don't think so but i could easily add a track for a test snap | 15:08 |
| Chipaca | noise][: otherwise, if it's easy for you to do, can you create an 'ingest' track in the http snap? | 15:09 |
| Chipaca | heh | 15:09 |
| noise][ | yep | 15:09 |
| Chipaca | noise][: yes please | 15:09 |
| Chipaca | just to have a concrete example for discussion | 15:09 |
| noise][ | Chipaca: created | 15:12 |
| niemeyer | Lunch! | 15:12 |
| Chipaca | noise][: looks like a track with no channels does not appear in channels_maps_list | 15:13 |
| Chipaca | noise][: (and that's fine) | 15:13 |
| noise][ | yeah, there's no there there | 15:14 |
| roadmr | ? | 15:14 |
| noise][ | seems reasonable since nothing has ever been released into any channels in the track, there's no channel map or history | 15:14 |
| Chipaca | yup, as i say, that's fine | 15:15 |
| Chipaca | if it had appeared we would've had to decide whether to show it at all on the client, or just hide it | 15:15 |
| Chipaca | so huzzah, less stuff to decide :-) | 15:15 |
| noise][ | \o/ | 15:16 |
| nacc | niemeyer: i wonder if someone from the snap team can update the open bot code to respond to !snap like it does to !info? The latter does a apt query (iirc) or it might look at the archive. It seems like we would like to be able to query the store just as easily from IRC for status. | 15:20 |
| nacc | niemeyer: let me find the linnk | 15:20 |
| nacc | https://launchpad.net/ubuntu-bots | 15:20 |
| nacc | niemeyer: we are starting to see some #ubuntu questions re: snaps and what's available periodically and i have to go run `snap find` myself :) | 15:21 |
| ogra_ | nacc, add a !snapforum command to that just prints "Please add this as a topic to the forum" ... | 15:23 |
| ogra_ | s/to/too/ | 15:23 |
| nacc | ogra_: heh :) | 15:23 |
| mup | Bug #1689578 opened: Lack of shell completion installation support for command line apps <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1689578> | 15:27 |
| nacc | ogra_: yeah, i was going to take a stab at it myself, but was hoping someone with more snap api knowledge could do it if not :) | 15:27 |
| zyga | Chipaca: hey, tests/main/completion often fails on zesty | 15:30 |
| zyga | Chipaca: are you running zesty by any chance? | 15:31 |
| Chipaca | zyga: I am not. When it fails, can I see *how* it fails? | 15:31 |
| Chipaca | zyga: spread, or autosmackagetest? | 15:31 |
| zyga | Chipaca: just run it in qemu in a loop | 15:31 |
| zyga | Chipaca: I think autosmacketest | 15:31 |
| Chipaca | zyga: i'll give it a look later tonight | 15:32 |
| zyga | Chipaca: thanks! | 15:32 |
| Chipaca | meanwhile if you come across it in the wild, point me at the logs | 15:32 |
| zyga | Chipaca: yep | 15:32 |
| zyga | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170509_140006_d459a@/log.gz | 15:32 |
| zyga | times out | 15:32 |
| jdstrand | what's the trick these days with uploading something to the canonical account? | 15:33 |
| jdstrand | s/to the/with the/ | 15:33 |
| zyga | jdstrand: not sure :/ | 15:33 |
| Chipaca | zyga: there are some improvements in tests/completion/lib.exp0 that are not in tests/main/completion/lib.exp0 which might make it better, if it's just timeouts | 15:33 |
| zyga | jdstrand: the aha | 15:33 |
| zyga | I meant | 15:33 |
| Chipaca | jdstrand: i think you get given access per snap | 15:33 |
| zyga | Chipaca: aha | 15:33 |
| jdstrand | ah | 15:33 |
| Chipaca | jdstrand: which snap? | 15:34 |
| jdstrand | ogra_: do you have access to the classic snap? | 15:34 |
| zyga | jdstrand: FYI: I added something that will make sure we're not happily running with old unused interface APIs https://github.com/snapcore/snapd/pull/3284/files#diff-634051b94f9aae657f75a08bc250a139L113 | 15:34 |
| mup | PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284> | 15:34 |
| jdstrand | Chipaca: classic | 15:34 |
| zyga | jdstrand: +1 welcome :) | 15:34 |
| diddledan | jdstrand: if some of us, like me - being non canonical employee, knew the trick then we might be labelled haxx0rs ;-) | 15:34 |
| Chipaca | zyga: that test failure looks like an actual timeout from the store | 15:34 |
| jdstrand | yeah, I forgot it was per snap | 15:34 |
| zyga | Chipaca: another bump in your graph/ | 15:34 |
| diddledan | I've lost count of how many times I've compiled my corebird snap trying to get a custom gtk build to work :-) | 15:35 |
| Chipaca | jdstrand: i've got access to classic | 15:35 |
| jdstrand | Chipaca: this will greatly improve the experience: http://paste.ubuntu.com/24543356/ | 15:36 |
| Chipaca | jdstrand: what's your lp email? | 15:36 |
| jdstrand | Chipaca: jamie at canonical.com | 15:36 |
| Chipaca | jdstrand: you've got mail | 15:36 |
| jdstrand | I'm happy to be added and to do the upload, etc | 15:36 |
| jdstrand | cool thanks | 15:37 |
| Chipaca | jdstrand: shouldn't that have an 'assumes' also? | 15:38 |
| * Chipaca doesn't know | 15:39 | |
| jdstrand | Chipaca: I've seen comments that assumes isn't well tested. I can add it since I'm going to leave the one in beta alone | 15:47 |
| Chipaca | jdstrand: I don't really know :-) | 15:47 |
| Chipaca | jdstrand: ev seems to really like it though | 15:47 |
| jdstrand | the interfaces code has always handled it ok | 15:47 |
| * jdstrand shrugs | 15:47 | |
| mup | Bug #1689578 changed: Lack of shell completion installation support for command line apps <Snapcraft:New> <snapd (Ubuntu):Fix Committed by chipaca> <https://launchpad.net/bugs/1689578> | 15:48 |
| Chipaca | sergiusens: hiya | 15:50 |
| Chipaca | sergiusens: dunno if you saw about the 'completer' thing | 15:50 |
| Chipaca | oh that reminds me | 15:50 |
| sergiusens | Chipaca: yeah, I saw things here and there | 15:50 |
| Chipaca | jdstrand: i haven't tried to push something to the store that has a 'completer' key; will it break? | 15:50 |
| Chipaca | validation i mean | 15:50 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | Chipaca: I wish you just create a PR against snapcraft though :-P | 15:50 |
| Chipaca | sergiusens: do you need anything from me to be able to do support it? | 15:51 |
| Chipaca | sergiusens: i know, but that'll not really be a good use of our time | 15:51 |
| sergiusens | I don't think so, if all we need is to point into a file inside `prime` (aka, the snap), then it is all good | 15:51 |
| sergiusens | when is this released? | 15:51 |
| Chipaca | sergiusens: it's in edge already | 15:52 |
| Chipaca | sergiusens: it'll move to beta tomorrow | 15:52 |
| sergiusens | Chipaca: when to us normals? | 15:52 |
| Chipaca | sergiusens: and it'll take a couple of weeks to reach the normies :-p | 15:52 |
| Chipaca | sergiusens: (modulo QA passing) | 15:52 |
| sergiusens | Chipaca: I can create a PR but not merge to see how it goes, but not going to make it in as we have bad precedent on introducing assumes and environment before it reached users | 15:53 |
| Chipaca | jdstrand: if the validator needs work for this, a bug task on #1689578 might be appropriate | 15:53 |
| mup | Bug #1689578: Lack of shell completion installation support for command line apps <Snapcraft:New> <snapd (Ubuntu):Fix Committed by chipaca> <https://launchpad.net/bugs/1689578> | 15:53 |
| Chipaca | sergiusens: oh, totally | 15:53 |
| sergiusens | if `assumes` were functional, we could use that to proceed in an elegant way | 15:54 |
| zyga | I thought that assumes are functional | 15:54 |
| Chipaca | so did i :-) | 15:54 |
| Chipaca | sergiusens: in any case, I added a snapcraft bug task to the above bug, to track this | 15:55 |
| Chipaca | sergiusens: and i think not implementing it in snapcraft until it's fix-released in snapd is fine | 15:55 |
| zyga | pstolowski: can you review that branch (no-funny-interfaces) and once it lands, merge it into your PR | 15:56 |
| zyga | pstolowski: I'd like to detect the attribute-unaware methods this wayt | 15:56 |
| jdstrand | Chipaca: task added. classic updated. PR for classic submitted | 15:56 |
| sergiusens | zyga: Chipaca functional internally maybe, but where is the documentation and where are the allowed keywords? | 15:56 |
| Chipaca | jdstrand: huzzah | 15:56 |
| pstolowski | zyga, ok | 15:56 |
| Facu | Chipaca, just arrived, was AFK; may I help you with anything or it's solved? | 15:57 |
| jdstrand | now people's logs won't fill up when using classic :) | 15:57 |
| Chipaca | Facu: i don't think there's anything to do at this point in time | 15:57 |
| zyga | sergiusens: we have had a few but I think the idea is to use "assumes snapd25" or similar so that you can know you are using at least certain snapd version | 15:57 |
| ogra_ | jdstrand, i do | 15:58 |
| ogra_ | (i think) | 15:58 |
| diddledan | ooh, getting closer. corebird now fires-up into a gui | 15:58 |
| diddledan | I needed to hack the desktop-gtk3 definition | 15:58 |
| jdstrand | ogra_: ah, thanks, but nm, got it sorted | 15:59 |
| ogra_ | jdstrand, source is at https://github.com/snapcore/classic-snap | 15:59 |
| ogra_ | (in case you didnt know that yet) | 15:59 |
| * jdstrand ods | 15:59 | |
| jdstrand | nods even | 15:59 |
| jdstrand | I already have a PR | 15:59 |
| ogra_ | cool | 16:00 |
| Chipaca | zyga: did you see that we've got kernel debs to try? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819 | 16:02 |
| mup | Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-da-key> <xenial> <Linux:Unknown> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):Incomplete by colin-king> <https://launchpad.net/bugs/1672819> | 16:02 |
| zyga | Chipaca: nope, not yet | 16:03 |
| pstolowski | zyga, +1 with one comment | 16:07 |
| zyga | pstolowski: thank you, looking | 16:07 |
| zyga | pstolowski: thanks! applied :) | 16:09 |
| sergiusens | zyga: great, now I need a map of snapd versions and features provided ;-) | 16:27 |
| Chipaca | sergiusens: {i: awesomeness*i for i in range(...)} | 16:30 |
| mup | PR snapd#3285 opened: interfaces/network: workaround Go's need for NETLINK_ROUTE on ARM with 'net'. LP: #1689536 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3285> | 16:31 |
| zyga | sergiusens: just set to current ^_^ | 16:33 |
| mup | PR snapd#3286 opened: cmd/snap: tweak info channels output <Created by chipaca> <https://github.com/snapcore/snapd/pull/3286> | 16:35 |
| zyga | Chipaca: can you do a 2nd review on trivial, important: https://github.com/snapcore/snapd/pull/3285 | 16:50 |
| mup | PR snapd#3285: interfaces/network: workaround Go's need for NETLINK_ROUTE on ARM with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3285> | 16:50 |
| === kay is now known as Guest11889 | ||
| Chipaca | zyga: ew | 16:52 |
| zyga | Chipaca: another timeout on tab completion https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170509_083625_159d3@/log.gz | 16:54 |
| mup | PR snapd#3281 closed: tests: add test for empty snap name on revert <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3281> | 16:54 |
| zyga | niemeyer: can you please +1 https://github.com/snapcore/snapd/pull/3026 | 16:55 |
| mup | PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026> | 16:55 |
| Chipaca | zyga: and in the same place | 16:55 |
| Chipaca | May 09 08:26:32 autopkgtest snapd[611]: 2017/05/09 08:26:32.144671 daemon.go:176: DEBUG: uid=0;@ GET /v2/find?name=test%2A 5.073657694s 200 | 16:56 |
| Chipaca | zyga: the store takes 5 seconds to reply | 16:56 |
| Chipaca | zyga: expect's timeout is 5 seconds | 16:56 |
| Chipaca | ¯\_(ツ)_/¯ | 16:56 |
| zyga | Chipaca: thanks! | 16:57 |
| * Chipaca is wearing out his :shrug: today | 16:57 | |
| zyga | Chipaca: I wish that was easier to grok :D | 16:57 |
| zyga | Chipaca: like if >5.0 printf "WTF is so slow?" | 16:57 |
| Chipaca | zyga: suggest bumping expect timeout to, say, 7 seconds :-) | 16:57 |
| niemeyer | zyga: +1 | 16:57 |
| zyga | niemeyer: thank you! | 16:57 |
| zyga | niemeyer: can you also look at https://github.com/snapcore/snapd/pull/3284 perhaps, I'd appreciate advice on how to make that better | 16:58 |
| mup | PR snapd#3284: interfaces: ensure that legacy interface methods are unused <Created by zyga> <https://github.com/snapcore/snapd/pull/3284> | 16:58 |
| zyga | I wanted to avoid using reflection in non-test code | 16:58 |
| niemeyer | zyga: I really want to finish my expense reporting.. it's way to tempting not to | 16:58 |
| zyga | I could also make the tinye "definer" interfaces public | 16:58 |
| niemeyer | too | 16:58 |
| zyga | niemeyer: understood :) | 16:58 |
| zyga | we are two PRs away from being one-page-long | 16:59 |
| mup | PR snapd#3026 closed: cmd/snap-confine: use defensive argument parser <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3026> | 16:59 |
| * zyga goes after another interface | 16:59 | |
| Chipaca | niemeyer: dunno if you saw but in the 'snap info' output i've had to change the - to a -- (for the 'channel is closed, and no less risky channel is open' case) | 16:59 |
| Chipaca | because, “stable: -” is not valid yaml | 17:00 |
| Chipaca | :-) | 17:00 |
| Chipaca | “stable: --” is, though, so i'm going with that | 17:00 |
| niemeyer | Ouch | 17:01 |
| Chipaca | :-) | 17:01 |
| niemeyer | Chipaca: How about an ndash? | 17:01 |
| niemeyer | Too confusing? | 17:01 |
| Chipaca | niemeyer: not confusing, but it'll look nasty in some cases | 17:01 |
| zyga | what is an ndash? | 17:01 |
| Chipaca | niemeyer: (non-utf8 aware cases, which will already look nasty for other reasons i'm sure) | 17:01 |
| Chipaca | zyga: a dash the width of an n | 17:02 |
| zyga | aah | 17:02 |
| Chipaca | zyga: as opposed to the mdash which is a dash the width of an m | 17:02 |
| niemeyer | This: foo: – | 17:02 |
| Chipaca | zyga: also an ndash is 1 en wide, and an mdash is one em wide | 17:02 |
| Chipaca | also an x is one en tall | 17:02 |
| zyga | I think I will hug my 1-cell sized monospace fonts : | 17:02 |
| Chipaca | ... and onf of those can be false in weird fonts | 17:03 |
| zyga | Chipaca: about our discussions earlier | 17:03 |
| zyga | Chipaca: double-cell glyphs! | 17:03 |
| zyga | Chipaca: back to regular broadcast | 17:03 |
| niemeyer | Chipaca: It does look nicer than -- though | 17:03 |
| mup | Bug #1673763 changed: Help for 'version' <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1673763> | 17:03 |
| mup | Bug #1680097 changed: core:network-bind plug is not connected after ubuntu-core -> core transition <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1680097> | 17:03 |
| Chipaca | zyga: hah. what about characters that are wide or thin depending | 17:03 |
| Chipaca | depending on what? who knows. depending. | 17:03 |
| Chipaca | (but people get upset) | 17:03 |
| * niemeyer wonders how unreasonable that is | 17:04 | |
| Chipaca | niemeyer: it does | 17:04 |
| zyga | Chipaca: there is a block like that | 17:04 |
| zyga | Chipaca: they are so-called ambiguous characters | 17:04 |
| zyga | Chipaca: and may be half-width or regular size | 17:04 |
| Chipaca | i know | 17:04 |
| zyga | Chipaca: where half width is really "regular" and regular is "double cell" | 17:04 |
| zyga | anyway | 17:04 |
| zyga | insane stuff | 17:04 |
| Chipaca | niemeyer: so... should I just do it? | 17:05 |
| niemeyer | Chipaca: If we also used hands it'd be more clear that it's UTF-8 :) | 17:05 |
| * niemeyer teases | 17:05 | |
| Chipaca | niemeyer: i was about to suggest using an actual arrow | 17:05 |
| zyga | actual arrows are really ... plentiful in unicode | 17:06 |
| niemeyer | Chipaca: Can you make an example for us to ponder on? | 17:06 |
| niemeyer | Chipaca: An arrow seems nicer than ^ as well, and not a big departure | 17:06 |
| Chipaca | niemeyer: ↑ ⇧ ⇪ ⇫ ⟰ ⤒ ⥉ ⥜ ⥣ ⥾ | 17:08 |
| niemeyer | First one seems nice | 17:08 |
| niemeyer | Although a bit too invisible | 17:09 |
| niemeyer | Chipaca: Do we have a larger one that looks like it | 17:09 |
| niemeyer | ? | 17:09 |
| niemeyer | Chipaca: I'm sure unicode must have hundreds of arrows that look almost exactly like that :) | 17:09 |
| Chipaca | yeah | 17:09 |
| zyga | that last one looks like a fountain | 17:09 |
| Chipaca | there's a lot more arrows pointing right than up though | 17:09 |
| zyga | http://www.fileformat.info/info/unicode/block/arrows/utf8test.htm | 17:09 |
| Chipaca | niemeyer: let me put it in code so you can see it in context | 17:10 |
| zyga | http://www.fileformat.info/info/unicode/block/arrows/list.htm | 17:10 |
| zyga | I see fields of ... arrows | 17:10 |
| zyga | I myself am quite fond of ⇡ | 17:10 |
| zyga | though ↯ is funky, just goes the wrong way | 17:10 |
| Chipaca | niemeyer: http://pastebin.ubuntu.com/24543901/ | 17:11 |
| Chipaca | niemeyer: looks like a tree | 17:11 |
| Chipaca | niemeyer: if anything it's _too_ big | 17:11 |
| zyga | Chipaca: I'd add a "legend" line at the bottom saying what those arrows and funkiness all mean | 17:12 |
| Chipaca | i think if we need that, we're doing it wrong | 17:13 |
| Chipaca | ah, ↑ is a lot less bold in the ubuntu mono font | 17:14 |
| Chipaca | bah. not in the ubuntu font. it's coming from DejaVu Sans | 17:14 |
| zyga | Chipaca: look at a map | 17:14 |
| zyga | Chipaca: maps have legend, they are not doing it wrong, it's just everything is unfamiliar at first | 17:14 |
| zyga | Chipaca: you may skip the legend later but it's useful to have one | 17:15 |
| * Chipaca likes mapmaking, but doesn't feel the terminal is an adequate place for it | 17:15 | |
| Chipaca | anyway, i must EOD | 17:15 |
| cratliff | I'm working on converting some systemd services to snaps. Is there a snappy way to edit variables that would be included in a environment file? | 17:15 |
| Chipaca | niemeyer: zyga: leave me a comment on the PR if you decide anything wrt this | 17:16 |
| * Chipaca off | 17:16 | |
| zyga | cratliff: in the environment of everything else in the system? | 17:16 |
| cratliff | that could probably work for me, but the way it is working right now is the services start with an EnvironmentFile parameter that sets a few variables used in the ROS launch file and other places. | 17:19 |
| zyga | cratliff: aha | 17:22 |
| zyga | cratliff: can you use the environment section in the snapcraft yaml? are those constants ore variables? | 17:23 |
| cratliff | I must have missed the environment section details. They are used to reuse packages on multiple devices so at runtime they are constants. | 17:24 |
| zyga | cratliff: give that a try! | 17:24 |
| cratliff | can you send me a link to a doc? I'm still having trouble finding it. | 17:28 |
| zyga | cratliff: I don't know where this is documented, perhaps sergiusens or kyrofa does | 17:33 |
| kyrofa | cratliff, zyga I'm not sure where it's documented either, but here's an example: https://github.com/snapcore/snapcraft/blob/master/demos/git/snap/snapcraft.yaml | 17:36 |
| zyga | niemeyer: can you please re-review https://github.com/snapcore/snapd/pull/2869; it has jdstrand's +1 and I added one missing bit and reviewed it myself | 17:36 |
| mup | PR snapd#2869: interfaces/builtin: add online-accounts-service interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869> | 17:36 |
| zyga | kyrofa: thank you! | 17:36 |
| niemeyer | zyga: Still doing expenses | 17:36 |
| zyga | niemeyer: sure | 17:36 |
| cratliff | Cool, thanks for pointing me in the right direction. | 17:38 |
| kgvelkov | hey | 18:06 |
| * zyga_ breaks for evening walk | 18:09 | |
| mup | PR snapd#3285 closed: interfaces/network: workaround Go's need for NETLINK_ROUTE with 'net'. LP: #1689536 <Critical> <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3285> | 20:52 |
| mup | PR snapd#3279 closed: tests: extend kernel-module-control interface test <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3279> | 20:59 |
| mup | PR snapd#3251 closed: packaging: cleanup how built-using is generated <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3251> | 21:00 |
| Chipaca | zyga: you around? | 21:14 |
| Chipaca | zyga: have you done the thing about the expect timeout? | 21:14 |
| === JanC is now known as Guest59098 | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!