[02:21] <mup> PR snapcraft#1198 closed: tests: add manual tests for the kernel snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1198>
[02:24] <mup> PR snapcraft#1200 closed: tests: allow to run individual autopkgtest suites <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1200>
[04:18] <mup> Bug #1629423 changed: Ordering of command line arguments matters <eco-team> <Snappy:Expired> <https://launchpad.net/bugs/1629423>
[05:30] <mup> PR snapcraft#1206 opened: Arm64 witness <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1206>
[07:20] <shuduo> 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] <zyga> shuduo: hi
[07:28] <zyga> shuduo: hey, known issue in the core snap, I think it was resolved last night but let me check
[07:28] <zyga> shuduo: thank you for reporting this
[07:30] <shuduo> zyga: welcome. just want everything perfect when i show off it to customer in future. :)
[07:34] <shuduo> 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] <zyga> 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] <zyga> shuduo: the problem is that we need static libcap in certain case
[07:37] <zyga> shuduo: I have a PR ...
[07:38] <zyga> one sec
[07:38] <zyga> this one: https://github.com/snapcore/snapd/pull/3039
[07:38] <mup> PR snapd#3039: many: add support for partially static builds <Created by zyga> <https://github.com/snapcore/snapd/pull/3039>
[07:38] <zyga> if you merge that in you should just get a clean build
[07:39] <shuduo> zyga: got it. let me try it. thanks!
[07:40] <zyga> shuduo: one more question, what does snap list say for you on suse?
[07:43] <zyga> shuduo: I'm refreshing core on my 42.2 leap system now
[07:43] <shuduo> zyga: only core 16-2 1441
[07:43] <zyga> I had 1512 but we reverted that to 14xx last night
[07:45] <zyga> shuduo: ok, reproduced
[07:45] <zyga> man....
[07:45] <zyga> those issues :-(
[07:46] <shuduo> zyga: i'm using tumbleweed.
[07:47] <zyga> right, I think this bug is in snapd
[07:47] <zyga> I'll get right to it and investigate
[07:47] <zyga> I'll release an update that puts a timeout on the configure hook at least so that people are not stuck forever
[07:48] <shuduo> zyga: good to know. :)
[07:48] <zyga> or even disable the configure hook on classic, it's not useful anyway yet
[07:48] <zyga> shuduo: did you report this anywhere?
[07:49] <shuduo> zyga: not yet. if you want I am happy to do that.
[07:50] <zyga> shuduo: I think there is a report of this on debian
[07:50] <zyga> let me find it
[07:51] <zyga> shuduo: https://bugs.launchpad.net/snappy/+bug/1674193
[07:51] <mup> Bug #1674193: core snap's configuration hangs on debian <Snappy:New> <https://launchpad.net/bugs/1674193>
[07:51] <zyga> can you please add to this bug that it also happens on tumbleweed and leap 42.2
[07:51] <zyga> add snap --version to the bug report too
[07:51] <shuduo> zyga: okay
[09:33] <mup> PR snapd#3070 opened: overlord: maintain per-revision snapshots of snap configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3070>
[09:38] <mup> PR snapd#3061 closed: interfaces: rename thumbnailer to thumbnailer-service <Created by michihenning> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3061>
[09:43] <mup> PR snapd#3011 closed: tests: remove core_name variable <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3011>
[09:55] <davmor2> 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] <ogra_> davmor2, you mean the build-packages option in snapcraft.yaml ?
[10:05] <davmor2> ogra_: could be I was just asking if there was one
[10:05] <ogra_> indeed there is :)
[10:06] <davmor2> ogra_: awesome I might try a edge build of pronterface and slic3r
[10:10] <morphis_> zyga_: so build on fedora is running, as you said, pretty easy to get that up and running :-)
[10:11] <mup> PR snapd#2987 closed: store: download from authenticated URL if there is a device session set <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2987>
[10:12] <Son_Goku> morphis_ , zyga_
[10:17] <morphis_> Son_Goku: you have two different nicks? :-)
[10:17] <Son_Goku> I have three, actually
[10:17] <Son_Goku> King_InuYasha is the third
[10:17] <morphis_> ah :-)
[10:17] <morphis_> good to know, each for a differnt machine?
[10:17] <Son_Goku> yep
[10:17] <morphis_> so fedpkg is actually quite nice
[10:18] <Son_Goku> yes, it's full of win
[10:18] <morphis_> 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] <Son_Goku> where's this hangout thing so I can pop in
[10:18] <Son_Goku> yeah, I already started doing that... :/
[10:18] <morphis_> there isn't one right now
[10:18] <morphis_> Son_Goku: ah great, how far did you come?
[10:18] <Son_Goku> snap-confine stuff builds, but snapd doesn't :(
[10:19] <morphis_> Son_Goku: is that work available somewhere?
[10:19] <Son_Goku> yep
[10:19] <Son_Goku> one sec
[10:21] <zyga> Son_Goku: we finished as morphis_ didn't have his fedora account yet
[10:21] <morphis_> zyga: I do now
[10:29] <Son_Goku> morphis_: what's your FAS?
[10:29] <morphis_> Son_Goku: mrmorph
[10:38] <Son_Goku> [06:38:30 AM]  <Son_Goku>	.fasinfo mrmorph
[10:38] <Son_Goku> [06:38:31 AM]  <zodbot>	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] <Son_Goku> [06:38:34 AM]  <zodbot>	Son_Goku: Approved Groups: cla_done cla_fpca
[10:39] <Son_Goku> morphis_, so that's you, morphis_ ^
[10:39] <morphis_> Son_Goku: yes
[10:43] <Son_Goku> morphis_: so you now need to go through the first-time packager process
[10:43] <Son_Goku> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[10:44] <morphis_> yeah, already working through that
[10:44] <Son_Goku> and don't forget to also be in #fedora-devel IRC
[10:45] <Son_Goku> lots of people hang out there and when real-time communications are supposed to happen, people like poking there
[10:45] <morphis_> thanks for that pointer!
[10:45] <morphis_> aye
[10:45] <morphis_> good to know
[10:47] <lool> 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] <mup> Bug #1674505: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>
[10:50] <morphis> 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] <Son_Goku> yes
[10:52] <morphis> Son_Goku: is that work somewhere too?
[10:52] <Son_Goku> yes
[10:53] <Son_Goku> morphis: https://github.com/Conan-Kudo/snapd/commit/4c71ef5a9e6e89cf8aa2d31eef12be7e2e66d1bd
[10:53] <morphis> Son_Goku: ah nice!
[10:54] <morphis> Son_Goku: I guess there is a reason why you had to copy the systemd unit files, right?
[10:54] <Son_Goku> the original systemd units use /snap and /usr/lib/snapd
[10:55] <morphis> ah right
[10:55] <Son_Goku> Fedora uses the saner paths /var/lib/snapd/snap and /usr/libexec/snapd
[10:55] <morphis> Son_Goku: wondering if we can't change that via unit mixin's
[10:57] <morphis> Son_Goku: that way we could keep the original files and just change what we need to
[10:58] <Son_Goku> mixin's?
[10:58] <zyga> Son_Goku: we can use sed later
[10:58] <zyga> Son_Goku: or add this to packaging/fedora
[10:58] <zyga> Son_Goku: for sanity
[10:58] <morphis> /lib/systemd/systemd/snapd.service.d/fedora.conf
[10:58] <zyga> Son_Goku: then we can just maintain it in one spot
[10:58] <morphis> everything in fedora.conf gets applied to the original unit file
[10:59] <Son_Goku> morphis: ideally, the unit file would actually be a template and debubuntu and fedora packaging would convert them properly
[11:00] <morphis> possible
[11:00] <morphis> but using sed in the spec file would be another way
[11:00] <Son_Goku> yes, using sed would be required in this case, actually
[11:01] <morphis> Son_Goku: so what is left to do in that branch you shared above?
[11:01] <Son_Goku> as we'd most likely have service.in files with @libexecdir@ and @snapmountdir@ and those would be sedded in the spec
[11:01] <Son_Goku> morphis: not much actually, the problem is that build deps can't be satisfied
[11:01] <Son_Goku> and the vendorized build (for EPEL) doesn't work
[11:02] <Son_Goku> it fails on the link stage due to choking on hardening flags
[11:03] <Son_Goku> 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] <Son_Goku> that's "golang(github.com/ojii/gettext.go)" and "golang(gopkg.in/retry.v1)"
[11:04] <morphis> those do not exist in fedora at all in the moment?
[11:04] <Son_Goku> nope
[11:05] <morphis> ok
[11:05] <Son_Goku> packaging is mostly automated, through the gofed tool
[11:05] <Son_Goku> you should be able to generate packaging using it
[11:05] <morphis> yeah heard that, can't wait to see that in action :-)
[11:05] <Son_Goku> https://github.com/gofed/gofed
[11:05] <Son_Goku> on your Fedora system, do "sudo dnf install gofed*" to install all the gofed packages
[11:06] <Son_Goku> since they broke up the functionality into lots of subpackages :/
[11:07] <Son_Goku> gofed is quite powerful, as it is also capable of doing something close to API/ABI checking of golang things
[11:07] <morphis> Son_Goku: nice
[11:08] <morphis> Son_Goku: ok, on my list
[11:13] <Son_Goku> let me know when you've made the review requests
[11:14] <morphis> will do
[11:27] <mup> PR snapcraft#1207 opened: kernel plugin: stop duplicating initrd and image file, use symlinks f… <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1207>
[11:54] <mup> Bug #1674505 opened: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:New> <https://launchpad.net/bugs/1674505>
[11:57] <mup> PR snapcraft#1202 closed: python plugin: support pbr/setup.cfg projects <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1202>
[12:09] <mup> Bug #1674505 changed: Error checking context: 'can't stat '/home/user/docker-project' when runing docker build <Snappy:Invalid> <https://launchpad.net/bugs/1674505>
[12:14] <morphis> Son_Goku: to build the package from the packaging/ directory, I can't use fedpkg, right?
[12:14] <Son_Goku> no, you can't
[12:14] <Son_Goku> you need to set up the tree correctly for it
[12:14] <morphis> rpmbuild then?
[12:14] <Son_Goku> yes
[12:15] <Son_Goku> set the tree up correctly, then rpmbuild -bs <spec>
[12:15] <Son_Goku> then mock </path/to/package.src.rpm>
[12:15] <Son_Goku> that way you don't need all builddeps installed on your system
[12:16] <morphis> 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] <Son_Goku> well, since snapd-2.23.1 actually has all the things
[12:17] <Son_Goku> you can use spectool to download the sources :)
[12:17] <morphis> ah
[12:17] <Son_Goku> spectool -C ~/rpmbuild/SOURCES -g snapd.spec
[12:17] <morphis> that was the point I was missing
[12:18] <Son_Goku> you'll want to apply the patch adding fedora packaging stuff as a patch in the spec
[12:18] <Son_Goku> that way, things like the systemd unit are available in the right place
[12:18] <mup> PR snapcraft#1206 closed: Arm64 witness <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1206>
[12:52] <jdstrand> pedronis: hey, am I crazy or is there an auto-connect bug: http://paste.ubuntu.com/24228316/
[13:16] <pedronis> jdstrand: maybe
[13:18] <jdstrand> 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] <pedronis> jdstrand: that's not relevant if there is something in the plug
[13:19] <jdstrand> well, unless there is a bug of course
[13:19] <pedronis> plug should be the only interesting one
[13:19] <pedronis> well, that logic is quite clear cut
[13:19] <pedronis> there might be a bug
[13:19] <pedronis> but it might not be about assertions
[13:19] <pedronis> fwiw
[13:19] <jdstrand> but yes, on the nm plugs I did simple "allow-auto-connection: true" and that didn't work
[13:19] <jdstrand> pedronis: shall I file a bug then?
[13:20] <jdstrand> pedronis: I just wanted to ping you here to double check my expectation that the snap decl should allow it
[13:20] <jdstrand> s/just/mostly/
[13:21] <pedronis> 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] <pedronis> because we have exercized that for other things quite a bit
[13:21] <pedronis> and it's rather clear cut
[13:21] <jdstrand> I'll file a bug then
[13:23] <jdstrand> pedronis: thanks
[13:23] <lool> 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] <jdstrand> 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] <lool> jdstrand: awesome, that's exactly what I was looking for; do you know if tunctl implements the right ioctl dance?
[13:29] <jdstrand> lool: I'm not familiar with that tool. let me check
[13:29] <lool> Hmm I'm kind of suspicious that this is still relevant given it was in uml-utilities
[13:29] <lool> my god I'm old
[13:29] <lool> I suspect iproute can do it
[13:30] <lool> right, ip is the right tool, let's check if it does the ioctl
[13:30] <lool>         if (ioctl(fd, TUNSETIFF, ifr)) {
[13:30] <lool> it does!
[13:30] <jdstrand> lool: ethertap.c unconditionally does a mknod
[13:31] <jdstrand> ok, good, use that instead :)
[13:31] <roadmr> 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] <lool> jdstrand: I'm kind of ashamed of mentioning user-mode linux on a public channel in 2017
[13:32] <jdstrand> 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] <jdstrand> roadmr: I saw! I've taken advantage of both already. thanks!! :)
[13:32] <lool> ah
[13:32] <jdstrand> lool: hehe
[13:32] <roadmr> whee :) glad to hear jdstrand.
[13:34] <jdstrand> 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] <lool> 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] <jdstrand> olive: I was on holiday last week. did someone else answer your question? if not, I'm here now
[13:50] <olive> jdstrand: thank you, stgraber answered me at #lxcontainers ;)
[13:50] <jdstrand> olive: great :)
[13:54] <pedronis> jdstrand: reading your bug, remember auto-connection works only if there is only one possibility, not sure it's relevant
[13:55] <pedronis> 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] <ogra_> 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] <pedronis> jdstrand: you need some rule that name needs to be same
[13:59] <ogra_> i assume just copying the file into the dir wont be enough
[14:00] <mup> PR snapcraft#878 closed: Added a fix for cases where modpbrobe append options to the line, ie.… <Created by croepha> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/878>
[14:00] <mup> PR snapcraft#1208 opened: kernel plugin: fix modprobe output parsing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1208>
[14:02] <pedronis> 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] <jdstrand> pedronis: I did try to use constraint alternations for allow-auto-connection using plug-attributes: { name: ... }
[14:06] <pedronis> jdstrand: ?
[14:06] <pedronis> jdstrand: but the plug rule has nothing
[14:06] <pedronis> nor the interface
[14:07] <pedronis> it seems like we need a rule either in code or assertions that compare name?
[14:07] <jdstrand> pedronis: the plug side does have something. it specifies the interface, the name and the bus
[14:07] <pedronis> jdstrand: in the assertion?
[14:07] <pedronis> the code afaict doesn't do anything
[14:07] <pedronis> with name atm
[14:07] <jdstrand> pedronis: I'm saying I attempted an assertion that did that
[14:07] <pedronis> I mean dbus interface code
[14:08] <kyleN> 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] <mup> Bug #1674778: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:New> <https://launchpad.net/bugs/1674778>
[14:08] <pedronis> that's not what is in the bug though
[14:08] <jdstrand> pedronis: no it isn't. I did say towards the end that I tried other things
[14:08] <ogra_> kyleN, niemeyer wanted to look into that one he just said in our team meeting ;)
[14:08] <pedronis> anyway given there are two slots what is in the bug cannot work for sure  I think
[14:08] <jdstrand> pedronis: I can give the example that I tried
[14:09] <pedronis> the auto connect logic finds two cands and says nope
[14:09] <ogra_> kyleN, we were actively talking to renat yesterday night and asked him to file that bug
[14:09] <kyleN> ogra_, ok thanks. just wanted to be sure it was noted
[14:09] <ogra_> it surely is
[14:09] <jdstrand> ogra_: cause the person who wrote the interface didn't ask for it :)
[14:10] <jdstrand> pedronis: ok, let me try something else then
[14:10] <ogra_> 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] <pedronis> 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] <cachio> jdstrand, hey
[14:15] <cachio> jdstrand, I have build a dbus snap which is adding a dbus slot and plugs the same one
[14:15] <cachio> I am getting a apparmor DENIED when I try to run in strict mode
[14:15] <cachio> jdstrand, any idea?
[14:16] <jdstrand> cachio: is the interface connected?
[14:16] <jdstrand> cachio: snap interfaces
[14:16] <cachio> yes
[14:16] <cachio> jdstrand, I connected the slot and the interface manually
[14:17] <jdstrand> cachio: can you paste the output of 'snap interfaces'?
[14:18] <cachio> jdstrand, http://paste.ubuntu.com/24228789/
[14:19] <jdstrand> cachio: can you paste /snap/kpi-dbus-tests/current/meta/snap.yaml
[14:19] <cachio> jdstrand, that http://paste.ubuntu.com/24228795/
[14:20] <cachio> jdstrand, http://paste.ubuntu.com/24228800/
[14:20] <jdstrand> 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] <jdstrand> that is a libc thing
[14:20] <cachio> jdstrand, ah, ok
[14:21] <cachio> jdstrand, I'll try that
[14:27] <cachio> jdstrand, should I connect against mount-observe?
[14:27] <cachio> jdstrand, I am getting that denied
[14:28] <jdstrand> cachio: mount-observe needs a manual connection
[14:28] <cachio> jdstrand, which slot should I use?
[14:29] <jdstrand> cachio: you 'plugs: [ mount-observe ]'
[14:29] <cachio> yes
[14:29] <jdstrand> sudo snap connect kpi-dbus-tests:mount-observe
[14:29] <cachio> jdstrand, ok
[14:30] <jdstrand> (you can use that instead of 'sudo snap connect kpi-dbus-tests:mount-observe :mount-observe' since it is an implicit slot
[14:32] <cachio> jdstrand, I see that now [ 4068.867293] wcn36xx: ERROR hal_remove_bsskey response failed err=6
[14:32] <jdstrand> cachio: are there denials in the log?
[14:33] <cachio> jdstrand, yes, from dmesg
[14:33] <mup> PR snapcraft#1150 closed: kernel plugin: rework MAKEFLAGS from the environment <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1150>
[14:33] <jdstrand> can you paste the denials that happen after you connected the mount-observe interface?
[14:34] <cachio> jdstrand, I don't see any denial, just that error
[14:35] <cachio> jdstrand, is it related to the snap?
[14:38] <jdstrand> 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] <jdstrand> 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] <cachio> jdstrand, ok, I'll try that, tx
[14:44] <mup> PR core#29 opened: drop sync from hooks/configure, it isnt in the interface <Created by ogra1> <https://github.com/snapcore/core/pull/29>
[14:55] <mup> Bug #1675054 opened: "snap info" should provide detailed track/channel release information. <Snappy:New> <https://launchpad.net/bugs/1675054>
[14:57] <zyga> morphis: have a look at https://github.com/gofed/gofed/issues/131
[14:58] <zyga> Pharaoh_Atem: thanks for reporting that and wow, that's one quick fix :)
[14:58] <zyga> morphis: this should help you out a lot
[14:58] <zyga> morphis: you can use that technique to just quickly patch gofed locally and package the last bit
[15:05] <plars> 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] <plars> 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] <ogra_> err
[15:06] <plars> 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] <ogra_> ubuntu-core is long dead for images
[15:06] <plars> yeah I thought so
[15:06] <ogra_> so i wonder what gives it the idea there would be any ubuntu-core to upgrade from
[15:07] <plars> ogra_: that's not something that came from the model is it?
[15:07] <ogra_> no, iirc the model doesnt define core, only kernel and gadgetz
[15:07] <ogra_> do you actually see any ubuntu-core under /snap ??
[15:10] <mup> PR snapd#3025 closed: cmd/snap-update-ns: compute the actions required to transform mount environment <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3025>
[15:10] <morphis> zyga: yeah I saw some crashes too but got those two missing deps for snapd now building
[15:11] <morphis> 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] <morphis> but as long as it works and gives me something I can tune I am happy for now
[15:12] <plars> ogra_: yes
[15:12] <ogra_> plars, how did that get there ? :)
[15:12] <plars> ubuntu-core         16-2           1889
[15:12] <ogra_> plars, do you use an ancient ubuntu-image ?
[15:13] <plars> ubuntu-image     0.12+real1  37
[15:13] <ogra_> nothing should install ubuntu-core anymore ... sincwe 6 weeks or even longer
[15:13] <ogra_> thats pretty old
[15:13] <plars> oh, it looks like there's a newer version... I guess it didn't refresh because it's devmode
[15:13] <ogra_> yeah
[15:13] <plars> ah, ok
[15:14] <plars> 0.15+snap3 now
[15:14] <plars> let me try that, hopefully that's all it was :)
[15:14] <ogra_> right, try again weith that
[15:14] <zyga> morphis: what is the changelog you are getting?
[15:14] <plars> thanks!
[15:14] <ogra_> at least it should use core now and not try to upgrade ... no guarantees for anything else  :)
[15:14] <plars> heh, ok
[15:16] <om26er> Hi! Can I know which ppa generally contains snapd release candidate ? also, is there a "edge" aka daily ppa as well ?
[15:18] <ogra_> om26er, https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial
[15:18] <om26er> ogra_: is there one for RC ?
[15:19] <ogra_> 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] <om26er> hmm, so I guess -proposed is more reliable than a ppa for release candidates.
[15:23] <ogra_> yes
[15:23] <jibel> om26er, release candidates are in -proposed
[15:23] <jibel> om26er, /image is used before uploading to proposed
[15:23] <jibel> it's a bit an equivalent of a beta
[15:24] <om26er> jibel: so shall we track xenial-proposed and for dailies, the edge ppa ?
[15:24] <jibel> om26er, yes
[15:24] <morphis> zyga: %changelog* Wed Mar 22 2017 Simon Fels <morphis@gravedo.de> - 0-0.1.gitb6dae1d
[15:24] <morphis> so both things are in the same line which the tools don't like
[15:25] <morphis> but its just another bug in gofed
[15:29] <mup> PR core#29 closed: drop sync from hooks/configure <Created by ogra1> <Merged by niemeyer> <https://github.com/snapcore/core/pull/29>
[15:31] <om26er> 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] <om26er> 201703221024 aka YYYYMMDDHHMM ?
[15:31] <om26er> or if you could point me to the right person.
[15:32] <ogra_> om26er, i think thats correct ...
[15:32] <ogra_> the right person would be mvo, but he is off sick this week
[15:37] <Pharaoh_Atem> morphis: I dunno why it always generates bad changelog sections
[15:38] <Pharaoh_Atem> it's easy enough to fix thankfully :)
[15:50] <pedronis> jdstrand: I put a comment in the bug
[15:56] <plars> 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] <ogra_> cool
[15:57] <ogra_> i thought ubuntu-image does it ... but indeed, ubuntu-image only acts as frontend for "snap prepare-image"
[16:13] <zyga> morphis: weird, I never saw that
[16:25] <morphis> zyga: yeah
[16:27] <mup> PR snapcraft#1145 closed: tests: expect failures for the tests that can't be run in arm64 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1145>
[16:29] <sergiusens> ppisati: ^ because I added this https://github.com/snapcore/snapcraft/pull/1209/commits/e1e0dbb56564bdc532479e1a8066ca89e866ff05
[16:29] <mup> PR snapcraft#1209: kernel plugin: use default per arch targets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
[16:30] <mup> PR snapcraft#1149 closed: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1149>
[16:30] <mup> PR snapcraft#1209 opened: kernel plugin: use default per arch targets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
[16:38] <ppisati> sergiusens: is that good or bad? do i need to do anything?
[16:39]  * ppisati curls in a corner and cries
[16:40]  * ogra_ notes it is that time of day ... 
[16:40] <ogra_> ... and hands ppisati a beer
[17:02] <sergiusens> ppisati: fixed a typo in your dict and added tests
[17:05] <ppisati> sergiusens: k
[17:06] <sergiusens> ppisati: just wanted to know if you were ok with it
[17:10] <ppisati> sergiusens: +1
[17:13]  * zyga EODs
[17:13] <jdstrand> pedronis: thanks-- I'm going to try something else and report back
[17:24] <mup> PR snapcraft#1210 opened: Add platforms for the nightly tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1210>
[17:45] <jdstrand> pedronis: thanks for your help-- see https://bugs.launchpad.net/snapd/+bug/1675019/comments/5
[17:45] <mup> Bug #1675019: wpa-supplicant's dbus interfaces are not auto-connecting to network-manager snap <snapd:Invalid> <https://launchpad.net/bugs/1675019>
[17:46] <jdstrand> pedronis: snap decls can sure get tricky :)
[17:46] <pedronis> :)
[17:48] <Timmay> In latest Ubuntu-Core, how do I load kernel module at boot, seeing that most of the file system is read only? Assume it is in some "writable" folder?
[17:52] <zyga> jdstrand: FYI https://bugs.launchpad.net/snappy/+bug/1674193/comments/3
[17:52] <mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <openSUSE:New for morphis> <https://launchpad.net/bugs/1674193>
[17:52] <zyga> jdstrand: do we have any fixes in seccomp that may be causing this?
[17:52] <zyga> jdstrand: (please reply in the bug report)
[17:52] <zyga> jdstrand: I'm EOD, just wanted to put this on your radar
[18:21] <roger__> Hi! I've gotten stuck on 'Run configure hook of "core" snap if present', and the only hit I get when searching for it suggests talking to people on IRC about it.
[18:21] <roger__> (see https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02739.html)
[19:19] <mup> PR snapcraft#1211 opened: asset-tracking: add git source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1211>
[19:24] <roadmr> jdstrand: tools r850 now in production! enjoy!
[19:24] <jdstrand> roadmr: that was fast. thanks!
[19:24] <roadmr> only if you discount the fact that r849 languished there for days ;)
[19:25] <jdstrand> heh
[19:25] <jdstrand> no complaints here
[19:25] <roadmr> :D
[19:31] <coreycb> sergiusens, thanks for the fix. :)  seems to work fine although I'm running into a few more issues post-install.  i updated the bug if you could take a look when you get a chance.
[19:43] <mup> PR snapd#3043 closed: interfaces: use spec in the dbus backend <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3043>
[20:09] <mup> Bug #1650688 opened: timedatectl set-timezone fails on UC16 <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
[20:34] <mup> PR snapcraft#1212 opened: store: better retry strategy for GETs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1212>
[20:40] <mup> PR snapcraft#1208 closed: kernel plugin: fix modprobe output parsing <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1208>
[20:40] <mup> PR snapcraft#1209 closed: kernel plugin: use default per arch targets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1209>
[23:13] <mup> PR snapcraft#1185 closed: repo: add version support for build-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1185>
[23:46] <mup> PR snapcraft#1213 opened: asset-tracking: add bazaar source tracking <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1213>