| mdye | is there a status page for snap services in case of outtages or such? (I have automated testing of download and installation of my snap and it's been slow or timed out the last few hours; is this a problem on my end or in store services?) | 00:01 |
|---|---|---|
| kyrofa | mdye, check http://status.snapcraft.io/ | 00:02 |
| mdye | thx | 00:02 |
| kyrofa | mdye, ah, some firewall maintenance is happening today, I wonder if that is affecting things | 00:03 |
| kyrofa | But I'll admit, that status page is quite a bit more optimistic about things than my experience has been. I have snaps uploading to CI daily and it's about 50/50 whether I'll get an email about a failed upload | 00:04 |
| mup | PR snapcraft#1100 opened: repo: remove symlinks to libc <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1100> | 00:10 |
| olympionex | when installing the app, it seems like the daemon in my snap is being started before the configure hook gets a chance to run. I use the configure hook to setup the config and a few other things. As a result, the daemon fails to start and the whole snap then seems to fail to install because of that. Is this an error or the expected behavior? | 01:05 |
| olympionex | *when installing the snap | 01:05 |
| kyrofa | olympionex, that's expected behavior. When you consider running a hook upon install, there are two possible scenarios: | 01:07 |
| kyrofa | 1. Run the hook after services start. This gives the hook a chance to query the running services, make sure everything is running correctly, and modify configuration if necessary. If something is wrong, it can error and rollback installation | 01:08 |
| kyrofa | 2. Run the hook before services start. Which allows the hook to do some setup required by included daemons, but makes it useless for querying them and checking their health | 01:09 |
| kyrofa | olympionex, honesty I think this is a good case for an install hook instead of making the configure hook do everything | 01:09 |
| kyrofa | olympionex, but that's the reason the configure hook runs when it does-- it's closer to its purpose | 01:10 |
| kyrofa | olympionex, would you mind logging a bug? | 01:10 |
| olympionex | kyrofa: agreed, just making sure I don't have an option. I'm trying to snapify a troublesome daemon that I can't modify unfortunately and need to do some setup upon install | 01:11 |
| kyrofa | olympionex, currently your only option is to write a shell wrapper that makes sure it's setup correctly when run. That wrapper should be your daemon, and after it ensures things are setup, it should run the real binary | 01:12 |
| kyrofa | olympionex, if we had an install hook that ran before the services did, you could use that instead | 01:12 |
| olympionex | kyrofa: yeah, makes sense -- snap seems to have a lot of development going on, so maybe I can look forward to it soon | 01:13 |
| kyrofa | olympionex, the configure hook stands alone in this regard because no one has asked for anything else. Please log a bug if you feel you need this | 01:14 |
| olympionex | kyrofa, for snapcore/snapd? | 01:15 |
| kyrofa | olympionex, right here: https://bugs.launchpad.net/ubuntu/+source/snapd/+filebug | 01:15 |
| kyrofa | olympionex, if you want some examples of other snaps that go the wrapper route, check out the nextcloud snap. A good example is the `mysql` daemon: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml | 01:18 |
| kyrofa | olympionex, notice that it doesn't run mysqd directly, it runs start_mysql: https://github.com/nextcloud/nextcloud-snap/blob/master/src/mysql/start_mysql | 01:18 |
| olympionex | kyrofa: thanks - I actually already have a wrapper to handle some of the required pid file requirements of my daemon | 01:18 |
| kyrofa | Which makes sure a database is generated, etc. | 01:18 |
| kyrofa | Good dea | 01:18 |
| kyrofa | l | 01:19 |
| htafdresgi | i snap installed docker, how do I docker pull? | 02:04 |
| htafdresgi | like I know I can cd into the /snap/docker/bin but is that how I'm supposed to do it, or is there a different way? | 02:04 |
| htafdresgi | never mind i fiugred it out | 04:15 |
| htafdresgi | figured* | 04:15 |
| olympionex | I'm having a catch-22 with classic confinement and snapcraft. It won't let me run snapcraft unless I install the core snap, and there is no way to do that b/c it conflicts with the immovable ubuntu-core snap | 04:22 |
| olympionex | this is on 16.04, weird that it works fine on my other pc | 04:23 |
| olympionex | same versions of everything, including the ubuntu-core snap | 04:23 |
| olympionex | i had to end up purging snapd and reinstalling | 04:25 |
| Mirv | oSoMoN: can you retest bug #1642900 vs. https://github.com/ubuntu/snapcraft-desktop-helpers/pull/40 ? | 07:01 |
| mup | PR ubuntu/snapcraft-desktop-helpers#40: Use also ubuntu-app-platform's lib/$ARCH dir for LD_LIBRARY_PATH (LP:… <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/40> | 07:01 |
| mup | Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Ubuntu App Platform:In Progress by timo-jyrinki> <https://launchpad.net/bugs/1642900> | 07:01 |
| Mirv | oSoMoN: note that you'd need edge version of platform snap to have the libgcc_s.so.1 | 07:02 |
| oSoMoN | Mirv, will do | 07:04 |
| zyga | o/ | 07:36 |
| === JanC is now known as Guest98802 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2692 closed: spread: add unit suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2692> | 08:03 |
| mup | PR snapd#2741 closed: store: enable download deltas on classic by default <Created by squidsoup> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2741> | 08:08 |
| mup | PR snapd#2751 closed: 14.04/integrationtests: rely on upstart to restart ssh <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2751> | 08:09 |
| mup | PR snapd#2743 closed: debian: move the snap-confine packaging into snapd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2743> | 08:11 |
| zyga | jjohansen: hey | 08:26 |
| zyga | jjohansen: which timezone do you live in? | 08:26 |
| jjohansen | zyga: uhm UCT-8 (portland, OR area) | 08:27 |
| jjohansen | but well, I can't say I uhmm follow the tz all that well | 08:28 |
| jjohansen | zyga: I haven't gotten to testing the test kernels against your bug yet. I have been chasing it as a regression for 1661030 and jdstrand's bug 1648903 | 08:29 |
| mup | Bug #1648903: Permission denied and inconsistent behavior in complain mode with 'ip netns list' command <AppArmor:New> <https://launchpad.net/bugs/1648903> | 08:29 |
| jjohansen | I was about to get around trying your reproducer | 08:29 |
| zyga | jjohansen: haha, that explains a lot :) | 08:29 |
| zyga | jjohansen: I'm already running the test with the kernel you indicated | 08:29 |
| jjohansen | ah nice | 08:30 |
| zyga | jjohansen: btw, where is your tree, I could follow your patches and learn a few things | 08:30 |
| jjohansen | zyga: ha which tree? I have a whole bunch of trees, sadly most are more stale than I like | 08:31 |
| jjohansen | there are the set on kernel.ubuntu.com/jj/ | 08:31 |
| zyga | jjohansen: s/tree/repo/ | 08:31 |
| zyga | let's see | 08:31 |
| jjohansen | 1 for each release + the backport kernels (which is work I need to get back too) | 08:31 |
| zyga | hmm, that's a 404 | 08:31 |
| zyga | jjohansen: do you use multiple repositories for that/ | 08:32 |
| zyga | I'm not familiar with kernel development process | 08:32 |
| jjohansen | http://kernel.ubuntu.com/git/jj/ | 08:32 |
| jjohansen | its git://kernel.ubuntu.com/jj/ from git | 08:32 |
| jjohansen | zyga: I was trying to get a base set of backport kernels setup in a single repo, sadly its in poor shape as I just haven't had enough to do it properly | 08:33 |
| jjohansen | I also have an upstream tree | 08:33 |
| zyga | thanks, I'm looking a the xenial tree now | 08:34 |
| jjohansen | but I don''t push to that one often because a lot of bots watch it, and if I push dev code there I get slammed with emails from bots complaining about any and every little thing | 08:34 |
| jjohansen | great some times, but not when you are in the middle of dev | 08:34 |
| jjohansen | zyga: the proposed patch hasn't been pushed yet | 08:35 |
| zyga | jjohansen: where is it? | 08:35 |
| jjohansen | give me a minute | 08:35 |
| zyga | ah | 08:35 |
| zyga | sure :) | 08:35 |
| zyga | jjohansen: curious, what do bots do when you push there? | 08:35 |
| zyga | (so far fetching from git://kernel.ubuntu.com/jj/ubuntu-xenial.git fails on corrupted repository) | 08:37 |
| zyga | jjohansen: the test passed!!! | 08:42 |
| zyga | jjohansen: it's fixed :) | 08:42 |
| zyga | jjohansen: when can you land that in the ubuntu kernels and upstream? | 08:44 |
| jjohansen | zyga: okay its pushed, I will send the patch out in a few minutes. It will land into -proposed with the other fixes (it fixes a regression) | 08:52 |
| jjohansen | so it should land in the next kernel release in 2.5 weeks | 08:53 |
| zyga | jjohansen: understood, thank you! | 08:56 |
| zyga | jjohansen: did you push it to git://kernel.ubuntu.com/jj/ubuntu-xenial.git? | 08:57 |
| zyga | I still get: remote: error: Could not read 162e766089a4fdbbb6626f39cc23da92fdb2204e | 08:58 |
| jjohansen | zyga: yes, on the master branch | 08:58 |
| jjohansen | gah, I need to reset my master-next as its been rebased and the ref no longer exists | 08:59 |
| jjohansen | this happens all the time | 08:59 |
| jjohansen | gah, no something else is broken | 09:01 |
| mup | PR snapd#2759 opened: asserts: support for correctly suggesting format 2 for snap-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2759> | 09:07 |
| zyga | jjohansen: btw, I'll break my userspace code and see if I can trigger an oops that I ran into earlier | 09:14 |
| zyga | jjohansen: I was trying to use a O_PATH fd to do something that wasn't meant for it (setns) | 09:14 |
| zyga | jjohansen: and that oopsed | 09:14 |
| jjohansen | zyga: sounds good, I am still trying to figure out what is wrong with the tree, something broke | 09:15 |
| zyga | jjohansen: what are your typical work hours? | 09:17 |
| jjohansen | O_o the tree has lost all its heads | 09:17 |
| zyga | jjohansen: this one? http://kernel.ubuntu.com/git/jj/ubuntu-xenial.git/log/ ? | 09:17 |
| jjohansen | zyga: yes | 09:18 |
| jjohansen | zyga: my work hours drift but for the last few weeks they have been roughly 07:00-11:00 UCT and 20:00-02:00 UCT | 09:19 |
| mup | PR snapd#2760 opened: merge release 2.22.1 into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2760> | 09:20 |
| jjohansen | if I got the conversion right | 09:20 |
| jjohansen | thats 23:00-4:00 and 12:00-18:00 local time | 09:20 |
| zyga | are you doing this to stay in touch with devs in europe? | 09:21 |
| jjohansen | zyga: some times, but not atm, I'm a night owl and tend to work at nights when things quiet down here | 09:23 |
| jjohansen | I do try reseting my hours every once and a while but then something comes up, I push and they drift ... | 09:24 |
| zyga | jjohansen: I know how this feels :) | 09:25 |
| jjohansen | :) | 09:25 |
| zyga | jjohansen: thank you for fixing this and a host of other issues | 09:26 |
| zyga | jjohansen: I'll check if the oops happens and let you know if it does (with a test case if I can) | 09:26 |
| jjohansen | sounds good | 09:27 |
| mup | PR snapd#2761 opened: vendor: move gettext.go back to github.com/ojii/gettext.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/2761> | 09:33 |
| mup | PR snapd#2762 opened: debian: update breaks/replaces for snap-config->snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2762> | 09:41 |
| zyga | jjohansen: no more oops | 09:46 |
| zyga | jjohansen: so whatever it was, one of your patches fixed it | 09:46 |
| jjohansen | zyga: \o/ | 10:10 |
| mup | PR snapd#2763 opened: store: retry on 502 http response as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/2763> | 10:36 |
| sergiusens | ogra_: where did the livecdrootfs stuff live? | 11:32 |
| mup | PR snapd#2762 closed: debian: update breaks/replaces for snap-confine->snapd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2762> | 11:41 |
| === tinwood is now known as tinwood_afk | ||
| ogra_ | sergiusens, image PPA | 12:02 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 12:02 |
| sergiusens | ogra_: so download source deb and the push? Might I just ask you to do something? xdg-open is in /usr/local/bin, would be nice to get that in the default PATH | 12:18 |
| ogra_ | sergiusens, well, see my comment on the bug :) | 12:18 |
| ogra_ | sergiusens, we have /usr/local/bin in the default path on images ... and the calling user on a classic system should also have it in his default PATH ... the only way to *not* have it in the default PATH is if a desktop wrapper redefines PATH | 12:20 |
| ogra_ | sergiusens, so IMHO the desktop wrppers need a fix here | 12:20 |
| ogra_ | *wrappers | 12:20 |
| ogra_ | ogra@localhost:~$ echo $PATH | 12:21 |
| ogra_ | bah | 12:21 |
| ogra_ | ogra@localhost:~$ echo $PATH | 12:21 |
| ogra_ | /home/ogra/bin:/home/ogra/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin | 12:21 |
| ogra_ | thats on my Pi | 12:21 |
| ogra_ | (and i get the same thing on my desktop classic install) | 12:21 |
| sergiusens | ogra_: http://paste.ubuntu.com/23910571/ | 12:22 |
| sergiusens | ogra_: I wonder if snap-confine is wiping it then | 12:22 |
| sergiusens | oops | 12:22 |
| ogra_ | that would be a question to zyga i guess | 12:22 |
| sergiusens | oh, no oops, I pasted the paste bin and confused by your output :-) | 12:22 |
| zyga | ogra_: hey | 12:23 |
| zyga | how can I help? | 12:23 |
| ogra_ | zyga, does snap-confine reset PATH ? | 12:23 |
| zyga | yes it does | 12:23 |
| ogra_ | aha | 12:23 |
| zyga | for snaps other than classic confinement that is | 12:23 |
| zyga | otherwise you don't know what PATH you may see | 12:23 |
| ogra_ | zyga, can we add /usr/local/bin then ? | 12:23 |
| sergiusens | zyga: then it needs /usr/local/bin and didrocks was right, you do need to fix it ;-) | 12:23 |
| ogra_ | zyga, we need to find xdg-open there | 12:23 |
| zyga | ogra_: does that path exist on core? | 12:23 |
| ogra_ | yes | 12:23 |
| zyga | ogra_: oh, curious | 12:24 |
| zyga | ogra_: sure I can fix this quickly | 12:24 |
| ogra_ | for apt, dpkg palceholders and for xdg-open | 12:24 |
| zyga | ogra_: is there a bug for reference? | 12:24 |
| ogra_ | yeah | 12:24 |
| sergiusens | zyga: do you use gui snaps at all??? | 12:24 |
| zyga | sergiusens: not that much, my local setup is in a weird state for content testing | 12:24 |
| zyga | sergiusens: and I don't want to rely on snaps on a dev machine | 12:24 |
| zyga | sergiusens: I use them on other machines though | 12:24 |
| zyga | sergiusens: why? | 12:25 |
| ogra_ | Bug 1661023 | 12:25 |
| mup | Bug #1661023: PATH does not include /usr/local/bin and /usr/local/sbin <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1661023> | 12:25 |
| zyga | ogra_: thank you | 12:25 |
| ogra_ | zyga, nad it needs to be first ... before /usr/bin | 12:25 |
| ogra_ | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin | 12:25 |
| ogra_ | like that | 12:26 |
| zyga | ogra_: noted | 12:26 |
| ogra_ | else it wont override | 12:26 |
| zyga | ogra_: actually without /snap/bin | 12:27 |
| ogra_ | heh, yeah, i guess | 12:28 |
| ogra_ | (that was just tghe PATH from ym Pi) | 12:28 |
| oSoMoN | didrocks, when I build a webbrowser-app snap locally and install it, the app won’t start, I’m getting this error: | 12:36 |
| oSoMoN | This application failed to start because it could not find or load the Qt platform plugin "xcb" | 12:36 |
| oSoMoN | in "". | 12:36 |
| sergiusens | zyga: I would strongly recommend you do dev in a VM and leave your main system as a dog fooding one to enjoy the pain and fix stuff as they show (some sort of stress testing) | 12:36 |
| didrocks | oSoMoN: did you snapcraft update since tuesday? | 12:37 |
| didrocks | oSoMoN: pat confirmed that updating to latest works | 12:37 |
| oSoMoN | didrocks, no I hadn’t, let me try that | 12:37 |
| zyga | sergiusens: I'm already working in a VM but I don't use the host as much, that's my "main" vm that moves from host to host as I change devices | 12:37 |
| zyga | sergiusens: I also use snaps but I don't use gui snaps that much | 12:39 |
| zyga | sergiusens: (I'm mostly a terminal + browser person | 12:39 |
| ogra_ | use a snapped browser and a snapped terminal !! | 12:40 |
| ogra_ | :) | 12:40 |
| oSoMoN | didrocks, confirmed, that fixed the issue | 12:40 |
| didrocks | oSoMoN: phew, same fixed issue then :) | 12:40 |
| didrocks | (the issue being part definition is cached, but the parameters used in the git repo has changed/been added) | 12:42 |
| oSoMoN | can snapcraft be improved to handle this better? | 12:42 |
| didrocks | unsure, I guess we have to think that the definition can be async compared to code | 12:42 |
| didrocks | so handling backward compatibility and not treating as one unit, but 2 | 12:43 |
| didrocks | (I didn't think about the caching at the time) | 12:43 |
| * didrocks really needs to take a lunch break, ttyl | 12:43 | |
| ogra_ | but if you already cache you know the local version | 12:43 |
| ogra_ | so its just a matter of comparing to the remote and notifying the user | 12:43 |
| sergiusens | oSoMoN: handle what better? | 12:44 |
| ogra_ | remote parts updates | 12:44 |
| sergiusens | oSoMoN: so you want the latest and greatest always no matter if what is locally works and what is remote doesn't? | 12:45 |
| ogra_ | i guess jst a notification that there is a new remote version would help | 12:45 |
| sergiusens | ogra_: we could do that on `pull` as it is an online operation; don't think it would be wise to anywhere else | 12:46 |
| sergiusens | and notify, not auto update | 12:47 |
| ogra_ | right | 12:47 |
| ogra_ | just let the user know "hey, there is a newer version of this remote part" | 12:47 |
| ogra_ | prevents support questions because of outdated local revisions | 12:47 |
| sergiusens | oSoMoN: if you log a bug, we can do it ;-) | 12:47 |
| oSoMoN | didrocks, mind filing the bug? you have a better understanding of the problem, and you would explain it better than I could | 12:48 |
| HumbleBeaver | jdstrand, mhall119 after all that help day before yesterday you two gave me I have found out that my system is to blame. Every snap installed on my system exhibits some sort of issue. | 13:48 |
| HumbleBeaver | But if I add process-control to the program and connect them they work fine. | 13:48 |
| HumbleBeaver | I'm currently trying to sort out the issue. | 13:49 |
| jdstrand | HumbleBeaver: its still just the one program? | 13:49 |
| mup | PR snapd#2764 opened: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2764> | 13:49 |
| HumbleBeaver | jdstrand no, another program I wrote is now exhibiting the same issue. (main screen never displays) , but hexchat locks up, blender-tpaw doesn't launch, Krita doesn't load, and both Telegram snaps won't allow me to attach files via the attach clip. | 13:53 |
| stokachu | tvoss, you around? | 13:53 |
| jdstrand | HumbleBeaver: and for all of them, if you connect 'process-control' it fixes the issue? | 13:54 |
| HumbleBeaver | jdstrand I've only added it to numnom so far, and yes it fixed the problem. | 13:56 |
| jdstrand | HumbleBeaver: can you give the output of 'grep type=1326 /var/log/syslog' after you see all these denials? | 13:57 |
| jdstrand | s/denials/failures/ | 13:57 |
| HumbleBeaver | jdstrand sure can, stand by | 13:58 |
| tvoss | stokachu: yup, I am | 14:02 |
| HumbleBeaver | jdstrand paste.ubuntu.com/23911024 | 14:08 |
| zyga | ogra_: https://github.com/snapcore/snapd/pull/2765 | 14:08 |
| mup | PR snapd#2765: cmd: add /usr/local/* to PATH <Created by zyga> <https://github.com/snapcore/snapd/pull/2765> | 14:08 |
| zyga | ogra_: review appreciated :) | 14:08 |
| mup | PR snapd#2765 opened: cmd: add /usr/local/* to PATH <Created by zyga> <https://github.com/snapcore/snapd/pull/2765> | 14:09 |
| zyga | jdstrand: if you are around I'd like to quickly discuss where to take the sc_must_stpcpy branch, | 14:11 |
| zyga | jdstrand: we talked but I'm not sure what the bottom line was | 14:11 |
| zyga | jdstrand: I'm +1 on the rename to sc_append_string (or similar) and +1 to drop the size limit if you want to as well; | 14:12 |
| zyga | jdstrand: and +0.5 on the simplification (from stpcpy-like to strcat-like) | 14:12 |
| ogra_ | zyga, looks fine, though not sure we need games actually :) | 14:14 |
| zyga | ogra_: I felt the same, added it for completeness | 14:14 |
| ogra_ | yeah | 14:14 |
| zyga | ogra_: but I can remove it if you feel we don't want to have it | 14:14 |
| === ara_ is now known as ara | ||
| ogra_ | well, we have it everywhere else, seems more consistent in the end | 14:15 |
| === ara is now known as Guest84900 | ||
| jdstrand | zyga: I am here, I'll need to circle back though | 14:16 |
| jdstrand | zyga: it sounds like you are in favor of basically everything then. I think going to strcat-like is going to be more useful long term. already you have to reset the pointer at the end of all the stpcpy calls to send the string off to be used, so this will remove that requirement | 14:19 |
| zyga | jdstrand: yes, it makes it simpler and more reliable at a irrelevant cost in performance | 14:20 |
| zyga | jdstrand: if you agree I'll folow up and do just that | 14:20 |
| zyga | jdstrand: and apply this across the tree to kill the static char buffers | 14:20 |
| jdstrand | HumbleBeaver: telegram, numnom, krita and codebreakers are all sched_setscheduler and that is a regression in 2.22 | 14:21 |
| jdstrand | HumbleBeaver: hexchat is fchown which was never allowed | 14:22 |
| zyga | ogra_: if you reviewed that branch can you please add a comment; that helps | 14:22 |
| jdstrand | zyga: sounds fine | 14:22 |
| zyga | jdstrand: thanks! :) | 14:22 |
| ogra_ | zyga, yeah, sorry distracted | 14:22 |
| zyga | ogra_: no worries, thank you :) | 14:24 |
| HumbleBeaver | jdstrand, well that explains why they still work on other people's computers. Thanks for your help | 14:26 |
| jdstrand | HumbleBeaver: right, you have 2.22, other people only have 2.21 | 14:32 |
| jdstrand | HumbleBeaver: for each of telegram, numnom, krita and codebreakers, can you add 'sched_setscheduler' (without the quotes) to the botton of /var/lib/snapd/seccomp/profiles/snap.<your snap>, then relaunch the app and let me know if it works? | 14:33 |
| jdstrand | bottom* | 14:33 |
| jdstrand | HumbleBeaver: fyi, bug 1661265 | 14:33 |
| mup | Bug #1661265: [regression] sched_setscheduler denied with Qt/QML applications <snapd (Ubuntu):New> <https://launchpad.net/bugs/1661265> | 14:33 |
| jdstrand | mvo: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1659522/comments/10 | 14:35 |
| mup | Bug #1659522: [SRU] 2.22 <verification-failed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Committed> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1659522> | 14:35 |
| mvo | jdstrand: oh, so we need a 2.22.2? | 14:36 |
| zyga | mvo: \o/ | 14:36 |
| jdstrand | mvo: I've assigned that to me, but I would like to do a little digging first | 14:36 |
| zyga | mvo: l.oo.l release | 14:36 |
| jdstrand | mvo: yes, sorry | 14:36 |
| mvo | jdstrand: no worries | 14:36 |
| mvo | jdstrand: I caused 2.22.1 myself :/ | 14:36 |
| mvo | jdstrand: do you have a rough estimate about times? | 14:36 |
| jdstrand | mvo: let me PR a fix right this second that way you aren't blocked on my investigation. I will want to augment the comment for this syscall pending my investigation | 14:37 |
| mvo | sounds good | 14:38 |
| mup | PR snapd#2766 opened: tests: improve snap-env test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2766> | 14:39 |
| mup | PR snapd#2767 opened: interfaces: allow sched_setscheduler again by default (LP: #1661265) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2767> | 14:45 |
| jdstrand | mvo: ^ | 14:45 |
| jdstrand | mvo: I did it to master. will you get it to 2.22.2 or should I do something extra? | 14:47 |
| mvo | jdstrand: I can cherry-pick it into the 2.22 branch | 14:47 |
| jdstrand | HumbleBeaver: in addition to trying all that, can you point me to your hexchat snap? I'd like to see how it is using fchown | 14:48 |
| HumbleBeaver | jdstrand, tingping is the developer of hexchat. It's the one in the store. | 14:51 |
| jdstrand | HumbleBeaver: great, thanks! | 14:51 |
| === tinwood_afk is now known as tinwood | ||
| mup | PR snapd#2768 opened: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2768> | 15:13 |
| zyga | jdstrand: FYI, I found this insteresting: https://github.com/snapcore/snapd/pull/2768/files#r99141379 | 15:20 |
| mup | PR snapd#2768: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2768> | 15:20 |
| jdstrand | zyga: yes, that occurred to me to. we'll have to design it to support snapd policy versions if we are going to allow different series core snaps on the same device. note, this isn't the only issue with this-- I suspect there will be a lot of things that will need to be done differently based on the core series | 15:22 |
| zyga | jdstrand: after writing this I realized that we can see the slot so we can identify 16 and 18 series but I totally agree with what you just said | 15:23 |
| jdstrand | zyga: I'd rather not try to predict all that right now though. when series 18 core snaps are a thing and we want to pull the trigger on something different, we should see how we want to do that | 15:24 |
| jdstrand | it's kinda scary if you really think about it-- series 22 with series 16-- how will snap-confine/snapd have changed? | 15:24 |
| zyga | jdstrand: I bet we will be asked for continuity so that 16-based snaps can be installed aon 18 | 15:24 |
| zyga | jdstrand: yes | 15:24 |
| zyga | jdstrand: I think it is worth to think about what we will do with multi-base snaps when we start to split that sometime soon | 15:25 |
| jdstrand | zyga: that request will need to also consider positive change moving forward | 15:25 |
| zyga | jdstrand: (I suspect we'll make ubuntu-base-16 before EOY) | 15:25 |
| zyga | jdstrand: backwards compatibility will win ous many hearts and I think it's not impossible to do | 15:26 |
| zyga | jdstrand: we'll just recommend devs to update to 18-base | 15:26 |
| jdstrand | eg, it is perfectly correct to evolve and deprecate. series 16 should always work, but does that mean series 18+ need to not evolve? interesting questions | 15:26 |
| zyga | jdstrand: I suspect that we may phase out series over time (e.g. a given snapd will only support 16 and 18 and maybe 20 but not 22 and 16 at the same time) | 15:26 |
| zyga | jdstrand: no, I didn't mean that | 15:26 |
| zyga | jdstrand: in 18 we should change what that interface does | 15:27 |
| zyga | jdstrand: (or to be precise) when that interface is connected to a 16-base snap it should behave as it does | 15:27 |
| zyga | jdstrand: but not in 18-base snap | 15:27 |
| zyga | jdstrand: from the same snapd process | 15:27 |
| zyga | jdstrand: (curious issues with >1 base snap and snap interfaces and auto-connection) | 15:27 |
| zyga | jdstrand: lots of fun things ahead :) | 15:27 |
| jdstrand | well, I think this needs to be all thought through at the appropriate time. there is a lot to consider | 15:27 |
| jdstrand | yes | 15:27 |
| kalikiana | Hmmm 'snapcraft push' just gabe me '502 Bad Gateway' | 15:36 |
| kalikiana | Basically a bunch of raw HTML | 15:36 |
| kalikiana | Tried again, now it seems to have worked | 15:39 |
| kyrofa | kalikiana, I get that every other day when LP tries to push as well | 16:02 |
| ogra_ | jdstrand, did you see my comment on the remote syslog bug ? would be nice to have /etc/rsyslog.d writable by the core-support interface | 16:03 |
| ogra_ | i can then add the needed script bits to the config script | 16:03 |
| jdstrand | ogra_: I thought I saw the comment, and I thought I saw you say you were going to do that, and I meant to say 'thank you' to you :)( | 16:04 |
| jdstrand | :) | 16:04 |
| ogra_ | oh | 16:04 |
| ogra_ | i only made the dir writable on an image level yet | 16:04 |
| mup | PR snapd#2769 opened: snap-exec: support nested environment variables in environment: <Created by mvo5> <https://github.com/snapcore/snapd/pull/2769> | 16:05 |
| jdstrand | ogra_: oh, I see what you mean | 16:05 |
| jdstrand | ogra_: let me take that onto an existing PR | 16:06 |
| ogra_ | awesome ! | 16:06 |
| ogra_ | thanks ... i'll care for the rest then | 16:06 |
| jdstrand | ogra_: is there a particular path or naming convention you are going to use? ie, we have a choice to allow modifying anything in there (eg, 50-default.conf) or to only modify [0-9][0-9]-snap*.conf (or something) | 16:10 |
| ogra_ | well, i made the whole dir writable on the image level ... if you want to restrict the interface to a particular filename, feel free to do so, just tell me the name then | 16:11 |
| mup | PR snapd#2767 closed: interfaces: allow sched_setscheduler again by default (LP: #1661265) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2767> | 16:12 |
| ogra_ | jdstrand, the latter sounds sane though ... also in the light that we might want to be able to add more options later | 16:13 |
| ogra_ | and i'd like to keep one file per option to not have to do sed stunts in the scripts | 16:14 |
| ogra_ | (rm $filepath is so much easier than in-place editing of a big config file) | 16:15 |
| jdstrand | ogra_: I was going to do this: http://paste.ubuntu.com/23911801/ | 16:15 |
| ogra_ | perfect | 16:15 |
| jdstrand | that at least namespaces it a bit | 16:16 |
| ogra_ | yep | 16:16 |
| jdstrand | I figure you might want some flexibility on 00-snap-foo.conf vs 99-snap-bar.conf vs snap-baz.conf | 16:16 |
| ogra_ | yeah | 16:17 |
| jdstrand | cool | 16:17 |
| jdstrand | I'll send it up. I think I will do a separate PR since I already have approval on the other one | 16:17 |
| jdstrand | ogra_: this is exciting! :) | 16:17 |
| ogra_ | :D | 16:18 |
| jdstrand | for some reason I'm a bit of a logging nerd :) | 16:18 |
| ogra_ | and i love to save wear levelling of my SDs | 16:18 |
| ogra_ | directing all my boards to a central place surely helps that | 16:19 |
| mup | Bug #1661265 opened: [regression] sched_setscheduler denied with Qt/QML applications <snapd-interface> <Canonical System Image:In Progress by pat-mcgowan> <Snappy:Fix Committed> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1661265> | 16:20 |
| mup | PR snapd#2758 closed: overlord/devicestate: implement policy about gadget and kernel matching the model <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2758> | 16:24 |
| mup | PR snapd#2770 opened: interfaces/core-support: allow modifying snap rsyslog configuration <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2770> | 16:25 |
| jdstrand | ogra_: since you mentioned you forgot about the remote logging bug, I'll remind you of bug #1504657 too since it is all in the same area | 16:37 |
| mup | Bug #1504657: ntp servers should be configurable on snappy <Snappy:Confirmed> <ubuntu-core-config (Ubuntu):Won't Fix by ogra> <https://launchpad.net/bugs/1504657> | 16:37 |
| ogra_ | geez ! | 16:38 |
| jdstrand | ogra_: sorry! feel free to prioritize how you want, just wanted to get it back on your radar. I don't have any more, I promise! :) | 16:38 |
| ogra_ | jdstrand, no, that was about me also missing this one | 16:38 |
| jdstrand | oh, heh :) | 16:39 |
| ogra_ | my LP search doesnt show it because the task assigned to me is wont-fixed | 16:39 |
| jdstrand | ogra_: makes sense | 16:40 |
| jdstrand | ogra_: this one is interesting. In addition to being able to set the time servers for core, I suspect that eventually people will want an ntp, chrony, openntpd, etc snap and therefore will want to be able to disable systemd-timesyncd so they can just use their snap | 16:42 |
| jdstrand | ogra_: so I think in the config (at least at this time) should include enable (default)/disable, and setting the timeservers | 16:43 |
| ogra_ | jdstrand, well, afer my last change ro tezh configure script that just means adding systemd-timesyncd to a variable list ... thats trivial | 16:43 |
| ogra_ | the way i changed it we only need to add the service names to the list now | 16:43 |
| jdstrand | cool. I figures from a snapd security policy perspectivy, it was covered with the systemctl changes | 16:44 |
| ogra_ | right | 16:44 |
| jdstrand | figured* | 16:44 |
| jdstrand | jeez I can't type :) | 16:44 |
| jdstrand | ogra_: thanks for this too, now I'm really, really excited! :) | 16:44 |
| jdstrand | :) | 16:44 |
| ogra_ | https://code.launchpad.net/~ogra/core-snap/more-flexible-service-handling/+merge/316116 | 16:45 |
| ogra_ | we just can add to SERVICES= as needed | 16:46 |
| jdstrand | neat :) | 16:46 |
| === JanC_ is now known as JanC | ||
| === jkridner|pd is now known as jkridner_ | ||
| === jkridner_ is now known as jkridner | ||
| BLu2 | is there a way to start a snap without network and device access? like "snap run hello --strict" or whatever if I don't fully trust the application? | 18:10 |
| noise][ | FYI we are experiencing some network issues that are leading to slow response times for some Store endpoints, see http://status.snapcraft.io/ for details and updates as we have them. Currently affecting mostly snapcraft release for a subset of snaps. | 18:11 |
| zyga | BLu2: you can disconnect the network / network-bind interface but due to the way seccomp works today that is not ideal (the app will be killed if it tries to use the network) | 18:13 |
| zyga | BLu2: ideally we'd not kill the app and just reject those calls | 18:13 |
| zyga | BLu2: and perhaps even offer an "offline" zone or something where we could connect the app there instead and it would just be in an empty network | 18:14 |
| zyga | jdstrand: ^^ I always wanted to do this use case | 18:14 |
| mup | PR snapd#2771 opened: debian: update changelog from releases 2.22.{1,2} <Created by mvo5> <https://github.com/snapcore/snapd/pull/2771> | 18:20 |
| BLu2 | zyga, sounds good enough | 18:21 |
| zyga | BLu2: note that soon we will not kill an app in that case but this feature is still not merged in the upstream kernel AFAIK | 18:25 |
| zyga | (or merged but not released) | 18:25 |
| jdstrand | zyga: you are in luck. tyhicks has patches that are going upstream for seccomp ERRNO with logging (ie, deny with EPERM (for example) but log). today we kill because that is the only one that logs | 18:27 |
| kyrofa | jdstrand, ahhhhh \o/! | 18:28 |
| jdstrand | yeah, cool stuff | 18:28 |
| * kyrofa hugs tyhicks | 18:28 | |
| kyrofa | That will change my life | 18:29 |
| kyrofa | jdstrand, judging from the regression bug I saw you log, can I assume that arg filtering is supported now as well? | 18:29 |
| jdstrand | zyga: I guess the use case you are talking about is running without network? (cc BLu2) interface connections are absolutely the way to do that. killing is not unreasonable if you don't trust the app, but that point is moot, we won't be killing soon | 18:30 |
| tyhicks | hey kyrofa :) | 18:30 |
| jdstrand | kyrofa: yes, it has been for some time. the first policy that used it came in Dec for network-control and interfaces | 18:30 |
| kyrofa | Very cool, good work guys | 18:30 |
| jdstrand | kyrofa: 2.22 had some small changes. I have several PRs open now for more arg filtering policy and working on a few more things | 18:31 |
| jdstrand | kyrofa: thanks! | 18:32 |
| kyrofa | jdstrand, one of the things pushing that was setpriority. Are some args whitelisted for that? | 18:32 |
| jdstrand | tyhicks: can you remind me-- do your patches include logging the value of the args? | 18:32 |
| tyhicks | jdstrand: the first set did but the audit people didn't like it | 18:32 |
| tyhicks | jdstrand: they see the audit message format as being set in stone :/ | 18:33 |
| kyrofa | :( | 18:33 |
| jdstrand | kyrofa: that is one of the ones that is up for review | 18:34 |
| jdstrand | actually, was that 2.22... | 18:34 |
| * jdstrand looks | 18:34 | |
| jdstrand | actually, no, that is still on the list, but it will be in 2.23 | 18:36 |
| jdstrand | tyhicks: that annoying | 18:37 |
| jdstrand | that's* | 18:37 |
| tyhicks | oh | 18:37 |
| jdstrand | tyhicks: is there anything more that we can do? | 18:37 |
| tyhicks | jdstrand: oh, I misunderstood you | 18:37 |
| jdstrand | maybe I asked unclearly | 18:37 |
| tyhicks | jdstrand: I thought you were asking if the errno value would be logged - that's what the audit folks were against | 18:37 |
| jdstrand | oh no | 18:38 |
| jdstrand | sorry | 18:38 |
| kyrofa | jdstrand, sounds good. What is the plan there-- only allowing setting priority for yourself and only specific priority ranges? | 18:38 |
| jdstrand | I meant if we allowed setpriority 0-19 and -1 was blocked, can we log that arg2 was -1 | 18:38 |
| tyhicks | jdstrand: that's not in the patch set - that looks very hard to do | 18:39 |
| tyhicks | jdstrand: I think the BPF that libseccomp generates would have to be modified to support that | 18:39 |
| zyga | jdstrand: I've updated https://github.com/snapcore/snapd/pull/2745 | 18:39 |
| mup | PR snapd#2745: cmd: add sc_string_append <Created by zyga> <https://github.com/snapcore/snapd/pull/2745> | 18:39 |
| jdstrand | kyrofa: we will allow setpriority(PRIO_PROCESS, ..., 0-19) by default. other uses will require process-control | 18:41 |
| kyrofa | jdstrand, good deal. MySQL wants -20, I wonder how they actually snapped it | 18:42 |
| kyrofa | Maybe the require process-control | 18:42 |
| kyrofa | Yup, they do | 18:43 |
| jdstrand | kyrofa: they use process-control | 18:43 |
| kyrofa | How cool will it be when mysql will request process-control, the user doesn't want to give it, so mysql simply says "okay, I just won't run at that high a priority then" instead of dying? | 18:46 |
| jdstrand | kyrofa: well, today it has a snap declaration that auto-connects it | 18:46 |
| jdstrand | kyrofa: but it will be cool when disconnected that it won't die, yes | 18:47 |
| kyrofa | jdstrand, yeah, I'm really talking about the one I embed in nextcloud | 18:47 |
| kyrofa | jdstrand, I'm still maintaining a mysql fork to compile that setpriority out | 18:47 |
| jdstrand | fun! | 18:47 |
| jdstrand | :) | 18:47 |
| kyrofa | jdstrand, although if I asked for a snap declaration to connect it, think I'd get it? | 18:48 |
| kyrofa | I guess it would probably perform better | 18:48 |
| zyga | jdstrand: I heard about that feature, I wonder if we can detect if the kernel supports this; the seccomp backend should do runtime detection | 18:48 |
| jdstrand | I doubt it :P | 18:48 |
| zyga | jdstrand: (as should apparmor perhaps) | 18:48 |
| jdstrand | zyga: what are we detecting? | 18:49 |
| jdstrand | zyga: the log vs not log? | 18:49 |
| zyga | jdstrand: capabilities of the implementation in the kernel | 18:50 |
| jdstrand | zyga: we'll just add that to the list of patches that need to be in a kernel. it'll be upstream, eventually it'll flow down. distros that don't want to patch their kernel can use kill instead. perhaps that should be a compile time flag... | 18:50 |
| zyga | jdstrand: that won't be very nice, I'd rather detect that (for a few reasons) | 18:51 |
| zyga | hmmm | 18:51 |
| zyga | than again | 18:51 |
| zyga | maybe for seccomp that's not relevant | 18:51 |
| zyga | unless there's new syntax | 18:51 |
| zyga | or new API that defines this in C | 18:52 |
| jdstrand | the policy won't change | 18:52 |
| zyga | I was mostly after being able to take snapd binary from a snap | 18:52 |
| zyga | and run in it somewhere | 18:52 |
| zyga | and not see issues | 18:52 |
| zyga | oh, drat, we will see issues already as snapd in debian will be affected by this | 18:52 |
| zyga | I'll add a card | 18:52 |
| jdstrand | that sounds like crazy talk :P | 18:52 |
| jdstrand | more seriously, I need to get to other thngs before eow | 18:52 |
| zyga | jdstrand: mmm think carefully | 18:52 |
| zyga | jdstrand: that's a good idea :) | 18:53 |
| zyga | jdstrand: if you +1 the sc_string_append branch I'll have easier life for the next few days | 18:53 |
| kyleN | hey, anyone know how to install core snap when ubuntu-core is already isntalled on xenial desktop? http://pastebin.ubuntu.com/23912890/ | 19:34 |
| kyrofa | kyleN, purge snapd or wait for the new release that will migrate it for you | 19:34 |
| kyleN | kyrofa, as in apt-get remove --purge snapd? | 19:35 |
| kyrofa | kyleN, apt purge snapd is more new-agey, but yeah | 19:35 |
| kyleN | ok, thanks | 19:35 |
| kyrofa | kyleN, but note that'll kill any snaps you have as well | 19:35 |
| kyleN | kyrofa, I already kill them off hoping that might fix it ;) | 19:36 |
| kyrofa | kyleN, ha! Easy fix then | 19:36 |
| kyrofa | kyleN, note that core will automatically be pulled in once you reinstall and attempt to install a snap | 19:37 |
| kyrofa | (instead of ubuntu-core) | 19:37 |
| kyleN | kyrofa, i also note that now snap install *requires* sudo (on xenial desktop) | 19:37 |
| kyrofa | kyleN, yeah that whole thing is beyond me. I always used sudo | 19:38 |
| kyleN | anyway, it worked, thanks kyrofa | 19:38 |
| kyrofa | kyleN, good deal, no problem | 19:39 |
| kyleN | kyrofa, can I 'sudo snap try prime' with a classic snap? I get: snap "make-system-user" requires consent to use classic confinement | 19:41 |
| kyleN | and passing --classic does not change that | 19:41 |
| kyrofa | kyleN, not sure, try passing-- oh | 19:41 |
| kyleN | (I like snap try : ) | 19:41 |
| kyrofa | kyleN, hmm... might be a bug, I'm not sure about that | 19:41 |
| kyrofa | I would like it if I could use it | 19:41 |
| kyrofa | Darn encrypted homes | 19:41 |
| mup | PR snapcraft#1101 opened: misc: consistently use a dash for copyright years <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1101> | 19:54 |
| jdstrand | roadmr: can you pull r837 whenever it is convenient. not urgent in the least | 20:15 |
| roadmr | jdstrand: totally. r836 is in the queue, just awaiting a deployment but it probably won't happen until Monday... | 20:16 |
| roadmr | jdstrand: so for now the consequence is that production doesn't yet accept those number-first snap names. On the upside, we never deployed to production the "name of death" revision, so we're safe there. | 20:16 |
| roadmr | anyway... 837 coming up | 20:16 |
| jdstrand | roadmr: cool, thanks. r837 covers the all-numeric case that pedronis mentioned is not supported | 20:17 |
| roadmr | neat! | 20:17 |
| jdstrand | which the name of death regex handled, but the new one didn't | 20:17 |
| roadmr | cool! ok jdstrand I see a deployment containing r836 was requested and may happen today. | 20:18 |
| jdstrand | r837 is really corner case so again, just whenever is fine | 20:18 |
| roadmr | thanks :) | 20:19 |
| mhall119 | sergiusens: does "snapcraft cleanbuild" ignore local directories named "snap"? | 20:22 |
| kyrofa | mhall119, yes it does, we just noticed that | 20:23 |
| mhall119 | :/ | 20:23 |
| mhall119 | is it a regex, or just "snap" ? | 20:24 |
| kyrofa | Just snap (remember `prime` used to be called `snap`) | 20:24 |
| kyrofa | It's a carry-over from that | 20:24 |
| mhall119 | thanks, I'll rename to snappkg then | 20:24 |
| kyrofa | mhall119, wait, what's in there? | 20:24 |
| mhall119 | a config file and wrapper script | 20:25 |
| kyrofa | mhall119, because the newest release is making the 'snap' directory special | 20:25 |
| mhall119 | this is a directory I made | 20:25 |
| kyrofa | Yeah you'll want to rename it anyway, then | 20:25 |
| mhall119 | thanks kyrofa | 20:27 |
| sergiusens | elopio: you need to test cleanbuild with every release ;-) | 21:00 |
| mup | PR snapcraft#1102 opened: cleanbuild: include snap directory in tarball <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1102> | 21:03 |
| kyrofa | sergiusens, there you go ^^ | 21:03 |
| mup | PR snapcraft#1103 opened: meta: support for the environment keyword <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103> | 21:12 |
| icey | what do I execute to get into a shell in a specific snap's sandbox? | 21:12 |
| cooksey | hello all | 21:16 |
| kyrofa | icey, snap run --shell <appname> | 21:17 |
| kyrofa | Hey there cooksey | 21:17 |
| cooksey | i want to build snapd on a yocto based linux (build from git source). has anyone done this? | 21:17 |
| icey | thanks kyrofa :) | 21:17 |
| mup | PR snapd#2772 opened: interfaces: allow nice/setpriority to positive values by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2772> | 21:17 |
| icey | I knew it was something like that but couldn't tease it out | 21:17 |
| kyrofa | cooksey, not that I know of. It should work fine, but keep in mind snapd's dependencies as well | 21:18 |
| jdstrand | kyrofa: fyi ^ PR | 21:18 |
| kyrofa | jdstrand, hey thanks! | 21:18 |
| cooksey | that's what I was looking for. trying to find a list of dependencies and basic instructions/best practices to build from source | 21:19 |
| cooksey | can't find any build from source documentation | 21:19 |
| kyrofa | cooksey, building won't be an issue so much, but you need to make sure you have a kernel with an up-to-date apparmor, and make sure seccomp is enabled | 21:20 |
| kyrofa | cooksey, zyga can probably give you some guidance | 21:20 |
| cooksey | ah | 21:20 |
| cooksey | just found the document that i think i need | 21:20 |
| kyrofa | cooksey, but I think he's gone for the day. You might consider pinging him earlier tomorrow | 21:20 |
| cooksey | thank, kyrofa. I will if I need him. | 21:21 |
| kyrofa | cooksey, sounds good | 21:21 |
| teward | who do I stab for issues wrt what's on the snapcraft.io site | 22:22 |
| kyrofa | teward, what's going on? | 22:25 |
| teward | kyrofa: I'm a moderator on Ask Ubuntu, which is linked as a 'support medium' for Snapcraft, but we're Ubuntu-centric, not "snapd" centric. | 22:25 |
| teward | would love to have that link 'removed' or at least have a comment next to it about "(if on Ubuntu Core)" since we don't support non-Ubuntu distros there | 22:26 |
| kyrofa | teward, snapcraft only runs on ubuntu | 22:26 |
| teward | kyrofa: what about snapd? | 22:26 |
| teward | does it only run on Ubuntu too? | 22:26 |
| teward | we're getting broad questions regarding snapd on non-Ubuntu | 22:27 |
| kyrofa | teward, no, but you complained about snapcraft, not snapd :) | 22:27 |
| teward | kyrofa: i'm complaining about the *site* | 22:27 |
| teward | not snapcraft or a specific component | 22:27 |
| teward | related: http://meta.askubuntu.com/questions/16672/do-we-support-snapd-on-other-distros | 22:27 |
| kyrofa | teward, perhaps an email to the snapcraft mailing list would be best | 22:27 |
| teward | list address? | 22:27 |
| kyrofa | teward, the link is right next to the AskUbuntu one | 22:28 |
| kyrofa | teward, https://lists.snapcraft.io/mailman/listinfo/snapcraft | 22:28 |
| mup | PR snapd#2755 closed: interfaces: port mount backend to new APIs, unify content of per app/hook profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2755> | 22:29 |
| kyrofa | teward, indeed, the link should probably mention "only if using on ubuntu" or something similar | 22:30 |
| kyrofa | teward, note also that there are two separate tags: snap and snapcraft | 22:33 |
| kyrofa | But snapcraft.io only mentions one | 22:33 |
| cory_fu | Hey, I'm hitting a strange error trying to build a classic snap | 22:37 |
| cory_fu | "classic confinement requires the core snap to be installed. Install it by running `snap install core`." | 22:37 |
| cory_fu | However, when I try to install that, I get this: | 22:37 |
| cory_fu | cannot install core snap "core" when core snap "ubuntu-core" is already present | 22:37 |
| zyga | cory_fu: hey | 22:38 |
| zyga | cory_fu: you can update snapd on your system | 22:38 |
| zyga | cory_fu: and track candidate/edge | 22:38 |
| kyrofa | cory_fu, yeah known issue. The newest snapd will migrate you from ubuntu-core to core | 22:38 |
| teward | kyrofa: https://github.com/ubuntudesign/snapcraft.io/issues/271 is relevant, and i have hailed someone on the rocket chat server apparently who pointed me to filing issues there | 22:38 |
| zyga | cory_fu: then some code will migrate ubuntu-core to core | 22:38 |
| teward | but you're not wrong | 22:38 |
| kyrofa | cory_fu, building a classic snap requires core | 22:38 |
| zyga | cory_fu: and you will be good to go | 22:38 |
| cory_fu | zyga: Sure. I'm currently using the snapd that came with xenial. How would I switch to candidate/edge? | 22:39 |
| kyrofa | cory_fu, do you have any snapd installed? | 22:40 |
| kyrofa | err, any snaps* | 22:40 |
| cory_fu | kyrofa: charm, snap-codelabs, and ubuntu-core | 22:40 |
| zyga | kyrofa: you don't have to purge state anymore | 22:41 |
| zyga | kyrofa: snapd does the migration | 22:41 |
| kyrofa | zyga, so he just needs to switch to ubuntu-core from edge? | 22:41 |
| zyga | kyrofa: yes | 22:41 |
| kyrofa | zyga, will that install the core snap from edge, then? | 22:41 |
| kyrofa | cory_fu, try `sudo snap refresh --edge ubuntu-core` | 22:42 |
| cory_fu | kyrofa: It said refreshed, but I still have ubuntu-core listed and snapcraft still fails missing core | 22:44 |
| kyrofa | cory_fu, then I refer you to zyga for the nice migration. I personally just purged snapd and reinstalled it | 22:45 |
| kyrofa | But that toasts your snaps too | 22:45 |
| cory_fu | kyrofa: I'm fine with that approach | 22:45 |
| kyrofa | cory_fu, then it'll install the `core` snap from the beginning, instead of `ubuntu-core` | 22:46 |
| cory_fu | Sounds good. After I apt remove snapd, how do I install the edge? | 22:46 |
| kyrofa | cory_fu, you don't need to | 22:47 |
| kyrofa | Just install snapd again, and install a snap | 22:47 |
| kyrofa | Or just `sudo snap install core` | 22:47 |
| kyrofa | cory_fu, refreshing to edge was an attempt to get that migration to run | 22:47 |
| kyrofa | But it didn't. Not sure how it works | 22:47 |
| cory_fu | Ah, gotcha | 22:47 |
| stokachu | is $SNAP* exposed in the hooks/configure scripts? | 22:49 |
| pedronis | zyga: notice I think that once you have switched it probably takes 5 minutes or so for the update to happen | 22:49 |
| kyrofa | stokachu, yes | 22:49 |
| stokachu | kyrofa, cool thanks | 22:50 |
| kyrofa | pedronis, good to know, thank you | 22:50 |
| cory_fu | kyrofa: That worked fine. Thanks. Is there any plan to backport that in some way so that lxd containers (I'm using ubuntu-xenial) or other new xenial instances will be able to use classic snaps out of the box? | 23:00 |
| kyrofa | cory_fu, yeah, eventually that migration will hit everyone | 23:00 |
| kyrofa | cory_fu, you're just riding the wave ;) | 23:01 |
| cory_fu | kyrofa: Is it possible to use the core snap inside a lxd container? I'm getting a mount error when trying to install it, even when using -c security.privileged=true | 23:09 |
| kyrofa | cory_fu, you're a little beyond my expertise. Have you seen https://www.stgraber.org/2016/12/07/running-snaps-in-lxd-containers/ ? | 23:10 |
| cory_fu | kyrofa: I hadn't, thanks. Possibly I need newer versions of lxd, or such. I will continue to investigate tomorrow. | 23:12 |
| cory_fu | For now, have a good evening. o/ | 23:12 |
| kyrofa | cory_fu, you as well! | 23:13 |
| === ahoneybun is now known as ahoneybun_ | ||
| mup | PR snapcraft#1097 closed: lifecycle: print the command needed to clean the dirty part <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1097> | 23:30 |
| mup | Bug #1661436 opened: snap download can't find gadget or kernel snap from a branded store <Snappy:New> <https://launchpad.net/bugs/1661436> | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!