| mup | Bug #1665184 opened: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665184> | 01:22 |
|---|---|---|
| kyrofa | barry, the fact that ubuntu-image uses the beta channel by default surprises me and is unclear from the manpages. Shouldn't it be stable? | 01:57 |
| === markusfluer1 is now known as markusfluer | ||
| barry | kyrofa: it can't be because it requires devmode. i think we definitely want to try to convert it to a classic snap at some point, but for now we treat beta as our release channel (and edge as our "proposed") | 03:33 |
| === chihchun_afk is now known as chihchun | ||
| === Sir_Gallantmon is now known as Son_Goku | ||
| sgorshkov | Hi | 05:50 |
| mup | PR snapd#2868 closed: Don't return null result for async responses <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2868> | 06:50 |
| kalikiana | barry: even though you can have a snap that uses devmode without declaring it in snapcraft.yaml ;-) | 06:57 |
| kalikiana | I don't know that it's the right thing to do, but some snaps do it, and it's not being blocked | 06:58 |
| kalyan_ | how to mount a ubuntu-core-16-dragonboard-410c.img | 07:03 |
| kalyan_ | and write a file in to the mount partition | 07:04 |
| === nhaines_ is now known as nhaines | ||
| mup | PR snapd#2869 opened: Add Online Accounts interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869> | 07:27 |
| === jamespag` is now known as jamespage | ||
| === alan_g is now known as alan_g|afk | ||
| ernstp | what's the difference between meta/snap.yaml and snapcraft.yaml? | 09:16 |
| ogra_ | one is used to build a snap, the other is meta information inside a snap package | 09:17 |
| ogra_ | snap.yaml is all the "non-build" meta info from the snapcraft.yaml usually | 09:18 |
| ernstp | sometimes you create a snap.yaml manually though? | 09:19 |
| ogra_ | not really ... you *can* do that but it means the build takes two steps and you cant use the auto-builder on launchpad | 09:20 |
| ernstp | looking at https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder and https://docs.ubuntu.com/core/en/guides/build-device/board-enablement | 09:22 |
| ogra_ | (like you can create a deb from scratch by putting the right files in the right places and using ar and gzip to finally create the package, you can do the same with a snap, but nobody would seriously do that) | 09:22 |
| ogra_ | ernstp, thats rather outdated | 09:23 |
| ernstp | wow, rly? | 09:23 |
| ogra_ | from a time where snapcraft did not understand "type: gadget" | 09:23 |
| ernstp | this page looks nice and official: https://docs.ubuntu.com/core/en/guides/build-device/board-enablement | 09:24 |
| ernstp | but it's already outdated? | 09:24 |
| ogra_ | yet it is outdated :) | 09:24 |
| ogra_ | https://github.com/snapcore/pi3-gadget | 09:24 |
| ogra_ | have a look there | 09:24 |
| ogra_ | ondra, ^^^ perhaps you shoudl update that ;) | 09:24 |
| ernstp | I started at these wonderful pages that haven't been updated since 2011 :-) https://wiki.ubuntu.com/ARM/RootStock https://wiki.ubuntu.com/ARM/RootfsFromScratch | 09:25 |
| ogra_ | hah | 09:25 |
| ogra_ | yeah, thats all obsolete but some of it might still work | 09:25 |
| ernstp | yeah I mean debootstrap will always work I guess | 09:26 |
| ogra_ | its not like the underlying technology changes much there | 09:26 |
| ernstp | and there's multistrap | 09:26 |
| ogra_ | rootstock went out of maintenance some time ago though ... but its just a script, easy to asdjust if needed | 09:27 |
| ernstp | ogra_: but thanks for pointing to the pi3 thing, I'll dig through it... | 09:28 |
| ogra_ | if you have questions, just ask :) | 09:28 |
| ernstp | ogra_: is this up to date... ? https://github.com/snapcore/snapd/wiki/Gadget-snap | 09:30 |
| ernstp | it mentions meta/snap.yaml again.. | 09:30 |
| === alan_g|afk is now known as alan_g | ||
| ogra_ | no, that needs updating too it seems | 09:31 |
| ernstp | I like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder because it includes building u-boot etc | 09:34 |
| ogra_ | ernstp, yeah, you could just call that from the snapcraft.yaml | 09:36 |
| ernstp | there's no kernel snap in the rpi3 repo? | 09:38 |
| ogra_ | no | 09:38 |
| ogra_ | the kernel is from the official builds in the ubuntu archive | 09:38 |
| ernstp | right | 09:39 |
| ogra_ | the source for it is on kernel.ubuntu.com | 09:39 |
| ernstp | I guess I'm comparing this to yocto... | 09:41 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | you cast really :) | 09:43 |
| ogra_ | *cant | 09:43 |
| ernstp | where you build a kernel, u-boot, pick up some userland, and then bake it all into an image | 09:43 |
| ogra_ | all the bits are separately upgradeable and you can also roll back each of them individually | 09:44 |
| ernstp | of course the point of using Ubuntu Core would be to _not_ compile all of userland from scratch | 09:44 |
| ogra_ | in case of kernel that happens even automatically if a new kernel doesnt finish booting | 09:44 |
| ogra_ | also the resulting image is readonly with only the few bits made writable the system needs to run, you cant really tinker with it | 09:45 |
| ogra_ | (snaps are signed readonly squashfs files) | 09:45 |
| ernstp | well comparing to yocto I still need to take a bunch of source, compile it and then combine it to an image I can flash to a device | 09:48 |
| ogra_ | well, the kernel and bootloader, yeah | 09:48 |
| ernstp | yes | 09:49 |
| ogra_ | (if your board is supported by the generic kernel only the bootloader ... ) | 09:49 |
| ernstp | no I've got a custom board | 09:50 |
| ernstp | the arm world is moving forward but it's going slow... | 09:51 |
| ogra_ | yep | 09:51 |
| ernstp | how could that setup look then... | 09:52 |
| ogra_ | well, enabling the beaglebone black which has mainline support was a 30min job for me ... simply because i didnt need to care for the kernel | 09:52 |
| === chihchun_afk is now known as chihchun | ||
| ernstp | gadget/gadget.yaml gadget/snapcraft.yaml kernel/snapcraft.yaml | 09:52 |
| ogra_ | https://github.com/snapcore/snapcraft/tree/master/demos/96boards-kernel/snap | 09:54 |
| ernstp | I'm using an imx6 processor plus a custom board | 09:54 |
| ogra_ | https://snapcraft.io/docs/reference/plugins/kernel has the docs for that | 09:55 |
| ernstp | ogra_: right, that's just like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/blob/master/builder/kernel/snapcraft.yaml makes perfect sense to me | 09:55 |
| ogra_ | right | 09:55 |
| ernstp | that's exactly what I need for the kernel, pointing out config, dtb, some options and whatnot | 09:56 |
| ernstp | then I want to build a gadget around that | 09:57 |
| ogra_ | right, and then an image | 09:57 |
| ogra_ | (docs for that are at https://docs.ubuntu.com/core/en/guides/build-device/image-building ) | 09:58 |
| ernstp | which leads to the https://docs.ubuntu.com/core/en/guides/build-device/board-enablement page that was outdated you said | 09:59 |
| ernstp | Can I reference snaps locally? | 10:01 |
| ernstp | right, I can, gadget and kernel refer to snaps already existing in the store or in the current directory | 10:01 |
| ogra_ | ernstp, yes, with the --extra-snaps option | 10:04 |
| ogra_ | ernstp, note that even if the page is outdated, the resulting snap will work and you can later port to plain snapcraft.yaml if you want | 10:12 |
| ogra_ | so just follow it for now :) | 10:13 |
| mup | PR snapd#2870 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2870> | 10:37 |
| mup | PR snapd#2871 opened: utils: helper function for creating a deep copy of interface attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/2871> | 11:04 |
| hangun | hi | 11:17 |
| hangun | I registered a new account and the profile is at https://launchpad.net/~ucrobotics123 | 11:18 |
| hangun | but when I executing " snapcraft register-key" commmand and inputing account and password | 11:19 |
| hangun | I got an error like this: you need to set a usename. it will appear in the developer filed alongside the other detials or your snap. | 11:20 |
| ernstp | hangun: I think it's confusingly called "Developer namespace" in the account details online | 11:43 |
| hangun | hi ernstip | 11:44 |
| hangun | how I set up the "namespace" | 11:45 |
| hangun | I dont see where to set up in my account https://launchpad.net/~ucrobotics123 | 11:46 |
| ogra_ | hangun, did you set it up on login.ubuntu.com ? | 11:48 |
| ernstp | hangun: if you read the full error message there's an url | 11:49 |
| hangun | I set up the "Username" filed at https://login.ubuntu.com/ | 11:52 |
| hangun | any role for that? | 11:53 |
| hangun | my username is "ucrobotics123" | 11:53 |
| ogra_ | and you can log in with that on https://myapps.developer.ubuntu.com ? | 11:53 |
| ogra_ | there is a ""developer namespace" option in the account settings | 11:54 |
| hangun | thanks ogra_ | 12:03 |
| hangun | it works now | 12:03 |
| hangun | I have another question: after snappy system booting up, executing commands " snap install hello-world" , "hello-world" | 12:09 |
| hangun | but got error like this: cannot bind-mount the mount namespace file /proc/11268/ns/mnt -> hello-world.mnd | 12:10 |
| hangun | support process for mount namespace capture exited abnormally | 12:10 |
| cachio | niemeyer, hi, I am trygin to push to spread a branch with the change that I did to export xunit format but I am getting | 12:14 |
| cachio | remote: Permission to snapcore/spread.git denied to sergiocazzolato | 12:14 |
| niemeyer | cachio: Hi | 12:14 |
| niemeyer | cachio: Got your email as well | 12:14 |
| niemeyer | cachio: Typical workflow in github is you fork the project into your own space, push the changes you want, and then send a pull request (PR) to the original project | 12:14 |
| niemeyer | cachio: You don't need write access to the master branch for that | 12:15 |
| cachio | niemeyer, I did that | 12:15 |
| niemeyer | cachio: Not really.. you see the message above? | 12:16 |
| niemeyer | cachio: You're trying to write into snapcore/spread.git.. that's not your fork | 12:16 |
| cachio | niemeyer, in that case I' try again | 12:16 |
| niemeyer | cachio: You're not supposed to be able to push there (yet, at least) | 12:16 |
| cachio | niemeyer, ok | 12:17 |
| hangun | hello all | 12:22 |
| hangun | I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457 | 12:22 |
| mup | Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457> | 12:22 |
| zyga | hello, sorry from being absent from IRC | 12:35 |
| zyga | anyone had a question about namespaces in snaps? | 12:36 |
| ogra_ | zyga, that was hangun | 12:47 |
| ogra_ | more abour namespaces in kernel i suspect though | 12:47 |
| ogra_ | *about | 12:47 |
| mup | PR snapd#2864 closed: interfaces: API additions for interface hooks <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2864> | 12:48 |
| zyga | hangun: hey | 12:48 |
| zyga | hangun: how can I help you, can you please repeat your question? | 12:48 |
| === cosmo_ is now known as cos | ||
| mup | PR snapd#2524 closed: interfaces/builtin,cmd/snap-confine: add the overmount interface <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2524> | 12:51 |
| niemeyer | zyga: | 12:52 |
| niemeyer | <hangun> hello all | 12:52 |
| niemeyer | 10:22:33 I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457 | 12:52 |
| mup | Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457> | 12:52 |
| ogra_ | heh, and he left | 12:54 |
| mup | PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2866> | 12:59 |
| jdstrand | zyga: hey, why make the libcap stuff conditional? it will work everywhere | 13:11 |
| zyga | jdstrand: because we cannot add dependencies to snapd easily now | 13:12 |
| zyga | jdstrand: I want to just enable it on compile time if it is available | 13:12 |
| zyga | jdstrand: and as we work on resolving the other bug (that affects apt) we can just hard-depend on it | 13:13 |
| jdstrand | zyga: but the code is correct... why can't you add a dependency? | 13:13 |
| zyga | jdstrand: right now because of how apt works it means people will not update | 13:13 |
| zyga | jdstrand: mvo has the gory details | 13:13 |
| zyga | jdstrand: but that's the bottom line | 13:13 |
| jdstrand | we add new stuff all the time | 13:13 |
| jdstrand | look at bind9 updates | 13:13 |
| jdstrand | this isn't a reason to not do stuff | 13:14 |
| zyga | jdstrand: and stats show us that people are stuck on ancient snapd | 13:14 |
| jdstrand | I know that thread | 13:14 |
| zyga | jdstrand: we researched this, apt behaves this way if you use a particular command | 13:14 |
| jdstrand | so fix apt | 13:14 |
| jdstrand | that was the takeaway from the conversation as I understood it | 13:14 |
| zyga | jdstrand: I'm not aware of that, I need to ask mvo | 13:15 |
| zyga | jdstrand: I asked him today and he recommended against adding deps to snapd | 13:15 |
| zyga | jdstrand: in any case, on ubuntu the build will not use libcap and will just do that unconditionally | 13:15 |
| zyga | jdstrand: on fedora we can use libcap | 13:16 |
| zyga | jdstrand: I think this is fine | 13:16 |
| zyga | jdstrand: until we can address the issue in apt | 13:16 |
| jdstrand | I don't think it is fine because it adds code complexity in the setgroups check | 13:16 |
| zyga | jdstrand: wh? | 13:16 |
| zyga | *why? | 13:17 |
| jdstrand | we are using libcap to see if we can use setgroup | 13:17 |
| zyga | the only complexity will be an #ifdef in the sc_has_capabaility | 13:17 |
| jdstrand | no | 13:17 |
| zyga | without libcap it will just say yes | 13:17 |
| jdstrand | and that will be wrong | 13:17 |
| zyga | why? | 13:17 |
| jdstrand | if you call drop privs as non-root, setgroups will fail | 13:17 |
| jdstrand | that is the whole reason the check is there | 13:18 |
| zyga | oh we ca easily check for that | 13:18 |
| zyga | we have the cap if running as root | 13:18 |
| jdstrand | yes, but the code is correct. we need to fix the underlying problem, not contort our code | 13:18 |
| zyga | that's one line in the #else part of the has_capability | 13:18 |
| jdstrand | the underlying problem is a distro problem that affects more than just snapd. not fixing it and people aren't getting other updates. snapd shows the symptom, but that is only because it is the only thing we are looking at | 13:19 |
| jdstrand | also, the xfslibs change also introduced a dependency. are we going to yank that out? cause that will affect security policy | 13:21 |
| jdstrand | kernels, bind9, and other things all do this regularly in the distro | 13:21 |
| zyga | jdstrand: I noticed that too | 13:21 |
| zyga | jdstrand: one secodn | 13:21 |
| zyga | jdstrand: (mvo says it is hard socially) | 13:21 |
| zyga | jdstrand: for that I think we just need the macro definitions | 13:22 |
| zyga | jdstrand: not any real dependency at runtime, right? | 13:22 |
| zyga | jdstrand: or we can link libacap statically | 13:24 |
| zyga | jdstrand: that's easy too | 13:24 |
| zyga | jdstrand: would you +1 that? | 13:24 |
| Son_Goku | :/ | 13:25 |
| jdstrand | for quota patch, it shouldn't pull in a runtime dep, only the build afaics (according to ldd) | 13:26 |
| zyga | jdstrand: I think we pulled in libhandle, not sure why | 13:27 |
| zyga | I saw it in ldd | 13:27 |
| zyga | Son_Goku: hey | 13:27 |
| jdstrand | oh, I don't have the right branch, hold on | 13:27 |
| Son_Goku | zyga: hi | 13:27 |
| zyga | jdstrand: I mean libhandle from xfs is in master | 13:27 |
| jdstrand | no, I have the right branch | 13:29 |
| jdstrand | ldd ./snap-confine/snap-confine | 13:29 |
| jdstrand | I see no libhandle | 13:29 |
| jdstrand | that is with quota patches but not up to date master | 13:30 |
| jdstrand | and with up to date master, no libhandle | 13:31 |
| jdstrand | mvo: hey, can you comment on the no new deps thing? ^ | 13:32 |
| zyga | jdstrand: I agree, I wonder why I saw it on centos, I'll check later | 13:32 |
| zyga | Son_Goku: question, so the centos package | 13:34 |
| zyga | Son_Goku: can we build a small centos package separately from the fedora package? | 13:35 |
| zyga | Son_Goku: just something that could live in copr for now | 13:35 |
| zyga | Son_Goku: I was looking at rhel and man, no build deps for anything | 13:35 |
| Son_Goku | haha | 13:35 |
| mvo | jdstrand: in a meeting right now | 13:35 |
| zyga | Son_Goku: so I think the package should build on centos first | 13:35 |
| Son_Goku | well, if it can build in EPEL, that's enough | 13:35 |
| zyga | Son_Goku: and then can move over as a binary package | 13:35 |
| zyga | Son_Goku: exactly | 13:35 |
| Son_Goku | no, I mean, that's enough for everyone (CentOS, RHEL, etc.) | 13:35 |
| zyga | Son_Goku: did you see my blog post about centos? | 13:36 |
| zyga | Son_Goku: ah, I see | 13:36 |
| Son_Goku | EPEL is RHEL + EPEL packages | 13:36 |
| mvo | jdstrand: what dependency was that again? | 13:36 |
| Son_Goku | and because CentOS is binary compatible, it works there | 13:36 |
| zyga | mvo: libcap2 | 13:36 |
| zyga | mvo: (and libcap-dev as build-dep) | 13:36 |
| jdstrand | mvo: this time, libcap | 13:36 |
| jdstrand | libcap2, yes | 13:36 |
| mvo | jdstrand: isn't that part of a the default install anyway? | 13:36 |
| mvo | if so, we are fine | 13:37 |
| zyga | hmmm, good question | 13:37 |
| jdstrand | let me double check | 13:37 |
| zyga | it is in main | 13:37 |
| ogra_ | we definitiely ship it in core | 13:37 |
| jdstrand | I checked the apt-cache rdepends, but didn't finish looking at it before I got fired up :) | 13:37 |
| mvo | it is installed in my pbuilder chroot | 13:37 |
| jdstrand | ogra_: we have libcap-ng in core | 13:37 |
| zyga | I think it's in bydefault | 13:37 |
| zyga | jdstrand: in that case let's re-open and land as-is | 13:38 |
| mup | PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866> | 13:38 |
| jdstrand | avahi-daemon needs it, so it is in the desktop | 13:38 |
| zyga | jdstrand: can you review it now | 13:38 |
| jdstrand | iputils-ping needs it, and that is in minimal | 13:39 |
| ogra_ | jdstrand, i see libcap2 here and libcap2-bin | 13:39 |
| jdstrand | (on trusty) | 13:39 |
| hangun | hi zyga | 13:39 |
| jdstrand | same for xenial | 13:39 |
| hangun | just left for a while | 13:39 |
| ogra_ | on trusty we still use the same core | 13:39 |
| ogra_ | https://launchpadlibrarian.net/306642126/core_16.04.1_amd64.manifest is the manifest file for the core snap | 13:40 |
| jdstrand | and yakkety and zesty | 13:40 |
| jdstrand | well, the core snap isn't an issue cause it'll just be slurped in, but I did check there. let me check again | 13:40 |
| Son_Goku | zyga: EPEL in Koji uses RHEL 7 base, EPEL in COPR uses CentOS 7 base | 13:41 |
| ogra_ | http://people.canonical.com/~ogra/core-builds/ has links to all the manifests | 13:41 |
| jdstrand | ogra_: you are right. libcap2 is in /lib but libcap-ng is in /usr/lib. I only checked /usr/lib | 13:41 |
| jdstrand | it's in minimal, so crisis averted for this | 13:41 |
| Son_Goku | jdstrand: bah, UsrMerge :) | 13:42 |
| Son_Goku | do iiiit :D | 13:42 |
| jdstrand | however, I thought a fix for apt-get was the way to go to make it work the same as apt | 13:42 |
| zyga | Son_Goku: I suspect 18 will do it | 13:42 |
| Son_Goku | FINALLY | 13:42 |
| zyga | Son_Goku: nobody cares though :) | 13:43 |
| Son_Goku | :'( | 13:43 |
| zyga | it's a change that changes nothing relevant for anyone | 13:43 |
| zyga | internal refactor | 13:43 |
| Son_Goku | y'all suck :) | 13:43 |
| zyga | hangun: hi | 13:43 |
| zyga | hangun: I want to help you with the issue you mentioned | 13:43 |
| zyga | hangun: I merged a small fix into snapd master that affects 3.10 | 13:43 |
| jdstrand | zyga: all this said. it is actually interesting to think about (not for this PR) to make snap-confine statically linked, or at least, partially so | 13:43 |
| zyga | jdstrand: yes, I agree, though we will use core libs for re-exec linking it statically is not a bad idea | 13:44 |
| zyga | hangun: can you try master and tell me exactly what error are you getting | 13:44 |
| jdstrand | zyga: well, re-exec is only for classic | 13:44 |
| zyga | jdstrand: yes | 13:45 |
| zyga | jdstrand: do you see advantages to static linking on core? | 13:45 |
| jdstrand | but it does help the re-exec case. it also would allow us to reduce the apparmor profile. potentially avoids problems where the libs it would dynamically link out to change incompatibly such that snap-confine fails. that *should* never happen and tests would reveal that type of thing | 13:47 |
| jdstrand | it does mean that we need to rebuild for security updates | 13:47 |
| jdstrand | it is something to think about. I'm not recommending it atm, just thinking out loud | 13:47 |
| zyga | jdstrand: I think we should add that to the list of things to investigate once core splits into core + base | 13:48 |
| zyga | jdstrand: could be used to keep core totally tiny | 13:48 |
| jdstrand | well, it would actually be a little bigger | 13:48 |
| mup | PR snapd#2872 opened: tests: only check core refresh if there's no update available <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2872> | 13:48 |
| jdstrand | since it doesn't use many libraries and most of those are fundamental-- I doubt any would drop of, so there would be duplication. but I'm not saying this is a concern, just that it wouldn't be smaller | 13:49 |
| zyga | jdstrand: only if something else also depends on libcap in core | 13:49 |
| hangun | zyga: My env like this snapd version (2.21), snapcraft version (2.26) ubuntu-snappy version (2.21). | 13:49 |
| jdstrand | libcap is the only thing | 13:49 |
| jdstrand | that it would save | 13:49 |
| zyga | hangun: you need to build snapd from master | 13:49 |
| jdstrand | if it is totally staically compiled, then libc is there and in core | 13:49 |
| zyga | hangun: there's a lot of improvements that landed since 2.21 | 13:50 |
| zyga | hangun: and the fix to 3.10 that I did is not released yet | 13:50 |
| zyga | hangun: I don't know it fixes the issue you are seeing but I did use it run on a 3.10 kernel | 13:50 |
| zyga | hangun: (though without apparmor) | 13:50 |
| zyga | hangun: but you need that fix to get it to work anyway | 13:50 |
| morphis | lool: lool: https://github.com/morphis/tvheadend/tree/snap-support | 13:51 |
| jdstrand | of course, you could just statically link libcap | 13:51 |
| jdstrand | anyway, something to think about | 13:51 |
| mup | PR snapd#2835 closed: strutil: support version compare with empty strings <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2835> | 13:51 |
| hangun | zyga: thanks, i try it now. | 13:52 |
| zyga | Son_Goku: what are those notificationabout snap-confine for f23 being deleted? | 13:54 |
| zyga | Son_Goku: is that because of EOL? | 13:54 |
| Son_Goku | no | 13:54 |
| Son_Goku | I think it's because you never submitted them as updates | 13:54 |
| zyga | so what is exactly being deleted? | 13:55 |
| Son_Goku | if they're not tagged, koji aggressively gc's them | 13:55 |
| Son_Goku | the build artifacts | 13:55 |
| zyga | ah | 13:55 |
| zyga | that's fine | 13:55 |
| zyga | Son_Goku: we should try to get those packages out | 13:55 |
| zyga | Son_Goku: 2.23 has all the fixes for fedora now | 13:55 |
| Son_Goku | is it released? | 13:55 |
| Son_Goku | I didn't see mvo announce 2.23 yet | 13:56 |
| Son_Goku | did we also get any new systemd units that I need to refresh my systemd unit patch for? | 13:56 |
| zyga | Son_Goku: mvo will release it today I think | 13:58 |
| zyga | mvo: when is the release? today? | 13:58 |
| zyga | Son_Goku: no, we can drop units now | 13:58 |
| zyga | Son_Goku: more less | 13:58 |
| Son_Goku | well, our systemd units work slightly differently from ubuntu's remember | 13:58 |
| zyga | Son_Goku: we have a packaging/ directory | 13:58 |
| zyga | Son_Goku: yes, I mean we should put them there | 13:58 |
| zyga | Son_Goku: if you commit them we don't need to carry the patch | 13:58 |
| Son_Goku | well, I can certainly submit a PR with them, if you'd like | 13:58 |
| zyga | Son_Goku: please, I really want those | 13:58 |
| zyga | Son_Goku: you didn't answer my question about the centos blog post | 13:59 |
| Son_Goku | I didn't read it yet | 13:59 |
| zyga | Son_Goku: did you see the stuff I added there? | 13:59 |
| zyga | Son_Goku: ah, OK | 13:59 |
| Son_Goku | reading it now | 13:59 |
| Son_Goku | looks like zbyszek left comments on your blog? | 14:00 |
| zyga | Son_Goku: yes | 14:00 |
| zyga | Son_Goku: nice to see feedback from systemd developers :) | 14:00 |
| Son_Goku | talking to them often helps, too :) | 14:00 |
| Son_Goku | Lukas and Zbyszek are nice people | 14:01 |
| zyga | I'm sure, I'd love to meet them in person one day | 14:01 |
| Son_Goku | Lukas is the RHEL systemd maintainer, and Zbyszek is the Fedora one | 14:01 |
| zyga | I could use more sleep ;) | 14:01 |
| Son_Goku | or more coffee :) | 14:01 |
| zyga | I think I need to survive too ;) | 14:01 |
| hangun | zyga: is this the snapd link https://github.com/snapcore/snapd/ ? How I compile it or any easy way to get a latest nightly deb package? | 14:02 |
| zyga | hangun: yes that is it | 14:02 |
| lool | morphis: awesome! | 14:02 |
| zyga | hangun: not sure where are the nighly packages, I think they are built somewhere but I cannot say | 14:03 |
| zyga | hangun: I wrote a blog post about how to build it from source on centos lately, the instructions are almost enitirely valid for other distributions (you just need the right build dependencies) | 14:03 |
| zyga | hangun: https://new.zygoon.pl/post/case-study-snapd-on-centos/ | 14:04 |
| hangun | zyga: awesome | 14:04 |
| zyga | hangun: feel free to ping me with question | 14:04 |
| zyga | hangun: you can try to build just the snap-confine parts | 14:05 |
| zyga | hangun: and you can make install DESTDIR=/tmp/foo if you just need a particular file to test | 14:05 |
| zyga | hangun: I'm not sure what the process is on your device | 14:05 |
| hangun | zyga: my board is bubblegum 96board http://www.96boards.org/product/bubblegum-96/ | 14:06 |
| zyga | hangun: I see | 14:09 |
| zyga | I don't have that board at home | 14:09 |
| ogra_ | hopefully all needed config options are set in that kernel | 14:10 |
| hangun | zyga: i will re-build snapd following your blog | 14:10 |
| mup | PR snapd#2841 closed: interfaces: allow recv* and send* by default, accept4 with accept and other cleanups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2841> | 14:12 |
| mup | PR snapd#2842 closed: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2842> | 14:14 |
| Son_Goku | zyga, what should I label the folder inside of packaging/ ? | 14:15 |
| Son_Goku | I originally was using the catch-all top level directory dist/, but I guess that doesn't fit here | 14:15 |
| zyga | Son_Goku: just put packaging/fedora-25 there | 14:18 |
| zyga | Son_Goku: we can use symlinks for others | 14:18 |
| zyga | Son_Goku: and then we can use that in downstream packages | 14:18 |
| zyga | Son_Goku: we can also keep a copy of the spec for CI | 14:19 |
| Son_Goku | even if the units are useful for more than fedora? they're basically the ones anyone that isn't using Debian uses | 14:19 |
| zyga | Son_Goku: yes | 14:19 |
| zyga | Son_Goku: symlinks :) | 14:19 |
| zyga | Son_Goku: we can sim;lify over time | 14:19 |
| Son_Goku | okay | 14:19 |
| Son_Goku | as for spec for CI, that would mean that snapcore-selinux needs to somehow be available for spread to pull in | 14:20 |
| Son_Goku | or is it always going to retrieve that from fedora dist-git? | 14:20 |
| zyga | Son_Goku: yes, I think we can come up with something | 14:20 |
| Son_Goku | okay | 14:20 |
| zyga | Son_Goku: not sure yet | 14:20 |
| zyga | jdstrand: what about 2863? | 14:21 |
| zyga | jdstrand: I'd like that in candidate that's going out now | 14:21 |
| mup | PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866> | 14:21 |
| jdstrand | zyI already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it | 14:25 |
| mup | PR snapd#2873 opened: tests: several improvements to the nested suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2873> | 14:25 |
| zyga | re | 14:27 |
| jdstrand | zyga: I already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it | 14:28 |
| zyga | jdstrand: just the approval :) | 14:28 |
| jdstrand | zyga: note, you merged https://github.com/snapcore/snapd/pull/2866 without a second +1, just mine | 14:29 |
| mup | PR snapd#2866: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866> | 14:29 |
| zyga | jdstrand: I cannot merge it without it | 14:29 |
| jdstrand | well, you'll need a second +1 too | 14:29 |
| jdstrand | unles the commit policy changed | 14:29 |
| zyga | jdstrand: that counts as one | 14:29 |
| * jdstrand is just operating under what he's been told | 14:29 | |
| jdstrand | zyga: what counts as one? my +1? yes, and you need two +1s other than yourself as I've been told | 14:30 |
| hangun | zyga: I git clone snapd from source and then ./mkversion.sh | 14:33 |
| hangun | zyga: *** Setting version to '2.22.2+git475.g7900000.dirty' from git. | 14:34 |
| Son_Goku | zyga, does snap-confine get the same versioning as snapd now? | 14:34 |
| Son_Goku | or does it still maintain its own version somewhere? | 14:35 |
| zyga | Son_Goku: yes | 14:35 |
| zyga | Son_Goku: it's the same version, easier :) | 14:35 |
| Son_Goku | okay | 14:35 |
| === chihchun is now known as chihchun_afk | ||
| Son_Goku | zyga: working on the snapd.spec rebase to v2.23... https://github.com/Conan-Kudo/snapd/commit/f73baebb3d0d9f049568b1134365c2b47368c981 | 15:05 |
| Son_Goku | let me know if there's something I'm missing that should be added | 15:06 |
| Son_Goku | haven't built it yet, either, as I need to go to work | 15:06 |
| Son_Goku | I'll test and fix up the inevitably broken file lists... | 15:06 |
| zyga | Son_Goku: looking | 15:06 |
| zyga | Son_Goku: BuildRequires: pkgconfig(libcap) | 15:08 |
| Son_Goku | on snap-confine? | 15:08 |
| Son_Goku | does that mean we can use file caps? | 15:08 |
| zyga | Son_Goku: also requires xfsprogs-devel | 15:09 |
| zyga | Son_Goku: no but we start to use libcap | 15:09 |
| zyga | Son_Goku: maybe we can switch over time, but the dependency is in place now | 15:09 |
| zyga | Son_Goku: you also want glibc-static | 15:09 |
| Son_Goku | uh why glibc-static? | 15:09 |
| zyga | Son_Goku: though we don't need to ship the resulting file (system-shutdown) | 15:10 |
| zyga | Son_Goku: there's a special helper that systemd runs on core systems to unmount the filesystem correctly | 15:10 |
| zyga | Son_Goku: it's only used on core | 15:10 |
| zyga | Son_Goku: and it runs back in intrd land | 15:10 |
| zyga | Son_Goku: so it has to be static | 15:10 |
| zyga | Son_Goku: just add the build-dep for now, we can make that conditional on something like --non-core-build or something later | 15:10 |
| zyga | Son_Goku: check the list in the blog post, I listed all the packages for centos and that's pretty much the same list for Fedora | 15:11 |
| zyga | Son_Goku: reading the rest now | 15:11 |
| zyga | Son_Goku: make sure the configure call matches autogen (not sure if it doenst) | 15:12 |
| zyga | Son_Goku: we have a new go executable (snapctl) that should be built and installed to %{_bindir} | 15:13 |
| zyga | Son_Goku: we should include the /var/lib/snapd/void directory that is root.root 0000 | 15:13 |
| zyga | Son_Goku: snap-confine creates it but it should be owned by the package | 15:13 |
| Son_Goku | it is | 15:13 |
| zyga | oh, must have missed it | 15:13 |
| Son_Goku | snapctl goes in snap-confine? | 15:13 |
| zyga | Son_Goku: no, more like snapd | 15:14 |
| zyga | Son_Goku: I'd merge them TBH | 15:14 |
| zyga | Son_Goku: one binary package | 15:14 |
| zyga | Son_Goku: but digress, | 15:14 |
| zyga | Son_Goku: we need a new info file | 15:14 |
| zyga | Son_Goku: it is in libexecdir for now | 15:14 |
| zyga | Son_Goku: it is in data/info after build AFAIR | 15:14 |
| zyga | Son_Goku: it's just a version dump | 15:14 |
| zyga | Son_Goku: oh and we should run ./mkversion.sh | 15:14 |
| zyga | Son_Goku: right now we skipped that but it is mandatory for snap-confine and everything else now | 15:15 |
| zyga | Son_Goku: we _probably_ have to fix mkversion | 15:15 |
| zyga | Son_Goku: or have it just echo the fedora version | 15:15 |
| zyga | Son_Goku: it looks at git | 15:15 |
| zyga | Son_Goku: but then falls back to debian/changelog | 15:15 |
| zyga | Son_Goku: it's a bit hard to say where the reference version should be | 15:15 |
| zyga | Son_Goku: we can fix that but not sure where to put the version | 15:15 |
| Son_Goku | if we could just write a file out somewhere, I can inject the version that way | 15:15 |
| Son_Goku | with like echo "%{version}" > VERSION | 15:16 |
| zyga | Son_Goku: the script generates a go version file, a static file for snap-confine (configure.ac reads it) and the info file (snapd reads it at runtiime) | 15:16 |
| zyga | Son_Goku: kind of yes, | 15:16 |
| zyga | Son_Goku: but if you do that in mkversion.sh as a patch we can upstream it and it will not drift over time | 15:16 |
| Son_Goku | yeah, alright, I'll take a look at it | 15:16 |
| zyga | Son_Goku: that script was a quick and dirty way to progress and this is a good chance to just make it nicer | 15:16 |
| Son_Goku | I gotta go to work | 15:17 |
| zyga | Son_Goku: thank you, let's sync later | 15:17 |
| zyga | Son_Goku: you can drop SNAPD_REEXEC, reexec is disabled on fedora and similar now | 15:17 |
| zyga | Son_Goku: you can keep it just in case you want to for now but it's not useful anymore | 15:18 |
| Son_Goku | I'm going to leave it as reference | 15:18 |
| zyga | Son_Goku: oh and we have a few more manual pages Is uspect | 15:18 |
| zyga | Son_Goku: still not enough but more than before :-) | 15:18 |
| zyga | I plan to write the missing few when I have a chance to look at this | 15:18 |
| zyga | (fighting other dragons now) | 15:18 |
| zyga | Son_Goku: we may have more directories in /var/lib/snapd/ we should cross-check with debian packaging | 15:19 |
| zyga | (and document them in snapd man page) | 15:19 |
| zyga | Son_Goku: that's all I could see on a quick read, again *thanks* for picking this up :) | 15:20 |
| brunch875 | does snappy have any system for bug reporting? | 15:33 |
| brunch875 | not snappy itself, but for specific snaps | 15:33 |
| zyga | brunch875: no not at present | 15:33 |
| brunch875 | zyga, is it planned? | 15:33 |
| zyga | brunch875: there's work for landing a way to display contact information, it should be ready in the next release | 15:34 |
| brunch875 | nice! | 15:34 |
| zyga | brunch875: I think that can be extended to include other URLs (e.g. a support URL) | 15:34 |
| zyga | brunch875: you want to ask mvo about this, he was working on the feature | 15:34 |
| zyga | brunch875: but I think he's very busy today, working on the release | 15:34 |
| zyga | brunch875: so perhaps tomorrow | 15:34 |
| zyga | brunch875: or just send an email to the snapcraft mailing list | 15:35 |
| mvo | snap info snapname in master will give you contact information | 15:35 |
| mvo | (in a meeting) | 15:35 |
| * zyga hugs mvo | 15:35 | |
| zyga | thanks! :) | 15:35 |
| brunch875 | thank you! | 15:35 |
| stokachu | im seeign this on 14.04 : 2017-02-16T15:34:49Z INFO snap "core" has bad plugs or slots: core-support (unknown interface) | 15:36 |
| ogra_ | stokachu, well, just an INFO message ... does it behave correctly ? | 15:36 |
| stokachu | ogra_, not sure yet still trying to load my snap | 15:36 |
| ogra_ | (core just got upgraded to new version, you most likely just got that one) | 15:37 |
| zyga | stokachu: this is a known issue, not sure where the bug for tracking that is | 15:38 |
| stokachu | zyga, ok thanks | 15:38 |
| ogra_ | it shouldnt cause any harm though | 15:39 |
| popey | mvo: just saw your mail about new core and tried to update... | 15:40 |
| popey | $ snap refresh | 15:40 |
| popey | 2017-02-16T15:40:17Z INFO snap "core" has bad plugs or slots: core-support (unknown interface) | 15:40 |
| popey | core 16.04.1 from 'canonical' refreshed | 15:40 |
| popey | is that expected? | 15:41 |
| mvo | popey: yes, its just a warning (still not nice) | 15:41 |
| ogra_ | so it refreshed fine and informed you that the old core didnt have that interface | 15:41 |
| popey | oh, it's moaning about the old core, I see. | 15:41 |
| popey | thanks | 15:41 |
| ogra_ | well, about the one in use at the time of the upgrade | 15:41 |
| ogra_ | (also, core-support is moot on classic systems) | 15:42 |
| ogra_ | (at least it should be :P) | 15:43 |
| jdstrand | kyrofa: fyi, responded to https://github.com/snapcore/snapd/pull/2837 | 16:03 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 16:03 |
| mup | Bug #1648615 changed: Apps hit apparmor denial trying to connect to unity8's mir_socket <Canonical System Image:Confirmed for alecu> <Snappy:Invalid by mterry> <https://launchpad.net/bugs/1648615> | 16:43 |
| mup | PR snapd#2874 opened: kmod: added Specification for kmod security backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/2874> | 16:56 |
| mup | PR snapd#2829 closed: tests: add libvirt interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2829> | 17:11 |
| === plars_ is now known as plars | ||
| sdrobertw | Found this forum post on 96Boards: http://bit.ly/2kWV5l5 | 17:27 |
| kyrofa | sdrobertw, not sure what's going on there-- I suggest an email to the snapcraft list, or have them hop in here so we can troubleshoot | 17:36 |
| kyrofa | barry, ah, no, I was using the deb anyway. I meant when I run ubuntu image without `-c`, it defaults to using beta | 17:38 |
| ogra_ | sdrobertw, i guess thats the same guy we have on the mailing list, he has assembled a non-working image (kernel snap not fully working etc) | 17:38 |
| ogra_ | sdrobertw, his image is/was built in a way that the firstboot initialization did not properly work, which results in snapd not working | 17:38 |
| barry | kyrofa: that must be a behavior of snap prepare-image. if no -c is given to u-i, we don't pass --channel to `snap prepare-image` | 17:40 |
| sdrobertw | kyrofa: I will tell them to join the channel | 17:40 |
| kyrofa | barry, ah, interesting. Perhaps you should, haha! | 17:40 |
| kyrofa | barry, that way you can document it. No one knows you're actually using snapd behind the scenes | 17:41 |
| barry | kyrofa: we should definitely document that, but understand that u-i will also eventually create classic images, so it's not supposed to be so tied to snaps. i guess snap prepare-image needs better documentation and/or defaults | 17:42 |
| kyrofa | barry, understood. Although keep in mind that documentation for snap prepare-image won't help anyone if it's always wrapped by ubuntu-image | 17:42 |
| kyrofa | barry, if we eventually need to call prepare-image ourselves (is that what you mean?), that's fine | 17:43 |
| barry | kyrofa: well, what i'd like to do is document u-i "backends" (of which there is only one right now) and that's where we can document how prepare-image is called under the hood | 17:43 |
| barry | kyrofa: no, you should never have to call it yourself | 17:43 |
| kyrofa | barry, I see, okay | 17:44 |
| lool | kyrofa: hey, is cleanbuild working for you with a snap/snapcraft.yaml? | 17:51 |
| lool | I've got this error when trying a build: | 17:52 |
| lool | Processing triggers for libc-bin (2.23-0ubuntu5) ... | 17:52 |
| lool | Could not find snap/snapcraft.yaml. Are you sure you're in the right directory? | 17:52 |
| lool | To start a new project, use 'snapcraft init' | 17:52 |
| kyrofa | lool, I haven't tried. To be completely honest I don't use cleanbuild-- I just create a clean container myself so I can utilize caching | 17:52 |
| lool | kyrofa: would you know if the tarball is supposed to contain snapcraft.yaml? | 17:52 |
| kyrofa | lool, ohhh | 17:52 |
| kyrofa | lool, I know what you hit | 17:52 |
| lool | I looked as the tarignore logic, and it seems correct yet the tarball doesn't contain snapcraft.yaml | 17:52 |
| kyrofa | lool, indeed, way back when 'prime' used to be called 'snap' so cleanbuild had logic to ignore it when creating the tarball | 17:53 |
| kyrofa | lool, that's since been fixed, let me see if it's been released yet | 17:53 |
| lool | oh ok, just me looking at fixed source code which is not the one I'm running, blah | 17:53 |
| kyrofa | lool, ah, 2.27 | 17:53 |
| kyrofa | lool, it's in proposed | 17:53 |
| kyrofa | lool, haha, that'll always get ya | 17:54 |
| kyrofa | lool, sorry about that, we caught that issue too late | 17:55 |
| lool | no that's great news, it's already fixed | 17:55 |
| lool | kyrofa: it's funny cause I actually thought of this snap/ ignore explanation and thought "oh that will be easy to fix" | 17:55 |
| kyrofa | lool, yeah it was like four characters | 17:56 |
| kyrofa | Plus tests, of couse | 17:56 |
| kyrofa | with an r in there somewhere | 17:56 |
| lool | BTW I've noticed two pieces of potentially interesting behavior | 17:56 |
| lool | one is with dependent libs | 17:56 |
| kyrofa | Oh? | 17:56 |
| lool | I have these binaries that require libsctp1 | 17:57 |
| lool | they are prebuilt | 17:57 |
| lool | if I build the snap on a system that has the package, the lib gets copied automagically | 17:57 |
| lool | however if it's missing, no error but the snap is incomplete | 17:57 |
| lool | this would be caught by cleanbuild | 17:57 |
| lool | in the sense that if I always used cleanbuild and tested the snap I would notice | 17:57 |
| lool | but someone doing changes / buidling the snap wont notice | 17:58 |
| lool | I wonder if you should warn/fail the build when trying to copy libs and failing, don't know | 17:58 |
| kyrofa | lool, indeed. There are a few things here | 17:58 |
| kyrofa | lool, first, check out https://snapcraft.io/docs/build-snaps/syntax and read about the `build-attributes` | 17:58 |
| lool | it's kind of hard to both be tolerant in case it's in a later part and to be rigorous to make sure all libs are there | 17:58 |
| kyrofa | lool, long story short, this is really unclear behavior as you noticed | 17:59 |
| lool | ah didn't know about build-attributes: no-system-libraries | 17:59 |
| kyrofa | lool, we're moving to, instead of magically copying things we know we need, erroring on them | 17:59 |
| kyrofa | lool, we're hemming and hawing on it because it will break a lot of things, though | 17:59 |
| lool | ok | 17:59 |
| kyrofa | lool, not sure when that will happen or what it'll look like | 17:59 |
| kyrofa | lool, however, if you want that behavior now, you can use that build-attribute | 17:59 |
| lool | can I set build-attributes globally? seems per part | 18:00 |
| kyrofa | lool, indeed, per-part | 18:00 |
| kyrofa | lool, it's really there for content sharing when "yes I know that lib isn't here, I don't _want_ it to be" | 18:00 |
| lool | kyrofa: is it build-attributes: [no-system-libraries]? | 18:00 |
| kyrofa | You got it | 18:00 |
| kyrofa | lool, what that means is that you'll need to specify all the libs you need as stage-packages | 18:01 |
| lool | ok, the other thing I wanted to mention, probably bottom of the priority pile thing, is about 32-bits in amd64 | 18:01 |
| lool | I'm building an amd64 snap on amd64 but it contains a 32-bits runtime because "meh" | 18:01 |
| lool | when I do this, I get tons or warnings | 18:01 |
| pmcgowan | kyrofa, is there a way to "pin" a version of a snap so it doesnt update | 18:02 |
| lool | kyrofa: actually I get one per binary | 18:02 |
| lool | e.g. Unable to determine library dependencies for b'prime/xyz' | 18:03 |
| lool | seems fair in terms of number of warnings, just thinking this could the same as for 64 bits, but again I dont expect any priority on this, just thought I'd mention I came across this | 18:04 |
| kyrofa | lool, got pulled into a call, give me a few and I'll get back to you | 18:05 |
| lool | kyrofa: no worries, this was just FYI | 18:06 |
| mup | PR snapd#2865 closed: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2865> | 18:18 |
| kyrofa | Alright, done with the call | 18:30 |
| ogra_ | who won ? | 18:30 |
| ogra_ | :) | 18:30 |
| kyrofa | Me, duh | 18:30 |
| kyrofa | lool, ah, indeed that's interesting. We use the host's ldd to check that | 18:31 |
| kyrofa | lool, but it's not a native elf file, so it skips it | 18:31 |
| kyrofa | pmcgowan, sorry for the delay: not that I know of. I think you can disable refresh systemwide by stopping the right systemd unit, but that doesn't sound like what you asked for | 18:32 |
| kyrofa | pmcgowan, however, that's a pretty popular request. manik is tracking it | 18:32 |
| pmcgowan | kyrofa, not exactly, so if I revert a snap, does that effectively do it? | 18:32 |
| pmcgowan | I assume the snap wont update after a revert? | 18:33 |
| kyrofa | pmcgowan, it won't update to the revision from which you reverted, but I do believe it'll update when a new update comes out | 18:33 |
| pmcgowan | makes sense | 18:33 |
| DedSec | does anyone know if its possible to have an snap get the current version of an app using an github tag? | 18:36 |
| kyrofa | DedSec, you mean when building? | 18:36 |
| DedSec | yes | 18:36 |
| kyrofa | DedSec, oh certainly | 18:36 |
| kyrofa | DedSec, use source-tag | 18:37 |
| kyrofa | DedSec, so you have `source: <github repo>` followed by `source-tag: <tag>` | 18:37 |
| kyrofa | DedSec, `snapcraft help sources` may prove helpful as well | 18:37 |
| DedSec | gotcha, so i could easily create an tag for Dev buils and one for stable and then have different snapcraf.yaml files for each version | 18:38 |
| DedSec | sounds easy :) | 18:38 |
| brunch875 | does anyone know why there are two telegram snaps? I'm using sergiusens one because it has never given me any trouble | 18:41 |
| * ogra_ uses it becaause he is a sergiusens fanboy | 18:41 | |
| kyrofa | brunch875, the store only cares about the names being unique. Anyone can release anything | 18:43 |
| brunch875 | So I could upload my own telegram? neat | 18:44 |
| brunch875 | thanks kyrofa, that cleared my doubts | 18:44 |
| kyrofa | brunch875, so if you run `snap find telegram` you'll see that sergiusens has one, and pain7 has one. Pick your poison, or upload your own! | 18:44 |
| kyrofa | brunch875, the one thing you can be certain of is that telegram has not officially released their own | 18:45 |
| kyrofa | brunch875, because that would probably be called "telegram" and come from the "telegram" developer | 18:45 |
| kyrofa | (or something) | 18:45 |
| brunch875 | what if I registered as telegram? | 18:45 |
| kyrofa | brunch875, I suspect the name is reserved | 18:46 |
| brunch875 | I take it telegram would be able to reclaim its name | 18:46 |
| kyrofa | brunch875, you'll have to justify it | 18:46 |
| Pharaoh_Atem | sergiusens: hey, any luck on the PR? | 18:47 |
| mup | PR snapd#2875 opened: mkversion.sh: Add support for taking the version as a parameter <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2875> | 19:11 |
| Cynerva | Is there a way for a snap configure hook to get all the config keys? | 19:16 |
| kyrofa | Cynerva, what do you mean? | 19:22 |
| Cynerva | kyrofa: I'd like to get a list of every config that's been set for the snap. Partially for validation - so if someone says `snap set mysnap potato` but we don't have a potato config, I'd like to have the hook fail with feedback for the user | 19:25 |
| kyrofa | Cynerva, ah okay. While I know you can retrieve multiple values at once with `snap get key1 key2 key3 ...` I don't think there's a way to retrieve _everything_ | 19:26 |
| kyrofa | Cynerva, but I think the plan is at some point to allow the snap to specify some sort of schema | 19:27 |
| kyrofa | (don't take my word for it though, not quite sure on the plan) | 19:27 |
| jdstrand | ogra_: hey, I was excited to see a new core in stable hoping for logging and ntp options (though they aren't there yet). That's fine, but I wanted to play with 'snap get', so I tried 'sudo snap get core ssh' and various other things, but it didn't work | 19:41 |
| jdstrand | $ sudo snap get core ssh | 19:42 |
| jdstrand | error: snap "core" has no "ssh" configuration option | 19:42 |
| jdstrand | ogra_: I feel like I am missing something obvious | 19:42 |
| jdstrand | https://docs.ubuntu.com/core/en/guides/build-device/config-hooks only shows 'set' | 19:43 |
| kyrofa | jdstrand, assuming things haven't changed too much, you can only get things once it's been set. If the hook in the core snap doesn't `snapctl set` them when installing, you can get them | 19:43 |
| jdstrand | it seems /snap/core/1083/meta/hooks/configure doesn't implement 'get', but I've not used the configure hook | 19:43 |
| kyrofa | jdstrand, `get` is a snapd function | 19:43 |
| jdstrand | oh | 19:43 |
| kyrofa | jdstrand, it just returns the config value corresponding to that key for the snap | 19:44 |
| jdstrand | let me try with rsyslog rather than ssh | 19:44 |
| Cynerva | kyrofa: ahh okay, we'll make do without the validation for now, thanks :) | 19:44 |
| kyrofa | jdstrand, which you can set via `snap set` (in which case the `configure` hook is run and can validate it) or from within the hook via `snapctl set` | 19:44 |
| ogra_ | jdstrand, snap get service.ssh.disabled | 19:45 |
| jdstrand | sure enough | 19:45 |
| ogra_ | jdstrand, snap get service.rsyslog.disabled | 19:45 |
| jdstrand | $ sudo snap set core service.rsyslog.disable=false | 19:45 |
| ogra_ | err | 19:45 |
| jdstrand | $ sudo snap get core service.rsyslog.disable | 19:45 |
| jdstrand | false | 19:45 |
| ogra_ | yeah | 19:45 |
| ogra_ | so setting it true disables ssh | 19:45 |
| ogra_ | same for rsyslog | 19:46 |
| jdstrand | $ sudo snap get core service.ssh.disable | 19:46 |
| jdstrand | error: snap "core" has no "service.ssh" configuration option | 19:46 |
| jdstrand | right | 19:46 |
| jdstrand | so you have to 'set' it first | 19:46 |
| ogra_ | yep | 19:46 |
| jdstrand | ok, I'll file that away while I wait for ntp and remote logging :) | 19:46 |
| jdstrand | kyrofa, ogra_: thanks! | 19:46 |
| ogra_ | well, service.systemd-timesyncd.disable | 19:47 |
| ogra_ | that one wroks already | 19:47 |
| ogra_ | (so you could install an ntp snap) | 19:47 |
| ogra_ | timeserver is next on my list | 19:47 |
| mup | Bug #1665438 opened: Running command can end up with wrong security profile if refreshed <Snappy:New> <https://launchpad.net/bugs/1665438> | 19:54 |
| === mup_ is now known as mup | ||
| stokachu | im trying to make a network interface persists through reboots using the daemon configuration, the interface is listed in ip addr but no ip address or iptables rules applied, https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L20-L24 | 20:34 |
| stokachu | this is a classic snap, am i missing anything here? | 20:34 |
| stokachu | here i sthe output from systemctl status https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada | 20:35 |
| stokachu | i dont see any errors here | 20:35 |
| stokachu | https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada#file-gistfile2-txt that shows running the command directly also works | 20:37 |
| mwhudson | what's the eta on snap info showing tracks? | 20:47 |
| mup | Bug #1665184 changed: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1665184> | 20:51 |
| kyrofa | barry, python3 -m flake8 is finding the one bundled in ubuntu-image before it finds python3-flake8 | 21:09 |
| kyrofa | barry, is that a problem on my machine? | 21:09 |
| kyrofa | barry, running from the ubuntu-image deb, by the way | 21:10 |
| barry | kyrofa: i'm not sure what that means. flake8 isn't bundled with u-i | 21:10 |
| kyrofa | barry, /usr/lib/python3/dist-packages/ubuntu_image/testing/flake8.py | 21:10 |
| barry | kyrofa: how is that even on sys.path? | 21:11 |
| barry | kyrofa: show me all the commands you're doing | 21:11 |
| kyrofa | barry, within the snapcraft tree: python3 -m flake8 --max-complexity=10 snapcraft | 21:12 |
| kyrofa | barry, and boy I'll tell you... it's not happy with snapcraft :P | 21:12 |
| barry | kyrofa: you mean, you're inside a snapcraft git clone? | 21:14 |
| kyrofa | Indeed | 21:14 |
| * barry tries to repoduce | 21:14 | |
| kyrofa | barry, which contains another snapcraft directory | 21:14 |
| kyrofa | barry, my sys.path doesn't look outrageous: http://pastebin.ubuntu.com/24009515/ | 21:15 |
| barry | indeed | 21:16 |
| barry | kyrofa: wtf?! | 21:18 |
| kyrofa | barry, do you see it as well? | 21:18 |
| barry | kyrofa: i do see it in a traceback | 21:19 |
| barry | offs | 21:20 |
| barry | kyrofa: i know what the problem is :( | 21:20 |
| barry | almost | 21:22 |
| kyrofa | barry, I'm curious | 21:22 |
| barry | kyrofa: i need to find one more piece of the puzzel | 21:22 |
| barry | *puzzle | 21:22 |
| lool | oh I have a funny one | 21:22 |
| lool | I have a symlink under stage/blah that is pointing to an absolute directory location on my system | 21:23 |
| lool | snapcraft tries to go in there and change stuff :-) | 21:23 |
| kyrofa | lool, how are you getting an absolute symlink into stage? | 21:23 |
| lool | I wasn't getting this issue until I had something installed in the system location | 21:23 |
| lool | install: | | 21:24 |
| lool | # ship static symlink pointing to writable dir | 21:24 |
| lool | mkdir -p $SNAPCRAFT_PART_INSTALL/config | 21:24 |
| lool | ln -sf /var/snap/lteenb-lool/current/rf_driver \ | 21:24 |
| lool | $SNAPCRAFT_PART_INSTALL/config/rf_driver | 21:24 |
| lool | in one of my parts | 21:24 |
| kyrofa | Ah, you're just asking for trouble | 21:24 |
| lool | I need the symlink though :-/ | 21:24 |
| kyrofa | lool, snapcraft works really hard in its plugins to prevent that, because you'll end up with a broken link in the final snap | 21:24 |
| lool | kyrofa: it actually works well in the final snap! :-) | 21:24 |
| kyrofa | lool, it won't make it through review, I expect | 21:25 |
| kyrofa | Oh wait... | 21:25 |
| kyrofa | lool, you cheater! | 21:25 |
| kyrofa | I didn't read the entire path | 21:25 |
| kyrofa | But yeah, I'd still be surprised if the review tools let that through. Have you tried? | 21:25 |
| kyrofa | lool, I'm assuming the snap is called "lteenb-lool"? | 21:26 |
| lool | yes | 21:26 |
| barry | kyrofa: LP: #1631156 | 21:26 |
| mup | Bug #1631156: flake8.extension entry point has global ramifications <Ubuntu Image:Won't Fix> <https://launchpad.net/bugs/1631156> | 21:26 |
| barry | which doesn't help you much unfortunately :( | 21:26 |
| kyrofa | barry, ouch. Yeah, I guess I'll remove it then | 21:27 |
| barry | kyrofa: are you on zesty? | 21:27 |
| kyrofa | barry, xenial | 21:27 |
| barry | dang | 21:27 |
| barry | i could fix it for zesty, but i'd have to put flufl.testing in backports for y and x | 21:27 |
| barry | which maybe i should do | 21:27 |
| barry | fwiw, it has nothing to do with snapcraft; any invocation of flake8 will break :( | 21:28 |
| ogra_ | lool, and cp instead of linking doesnt work ? | 21:28 |
| lool | ogra_: would like to keep the up-to-date master configs in the snap | 21:28 |
| kyrofa | barry, alright, thank you for the investigation! | 21:29 |
| ogra_ | hmm | 21:29 |
| barry | kyrofa: let me think more on it | 21:29 |
| bdmurray | https://snapcraft.io/docs/build-snaps/metadata makes reference to using wrappers, how I can add things to the wrapper? | 21:30 |
| kyrofa | lool, what exactly are you trying to accomplish there? | 21:30 |
| lool | kyrofa: the config has an include system with include <rf_driver/foo>; rf_driver is a symlink to the actual backend | 21:30 |
| ogra_ | bdmurray, easiest is to just add another wrapper (yay onions) | 21:31 |
| kyrofa | bdmurray, those are small scripts you'd write yourself | 21:31 |
| lool | instead of having the whole config copied into SNAP_DATA, I have SNAP/rf_driver -> SNAP_DATA/rf_driver and I manage the SNAP_DATA/rf_driver symlink with the snap's config | 21:31 |
| kyrofa | lool, why not generate it at install time? | 21:31 |
| mup | PR snapcraft#1143 opened: Switch Track and Arch in channel maps <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1143> | 21:31 |
| lool | kyrofa: well the configs are under SNAP, so cant write there | 21:32 |
| bdmurray | ogra_: Could you elaborate? | 21:32 |
| ogra_ | bdmurray, command-<command>.wrapper is generated, you cant really change it ... but you can make "command" another wrapper that then calls the actual command | 21:32 |
| kyrofa | lool, ah yes of course | 21:32 |
| ogra_ | bdmurray, an onion of shell wrappers ... | 21:33 |
| kyrofa | lool, so when you say snapcraft messes with it, what do you see happening? | 21:33 |
| mup | PR snapd#2824 closed: overlord: make seeding work also on classic, optionally <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2824> | 21:33 |
| lool | generally, it doesn't build anymore right now, I think it used to with previous version; but more interestingly, when I build it with the snap installed, because the absolute symlink ends up in stage/, snapcraft dives into it and tries to move files underneath | 21:34 |
| lool | I suspect I have changed other things in the build that trigger this issue though | 21:35 |
| kyrofa | lool, yeah probably because it notices it's absolute, so it's trying to follow the symlink and copy the dir | 21:35 |
| bdmurray | ogra_: there's nothing that can be put in the yaml file to just set env variables in the wrapper? | 21:35 |
| ogra_ | bdmurray, i think something was recently added ... not sure it is in a released snapcraft yet ? | 21:36 |
| kyrofa | bdmurray, you'll be able to do that in snapcraft v2.27, in proposed | 21:36 |
| ogra_ | kyrofa, was the environment handling in snapcraft.yaml released already ? (and are there docs for bdmurray ) | 21:36 |
| kyrofa | ogra_, too slow! | 21:36 |
| ogra_ | ah, yeah :) | 21:36 |
| ogra_ | <- old fart :P | 21:37 |
| lool | kyrofa: I'll play a bit more with it, I think I can reduce the number of weird things | 21:37 |
| pmcgowan | ogra_, kyrofa which services do I need to disable to stop auto updates? is snap.refresh.service enough? | 21:45 |
| kyrofa | pmcgowan, I _think_ so | 21:45 |
| * kyrofa wonders about snapd.refresh.timer | 21:47 | |
| pmcgowan | kyrofa, that was my thought | 21:47 |
| kyrofa | pmcgowan, I haven't done this if you can't tell : | 21:48 |
| kyrofa | :P | 21:48 |
| bdmurray | How can I only rebuild the necessary parts of the snap after I added environment information to the yaml file? | 21:48 |
| kyrofa | bdmurray, just run `snapcraft` again, that meta-data is always copied over | 21:51 |
| kyrofa | bdmurray, are you running out of snapcraft master, then? | 21:52 |
| bdmurray | kyrofa: no 2.27 is in -proposed and I installed it | 21:55 |
| kyrofa | bdmurray, ah, okay | 21:55 |
| kyrofa | Then you should be good, yeah | 21:55 |
| lool | kyrofa: so I was wrong, everything is fine now; I think the new snapcraft was actually stricted and made me fix a bug (trying to install this symlink twice) which probably snapcraft shouldn't bother detecting | 21:56 |
| lool | what was really happening was that another part was shipping a default version of this symlink (the upstream one) and when snapcraft tried installing it, it installed in the system dir due to my hacked symlink | 21:56 |
| lool | not something you should worry about really | 21:57 |
| kyrofa | Ahh, yeah that would be tough | 21:57 |
| lool | once I stopped priming that copy of the symlink, things worked again just fine | 21:57 |
| kyrofa | Good catch though | 21:57 |
| lool | well snapcraft was good actually | 21:57 |
| lool | it's actually been a pleasure to do this build from source that upstream requested (instead of the from debs I had) | 21:57 |
| kyrofa | Yeah in my experience anything complex from debs just require all sorts of hackery to make work | 21:58 |
| kyrofa | From source is so much easier in a lot of cases | 21:58 |
| pmcgowan | kyrofa, after some search I decided to disable the timer just fyi | 21:59 |
| lool | kyrofa: it was from a PPA in this case, but otherwise trivial to use the debs | 21:59 |
| kyrofa | pmcgowan, I guess you'll see in a few hours if that's what was required :P | 21:59 |
| kyrofa | Ah, okay | 21:59 |
| mup | PR snapcraft#1118 closed: Trigger beta tests on travis every day <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1118> | 22:01 |
| mup | PR snapcraft#1144 opened: Trigger beta tests on travis every day <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1144> | 22:01 |
| bdmurray | kyrofa: So that didn't work out too well for me. http://pastebin.ubuntu.com/24009810/ | 22:20 |
| kyrofa | bdmurray, that doesn't mean anything to me. But I assume you're saying the environment variable wasn't defined? Can I see your snapcraft.yaml? | 22:20 |
| bdmurray | kyrofa: I'm saying I think the "\n" is an issue | 22:21 |
| kyrofa | bdmurray, wait.... you're essentially calling `open('$SNAP')`? | 22:21 |
| bdmurray | kyrofa: no $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf | 22:22 |
| kyrofa | bdmurray, point is, python isn't going to resolve that for you | 22:22 |
| kyrofa | bdmurray, I'm not sure where that's coming from in this case, but that's definitely wrong | 22:22 |
| bdmurray | APPORT_CRASHDB_CONF: $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf | 22:23 |
| bdmurray | That's what I put under environment: | 22:23 |
| kyrofa | bdmurray, looks like the environment is working then | 22:23 |
| kyrofa | bdmurray, but your python code needs to support that string containing an environment variables | 22:23 |
| kyrofa | Which it seems it does not | 22:23 |
| kyrofa | bdmurray, to be clear, $SNAP is defined at runtime, not at build time | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!