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:08 |
---|---|---|
mup | PR snapcraft#1220 closed: Release changelog for 2.28 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1220> | 03:48 |
=== chihchun_afk is now known as chihchun | ||
=== morphis_ is now known as morphis | ||
zyga | good morning | 07:48 |
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> | 07:53 |
morphis | Son_Goku: I have the C part of snapd now building | 10:33 |
mup | PR snapd#3077 opened: interfaces: convert systemd backend to new APIs <Created by zyga> <https://github.com/snapcore/snapd/pull/3077> | 10:39 |
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:57 |
morphis | abeato: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz | 10:59 |
abeato | morphis, thanks, seems more modern than last time I took a lookf | 11:01 |
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:11 |
Son_Goku | unvendored? | 11:12 |
morphis | yes! | 11:12 |
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:13 |
Son_Goku | what changes did you need to make to snapd.spec? | 11:14 |
morphis | a few | 11:14 |
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:15 |
morphis | Son_Goku: btw. https://bugzilla.redhat.com/show_bug.cgi?id=1435572 | 11:16 |
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:17 |
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:18 |
morphis | or just keep one or two | 11:19 |
Son_Goku | I've already got modified packaging pulling in all the openSUSE patches | 11:19 |
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:20 |
Son_Goku | yes | 11:21 |
morphis | ok, I've switched from %gobuild to a simple go build for this | 11:21 |
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:22 |
morphis | Son_Goku: https://github.com/morphis/snapd/tree/f/fedora-packaging | 11:24 |
Son_Goku | errm | 11:25 |
Son_Goku | your systemd units don't work | 11:25 |
morphis | I know :-) | 11:25 |
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:26 |
morphis | sure, but that are the next steps | 11:27 |
morphis | Son_Goku: so in general, getting something in f25 is possible or only with an exception? | 11:28 |
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:29 |
Son_Goku | well | 11:30 |
Son_Goku | I could, because it's pending their inclusion | 11:30 |
morphis | ok | 11:30 |
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:32 |
morphis | sure, lets collect those bits and get them fixed | 11:33 |
morphis | Son_Goku: shared a doc with you | 11:35 |
morphis | Son_Goku: feel free to add things I am missing | 11:39 |
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:43 |
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:44 |
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:45 |
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:46 | |
zyga | not a great way to start spring | 11:47 |
Son_Goku | it's cold and rainy here, so spring already sucks | 11:47 |
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:48 |
mup | PR snapd#3078 opened: tests: remove stale apt proxy leftover from cloud-init <Created by zyga> <https://github.com/snapcore/snapd/pull/3078> | 11:53 |
morphis | Son_Goku: how much time do you have to work on those remaining things? | 12:08 |
=== hikiko is now known as hikiko|ln | ||
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:15 |
morphis | awesome! | 12:16 |
Son_Goku | limb will approve them later today, most likely | 12:16 |
morphis | limb? | 12:16 |
Son_Goku | Jon Ciesla | 12:17 |
Son_Goku | well, apparently it's Gwyn now | 12:19 |
Son_Goku | but his FAS account name is limb and Gwyn often shows up on IRC as limb, too | 12:20 |
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:21 |
mup | PR snapd#3079 opened: osutil: add GetBootID <Created by zyga> <https://github.com/snapcore/snapd/pull/3079> | 12:26 |
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:34 |
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:40 |
morphis | Son_Goku: maybe, need to talk with mvogt about that | 12:41 |
morphis | he currently generates the release tarballs by hand | 12:41 |
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:43 |
Son_Goku | things like spectool cannot process conditional sources | 12:44 |
morphis | I see, let me see if that is something we can do | 12:45 |
Son_Goku | Debian packaging should also be able to leverage such a configuration easily, too | 12:46 |
mup | PR snapd#3080 opened: interfaces: remove old API <Created by stolowski> <https://github.com/snapcore/snapd/pull/3080> | 12:51 |
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 | 12:58 |
=== hikiko|ln is now known as hikiko | ||
=== kgunn is now known as Guest24973 | ||
Son_Goku | morphis: and here's the "pristine" one: https://github.com/Conan-Kudo/snapd/commit/494f96fa458d6c71d07d2520555e5fabf61a8445 | 13:03 |
zyga | Son_Goku: wrt vendor tarball, yes, I'm sure | 13:04 |
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:05 |
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:07 |
Son_Goku | because right now, it's a pain to switch back and forth | 13:08 |
Son_Goku | especially when debugging golang issues | 13:08 |
=== chihchun is now known as chihchun_afk | ||
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:10 |
Son_Goku | well, I can build vendorized builds now in copr if I wanted to | 13:11 |
morphis | Son_Goku: lets put a vendorized build into copr now, then we have something people can play with if they want | 13:14 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
zyga | morphis: headless VMs? | 13:33 |
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:34 |
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:37 |
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:38 |
jdstrand | I'm going to poke at this and try to provide some extra info for triage | 13:39 |
* 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:40 |
jdstrand | morphis: yeah, let me poke at it for a bit | 13:41 |
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:44 |
morphis | zyga: +1 | 13:45 |
Son_Goku | zyga: ahh yep, I have some fixing to do | 13:47 |
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:48 |
zyga | fixing is a continouous thing ;) | 13:49 |
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:53 |
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:54 |
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:55 |
Son_Goku | zyga: removed ubuntu-core-launcher | 13:57 |
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 | 13:58 |
pshod | other than using node-snapper | 14:27 |
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:28 |
zyga | pshod: hey | 14:33 |
zyga | pshod: try snapcraft :-) | 14:33 |
zyga | pshod: snapcraft.io | 14:33 |
pshod | hey zyga :D | 14:35 |
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:36 |
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:37 |
ogra_ | people shlouldnt :P | 14:38 |
ogra_ | node-snapper was for 15.04 snaps | 14:38 |
ogra_ | before snapcraft existed at all | 14:38 |
ogra_ | with the creation of snapcraft node-snapper became obsolete ... so i stopped maintaining it | 14:39 |
pshod | ogra :D | 14:41 |
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:43 |
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:44 |
pshod | but the link doesnt actually have anything | 14:45 |
pshod | give me a min | 14:45 |
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:46 |
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:47 |
pshod | he has listed the snap in the node-packages | 14:49 |
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:50 |
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:52 |
pshod | node-packages: -hello-node-snap | 14:54 |
pshod | does this translate to npm install hello-node-snap | 14:54 |
pshod | ? | 14:54 |
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:07 |
morphis | jdstrand: what wonders me is that I saw the bind syscall in the seccomp policy for the configure hook, see comment #3 | 15:09 |
jdstrand | morphis: I can try a vanilla kernel too | 15:10 |
morphis | jdstrand: but do you saw bind in the policy for the configure hook too by default? | 15:11 |
jdstrand | morphis: no | 15:12 |
morphis | hm | 15:12 |
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:13 |
morphis | hm, checked on fedora with 2.23.1 and no bind there | 15:14 |
morphis | so looks like you're right | 15:14 |
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:19 |
morphis | jdstrand: hm, maybe that was what I was seeing yesterday | 15:20 |
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:34 |
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:47 |
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:51 |
morphis | Pharaoh_Atem: ah, thanks! | 15:52 |
Pharaoh_Atem | if you don't have it, do "dnf install 'compiler(go-compiler)'" | 15:52 |
morphis | Pharaoh_Atem: ok, looks like I've fixed the linker/relro issue | 15:58 |
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> | 15:59 |
morphis | Pharaoh_Atem: yeah I did | 16:00 |
Pharaoh_Atem | what was the fix? | 16:00 |
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:01 |
morphis | Pharaoh_Atem: switching the order of C and Go build in the spec file | 16:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
jdstrand | I would like to be a part of any PR that addresses this | 16:18 |
jdstrand | morphis: ^ | 16:18 |
morphis | jdstrand: +1 | 16:18 |
zyga | pshod: hey, did you check out snapcraft chat room on rocket chat? | 16:19 |
pshod | zyga: no | 16:27 |
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:28 |
Pharaoh_Atem | morphis: pushed revised specs to my git repos | 16:29 |
* zyga loves to see morphis and Pharaoh_Atem do everything he wanted to get done :) | 16:31 | |
* kyrofa too | 16:31 | |
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:33 |
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:34 |
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:39 |
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:40 |
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! | 16:41 |
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:14 |
mup | PR snapd#3084 opened: packaging: use templates for relevant systemd units <Created by morphis> <https://github.com/snapcore/snapd/pull/3084> | 17:15 |
kyrofa | jdstrand, is there an interface that will cover /dev/input/js0 ? | 17:38 |
ogra_ | kyrofa, most likely the joystick interface ;) | 17:39 |
ogra_ | (no, doesnt exist yet i think) | 17:39 |
kyrofa | ogra_, :P | 17:39 |
kyrofa | jdstrand, assuming it's not covered, think that'd be a pretty easy addition? | 17:40 |
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:01 |
morphis | Pharaoh_Atem: aye | 18:02 |
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:03 |
morphis | Pharaoh_Atem: ok, a problem seems to be still there: $ krita | 18:08 |
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:09 |
kyrofa | jdstrand, I assume /dev/input/js* would be safe, but /dev/input/event* sounds a little more general-purpose | 18:10 |
jdstrand | kyrofa: event* is where you can start doing nasty things | 18:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
jdstrand | jhodapp: great! | 18:17 |
kyrofa | Huh, very interesting! | 18:17 |
mup | PR snapd#3079 closed: osutil: add BootID <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3079> | 19:58 |
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:04 |
kyrofa | NicolinoCuralli, I'd refer you to ogra_, but I suspect he's off for the day | 21:06 |
NicolinoCuralli | kyrofa: is it better to ask on the mailinglist? | 21:07 |
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:08 |
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:20 |
kyrofa | It seems so. jdstrand can I get a review on a gadget snap? | 21:25 |
kyrofa | I can't even upload a gadget to beta or edge, it seems | 21:33 |
kyrofa | It's really hard to make/test a gadget snap! | 21:34 |
jdstrand | kyrofa: it was uploaded | 21:37 |
kyrofa | jdstrand, heh, release then | 21:38 |
kyrofa | Thanks jdstrand! | 21:39 |
jdstrand | kyrofa: approved. I'll let you review | 21:39 |
jdstrand | err | 21:39 |
jdstrand | release | 21:39 |
kyrofa | jdstrand, I'll probably need to iterate on this-- will I need a manual review each time? | 21:40 |
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:42 |
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:43 | |
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:44 |
jdstrand | kyrofa: I suggest raising with stakeholders :) | 21:45 |
* jdstrand knows this comes up from time to time. squeaky wheel... | 21:45 | |
kyrofa | Yeah, I was told to leave it alone and just write the series with a gadget snap | 21:46 |
jdstrand | roadmr: totally not urgent, but can you please pull r852 whenever is convenient? | 21:53 |
jdstrand | kyrofa: that is for you ^ | 21:53 |
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:54 |
pedronis | kyrofa: the model assertion take just a name, you can override it with a local snap using --extra-snaps | 21:57 |
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:58 |
jdstrand | roadmr: thanks :) | 21:59 |
kyrofa | Indeed | 21:59 |
pedronis | kyrofa: remember that local snaps will not refresh though , just like snap install .snap | 22:00 |
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:01 |
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:02 |
kyrofa | pedronis, agreed, thanks for the tip | 22:03 |
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:06 |
kyrofa | pedronis, which page? All I know about is the tutorial | 22:07 |
kyrofa | I mean on tutorials.ubuntu.com | 22:07 |
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:08 |
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:09 |
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:10 |
kyrofa | Although "as published on the store" begs the question "what if my snap isn't in the store" | 22:11 |
pedronis | well name of the snap, is the name of the snap, what you put snapcraft.yaml and goes into snap.yaml | 22:12 |
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:13 |
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:14 |
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:15 |
kyrofa | Hey jdstrand this serial port interface doesn't seem to be doing anything | 22:39 |
kyrofa | jdstrand, this specifically: https://github.com/kyrofa/pc-amd64-turtlebot-gadget/blob/master/snapcraft.yaml | 22:41 |
kyrofa | jdstrand, should the vendor and product actually be strings? | 22:42 |
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:49 |
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 | 22:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!