| === chihchun_afk is now known as chihchun | ||
| jobot | 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 | 05:44 |
|---|---|---|
| === JanC_ is now known as JanC | ||
| zyga | good morning | 06:58 |
| olympionex | 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 |
| olympionex | 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 |
| olympionex | good morning | 06:58 |
| zyga | olympionex: good morning | 06:59 |
| zyga | olympionex: I believe snapcraft puts this in the generated command wrappers | 07:00 |
| zyga | olympionex: after building your snap please look at meta/snap.yaml | 07:00 |
| zyga | olympionex: you will see that the command: parts are re-written | 07:00 |
| zyga | olympionex: and you can look at what they contain for insight | 07:00 |
| olympionex | thanks, i'll have a look. The command wrappers themselves seemed pretty empty, but now there are binaries in /snap/bin | 07:01 |
| zyga | olympionex: the inaries in /snap/bin are just symlinks to 'snap' | 07:01 |
| mup | PR snapd#3319 opened: wrappers: don't convert between []byte and string needlessly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3319> | 07:01 |
| zyga | olympionex: those essentially do the same as "snap run $SNAP.$APP' | 07:01 |
| Chipaca | zyga: good morning! | 07:02 |
| * Chipaca off to get more coffee | 07:02 | |
| * Chipaca on 0hs of sleep, because ¯\_(ツ)_/¯ | 07:02 | |
| zyga | Chipaca: omg, really? | 07:03 |
| zyga | Chipaca: take some care :/ | 07:03 |
| Chipaca | yeah, gave up trying to sleep at 5am | 07:03 |
| zyga | Chipaca: I'll be working on the road today, going to some magnificent places :) | 07:03 |
| Chipaca | zyga: :-) nice! | 07:04 |
| Chipaca | working on the road many years ago was when i realised i was in the future :-) | 07:04 |
| zyga | something odd is going on with image building | 07:05 |
| Chipaca | anyway, got most of the services work mapped out in my head, just need to make it happen now | 07:05 |
| zyga | the i386 image has the new version | 07:05 |
| zyga | the amd64 image does not | 07:05 |
| Chipaca | hmm | 07:05 |
| olympionex | 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:08 |
| zyga | 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 |
| zyga | (I'm not a snapcraft developer) | 07:09 |
| olympionex | zyga: yeah, it must have changed -- i'll have to either revert snapcraft or dig through and figure out what they changed | 07:11 |
| olympionex | zyga: where are you driving to? | 07:11 |
| zyga | olympionex: to girona :) | 07:12 |
| zyga | olympionex: the whole city is full of flowers and flower scupltures and flower themes | 07:12 |
| zyga | olympionex: it's amazing (when I mean the wohle city I do mean the whole city) | 07:13 |
| olympionex | Catalonia? | 07:13 |
| zyga | Chipaca: can you please have a look at https://github.com/snapcore/snapd/pull/3311 | 07:13 |
| mup | PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311> | 07:13 |
| zyga | olympionex: yes | 07:13 |
| olympionex | zyga: do you live in Spain or somewhere else? | 07:13 |
| zyga | olympionex: most people here would say I live in Catalonia :) | 07:13 |
| olympionex | haha | 07:13 |
| zyga | olympionex: just on the coast, very close to Girona | 07:14 |
| olympionex | nice | 07:14 |
| olympionex | it is evening here and i've only been to work | 07:14 |
| zyga | olympionex: https://www.youtube.com/embed/fAL90qLfGQA | 07:15 |
| zyga | olympionex: (ad for the event) | 07:15 |
| olympionex | its also winter... | 07:15 |
| olympionex | so all those things look nice =) | 07:15 |
| olympionex | that looks very nice | 07:16 |
| zyga | I must say that ajuntament did a very good job :) | 07:17 |
| zyga | olympionex: yeah, summer is getting here in full force, the weekend was very hot | 07:17 |
| Chipaca | olympionex: from a quick look at snapcraft, it should still be adding LD_LIBRARY_PATH | 07:25 |
| Chipaca | olympionex: can you share your snapcraft.yaml? or is it secret :-) | 07:25 |
| Chipaca | i also am not a snapcraft developer, fwiw | 07:25 |
| olympionex | zyga: sorry, had to tend to dinner for a second | 07:27 |
| zyga | olympionex: no worries :) | 07:28 |
| * zyga thinks it would be good to have a snapcraft developer in this timezone | 07:29 | |
| pedronis | zyga: hi, did you push writable-localtime to snapcore/snapd by mistake? | 07:30 |
| olympionex | its proprietary, so i removed/changed some of the critical bits -- https://pastebin.com/41d79JT4 | 07:31 |
| zyga | pedronis: no, that was ogra | 07:31 |
| olympionex | as i said, a very similar snap i compiled recently has the LD_LIBRARY_PATH in the wrappers | 07:31 |
| zyga | pedronis: I just pushed it there again to fix spread | 07:31 |
| olympionex | but now i'm on 2.29 on this machine and it doesn't | 07:31 |
| olympionex | checking on another machine with 2.27.1 | 07:32 |
| olympionex | hmm, the 2.27.1 wrappers don't have any library paths either | 07:33 |
| zyga | Chipaca: if you have spare cycles we could also use a review on https://github.com/snapcore/snapd/pull/3271 | 07:35 |
| mup | PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271> | 07:35 |
| morphis | 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 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 07:38 |
| morphis | ah sorry, 35 times | 07:38 |
| zyga | morphis: kind of yes, because that means I don't have to do it in task.yaml's | 07:40 |
| zyga | morphis: but that's just one vote, see what others say | 07:40 |
| zyga | morphis: ideally spred would have environment-script: section that lets us do this programmatically on 3 lines in one place | 07:40 |
| morphis | 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 |
| morphis | zyga: right that is what I was proposing | 07:40 |
| morphis | 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 | |
| zyga | morphis: I merged master into some of your branches | 07:41 |
| zyga | to fix conflicts and to re-start tests that were broken by new version string on the core snap | 07:42 |
| morphis | zyga: thanks | 07:42 |
| morphis | fgimenez: time to look into https://github.com/snapcore/snapd/pull/3307 and https://github.com/snapcore/snapd/pull/3308 today? | 07:43 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 07:43 |
| mup | PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308> | 07:43 |
| fgimenez | morphis: sure! :) will be on it in a bit | 07:44 |
| morphis | fgimenez: thanks! | 07:45 |
| * zyga goes for breakfast | 07:49 | |
| olympionex | 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:49 |
| zyga | olympionex: ah | 07:50 |
| zyga | olympionex: classic confinement snap? | 07:50 |
| olympionex | yeah | 07:50 |
| zyga | olympionex: in that case there is no help, no love, no wrappers AFAIK | 07:50 |
| zyga | olympionex: how are you buidling your snap contents? | 07:50 |
| zyga | olympionex: is it using stage-packages? | 07:50 |
| zyga | olympionex: https://new.zygoon.pl/post/state-of-classic-confinement/ | 07:51 |
| zyga | olympionex: have a look at this please | 07:51 |
| olympionex | its dumping a deb that I made | 07:51 |
| zyga | olympionex: that will not work correctly | 07:52 |
| zyga | olympionex: the blog has the details | 07:52 |
| olympionex | hmm, ok | 07:52 |
| olympionex | it must have changed at some point | 07:52 |
| olympionex | i have the working .snap i made in the past with the wrappers | 07:52 |
| olympionex | and its classic confinement | 07:53 |
| olympionex | but i'll read and see whats different | 07:53 |
| Chipaca | zyga: “With those three assumptions you and the bag of predictable low-level libraries [...]” | 07:56 |
| zyga | Chipaca: ah s/you// | 07:57 |
| zyga | morphis: can you please have a look at https://github.com/snapcore/snapd/pull/3311/files -- it needs a 2nd +1 | 08:04 |
| mup | PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311> | 08:04 |
| * zyga really goes to eat something now | 08:04 | |
| Chipaca | morphis: in snapd#3271, why are you droppping tests/regression/lp-1580018? | 08:08 |
| mup | PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271> | 08:08 |
| morphis | Chipaca: it is merged with the other test case I am modifying | 08:09 |
| morphis | Chipaca: check the environment: part | 08:09 |
| olympionex | 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:09 |
| Chipaca | morphis: yeah | 08:10 |
| zyga | olympionex: an interface :) | 08:10 |
| zyga | olympionex: do you have the source for the daemon? | 08:11 |
| olympionex | 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 |
| zyga | olympionex: that will not be approved for a classic confinement snap | 08:13 |
| olympionex | 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 |
| olympionex | zyga: its not for the store | 08:13 |
| zyga | olympionex: well, I'm here if you need me ;) | 08:13 |
| olympionex | zyga: i only sideload it on our systems | 08:13 |
| zyga | 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 |
| olympionex | 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:14 |
| morphis | zyga: looking | 08:15 |
| olympionex | zyga: they aren't in the FOSS spirit, their latest libraries use some kind of code protection deb I also have to install | 08:15 |
| zyga | olympionex: vote with your money and even more reason to confine it | 08:16 |
| zyga | morphis: thank you | 08:16 |
| morphis | zyga: commented | 08:16 |
| olympionex | 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 |
| olympionex | zyga: o | 08:17 |
| olympionex | zyga: i'm off to dinner as well | 08:17 |
| olympionex | zyga: hope i didn't interrupt your meal too much1 | 08:17 |
| zyga | morphis: replied | 08:18 |
| * zyga nods | 08:18 | |
| zyga | olympionex: good luck then | 08:18 |
| fgimenez | morphis: done, LGTM with small suggestions about systemd-escape | 08:28 |
| morphis | fgimenez: how do you feel about the discussion I have with zyga on https://github.com/snapcore/snapd/pull/3308 ? | 08:30 |
| mup | PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308> | 08:30 |
| fgimenez | morphis: i like more the centralized approach proposed in the PR, will drop a line | 08:34 |
| morphis | fgimenez: thanks | 08:35 |
| mup | PR snapd#3311 closed: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3311> | 08:48 |
| mup | 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 <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3318> | 08:51 |
| morphis | Pharaoh_Atem: ping | 08:56 |
| Chipaca | pedronis: thanks! | 09:01 |
| pedronis | Chipaca: np, I think zyga's remark about DeepEquals is right though if you want to change it in some follow up | 09:02 |
| Chipaca | ok | 09:03 |
| Chipaca | pedronis: what do you think about his suggestion on snapd#3292? | 09:07 |
| mup | PR snapd#3292: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292> | 09:07 |
| Chipaca | (if you looked at that at all) | 09:07 |
| pedronis | Chipaca: I think serviceName in the rewritten code has the same problem as app | 09:12 |
| pedronis | mmh, maybe not | 09:13 |
| zyga | hmm | 09:14 |
| zyga | we need a generic "run-from-core-or-from-distro re-exec helper" | 09:14 |
| Chipaca | pedronis: no, it's defined inside the loop | 09:15 |
| pedronis | Chipaca: yea, sorry | 09:15 |
| Chipaca | i still prefer the one with a slice though | 09:15 |
| Chipaca | :-) | 09:15 |
| Chipaca | OTOH, I'll be moving some of these around | 09:16 |
| Chipaca | maybe I should do this after that | 09:16 |
| Chipaca | hrm | 09:16 |
| Chipaca | OT*O*OH I could make this work with helper funcs passing &err | 09:17 |
| Chipaca | which might make it better | 09:17 |
| pedronis | that sounds obscure | 09:17 |
| Chipaca | yes | 09:18 |
| Chipaca | pedronis: zyga: I'm going to close #3292 | 09:18 |
| Chipaca | reshuffle add/start/stop/remove | 09:18 |
| Chipaca | (because they're wrong in subtle ways anyway, afaict) | 09:18 |
| Chipaca | and then redoing 3292 after fixing that should be cleaner | 09:18 |
| Chipaca | ok? | 09:19 |
| zyga | Chipaca: +1 | 09:19 |
| pedronis | Chipaca: master should failed on tests/main/completation | 09:21 |
| pedronis | https://travis-ci.org/snapcore/snapd/builds/232346364 | 09:21 |
| mup | PR snapd#3292 closed: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3292> | 09:21 |
| Chipaca | pedronis: key gen | 09:22 |
| Chipaca | timeout in prepare | 09:23 |
| Chipaca | pedronis: what triggered this travis run? | 09:24 |
| pedronis | Chipaca: my merge of your branch | 09:25 |
| pedronis | :) | 09:25 |
| Chipaca | pedronis: the expect script sets a timeout of 60s for the key gen | 09:25 |
| Chipaca | and that timed out :-/ | 09:25 |
| pedronis | well we need to do something about entropy like we do on debian | 09:26 |
| Chipaca | should I just re-run? | 09:26 |
| pedronis | fgimenez should look into that I suppose | 09:26 |
| fgimenez | 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:27 |
| fgimenez | pedronis: i'll prepare a branch | 09:28 |
| Chipaca | fgimenez: I think pollinate is part of the fix also, somewhere | 09:28 |
| Chipaca | not sure if the linode hosts are using pollinate | 09:28 |
| Chipaca | (I'm assuming the guests eat from the host's pool) | 09:28 |
| Chipaca | pedronis: objections to restarting that travis build? | 09:29 |
| fgimenez | 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 |
| Chipaca | not currently | 09:30 |
| fgimenez | or at least get the assembled .assert file | 09:30 |
| fgimenez | 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:31 |
| zyga | morphis: hey, is cmd/cmd.go something that needs changes (for /snap vs /var/lib/snapd/snap) ? | 09:32 |
| zyga | morphis: look at oldCore vs newCore | 09:32 |
| mup | PR snapd#3316 closed: make /etc/localtime writable in timezone_control <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3316> | 09:33 |
| morphis | zyga: nothing which any test covered so far | 09:34 |
| * zyga shakes fist at openvswitch tests :/ | 09:35 | |
| zyga | morphis: I think it's broken but we don't know because we re-exec where we use /snap anyway | 09:35 |
| * zyga -> small walk | 09:36 | |
| pedronis | fgimenez: Chipaca: yes | 09:36 |
| morphis | zyga: will have a look | 09:37 |
| pedronis | fgimenez: set the envvar UBUNTU_STORE_ARCH | 09:38 |
| fgimenez | pedronis: great, thanks a lot! just for snap (ie global env), not snapd right? | 09:39 |
| Chipaca | oooh :-) | 09:39 |
| pedronis | yes, this works only with snap download | 09:39 |
| leeboby | Is there anyone have debug alsa in ubuntu core | 10:05 |
| leeboby | The good codec device ported to ubuntu coer, but can't working normal | 10:06 |
| === gbisson_ is now known as gbisson | ||
| mup | PR snapd#3320 opened: tests: improve entropy also for ubuntu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3320> | 10:25 |
| fgimenez | pedronis: Chipaca snapd#3320 extends morphis' entropy solution to ubuntu classic systems, works fine on local executions | 10:26 |
| mup | PR snapd#3320: tests: improve entropy also for ubuntu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3320> | 10:26 |
| morphis | fgimenez: nice! | 10:27 |
| AdamH_ | Hello, is there any current issues with ports.ubuntu.com? I get the error message about it not being resolvable | 10:30 |
| diddledan | 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 |
| diddledan | https://build.snapcraft.io/user/diddledan/corebird-snap/38228 | 10:30 |
| diddledan | 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 |
| diddledan | 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 |
| diddledan | oops | 10:31 |
| diddledan | that was supposed to be a link | 10:31 |
| diddledan | my snap is at https://github.com/diddledan/corebird-snap | 10:32 |
| === popey_ is now known as popey | ||
| cjwatson | That is rather deeply unlikely ... | 10:38 |
| diddledan | strange then that it works on a snapcraft cleanbuild locally | 10:38 |
| cjwatson | 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:39 |
| cjwatson | You sure it's not the three lines immediately above the one you quote? | 10:40 |
| cjwatson | id: ‘jhbuild’: no such user | 10:40 |
| cjwatson | python-gobject not found | 10:40 |
| cjwatson | dbus-python not found | 10:40 |
| diddledan | no, they're normal | 10:40 |
| cjwatson | Could be just missing build-packages or something. | 10:40 |
| cjwatson | Or maybe jhbuild uses HTTP code that fails to deal with proxies correctly. | 10:41 |
| Chipaca | pedronis: https://travis-ci.org/snapcore/snapd/builds/232346364 | 10:43 |
| cjwatson | 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:44 |
| diddledan | ok, that makes sense. I guess it's failing to download then due to the proxy | 10:45 |
| cjwatson | It's just Python, so that is a *bit* surprising. | 10:45 |
| cjwatson | 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:46 |
| cjwatson | You're welcome to file a bug against https://bugs.launchpad.net/launchpad-buildd if you want more detailed investigation | 10:47 |
| diddledan | thanks, I'll try a few more things first I think | 10:50 |
| diddledan | one thing I can immediately do, is replace the git checkout of jhbuild with a release tarball | 10:50 |
| diddledan | it might be that they broke it upstream | 10:50 |
| morphis | zyga: /snap in cmd/cmd.go isn't yet a problem as we have reexec support explicitly disabled on fedora | 10:54 |
| cjwatson | diddledan: (It's also possible to set up launchpad-buildd locally, though still a non-trivial amount of work ...) | 10:54 |
| zyga | morphis: right, I agree | 10:55 |
| zyga | morphis: idea: snap tool update-ns | 10:56 |
| zyga | morphis: snap tool discard-ns | 10:56 |
| zyga | (tool would be a hidde command) | 10:56 |
| zyga | morphis: not sure this is necessary but I was thinking about it | 10:56 |
| morphis | why not `snap update-ns` ? | 10:56 |
| zyga | morphis: because there would be many of those and that would just clutter the top-level namespace | 10:57 |
| zyga | morphis: and you could have nice stuff on `snap tool` like --no-reexec or --reexec or others | 10:57 |
| zyga | morphis: useful for testing mainly | 10:57 |
| morphis | as long as they stay hidden, that shouldn't be a problem | 10:57 |
| zyga | morphis: it also has the `go tool` feeling which I like :) | 10:57 |
| morphis | :-) | 10:58 |
| mup | PR snapd#3282 closed: hooks: default timeout <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3282> | 10:58 |
| morphis | zyga: mvo suggested something similar for the `snap forced-managed` command but waiting for feedback from niemeyer on that | 10:58 |
| diddledan | lol, cjwatson, was that a trigger? I see you've just this second released a new launchpad buildd :-p | 11:00 |
| zyga | morphis: aha | 11:01 |
| zyga | morphis: that might make sense (the debug command I presume) | 11:01 |
| morphis | yes | 11:01 |
| cjwatson | diddledan: Nah, I sent the ticket for that on Friday afternoon, just tidying up now :) | 11:01 |
| diddledan | co inky dink (coincidence) | 11:02 |
| AdamH_ | 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:02 |
| pedronis | that sounds very snap specific, is it trying to do some apt get stuff behind the scenes? | 11:04 |
| AdamH_ | It installs the snap and then start to see the errors the first time you use the snap sudo classic | 11:05 |
| pedronis | ah, classic snap, not a classic snap | 11:06 |
| mup | PR snapd#3319 closed: wrappers: don't convert between []byte and string needlessly <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3319> | 11:06 |
| pedronis | sounds a question for mvo | 11:06 |
| zyga | can someone do a (trivial) 2nd review on https://github.com/snapcore/snapd/pull/3315 please? | 11:06 |
| mup | PR snapd#3315: spread.yaml: rename host's http proxy env vars <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3315> | 11:06 |
| zyga | AdamH_: looks like a DNS issue (so far), can you ping ports.ubuntu.com? | 11:07 |
| AdamH_ | zyga: Yes I can resolve and ping ports.ubuntu.com | 11:08 |
| mup | PR snapd#3315 closed: spread.yaml: rename host's http proxy env vars <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3315> | 11:08 |
| zyga | AdamH_: intersting, so it may be something deeper | 11:08 |
| AdamH_ | 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:09 |
| pedronis | pstolowski: could you adjust the tests in snapd#3235 ? it seems very close | 11:13 |
| mup | PR snapd#3235: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <https://github.com/snapcore/snapd/pull/3235> | 11:13 |
| morphis | 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 |
| mup | PR snapd#3260: daemon: implement --user instance for snapd <Created by morphis> <https://github.com/snapcore/snapd/pull/3260> | 11:20 |
| zyga | morphis: looking now | 11:22 |
| pstolowski | pedronis, yes, will do | 11:23 |
| morphis | zyga: thanks | 11:23 |
| morphis | fgimenez, niemeyer: a review on https://github.com/snapcore/spread-images/pull/2 would be nice | 11:31 |
| mup | PR spread-images#2: Add fedora-25-64 image <Created by morphis> <https://github.com/snapcore/spread-images/pull/2> | 11:31 |
| fgimenez | morphis: sure, i'll have a look | 11:33 |
| morphis | fgimenez: thanks | 11:35 |
| zyga | morphis: done | 11:42 |
| zyga | morphis: and done | 11:43 |
| mup | PR snapd#3271 closed: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3271> | 11:45 |
| zyga | is mvo around today? | 11:45 |
| zyga | 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 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 11:47 |
| morphis | zyga: didn't you want a review from jdstrand_ on https://github.com/snapcore/snapd/pull/3271 ? | 11:48 |
| mup | PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3271> | 11:48 |
| zyga | 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 |
| zyga | morphis: and I want to see it fix suse :) | 11:48 |
| morphis | zyga: good | 11:48 |
| zyga | morphis: the conference is coming up, we should do a .1 just for suse | 11:48 |
| zyga | morphis: all those nice snaps should work :-) | 11:49 |
| morphis | zyga: sure, wanted to get that PR merged and will add that patch to the suse pkg soon | 11:49 |
| pstolowski | 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 |
| zyga | pstolowski: yeah, this happens sometimes | 11:51 |
| pstolowski | indeed I saw this once in the past | 11:51 |
| pedronis | pstolowski: no, I was referring to Gustavo's comment, to not change the common fake hook handler | 11:51 |
| pstolowski | pedronis, ah, sorry, my bad, I went to wrong PR | 11:52 |
| zyga | Chipaca: around? | 12:02 |
| mup | PR snapd#3320 closed: tests: improve entropy also for ubuntu <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3320> | 12:02 |
| zyga | Chipaca: completion failure https://travis-ci.org/snapcore/snapd/builds/232387046?utm_source=github_status&utm_medium=notification | 12:02 |
| Chipaca | zyga: around | 12:02 |
| Chipaca | zyga: in tests/main/completion, during prepare? | 12:03 |
| Chipaca | zyga: timeout creating a key | 12:03 |
| zyga | Chipaca: ah, so that will go away (hopefully) with the branch I just merged | 12:04 |
| zyga | thanks! | 12:04 |
| zyga | Chipaca: how are you feeling? you said you didn't sleep at all | 12:04 |
| Chipaca | zyga: i napped for about an hour, and have just finished lunch | 12:05 |
| zyga | Chipaca: feel like doing a review for https://github.com/snapcore/snapd/pull/3225 | 12:05 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 12:05 |
| Chipaca | feeling sleepy and weird but ok | 12:05 |
| zyga | Chipaca: I'd like to land it and give it some real-world testing on anything I can think of | 12:05 |
| Chipaca | zyga: that needs a review from gustavo :-) | 12:05 |
| Chipaca | a re-review, even | 12:06 |
| Chipaca | ah but he's not here | 12:06 |
| Chipaca | hrm | 12:06 |
| zyga | Chipaca: I addressed all of his feedback | 12:06 |
| zyga | Chipaca: I wanted to just get it in and iterate on anything we find | 12:07 |
| * zyga wishes it was less hot | 12:08 | |
| zyga | it's 28C easily now | 12:08 |
| zyga | and only getting hotter | 12:08 |
| zyga | morphis: https://github.com/snapcore/snapd/pull/3225 has conflicts | 12:15 |
| mup | PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225> | 12:15 |
| zyga | morphis: shall I resolve them? | 12:15 |
| morphis | zyga: isn't that your PR? | 12:15 |
| zyga | no | 12:15 |
| zyga | oh | 12:15 |
| zyga | bad paste | 12:16 |
| zyga | https://github.com/snapcore/snapd/pull/3307 | 12:16 |
| mup | PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307> | 12:16 |
| zyga | I meant this one | 12:16 |
| morphis | no, I will do that | 12:16 |
| zyga | thanks! | 12:16 |
| zyga | I'll re-review it once it is green | 12:16 |
| zyga | pstolowski: hey, any updates on https://github.com/snapcore/snapd/pull/3120 ? | 12:20 |
| mup | PR snapd#3120: interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3120> | 12:20 |
| pstolowski | zyga, no, I didnt' have time to work on it yet; focusing on snapctl-outside-of-hooks branch still | 12:31 |
| zyga | pstolowski: OK | 12:32 |
| zyga | Chipaca: anything I can do to move the patch problem forward? | 12:32 |
| zyga | Chipaca: or to cheat and get the InstallPath into sideinfo? | 12:32 |
| zyga | Chipaca: (or similar that postpones the patch problem) | 12:32 |
| Chipaca | zyga: the patch problem? | 12:32 |
| zyga | Chipaca: AFAIK the patch system is currently unusable | 12:33 |
| zyga | Chipaca: because we have no unpatch that allows rollback | 12:33 |
| zyga | Chipaca: correct? | 12:33 |
| Chipaca | zyga: because having unpatch that allows rollback implies rewriting the past | 12:35 |
| pedronis | zyga: Chipaca: I'm getting run-checks --static errors/warning about spellings on master | 12:40 |
| pedronis | relared to cmd/* stuff | 12:40 |
| Chipaca | pedronis: where? | 12:40 |
| pedronis | stuff like: | 12:41 |
| pedronis | Checking spelling errors | 12:41 |
| pedronis | cmd/config.sub:118:2: "nto" is a misspelling of "not" | 12:41 |
| pedronis | ... | 12:41 |
| pedronis | cmd/configure:1195:55: "includ" is a misspelling of "include" | 12:41 |
| pedronis | Chipaca: just get master and run ./run-checks --static ? | 12:43 |
| Chipaca | pedronis: “( cd cmd && make distclean )” | 12:44 |
| Chipaca | :-) | 12:44 |
| mup | PR snapd#3321 opened: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321> | 12:44 |
| pedronis | Chipaca: thx, interestngly I had not Makefile | 12:49 |
| pedronis | s/not/no/ | 12:49 |
| Chipaca | heh | 12:49 |
| === chihchun is now known as chihchun_afk | ||
| cjwatson | popey: Did your home-assistant repository move somewhere else? I'd like a handy test case for https://github.com/canonical-ols/build.snapcraft.io/issues/497 | 13:02 |
| Chipaca | pedronis: standup | 13:02 |
| cjwatson | popey: though I guess I can use https://github.com/stuartlangridge/ColourPicker | 13:05 |
| diddledan | is build.snapcraft.io down? | 13:11 |
| cjwatson | diddledan: shouldn't be, though I just upgraded it. what's up? | 13:12 |
| diddledan | it's timing out | 13:12 |
| cjwatson | seems fine from here | 13:12 |
| diddledan | hmm | 13:12 |
| diddledan | let me try a different browser | 13:12 |
| diddledan | ok, seems that browser is b0rked - ms edge | 13:13 |
| cjwatson | has it worked with BSI before? | 13:13 |
| diddledan | yup, it was when I hit refresh that it didn't come back | 13:14 |
| cjwatson | diddledan: OK, can you please file an issue on https://github.com/canonical-ols/build.snapcraft.io with whatever details you have? | 13:15 |
| cjwatson | we should find out if that's consistent or what | 13:15 |
| diddledan | ok, it's back now. I have no idea what's happened there | 13:18 |
| diddledan | I've opened https://github.com/canonical-ols/build.snapcraft.io/issues/768 and noted that it seemingly works again now | 13:22 |
| sborovkov | Chipaca: hi, question about rest api. {"type":"sync","status-code":200,"status":"OK","result":{"id":"12","kind":"configure-snap","summary":"Change configuration of \"core\" snap","status":"Doing","tasks":[{"id":"82","kind":"run-hook","summary":"Run configure hook of \"core\" snap","status":"Doing","progress":{"label":"","done":1,"total":1},"spawn-time":"2017-05-12T09:51:34.973297068Z"}],"ready":false,"spawn-time":"2017-05-12T09:51:34.973459255Z"}} So it | 13:23 |
| sborovkov | says "doing" but if I look at "progress" inside "done" is 1? | 13:23 |
| sborovkov | so what should I actually be looking at that job is done | 13:23 |
| Chipaca | pstolowski: do you remember offhand what the progress info means for the configure hook? | 13:35 |
| Chipaca | sborovkov: wrt knowing whether it's done, it changes to status:Done | 13:35 |
| Chipaca | ah! | 13:36 |
| Chipaca | sborovkov: a total of "1" means there isn't progress information | 13:36 |
| Chipaca | i.e., just spin | 13:36 |
| sborovkov | hmm alright thanks | 13:37 |
| pstolowski | Chipaca, no, but I just had a quick look and I don't see it doing anything about progress, so yes as you say it's (0,1) -> (1,1) | 13:39 |
| Chipaca | yep | 13:39 |
| zyga | re | 13:39 |
| zyga | Chipaca: (sorry for disconnecting earlier) | 13:39 |
| zyga | Chipaca: so what is the path forward for patch? | 13:40 |
| Chipaca | zyga: a time machine | 13:41 |
| zyga | Chipaca: do we have anything better? | 13:42 |
| zyga | :D | 13:42 |
| zyga | Chipaca: question, is golint right or are we right? | 13:43 |
| zyga | bootstrap.go:48:2: error var noNamespaceError should have name of the form errFoo | 13:43 |
| Chipaca | ah! no, my bad | 13:44 |
| Chipaca | i got confused | 13:44 |
| Chipaca | zyga: ErrFoo is for values, FooError is for types | 13:44 |
| zyga | Chipaca: aha | 13:45 |
| Chipaca | zyga: wrt patches, the problem is that we want them to not be flagday events, ie we want them to be undoable | 13:45 |
| Chipaca | zyga: for which we need to enable let past snapds undo patches of future snapds | 13:46 |
| Chipaca | which is doable, but super easy to over-engineer | 13:47 |
| zyga | Chipaca: aha | 13:47 |
| zyga | Chipaca: hmm | 13:47 |
| zyga | Chipaca: undo could be simply a snapshot we roll back to | 13:47 |
| Chipaca | and i don't see a way out of having either a single epoch when we implement this thing, or having one last flagday | 13:47 |
| zyga | Chipaca: e.g. /var/lib/snapd/state.json -> state.patch21.json | 13:47 |
| zyga | Chipaca: but "past" snapd could read the symlink and say "gee, this sucks", I'll use state.patch20.json | 13:47 |
| Chipaca | zyga: right, but we want to let a person revert a day (a week) after they got refreshed into something they didn't notice wasn't working | 13:48 |
| zyga | Chipaca: devil is in details, specifically if you rollback just after upgrade | 13:48 |
| zyga | Chipaca: or after collecting 100 extra changes | 13:48 |
| zyga | Chipaca: indeed | 13:48 |
| zyga | Chipaca: but how can future snapd downgrade non-programmatically? | 13:48 |
| zyga | Chipaca: could we ask snapd to downgrade state to given patch level? | 13:49 |
| Chipaca | easily (the problem is _past_ snapd :-p) | 13:49 |
| zyga | Chipaca: e.g. snap set core patch-level=10 | 13:49 |
| zyga | Chipaca: then rollback | 13:49 |
| Chipaca | I think it's doable and there should be a generic, simple, straightforward and correct way of expressing transformations to the state | 13:49 |
| Chipaca | but making it have all those attributes is hard | 13:50 |
| zyga | Chipaca: "generic simple straightforward", gee, sounds like a turing machine :D | 13:50 |
| zyga | Chipaca: the question is this | 13:53 |
| zyga | Chipaca: should we describe a transformation of state | 13:53 |
| pedronis | zyga: so far we cheat with one shot Ensure stuff | 13:53 |
| zyga | Chipaca: and teach current snapd to process the transformations | 13:53 |
| zyga | pedronis: (yes) | 13:53 |
| zyga | Chipaca: or should we do something (anything) else | 13:53 |
| pedronis | if you need something today that's the way | 13:54 |
| pedronis | maybe at the sprint we can discuss something else | 13:54 |
| zyga | pedronis: mmm, I think this can wait for the sprint | 13:54 |
| zyga | pedronis: it's for the oldest open branch: | 13:54 |
| zyga | ah, 2nd oldest | 13:54 |
| zyga | https://github.com/snapcore/snapd/pull/2837 | 13:54 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 13:54 |
| zyga | I think that to fix it we need to store extra stuff about "try" snaps | 13:55 |
| pedronis | not so clear what why we need to fix the past there though | 13:55 |
| pedronis | it's broken atm | 13:55 |
| zyga | pedronis: yep | 13:55 |
| zyga | pedronis: so... maybe I can use a patch :) | 13:55 |
| pedronis | and try stuff is ephemeralish | 13:55 |
| zyga | pedronis: the tricky thing is that I'm not sure a patch can fix anything | 13:55 |
| pedronis | well, more do nothing for old stuff | 13:55 |
| zyga | pedronis: as we just don't have any state today there | 13:55 |
| pedronis | just fix it for new stuff | 13:55 |
| zyga | pedronis: I just want to start collecting more state | 13:55 |
| zyga | pedronis: yep | 13:56 |
| Chipaca | zyga: 3225 gtg once green | 13:56 |
| zyga | pedronis: I think you are right | 13:56 |
| zyga | Chipaca: thank you! | 13:56 |
| zyga | Chipaca: I'm working on unit tests now | 13:56 |
| Chipaca | zyga: pedronis: in any case, I think _backwards compatible_ changes (i.e. additions to structs) should be fine | 13:56 |
| zyga | once it hits edge we should rally people on the forum to do some dedicated testing | 13:56 |
| Chipaca | that is, we should be able to do those without having to bump patch level i think? | 13:57 |
| pedronis | kind of | 13:57 |
| pedronis | you need to redo them | 13:57 |
| zyga | redo? | 13:57 |
| pedronis | if you go back and forward | 13:57 |
| pedronis | but maybe I'm not understanding what Chipaca is saying | 13:57 |
| Chipaca | pedronis: I think you are | 13:58 |
| Chipaca | i mean, yes you'd have to redo them on rollback/re-refresh | 13:58 |
| pedronis | so you don't need a patch level for those but something | 13:59 |
| Chipaca | because they're backwards compatible, we get away with their undo being a NOP | 13:59 |
| Chipaca | but you still need to (re)do them when moving forwards | 13:59 |
| zyga | Chipaca: here I think this is tricky because the forward path is also a nop | 13:59 |
| zyga | Chipaca: as we cannot just guess the data easily | 13:59 |
| zyga | Chipaca: (we might but I would argue not to as the cost outweights the benefit) | 14:00 |
| Chipaca | zyga: how is the forwards a nop? | 14:00 |
| zyga | Chipaca: because of zero values | 14:00 |
| pedronis | as I said I see no reason to use a patch that might brick you to fix a development case | 14:00 |
| Chipaca | if the patch do is a nop, and the undo is a nop, then there is no patch :-) | 14:00 |
| zyga | Chipaca: we'd add a new field to a struct | 14:00 |
| zyga | Chipaca: quick comment on https://github.com/snapcore/snapd/pull/3321 | 14:07 |
| mup | PR snapd#3321: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321> | 14:07 |
| popey | cjwatson: oh, did I delete that, sorry. Yes, Stuarts is a good alternative | 14:12 |
| AdamH_ | Not sure if i am going mad here, but has syslog been taken out of the latest edge builds? | 14:20 |
| Pharaoh_Atem | morphis: pong | 14:23 |
| kyrofa | AdamH_, indeed it has | 14:27 |
| kyrofa | AdamH_, more details here: https://forum.snapcraft.io/t/change-in-logging-behaviour-on-ubuntu-core/591 | 14:28 |
| AdamH_ | kyrofa: By design? Only noticed when trying to get mir-kiosk-apps to run and they fails as well. | 14:28 |
| pedronis | Chipaca: I think I have hit some variant of aborting on seeding explodes problem in a test | 14:28 |
| AdamH_ | Thanks | 14:28 |
| pedronis | Chipaca: good and bad | 14:32 |
| Chipaca | ...? | 14:32 |
| pedronis | Chipaca: well good I have a reproducer of something, bad it's a distraction from my current task | 14:34 |
| Chipaca | pedronis: http://i.imgur.com/rQIb4Vw.gif | 14:36 |
| pedronis | anyway good but will ignore for a bit | 14:37 |
| Chipaca | man, *all* the tests that create keys are timing out :-( | 14:38 |
| zyga | Chipaca: I'll look at that | 14:38 |
| zyga | Chipaca: maybe the hwrng thing isn't helpin | 14:38 |
| zyga | g | 14:39 |
| Chipaca | is it done already? | 14:39 |
| zyga | I think so | 14:39 |
| zyga | yep | 14:39 |
| zyga | yes, tests are rather red now | 14:40 |
| Chipaca | do linode hosts even have a hwrng | 14:41 |
| Chipaca | i still think we need pollinate | 14:41 |
| zyga | Chipaca: I think recent intel and amd hardware have cpu instruction for that but I agree we need polinate | 14:42 |
| zyga | or pollinate even | 14:42 |
| * zyga reads https://forum.linode.com/viewtopic.php?t=2311%3E | 14:43 | |
| Chipaca | zyga: I doubt we're running on hardware | 14:44 |
| zyga | Chipaca: that's okay, it's just an instructions any VM can use | 14:45 |
| zyga | (given recent hardware) | 14:45 |
| zyga | still reading though | 14:45 |
| AdamH_ | Looks like the latest edge build breaks the mir-kiosk-apps demo with [QPA] QMirClientClientIntegration: connection to Mir server failed. Mir returned: "" | 14:47 |
| zyga | AdamH_: any denials? | 14:47 |
| AdamH_ | zyga: Nope not seeing any | 14:48 |
| zyga | did the snap itself change/ | 14:48 |
| AdamH_ | zyga: Not that I am aware of, we use it as a baseline to test mir-kiosk install when we have issue with the builds of our own app. Hence noticing the error | 14:49 |
| zyga | Chipaca: heh, forum suggests to run this in a separate terminal: >while true ; do mandb ; done | 14:51 |
| zyga | Chipaca: as source of entropy ;D | 14:51 |
| Chipaca | /o\ | 14:51 |
| zyga | AdamH_: does it work on stable core/ | 14:51 |
| AdamH_ | zyga: No because vc4 is missing from the build so mir-kiosk does not start on rPi3 | 14:52 |
| AdamH_ | so been running on the edge build which includes vc4 | 14:53 |
| zyga | AdamH_: do you have an edge revision where id still worked? | 15:03 |
| morphis | Pharaoh_Atem: you had time to rework the snap-mgmt script? | 15:06 |
| Chipaca | FWIW, we do seem to have /dev/hwrng | 15:08 |
| Pharaoh_Atem | morphis: I was going to after you sent me that list of files | 15:08 |
| morphis | Pharaoh_Atem: ah, right | 15:12 |
| morphis | I knew that I forgot something .. | 15:12 |
| * zyga merged update-ns! | 15:17 | |
| zyga | now for real world feedback | 15:17 |
| zyga | and those unit tests :) | 15:17 |
| zyga | but first hwrng :(( | 15:17 |
| AdamH_ | zyga: Unfortunately not | 15:17 |
| mup | PR snapd#3225 closed: cmd/snap-update-ns: add actual implementation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3225> | 15:18 |
| zyga | if anyone notices something funky with the content interface, let me know please | 15:21 |
| zyga | fgimenez: did you see https://blog.travis-ci.com/2017-05-11-introducing-build-stages?utm_source=broadcast&utm_medium=notification | 15:24 |
| zyga | fgimenez: anything we could benefit from | 15:24 |
| zyga | ?? | 15:24 |
| fgimenez | zyga: yes, not sure if it makes too much sense for snapd suite though | 15:24 |
| fgimenez | zyga: don't really know :) what do you think? | 15:25 |
| zyga | fgimenez: I was thinking about running some quick smoke test early on (say unit tests) and then run the spread suite only if that fist thing passes | 15:26 |
| zyga | fgimenez: so sequential check then parallel spread | 15:27 |
| zyga | fgimenez: maybe even just run unit tests as an early warning systme | 15:27 |
| zyga | *system | 15:27 |
| * zyga is tired and takes a break | 15:30 | |
| fgimenez | zyga: i think we can do that without stages, we do something similar now with the static tests, unit are more expensive and that would impose an upfront delay to all the builds, currently we are making good use of spread paralellization by executing the unit tests as a regular task | 15:31 |
| fgimenez | zyga: but yes, maybe it is good to have that early warning system, there are always tradeoffs and perhaps the benefits of having it are better than having the execution time improvements | 15:32 |
| fgimenez | mmm i'm getting a panic on pi3 (2.26) http://paste.ubuntu.com/24581419/ | 15:33 |
| AdamH_ | zyga: mir-kiosk-apps works when using the beta channel if that helps | 15:44 |
| Chipaca | fgimenez: is there a particular reason you make rngd use /dev/urandom ? | 15:52 |
| Chipaca | fgimenez: (in other words, if I changed it to use /dev/hwrng if present, would that be ok?) | 15:53 |
| fgimenez | Chipaca: yes i think so, morphis did that changes though, i just enabled them for ubuntu, he can confirm if that is ok | 15:55 |
| Chipaca | ah | 15:55 |
| morphis | Chipaca: just because that is available everywhere, qemu, linode, .. | 15:55 |
| === JohnAgosta is now known as JohnAgosta-otp | ||
| Chipaca | morphis: afaict hwrng is also available in those places | 15:57 |
| Chipaca | (on debian you need to load a module) | 15:57 |
| morphis | Chipaca: not on qemu unless you enable that with the qemu cmd line | 15:57 |
| Chipaca | in any case, i'll propose a branch (if this change makes debian happier) | 15:58 |
| Chipaca | morphis: strange, i see it in qemu in both ubuntu (by default) and debian (after the modprobe) | 15:58 |
| morphis | Chipaca: really? I had to add -device virtio-rng-pci to get the host hwrng forwarded | 15:58 |
| Chipaca | morphis: and if you modprobe tpm-rng? | 15:59 |
| morphis | guess that still needs a tpm, either emulator by qemu (which it may does by default) or forwarded from the host | 16:00 |
| morphis | Chipaca: but let me try that | 16:01 |
| elopio | cjwatson: is it possible to retrigger a build in build.snapcraft.io? | 16:06 |
| === jdstrand_ is now known as jdstrand | ||
| cjwatson | elopio: not at the moment | 16:08 |
| cjwatson | (this is a bug IMO, though not sure if it's been filed) | 16:08 |
| elopio | cjwatson: I couldn't find it, so I will report it. And is there a plan to do this with an API? For some cases, I want to trigger the build from travis. | 16:12 |
| cjwatson | elopio: Thanks in advance for the report. My feeling is that if you're getting to the point where you need an API then you should be using the underlying Launchpad facilities directly, not via BSI. | 16:15 |
| elopio | cjwatson: that works for me. However, the UI is a lot nicer on this side. I would appreciate a nice dashboard even for the ones that are hooked to my weird CI. | 16:16 |
| cjwatson | elopio: You can certainly request it (though in a separate issue, please). Just telling you that APIs aren't a priority at the moment. | 16:17 |
| elopio | cjwatson: I will leave somebody else (who actually needs it) to report it, because launchpad indeed solves my use case. | 16:18 |
| cjwatson | OK | 16:18 |
| Chipaca | morphis: gah, modprobe works, device gets created, but rngd fails to read it :-( | 16:27 |
| morphis | :-) | 16:27 |
| Chipaca | morphis: (also, there's a rng-tools5 that seems to be ubuntu's rng-tools; rng-tools in debian is ancient) | 16:27 |
| morphis | Pharaoh_Atem: https://paste.ubuntu.com/24581840/ | 16:31 |
| morphis | Pharaoh_Atem: also looks like the snaps didn't got unmount now with my installation of the snapd 2.25 package on F25 (fresh install) | 16:31 |
| morphis | Pharaoh_Atem: for the paste I unmounted them manually | 16:31 |
| Pharaoh_Atem | hmm | 16:46 |
| Pharaoh_Atem | I didn't change anything regarding that | 16:46 |
| === jdstrand is now known as jdstrand_ | ||
| === jdstrand_ is now known as jdstrand | ||
| mup | PR snapd#3322 opened: overlord: make config defaults from gadget work at also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322> | 18:20 |
| mup | PR snapcraft#1248 closed: snap: include asset tracking details in snap/snapcraft.yaml <Created by josepht> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1248> | 19:07 |
| mup | PR snapd#3323 opened: overlord/snapstate: avoid creating command aliases for daemons <Created by pedronis> <https://github.com/snapcore/snapd/pull/3323> | 19:27 |
| === JanC_ is now known as JanC | ||
| mup | Bug #1690880 opened: test_snappy_version fails on artful <cloud-init:New> <Snappy:New> <https://launchpad.net/bugs/1690880> | 21:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
