=== chihchun_afk is now known as chihchun [05:44] Hello, I have a beaglebone black. I'm running a snappy image by ogra. I also have a wifi adapter (https://www.logicsupply.com/uwn100/) but I don't know how to install the drivers. I have a guess, but it requires writing to the device storage. However, it seems that snappy is unwritable by default. Is there any guidance on this issue? thanks === JanC_ is now known as JanC [06:58] good morning [06:58] what mechanism does snapcraft use by default to set the directories where a snap command searches for shared libs? All of a sudden, i have this problem where my command can't find libraries, but they exist in $SNAP/usr/lib. If I shell into the command (snap run --shell command), I can manually set the LD_LIBRARY_PATH to $SNAP/usr/bin and it works fine. I've tried adding an environment key to the snapcraft.yaml to set the LD_L [06:58] IBRARY_PATH, and while it does get set, for some reason it doesn't work unless I do it manually inside the shell [06:58] good morning [06:59] olympionex: good morning [07:00] olympionex: I believe snapcraft puts this in the generated command wrappers [07:00] olympionex: after building your snap please look at meta/snap.yaml [07:00] olympionex: you will see that the command: parts are re-written [07:00] olympionex: and you can look at what they contain for insight [07:01] thanks, i'll have a look. The command wrappers themselves seemed pretty empty, but now there are binaries in /snap/bin [07:01] olympionex: the inaries in /snap/bin are just symlinks to 'snap' [07:01] PR snapd#3319 opened: wrappers: don't convert between []byte and string needlessly [07:01] olympionex: those essentially do the same as "snap run $SNAP.$APP' [07:02] zyga: good morning! [07:02] * Chipaca off to get more coffee [07:02] * Chipaca on 0hs of sleep, because ¯\_(ツ)_/¯ [07:03] Chipaca: omg, really? [07:03] Chipaca: take some care :/ [07:03] yeah, gave up trying to sleep at 5am [07:03] Chipaca: I'll be working on the road today, going to some magnificent places :) [07:04] zyga: :-) nice! [07:04] working on the road many years ago was when i realised i was in the future :-) [07:05] something odd is going on with image building [07:05] anyway, got most of the services work mapped out in my head, just need to make it happen now [07:05] the i386 image has the new version [07:05] the amd64 image does not [07:05] hmm [07:08] zyga: hmm , ok -- I see. Yeah its just calling the wrapper, but my wrappers have nothing except 'exec "command" "$@"' I have an older working snap and those wrappers have the LD_LIBRARY paths set [07:09] olympionex: interesting, can you look at any environment section that may be there? perhaps snapscraft has changed how it conveys the environment variables to snapd [07:09] (I'm not a snapcraft developer) [07:11] zyga: yeah, it must have changed -- i'll have to either revert snapcraft or dig through and figure out what they changed [07:11] zyga: where are you driving to? [07:12] olympionex: to girona :) [07:12] olympionex: the whole city is full of flowers and flower scupltures and flower themes [07:13] olympionex: it's amazing (when I mean the wohle city I do mean the whole city) [07:13] Catalonia? [07:13] Chipaca: can you please have a look at https://github.com/snapcore/snapd/pull/3311 [07:13] PR snapd#3311: difs,interfaces/mount: add support for locking namespaces [07:13] olympionex: yes [07:13] zyga: do you live in Spain or somewhere else? [07:13] olympionex: most people here would say I live in Catalonia :) [07:13] haha [07:14] olympionex: just on the coast, very close to Girona [07:14] nice [07:14] it is evening here and i've only been to work [07:15] olympionex: https://www.youtube.com/embed/fAL90qLfGQA [07:15] olympionex: (ad for the event) [07:15] its also winter... [07:15] so all those things look nice =) [07:16] that looks very nice [07:17] I must say that ajuntament did a very good job :) [07:17] olympionex: yeah, summer is getting here in full force, the weekend was very hot [07:25] olympionex: from a quick look at snapcraft, it should still be adding LD_LIBRARY_PATH [07:25] olympionex: can you share your snapcraft.yaml? or is it secret :-) [07:25] i also am not a snapcraft developer, fwiw [07:27] zyga: sorry, had to tend to dinner for a second [07:28] olympionex: no worries :) [07:29] * zyga thinks it would be good to have a snapcraft developer in this timezone [07:30] zyga: hi, did you push writable-localtime to snapcore/snapd by mistake? [07:31] its proprietary, so i removed/changed some of the critical bits -- https://pastebin.com/41d79JT4 [07:31] pedronis: no, that was ogra [07:31] as i said, a very similar snap i compiled recently has the LD_LIBRARY_PATH in the wrappers [07:31] pedronis: I just pushed it there again to fix spread [07:31] but now i'm on 2.29 on this machine and it doesn't [07:32] checking on another machine with 2.27.1 [07:33] hmm, the 2.27.1 wrappers don't have any library paths either [07:35] Chipaca: if you have spare cycles we could also use a review on https://github.com/snapcore/snapd/pull/3271 [07:35] PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap [07:38] zyga: for https://github.com/snapcore/snapd/pull/3307 , you really want to have one environment: stanza per system definition in spread.yaml which repeatidly defines SNAPMOUNT/LIBEXECDIR? if we would do that for Ubuntu we would have that 31 times repeated [07:38] PR snapd#3307: tests: abstract common dirs which differ on distributions [07:38] ah sorry, 35 times [07:40] morphis: kind of yes, because that means I don't have to do it in task.yaml's [07:40] morphis: but that's just one vote, see what others say [07:40] morphis: ideally spred would have environment-script: section that lets us do this programmatically on 3 lines in one place [07:40] zyga: I am in for not doing it in task.yaml but we should repeat the same key/value pair more than a single time [07:40] zyga: right that is what I was proposing [07:41] zyga: lets keep it as is for now and I will look into adding an environment-script/environment-include part to spread [07:41] * zyga nods [07:41] morphis: I merged master into some of your branches [07:42] to fix conflicts and to re-start tests that were broken by new version string on the core snap [07:42] zyga: thanks [07:43] fgimenez: time to look into https://github.com/snapcore/snapd/pull/3307 and https://github.com/snapcore/snapd/pull/3308 today? [07:43] PR snapd#3307: tests: abstract common dirs which differ on distributions [07:43] PR snapd#3308: tests/lib: introduce pkgdb helper library [07:44] morphis: sure! :) will be on it in a bit [07:45] fgimenez: thanks! [07:49] * zyga goes for breakfast [07:49] zyga: since i'm building a classic mode snap, is snapcraft just expecting my to use ld.so.conf.d scripts maybe? Still not sure why this snap i built sometime in the past has the exports and works and when i build now it doesn't [07:50] olympionex: ah [07:50] olympionex: classic confinement snap? [07:50] yeah [07:50] olympionex: in that case there is no help, no love, no wrappers AFAIK [07:50] olympionex: how are you buidling your snap contents? [07:50] olympionex: is it using stage-packages? [07:51] olympionex: https://new.zygoon.pl/post/state-of-classic-confinement/ [07:51] olympionex: have a look at this please [07:51] its dumping a deb that I made [07:52] olympionex: that will not work correctly [07:52] olympionex: the blog has the details [07:52] hmm, ok [07:52] it must have changed at some point [07:52] i have the working .snap i made in the past with the wrappers [07:53] and its classic confinement [07:53] but i'll read and see whats different [07:56] zyga: “With those three assumptions you and the bag of predictable low-level libraries [...]” [07:57] Chipaca: ah s/you// [08:04] morphis: can you please have a look at https://github.com/snapcore/snapd/pull/3311/files -- it needs a 2nd +1 [08:04] PR snapd#3311: difs,interfaces/mount: add support for locking namespaces [08:04] * zyga really goes to eat something now [08:08] morphis: in snapd#3271, why are you droppping tests/regression/lp-1580018? [08:08] PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap [08:09] Chipaca: it is merged with the other test case I am modifying [08:09] Chipaca: check the environment: part [08:09] zyga: Thanks for the info. Looks like 2.26 was the last version that adds the LD_LIBRARY_PATH to classic snaps. I have to use classic (afaik) because i have a daemon whose source I don't control and it has to write a .pid file to /var/run/ueyed. Maybe there is a better way, but I haven't found it yet [08:10] morphis: yeah [08:10] olympionex: an interface :) [08:11] olympionex: do you have the source for the daemon? [08:13] zyga: no, its a library for a camera we use. I'm just snapping it to ease deployment. It seemingly has a parameter to specify the PID path, but it doesn't seem to like if I write it anywhere else - I think it might be a bug in the daemon. [08:13] olympionex: that will not be approved for a classic confinement snap [08:13] zygs: i'll look at interfaces again, I couldn't find great documentation last year, but it seems like there may be some new stuff [08:13] zyga: its not for the store [08:13] olympionex: well, I'm here if you need me ;) [08:13] zyga: i only sideload it on our systems [08:14] olympionex: but if you don't have the source it could be bad anyway, I'd suggest talking to your software vendor to help, it should be a simple fix for that pid parameter [08:14] zyga: yeah -- i notified them and haven't gotten a report back. I guess they don't expect people to do funny things with their software... [08:15] zyga: looking [08:15] zyga: they aren't in the FOSS spirit, their latest libraries use some kind of code protection deb I also have to install [08:16] olympionex: vote with your money and even more reason to confine it [08:16] morphis: thank you [08:16] zyga: commented [08:17] zyga: haha, well my company votes with its money, but unfortunately there aren't a lot of great industrial 3D cameras to choose from. This is just the driver for their camera [08:17] zyga: o [08:17] zyga: i'm off to dinner as well [08:17] zyga: hope i didn't interrupt your meal too much1 [08:18] morphis: replied [08:18] * zyga nods [08:18] olympionex: good luck then [08:28] morphis: done, LGTM with small suggestions about systemd-escape [08:30] fgimenez: how do you feel about the discussion I have with zyga on https://github.com/snapcore/snapd/pull/3308 ? [08:30] PR snapd#3308: tests/lib: introduce pkgdb helper library [08:34] morphis: i like more the centralized approach proposed in the PR, will drop a line [08:35] fgimenez: thanks [08:48] PR snapd#3311 closed: difs,interfaces/mount: add support for locking namespaces [08:51] PR snapd#3318 closed: overlord/snapstate: Enable() was ignoring the flags from the snap's state, resulting in losing "devmode" on disable/enable. This fixes that [08:56] Pharaoh_Atem: ping [09:01] pedronis: thanks! [09:02] Chipaca: np, I think zyga's remark about DeepEquals is right though if you want to change it in some follow up [09:03] ok [09:07] pedronis: what do you think about his suggestion on snapd#3292? [09:07] PR snapd#3292: wrappers: make StartSnapServices cleanup any services that were added if a later one fails [09:07] (if you looked at that at all) [09:12] Chipaca: I think serviceName in the rewritten code has the same problem as app [09:13] mmh, maybe not [09:14] hmm [09:14] we need a generic "run-from-core-or-from-distro re-exec helper" [09:15] pedronis: no, it's defined inside the loop [09:15] Chipaca: yea, sorry [09:15] i still prefer the one with a slice though [09:15] :-) [09:16] OTOH, I'll be moving some of these around [09:16] maybe I should do this after that [09:16] hrm [09:17] OT*O*OH I could make this work with helper funcs passing &err [09:17] which might make it better [09:17] that sounds obscure [09:18] yes [09:18] pedronis: zyga: I'm going to close #3292 [09:18] reshuffle add/start/stop/remove [09:18] (because they're wrong in subtle ways anyway, afaict) [09:18] and then redoing 3292 after fixing that should be cleaner [09:19] ok? [09:19] Chipaca: +1 [09:21] Chipaca: master should failed on tests/main/completation [09:21] https://travis-ci.org/snapcore/snapd/builds/232346364 [09:21] PR snapd#3292 closed: wrappers: make StartSnapServices cleanup any services that were added if a later one fails [09:22] pedronis: key gen [09:23] timeout in prepare [09:24] pedronis: what triggered this travis run? [09:25] Chipaca: my merge of your branch [09:25] :) [09:25] pedronis: the expect script sets a timeout of 60s for the key gen [09:25] and that timed out :-/ [09:26] well we need to do something about entropy like we do on debian [09:26] should I just re-run? [09:26] fgimenez should look into that I suppose [09:27] pedronis: yep, we can modify the images to include rng-tools and configure it to use /dev/urandom, for the time being we could do that on prepare-project too [09:28] pedronis: i'll prepare a branch [09:28] fgimenez: I think pollinate is part of the fix also, somewhere [09:28] not sure if the linode hosts are using pollinate [09:28] (I'm assuming the guests eat from the host's pool) [09:29] pedronis: objections to restarting that travis build? [09:30] pedronis: Chipaca ok i'll take a look, btw is it possible to snap download for an architecture different from the calling one? [09:30] not currently [09:30] or at least get the assembled .assert file [09:31] Chipaca: aha, ok thanks, i find myself doing nasty things with the files dropped in var/lib/snapd/seeed/assertions by snap prepare-image :) [09:32] morphis: hey, is cmd/cmd.go something that needs changes (for /snap vs /var/lib/snapd/snap) ? [09:32] morphis: look at oldCore vs newCore [09:33] PR snapd#3316 closed: make /etc/localtime writable in timezone_control [09:34] zyga: nothing which any test covered so far [09:35] * zyga shakes fist at openvswitch tests :/ [09:35] morphis: I think it's broken but we don't know because we re-exec where we use /snap anyway [09:36] * zyga -> small walk [09:36] fgimenez: Chipaca: yes [09:37] zyga: will have a look [09:38] fgimenez: set the envvar UBUNTU_STORE_ARCH [09:39] pedronis: great, thanks a lot! just for snap (ie global env), not snapd right? [09:39] oooh :-) [09:39] yes, this works only with snap download [10:05] Is there anyone have debug alsa in ubuntu core [10:06] The good codec device ported to ubuntu coer, but can't working normal === gbisson_ is now known as gbisson [10:25] PR snapd#3320 opened: tests: improve entropy also for ubuntu [10:26] pedronis: Chipaca snapd#3320 extends morphis' entropy solution to ubuntu classic systems, works fine on local executions [10:26] PR snapd#3320: tests: improve entropy also for ubuntu [10:27] fgimenez: nice! [10:30] Hello, is there any current issues with ports.ubuntu.com? I get the error message about it not being resolvable [10:30] cjwatson: moving a conversation from #snapcraft on rocket.ubuntu.com: popey_ thinks there might be something in the build.snapcraft.io system that is rewriting my URLs - I use jhbuild in my snap as a subprocess to handle the build of my part but it is failing only on build service because a url has lost a / from http:// [10:30] https://build.snapcraft.io/user/diddledan/corebird-snap/38228 [10:31] relevant log line: jhbuild list: failed to parse /bacfbbd4b618017965cf05163fa2626f-xenial/parts/corebird/jhbuild/usr/lib/python2.7/site-packages/modulesets/http:/ftp.gnome.org/pub/GNOME/teams/releng/3.25.1/gnome-apps-3.25.1.modules: [Errno 2] No such file or directory: [10:31] u'/bacfbbd4b618017965cf05163fa2626f-xenial/parts/corebird/jhbuild/usr/lib/python2.7/site-packages/modulesets/http:/ftp.gnome.org/pub/GNOME/teams/releng/3.25.1/gnome-apps-3.25.1.modules' [10:31] oops [10:31] that was supposed to be a link [10:32] my snap is at https://github.com/diddledan/corebird-snap === popey_ is now known as popey [10:38] That is rather deeply unlikely ... [10:38] strange then that it works on a snapcraft cleanbuild locally [10:39] Nothing in BSI or even in Launchpad really digs into the build at a low enough level that it could affect that kind of thing. [10:40] You sure it's not the three lines immediately above the one you quote? [10:40] id: ‘jhbuild’: no such user [10:40] python-gobject not found [10:40] dbus-python not found [10:40] no, they're normal [10:40] Could be just missing build-packages or something. [10:41] Or maybe jhbuild uses HTTP code that fails to deal with proxies correctly. [10:43] pedronis: https://travis-ci.org/snapcore/snapd/builds/232346364 [10:44] diddledan,popey: I'm pretty certain that the URL thing is a red herring. jhbuild builds a local cache for remote URLs it needs to fetch, so that'll just be where it decides to stash them. [10:45] ok, that makes sense. I guess it's failing to download then due to the proxy [10:45] It's just Python, so that is a *bit* surprising. [10:46] But I have no better guess at the moment. I have branches in flight to simplify the proxy setup from the client point of view. [10:47] You're welcome to file a bug against https://bugs.launchpad.net/launchpad-buildd if you want more detailed investigation [10:50] thanks, I'll try a few more things first I think [10:50] one thing I can immediately do, is replace the git checkout of jhbuild with a release tarball [10:50] it might be that they broke it upstream [10:54] zyga: /snap in cmd/cmd.go isn't yet a problem as we have reexec support explicitly disabled on fedora [10:54] diddledan: (It's also possible to set up launchpad-buildd locally, though still a non-trivial amount of work ...) [10:55] morphis: right, I agree [10:56] morphis: idea: snap tool update-ns [10:56] morphis: snap tool discard-ns [10:56] (tool would be a hidde command) [10:56] morphis: not sure this is necessary but I was thinking about it [10:56] why not `snap update-ns` ? [10:57] morphis: because there would be many of those and that would just clutter the top-level namespace [10:57] morphis: and you could have nice stuff on `snap tool` like --no-reexec or --reexec or others [10:57] morphis: useful for testing mainly [10:57] as long as they stay hidden, that shouldn't be a problem [10:57] morphis: it also has the `go tool` feeling which I like :) [10:58] :-) [10:58] PR snapd#3282 closed: hooks: default timeout [10:58] zyga: mvo suggested something similar for the `snap forced-managed` command but waiting for feedback from niemeyer on that [11:00] lol, cjwatson, was that a trigger? I see you've just this second released a new launchpad buildd :-p [11:01] morphis: aha [11:01] morphis: that might make sense (the debug command I presume) [11:01] yes [11:01] diddledan: Nah, I sent the ticket for that on Friday afternoon, just tidying up now :) [11:02] co inky dink (coincidence) [11:02] Any body else get the following when trying to install classic snap? Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/xenial/InRelease Could not resolve 'ports.ubuntu.com' [11:04] that sounds very snap specific, is it trying to do some apt get stuff behind the scenes? [11:05] It installs the snap and then start to see the errors the first time you use the snap sudo classic [11:06] ah, classic snap, not a classic snap [11:06] PR snapd#3319 closed: wrappers: don't convert between []byte and string needlessly [11:06] sounds a question for mvo [11:06] can someone do a (trivial) 2nd review on https://github.com/snapcore/snapd/pull/3315 please? [11:06] PR snapd#3315: spread.yaml: rename host's http proxy env vars [11:07] AdamH_: looks like a DNS issue (so far), can you ping ports.ubuntu.com? [11:08] zyga: Yes I can resolve and ping ports.ubuntu.com [11:08] PR snapd#3315 closed: spread.yaml: rename host's http proxy env vars [11:08] AdamH_: intersting, so it may be something deeper [11:09] zyga: Also works fine doing a sudo apt-get update once the snap has been setup, just fails on the initial setup for lsb-release [11:13] pstolowski: could you adjust the tests in snapd#3235 ? it seems very close [11:13] PR snapd#3235: overlord/hooks: make sure only one hook for given snap is executed at a time [11:20] zyga, pedronis, Chipaca, niemeyer: can you guys also have a look on https://github.com/snapcore/snapd/pull/3260 ? would like to get some eyes on the Go code before I spend to much time to getting the tests passing [11:20] PR snapd#3260: daemon: implement --user instance for snapd [11:22] morphis: looking now [11:23] pedronis, yes, will do [11:23] zyga: thanks [11:31] fgimenez, niemeyer: a review on https://github.com/snapcore/spread-images/pull/2 would be nice [11:31] PR spread-images#2: Add fedora-25-64 image [11:33] morphis: sure, i'll have a look [11:35] fgimenez: thanks [11:42] morphis: done [11:43] morphis: and done [11:45] PR snapd#3271 closed: cmd/snap-confine: use /etc/ssl from the core snap [11:45] is mvo around today? [11:47] so https://github.com/snapcore/snapd/pull/3225 is now under testing, I'd like to land it and iterate on more tests [11:47] PR snapd#3225: cmd/snap-update-ns: add actual implementation [11:48] zyga: didn't you want a review from jdstrand_ on https://github.com/snapcore/snapd/pull/3271 ? [11:48] PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap [11:48] morphis: yes but 1) it's the beginning of the cycle and 2) jdstrand said he is pretty busy on a new project now [11:48] morphis: and I want to see it fix suse :) [11:48] zyga: good [11:48] morphis: the conference is coming up, we should do a .1 just for suse [11:49] morphis: all those nice snaps should work :-) [11:49] zyga: sure, wanted to get that PR merged and will add that patch to the suse pkg soon [11:51] pedronis, i'm not sure what's wrong with #3235, seems like travis got confused, the tests are green but the status is not [11:51] pstolowski: yeah, this happens sometimes [11:51] indeed I saw this once in the past [11:51] pstolowski: no, I was referring to Gustavo's comment, to not change the common fake hook handler [11:52] pedronis, ah, sorry, my bad, I went to wrong PR [12:02] Chipaca: around? [12:02] PR snapd#3320 closed: tests: improve entropy also for ubuntu [12:02] Chipaca: completion failure https://travis-ci.org/snapcore/snapd/builds/232387046?utm_source=github_status&utm_medium=notification [12:02] zyga: around [12:03] zyga: in tests/main/completion, during prepare? [12:03] zyga: timeout creating a key [12:04] Chipaca: ah, so that will go away (hopefully) with the branch I just merged [12:04] thanks! [12:04] Chipaca: how are you feeling? you said you didn't sleep at all [12:05] zyga: i napped for about an hour, and have just finished lunch [12:05] Chipaca: feel like doing a review for https://github.com/snapcore/snapd/pull/3225 [12:05] PR snapd#3225: cmd/snap-update-ns: add actual implementation [12:05] feeling sleepy and weird but ok [12:05] Chipaca: I'd like to land it and give it some real-world testing on anything I can think of [12:05] zyga: that needs a review from gustavo :-) [12:06] a re-review, even [12:06] ah but he's not here [12:06] hrm [12:06] Chipaca: I addressed all of his feedback [12:07] Chipaca: I wanted to just get it in and iterate on anything we find [12:08] * zyga wishes it was less hot [12:08] it's 28C easily now [12:08] and only getting hotter [12:15] morphis: https://github.com/snapcore/snapd/pull/3225 has conflicts [12:15] PR snapd#3225: cmd/snap-update-ns: add actual implementation [12:15] morphis: shall I resolve them? [12:15] zyga: isn't that your PR? [12:15] no [12:15] oh [12:16] bad paste [12:16] https://github.com/snapcore/snapd/pull/3307 [12:16] PR snapd#3307: tests: abstract common dirs which differ on distributions [12:16] I meant this one [12:16]