=== jamesh_ is now known as jamesh [02:21] PR snapcraft#1198 closed: tests: add manual tests for the kernel snaps [02:24] PR snapcraft#1200 closed: tests: allow to run individual autopkgtest suites === chihchun_afk is now known as chihchun [04:18] Bug #1629423 changed: Ordering of command line arguments matters === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [05:30] PR snapcraft#1206 opened: Arm64 witness [07:20] zyga: hi, i upgrade snapd to 2.23.1 on opensuse. now i'm installing hello-world and it stuck at "Run configure hook of core snap if present". anything I miss? [07:28] shuduo: hi [07:28] shuduo: hey, known issue in the core snap, I think it was resolved last night but let me check [07:28] shuduo: thank you for reporting this [07:30] zyga: welcome. just want everything perfect when i show off it to customer in future. :) [07:34] zyga: one more question, i follow your blog https://new.zygoon.pl/post/case-study-snapd-on-centos/ to build snapd on centos 7. and i got error "cannot find -lcap" when making in cmd directory. but actually libcap-devel 2.22 is installed by default. i'm curious how you make it. thanks. [07:37] shuduo: when I wrote the blog the build system had different requirements, there's a PR waiting now that once landed will make it build easily anywhere [07:37] shuduo: the problem is that we need static libcap in certain case [07:37] shuduo: I have a PR ... [07:38] one sec [07:38] this one: https://github.com/snapcore/snapd/pull/3039 [07:38] PR snapd#3039: many: add support for partially static builds [07:38] if you merge that in you should just get a clean build [07:39] zyga: got it. let me try it. thanks! [07:40] shuduo: one more question, what does snap list say for you on suse? [07:43] shuduo: I'm refreshing core on my 42.2 leap system now [07:43] zyga: only core 16-2 1441 [07:43] I had 1512 but we reverted that to 14xx last night [07:45] shuduo: ok, reproduced [07:45] man.... [07:45] those issues :-( [07:46] zyga: i'm using tumbleweed. [07:47] right, I think this bug is in snapd [07:47] I'll get right to it and investigate [07:47] I'll release an update that puts a timeout on the configure hook at least so that people are not stuck forever [07:48] zyga: good to know. :) [07:48] or even disable the configure hook on classic, it's not useful anyway yet [07:48] shuduo: did you report this anywhere? [07:49] zyga: not yet. if you want I am happy to do that. [07:50] shuduo: I think there is a report of this on debian [07:50] let me find it [07:51] shuduo: https://bugs.launchpad.net/snappy/+bug/1674193 [07:51] Bug #1674193: core snap's configuration hangs on debian [07:51] can you please add to this bug that it also happens on tumbleweed and leap 42.2 [07:51] add snap --version to the bug report too [07:51] zyga: okay [09:33] PR snapd#3070 opened: overlord: maintain per-revision snapshots of snap configuration [09:38] PR snapd#3061 closed: interfaces: rename thumbnailer to thumbnailer-service [09:43] PR snapd#3011 closed: tests: remove core_name variable [09:55] hey guys question. Is there a way I can tell snapcraft to get the build parts it needs from a deb file so I can then pull from github? Kinda like apt build-deps [10:05] davmor2, you mean the build-packages option in snapcraft.yaml ? [10:05] ogra_: could be I was just asking if there was one [10:05] indeed there is :) [10:06] ogra_: awesome I might try a edge build of pronterface and slic3r [10:10] zyga_: so build on fedora is running, as you said, pretty easy to get that up and running :-) [10:11] PR snapd#2987 closed: store: download from authenticated URL if there is a device session set [10:12] morphis_ , zyga_ [10:17] Son_Goku: you have two different nicks? :-) [10:17] I have three, actually [10:17] King_InuYasha is the third [10:17] ah :-) === zyga_ is now known as zyga [10:17] good to know, each for a differnt machine? [10:17] yep [10:17] so fedpkg is actually quite nice [10:18] yes, it's full of win [10:18] but looks like we have to combine the packaging for snap-confine and snapd now that boht are build from the same source tree [10:18] where's this hangout thing so I can pop in [10:18] yeah, I already started doing that... :/ [10:18] there isn't one right now [10:18] Son_Goku: ah great, how far did you come? [10:18] snap-confine stuff builds, but snapd doesn't :( [10:19] Son_Goku: is that work available somewhere? [10:19] yep [10:19] one sec [10:21] Son_Goku: we finished as morphis_ didn't have his fedora account yet [10:21] zyga: I do now [10:29] morphis_: what's your FAS? [10:29] Son_Goku: mrmorph === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [10:38] [06:38:30 AM] .fasinfo mrmorph [10:38] [06:38:31 AM] Son_Goku: User: mrmorph, Name: Simon Fels, email: morphis@gravedo.de, Creation: 2017-03-22, IRC Nick: morphis, Timezone: UTC, Locale: en, GPG key ID: 1412DB3B, Status: active [10:38] [06:38:34 AM] Son_Goku: Approved Groups: cla_done cla_fpca [10:39] morphis_, so that's you, morphis_ ^ [10:39] Son_Goku: yes [10:43] morphis_: so you now need to go through the first-time packager process [10:43] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers [10:44] yeah, already working through that [10:44] and don't forget to also be in #fedora-devel IRC [10:45] lots of people hang out there and when real-time communications are supposed to happen, people like poking there [10:45] thanks for that pointer! [10:45] aye [10:45] good to know [10:47] jdstrand: hey, https://bugs.launchpad.net/snappy/+bug/1674505 might be of interest to you; one part of it is about apparmor home permissions when running under sudo [10:47] Bug #1674505: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build === morphis_ is now known as morphis [10:50] Son_Goku: so you started work on combining the snapd/snap-confine packaging, did you also start work on updating the packaging to a more recent snapd version? [10:50] yes [10:52] Son_Goku: is that work somewhere too? [10:52] yes [10:53] morphis: https://github.com/Conan-Kudo/snapd/commit/4c71ef5a9e6e89cf8aa2d31eef12be7e2e66d1bd [10:53] Son_Goku: ah nice! [10:54] Son_Goku: I guess there is a reason why you had to copy the systemd unit files, right? [10:54] the original systemd units use /snap and /usr/lib/snapd [10:55] ah right [10:55] Fedora uses the saner paths /var/lib/snapd/snap and /usr/libexec/snapd [10:55] Son_Goku: wondering if we can't change that via unit mixin's [10:57] Son_Goku: that way we could keep the original files and just change what we need to [10:58] mixin's? [10:58] Son_Goku: we can use sed later [10:58] Son_Goku: or add this to packaging/fedora [10:58] Son_Goku: for sanity [10:58] /lib/systemd/systemd/snapd.service.d/fedora.conf [10:58] Son_Goku: then we can just maintain it in one spot [10:58] everything in fedora.conf gets applied to the original unit file [10:59] morphis: ideally, the unit file would actually be a template and debubuntu and fedora packaging would convert them properly [11:00] possible [11:00] but using sed in the spec file would be another way [11:00] yes, using sed would be required in this case, actually [11:01] Son_Goku: so what is left to do in that branch you shared above? [11:01] as we'd most likely have service.in files with @libexecdir@ and @snapmountdir@ and those would be sedded in the spec [11:01] morphis: not much actually, the problem is that build deps can't be satisfied [11:01] and the vendorized build (for EPEL) doesn't work [11:02] it fails on the link stage due to choking on hardening flags [11:03] I've already finished the other adaptations, and one thing you can really do now is start working on the missing golang build deps [11:04] that's "golang(github.com/ojii/gettext.go)" and "golang(gopkg.in/retry.v1)" [11:04] those do not exist in fedora at all in the moment? [11:04] nope [11:05] ok [11:05] packaging is mostly automated, through the gofed tool [11:05] you should be able to generate packaging using it [11:05] yeah heard that, can't wait to see that in action :-) [11:05] https://github.com/gofed/gofed [11:05] on your Fedora system, do "sudo dnf install gofed*" to install all the gofed packages [11:06] since they broke up the functionality into lots of subpackages :/ [11:07] gofed is quite powerful, as it is also capable of doing something close to API/ABI checking of golang things [11:07] Son_Goku: nice [11:08] Son_Goku: ok, on my list [11:13] let me know when you've made the review requests [11:14] will do [11:27] PR snapcraft#1207 opened: kernel plugin: stop duplicating initrd and image file, use symlinks f… === chihchun is now known as chihchun_afk === femme_ is now known as femme [11:54] Bug #1674505 opened: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build === JanC_ is now known as JanC [11:57] PR snapcraft#1202 closed: python plugin: support pbr/setup.cfg projects [12:09] Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build === zyga_ is now known as zyga [12:14] Son_Goku: to build the package from the packaging/ directory, I can't use fedpkg, right? [12:14] no, you can't [12:14] you need to set up the tree correctly for it [12:14] rpmbuild then? [12:14] yes [12:15] set the tree up correctly, then rpmbuild -bs [12:15] then mock [12:15] that way you don't need all builddeps installed on your system [12:16] sounds good, the source package snapd-2.23.1.tar.gz is what I need to provide, right? it doesn't generate it from the source tree [12:17] well, since snapd-2.23.1 actually has all the things [12:17] you can use spectool to download the sources :) [12:17] ah [12:17] spectool -C ~/rpmbuild/SOURCES -g snapd.spec [12:17] that was the point I was missing [12:18] you'll want to apply the patch adding fedora packaging stuff as a patch in the spec [12:18] that way, things like the systemd unit are available in the right place [12:18] PR snapcraft#1206 closed: Arm64 witness === hikiko is now known as hikiko|ln [12:52] pedronis: hey, am I crazy or is there an auto-connect bug: http://paste.ubuntu.com/24228316/ === hikiko|ln is now known as hikiko [13:16] jdstrand: maybe [13:18] pedronis: so, I tried quite a few things. I tried in the wpa slot side 'allow-auto-connection: true' and on the nm side 'allow-auto-connection: true', and various alternations. I didn't try to change the wpa connection contraint alternation though [13:18] jdstrand: that's not relevant if there is something in the plug [13:19] well, unless there is a bug of course [13:19] plug should be the only interesting one [13:19] well, that logic is quite clear cut [13:19] there might be a bug [13:19] but it might not be about assertions [13:19] fwiw [13:19] but yes, on the nm plugs I did simple "allow-auto-connection: true" and that didn't work [13:19] pedronis: shall I file a bug then? [13:20] pedronis: I just wanted to ping you here to double check my expectation that the snap decl should allow it [13:20] s/just/mostly/ [13:21] I think it should but as I said I suspect either we are missing something obvious or the bug might not be in the assertion level [13:21] because we have exercized that for other things quite a bit [13:21] and it's rather clear cut [13:21] I'll file a bug then [13:23] pedronis: thanks [13:23] jdstrand: hey, is there an existing bug/spec for tun/tap devices in snaps? the snap I'm looking after calls mknod directly to create a tun device; tun/tap are probably common for VPN/VNF use cases [13:27] lool: tun and tap devices are allowed by the network-control interface. mknod is not allowed anywhere, but there is a pr to allow it to create non-devices. I suspect you are asking for mknod of these devices. the application should instead use ioctl on /dev/net/tun and then the devices will be created without needing mknod. see https://www.kernel.org/doc/Documentation/networking/tuntap.txt [13:28] jdstrand: awesome, that's exactly what I was looking for; do you know if tunctl implements the right ioctl dance? [13:29] lool: I'm not familiar with that tool. let me check [13:29] Hmm I'm kind of suspicious that this is still relevant given it was in uml-utilities [13:29] my god I'm old [13:29] I suspect iproute can do it === allison[m] is now known as allison [13:30] right, ip is the right tool, let's check if it does the ioctl [13:30] if (ioctl(fd, TUNSETIFF, ifr)) { [13:30] it does! [13:30] lool: ethertap.c unconditionally does a mknod [13:31] ok, good, use that instead :) [13:31] jdstrand: hola. Hey I wanted to mention: last week we deployed some tweaks to the upload queue for a snap. The first upload that's "blocking" the queue due to needing manual review is now shown. Also, the snap's developer can now self-reject uploads pending review so they can self-unclog their snap's queue [13:31] jdstrand: I'm kind of ashamed of mentioning user-mode linux on a public channel in 2017 [13:32] lool: now, if /dev/net/tun doesn't exist then the tuntap.txt I referenced says to mknod that. if you encoutner this situation, I think snapd should do that for you, and that would be a bug against snapd [13:32] roadmr: I saw! I've taken advantage of both already. thanks!! :) [13:32] ah [13:32] lool: hehe [13:32] whee :) glad to hear jdstrand. [13:34] lool: I think udev is going to create /dev/net/tun automatically. I see it on bbb and other places where I'm not using tun/tap devices [13:38] jdstrand: ok; I'll try to get more info; it's closed source, but I can ask to run it unconfined and see what it actually does [13:47] olive: I was on holiday last week. did someone else answer your question? if not, I'm here now [13:50] jdstrand: thank you, stgraber answered me at #lxcontainers ;) [13:50] olive: great :) [13:54] jdstrand: reading your bug, remember auto-connection works only if there is only one possibility, not sure it's relevant [13:55] jdstrand: and I don't remember if assertions are used or not to prune down options anyway your assertion doesn't have extra info for that [13:59] jdstrand, do you happen to know why https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_setup_control.go has no execution rights for "netplan generate" ? [13:59] jdstrand: you need some rule that name needs to be same [13:59] i assume just copying the file into the dir wont be enough [14:00] PR snapcraft#878 closed: Added a fix for cases where modpbrobe append options to the line, ie.… [14:00] PR snapcraft#1208 opened: kernel plugin: fix modprobe output parsing [14:02] jdstrand: there should be only one possibility, and assertions are used for pruning, and also the interface AutoConnect() method but I don't see anything that would pick only one in your example [14:06] pedronis: I did try to use constraint alternations for allow-auto-connection using plug-attributes: { name: ... } [14:06] jdstrand: ? [14:06] jdstrand: but the plug rule has nothing [14:06] nor the interface [14:07] it seems like we need a rule either in code or assertions that compare name? [14:07] pedronis: the plug side does have something. it specifies the interface, the name and the bus [14:07] jdstrand: in the assertion? [14:07] the code afaict doesn't do anything [14:07] with name atm [14:07] pedronis: I'm saying I attempted an assertion that did that [14:07] I mean dbus interface code [14:08] hey ogra_: can you please check out this bug a client filed? I'm not sure what the next step is, but it's critical for them: https://bugs.launchpad.net/snappy/+bug/1674778 [14:08] Bug #1674778: snapd hangs with 100% CPU usage when image has a custom gadget snap [14:08] that's not what is in the bug though [14:08] pedronis: no it isn't. I did say towards the end that I tried other things [14:08] kyleN, niemeyer wanted to look into that one he just said in our team meeting ;) [14:08] anyway given there are two slots what is in the bug cannot work for sure I think [14:08] pedronis: I can give the example that I tried [14:09] the auto connect logic finds two cands and says nope [14:09] kyleN, we were actively talking to renat yesterday night and asked him to file that bug [14:09] ogra_, ok thanks. just wanted to be sure it was noted [14:09] it surely is [14:09] ogra_: cause the person who wrote the interface didn't ask for it :) [14:10] pedronis: ok, let me try something else then [14:10] jdstrand, haha ... well unless netplan has a clever inotify implem,entation i suspect the interface is pointless without being able to run "netplan generate" and "netplan apply" [14:12] jdstrand: another option would be to change dbus AutoConnect method, usually atm it's always just true because we do things with decls though [14:14] jdstrand, hey [14:15] jdstrand, I have build a dbus snap which is adding a dbus slot and plugs the same one [14:15] I am getting a apparmor DENIED when I try to run in strict mode [14:15] jdstrand, any idea? [14:16] cachio: is the interface connected? [14:16] cachio: snap interfaces [14:16] yes [14:16] jdstrand, I connected the slot and the interface manually [14:17] cachio: can you paste the output of 'snap interfaces'? [14:18] jdstrand, http://paste.ubuntu.com/24228789/ [14:19] cachio: can you paste /snap/kpi-dbus-tests/current/meta/snap.yaml [14:19] jdstrand, that http://paste.ubuntu.com/24228795/ [14:20] jdstrand, http://paste.ubuntu.com/24228800/ [14:20] cachio: oh, that is a noisy denial that has nothing to do with the dbus interface. to get rid of it you can plugs: mount-observe [14:20] that is a libc thing [14:20] jdstrand, ah, ok [14:21] jdstrand, I'll try that [14:27] jdstrand, should I connect against mount-observe? [14:27] jdstrand, I am getting that denied [14:28] cachio: mount-observe needs a manual connection [14:28] jdstrand, which slot should I use? [14:29] cachio: you 'plugs: [ mount-observe ]' [14:29] yes [14:29] sudo snap connect kpi-dbus-tests:mount-observe [14:29] jdstrand, ok [14:30] (you can use that instead of 'sudo snap connect kpi-dbus-tests:mount-observe :mount-observe' since it is an implicit slot [14:32] jdstrand, I see that now [ 4068.867293] wcn36xx: ERROR hal_remove_bsskey response failed err=6 [14:32] cachio: are there denials in the log? [14:33] jdstrand, yes, from dmesg [14:33] PR snapcraft#1150 closed: kernel plugin: rework MAKEFLAGS from the environment [14:33] can you paste the denials that happen after you connected the mount-observe interface? [14:34] jdstrand, I don't see any denial, just that error [14:35] jdstrand, is it related to the snap? [14:38] cachio: it is probably a snap issue then. you should try again after doing this though: sudo sysctl -w kernel.printk_ratelimit=0 [14:39] cachio: that will disable kernel rate limiting (sometimes denials are rate limited). you should also look in syslog, not dmesg since dmesg won't show dbus denials [14:40] jdstrand, ok, I'll try that, tx [14:44] PR core#29 opened: drop sync from hooks/configure, it isnt in the interface [14:55] Bug #1675054 opened: "snap info" should provide detailed track/channel release information. [14:57] morphis: have a look at https://github.com/gofed/gofed/issues/131 [14:58] Pharaoh_Atem: thanks for reporting that and wow, that's one quick fix :) [14:58] morphis: this should help you out a lot [14:58] morphis: you can use that technique to just quickly patch gofed locally and package the last bit [15:05] ogra_: I'm seeing a problem with dragonboard images that seems to have started recently. We generate our own for automated tests with ubuntu-image so that we can apply a user assertion, and pretty soon after booting it, it wants to transition from ubuntu-core to core [15:05] ogra_: so if I try to install a snap in that window, before it reboots after, it says: "ubuntu-core to core transition in progress, no other changes allowed until this is done" [15:06] err [15:06] but if we are building the image right then, shouldn't it already have core instead of ubuntu-core? why does it need to upgrade right away? [15:06] ubuntu-core is long dead for images [15:06] yeah I thought so [15:06] so i wonder what gives it the idea there would be any ubuntu-core to upgrade from [15:07] ogra_: that's not something that came from the model is it? [15:07] no, iirc the model doesnt define core, only kernel and gadgetz [15:07] do you actually see any ubuntu-core under /snap ?? [15:10] PR snapd#3025 closed: cmd/snap-update-ns: compute the actions required to transform mount environment [15:10] zyga: yeah I saw some crashes too but got those two missing deps for snapd now building [15:11] zyga, Pharaoh_Atem: also it looks like the gofed tool generates invalid spec files as the changelog at the bottom is somehow messed up in my cases [15:11] but as long as it works and gives me something I can tune I am happy for now [15:12] ogra_: yes [15:12] plars, how did that get there ? :) [15:12] ubuntu-core 16-2 1889 [15:12] plars, do you use an ancient ubuntu-image ? [15:13] ubuntu-image 0.12+real1 37 [15:13] nothing should install ubuntu-core anymore ... sincwe 6 weeks or even longer [15:13] thats pretty old [15:13] oh, it looks like there's a newer version... I guess it didn't refresh because it's devmode [15:13] yeah [15:13] ah, ok [15:14] 0.15+snap3 now [15:14] let me try that, hopefully that's all it was :) [15:14] right, try again weith that [15:14] morphis: what is the changelog you are getting? [15:14] thanks! [15:14] at least it should use core now and not try to upgrade ... no guarantees for anything else :) [15:14] heh, ok [15:16] Hi! Can I know which ppa generally contains snapd release candidate ? also, is there a "edge" aka daily ppa as well ? [15:18] om26er, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial [15:18] ogra_: is there one for RC ? [15:19] om26er, well, thats usually xenial-proposed ... but sometimes it gets uploaded in parallel to https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial [15:22] hmm, so I guess -proposed is more reliable than a ppa for release candidates. [15:23] yes [15:23] om26er, release candidates are in -proposed [15:23] om26er, /image is used before uploading to proposed [15:23] it's a bit an equivalent of a beta [15:24] jibel: so shall we track xenial-proposed and for dailies, the edge ppa ? [15:24] om26er, yes [15:24] zyga: %changelog* Wed Mar 22 2017 Simon Fels - 0-0.1.gitb6dae1d [15:24] so both things are in the same line which the tools don't like [15:25] but its just another bug in gofed [15:29] PR core#29 closed: drop sync from hooks/configure === chihchun_afk is now known as chihchun [15:31] ogra_: can you tell the version scheme for snapd used here includes the time of upload https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial ? [15:31] 201703221024 aka YYYYMMDDHHMM ? [15:31] or if you could point me to the right person. [15:32] om26er, i think thats correct ... [15:32] the right person would be mvo, but he is off sick this week [15:37] morphis: I dunno why it always generates bad changelog sections [15:38] it's easy enough to fix thankfully :) [15:50] jdstrand: I put a comment in the bug [15:56] ogra_: ok, that didn't seem to help, but I think I may have it resolved now. I upgraded snapd on the host that built the image, and then it updated to core from ubuntu-core, and now the new images seem to have core in them [15:56] cool [15:57] i thought ubuntu-image does it ... but indeed, ubuntu-image only acts as frontend for "snap prepare-image" [16:13] morphis: weird, I never saw that [16:25] zyga: yeah [16:27] PR snapcraft#1145 closed: tests: expect failures for the tests that can't be run in arm64