| mup | PR snapcraft#1113 opened: repo: cache stage packages for faster future use <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1113> | 00:06 |
|---|---|---|
| === markusfluer1 is now known as markusfluer | ||
| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest57353 | ||
| === JanC_ is now known as JanC | ||
| liuxg | ogra_, I am now using your proxy snap for building snap. when I build nodejs project, it still downloads the node-v4.4.4-linux-x64.tar.gz from internet. it is not cached. is there any way to solve the problem? it is really slow. | 06:43 |
| mup | PR snapd#2771 closed: debian: update changelog from releases 2.22.{1,2} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2771> | 07:04 |
| mup | PR snapd#2558 closed: snapstate: move refresh from a systemd timer to the internal snapstate Ensure() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2558> | 07:08 |
| mup | PR snapd#2764 closed: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2764> | 07:12 |
| mup | PR snapd#2754 closed: tests: improve debug when the core transition test hangs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2754> | 07:15 |
| mup | PR snapd#2772 closed: interfaces: allow nice/setpriority to 0-19 values for calling process by default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2772> | 07:33 |
| mup | PR snapd#2750 closed: interfaces/default: don't allow TIOCSTI ioctl <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2750> | 07:35 |
| mup | PR snapd#2796 closed: Fix checks failing on code formatting <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2796> | 07:36 |
| mup | PR snapd#2797 opened: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <https://github.com/snapcore/snapd/pull/2797> | 07:55 |
| mup | Bug #1662452 opened: A snap tries to continue setting up a systemd service, even if download failed <Snappy:New> <https://launchpad.net/bugs/1662452> | 08:22 |
| log-snap | hi there just wanted to include an icon as mentioned here [1], but snapcraft calls it unexpected. Was "icon" deprecated? And how do i include my icon now? .desktop? | 08:32 |
| log-snap | 1: https://snapcraft.io/docs/build-snaps/metadata | 08:32 |
| mup | PR snapd#2757 closed: tests: add regression spread test for #1660941 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2757> | 08:34 |
| mup | PR snapd#2798 opened: interfaces/builtin: instead of just /proc/bus/pci/devices allow full read access on /proc/bus/pci <Created by morphis> <https://github.com/snapcore/snapd/pull/2798> | 08:40 |
| morphis | mvo: can you add the PR above for 2.23? | 08:40 |
| mvo | morphis: sure | 08:42 |
| morphis | mvo: thanks! | 08:45 |
| mup | PR snapd#2799 opened: tests: fix pattern and use MATCH in find-private <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2799> | 08:57 |
| mup | PR snapd#2795 closed: Only add aliases field when we have aliases <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2795> | 09:01 |
| ogra_ | liuxg, well, my packageproxy only operates .deb packages ... i suspect you would have ot hack up the nodejs plugin to use a local tarball for this | 09:38 |
| liuxg | ogra_, yeah, this is too troublesome.. the developers in my last sprint was desperate in downloading the package again and again. | 09:39 |
| ogra_ | liuxg, well, the plugins are only python. cant be to hard to make this one use a local tarball instead of downloading it | 09:41 |
| ogra_ | liuxg, also file a bug so the snapcrafters can add an option for this | 09:41 |
| ogra_ | there is one :) | 09:41 |
| liuxg | ogra_, yeah, I will do it. thanks. really? what is the bug number? | 09:41 |
| zyga | I thin the issue is that snapcraft often requires "gah, doesn't work - snapcraft clean" workflow | 09:42 |
| ogra_ | sergiusens, is it somehow possible to prevent the nodejs plugin from downloading the tarball all the time ? | 09:42 |
| zyga | and then you are stuck with downloading over and over | 09:42 |
| ogra_ | liuxg, i said you should file a bug :) | 09:42 |
| liuxg | ogra_, OK. I will do that, thanks | 09:42 |
| ogra_ | zyga, right, but you should be able to make it skip the downloading and make it use a local version of the tarball | 09:42 |
| ogra_ | that cant be to hard | 09:43 |
| zyga | ogra_: no, it just just be smarter | 09:43 |
| sergiusens | ogra_: implementing a fix for the bug ev logged a while back will do the trick | 09:43 |
| ogra_ | zyga, what if you dont want to download it at all ? | 09:43 |
| mup | PR snapd#2797 closed: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2797> | 09:43 |
| zyga | ogra_: you don't want to hand-hold the process, you just want the process to be less silly | 09:43 |
| ogra_ | smartness wont help | 09:43 |
| zyga | ogra_: I don't understand what you mean, | 09:44 |
| zyga | ogra_: if your snapcraft is offline then it will work offline | 09:44 |
| zyga | ogra_: if it is not offline, you need to get them | 09:44 |
| zyga | ogra_: and be super smart on caching | 09:44 |
| sergiusens | ogra_: I am going to implement something similar to the python plugin where if it is staged (dump it) you won't need to download | 09:44 |
| ogra_ | most of the times i agree ... but in a presentation where you already use a package proxy for the debs and your internet is 2G based you better down download at all | 09:44 |
| zyga | ogra_: adding a gazillion options won't be useful as nobody will really feel good about that (hard to find, quirky, why it it even an option) | 09:44 |
| ogra_ | make it not an option, make it an env var (and consider not documenting it) | 09:45 |
| zyga | program --dont-be-silly-and-broken=3 | 09:45 |
| sergiusens | ogra_: when I get xenial on my tablet I will be able to work from bed and be much more productive btw ;-) | 09:45 |
| ogra_ | zyga, rather --dont-use-the-great-chinese-wall | 09:45 |
| ogra_ | thats the issue here | 09:46 |
| zyga | so what are the options? | 09:46 |
| zyga | where do people get those bits from? | 09:46 |
| zyga | moon? :) | 09:46 |
| ogra_ | zyga, in the workshop the presenter shares them | 09:46 |
| zyga | I see | 09:46 |
| ogra_ | he downloaded it in davance over night | 09:46 |
| zyga | if snapcraft had caching sufficient to do "snapcraft cache" | 09:47 |
| zyga | then one option would be to copy that tree over to everyone | 09:47 |
| zyga | but there are many things that are tricky to do caching / offline work right | 09:47 |
| ogra_ | the point is that liuxg has limited time forhis workshops ... debs already use a package proxy ... but the plugin still downloads | 09:47 |
| zyga | I bet sergiusens know this far better than I even imagine the problem | 09:47 |
| ogra_ | yeah, i'm fine with copying a cache ... as long as you cover this usecase | 09:48 |
| ogra_ | not everything needs to be an option ;) you can make it a hidden feature, a cache dir to copy, a hidden env var etc | 09:48 |
| liuxg | zyga, ogra_, yes, that is the point. during a workshop, the download of the nodejs can be tedious, even in my daily work. it takes a few minutes to get it done. | 09:49 |
| liuxg | ogra_, I have reported a bug for it. https://bugs.launchpad.net/snapcraft/+bug/1662464, thanks for your help | 09:52 |
| mup | Bug #1662464: node-v4.4.4-linux-x64.tar.gz is downloaded again and again during the build of a snap <Snapcraft:New> <https://launchpad.net/bugs/1662464> | 09:52 |
| liuxg | sergiusens, is there any way to use the nodejs from the cache? thanks | 09:54 |
| JerryKao | mvo, ping | 10:04 |
| mvo | JerryKao: pong | 10:05 |
| JerryKao | hi mvo, how to check snapd version in core system? | 10:06 |
| ogra_ | snap version | 10:06 |
| ogra_ | like on a classic system | 10:06 |
| JerryKao | ogra_, thanks | 10:07 |
| mup | PR snapd#2799 closed: tests: fix pattern and use MATCH in find-private <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2799> | 10:32 |
| mvo | ara: one quick question - what is the output of "snap version" in the non-chatty version that fails for you? | 10:34 |
| ara | mvo, 2.22.1 | 10:35 |
| mvo | thanks | 10:37 |
| mup | Bug #1662357 changed: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):New> <https://launchpad.net/bugs/1662357> | 10:37 |
| ogra_ | mvo, would you be opposed if i made lsb_relese non-executable with a build time hack on the core images ... we're always getting bugs for it | 10:38 |
| mvo | ogra_: hm, can we remove it entirely? | 10:38 |
| ogra_ | i can rm it but not remove the package easily | 10:38 |
| ogra_ | we also need it in the classic tarball ... there i made it work fine | 10:39 |
| mvo | ogra_: right, either way is fine with me then, rm the binary feels slightly cleaner | 10:39 |
| ogra_ | no prob, will do that then ... | 10:40 |
| mvo | ta | 10:41 |
| mup | PR snapd#2677 closed: snap: improve the error message for `snap try` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2677> | 11:35 |
| === hikiko is now known as hikiko|ln | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2800 opened: daemon: show "$snapname (delta)" in progress when downloading deltas <Created by mvo5> <https://github.com/snapcore/snapd/pull/2800> | 12:15 |
| mup | PR snapd#2801 opened: snap-confine: add the key for which hsearch_r fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/2801> | 12:23 |
| kw | Hi guys, has anyone here tried to upgrade/change the kernel in ubuntu core? | 12:27 |
| zyga | kw: hey, can you be more specific? the kernel is reglarly updated | 12:28 |
| ogra_ | zyga, well ... | 12:29 |
| kw | Yes, sure. Let me rephrase. | 12:29 |
| ogra_ | kw, what hardware ? | 12:30 |
| kw | I'm using up board with ubuntu core installed. The original goal is to overclock the cpu frequency a little bit but it seems that the kernel wouldn't allow. ( not sure how to confirm) | 12:32 |
| kw | We have a working one beside (up board with legacy ubuntu 14.04 and higher cpu freq) | 12:33 |
| kw | that's probably where the guess is from | 12:33 |
| kw | so I'm thinking the possibilities to upgrade the kernel in ubuntu core | 12:34 |
| kw | it would be appreciated, if anyone could give any recommendation, | 12:35 |
| zyga | kw: you will need to roll your own kernel snap | 12:35 |
| zyga | kw: and a model assertion that describes that | 12:35 |
| zyga | kw: and (AFAIK, could be wrong) a gadget snap | 12:35 |
| kw | yes ,I was also thinking about that and I found this | 12:36 |
| kw | https://docs.ubuntu.com/core/en/guides/build-device/image-building | 12:36 |
| kw | not sure if this is the manual I should follow. the information is limited though | 12:36 |
| zyga | kw: the kernel and gadget need to be signed by your "brand" key | 12:38 |
| zyga | kw: you will need to build an image with that assertion | 12:38 |
| zyga | kw: you cannot change a kernel on an already running device (only the brand can do that) | 12:38 |
| zyga | kw: not sure, | 12:38 |
| ogra_ | zyga, hmm, its an ATOM, i would expect our pc kernel snap to work on this | 12:41 |
| zyga | ogra_: yeah, it should work | 12:41 |
| kw | I see | 12:41 |
| ogra_ | i rather think you want your own gadget and modify cmdline options | 12:41 |
| kw | is there tutorial or instruction for creating custom kernel and gadget snap? | 12:42 |
| ogra_ | and possibly ship some sysctl.d files | 12:42 |
| ogra_ | kw, https://github.com/snapcore/pc-amd64-gadget | 12:43 |
| ogra_ | pull that, install snapcraft on your desktop ... then run snapcraft in the toplevel dir | 12:43 |
| ogra_ | and indeed make changes before calling snapcraft as needed :) | 12:43 |
| kw | yes, this also works for me. thanks | 12:44 |
| ogra_ | with ubuntu-image you just need to use the --extra-snaps option and point to your snap then | 12:45 |
| ogra_ | the local one will override the one from the store | 12:45 |
| kw | I see. | 12:47 |
| kw | I think I'll give it a try first and see how it goes. | 12:48 |
| kw | I'm not familiar with snap enough yet | 12:48 |
| kw | many thanks :) | 12:48 |
| === hikiko|ln is now known as hikiko | ||
| ogra_ | just ask if you run into more issues :) | 12:53 |
| mup | PR snapd#2801 closed: snap-confine: add the key for which hsearch_r fails <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2801> | 13:13 |
| joedborg | hey all | 13:22 |
| joedborg | has anyone got experience with creating a snap package where git binary is needed for the application you're snapping (e.g. NPM)? | 13:22 |
| ogra_ | add git-core to build packages or some such | 13:23 |
| ogra_ | or just the toplevel 2git" | 13:23 |
| ogra_ | *"git" | 13:23 |
| zyga | joedborg: could be hairy (it will pull in perl and a zoo of other bits I bet) but you can try | 13:24 |
| ogra_ | thoug, doesnt the nodejs plugin provide all bits needed for npm builds ? | 13:24 |
| joedborg | i've tried adding it as a build-package and stage-package as well as a separate part and build it | 13:25 |
| joedborg | but it always says that the "https helper is missing" | 13:25 |
| joedborg | so it can't pull any https repos | 13:25 |
| joedborg | I'm trying to package bower | 13:25 |
| joedborg | NPM was just an example | 13:25 |
| ogra_ | try libcurl4-openssl-dev in build-packages | 13:26 |
| joedborg | yep, I've tried that too | 13:26 |
| ogra_ | i think that provides https | 13:26 |
| joedborg | as well as - gettext | 13:26 |
| joedborg | - libssl-dev | 13:26 |
| joedborg | - libcurl4-openssl-dev | 13:26 |
| joedborg | - libexpat1-dev | 13:26 |
| joedborg | and adding the --with-curl and --with-expat flags to the configure | 13:27 |
| joedborg | and then given it home and network plugs | 13:27 |
| ogra_ | err, wait, you are trying to run git *inside* your snap at execution time ?? | 13:28 |
| zyga | ogra_: yes | 13:29 |
| ogra_ | ah, i misunderstood | 13:29 |
| zyga | joedborg: I'd suggest trying to usea classic confinement snap | 13:29 |
| joedborg | zyga: yeah, I made the snap like that originally but want to try to get it into strict confinement | 13:29 |
| zyga | joedborg: depending on what you want from git (I suspect npm just wants to clone) | 13:32 |
| zyga | joedborg: you could build a super small git version in your snap | 13:32 |
| zyga | joedborg: just enough to have basic bits written in C | 13:32 |
| zyga | joedborg: should be simple and fast | 13:32 |
| zyga | joedborg: (build git from source, disable all the useless option) | 13:32 |
| joedborg | zyga: you mean write my own, calling libgit? | 13:34 |
| zyga | joedborg: no, just build upstream git but trim all the deps | 13:34 |
| zyga | joedborg: npm doesn't need 99% of git, just git clone I suspect | 13:34 |
| zyga | joedborg: and a minmal build of git from source should be good | 13:34 |
| zyga | joedborg: and you can pick any version you want :) | 13:34 |
| joedborg | zyga: yes, that's what I've also been trying, but if I cannot build the current source with git-http, I think I'd have the same issue even if i cut the bloat out, right? | 13:35 |
| zyga | joedborg: what's the problem with building? | 13:36 |
| joedborg | zyga: git: | 13:36 |
| joedborg | source: https://github.com/git/git | 13:36 |
| joedborg | source-type: git | 13:36 |
| joedborg | source-depth: 1 | 13:36 |
| joedborg | plugin: autotools | 13:36 |
| joedborg | configflags: | 13:36 |
| joedborg | - --with-curl | 13:36 |
| zyga | joedborg: bloat may be built-in (deps) | 13:36 |
| joedborg | - --with-expat | 13:36 |
| joedborg | build-packages: | 13:36 |
| joedborg | - gettext | 13:36 |
| joedborg | - libssl-dev | 13:36 |
| joedborg | - libcurl4-openssl-dev | 13:36 |
| joedborg | - libexpat1-dev | 13:36 |
| joedborg | stage-packages: | 13:36 |
| joedborg | - libcurl3 | 13:36 |
| zyga | joedborg: rather than pasting here please use pastebin, irc likes things this way | 13:36 |
| joedborg | this builds without warnings | 13:36 |
| zyga | joedborg: does it work in the end? | 13:36 |
| zyga | joedborg: note that I'm not a snapcraft expert, I work on snapd internals | 13:37 |
| zyga | joedborg: perhaps sergiusens or kyrofa can give you better advice | 13:37 |
| joedborg | zyga: okay, here is is as a Gist https://gist.github.com/joedborg/c496eaa6de26a14d73b55a6db372f531 | 13:37 |
| joedborg | and the build looks okay, I even see "checking if Curl supports SSL... yes" | 13:39 |
| zyga | joedborg: and what is the part that doesn't work? | 13:40 |
| joedborg | zyga: but then, if i install with --devmode (to see what's going on) and try to get bower to pull something (which is done via git) I get "Failed to execute "git ls-remote --tags --heads https://github.com/jquery/jquery-dist.git", exit code of #128 fatal: Unable to find remote helper for 'https'" | 13:42 |
| zyga | joedborg: what probably happens is that your git looks for /usr/bin/something | 13:44 |
| zyga | joedborg: and that's not found there | 13:44 |
| zyga | joedborg: apart from teaching git to use $SNAP and be smarter | 13:45 |
| zyga | joedborg: I'd suggest configuring with --prefix=/snap/$SNAP_NAME/current/usr | 13:45 |
| zyga | joedborg: and changing the installed files with organize | 13:45 |
| zyga | joedborg: so that your snap contains just the /usr part | 13:45 |
| zyga | joedborg: I did that a few times when apps love to hardcode where to run stuff from | 13:45 |
| zyga | joedborg: otherwise it just looks for files in the usual spot and they are not there | 13:46 |
| joedborg | zyga: that makes sense, because the helper should be in "/snap/libexec/git-core" | 13:46 |
| zyga | joedborg: look at the output of `dpkg -L git` | 13:46 |
| zyga | joedborg: this is where git keeps all the commands | 13:46 |
| joedborg | zyga: so I guess it's an environment problem | 13:46 |
| zyga | joedborg: play with --prefix and other bits | 13:46 |
| zyga | joedborg: I bet you can get it to work | 13:46 |
| zyga | joedborg: environment? | 13:47 |
| joedborg | zyga: if that's the case, I think I'd just need to add libexec/git-core to $PATH inside the snap | 13:48 |
| zyga | joedborg: depending on how git runs those | 13:48 |
| zyga | joedborg: if it uses PATH to search, yeah | 13:48 |
| zyga | joedborg: if it has a hard-coded path, you need to do more | 13:48 |
| joedborg | I've just got to work out how to do that from snapcraft | 13:48 |
| zyga | joedborg: --prefix=/snap/yoursnapname/current/usr | 13:49 |
| zyga | joedborg: then use organize | 13:49 |
| zyga | joedborg: (in the part) | 13:49 |
| zyga | joedborg: to strip that so that only usr is placed in the prime dir | 13:49 |
| mup | PR snapd#2768 closed: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2768> | 13:51 |
| ogra_ | https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables#Global-Behavior | 13:51 |
| ogra_ | you migth want to use a wrapper around git that sets some of these global vars ;) | 13:51 |
| zyga | ogra_: yeah, nice | 13:51 |
| zyga | joedborg: GIT_EXEC_PATH | 13:51 |
| zyga | though I think building git with correct prefix is pretty good too | 13:52 |
| joedborg | zyga: trying the prefix first, can't work the syntax out for setting envars in snapcraft yaml | 13:52 |
| zyga | joedborg: you need a wrapper script or latest snapcraft | 13:53 |
| zyga | (it's a new feature in snapcraft) | 13:53 |
| zyga | sergiusens: ^^ | 13:53 |
| ogra_ | ah, did that land already ? | 13:53 |
| zyga | not sure, it might have | 13:54 |
| joedborg | zyga: i'm on 2.26 | 13:54 |
| ogra_ | i saw a commit but didnt follow the status | 13:54 |
| joedborg | zyga: you get the same issue when setting prefix - i assume because path still isn't pointing to the libexec/git-core directory | 13:59 |
| zyga | joedborg: note that that is not on PATH in any distro either | 13:59 |
| zyga | joedborg: look at what git is doing internally | 13:59 |
| mup | PR snapd#2746 closed: interfaces: remove some syscalls already in the default policy plus comment cleanups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2746> | 14:00 |
| ogra_ | GIT_EXEC_PATH is the one that needs to point to libexec/git-core | 14:00 |
| ogra_ | (check on any ubuntu install with "git --exec-path" ... it should return /usr/lib/git-core) | 14:01 |
| ogra_ | (which has all the binaries) | 14:01 |
| zyga | ogra_: question is, how does git decide on that value? | 14:01 |
| ogra_ | why does that matter as long as it respects your override | 14:02 |
| zyga | ogra_: it matters to know how git works as this may be something we may fix in general | 14:02 |
| ogra_ | i guess it is set at build time normally | 14:02 |
| zyga | ogra_: depending on ... ? prefix? | 14:02 |
| ogra_ | combo ... | 14:02 |
| ogra_ | at build time i guess prefix is just /usr | 14:03 |
| ogra_ | so it combines with the distros typical libexec path | 14:03 |
| ogra_ | which is lib in our case | 14:03 |
| joedborg | ogra_ zyga: would that be baked in when git is packaged for apt? i don't think we have any GIT_* envars set | 14:07 |
| ogra_ | the vars are for user overrides ... so indeed they are not set by the package :) | 14:07 |
| ogra_ | they are nontheless the right thing to use in a snap | 14:07 |
| joedborg | orga_: do you know if this can be passed in via snapcraft? | 14:08 |
| ogra_ | https://github.com/snapcore/snapcraft/pull/1103 is the commit adding support for that to snapcraft btw | 14:08 |
| mup | PR snapcraft#1103: meta: support for the environment keyword <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103> | 14:08 |
| ogra_ | merged 23h ago | 14:08 |
| joedborg | okay, I'll pull master down and built it and try with that | 14:09 |
| ogra_ | hah | 14:09 |
| ogra_ | look at the changed files there ... there is even: | 14:10 |
| ogra_ | + PATH: $PATH:$SNAP/libexec/git-core | 14:10 |
| ogra_ | + GIT_TEMPLATE_DIR: $SNAP/share/git-core/templates | 14:10 |
| ogra_ | so exactly what you want | 14:11 |
| mup | PR snapd#2802 opened: snap-confine: make sc_map_search/read_number take const const char * arguments <Created by mvo5> <https://github.com/snapcore/snapd/pull/2802> | 14:20 |
| joedborg | ogra_: just getting through the snapcraft master build :) | 14:24 |
| mup | PR snapd#2803 opened: asserts: introduce a variant of model assertions for classic systems <Created by pedronis> <https://github.com/snapcore/snapd/pull/2803> | 14:30 |
| joedborg | ogra_: seems to still fail the YAML check | 14:38 |
| mup | PR snapd#2770 closed: interfaces/core-support: allow modifying snap rsyslog configuration <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2770> | 14:56 |
| jdstrand | ogra_: fyi ^ | 14:59 |
| ogra_ | \o/ | 14:59 |
| ogra_ | jdstrand, next is timesyncd :) | 14:59 |
| jdstrand | ogra_: I'm sending up a PR for /etc/systemd/timesyncd.conf now | 14:59 |
| ogra_ | hah, snap | 15:00 |
| jdstrand | yep! :) | 15:00 |
| jdstrand | :) | 15:00 |
| ogra_ | and then the more complex sysctl.d | 15:00 |
| jdstrand | oh, I haven't seen that one. is there a bug? | 15:00 |
| ogra_ | though thats only complex on the configure hook side ... | 15:00 |
| ogra_ | hmm, not sure, let me search | 15:01 |
| ogra_ | bug 1485683 and bug 1552679 | 15:01 |
| mup | Bug #1485683: /etc/sysctl.d is not applied on boot <Snappy:Expired> <https://launchpad.net/bugs/1485683> | 15:01 |
| mup | Bug #1552679: snappy config ubuntu-core should get support for manipulating /etc/sysctl.conf <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1552679> | 15:01 |
| ogra_ | hmm. probably only the latter one | 15:02 |
| jdstrand | ogra_: do you want to modify /etc/sysctl.conf or /etc/sysctl.d/{,[0-9][0-9]-}snap*.conf ? | 15:03 |
| ogra_ | yeah, one fixed filename would be enough though | 15:03 |
| ogra_ | i doubt we will use multiple files since the configure hook needs to generate all of it on every run | 15:04 |
| jdstrand | ogra_: shall I send something up for that? | 15:04 |
| ogra_ | that would be awesome | 15:04 |
| jdstrand | ok | 15:04 |
| jdstrand | ogra_: will you be applying the sysctl values in the config hook or some other way? | 15:06 |
| ogra_ | the config hook will create or re-create the file if it runs | 15:07 |
| jdstrand | ogra_: will the config hook also run 'sysctl -p /etc/sysctl.d/<file>'? | 15:08 |
| ogra_ | i'd like a more atomic way, but the current implementation of the config handling doesnt provide that ... i could create a file per option but i fear that gets messy | 15:08 |
| ogra_ | oh, i didnt think of that, yeah it should immediately apply the new settings with sysctl -p | 15:08 |
| mterry | Elleo: so my in-progress unity8 interface had some maliit access bits and jdstrand pointed me to your maliit interface branch. jdstrand, how granular do we want those to be? Elleo, do we plan to ship the OSK separate from the unity8 snap? | 15:09 |
| Elleo | mterry: when I'd suggested including maliit access in the unity8 interface tvoss wasn't very keen on the idea, so might be a good idea to check up on his thinking there | 15:12 |
| zyga | mterry: FYI: one snap can use many interfaces | 15:12 |
| Elleo | mterry: but we're likely to have scenarios where we want the OSK but not unity8 (e.g. probably in kiosk cases) | 15:13 |
| jdstrand | I figured that maliit and unity8 interfaces would be separate, but unity8-session snap would slots both | 15:13 |
| mterry | zyga: I know, it's just a matter of what we want app developers to put: "[maliit, mir, unity8]" or just [mir, unity8] | 15:13 |
| jamespage | jdstrand, hey I understand you might be the person to talk to about getting auto-aliases added to my snaps in the snapstore - is that right? | 15:13 |
| jdstrand | jamespage: I am one person who can help with that, yes | 15:14 |
| mterry | Elleo, jdstrand: OK I can take the maliit bits out of u8 | 15:14 |
| jdstrand | mterry: I think the former ([maliit, mir, unity8]). this can all be made the default in the sdk | 15:14 |
| jdstrand | for the unity8 tempalte | 15:14 |
| mterry | yar | 15:15 |
| mup | PR snapd#2804 opened: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2804> | 15:30 |
| jdstrand | ogra_: fyi, ^ | 15:31 |
| === qengho_ is now known as qengho | ||
| ogra_ | yeah, just saw it pass on telegram :) | 15:31 |
| jdstrand | fun :) | 15:31 |
| ogra_ | mup is everywhere ! | 15:31 |
| jdstrand | heh | 15:31 |
| ryebot | We're snapping an application that calls out to iptables - is there a way to do that without classic confinement? We've looked into using the network-control plug, but that doesn't appear to have the juju we need. | 15:35 |
| ogra_ | ogra@localhost:~$ snap interfaces|grep firewall | 15:36 |
| ogra_ | :firewall-control - | 15:36 |
| ogra_ | :) | 15:36 |
| ogra_ | not sure thats available on classic installs though ... | 15:37 |
| ogra_ | (i see it exposed there ...) | 15:37 |
| ryebot | Thanks ogra_ | 15:40 |
| ppisati | ogra_: i'm rebuilding a snapdragon image from scratch, and it stops at "/scripts/local-premount" - does it ring any bell? | 15:43 |
| ogra_ | ppisati, how did you rebuild ? | 15:43 |
| ppisati | ogra_: right, i didn't explain well enough | 15:43 |
| ogra_ | (do you have a "writable" label, else the boot will wait for 2min til it times out) | 15:44 |
| ppisati | ogra_: if i use the kernel from the store, everything is fine | 15:44 |
| ogra_ | ah | 15:44 |
| ppisati | ogra_: my problem only happens with a src built kernel snap | 15:44 |
| ppisati | i'm using the -stable channel FWIW | 15:44 |
| ogra_ | ppisati, there is a bug in the kernel plugin | 15:44 |
| ogra_ | sergiusens just worked on a patch afaik | 15:44 |
| ogra_ | (modules and firmware land in the wrong dir) | 15:44 |
| ppisati | oh | 15:45 |
| ppisati | lp1658177 | 15:45 |
| ogra_ | in /lib/firmware and /lib/modules ... while they should be in /firmware and /modules | 15:45 |
| ppisati | ogra_: i was tryting to follow up to the snapdragon's guy on the ml | 15:45 |
| ppisati | ogra_: so i was trying to reproduce all the steps to generate a new image with a custom kernel | 15:46 |
| ogra_ | with the eragon board ? | 15:46 |
| ppisati | ogra_: nope, snapdragon | 15:46 |
| ogra_ | yeah, seems thats one of the main issues he hits | 15:46 |
| ogra_ | hmm | 15:46 |
| ppisati | sergiusens: do you have anything for lp1658177? | 15:46 |
| ppisati | ogra_: i don't know, it appears he has many issues | 15:49 |
| ogra_ | yeah | 15:49 |
| ppisati | ogra_: but i wanted to be sure that our kernel (and our building workflow was fine) | 15:49 |
| ogra_ | he showed his demsg and there his kernel only has half the cmdline | 15:49 |
| ppisati | ogra_: so tried to build eveyrthing from scratch and i hit this | 15:49 |
| ppisati | ogra_: right | 15:49 |
| ryebot | ogra_: that worked, thanks! | 15:50 |
| ogra_ | :) | 15:50 |
| === sergiusens_ is now known as sergiusens | ||
| kw | For some reason, we had to port some open source tools as snap package that we can continue what we wanted to do. Can we just upload those tools to the store? I saw that for some package, there are different versions of it. Is there any rules to manage this currently? | 16:36 |
| kw | This might be a strange question though | 16:36 |
| zyga | kw: hey | 16:43 |
| zyga | kw: you can just upload those to the store | 16:43 |
| zyga | kw: versions have no relevance in the store | 16:43 |
| zyga | kw: it's just a convenience for the user | 16:43 |
| zyga | kw: but it doesn't decide on updates or anything like that | 16:43 |
| mup | PR snapd#2798 closed: interfaces/builtin: instead of just /proc/bus/pci/devices allow full read access on /proc/bus/pci <Created by morphis> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2798> | 16:57 |
| qengho | kw: The most recent update (" that is applied to the "channel" a user is tracking becomes what is received by the user. The "version" is information for brains, not computers. | 16:58 |
| qengho | kw: The most recent update ("revision") that is applied to the "channel" a user is tracking becomes what is received by the user. The "version" is information for brains, not computers. | 16:58 |
| mup | PR snapd#2805 opened: snap: improve message after `snap refresh pkg1 pkg2` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2805> | 17:04 |
| pmcgowan | ogra_, there is no db image at http://cdimage.ubuntu.com/ubuntu-core/16/stable/ | 17:23 |
| pmcgowan | which https://developer.ubuntu.com/core/get-started/dragonboard-410c points to | 17:24 |
| ogra_ | pmcgowan, http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ | 17:24 |
| pmcgowan | yeah but | 17:24 |
| ogra_ | slangasek, can we get that missing symlink too ? | 17:24 |
| pmcgowan | thanks | 17:24 |
| mup | PR snapcraft#1085 closed: snapcraft: fix or ignore PEP8 static errors <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1085> | 17:25 |
| slangasek | "db image"? | 17:25 |
| slangasek | oh, dragonboard | 17:25 |
| ogra_ | yeah "insider speak" :P | 17:25 |
| slangasek | sorry, seems to be a bad symlink | 17:25 |
| ogra_ | np | 17:25 |
| slangasek | because of a differing filename | 17:25 |
| ogra_ | 96boards insists on the numbering there | 17:26 |
| slangasek | fixed | 17:26 |
| ogra_ | because there are multiple dragonboards | 17:26 |
| ogra_ | thanks ! | 17:26 |
| pmcgowan | ogra_, the reason I was getting it is my current install won't refresh any snaps, was that a known error at some point? | 17:26 |
| pmcgowan | the downloads just hang | 17:26 |
| ogra_ | pmcgowan, oh, i have the same burt was blaming my old install from nov. | 17:27 |
| ogra_ | zyga, ^^^^ | 17:27 |
| slangasek | ogra_: sure - the script I inherited from mvo didn't name it that way. Guess I'll update the script | 17:27 |
| ogra_ | slangasek, yes please | 17:27 |
| pmcgowan | I have an oldish core but it used to work | 17:27 |
| ogra_ | pmcgowan, right ... we didnt get anywhere debugging that on my board | 17:27 |
| ogra_ | core 16.04.1 551 canonical - | 17:27 |
| ogra_ | thats what i'm stuck at | 17:28 |
| pmcgowan | I have 717 | 17:28 |
| zyga | ogra_: mmm | 17:28 |
| ogra_ | but it doesnt download anything at all ... there is a macroon issue i think | 17:28 |
| ogra_ | zyga, so pmcgowan sees similar issues with not being able to update on a dragonboard | 17:28 |
| zyga | I don't remember the issue exactly | 17:28 |
| ogra_ | macraoon auth issue iirc | 17:28 |
| zyga | hmmm | 17:28 |
| zyga | ah | 17:29 |
| pmcgowan | I entered this bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603 | 17:29 |
| zyga | I know | 17:29 |
| mup | Bug #1662603: snap refresh hang during download <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662603> | 17:29 |
| zyga | pmcgowan: move aside /root/.snap please | 17:29 |
| ogra_ | in fact Chipaca actually debugged it more woth me than you | 17:29 |
| zyga | pmcgowan: it's fixed now, just get that out of the way and it will refresh | 17:29 |
| zyga | pmcgowan: or more accurately, the config will apply | 17:29 |
| zyga | pmcgowan: (it breaks core snap tho) | 17:29 |
| zyga | pmcgowan: if you don't hae /root/.snap then this is a different bug | 17:29 |
| ogra_ | i dont think that was it | 17:29 |
| pmcgowan | I dont have ".snap" just snap | 17:30 |
| ogra_ | right | 17:30 |
| pmcgowan | zyga, I have a .snap in the user home dir | 17:31 |
| pmcgowan | but not for root | 17:32 |
| ogra_ | pmcgowan, can you file a bug, i dont think we have one yet ... i'll bring it up with the team tomorrow ... | 17:32 |
| pmcgowan | ogra_, I did see above | 17:32 |
| ogra_ | if it isnt my messed up install and you see it too i guess it is more serious | 17:32 |
| ogra_ | oops | 17:32 |
| pmcgowan | ogra_, I previously had that issue where current pointed to an old version, and fixed it manually somehow | 17:35 |
| ogra_ | yeah, that one was fixed | 17:35 |
| ogra_ | i remember this one | 17:35 |
| pmcgowan | really dont want to wipe it and start over | 17:35 |
| pmcgowan | zyga, let me know if I can add more info to the bug | 17:36 |
| zyga | pmcgowan: checking | 17:40 |
| pmcgowan | ogra_, the macaroon in auth.json on my desktop is very different than on the db, is that normal? | 17:40 |
| zyga | pcoca: can you refresh just core? | 17:40 |
| zyga | pmcgowan: can you refresh just core? | 17:41 |
| ogra_ | pmcgowan, i thought macaroons are device specific | 17:41 |
| zyga | pcoca: (sorry, bad tab-complete) | 17:41 |
| ogra_ | zyga, you cant refresh anything | 17:41 |
| pmcgowan | zyga, nope, that hangs | 17:41 |
| pcoca | zyga, no worries :) | 17:41 |
| zyga | pmcgowan: can you tell me what happens? snap refresh core | 17:41 |
| zyga | then show snap change for that | 17:41 |
| pmcgowan | sure I have that, it shows all the steps with downloading Doing | 17:42 |
| pmcgowan | but it never finishes | 17:42 |
| zyga | pmcgowan: specifically on the core? | 17:42 |
| zyga | hmmm | 17:42 |
| zyga | pmcgowan: can you show your syslog please | 17:42 |
| zyga | (journalctl) | 17:42 |
| pmcgowan | zyga, here is one in progress http://pastebin.ubuntu.com/23948993/ | 17:43 |
| pmcgowan | zyga, core was the same as that | 17:43 |
| zyga | pmcgowan: mir-kiosk is another thing, I'm thinking about core specifically | 17:43 |
| zyga | if you are stuck on broken core because you cannot update | 17:43 |
| zyga | vs all the snaps are broken but you can update core | 17:43 |
| zyga | pmcgowan: can you set your $HOME/.snap directory aside | 17:44 |
| zyga | the one in your home directory, not root | 17:44 |
| zyga | pmcgowan: then snap refresh core | 17:44 |
| pmcgowan | zyga, sure on sec | 17:44 |
| zyga | (snap abort changes if they are in progress) | 17:44 |
| ogra_ | pmcgowan, was your board off for a while ? | 17:45 |
| pmcgowan | ogra_, yes, at least two weeks | 17:45 |
| pmcgowan | maybe more | 17:45 |
| ogra_ | pmcgowan, Chipaca seems to have a theory that it is realted to that | 17:45 |
| ogra_ | yeah, mine too | 17:45 |
| zyga | mine too | 17:45 |
| zyga | but the PSU is too far away to turn on and I'm somewhat swamped with laundry up here so I won't reach it easily | 17:46 |
| pmcgowan | zyga, sudo snap refresh core | 17:47 |
| pmcgowan | error: cannot perform the following tasks: | 17:47 |
| pmcgowan | - Download snap "core" (892) from channel "stable" (cannot download non-free snap without purchase) | 17:47 |
| zyga | hmmmm | 17:48 |
| zyga | looks like a store bug or something I'm not familiar with | 17:48 |
| zyga | thanks for letting us know | 17:48 |
| ogra_ | just FYI i checked the store page and the core snap still says it is free | 17:55 |
| ogra_ | Price | 17:55 |
| ogra_ | Free | 17:55 |
| ogra_ | Licence | 17:55 |
| ogra_ | Other Open Source | 17:55 |
| zyga | jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/2778 | 18:25 |
| mup | PR snapd#2778: cmd: use safer functions in sc_mount_opt2str <Created by zyga> <https://github.com/snapcore/snapd/pull/2778> | 18:25 |
| zyga | failry short and simple, large part of the diff is boring format change caused by indent | 18:25 |
| seshu | Is there a way to make the entire system point to beta channel? Our QA wants to test autoupdate of our snap and its behavior. | 18:28 |
| kyrofa | seshu, channels are per-snap. Some snaps may not even have releases in beta | 18:29 |
| seshu | Kyrofa: If I point and download my snap from a particular channel, would a higher version upload to same channel gets pushed to device as autoupdate? | 18:30 |
| kyrofa | seshu, indeed | 18:31 |
| kyrofa | seshu, note though that the version has nothing to do with it-- it's the fact that it's a higher revision | 18:31 |
| kyrofa | Which is something assigned by the store. Essentially, since you uploaded another one, it gets a higher revision | 18:31 |
| seshu | kyrofa: Great! That's what I wanted to know. I guess, the update happens within next 6-12 hours after I upload and publish. | 18:33 |
| kyrofa | seshu, indeed, autoupdates happen four times a day, but the exact spacing is somewhat random so as to even the load | 18:33 |
| kyrofa | seshu, if you want to update immediately, you can use the `snap refresh` command | 18:33 |
| seshu | kyrofa: One more quick question...would a reboot or network event trigger such autoupdates...In case, I don't want the user to wait an entire day to get my updated snap on to his system | 18:34 |
| kyrofa | seshu, that's a good question, I'm not sure. zyga or mvo probably know | 18:35 |
| seshu | kyrofa: assuming mine is a system without terminal and keyboard...hence cannot do snap refresh | 18:35 |
| kyrofa | seshu, right, that's what this was made for | 18:35 |
| seshu | zyga: would a reboot or network or (any special) event trigger autoupdates...In case, I don't want the user to wait an entire day to get my updated snap on to his system and `snap refresh` is not an option for the user (as my system is headless and without keyboard attached). | 18:40 |
| mup | Bug #1662627 opened: snapd project also open for bugs <Snappy:New> <https://launchpad.net/bugs/1662627> | 18:41 |
| zyga | seshu: looking | 18:42 |
| zyga | seshu: not at this time | 18:43 |
| seshu | zyga: Thanks for checking. Would autoupdate happen atleast at first boot (after flashing the image or first time out-of-the-box) assuming the factory installs base image few months prior the actual deployment in the field and there may be updates to pre-bundled snaps (including core snap...which would need reboot)...coz in critical deployments any reboot after the install setup could cause major loss (i mean in factory automation set | 18:46 |
| rogpeppe | anyone know how I can run a command at bootstrap time in Snappy? (as root) | 18:47 |
| zyga | seshu: I think first boot is special, yes | 18:49 |
| zyga | seshu: we do a few things there, that should ensure that your snaps are fresh | 18:49 |
| mup | PR snapd#2803 closed: asserts: introduce a variant of model assertions for classic systems <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2803> | 18:49 |
| zyga | rogpeppe: can you be more specific (what do you mean by bootstrap?) | 18:49 |
| rogpeppe | zyga: for background, i have a raspberry pi with a hardware rtc but the kernel /dev/rtc device doesn't seem to work (I'm fairly sure I've configured the right overlay). I can use my own code to read the rtc and system clock time, but I don't know how to get that to run before the snap services do. | 18:50 |
| zyga | hmmm | 18:51 |
| zyga | ogra_: ^^ | 18:51 |
| rogpeppe | s/system clock time/set system clock time/ | 18:51 |
| zyga | (he's EOD now) | 18:51 |
| seshu | zyga: Great...that's nice...would you please point to any documentation or details to know more about the first boot behavior. | 18:51 |
| zyga | rogpeppe: that smells like a derivative gadget snap to me | 18:51 |
| zyga | seshu: I don't think we have any, let me check though | 18:51 |
| zyga | seshu: no we don't have that | 18:51 |
| rogpeppe | zyga: mm hmm. | 18:52 |
| rogpeppe | zyga: :( | 18:52 |
| rogpeppe | seshu: :) | 18:52 |
| zyga | seshu: I can write something tomorrow, it will be available on the snapd wiki | 18:52 |
| * rogpeppe can't type | 18:52 | |
| rogpeppe | zyga: that sailed right over my head. what's a "derivative gadget snap" ? | 18:52 |
| zyga | rogpeppe: you need to take the stock gadget snap for pi and patch it with that logic and build an image using that gadget snap | 18:52 |
| seshu | zyga: Sure helps! thanks a ton. | 18:52 |
| zyga | rogpeppe: unless there's a way to make that work with an add-on snap | 18:52 |
| zyga | rogpeppe: and an interface | 18:53 |
| zyga | rogpeppe: on a generic | 18:53 |
| seshu | Thank you kurofa and zyga. | 18:53 |
| zyga | rogpeppe: I think you want to chat with ogra_ tomorrow when he's around (europe) | 18:53 |
| zyga | rogpeppe: as he may have an easier suggestion | 18:53 |
| rogpeppe | zyga: so you're saying i can't use the stock ubuntu-core image? | 18:53 |
| zyga | seshu: stick around, I'll ping you tomorrow | 18:53 |
| * rogpeppe reads up about gadget snaps | 18:53 | |
| zyga | rogpeppe: well, I'm saying that we don't allow to stick unconfined stuff that runs as root on boot, yes | 18:54 |
| zyga | rogpeppe: https://github.com/snapcore/snapd/wiki/Gadget-snap | 18:54 |
| rogpeppe | zyga: ok, i suspected that was the case. | 18:54 |
| zyga | rogpeppe: https://github.com/snapcore/pi3-gadget | 18:54 |
| zyga | (there's a pi2-gadget repo as well) | 18:54 |
| rogpeppe | zyga: i'm wondering if it was a bad idea using snappy for this :) | 18:54 |
| zyga | rogpeppe: not if you want security and snaps people make :) | 18:54 |
| zyga | rogpeppe: if it is a common RTC we could perhaps support it in the gadget snap for pi in general | 18:55 |
| zyga | rogpeppe: and everyone could use it | 18:55 |
| rogpeppe | zyga: well, yeah, that would be nice. but being able to install temporary hacks to stop things crashing is also nice sometimes. I know those two things are oppositional :) | 18:55 |
| zyga | rogpeppe: I really suggest that you talk to ogra_ tomorrow to find a solution | 18:55 |
| zyga | rogpeppe: well | 18:55 |
| zyga | rogpeppe: temporary hack is something else | 18:55 |
| rogpeppe | zyga: i raised it on the mailing list a while ago | 18:55 |
| zyga | rogpeppe: just stick a systemd service | 18:55 |
| zyga | rogpeppe: (manually) | 18:55 |
| seshu | zyga: Sure... | 18:56 |
| zyga | rogpeppe: the shell you log into is not confined | 18:56 |
| rogpeppe | zyga: and poked again last week | 18:56 |
| rogpeppe | zyga: but no response | 18:56 |
| zyga | rogpeppe: you can experiment and do stuff like that | 18:56 |
| zyga | rogpeppe: I see, well, sometimes people are busy | 18:56 |
| rogpeppe | zyga: it's important that it needs to happen automatically on reboot | 18:56 |
| zyga | rogpeppe: a systemd unit will give you that | 18:56 |
| zyga | rogpeppe: you can even ensure it runs before snapd or other bits | 18:56 |
| zyga | rogpeppe: but that's a one-off hack | 18:56 |
| zyga | rogpeppe: for a way to incorporate that into snappy proper you have to talk to ogra or see if you can achieve this with your gadget snap | 18:57 |
| rogpeppe | zyga: i know, but it's a little bit frustrating as i'm actually trying to use this to control a household electrical system and it's a bit embarrassing when it fails after a power cut... | 18:57 |
| zyga | rogpeppe: I bet it is, | 18:57 |
| jdstrand | zyga: re 2778, ok | 18:59 |
| zyga | jdstrand: thanks | 19:00 |
| lool | jdstrand: hey ever seen something like this? http://paste.ubuntu.com/23949356/ | 19:02 |
| lool | this is a regular snap I had installed in devmode | 19:03 |
| lool | I changed it ot classic | 19:03 |
| lool | I tried a reboot to clear the loaded apparmor profiles but it didn't help | 19:03 |
| rogpeppe | zyga: so if i add, say, /etc/systemd/system/rtcsync.service and start it, that might do the job? | 19:03 |
| zyga | lool: is this on old snapd? | 19:03 |
| zyga | rogpeppe: I think so | 19:03 |
| lool | ubuntu@fbwedge100:~$ snap version | 19:03 |
| lool | snap 2.20.1ubuntu1 | 19:03 |
| lool | snapd 2.20.1ubuntu1 | 19:03 |
| jdstrand | lool: you can't use plugs with classic | 19:03 |
| rogpeppe | zyga: (assuming the right systemd magic - my head still hasn't migrated from upstart yet...) | 19:04 |
| zyga | lool: update, that's been fixed long ago | 19:04 |
| lool | zyga: ok | 19:04 |
| zyga | lool: (and regenerate the profile) | 19:04 |
| lool | jdstrand: ok, the store rejects plugs: [] in hooks though | 19:04 |
| zyga | (we should _really_ do that automatically soo) | 19:04 |
| zyga | lool: just don't do any plugs | 19:04 |
| jdstrand | lool: hmm? | 19:04 |
| lool | zyga: ok, will update and install the snap | 19:04 |
| jdstrand | lool: the store will let you know that you are using plugs with classic. what are you referring to? | 19:05 |
| zyga | lool: recent snapd lets you disable / enable a snap to refresh security | 19:05 |
| rogpeppe | zyga: i can always make my service pause for 10s when it runs to make sure that the other one gets to run first... | 19:05 |
| zyga | jdstrand: note that plugs on classic snap make sense with --jailmode and the store should not reject those | 19:05 |
| zyga | rogpeppe: the other one? | 19:05 |
| lool | jdstrand: no I mean a regular snap with plugs: [] will be rejected | 19:05 |
| zyga | rogpeppe: I refer you to excellent systemd documentation, it has all the bells and whistles you need | 19:05 |
| lool | sorry, a configure hook wiht plugs: [] | 19:06 |
| zyga | rogpeppe: you should set up correct dependencies | 19:06 |
| zyga | rogpeppe: and not use any timers | 19:06 |
| rogpeppe | zyga: ah, ok. i really must sit down one day and rtfm, yes | 19:06 |
| jdstrand | lool: I'd need to see the yaml. just drop 'plugs' at all if you don't want it rather than specifying an empty list? | 19:06 |
| rogpeppe | zyga: thanks | 19:06 |
| zyga | rogpeppe: systemd starts things in parallel so your 'wait for 10s' thing won't matter | 19:06 |
| zyga | rogpeppe: unless you express that as a dependency | 19:07 |
| rogpeppe | zyga: given that snappy creates the other service for me, is it possible to make it depend on my rtcsync service? | 19:07 |
| kyrofa | zyga, are dependent services supported, though? | 19:07 |
| lool | jdstrand: if I drop plugs entirely snapcraft rejects it | 19:07 |
| zyga | rogpeppe: yes, but I suggest to make your hack to run early on boot | 19:07 |
| zyga | rogpeppe: it really depends on what you want to do there | 19:07 |
| zyga | kyrofa: no | 19:07 |
| lool | jdstrand: https://github.com/lool/sonic-snap/blob/master/snapcraft.yaml | 19:08 |
| zyga | kyrofa: but systemd has reverse dependency syntax | 19:08 |
| zyga | kyrofa: a service can run before something else | 19:08 |
| rogpeppe | zyga: i want to do as little as possible pending the real driver/kernel fix :) | 19:08 |
| jdstrand | lool: I feel like I am missing a lot of context. are we talking about snapcraft.yaml, snap.yaml or the store? | 19:08 |
| rogpeppe | zyga: ah, i wondered if it might | 19:08 |
| lool | jdstrand: both | 19:08 |
| rogpeppe | zyga: thanks | 19:08 |
| lool | jdstrand: sorry, I'm doing too many things in parallel | 19:08 |
| rogpeppe | zyga: i'll give that a go | 19:08 |
| kyrofa | zyga, yeah, would sure be nice to expose that in snapd | 19:08 |
| lool | jdstrand: if I dont specify plugs at all, snapcraft rejects it, so I specify an empty list, but then the store rejects it | 19:09 |
| jdstrand | lool: that yaml is using devmode. what is the yaml that uses classic? | 19:09 |
| lool | jdstrand: I've just changed this snap from devmode to classic to run gdb on it | 19:09 |
| lool | locally | 19:09 |
| rogpeppe | zyga: where would you suggest starting in the systemd docs? | 19:09 |
| jdstrand | sergiusens: snapcraft now requires 'plugs' in snapcraft.yaml? | 19:09 |
| rogpeppe | zyga: is the canonical place? https://www.freedesktop.org/wiki/Software/systemd/ | 19:09 |
| zyga | rogpeppe: man systemd.unit | 19:09 |
| zyga | rogpeppe: man systemd.service | 19:10 |
| zyga | rogpeppe: that wiki is probably also good but you have everything on your system already | 19:10 |
| lool | jdstrand: $ snapcraft | 19:10 |
| lool | Issues while validating snapcraft.yaml: The 'hooks/configure' property does not match the required schema: None is not of type 'object' | 19:10 |
| rogpeppe | zyga: ah, great, i like section 5 pages. | 19:10 |
| lool | if I drop the plugs line | 19:10 |
| lool | with 2.26 | 19:10 |
| jdstrand | sergiusens: and it generates 'plugs: []' in snap.yaml? if so, why? ^ | 19:11 |
| lool | zyga: hmm $ sudo snap refresh --edge core | 19:11 |
| lool | 2017-02-07T19:06:44Z INFO snap "core" has bad plugs or slots: core-support (unknown interface) | 19:11 |
| lool | error: cannot perform the following tasks: | 19:11 |
| lool | - Setup snap "core" (1126) security profiles (no state entry for key) | 19:11 |
| jdstrand | lool: what if you do 'configure: null'? | 19:11 |
| zyga | lool: oooooh | 19:11 |
| zyga | lool: that's pretty interesting/bad | 19:11 |
| zyga | lool: so core support is a new interface | 19:11 |
| lool | jdstrand: Issues while validating snapcraft.yaml: The 'hooks/configure' property does not match the required schema: None is not of type 'object' | 19:11 |
| zyga | lool: that is there to support... core | 19:11 |
| rogpeppe | zyga: thanks a lot for your help. i think that's enough to get me a system that works... | 19:12 |
| zyga | lool: and I suspect we install new core | 19:12 |
| lool | zyga: yeah I figured, seems like the upgrade path is broken though | 19:12 |
| zyga | lool: try to conifgure it (it ships a hook now) | 19:12 |
| zyga | lool: and it dies | 19:12 |
| zyga | lool: can you report this please | 19:12 |
| lool | snappy project? | 19:12 |
| zyga | lool: snapd please | 19:12 |
| zyga | rogpeppe: good luck, and don't forget to talk to ogra tomorrow | 19:12 |
| ryebot | Is there a plug that allows a snap to use sysctl? | 19:14 |
| lool | zyga: https://bugs.launchpad.net/snapd/+bug/1662636 | 19:14 |
| mup | Bug #1662636: Can't upgrade to edge core snap due to missing core-support interface <snapd:New> <https://launchpad.net/bugs/1662636> | 19:14 |
| lool | jdstrand: the second copy-paste was with configure: null | 19:14 |
| zyga | lool: just to checek, can you add snap changes & snap change N for that change to the bug report | 19:15 |
| lool | zyga: would it help to use 2.22 from -proposed? | 19:15 |
| zyga | lool: (actually just the change) | 19:15 |
| zyga | lool: not sure yet, hold on | 19:16 |
| zyga | lool: I specifically want to see what failed (which task in that change) | 19:16 |
| lool | zyga: actually I lied, this system is NOT up-to-date | 19:16 |
| ryebot | specifically, the app we're trying to snap is failing with "can't set sysctl net/ipv4/conf/all/route_localnet: open /proc/sys/net/ipv4/conf/all/route_localnet: permission denied" | 19:17 |
| ryebot | is that possible without classic snaps? | 19:17 |
| lool | zyga: upgrading now | 19:17 |
| ryebot | classic confinement* | 19:17 |
| zyga | ryebot: not likely, classic confinement has no limitations | 19:18 |
| zyga | ryebot: but look at dmesg |grep DENIED | 19:18 |
| zyga | maybe we're missing something | 19:18 |
| ryebot | zyga: yeah, it definitely works with classic confinement | 19:19 |
| ryebot | zyga: trying to confine it now | 19:19 |
| zyga | ryebot: ah, I misread your question | 19:19 |
| zyga | let me check | 19:19 |
| ryebot | zyga: thanks :) | 19:19 |
| lool | zyga: I'm upgrading to xenial-updates | 19:19 |
| lool | and then will repro | 19:20 |
| zyga | ryebot: I don't think there's an interface that covers this, perhaps https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go should but I don't know | 19:20 |
| ryebot | zyga: I'll give it a shot; thanks | 19:21 |
| lool | jdstrand: BTW is there a shortcut to gdb-ing a snap? here are the options I thought of: 1) switch to classic snap, snap run --shell, run gdb there; 2) set SNAP env var manually, run binaries (but then namespaces aren't setup); 3) add gdb as a stage-package and snap run --shell | 19:35 |
| lool | none of these are very pleasing, is there something smarter to do? | 19:35 |
| mcphail | Can you debug in "snap try"? | 19:36 |
| balloons | anyway I can do something like this: source: file://$GOPATH/src/github.com/ to pull and use local sources to build my snap instead of a remote? | 19:37 |
| lool | mcphail: I guess; I'm actually building the snap on another host | 19:38 |
| balloons | note, I can specify the absolute path, and that does work | 19:38 |
| mup | Bug #1662627 changed: snapd project also open for bugs <Snappy:Invalid> <https://launchpad.net/bugs/1662627> | 19:44 |
| sergiusens | lool: jdstrand you only define hooks in `snapcraft.yaml` if you need to define plugs, what is going on? | 19:46 |
| lool | sergiusens: hooks have plugs | 19:48 |
| lool | sergiusens: but you can't define a hook without the plugs entry | 19:48 |
| lool | if you do an empty plugs list that's rejected by the store | 19:48 |
| zyga | lool: use snap run --shell | 19:50 |
| zyga | lool: and yes, use gdb from there | 19:50 |
| zyga | lool: if this is on classic you have gdb available in the host (via /var/lib/snapd/hostfs) | 19:51 |
| zyga | lool: if core then not sure | 19:51 |
| zyga | lool: didn't try that | 19:51 |
| zyga | lool: I think we could grow snap debug --strace | --gdb | ... over time | 19:51 |
| zyga | lool: that would do all the magic for symbols and what not | 19:51 |
| * zyga wonders about -debug snap with detached symbols | 19:52 | |
| zyga | e.g. foo might have a private foo-debug snap | 19:52 |
| zyga | install both, content does the rest | 19:52 |
| seshu | any issue with snap store? I'm unable to install my snap from --edge and --beta channel...got struck at Download snap XXXX from channel "edge" for a while now... | 19:53 |
| mup | PR snapcraft#940 closed: store: implement delta uploads in push <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/940> | 19:55 |
| mup | PR snapcraft#1114 opened: tests: avoid snapping progress to leak into report <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1114> | 20:01 |
| ryebot | zyga: That actually got us part of the way there, thanks! | 20:07 |
| ryebot | zyga: Now we're hitting "open /sys/module/nf_conntrack/parameters/hashsize: permission denied" | 20:08 |
| ryebot | network_control.go supports "@{PROC}/sys/net/nf_conntrack_max rw", but unfortunately I don't see sys/module/nf... in there. | 20:09 |
| zyga | ryebot: oh, that's great | 20:27 |
| zyga | ryebot: can you open a bug on this (in the snapd project on launchpad) | 20:27 |
| zyga | ryebot: and make sure to tag it "snapd-interface" | 20:28 |
| ryebot | zyga: will do! | 20:28 |
| zyga | ryebot: thank you | 20:29 |
| zyga | ryebot: our security team will review it and if it is within the policy, it will be added in a few days | 20:30 |
| ryebot | zyga: awesome, thanks! | 20:30 |
| jdstrand | ryebot: feel free to ping me when you file it | 20:31 |
| ryebot | jdstrand: cool, will do | 20:31 |
| zyga | seshu: yes, we think there's an issue | 20:32 |
| zyga | seshu: can you look if this bug describes the problem you are seing... | 20:32 |
| zyga | seshu: hmm, it's not filed? | 20:33 |
| * zyga should EOD and rest | 20:33 | |
| jdstrand | tvoss, zyga: fyi, https://lists.freedesktop.org/archives/xdg-app/2017-February/000534.html | 20:33 |
| pedronis | zyga: it's filed on the package | 20:34 |
| pedronis | not snappy or snapd | 20:34 |
| zyga | pedronis: ah, thanks | 20:34 |
| pedronis | (it's confusing all these places) | 20:34 |
| ryebot | jdstrand zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662662 <-- lmk if you need more information | 20:34 |
| mup | Bug #1662662: No interface allows access to "/sys/module/nf_conntrack/" <cdk> <snapd-interface> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1662662> | 20:34 |
| zyga | jdstrand: very interesting | 20:35 |
| zyga | jdstrand: thank you | 20:35 |
| pedronis | zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662603 | 20:35 |
| mup | Bug #1662603: snap refresh hang during download <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662603> | 20:36 |
| zyga | seshu: ^^ | 20:36 |
| pedronis | seshu: what device are you running snap from? | 20:36 |
| jdstrand | ryebot: thanks, triaged and assigned to me | 20:37 |
| ryebot | jdstrand: You rock, thanks a lot! | 20:38 |
| jdstrand | ryebot: thank you for filing the bug! :) | 20:38 |
| ryebot | np! | 20:38 |
| zyga | jdstrand: we should discuss the state of nvidia support | 20:40 |
| zyga | jdstrand: it's more complex with glvnd | 20:40 |
| jdstrand | zyga: probably should discuss with tvoss. I'm happy to participate for implementation ideas but I'm not well-versed in gl | 20:50 |
| popey | zyga: arch appears to have snapd 2.16, do you know when they might get 2.21? | 20:50 |
| mhall119 | sergiusens: how can I make an architecture-agnostic snap with snapcraft? | 20:54 |
| sergiusens | mhall119: force it with `architectures: [all]` | 20:56 |
| sergiusens | you seem to ask this question a lot :-P | 20:56 |
| mhall119 | I do? | 20:56 |
| mhall119 | all or any? that's the part I can never remember | 20:57 |
| popey | sergiusens: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/libraries.py#L84 is that relatively new? Pretty neat. | 20:57 |
| popey | I only discovered it today :) | 20:57 |
| popey | zyga: ignore me, wiki has the data | 20:57 |
| zyga | popey: no, I poked the package as out-of-date but I had no reply | 20:59 |
| zyga | popey: I don't have time to update it now | 20:59 |
| zyga | (the package) | 20:59 |
| sergiusens | popey: this is what sort of needs disabling that was discussed on-list :-/ | 21:00 |
| zyga | jdstrand: I have looked at this a while ago but I think we should come up with a solid plan forward | 21:02 |
| zyga | jdstrand: and it's 100% required to have nvidia hardware to hack on this, I don't have any anymore | 21:02 |
| jdstrand | hmm, me either | 21:03 |
| zyga | (had old GPU but I left it in poland as it was not working reliably) | 21:03 |
| mup | PR snapd#2778 closed: cmd: use safer functions in sc_mount_opt2str <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2778> | 21:03 |
| zyga | jdstrand: I merged the PR, I'll follow up with same cleanups in more places | 21:03 |
| zyga | jdstrand: thanks for the strnlen tip | 21:03 |
| kyrofa | popey, yeah we like it too, but it's just not deterministic enough | 21:04 |
| zyga | jamiebennett: ^^ | 21:07 |
| zyga | jamiebennett: (the nvidia discussion) | 21:07 |
| mhall119 | thanks sergiusens, you got me all squared away :) | 21:15 |
| balloons | sergiusens, is there a way to use local source, even for the godeps? | 21:22 |
| balloons | if you use source: ., godeps will still download the depends, even though I have them in $GOPATH | 21:23 |
| sergiusens | balloons: GOPATH for the plugin is different that GOPATH in your env | 21:24 |
| balloons | sergiusens, yea that seemed quite apparent when I tried to use file://$GOPATH. Still, is there anyway for godeps to find the dependencies, or not really? | 21:26 |
| popey | kyrofa: yeah, it threw me today. One of my snaps magically acquired the right libraries, but didn't when built on another arch machine - ppa missing. | 21:26 |
| popey | kyrofa: took me a while to figure out, then I saw the warnings (which have an odd b/ in front of them) and found that source code | 21:27 |
| kyrofa | popey, yeah, exactly. Magic is awesome but only if you can promise it'll always work, eh? | 21:27 |
| sergiusens | balloons: not that I can think of, not really a godeps person here | 21:28 |
| balloons | perhaps kyrofa would know? | 21:30 |
| sergiusens | balloons: I don't think you can aggregate GOPATHs though | 21:31 |
| sergiusens | don't clean the pull step is what I can think of | 21:31 |
| sergiusens | and maybe root for having the rebuild support in place ;-) | 21:31 |
| balloons | is this a wishlist bug perhaps? | 21:31 |
| sergiusens | it's almost like next in line | 21:32 |
| kyrofa | Yeah we're close | 21:32 |
| === JanC_ is now known as JanC | ||
| balloons | ohh, is there an open issue or something for me to watch? | 21:38 |
| balloons | I'd be keen to use it :-) | 21:38 |
| kyrofa | balloons, https://bugs.launchpad.net/snapcraft/+bug/1647877 | 21:40 |
| mup | Bug #1647877: The pull step is not marked as dirty when the source of the dump plugin is changed <dirty> <Snapcraft:Confirmed for kyrofa> <https://launchpad.net/bugs/1647877> | 21:40 |
| balloons | thanks guys! | 21:41 |
| mup | PR snapcraft#1114 closed: tests: avoid snapping progress to leak into report <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1114> | 21:43 |
| mup | PR snapd#2800 closed: daemon: show "$snapname (delta)" in progress when downloading deltas <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2800> | 21:47 |
| mup | PR snapd#2792 closed: tests: add spread test for delta downloads <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2792> | 21:48 |
| cholcombe | snappy: i'm getting a `classic confinement requires the core snap to be installed. Install it by running `snap install core`.` on my builds. is that something you need to do or me? | 21:57 |
| balloons | cholcombe, you need to have the core snap installed; you can fix it by installing it | 21:57 |
| cholcombe | balloons, https://code.launchpad.net/~xfactor973/+snap/ceph-safe-disk i can't do that | 21:57 |
| cholcombe | i have LP building for me | 21:57 |
| balloons | cholcombe, ahh, lp can't build classic snaps yep | 21:58 |
| cholcombe | darn | 21:58 |
| cholcombe | alright dev mode it is | 21:58 |
| balloons | yea sadness | 21:58 |
| cholcombe | balloons, is there a bug i can reference around that? Just so i can remember to update this when that gets fixed | 21:59 |
| balloons | https://bugs.launchpad.net/launchpad-buildd/+bug/1650946 | 22:00 |
| mup | Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946> | 22:00 |
| sergiusens | balloons: cholcombe that's going to be in snapcraft 2.27 and in master tonight/tomorrow | 22:05 |
| cholcombe | sergiusens, oh cool! alright | 22:05 |
| balloons | sergiusens, but it still needs lp changes right? | 22:08 |
| balloons | If I can build with -proposed or your daily build ppa to get snapcraft 2.27 , I'll do it. I'd love to switch to classic for lp builds | 22:09 |
| sergiusens | balloons: yeah, but timelines should align and the lp folks are working on another solution as well | 22:09 |
| sergiusens | balloons: snapcraft has no PPA, it goes against its principles :-) | 22:10 |
| balloons | sergiusens, :-) | 22:10 |
| mskalka | has anyone tried installing the Juju charm-tools snap lately? I can fetch it just fine but when I try to install it errors out with: error: cannot install "charm": snap not found | 22:11 |
| sergiusens | mskalka: maybe marcoceppi knows | 22:13 |
| mskalka | looks like it's just that one snap too, others install fine | 22:17 |
| kyrofa | It's a classic snap-- do you need to pass --classic? | 22:21 |
| kyrofa | mskalka, ^^ | 22:21 |
| mup | PR snapcraft#1098 closed: Ignore .tox directories when creating cleanbuild tar <Created by OddBloke> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1098> | 22:28 |
| mup | PR snapcraft#1115 opened: kernel plugin: fix kernel snap layout <Created by lool> <https://github.com/snapcore/snapcraft/pull/1115> | 22:46 |
| mup | PR snapd#2773 closed: interfaces/mount: generate per-snap mount profile <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2773> | 22:53 |
| mup | PR snapcraft#1110 closed: Show error messages for snap processing errors <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1110> | 23:13 |
| mup | PR snapd#2747 closed: interfaces/mount-observe: add quotactl with arg filtering (LP: #1626359) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2747> | 23:15 |
| mup | Bug #1637596 changed: Configure hook in tried snap with ecryptfs: permission denied <snapd:New for zyga> <https://launchpad.net/bugs/1637596> | 23:55 |
| mup | Bug #1653769 changed: Missing keyring interface <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1653769> | 23:55 |
| mup | Bug #1655125 changed: Missing interface: content sharing in the other direction <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1655125> | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!