[03:08] Bug #1650091 changed: console-conf and getty hang if password is not set and press many enters [03:48] PR snapcraft#1220 closed: Release changelog for 2.28 === chihchun_afk is now known as chihchun === morphis_ is now known as morphis [07:48] good morning [07:53] PR snapd#3076 opened: cmd: disable the re-associate fix as requested by jdstrand [10:33] Son_Goku: I have the C part of snapd now building [10:39] PR snapd#3077 opened: interfaces: convert systemd backend to new APIs [10:57] 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] abeato: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz [11:01] morphis, thanks, seems more modern than last time I took a lookf [11:11] 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] unvendored? [11:12] yes! [11:13] so you mockchain'd a build and it worked? [11:13] I installed a few local packages into the mock env, but yeah [11:14] what changes did you need to make to snapd.spec? [11:14] a few [11:15] I also had to update the tomb package as it was quite outdated [11:15] I will push in a bit [11:15] things are still very rought [11:15] push to where? [11:15] github.com/morphis/snapd [11:16] Son_Goku: btw. https://bugzilla.redhat.com/show_bug.cgi?id=1435572 [11:17] Son_Goku: and zyga will be happy that we now see https://bugs.launchpad.net/snappy/+bug/1674193 on fedora too :-) [11:17] Bug #1674193: core snap's configuration hangs on debian|openSUSE [11:17] what I'm concerned about is that I currently need nine patches to make snapd build [11:18] 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] 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] or just keep one or two [11:19] I've already got modified packaging pulling in all the openSUSE patches [11:20] ah great [11:20] Son_Goku: so you have snapd building with the vendorized tree? [11:20] no [11:20] it fails to link vendorized [11:20] with a error that the linker doesn't know about relro? [11:21] yes [11:21] ok, I've switched from %gobuild to a simple go build for this [11:22] looks like LDFLAGS carrys something which the go linker doesn't like [11:22] yeah, we enforce hardening [11:22] yeah [11:24] Son_Goku: https://github.com/morphis/snapd/tree/f/fedora-packaging [11:25] errm [11:25] your systemd units don't work [11:25] I know :-) [11:26] I said its kind of rough [11:26] it also puts things into /snap .. [11:26] doesn't run any tests .. [11:26] well, I did have a working build, but it wasn't something worth releasing into Fedora [11:27] sure, but that are the next steps [11:28] Son_Goku: so in general, getting something in f25 is possible or only with an exception? [11:29] I *could* technically get something released now, with a whole lot of FIXMEs [11:29] even with my two packages not included? [11:29] well, no [11:29] not without those [11:30] well [11:30] I could, because it's pending their inclusion [11:30] ok [11:32] 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] no hardening flags is a problem, though [11:32] hardened builds should be working [11:32] and I'd be even more concerned with snapd than normal go packages [11:33] sure, lets collect those bits and get them fixed [11:35] Son_Goku: shared a doc with you [11:39] Son_Goku: feel free to add things I am missing [11:43] morphis: file a bug in rhbz to request an update for golang-github-go-tomb-tomb [11:43] Son_Goku: who has to do the update? we or the maintainer? [11:44] well, the maintainer usually [11:44] you should also request comaintainership: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-github-go-tomb-tomb/ [11:44] in fact, you should do that for all packages that are snapd deps [11:45] you and zyga might also want to join the golang sig [11:45] though apparently no page describing it exists :/ [11:46] anyway, jchaloup is the maintainer of the package, so you could also email him [11:46] Son_Goku: +1 good idea [11:46] * zyga looks outside at the soaking rain [11:47] not a great way to start spring [11:47] it's cold and rainy here, so spring already sucks [11:48] morphis: you really need to do your introduction in devel@ [11:48] Son_Goku: yeah, I have that prepared here [11:48] Son_Goku, zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1435616 [11:53] PR snapd#3078 opened: tests: remove stale apt proxy leftover from cloud-init [12:08] Son_Goku: how much time do you have to work on those remaining things? === hikiko is now known as hikiko|ln [12:15] 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] and I juggle a lot of other things too [12:15] Son_Goku: yeah, really appreciate this! [12:15] anyway, I approved your two golang package review requests [12:15] Son_Goku: so I can take us through all of these next week [12:15] and you're now sponsored into packagers group [12:16] awesome! [12:16] limb will approve them later today, most likely [12:16] limb? [12:17] Jon Ciesla [12:19] well, apparently it's Gwyn now [12:20] but his FAS account name is limb and Gwyn often shows up on IRC as limb, too [12:21] ah I see [12:21] oh boy, this is going to be rough :/ [12:21] remembering to use the right pronouns [12:26] PR snapd#3079 opened: osutil: add GetBootID [12:34] Son_Goku: so any particular item you want to work on or should I take them all for now? [12:34] you take them all for now [12:34] I'm about to push my pending changes to a git repo, one sec [12:40] morphis: would it be possible to release an "overlay tarball" that overlays the vendored stuff on top of the regular snappy sources? [12:41] Son_Goku: maybe, need to talk with mvogt about that [12:41] he currently generates the release tarballs by hand [12:43] if the "vendorizing" was a separate overlay tarball, that would make this easier for me [12:43] Son_Goku: which way? [12:43] because then I can upload both sources and only use the vendorized code for EL7 [12:43] and I don't have to condition which tarball to use [12:44] things like spectool cannot process conditional sources [12:45] I see, let me see if that is something we can do [12:46] Debian packaging should also be able to leverage such a configuration easily, too [12:51] PR snapd#3080 opened: interfaces: remove old API [12:58] morphis: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/commit/d2cd7591b6f362f4828ed7bbf29fb3cf335b541d [12:58] I exported fedora-dist-git and applied my in-progress packaging work there [12:58] Son_Goku: great === hikiko|ln is now known as hikiko === kgunn is now known as Guest24973 [13:03] morphis: and here's the "pristine" one: https://github.com/Conan-Kudo/snapd/commit/494f96fa458d6c71d07d2520555e5fabf61a8445 [13:04] Son_Goku: wrt vendor tarball, yes, I'm sure [13:05] Son_Goku: thanks, will integrate those bits [13:05] zyga: overlay tarballs would be much better for me, since I can just conditionally install the second set of sources [13:05] but I can always pull them both and upload them in tandem [13:07] Son_Goku: we could also split the upstream release to two tarballs, pristine snapd and pristine vendor tree [13:07] Son_Goku: it's just a directory after all [13:07] zyga: that's what I meant [13:07] the vendor tree would be an overlay tarball [13:07] Son_Goku: and then packaging for vendor/devendrized becomes easier [13:07] yes, definitely, when michael is back (he's off resting today) we should propose that [13:08] because right now, it's a pain to switch back and forth [13:08] especially when debugging golang issues === chihchun is now known as chihchun_afk [13:10] zyga: but I have "building" sources now: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec [13:10] but only when building in vendorized mode [13:10] Son_Goku: that's great, I would like to see a vendorized build in CORP [13:10] COPR [13:10] Son_Goku: in parallel with the devendorized build in the repository [13:11] well, I can build vendorized builds now in copr if I wanted to [13:14] Son_Goku: lets put a vendorized build into copr now, then we have something people can play with if they want [13:20] morphis, maybe later today [13:20] as it is, I haven't even attempted to use the packages yet :/ [13:20] morphis: does the package you have built work? [13:21] morphis: did you try it with some snaps? [13:21] zyga: yes, it works fully [13:21] nextcloud etc. comes up without problems [13:21] zyga: however its a bit rough, need to fix the systemd packages etc. [13:21] Son_Goku, zyga: but we could atleast push these things to https://copr.fedorainfracloud.org/coprs/zyga/snapcore/ [13:22] 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] my version should also be using /var/lib/snapd/snap correctly, among other things [13:22] right [13:23] that is why I need to merge :-) [13:23] morphis: rought in which way? [13:23] jdstrand, could you approve this package? https://myapps.developer.ubuntu.com/dev/click-apps/6453/rev/8/ [13:23] morphis: we have the presets now so snapd.socket should start ok [13:23] morphis: yes, I think we should push something to COPR [13:23] renatu: I literally just did :) [13:23] jdstrand, thanks :D [13:23] zyga: yes but the other jobs need patching which Son_Goku did [13:23] morphis, Son_Goku: if you guys have a package (vendorized, using /var/lib/snapd/snap) I would like to upload it there [13:23] jdstrand, can we white list it ? [13:24] renatu: I already did [13:24] aha, sounds good [13:24] zyga: lets target that for monday [13:24] jdstrand, thanks again :D [13:24] very good idea [13:24] renatu: check your email :) [13:24] np [13:24] releases on Friday bring back luck [13:24] yeah [13:24] read-only friday! [13:24] :-D [13:25] anyway, that also gives us the weekend to get snappy deps updated in Fedora [13:25] which allows us to no longer vendorize [13:25] +1 [13:25] Son_Goku: but we wont get those into f25, right? [13:25] why wouldn't we? [13:26] morphis: why not, this is not debian [13:26] hah! [13:26] we're not debian or ubuntu [13:26] we don't make life hard for people ;) [13:26] I am starting to like Fedora :-) [13:26] Fedora master race :) [13:26] new packages can enter all stable repos [13:26] :-) [13:26] let's try that hangout next week guys [13:26] once this is released we could plan some next steps (CI) [13:26] and just enabling unit tests [13:26] zyga: +1 [13:27] we really need to get this done asap [13:27] preferably before the F26 Alpha goes out [13:27] Son_Goku: is there a target date for the alpha? [13:27] I'm getting tired of the buildsystem bitching at me about snapd-glib [13:28] morphis: week after next Tuesday [13:28] Son_Goku: oh, yes [13:28] Son_Goku: btw, I wonder if that is integrated to gnome-software [13:28] right now, no [13:28] Son_Goku: once you have snapd installed [13:28] because gnome-software will FTBFS [13:28] aaaha [13:28] maybe there's a pkg-config test? [13:28] I think this was upstreamed some time ago [13:28] gnome software < 3.24 doesn't use snapd-glib, so it works [13:28] ok [13:28] well, litte by little :) [13:28] err, < 3.22 [13:29] so Fedora 25 won't get it [13:29] but we can get it for F26 [13:29] I just have to ask hughsie very nicely to turn it on once we update everything [13:29] Son_Goku: nice! [13:29] Son_Goku: I am fully on getting this done and having a target date is even better :-) [13:30] the GNOME 3.24 megaupdate has landed in Fedora 26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d1ab69a395 [13:30] well, will land [13:30] it's pending [13:30] it's already in Rawhide [13:31] Son_Goku: I'm actually curious, I will try F26, I wanted to see how the new gnome feels like [13:31] did you try it? [13:32] morphis: how do you feel working with all the distros? :) [13:32] zyga: I actually planned on updating my secondary machine to F26 today [13:32] zyga: I am using them all through ssh so I don't see much of the user interface, but yeah, interesting :-) [13:32] I always do it around alpha time [13:33] morphis: headless VMs? [13:34] zyga: not really headless yet but I ignore the vbox windows and have them minized all the time :-) [13:34] ssh + sshfs integrates much more into my workflo [13:37] 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] jdstrand: correct [13:37] ok, so that is consistent with all other evidence pointing to mainline [13:38] jdstrand: so your idea is that something in the kernel part is broken? [13:38] I don't have any ideas. that is a reflection of Zygmunt's idea [13:39] 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] 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] morphis: yeah, let me poke at it for a bit [13:44] morphis: we should have a simple small smoke test [13:44] morphis: C program [13:44] morphis: using libseccomp [13:44] morphis: allowing bind [13:44] morphis: doing bind [13:45] zyga: +1 [13:47] zyga: ahh yep, I have some fixing to do [13:48] new snapd is still broken [13:48] the selinux policy needs to account for the new binaries [13:48] Son_Goku: ah, thank you for fixing that [13:48] I mean, I haven't done it yet... [13:49] fixing is a continouous thing ;) [13:53] zyga: https://github.com/snapcore/snapd/pull/3081 [13:53] PR snapd#3081: data/selinux: Add contexts for snapctl and ubuntu-core-launcher [13:54] PR snapd#3081 opened: data/selinux: Add contexts for snapctl and ubuntu-core-launcher [13:55] zyga, morphis: that should fix issues related to snapctl, since it will have the access rights to snapd [13:55] Son_Goku: commented [13:57] zyga: removed ubuntu-core-launcher [13:58] Son_Goku: great, I'll merge it when CI goes green (I cannot earlier) [13:58] anyway, now I really need to get to work [14:27] other than using node-snapper [14:28] can some1 tell me how do i make a snap application from a script written in node js [14:28] ? [14:28] URGENT! HELP! HELP! HELP! [14:33] pshod: hey [14:33] pshod: try snapcraft :-) [14:33] pshod: snapcraft.io [14:35] hey zyga :D [14:36] i really do not understand where my .js script goes with the nodejs plugin [14:36] so i switched to node-snapper [14:36] 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] but would still want to do without it [14:37] looked around a bit [14:37] pshod: otherwise perhaps ask in https://rocket.ubuntu.com/channel/snapcraft [14:37] people happily use the node-snapper instead [14:38] people shlouldnt :P [14:38] node-snapper was for 15.04 snaps [14:38] before snapcraft existed at all [14:39] with the creation of snapcraft node-snapper became obsolete ... so i stopped maintaining it [14:41] ogra :D [14:43] where do i put my .js script which should run on node [14:43] i can put the packages I need with node-packages tag [14:43] or do i need to write a package.json [14:43] ? [14:43] see snapcraft.io there should be examples [14:43] if i do [14:43] where do i put it [14:44] there are not [14:44] i havent packaged a node app since we have the new stuff [14:44] "new stuff" ? [14:44] pshod: quick google: http://blog.bhdouglass.com/nodejs/snap/2016/08/06/packaging-nodejs-projects-as-snaps.html [14:44] https://snapcraft.io/docs/reference/plugins/nodejs ... also has pointers to examples [14:44] zyga: saw this one [14:44] pshod: what's wrong with it? [14:44] it has [14:45] but the link doesnt actually have anything [14:45] give me a min [14:46] 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] no, but look at the first line of the script in the hello world example [14:47] https://github.com/bhdouglass/hello-node-snap/blob/master/bin/hello-node-snap#L1 [14:47] hey thanks [14:47] doing tat now [14:47] PR snapd#3081 closed: data/selinux: add context definition for snapctl [14:49] he has listed the snap in the node-packages [14:50] and exposes the app in the command [14:50] I have 2 .js scripts, one is 'required" in another for using api's [14:52] the .js file acting as an api provider requires other packages which i plan to put in the node-packages tag [14:52] sorry if all this sounds pretty noob [14:52] I AM :p [14:54] node-packages: -hello-node-snap [14:54] does this translate to npm install hello-node-snap [14:54] ? [15:07] morphis, zyga, mwhudson: fyi https://bugs.launchpad.net/snappy/+bug/1674193/comments/16 [15:07] Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel [15:09] jdstrand: what wonders me is that I saw the bind syscall in the seccomp policy for the configure hook, see comment #3 [15:10] morphis: I can try a vanilla kernel too [15:11] jdstrand: but do you saw bind in the policy for the configure hook too by default? [15:12] morphis: no [15:12] hm [15:13] only mbind [15:13] I saw this with 2.23.1 [15:13] this is 2.22.6 [15:13] maybe my fgrep was misleading, let me check [15:14] hm, checked on fedora with 2.23.1 and no bind there [15:14] so looks like you're right [15:19] morphis: there was a moment when the core snap plugged network-bind [15:19] but it was reverted [15:19] well, it isn't in r1441 anyway [15:19] idk why you saw it [15:20] jdstrand: hm, maybe that was what I was seeing yesterday [15:34] Pharaoh_Atem: can I somehow avoid that I need to do something like this: [15:34] [simon@localhost fedorapkgs-snapd]$ cp *.patch ~/rpmbuild/SOURCES/ [15:34] before I can run rpmbuild -bs snapd.spec? [15:47] morphis: yes, you can --define "_sourcedir " on the rpmbuild command line [15:47] ah great [15:47] Pharaoh_Atem: also where is this %gobuild macro defined? [15:51] it's defined in /usr/lib/rpm/macros.d/macros.golang-go-compiler [15:51] err /usr/lib/rpm/macros.d/macros.golang-compiler [15:51] PR snapd#3082 opened: many: break the /aliases mutation API with a clean 400 [15:52] Pharaoh_Atem: ah, thanks! [15:52] if you don't have it, do "dnf install 'compiler(go-compiler)'" [15:58] Pharaoh_Atem: ok, looks like I've fixed the linker/relro issue [15:59] PR snapd#3050 closed: interfaces/mount: compute mount changes required to transition mount profiles [16:00] Pharaoh_Atem: yeah I did [16:00] what was the fix? [16:01] PR snapd#3067 closed: tests: move docker test to new nightly suite [16:03] Pharaoh_Atem: switching the order of C and Go build in the spec file [16:04] 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] Pharaoh_Atem: https://paste.ubuntu.com/24241472/ [16:04] that's so retarded [16:05] :-) [16:05] Pharaoh_Atem: I will prepare templating for the systemd units then we don't have to carry copies of them [16:06] my suggestion, use @libexecdir@ and @snapmountdir@ in place of /usr/libexec and /var/lib/snapd/snap, respectively [16:06] yeah [16:06] Pharaoh_Atem: what do you mean with "Retire separate snap-confine package"? [16:07] snap-confine has been in Fedora since F23 [16:07] it's 1.0.43 I think [16:07] i am packaging a node js script into a snap app [16:08] some of the packages listed under the node-packages tag cannot be downloaded proly cos of company's proxy [16:08] morphis: once we have a new snapd ready, then snap-confine needs to be retired [16:08] Pharaoh_Atem: so the "Obsoletes:" in the spec file isn't enough? [16:08] so i first pull the part [16:08] Pharaoh_Atem: ah there is a separate step we need to do for that [16:08] morphis: well, it is for users, but we need to get rid of it in the SCM :) [16:08] Pharaoh_Atem: I see :-) [16:08] so that the build system stops building the old snap-confine package [16:08] then in /parts/part-name/install/lib/node-modules [16:09] i copy the packages i needed [16:09] Pharaoh_Atem: I've reinstalled my package and got https://paste.ubuntu.com/24241487/ during the install [16:09] looks like its trying to adjust the existing squashfs mounts [16:09] they also reflect in the prime folder [16:09] but are not being found by the binary inside prime [16:09] which is exposed as an app [16:11] pshod: really sounds like necessary env variables or so are not set up properly [16:11] ummm [16:11] in the binary [16:11]