[03:08] <mup> Bug #1650091 changed: console-conf and getty hang if password is not set and press many enters <Snappy:Fix Released> <https://launchpad.net/bugs/1650091>
[03:48] <mup> PR snapcraft#1220 closed: Release changelog for 2.28 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1220>
[07:48] <zyga> good morning
[07:53] <mup> PR snapd#3076 opened: cmd: disable the re-associate fix as requested by jdstrand <Created by zyga> <https://github.com/snapcore/snapd/pull/3076>
[10:33] <morphis> Son_Goku: I have the C part of snapd now building
[10:39] <mup> PR snapd#3077 opened: interfaces: convert systemd backend to new APIs <Created by zyga> <https://github.com/snapcore/snapd/pull/3077>
[10:57] <abeato> ogra_, where can I find the latest stable rpi3 image? I've flashed the daily one but not sure if it is working
[10:59] <morphis> abeato: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
[11:01] <abeato> morphis, thanks, seems more modern than last time I took a lookf
[11:11] <morphis> Son_Goku: and a few builds later: INFO: Done(/home/simon/rpmbuild/SRPMS/snapd-2.23.1-1.fc25.src.rpm) Config(default) 0 minutes 57 seconds
[11:12] <Son_Goku> unvendored?
[11:12] <morphis> yes!
[11:13] <Son_Goku> so you mockchain'd a build and it worked?
[11:13] <morphis> I installed a few local packages into the mock env, but yeah
[11:14] <Son_Goku> what changes did you need to make to snapd.spec?
[11:14] <morphis> a few
[11:15] <morphis> I also had to update the tomb package as it was quite outdated
[11:15] <morphis> I will push in a bit
[11:15] <morphis> things are still very rought
[11:15] <Son_Goku> push to where?
[11:15] <morphis> github.com/morphis/snapd
[11:16] <morphis> Son_Goku: btw. https://bugzilla.redhat.com/show_bug.cgi?id=1435572
[11:17] <morphis> Son_Goku: and zyga will be happy that we now see https://bugs.launchpad.net/snappy/+bug/1674193 on fedora too :-)
[11:17] <mup> Bug #1674193: core snap's configuration hangs on debian|openSUSE <Snappy:In Progress by morphis> <snapd (Debian):New> <openSUSE:Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[11:17] <Son_Goku> what I'm concerned about is that I currently need nine patches to make snapd build
[11:18] <Son_Goku> the rate of churn in snapd git makes it impossible to keep up with out of tree patches easily, unless they are very minor
[11:18] <morphis> Son_Goku: yes I agree, but we can do this for now and I will work with zyga to get us drop all these
[11:19] <morphis> or just keep one or two
[11:19] <Son_Goku> I've already got modified packaging pulling in all the openSUSE patches
[11:20] <morphis> ah great
[11:20] <morphis> Son_Goku: so you have snapd building with the vendorized tree?
[11:20] <Son_Goku> no
[11:20] <Son_Goku> it fails to link vendorized
[11:20] <morphis> with a error that the linker doesn't know about relro?
[11:21] <Son_Goku> yes
[11:21] <morphis> ok, I've switched from %gobuild to a simple go build for this
[11:22] <morphis> looks like LDFLAGS carrys something which the go linker doesn't like
[11:22] <Son_Goku> yeah, we enforce hardening
[11:22] <morphis> yeah
[11:24] <morphis> Son_Goku: https://github.com/morphis/snapd/tree/f/fedora-packaging
[11:25] <Son_Goku> errm
[11:25] <Son_Goku> your systemd units don't work
[11:25] <morphis> I know :-)
[11:26] <morphis> I said its kind of rough
[11:26] <morphis> it also puts things into /snap ..
[11:26] <morphis> doesn't run any tests ..
[11:26] <Son_Goku> well, I did have a working build, but it wasn't something worth releasing into Fedora
[11:27] <morphis> sure, but that are the next steps
[11:28] <morphis> Son_Goku: so in general, getting something in f25 is possible or only with an exception?
[11:29] <Son_Goku> I *could* technically get something released now, with a whole lot of FIXMEs
[11:29] <morphis> even with my two packages not included?
[11:29] <Son_Goku> well, no
[11:29] <Son_Goku> not without those
[11:30] <Son_Goku> well
[11:30] <Son_Goku> I could, because it's pending their inclusion
[11:30] <morphis> ok
[11:32] <morphis> Son_Goku: then lets do a plan of what next things we take to get those remaining bits fixed so we can submit with a clean and working package
[11:32] <Son_Goku> no hardening flags is a problem, though
[11:32] <Son_Goku> hardened builds should be working
[11:32] <Son_Goku> and I'd be even more concerned with snapd than normal go packages
[11:33] <morphis> sure, lets collect those bits and get them fixed
[11:35] <morphis> Son_Goku: shared a doc with you
[11:39] <morphis> Son_Goku: feel free to add things I am missing
[11:43] <Son_Goku> morphis: file a bug in rhbz to request an update for golang-github-go-tomb-tomb
[11:43] <morphis> Son_Goku: who has to do the update? we or the maintainer?
[11:44] <Son_Goku> well, the maintainer usually
[11:44] <Son_Goku> you should also request comaintainership: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-go-tomb-tomb/
[11:44] <Son_Goku> in fact, you should do that for all packages that are snapd deps
[11:45] <Son_Goku> you and zyga might also want to join the golang sig
[11:45] <Son_Goku> though apparently no page describing it exists :/
[11:46] <Son_Goku> anyway,  jchaloup is the maintainer of the package, so you could also email him
[11:46] <zyga> Son_Goku: +1 good idea
[11:46]  * zyga looks outside at the soaking rain 
[11:47] <zyga> not a great way to start spring
[11:47] <Son_Goku> it's cold and rainy here, so spring already sucks
[11:48] <Son_Goku> morphis: you really need to do your introduction in devel@
[11:48] <morphis> Son_Goku: yeah, I have that prepared here
[11:48] <morphis> Son_Goku, zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1435616
[11:53] <mup> PR snapd#3078 opened: tests: remove stale apt proxy leftover from cloud-init <Created by zyga> <https://github.com/snapcore/snapd/pull/3078>
[12:08] <morphis> Son_Goku: how much time do you have to work on those remaining things?
[12:15] <Son_Goku> morphis: I can try to make as much time as I can, but unlike you guys, I'm doing this in my spare time
[12:15] <Son_Goku> and I juggle a lot of other things too
[12:15] <morphis> Son_Goku: yeah, really appreciate this!
[12:15] <Son_Goku> anyway, I approved your two golang package review requests
[12:15] <morphis> Son_Goku: so I can take us through all of these next week
[12:15] <Son_Goku> and you're now sponsored into packagers group
[12:16] <morphis> awesome!
[12:16] <Son_Goku> limb will approve them later today, most likely
[12:16] <morphis> limb?
[12:17] <Son_Goku> Jon Ciesla
[12:19] <Son_Goku> well, apparently it's Gwyn now
[12:20] <Son_Goku> but his FAS account name is limb and Gwyn often shows up on IRC as limb, too
[12:21] <morphis> ah I see
[12:21] <Son_Goku> oh boy, this is going to be rough :/
[12:21] <Son_Goku> remembering to use the right pronouns
[12:26] <mup> PR snapd#3079 opened: osutil: add GetBootID <Created by zyga> <https://github.com/snapcore/snapd/pull/3079>
[12:34] <morphis> Son_Goku: so any particular item you want to work on or should I take them all for now?
[12:34] <Son_Goku> you take them all for now
[12:34] <Son_Goku> I'm about to push my pending changes to a git repo, one sec
[12:40] <Son_Goku> morphis: would it be possible to release an "overlay tarball" that overlays the vendored stuff on top of the regular snappy sources?
[12:41] <morphis> Son_Goku: maybe, need to talk with mvogt about that
[12:41] <morphis> he currently generates the release tarballs by hand
[12:43] <Son_Goku> if the "vendorizing" was a separate overlay tarball, that would make this easier for me
[12:43] <morphis> Son_Goku: which way?
[12:43] <Son_Goku> because then I can upload both sources and only use the vendorized code for EL7
[12:43] <Son_Goku> and I don't have to condition which tarball to use
[12:44] <Son_Goku> things like spectool cannot process conditional sources
[12:45] <morphis> I see, let me see if that is something we can do
[12:46] <Son_Goku> Debian packaging should also be able to leverage such a configuration easily, too
[12:51] <mup> PR snapd#3080 opened: interfaces: remove old API <Created by stolowski> <https://github.com/snapcore/snapd/pull/3080>
[12:58] <Son_Goku> morphis: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/commit/d2cd7591b6f362f4828ed7bbf29fb3cf335b541d
[12:58] <Son_Goku> I exported fedora-dist-git and applied my in-progress packaging work there
[12:58] <morphis> Son_Goku: great
[13:03] <Son_Goku> morphis: and here's the "pristine" one: https://github.com/Conan-Kudo/snapd/commit/494f96fa458d6c71d07d2520555e5fabf61a8445
[13:04] <zyga> Son_Goku: wrt vendor tarball, yes, I'm sure
[13:05] <morphis> Son_Goku: thanks, will integrate those bits
[13:05] <Son_Goku> zyga: overlay tarballs would be much better for me, since I can just conditionally install the second set of sources
[13:05] <Son_Goku> but I can always pull them both and upload them in tandem
[13:07] <zyga> Son_Goku: we could also split the upstream release to two tarballs, pristine snapd and pristine vendor tree
[13:07] <zyga> Son_Goku: it's just a directory after all
[13:07] <Son_Goku> zyga: that's what I meant
[13:07] <Son_Goku> the vendor tree would be an overlay tarball
[13:07] <zyga> Son_Goku: and then packaging for vendor/devendrized becomes easier
[13:07] <zyga> yes, definitely, when michael is back (he's off resting today) we should propose that
[13:08] <Son_Goku> because right now, it's a pain to switch back and forth
[13:08] <Son_Goku> especially when debugging golang issues
[13:10] <Son_Goku> zyga: but I have "building" sources now: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec
[13:10] <Son_Goku> but only when building in vendorized mode
[13:10] <zyga> Son_Goku: that's great, I would like to see a vendorized build in CORP
[13:10] <zyga> COPR
[13:10] <zyga> Son_Goku: in parallel with the devendorized build in the repository
[13:11] <Son_Goku> well, I can build vendorized builds now in copr if I wanted to
[13:14] <morphis> Son_Goku: lets put a vendorized build into copr now, then we have something people can play with if they want
[13:20] <Son_Goku> morphis, maybe later today
[13:20] <Son_Goku> as it is, I haven't even attempted to use the packages yet :/
[13:20] <zyga> morphis: does the package you have built work?
[13:21] <zyga> morphis: did you try it with some snaps?
[13:21] <morphis> zyga: yes, it works fully
[13:21] <morphis> nextcloud etc. comes up without problems
[13:21] <morphis> zyga: however its a bit rough, need to fix the systemd packages etc.
[13:21] <morphis> Son_Goku, zyga: but we could atleast push these things to https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
[13:22] <morphis> zyga: my plan is to merge with Son_Goku's changes next and then we can have something testable and do any further cleanup from there
[13:22] <Son_Goku> my version should also be using /var/lib/snapd/snap correctly, among other things
[13:22] <morphis> right
[13:23] <morphis> that is why I need to merge :-)
[13:23] <zyga> morphis: rought in which way?
[13:23] <renatu> jdstrand, could you approve this package? https://myapps.developer.ubuntu.com/dev/click-apps/6453/rev/8/
[13:23] <zyga> morphis: we have the presets now so snapd.socket should start ok
[13:23] <zyga> morphis: yes, I think we should push something to COPR
[13:23] <jdstrand> renatu: I literally just did :)
[13:23] <renatu> jdstrand, thanks :D
[13:23] <morphis> zyga: yes but the other jobs need patching which Son_Goku did
[13:23] <zyga> morphis, Son_Goku: if you guys have a package (vendorized, using /var/lib/snapd/snap) I would like to upload it there
[13:23] <renatu> jdstrand, can we white list it ?
[13:24] <jdstrand> renatu: I already did
[13:24] <zyga> aha, sounds good
[13:24] <morphis> zyga: lets target that for monday
[13:24] <renatu> jdstrand, thanks again :D
[13:24] <zyga> very good idea
[13:24] <jdstrand> renatu: check your email :)
[13:24] <jdstrand> np
[13:24] <zyga> releases on Friday bring back luck
[13:24] <morphis> yeah
[13:24] <Son_Goku> read-only friday!
[13:24] <morphis> :-D
[13:25] <Son_Goku> anyway, that also gives us the weekend to get snappy deps updated in Fedora
[13:25] <Son_Goku> which allows us to no longer vendorize
[13:25] <morphis> +1
[13:25] <morphis> Son_Goku: but we wont get those into f25, right?
[13:25] <Son_Goku> why wouldn't we?
[13:26] <zyga> morphis: why not, this is not debian
[13:26] <morphis> hah!
[13:26] <Son_Goku> we're not debian or ubuntu
[13:26] <Son_Goku> we don't make life hard for people ;)
[13:26] <morphis> I am starting to like Fedora :-)
[13:26] <Son_Goku> Fedora master race :)
[13:26] <Son_Goku> new packages can enter all stable repos
[13:26] <zyga> :-)
[13:26] <zyga> let's try that hangout next week guys
[13:26] <zyga> once this is released we could plan some next steps (CI)
[13:26] <zyga> and just enabling unit tests
[13:26] <morphis> zyga: +1
[13:27] <Son_Goku> we really need to get this done asap
[13:27] <Son_Goku> preferably before the F26 Alpha goes out
[13:27] <morphis> Son_Goku: is there a target date for the alpha?
[13:27] <Son_Goku> I'm getting tired of the buildsystem bitching at me about snapd-glib
[13:28] <Son_Goku> morphis: week after next Tuesday
[13:28] <zyga> Son_Goku: oh, yes
[13:28] <zyga> Son_Goku: btw, I wonder if that is integrated to gnome-software
[13:28] <Son_Goku> right now, no
[13:28] <zyga> Son_Goku: once you have snapd installed
[13:28] <Son_Goku> because gnome-software will FTBFS
[13:28] <zyga> aaaha
[13:28] <zyga> maybe there's a pkg-config test?
[13:28] <zyga> I think this was upstreamed some time ago
[13:28] <Son_Goku> gnome software < 3.24 doesn't use snapd-glib, so it works
[13:28] <zyga> ok
[13:28] <zyga> well, litte by little :)
[13:28] <Son_Goku> err, < 3.22
[13:29] <Son_Goku> so Fedora 25 won't get it
[13:29] <Son_Goku> but we can get it for F26
[13:29] <Son_Goku> I just have to ask hughsie very nicely to turn it on once we update everything
[13:29] <morphis> Son_Goku: nice!
[13:29] <morphis> Son_Goku: I am fully on getting this done and having a target date is even better :-)
[13:30] <Son_Goku> the GNOME 3.24 megaupdate has landed in Fedora 26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d1ab69a395
[13:30] <Son_Goku> well, will land
[13:30] <Son_Goku> it's pending
[13:30] <Son_Goku> it's already in Rawhide
[13:31] <zyga> Son_Goku: I'm actually curious, I will try F26, I wanted to see how the new gnome feels like
[13:31] <zyga> did you try it?
[13:32] <zyga> morphis: how do you feel working with all the distros? :)
[13:32] <Son_Goku> zyga: I actually planned on updating my secondary machine to F26 today
[13:32] <morphis> zyga: I am using them all through ssh so I don't see much of the user interface, but yeah, interesting :-)
[13:32] <Son_Goku> I always do it around alpha time
[13:33] <zyga> morphis: headless VMs?
[13:34] <morphis> zyga: not really headless yet but I ignore the vbox windows and have them minized all the time :-)
[13:34] <morphis> ssh + sshfs integrates much more into my workflo
[13:37] <jdstrand> morphis: hey, can you clarify this comment: "With snapd 2.23 now building on Fedora 25 I can reproduce the same problem without specifying --disable-seccomp for the snap-confine build." - you are saying that when seccomp is enabled on F25, you see the problem but when it isn't, you don't?
[13:37] <morphis> jdstrand: correct
[13:37] <jdstrand> ok, so that is consistent with all other evidence pointing to mainline
[13:38] <morphis> jdstrand: so your idea is that something in the kernel part is broken?
[13:38] <jdstrand> I don't have any ideas. that is a reflection of Zygmunt's idea
[13:39] <jdstrand> I'm going to poke at this and try to provide some extra info for triage
[13:40]  * jdstrand is only just now starting to look at it
[13:40] <morphis> jdstrand: ok, I wanted to look into this too but if you do than I can concentrate on getting the packaging stuff done
[13:41] <jdstrand> morphis: yeah, let me poke at it for a bit
[13:44] <zyga> morphis: we should have a simple small smoke test
[13:44] <zyga> morphis: C program
[13:44] <zyga> morphis: using libseccomp
[13:44] <zyga> morphis: allowing bind
[13:44] <zyga> morphis: doing bind
[13:45] <morphis> zyga: +1
[13:47] <Son_Goku> zyga: ahh yep, I have some fixing to do
[13:48] <Son_Goku> new snapd is still broken
[13:48] <Son_Goku> the selinux policy needs to account for the new binaries
[13:48] <zyga> Son_Goku: ah, thank you for fixing that
[13:48] <Son_Goku> I mean, I haven't done it yet...
[13:49] <zyga> fixing is a continouous thing ;)
[13:53] <Son_Goku> zyga: https://github.com/snapcore/snapd/pull/3081
[13:53] <mup> PR snapd#3081: data/selinux: Add contexts for snapctl and ubuntu-core-launcher <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3081>
[13:54] <mup> PR snapd#3081 opened: data/selinux: Add contexts for snapctl and ubuntu-core-launcher <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3081>
[13:55] <Son_Goku> zyga, morphis: that should fix issues related to snapctl, since it will have the access rights to snapd
[13:55] <zyga> Son_Goku: commented
[13:57] <Son_Goku> zyga: removed ubuntu-core-launcher
[13:58] <zyga> Son_Goku: great, I'll merge it when CI goes green (I cannot earlier)
[13:58] <Son_Goku> anyway, now I really need to get to work
[14:27] <pshod> other than using node-snapper
[14:28] <pshod> can some1 tell me how do i make a snap application from a script written in node js
[14:28] <pshod> ?
[14:28] <pshod> URGENT! HELP! HELP! HELP!
[14:33] <zyga> pshod: hey
[14:33] <zyga> pshod: try snapcraft :-)
[14:33] <zyga> pshod: snapcraft.io
[14:35] <pshod> hey zyga :D
[14:36] <pshod> i really do not understand where my .js script goes with the nodejs plugin
[14:36] <pshod> so i switched to node-snapper
[14:36] <zyga> pshod: I'm not a node developer but if you look at snapcraft you may find some examples of how to do stuff
[14:36] <pshod> but would still want to do without it
[14:37] <pshod> looked around a bit
[14:37] <zyga> pshod: otherwise perhaps ask in https://rocket.ubuntu.com/channel/snapcraft
[14:37] <pshod> people happily use the node-snapper instead
[14:38] <ogra_> people shlouldnt :P
[14:38] <ogra_> node-snapper was for 15.04 snaps
[14:38] <ogra_> before snapcraft existed at all
[14:39] <ogra_> with the creation of snapcraft node-snapper became obsolete ... so i stopped maintaining it
[14:41] <pshod> ogra :D
[14:43] <pshod> where do i put my .js script which should run on node
[14:43] <pshod> i can put the packages I need with node-packages tag
[14:43] <pshod> or do i need to write a package.json
[14:43] <pshod> ?
[14:43] <ogra_> see snapcraft.io there should be examples
[14:43] <pshod> if i do
[14:43] <pshod> where do i put it
[14:44] <pshod> there are not
[14:44] <ogra_> i havent packaged a node app since we have the new stuff
[14:44] <pshod> "new stuff" ?
[14:44] <zyga> pshod: quick google: http://blog.bhdouglass.com/nodejs/snap/2016/08/06/packaging-nodejs-projects-as-snaps.html
[14:44] <ogra_> https://snapcraft.io/docs/reference/plugins/nodejs ... also has pointers to examples
[14:44] <pshod> zyga: saw this one
[14:44] <zyga> pshod: what's wrong with it?
[14:44] <pshod> it has
[14:45] <pshod> but the link doesnt actually have anything
[14:45] <pshod> give me a min
[14:46] <pshod> zyga: so in the apps section, if i put my script path in the command tag, it will be automatically executed with node?
[14:46] <zyga> no, but look at the first line of the script in the hello world example
[14:47] <zyga> https://github.com/bhdouglass/hello-node-snap/blob/master/bin/hello-node-snap#L1
[14:47] <pshod> hey thanks
[14:47] <pshod> doing tat now
[14:47] <mup> PR snapd#3081 closed: data/selinux: add context definition for snapctl <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3081>
[14:49] <pshod> he has listed the snap in the node-packages
[14:50] <pshod> and exposes the app in the command
[14:50] <pshod> I have 2 .js scripts, one is 'required" in another for using api's
[14:52] <pshod> the .js file acting as an api provider requires other packages which i plan to put in the node-packages tag
[14:52] <pshod> sorry if all this sounds pretty noob
[14:52] <pshod> I AM :p
[14:54] <pshod> node-packages: -hello-node-snap
[14:54] <pshod> does this translate to npm install hello-node-snap
[14:54] <pshod> ?
[15:07] <jdstrand> morphis, zyga, mwhudson: fyi https://bugs.launchpad.net/snappy/+bug/1674193/comments/16
[15:07] <mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[15:09] <morphis> jdstrand: what wonders me is that I saw the bind syscall in the seccomp policy for the configure hook, see comment #3
[15:10] <jdstrand> morphis: I can try a vanilla kernel too
[15:11] <morphis> jdstrand: but do you saw bind in the policy for the configure hook too by default?
[15:12] <jdstrand> morphis: no
[15:12] <morphis> hm
[15:13] <jdstrand> only mbind
[15:13] <morphis> I saw this with 2.23.1
[15:13] <jdstrand> this is 2.22.6
[15:13] <morphis> maybe my fgrep was misleading, let me check
[15:14] <morphis> hm, checked on fedora with 2.23.1 and no bind there
[15:14] <morphis> so looks like you're right
[15:19] <jdstrand> morphis: there was a moment when the core snap plugged network-bind
[15:19] <jdstrand> but it was reverted
[15:19] <jdstrand> well, it isn't in r1441 anyway
[15:19] <jdstrand> idk why you saw it
[15:20] <morphis> jdstrand: hm, maybe that was what I was seeing yesterday
[15:34] <morphis> Pharaoh_Atem: can I somehow avoid that I need to do something like this:
[15:34] <morphis> [simon@localhost fedorapkgs-snapd]$ cp *.patch ~/rpmbuild/SOURCES/
[15:34] <morphis> before I can run rpmbuild -bs snapd.spec?
[15:47] <Pharaoh_Atem> morphis: yes, you can --define "_sourcedir </path/to/sources>" on the rpmbuild command line
[15:47] <morphis> ah great
[15:47] <morphis> Pharaoh_Atem: also where is this %gobuild macro defined?
[15:51] <Pharaoh_Atem> it's defined in /usr/lib/rpm/macros.d/macros.golang-go-compiler
[15:51] <Pharaoh_Atem> err  /usr/lib/rpm/macros.d/macros.golang-compiler
[15:51] <mup> PR snapd#3082 opened: many: break the /aliases mutation API with a clean 400 <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3082>
[15:52] <morphis> Pharaoh_Atem: ah, thanks!
[15:52] <Pharaoh_Atem> if you don't have it, do "dnf install 'compiler(go-compiler)'"
[15:58] <morphis> Pharaoh_Atem: ok, looks like I've fixed the linker/relro issue
[15:59] <mup> PR snapd#3050 closed: interfaces/mount: compute mount changes required to transition mount profiles <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3050>
[16:00] <morphis> Pharaoh_Atem: yeah I did
[16:00] <Pharaoh_Atem> what was the fix?
[16:01] <mup> PR snapd#3067 closed: tests: move docker test to new nightly suite <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3067>
[16:03] <morphis> Pharaoh_Atem: switching the order of C and Go build in the spec file
[16:04] <morphis> the C build of snap-confine somehow leaves LDFLAGS set which the go linker can't work with, if you build Go stuff first with %gobuild it isn't set and things build as they should
[16:04] <morphis> Pharaoh_Atem: https://paste.ubuntu.com/24241472/
[16:04] <Pharaoh_Atem> that's so retarded
[16:05] <morphis> :-)
[16:05] <morphis> Pharaoh_Atem: I will prepare templating for the systemd units then we don't have to carry copies of them
[16:06] <Pharaoh_Atem> my suggestion, use @libexecdir@ and @snapmountdir@ in place of /usr/libexec and /var/lib/snapd/snap, respectively
[16:06] <morphis> yeah
[16:06] <morphis> Pharaoh_Atem: what do you mean with "Retire separate snap-confine package"?
[16:07] <Pharaoh_Atem> snap-confine has been in Fedora since F23
[16:07] <Pharaoh_Atem> it's 1.0.43 I think
[16:07] <pshod> i am packaging a node js script into a snap app
[16:08] <pshod> some of the packages listed under the node-packages tag cannot be downloaded proly cos of company's proxy
[16:08] <Pharaoh_Atem> morphis: once we have a new snapd ready, then snap-confine needs to be retired
[16:08] <morphis> Pharaoh_Atem: so the "Obsoletes:" in the spec file isn't enough?
[16:08] <pshod> so i first pull the part
[16:08] <morphis> Pharaoh_Atem: ah there is a separate step we need to do for that
[16:08] <Pharaoh_Atem> morphis: well, it is for users, but we need to get rid of it in the SCM :)
[16:08] <morphis> Pharaoh_Atem: I see :-)
[16:08] <Pharaoh_Atem> so that the build system stops building the old snap-confine package
[16:08] <pshod> then in /parts/part-name/install/lib/node-modules
[16:09] <pshod> i copy the packages i needed
[16:09] <morphis> Pharaoh_Atem: I've reinstalled my package and got https://paste.ubuntu.com/24241487/ during the install
[16:09] <morphis> looks like its trying to adjust the existing squashfs mounts
[16:09] <pshod> they also reflect in the prime folder
[16:09] <pshod> but are not being found by the binary inside prime
[16:09] <pshod> which is exposed as an app
[16:11] <morphis> pshod: really sounds like necessary env variables or so are not set up properly
[16:11] <pshod> ummm
[16:11] <pshod> in the binary
[16:11] <pshod> which i have used as a .js script
[16:12] <pshod> i removed the extn of .js
[16:12] <Pharaoh_Atem> morphis: that's normal
[16:12] <pshod> instead added #!/usr/bin/env node
[16:12] <pshod> is that supposed to work?
[16:12] <morphis> Pharaoh_Atem: so no way to teach the macros to skip those mounts
[16:12] <Pharaoh_Atem> morphis: it's not the macros
[16:13] <Pharaoh_Atem> it's restorecon -Rv
[16:13] <morphis> pshod: sadly I am not an expert in nodejs things .. if you don't find anyone else here the best is to drop a mail to the snapcraft mailinglist
[16:14] <Pharaoh_Atem> morphis: ideally, it wouldn't matter as snapd would mount them all with that label
[16:14] <pshod> hey thank you!
[16:14] <Pharaoh_Atem> right now, it does not
[16:14] <pshod> moreover i think if i get the proxy issue resolved this thing also might work
[16:15] <pshod> its just too late here for me to call someone at IT to resolve the proxy thing
[16:15] <pshod> :(
[16:15] <pshod> fuck corporate proxy
[16:15] <morphis> Pharaoh_Atem: ok
[16:16] <jdstrand> morphis: fyi, https://bugs.launchpad.net/snappy/+bug/1674193/comments/18
[16:16] <mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[16:17] <morphis> jdstrand: ok, so things are clear and we need bind for every hook or the snapctl implementation fixed
[16:17] <jdstrand> morphis: yes
[16:18] <jdstrand> I would like to be a part of any PR that addresses this
[16:18] <jdstrand> morphis: ^
[16:18] <morphis> jdstrand: +1
[16:19] <zyga> pshod: hey, did you check out snapcraft chat room on rocket chat?
[16:27] <pshod> zyga: no
[16:28] <pshod> will do
[16:28] <pshod> thanks for the info
[16:28] <zyga> pshod: I think that will work better, there are losts of people making snaps there
[16:29] <Pharaoh_Atem> morphis: pushed revised specs to my git repos
[16:31]  * zyga loves to see morphis and Pharaoh_Atem do everything he wanted to get done :)
[16:31]  * kyrofa too
[16:33] <mup> PR snapd#3083 opened: tests: move unity test to nightly suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3083>
[16:33] <zyga> first fedora then the world ;D
[16:33] <zyga> I'd love to see snapd on osx and windows
[16:34] <zyga> I bought the original DOOM on GOG
[16:34] <zyga> I'll snap it this weekend
[16:34] <zyga> I wonder if GOG folks could offer snaps for linux
[16:34] <zyga> or even put them in the store somehow
[16:39] <morphis> zyga: :-D
[16:39] <morphis> Pharaoh_Atem: awesome!
[16:39] <morphis> one step closer to a release
[16:39] <morphis> Pharaoh_Atem: there will be one more patch for us to integrate to get the templating for the systemd units
[16:40] <zyga> morphis: we could actually release over weekend, people can check bodhi and try it and vote
[16:40] <zyga> it's not like it's going live in seconds
[16:40] <zyga> Pharaoh_Atem: what do you think?
[16:40] <zyga> morphis: if you think it is ready
[16:40] <zyga> (for wider testing)
[16:40] <morphis> zyga: https://docs.google.com/document/d/1l9xS8RqSSjASNEIcHAOanlURNrpmfodf4Fd79QXdLG4/edit
[16:40] <zyga> even if it ends with -2 in the end
[16:40] <zyga> morphis: can you share that to make it public
[16:41] <morphis> done
[16:41] <zyga> Pharaoh_Atem: packaging question, can we recommend/depend on snapd-xdg-open from snapd on a workstation variant but not on a server variant?
[16:41] <zyga> thanks!
[17:14] <morphis> Pharaoh_Atem: https://github.com/snapcore/snapd/pull/3084
[17:14] <mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
[17:15] <mup> PR snapd#3084 opened: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
[17:38] <kyrofa> jdstrand, is there an interface that will cover /dev/input/js0 ?
[17:39] <ogra_> kyrofa, most likely the joystick interface ;)
[17:39] <ogra_> (no, doesnt exist yet i think)
[17:39] <kyrofa> ogra_, :P
[17:40] <kyrofa> jdstrand, assuming it's not covered, think that'd be a pretty easy addition?
[18:01] <Pharaoh_Atem> morphis: see my comments https://github.com/snapcore/snapd/pull/3084#pullrequestreview-28972607
[18:01] <mup> PR snapd#3084: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084>
[18:02] <morphis> Pharaoh_Atem: aye
[18:03] <morphis> Pharaoh_Atem: I have those bits also included in the rpm packaging now
[18:03] <morphis> but will change to those suggested names
[18:08] <morphis> Pharaoh_Atem: ok, a problem seems to be still there: $ krita
[18:09] <morphis> dropping privs did not work: No such file or directory
[18:09] <morphis> but that is something for next week :-)
[18:09] <jdstrand> kyrofa: there isn't, no. I suspect that the interface would need more than just /dev/input/js* (eg, probably /dev/input/event*) and that is where things might get dicey, but, I'd be happy to review a PR
[18:10] <kyrofa> jdstrand, I assume /dev/input/js* would be safe, but /dev/input/event* sounds a little more general-purpose
[18:11] <jdstrand> kyrofa: event* is where you can start doing nasty things
[18:12] <jdstrand> kyrofa: I guess you are snapping something that needs it. did you add '/dev/input/js0 rw,' and did it resolve all your denials?
[18:12] <mup> PR snapcraft#1221 opened: state: factor state bits out of meta <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1221>
[18:12] <kyrofa> jdstrand, I haven't tried yet, still putting the snap together
[18:13] <kyrofa> jdstrand, but I'll try that. If that works, I assume that interface would be a slam dunk?
[18:13] <jdstrand> kyrofa: it would, yes
[18:13] <kyrofa> jdstrand, alright, I'll be in touch
[18:14] <jdstrand> kyrofa: if you are writing it, model it after framebuffer (as opposed to say, camera)
[18:14] <kyrofa> jdstrand, thanks for the hint! I'll make sure I touch bases before I write anything
[18:15] <jdstrand> kyrofa: and be aware of https://bugs.launchpad.net/snapd/+bug/1675738. I believe jhodapp's team will be fixing all the historical interfaces that aren't doing the right thing
[18:15] <mup> Bug #1675738: OpenGL interface should udev tag all /dev/* files <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1675738>
[18:15] <jdstrand> kyrofa: cool, np
[18:16] <jhodapp> jdstrand, yeah, we'll be doing a 2 pass approach to it...first is to do a quick fix so we can get the fix in in time for snapd 2.24
[18:16] <jhodapp> then we'll do the comprehensive fix
[18:17] <jdstrand> jhodapp: great!
[18:17] <kyrofa> Huh, very interesting!
[19:58] <mup> PR snapd#3079 closed: osutil: add BootID <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3079>
[21:04] <NicolinoCuralli> hi all just a doubt: it seem that a gadget can't be upgraded during the lifetime of a supported board? I don't find anything for making it in a transational manner: do I think wrong?
[21:06] <kyrofa> NicolinoCuralli, I'd refer you to ogra_, but I suspect he's off for the day
[21:07] <NicolinoCuralli> kyrofa: is it better to ask on the mailinglist?
[21:08] <kyrofa> NicolinoCuralli, yeah I suspect so
[21:08] <kyrofa> NicolinoCuralli, he's very responsive there
[21:08] <NicolinoCuralli> kyrofa : thanks a lot :D
[21:08] <kyrofa> Any time!
[21:20] <kyrofa> Hey niemeyer, can I not use a relative path for the gadget snap in a model assertion? Does it need to be in the store?
[21:25] <kyrofa> It seems so. jdstrand can I get a review on a gadget snap?
[21:33] <kyrofa> I can't even upload a gadget to beta or edge, it seems
[21:34] <kyrofa> It's really hard to make/test a gadget snap!
[21:37] <jdstrand> kyrofa: it was uploaded
[21:38] <kyrofa> jdstrand, heh, release then
[21:39] <kyrofa> Thanks jdstrand!
[21:39] <jdstrand> kyrofa: approved. I'll let you review
[21:39] <jdstrand> err
[21:39] <jdstrand> release
[21:40] <kyrofa> jdstrand, I'll probably need to iterate on this-- will I need a manual review each time?
[21:42] <jdstrand> kyrofa: since we don't have model assertions, I need to add something to the review tools to override this. I'm doing that now, but it won't be in production for a while. until then, yes
[21:42] <kyrofa> jdstrand, sounds good :)
[21:42] <kyrofa> This might just work!
[21:42] <jdstrand> kyrofa: in what capacity is this being supported?
[21:43] <jdstrand> kyrofa: you have -kyrofa in the name, so guessing this isn't Canonical supported?
[21:43] <kyrofa> jdstrand, nah, for a blog post series about the Turtlebot. I need the gadget due to bug #1645445
[21:43] <mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445>
[21:43]  * jdstrand nods
[21:44] <kyrofa> jdstrand, I'm a little sad no one will be able to follow it though. I was under the impression ubuntu-image would accept file paths
[21:44] <jdstrand> hotplugging will be nice
[21:44] <kyrofa> jdstrand, yes that would be better :)
[21:45] <jdstrand> kyrofa: I suggest raising with stakeholders :)
[21:45]  * jdstrand knows this comes up from time to time. squeaky wheel...
[21:46] <kyrofa> Yeah, I was told to leave it alone and just write the series with a gadget snap
[21:53] <jdstrand> roadmr: totally not urgent, but can you please pull r852 whenever is convenient?
[21:53] <jdstrand> kyrofa: that is for you ^
[21:54] <roadmr> jdstrand: sure thing
[21:54] <kyrofa> jdstrand, haha, quick work!
[21:54] <kyrofa> jdstrand, thank you :)
[21:54] <roadmr> jdstrand: I should have that deployed early next week, but I'm starting by committing the change
[21:57] <pedronis> kyrofa: the model assertion take just a name, you can override it with a local snap using --extra-snaps
[21:58] <kyrofa> pedronis, ah ha! I tried that, but I still used a path in the assertion
[21:58] <kyrofa> pedronis, let me give that a shot, thanks for jumping in
[21:58] <pedronis> (that option name is very confusing, adding extra-snap is actually the thing we wantt the least, and might remove, but overriding with locall will stay supported)
[21:59] <jdstrand> roadmr: thanks :)
[21:59] <kyrofa> Indeed
[22:00] <pedronis> kyrofa: remember that local snaps will not refresh though , just like snap install .snap
[22:01] <kyrofa> pedronis, indeed. Although I seem to remember that gadget snaps being refreshed isn't really a thing anyway?
[22:01] <pedronis> it gets refreshed
[22:01] <pedronis> we don't do much with the refreshed content though
[22:01] <pedronis> that's a bug, to fix
[22:01] <kyrofa> Ah, right
[22:02] <kyrofa> pedronis, there's a mailing list question for you to answer, then
[22:02] <kyrofa> Sent about an hour ago
[22:02] <pedronis> mostly that if it's a tutorial you might want to note on the side (I'm using a local snap because it's quick but for the full experience with refresh need a store one or something)
[22:03] <kyrofa> pedronis, agreed, thanks for the tip
[22:06] <kyrofa> pedronis, verified: leaving the assertion with just the name and using --extra-snaps works
[22:06] <pedronis> I wonder if our page about model assertion/ubuntu-image needs improvement, because I have been explaining this a couple of times
[22:06] <pedronis> I think
[22:07] <kyrofa> pedronis, which page? All I know about is the tutorial
[22:07] <kyrofa> I mean on tutorials.ubuntu.com
[22:08] <pedronis> yes, it says this:  gadget: name of the gadget snap as published on the store. Note that this snap can be a file on disk.
[22:08] <kyrofa> pedronis, yeah I read that as "this can be a file path on disk"
[22:08] <pedronis> yea, not super clear
[22:08] <pedronis> but it really means what it says literally
[22:09] <pedronis> here goes the name (in snap.yaml/store) sense of the snap and the snap can be  a file
[22:09] <pedronis> but then it doesn't says anywhere something about --extra-snaps
[22:10] <kyrofa> Yeah I would say "name of the gadget snap as published on the store. If you want to use a snap from your disk, you'll need to supply its path via --extra-snaps" or something similar
[22:11] <kyrofa> Although "as published on the store" begs the question "what if my snap isn't in the store"
[22:12] <pedronis> well name of the snap, is the name of the snap, what you put snapcraft.yaml and goes into snap.yaml
[22:13] <pedronis> but not sure how ingrained is that in general
[22:13] <kyrofa> pedronis, note that you can edit the snap name in the store though
[22:13] <kyrofa> pedronis, so there's a few levels of confusion that can happen there
[22:13] <pedronis> I don't remember that
[22:14] <pedronis> it can be renamed
[22:14] <kyrofa> pedronis, it doesn't rename it as far as snapd is concerned
[22:14] <pedronis> given that snap name need to be registered
[22:14] <kyrofa> pedronis, it's just a presentation layer thing
[22:14] <pedronis> might be a left over from clicks
[22:14] <pedronis> or something
[22:14] <kyrofa> But the option is "edit name"
[22:14] <pedronis> sounds strange for snaps
[22:14] <kyrofa> Yeah maybe
[22:15] <jrwren> Is there any docs on how snaps actually run. I see a snap which runs on xenial, but fails on trusty, but I thought this would be impossible given the ubuntu-core is the same. How does this actually work?
[22:39] <kyrofa> Hey jdstrand this serial port interface doesn't seem to be doing anything
[22:41] <kyrofa> jdstrand, this specifically: https://github.com/kyrofa/pc-amd64-turtlebot-gadget/blob/master/snapcraft.yaml
[22:42] <kyrofa> jdstrand, should the vendor and product actually be strings?
[22:49] <totallyhuman> hi
[22:49] <totallyhuman> i have searched around for this error
[22:49] <totallyhuman> and there are several bugs filed
[22:49] <totallyhuman> with no success
[22:50] <totallyhuman> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/find?q=e: dial unix /run/snapd-snap.socket: connect: no such file or directory