[01:22] Bug #1665184 opened: Assertion list returned by GET /v2/assertions/type can't be reliably split [01:57] 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? === markusfluer1 is now known as markusfluer [03:33] 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") === chihchun_afk is now known as chihchun === Sir_Gallantmon is now known as Son_Goku [05:50] Hi [06:50] PR snapd#2868 closed: Don't return null result for async responses [06:57] barry: even though you can have a snap that uses devmode without declaring it in snapcraft.yaml ;-) [06:58] I don't know that it's the right thing to do, but some snaps do it, and it's not being blocked [07:03] how to mount a ubuntu-core-16-dragonboard-410c.img [07:04] and write a file in to the mount partition === nhaines_ is now known as nhaines [07:27] PR snapd#2869 opened: Add Online Accounts interface === jamespag` is now known as jamespage === alan_g is now known as alan_g|afk [09:16] what's the difference between meta/snap.yaml and snapcraft.yaml? [09:17] one is used to build a snap, the other is meta information inside a snap package [09:18] snap.yaml is all the "non-build" meta info from the snapcraft.yaml usually [09:19] sometimes you create a snap.yaml manually though? [09:20] not really ... you *can* do that but it means the build takes two steps and you cant use the auto-builder on launchpad [09:22] 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] (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:23] ernstp, thats rather outdated [09:23] wow, rly? [09:23] from a time where snapcraft did not understand "type: gadget" [09:24] this page looks nice and official: https://docs.ubuntu.com/core/en/guides/build-device/board-enablement [09:24] but it's already outdated? [09:24] yet it is outdated :) [09:24] https://github.com/snapcore/pi3-gadget [09:24] have a look there [09:24] ondra, ^^^ perhaps you shoudl update that ;) [09:25] 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] hah [09:25] yeah, thats all obsolete but some of it might still work [09:26] yeah I mean debootstrap will always work I guess [09:26] its not like the underlying technology changes much there [09:26] and there's multistrap [09:27] rootstock went out of maintenance some time ago though ... but its just a script, easy to asdjust if needed [09:28] ogra_: but thanks for pointing to the pi3 thing, I'll dig through it... [09:28] if you have questions, just ask :) [09:30] ogra_: is this up to date... ? https://github.com/snapcore/snapd/wiki/Gadget-snap [09:30] it mentions meta/snap.yaml again.. === alan_g|afk is now known as alan_g [09:31] no, that needs updating too it seems [09:34] I like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder because it includes building u-boot etc [09:36] ernstp, yeah, you could just call that from the snapcraft.yaml [09:38] there's no kernel snap in the rpi3 repo? [09:38] no [09:38] the kernel is from the official builds in the ubuntu archive [09:39] right [09:39] the source for it is on kernel.ubuntu.com [09:41] I guess I'm comparing this to yocto... === chihchun is now known as chihchun_afk [09:43] you cast really :) [09:43] *cant [09:43] where you build a kernel, u-boot, pick up some userland, and then bake it all into an image [09:44] all the bits are separately upgradeable and you can also roll back each of them individually [09:44] of course the point of using Ubuntu Core would be to _not_ compile all of userland from scratch [09:44] in case of kernel that happens even automatically if a new kernel doesnt finish booting [09:45] 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] (snaps are signed readonly squashfs files) [09:48] 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] well, the kernel and bootloader, yeah [09:49] yes [09:49] (if your board is supported by the generic kernel only the bootloader ... ) [09:50] no I've got a custom board [09:51] the arm world is moving forward but it's going slow... [09:51] yep [09:52] how could that setup look then... [09:52] 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 === chihchun_afk is now known as chihchun [09:52] gadget/gadget.yaml gadget/snapcraft.yaml kernel/snapcraft.yaml [09:54] https://github.com/snapcore/snapcraft/tree/master/demos/96boards-kernel/snap [09:54] I'm using an imx6 processor plus a custom board [09:55] https://snapcraft.io/docs/reference/plugins/kernel has the docs for that [09:55] 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] right [09:56] that's exactly what I need for the kernel, pointing out config, dtb, some options and whatnot [09:57] then I want to build a gadget around that [09:57] right, and then an image [09:58] (docs for that are at https://docs.ubuntu.com/core/en/guides/build-device/image-building ) [09:59] which leads to the https://docs.ubuntu.com/core/en/guides/build-device/board-enablement page that was outdated you said [10:01] Can I reference snaps locally? [10:01] right, I can, gadget and kernel refer to snaps already existing in the store or in the current directory [10:04] ernstp, yes, with the --extra-snaps option [10:12] 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:13] so just follow it for now :) [10:37] PR snapd#2870 opened: tests: failover test for rc.local crash [11:04] PR snapd#2871 opened: utils: helper function for creating a deep copy of interface attributes [11:17] hi [11:18] I registered a new account and the profile is at https://launchpad.net/~ucrobotics123 [11:19] but when I executing " snapcraft register-key" commmand and inputing account and password [11:20] 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:43] hangun: I think it's confusingly called "Developer namespace" in the account details online [11:44] hi ernstip [11:45] how I set up the "namespace" [11:46] I dont see where to set up in my account https://launchpad.net/~ucrobotics123 [11:48] hangun, did you set it up on login.ubuntu.com ? [11:49] hangun: if you read the full error message there's an url [11:52] I set up the "Username" filed at https://login.ubuntu.com/ [11:53] any role for that? [11:53] my username is "ucrobotics123" [11:53] and you can log in with that on https://myapps.developer.ubuntu.com ? [11:54] there is a ""developer namespace" option in the account settings [12:03] thanks ogra_ [12:03] it works now [12:09] I have another question: after snappy system booting up, executing commands " snap install hello-world" , "hello-world" [12:10] but got error like this: cannot bind-mount the mount namespace file /proc/11268/ns/mnt -> hello-world.mnd [12:10] support process for mount namespace capture exited abnormally [12:14] 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] remote: Permission to snapcore/spread.git denied to sergiocazzolato [12:14] cachio: Hi [12:14] cachio: Got your email as well [12:14] 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:15] cachio: You don't need write access to the master branch for that [12:15] niemeyer, I did that [12:16] cachio: Not really.. you see the message above? [12:16] cachio: You're trying to write into snapcore/spread.git.. that's not your fork [12:16] niemeyer, in that case I' try again [12:16] cachio: You're not supposed to be able to push there (yet, at least) [12:17] niemeyer, ok [12:22] hello all [12:22] I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457 [12:22] Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 [12:35] hello, sorry from being absent from IRC [12:36] anyone had a question about namespaces in snaps? [12:47] zyga, that was hangun [12:47] more abour namespaces in kernel i suspect though [12:47] *about [12:48] PR snapd#2864 closed: interfaces: API additions for interface hooks [12:48] hangun: hey [12:48] hangun: how can I help you, can you please repeat your question? === cosmo_ is now known as cos [12:51] PR snapd#2524 closed: interfaces/builtin,cmd/snap-confine: add the overmount interface [12:52] zyga: [12:52] hello all [12:52] 10:22:33 I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457 [12:52] Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 [12:54] heh, and he left [12:59] PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions [13:11] zyga: hey, why make the libcap stuff conditional? it will work everywhere [13:12] jdstrand: because we cannot add dependencies to snapd easily now [13:12] jdstrand: I want to just enable it on compile time if it is available [13:13] jdstrand: and as we work on resolving the other bug (that affects apt) we can just hard-depend on it [13:13] zyga: but the code is correct... why can't you add a dependency? [13:13] jdstrand: right now because of how apt works it means people will not update [13:13] jdstrand: mvo has the gory details [13:13] jdstrand: but that's the bottom line [13:13] we add new stuff all the time [13:13] look at bind9 updates [13:14] this isn't a reason to not do stuff [13:14] jdstrand: and stats show us that people are stuck on ancient snapd [13:14] I know that thread [13:14] jdstrand: we researched this, apt behaves this way if you use a particular command [13:14] so fix apt [13:14] that was the takeaway from the conversation as I understood it [13:15] jdstrand: I'm not aware of that, I need to ask mvo [13:15] jdstrand: I asked him today and he recommended against adding deps to snapd [13:15] jdstrand: in any case, on ubuntu the build will not use libcap and will just do that unconditionally [13:16] jdstrand: on fedora we can use libcap [13:16] jdstrand: I think this is fine [13:16] jdstrand: until we can address the issue in apt [13:16] I don't think it is fine because it adds code complexity in the setgroups check [13:16] jdstrand: wh? [13:17] *why? [13:17] we are using libcap to see if we can use setgroup [13:17] the only complexity will be an #ifdef in the sc_has_capabaility [13:17] no [13:17] without libcap it will just say yes [13:17] and that will be wrong [13:17] why? [13:17] if you call drop privs as non-root, setgroups will fail [13:18] that is the whole reason the check is there [13:18] oh we ca easily check for that [13:18] we have the cap if running as root [13:18] yes, but the code is correct. we need to fix the underlying problem, not contort our code [13:18] that's one line in the #else part of the has_capability [13:19] 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:21] also, the xfslibs change also introduced a dependency. are we going to yank that out? cause that will affect security policy [13:21] kernels, bind9, and other things all do this regularly in the distro [13:21] jdstrand: I noticed that too [13:21] jdstrand: one secodn [13:21] jdstrand: (mvo says it is hard socially) [13:22] jdstrand: for that I think we just need the macro definitions [13:22] jdstrand: not any real dependency at runtime, right? [13:24] jdstrand: or we can link libacap statically [13:24] jdstrand: that's easy too [13:24] jdstrand: would you +1 that? [13:25] :/ [13:26] for quota patch, it shouldn't pull in a runtime dep, only the build afaics (according to ldd) [13:27] jdstrand: I think we pulled in libhandle, not sure why [13:27] I saw it in ldd [13:27] Son_Goku: hey [13:27] oh, I don't have the right branch, hold on [13:27] zyga: hi [13:27] jdstrand: I mean libhandle from xfs is in master [13:29] no, I have the right branch [13:29] ldd ./snap-confine/snap-confine [13:29] I see no libhandle [13:30] that is with quota patches but not up to date master [13:31] and with up to date master, no libhandle [13:32] mvo: hey, can you comment on the no new deps thing? ^ [13:32] jdstrand: I agree, I wonder why I saw it on centos, I'll check later [13:34] Son_Goku: question, so the centos package [13:35] Son_Goku: can we build a small centos package separately from the fedora package? [13:35] Son_Goku: just something that could live in copr for now [13:35] Son_Goku: I was looking at rhel and man, no build deps for anything [13:35] haha [13:35] jdstrand: in a meeting right now [13:35] Son_Goku: so I think the package should build on centos first [13:35] well, if it can build in EPEL, that's enough [13:35] Son_Goku: and then can move over as a binary package [13:35] Son_Goku: exactly [13:35] no, I mean, that's enough for everyone (CentOS, RHEL, etc.) [13:36] Son_Goku: did you see my blog post about centos? [13:36] Son_Goku: ah, I see [13:36] EPEL is RHEL + EPEL packages [13:36] jdstrand: what dependency was that again? [13:36] and because CentOS is binary compatible, it works there [13:36] mvo: libcap2 [13:36] mvo: (and libcap-dev as build-dep) [13:36] mvo: this time, libcap [13:36] libcap2, yes [13:36] jdstrand: isn't that part of a the default install anyway? [13:37] if so, we are fine [13:37] hmmm, good question [13:37] let me double check [13:37] it is in main [13:37] we definitiely ship it in core [13:37] I checked the apt-cache rdepends, but didn't finish looking at it before I got fired up :) [13:37] it is installed in my pbuilder chroot [13:37] ogra_: we have libcap-ng in core [13:37] I think it's in bydefault [13:38] jdstrand: in that case let's re-open and land as-is [13:38] PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions [13:38] avahi-daemon needs it, so it is in the desktop [13:38] jdstrand: can you review it now [13:39] iputils-ping needs it, and that is in minimal [13:39] jdstrand, i see libcap2 here and libcap2-bin [13:39] (on trusty) [13:39] hi zyga [13:39] same for xenial [13:39] just left for a while [13:39] on trusty we still use the same core [13:40] https://launchpadlibrarian.net/306642126/core_16.04.1_amd64.manifest is the manifest file for the core snap [13:40] and yakkety and zesty [13:40] 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:41] zyga: EPEL in Koji uses RHEL 7 base, EPEL in COPR uses CentOS 7 base [13:41] http://people.canonical.com/~ogra/core-builds/ has links to all the manifests [13:41] ogra_: you are right. libcap2 is in /lib but libcap-ng is in /usr/lib. I only checked /usr/lib [13:41] it's in minimal, so crisis averted for this [13:42] jdstrand: bah, UsrMerge :) [13:42] do iiiit :D [13:42] however, I thought a fix for apt-get was the way to go to make it work the same as apt [13:42] Son_Goku: I suspect 18 will do it [13:42] FINALLY [13:43] Son_Goku: nobody cares though :) [13:43] :'( [13:43] it's a change that changes nothing relevant for anyone [13:43] internal refactor [13:43] y'all suck :) [13:43] hangun: hi [13:43] hangun: I want to help you with the issue you mentioned [13:43] hangun: I merged a small fix into snapd master that affects 3.10 [13:43] 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:44] jdstrand: yes, I agree, though we will use core libs for re-exec linking it statically is not a bad idea [13:44] hangun: can you try master and tell me exactly what error are you getting [13:44] zyga: well, re-exec is only for classic [13:45] jdstrand: yes [13:45] jdstrand: do you see advantages to static linking on core? [13:47] 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] it does mean that we need to rebuild for security updates [13:47] it is something to think about. I'm not recommending it atm, just thinking out loud [13:48] jdstrand: I think we should add that to the list of things to investigate once core splits into core + base [13:48] jdstrand: could be used to keep core totally tiny [13:48] well, it would actually be a little bigger [13:48] PR snapd#2872 opened: tests: only check core refresh if there's no update available [13:49] 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] jdstrand: only if something else also depends on libcap in core [13:49] zyga: My env like this snapd version (2.21), snapcraft version (2.26) ubuntu-snappy version (2.21). [13:49] libcap is the only thing [13:49] that it would save [13:49] hangun: you need to build snapd from master [13:49] if it is totally staically compiled, then libc is there and in core [13:50] hangun: there's a lot of improvements that landed since 2.21 [13:50] hangun: and the fix to 3.10 that I did is not released yet [13:50] 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] hangun: (though without apparmor) [13:50] hangun: but you need that fix to get it to work anyway [13:51] lool: lool: https://github.com/morphis/tvheadend/tree/snap-support [13:51] of course, you could just statically link libcap [13:51] anyway, something to think about [13:51] PR snapd#2835 closed: strutil: support version compare with empty strings [13:52] zyga: thanks, i try it now. [13:54] Son_Goku: what are those notificationabout snap-confine for f23 being deleted? [13:54] Son_Goku: is that because of EOL? [13:54] no [13:54] I think it's because you never submitted them as updates [13:55] so what is exactly being deleted? [13:55] if they're not tagged, koji aggressively gc's them [13:55] the build artifacts [13:55] ah [13:55] that's fine [13:55] Son_Goku: we should try to get those packages out [13:55] Son_Goku: 2.23 has all the fixes for fedora now [13:55] is it released? [13:56] I didn't see mvo announce 2.23 yet [13:56] did we also get any new systemd units that I need to refresh my systemd unit patch for? [13:58] Son_Goku: mvo will release it today I think [13:58] mvo: when is the release? today? [13:58] Son_Goku: no, we can drop units now [13:58] Son_Goku: more less [13:58] well, our systemd units work slightly differently from ubuntu's remember [13:58] Son_Goku: we have a packaging/ directory [13:58] Son_Goku: yes, I mean we should put them there [13:58] Son_Goku: if you commit them we don't need to carry the patch [13:58] well, I can certainly submit a PR with them, if you'd like [13:58] Son_Goku: please, I really want those [13:59] Son_Goku: you didn't answer my question about the centos blog post [13:59] I didn't read it yet [13:59] Son_Goku: did you see the stuff I added there? [13:59] Son_Goku: ah, OK [13:59] reading it now [14:00] looks like zbyszek left comments on your blog? [14:00] Son_Goku: yes [14:00] Son_Goku: nice to see feedback from systemd developers :) [14:00] talking to them often helps, too :) [14:01] Lukas and Zbyszek are nice people [14:01] I'm sure, I'd love to meet them in person one day [14:01] Lukas is the RHEL systemd maintainer, and Zbyszek is the Fedora one [14:01] I could use more sleep ;) [14:01] or more coffee :) [14:01] I think I need to survive too ;) [14:02] 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] hangun: yes that is it [14:02] morphis: awesome! [14:03] hangun: not sure where are the nighly packages, I think they are built somewhere but I cannot say [14:03] 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:04] hangun: https://new.zygoon.pl/post/case-study-snapd-on-centos/ [14:04] zyga: awesome [14:04] hangun: feel free to ping me with question [14:05] hangun: you can try to build just the snap-confine parts [14:05] hangun: and you can make install DESTDIR=/tmp/foo if you just need a particular file to test [14:05] hangun: I'm not sure what the process is on your device [14:06] zyga: my board is bubblegum 96board http://www.96boards.org/product/bubblegum-96/ [14:09] hangun: I see [14:09] I don't have that board at home [14:10] hopefully all needed config options are set in that kernel [14:10] zyga: i will re-build snapd following your blog [14:12] PR snapd#2841 closed: interfaces: allow recv* and send* by default, accept4 with accept and other cleanups [14:14] PR snapd#2842 closed: interfaces: misc updates for network-control, firewall-control, unity7 and default policy [14:15] zyga, what should I label the folder inside of packaging/ ? [14:15] I originally was using the catch-all top level directory dist/, but I guess that doesn't fit here [14:18] Son_Goku: just put packaging/fedora-25 there [14:18] Son_Goku: we can use symlinks for others [14:18] Son_Goku: and then we can use that in downstream packages [14:19] Son_Goku: we can also keep a copy of the spec for CI [14:19] even if the units are useful for more than fedora? they're basically the ones anyone that isn't using Debian uses [14:19] Son_Goku: yes [14:19] Son_Goku: symlinks :) [14:19] Son_Goku: we can sim;lify over time [14:19] okay [14:20] as for spec for CI, that would mean that snapcore-selinux needs to somehow be available for spread to pull in [14:20] or is it always going to retrieve that from fedora dist-git? [14:20] Son_Goku: yes, I think we can come up with something [14:20] okay [14:20] Son_Goku: not sure yet [14:21] jdstrand: what about 2863? [14:21] jdstrand: I'd like that in candidate that's going out now [14:21] PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions