| === c74d is now known as Guest68804 | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| Rlyeh | Hi | 06:36 |
|---|---|---|
| Rlyeh | I replaced a fresh snappy on my BBB, updated ubuntu-core 3 to 4, installed docker and then owncloud | 06:36 |
| Rlyeh | But owncloud is still not working on port 443! http://paste.ubuntu.com/12077510/ | 06:36 |
| Rlyeh | Did I missed something? | 06:36 |
| === chihchun_afk is now known as chihchun | ||
| Rlyeh | Anyone knows how to use owncloud?! | 06:40 |
| Rlyeh | When I run owncloud, docker can't find owncloud locally and it download from docker repo! http://paste.ubuntu.com/12077534/ | 06:45 |
| === Rlyeh is now known as Rlyehh | ||
| Rlyeh | No idea for owncloud? | 06:51 |
| tasdomas | hi | 07:05 |
| tasdomas | is there a way for a snap to know which other snaps are installed on the system or are the snaps completely isolated from each other? | 07:06 |
| fgimenez | good morning | 07:07 |
| tasdomas | morning, fgimenez | 07:08 |
| fgimenez | hey tasdomas | 07:08 |
| dholbach | good morning | 07:32 |
| === erkules_ is now known as erkules | ||
| tasdomas | are there any service discovery solutions for snappy? Both internally (snaps discovering other snaps) and externally (other wireless devices discovering services running on snappy | 10:00 |
| ogra_ | well, netstat is installed by default :) | 10:02 |
| ogra_ | (nothing hiher level yet, no) | 10:02 |
| ogra_ | *higher | 10:03 |
| pcoca | Hi everyone, I'm not able to make a snap with snapcraft out of a python script that requires opencv, I've tried several plugins python2-project, python3-project, ubuntu, but it doesn't include the library. | 10:06 |
| pcoca | has this something to do with the setup.py? | 10:06 |
| === greyback__ is now known as greyback | ||
| longsleep | Question - what is the preferred way to load additional kernel modules in snappy? | 10:25 |
| longsleep | in normal Ubuntu i just cat them at the end of /etc/modules ... | 10:25 |
| ogra_ | you ship them in your devce tarball | 10:27 |
| ogra_ | or gadget snap later ... | 10:27 |
| longsleep | no way to do this from a snap? So stuff like that always needs oem? | 10:28 |
| ogra_ | yes | 10:28 |
| ogra_ | well, kernel/device | 10:28 |
| ogra_ | oem is bootloader only currently | 10:28 |
| longsleep | right | 10:28 |
| ogra_ | for now i'd just ship system/etc/modules in the device tarball | 10:29 |
| longsleep | yes i can do that | 10:29 |
| longsleep | i read through the webcam example | 10:29 |
| longsleep | it seems to expect that the driver for the webcam gets loaded automatically | 10:29 |
| ogra_ | yeah | 10:30 |
| longsleep | so i was wondering if there is a way for manual driver loading for other stuff | 10:30 |
| ogra_ | i think we'll have that via snappy-config at some point ... i.e. you can ship multiple modules and define which ones are loaded through a config hook | 10:31 |
| longsleep | yes that would make sense | 10:31 |
| ogra_ | once we have snappified the device tarball side | 10:31 |
| ogra_ | yay | 10:32 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ df -h|grep oem | 10:32 |
| ogra_ | /dev/sda1 15G 813M 14G 6% /oem | 10:32 |
| ogra_ | 16G writable space :) | 10:32 |
| longsleep | yah! | 10:32 |
| ogra_ | on USB stick | 10:32 |
| longsleep | so what did you do? | 10:32 |
| longsleep | moved oem to usb stick? | 10:33 |
| ogra_ | just format it ext4, label it writable, copy the SD writable content over and re-label the SD writable to old-writable | 10:33 |
| longsleep | right, so snappy auto mounts stuff? | 10:33 |
| ogra_ | well, on boot | 10:34 |
| ogra_ | i did the above on a PC :) | 10:34 |
| ogra_ | and then booted with USB and SD ... | 10:34 |
| ogra_ | we mouont by label ... so switching the writable bts to a bi 3TB USB disk is easy | 10:35 |
| ogra_ | i just needed to test it (i want to blog about it) | 10:35 |
| longsleep | ah ok understand | 10:35 |
| longsleep | any news on getting snappy to automatically expand the partition on boot? | 10:36 |
| ogra_ | working on it :) | 10:36 |
| longsleep | cool | 10:36 |
| ogra_ | i hope ot have that landed next week in the rolling channel | 10:36 |
| * ogra_ tries some fun stuff on the side with https://github.com/paimpozhil/DockerX2go/tree/master/xubuntu | 10:37 | |
| ogra_ | :) | 10:37 |
| longsleep | i guess i should switch to whatever becomes snappy 15.10 at some point | 10:37 |
| ogra_ | not sure there will be a snappy 15.10, currently we are backporting all backportable bits to 15.04 | 10:38 |
| longsleep | ogra_: ok - well i do not care about the version really so long as i am on the latest | 10:38 |
| ogra_ | could well be that we directly go to 16.04 then with the next iteration of the stable channel | 10:38 |
| * ogra_ knows there are some release plans ... but i cant find them atm | 10:39 | |
| longsleep | ogra_: btw i ended up creating some unconfined snaps to handle some internal stuff - should i try hard to avoid unconfined stuff? | 10:40 |
| ogra_ | well, i would ... but i want my snaps in the store without delays :) | 10:40 |
| longsleep | ogra_: things need to read all kinds of things from /proc for example | 10:40 |
| longsleep | ogra_: and i am currently skipping the work to create custom profiles for this and just leave it unconfined | 10:41 |
| * longsleep wonders if that is a problem | 10:41 | |
| ogra_ | i think the planned sub-store setup together with the oem snap will help here | 10:41 |
| ogra_ | in such a sub store you can break out of confinement if you want afaik | 10:41 |
| ogra_ | since you make the rules for it | 10:42 |
| ogra_ | dont quote me on that though :D | 10:42 |
| longsleep | ogra_: we will try it out for sure :) | 10:42 |
| longsleep | ogra_: unconfined snaps cannot go into the store at all or is it a matter of review only? | 10:43 |
| ogra_ | completely unconfined cant i think ... | 10:43 |
| ogra_ | (well, technically they can ... thats indeed a policy thing) | 10:43 |
| longsleep | not that i am going to submit those at the moment but eventually it might be nice to have | 10:43 |
| ogra_ | as i said, with your ownb sub-store it should be possible since i guess you make the rules abouot what goes in there | 10:44 |
| longsleep | right | 10:44 |
| ogra_ | so if adjustment to the confinement policy is needed by your oem setup that should be possible | 10:45 |
| * ogra_ hopes someone corrects him if he talks rubbish :) | 10:46 | |
| longsleep | well let me try to avoid unconfined for the next snap, though for this need to understand the assing block in the yaml | 10:46 |
| longsleep | but first - lunch! | 10:46 |
| ogra_ | enjoy ! | 10:46 |
| longsleep | thanks | 10:46 |
| ogra_ | hmm | 11:03 |
| ogra_ | sergiusens, we need a way to ship sysctl settings in the kernel snap ... | 11:03 |
| * ogra_ just notices that the RPi NIC exposes the typical smsc95xx where you need to adjust the vm.min_free_kbytes default to make it not drop frames | 11:04 | |
| longsleep | ogra_: yes - i need that - currently fusing them into initrd :/ | 11:04 |
| ogra_ | such an old bug ... :/ | 11:04 |
| sergiusens | ogra_: I did sort of mentioned that to lool | 11:04 |
| sergiusens | ogra_: I'm just waiting for the new snap formats to show up | 11:04 |
| ogra_ | cool | 11:05 |
| ogra_ | i guess it currentrly is possible via the device tarball | 11:05 |
| ogra_ | (shipping a file in system/etc/sysctl.d/ ....) | 11:05 |
| longsleep | yes - that works though is too late for some settings | 11:05 |
| longsleep | (thats why i currently have them all in initrd hook) | 11:06 |
| ogra_ | https://bugs.launchpad.net/linux-linaro/+bug/664477 | 11:07 |
| ubottu | Launchpad bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released] | 11:07 |
| ogra_ | 2011 | 11:07 |
| ogra_ | oh, even reported in 2010 | 11:08 |
| longsleep | and that happens on rpi2 as well? | 11:08 |
| ogra_ | it is a hardware thing | 11:08 |
| longsleep | ah they have the same nic | 11:09 |
| ogra_ | well, or a kernel defaults one ... | 11:09 |
| ogra_ | depends which way you look at it :) | 11:09 |
| * ogra_ files bug 1484898 | 11:14 | |
| ubottu | bug 1484898 in Snappy "device tarball needs to allow setting sysctl defaults" [Undecided,New] https://launchpad.net/bugs/1484898 | 11:14 |
| ogra_ | bah | 11:15 |
| ogra_ | time="2015-08-14T11:12:17Z" level=fatal msg="Error response from daemon: Cannot start container 22626e0f94cf7ea90bd53faf37a8526676e2a572dc16b045a74e428e9d8d8b3b: [8] System error: exec format error" | 11:15 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ | 11:15 |
| ogra_ | *sniff* | 11:15 |
| Chipaca | dholbach: python-apt upstream now includes the verbosity fix | 11:16 |
| longsleep | armf vs x86_64 | 11:16 |
| Chipaca | dholbach: dunno where to go from here -- resync? | 11:16 |
| Chipaca | dholbach: that is: it's in the debian/sid branch of debian's git thing | 11:16 |
| dholbach | Chipaca, let's wait for mvo to land it in ubuntu then | 11:17 |
| dholbach | he knows which branch to merge and what to upload | 11:17 |
| ogra_ | longsleep, yeah | 11:17 |
| Chipaca | dholbach: okie doke | 11:17 |
| dholbach | :) | 11:18 |
| === chihchun is now known as chihchun_afk | ||
| longsleep | yay snappy has 'netcat-openbsd' available - is that intentional or accident? | 11:46 |
| ogra_ | neither :) | 11:48 |
| ogra_ | it is inherited from the ubuntu-core seeds | 11:48 |
| longsleep | so should i use it from the system or rather have my own python netcat in each snap? | 11:49 |
| ogra_ | might be ripped out and become part of comfy ... dont rely on it being there | 11:49 |
| longsleep | all right | 11:49 |
| longsleep | its so handy to pipe stuff into sockets for testing .. | 11:50 |
| ogra_ | systemd, kernel and the snappy binary are the only guaranteed bits in the core :) | 11:50 |
| ogra_ | (and the glue necessary to make them work, but that glue can change at any time) | 11:50 |
| longsleep | well i guess all the stuff from the default aa profile is pretty much solid | 11:50 |
| longsleep | by the way, sideloading snaps with snappy-remote has a bug. Id does not wait for services to stop before replacing files leading to 'text file busy' issues | 11:52 |
| ogra_ | i thnk i have seen that with local sideloading too | 11:52 |
| ogra_ | might be a general race | 11:53 |
| Chipaca | oh? | 11:53 |
| ogra_ | (just exposed stronger via remote) | 11:53 |
| Chipaca | that sounds like a bug :) | 11:53 |
| longsleep | it annoys me pretty hard at the moment :) | 11:53 |
| ogra_ | Chipaca, yes, i only noticed it yesterday when playin with my broken xorg stuff | 11:53 |
| Chipaca | "stop" waits | 11:54 |
| longsleep | http://paste.ubuntu.com/12078757/ | 11:54 |
| Chipaca | and i'm pretty sure "remove" calls stop | 11:54 |
| ogra_ | (where i had syslog tailed permanently in a separate window ... sometimes it didnt stop the running process in time and fell over) | 11:54 |
| Chipaca | i mean, i wrote it that way :) but maybe we broke it? | 11:54 |
| longsleep | if that happens one has to remote the snap two more times | 11:55 |
| longsleep | first time after the error service gets not started | 11:55 |
| ogra_ | well, we stop the service ... but that service runs a wrapper that runs a shell script (in my case at least) which in turn runs a subcommand ... | 11:55 |
| longsleep | third time everything works fine | 11:55 |
| Chipaca | it sounds like that is unpacking into the current directory | 11:56 |
| Chipaca | hmm | 11:56 |
| ogra_ | longsleep, thats exactly the same i have seen yesterday | 11:56 |
| longsleep | Chipaca: syslog here: http://paste.ubuntu.com/12078774/ | 11:57 |
| longsleep | (it does not stop the service) | 11:57 |
| Chipaca | lovely D: | 11:58 |
| Chipaca | so | 11:59 |
| Chipaca | sideloading is treated differently, in that the usual "is installed" check is skipped | 12:00 |
| Chipaca | because otherwise it slows you down (you'd have to remove the package manually before re-sideloading it) | 12:00 |
| Chipaca | however that does mean it's not really expecting this error | 12:00 |
| Chipaca | longsleep: how reproducible is this? | 12:01 |
| Chipaca | longsleep: if i'm understanding the error correctly, bumping the version would "fix" it | 12:01 |
| Chipaca | longsleep: where i'd consider that a workaround more than a fix, but | 12:01 |
| Chipaca | good enough to confirm that that is what's happening | 12:01 |
| Chipaca | i think | 12:01 |
| Chipaca | :) | 12:01 |
| ogra_ | i have seen it a lot yesterday | 12:02 |
| ogra_ | i would say about a third of my install attempts showed it | 12:02 |
| Chipaca | yeah | 12:02 |
| Chipaca | the unpack is done before the activate/deactivate | 12:02 |
| Chipaca | and in fact it's done straight to the directory it'll work from | 12:02 |
| Chipaca | which makes sense, as some of the checks then rely on that | 12:03 |
| Chipaca | the checks done before activation | 12:03 |
| ogra_ | the directrory is gone after the failure though | 12:03 |
| Chipaca | however when sideloading it's an issue | 12:03 |
| ogra_ | something seems to wipe it | 12:03 |
| Chipaca | well, yes | 12:03 |
| Chipaca | installation cleans up on failure | 12:03 |
| Chipaca | and as it's not coping with reinstallation of the same version at all | 12:03 |
| Chipaca | ... well, i don't need to spell it out :) | 12:04 |
| ogra_ | :) | 12:04 |
| Chipaca | so, either we block sideloading of the same version | 12:04 |
| Chipaca | or we cope with it properly | 12:04 |
| Chipaca | the current situation is a recipe for heartache | 12:05 |
| ogra_ | it doesnt onyl happen with the same version (i need to bump the version when changing sccomp or apparmor profiles) | 12:05 |
| Chipaca | ogra_: wat | 12:05 |
| Chipaca | ogra_: i'd love to see the error when it's a different version! | 12:06 |
| Chipaca | it surely can't be the same :) | 12:06 |
| Chipaca | (if it is, something is seriously wrong, not just a cornercase bug) | 12:06 |
| ogra_ | i'd give you the log, but since the broken service was starting in a loop that wont be much helpful | 12:08 |
| ogra_ | (over like 4h or so) | 12:08 |
| Chipaca | i'll write it down to you not having had lunch until i see logs :-p | 12:09 |
| longsleep | Chipaca: it fails very time | 12:10 |
| Chipaca | longsleep: and if you bump the version? | 12:10 |
| longsleep | let me try | 12:10 |
| Chipaca | ta | 12:10 |
| longsleep | that should work i assume | 12:11 |
| Chipaca | it failing in a different way would be interesting | 12:11 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo ls -lh /var/log/syslog | 12:11 |
| ogra_ | -rw-r----- 1 syslog adm 13M Aug 14 12:10 /var/log/syslog | 12:11 |
| Chipaca | it failing in the *same* way would be *very interesting* | 12:11 |
| ogra_ | hmm, dont we have logrotate in place ? | 12:11 |
| ogra_ | (the log starts on the 7th) | 12:11 |
| longsleep | Chipaca: did not fail but now it runs twice :) | 12:12 |
| longsleep | Chipaca: the old version still runs | 12:12 |
| Chipaca | longsleep: ok | 12:12 |
| Chipaca | longsleep: where it says "ok", read it in a tone of voice that implies serious non-OKness | 12:12 |
| longsleep | :D | 12:12 |
| Chipaca | longsleep: how do you stop your service? | 12:13 |
| longsleep | Chipaca: i let systemd take care of it | 12:13 |
| longsleep | Chipaca: i assume it just kills it | 12:13 |
| Chipaca | it should | 12:13 |
| Chipaca | what's going on | 12:13 |
| Chipaca | longsleep: what does systemctl status tell you? | 12:13 |
| longsleep | degraded | 12:14 |
| longsleep | http://paste.ubuntu.com/12078864/ | 12:14 |
| longsleep | from what i see in the logs, the old service never was stopped | 12:15 |
| Chipaca | and 'systemctl stop dotstar-leds_dotstar_0.0.1-1.service' just works, yes? | 12:15 |
| longsleep | yes | 12:15 |
| Chipaca | dammit, i can't blame it on you :-) | 12:16 |
| longsleep | heh | 12:16 |
| Chipaca | i'll file a bug, in penance | 12:16 |
| longsleep | thanks :) | 12:16 |
| Chipaca | https://bugs.launchpad.net/snappy/+bug/1484922 | 12:17 |
| ubottu | Launchpad bug 1484922 in Snappy "Sideloading a snap with a service does not stop the service of the old version" [Undecided,New] | 12:17 |
| Chipaca | now let's see if i can reproduce it | 12:18 |
| longsleep | btw the reason my system is marged as degrated is none of my snaps but rather webdm because of bug 1466672 | 12:18 |
| ubottu | bug 1466672 in Snappy 15.04 "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672 | 12:18 |
| Chipaca | yep | 12:20 |
| Chipaca | degraded means a unit failed | 12:21 |
| Chipaca | sergiusens: you around? | 12:21 |
| longsleep | btw i find it strange that there is a poststop but no poststart in package-metadata yaml for services. | 12:22 |
| * longsleep would really like to run some things after the service started and without dash hackery | 12:23 | |
| sergiusens | Chipaca: yeah | 12:26 |
| Chipaca | sergiusens: what's blocking https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 do you know/remember? | 12:27 |
| Chipaca | longsleep: so, i can't reproduce the issue with snappy from wily edge. you're on 15.04 stable? | 12:28 |
| sergiusens | Chipaca: me | 12:28 |
| sergiusens | :-) | 12:28 |
| * Chipaca hugs sergiusens | 12:28 | |
| longsleep | Chipaca: yes | 12:28 |
| longsleep | Chipaca: version 4 from stable channel | 12:29 |
| Chipaca | longsleep: 1.4? | 12:30 |
| Chipaca | oh, wait | 12:30 |
| Chipaca | this is not that | 12:30 |
| * Chipaca starts another kvm | 12:30 | |
| longsleep | Chipaca: ubuntu-core 2015-07-29 4 ubuntu | 12:30 |
| longsleep | Chipaca: channel: ubuntu-core/15.04/stable | 12:31 |
| Chipaca | yep yep | 12:31 |
| Chipaca | the 1504 i had was something else :) | 12:31 |
| Chipaca | longsleep: also can't reproduce it with 15.04 rev 4 | 12:35 |
| Chipaca | longsleep: using the python xkcd webserver snap | 12:35 |
| longsleep | Chipaca: do you have a service which is a binary file? | 12:35 |
| Chipaca | no | 12:35 |
| Chipaca | that's next | 12:35 |
| longsleep | i think text files can always be replaced | 12:35 |
| longsleep | but at least your service should run twice when you update to a new sideloaded version | 12:36 |
| longsleep | (if that service can be run twice) | 12:36 |
| Chipaca | longsleep: this is with a different version, so replacing file should not be an issue | 12:37 |
| Chipaca | exactly, it's the running twice thing that i was trying for | 12:37 |
| longsleep | ah | 12:38 |
| longsleep | Chipaca: could be also related to snappy-remote - i am running 0.4-0ubuntu1build1 on trusty | 12:43 |
| Chipaca | is snappy-remote anything other than something that ssh's in and runns snappy with all the given args? | 12:43 |
| sergiusens | longsleep: Chipaca snappy-remote just uses the snappy binary on the host | 12:43 |
| Chipaca | exactly | 12:43 |
| Chipaca | i imagin it as a two-line shellscript | 12:44 |
| sergiusens | the problem is in snappy itself | 12:44 |
| sergiusens | Chipaca: dream all you want :-P | 12:44 |
| Chipaca | :) | 12:44 |
| Chipaca | sergiusens: :) | 12:44 |
| Chipaca | sergiusens: see, if instead of having an option for the host you took it from environ, you could've made it a oneliner :-p | 12:45 |
| Chipaca | ssh ${SNAPPY_REMOTE_HOST:?Set SNAPPY_REMOTE_HOST to what to ssh to} -- "$@" | 12:45 |
| Chipaca | done \o/ | 12:46 |
| Chipaca | oh, add a "snappy" before the $@ | 12:46 |
| * Chipaca does not have enough :-P to sprinkle into that | 12:46 | |
| Chipaca | the go-example-webserver in snappy-examples is broken \o/ | 12:48 |
| Chipaca | ah, maybe i need to build it properly :-) | 12:49 |
| Chipaca | picky, pikcy | 12:49 |
| Chipaca | i wonder if this is something on arm only? | 12:52 |
| longsleep | Chipaca: that example is also problematic as it will fail to run twice | 12:53 |
| Chipaca | because on amd64 i can't get it to break | 12:53 |
| longsleep | (becasue of port already in use) | 12:53 |
| Chipaca | longsleep: ah! | 12:53 |
| * longsleep has problems with the order of letters today | 12:53 | |
| Chipaca | maybe? | 12:53 |
| * Chipaca adds a ports section | 12:54 | |
| longsleep | Chipaca: well with the go service you should get the text file busy problem | 12:54 |
| Chipaca | longsleep: not with different versions | 12:55 |
| Chipaca | it's two separate issues | 12:55 |
| longsleep | right | 12:55 |
| Chipaca | the text file busy one is due to how we (don't) handle sideloading of the same version | 12:55 |
| longsleep | really? Why - if the service would stop there would be no text file busy problem | 12:55 |
| Chipaca | the two services of different versions of the same app is really worrying | 12:55 |
| Chipaca | longsleep: on install, first we unpack, then we do some checks, then we stop the old version and start the new one | 12:56 |
| longsleep | Chipaca: ah ok | 12:56 |
| Chipaca | longsleep: :) | 12:56 |
| Chipaca | longsleep: so one workaround for that would be to, on sideload, stop before unpack | 12:59 |
| Chipaca | longsleep: because sideload install is not going to happen automatically, so the downtime is more tolerable | 12:59 |
| Chipaca | maybe also don't clean up on sideload install failure | 12:59 |
| Chipaca | slightly uncomfortable about making the two so different though | 13:00 |
| Chipaca | rsalveti: sergiusens: opinion about ^? | 13:00 |
| elopio | good morning. | 13:03 |
| sergiusens | Chipaca: I thought we wanted to kill the version on sideload installs and just create a hash | 13:04 |
| Chipaca | we did? i have no memory of that | 13:05 |
| Chipaca | but that does not mean we didn't :) | 13:05 |
| sergiusens | Chipaca: maybe you weren't there :-P | 13:06 |
| sergiusens | Chipaca: but the version is meaningless and this sort of solves people accidentally hardcoding stuff during development | 13:07 |
| Chipaca | longsleep: can i have a pastebin of you doing the snappy remote of an updated version that resulted in two services running, please? | 13:13 |
| longsleep | Chipaca: i do not know why, but now it did stop the old service when i installed a new version | 13:13 |
| Chipaca | sigh | 13:13 |
| Chipaca | longsleep: ok | 13:13 |
| longsleep | Chipaca: it might be related to the failure before | 13:13 |
| Chipaca | longsleep: so, how about this | 13:13 |
| longsleep | let me try to reproduce | 13:13 |
| Chipaca | longsleep: you tried to install the same thing | 13:13 |
| Chipaca | longsleep: it aborted because of text file thing | 13:13 |
| Chipaca | longsleep: but cleaned up -- removed files | 13:13 |
| Chipaca | longsleep: service still running, because who cares the file was rm' | 13:14 |
| Chipaca | ed | 13:14 |
| longsleep | let me try - should be easy to replicate | 13:14 |
| Chipaca | longsleep: installed, snappy did not find old thing, did not try to disable service | 13:14 |
| Chipaca | so that would result in two services | 13:14 |
| Chipaca | as a consecuence of the text file thing | 13:14 |
| longsleep | most likely yes | 13:14 |
| Chipaca | without it being a whole separate problem | 13:14 |
| longsleep | i am on it | 13:14 |
| Chipaca | thank you | 13:14 |
| longsleep | starting from clean state now | 13:15 |
| elopio | fgimenez: yesterday I was looking at the subunit tools. With what you have in that parser branch, it should be really easy to integrate with calls to subunit-output. | 13:15 |
| longsleep | Chipaca: yes it just failed to install, removed the stuff and the service is still running | 13:16 |
| longsleep | os i see the process and the file is gone | 13:16 |
| Chipaca | that makes sense | 13:17 |
| longsleep | Chipaca: yes reproduced - it only runs twice when the text file busy error happend | 13:17 |
| elopio | fgimenez: let me know when you are done with the parsing and I can start piping the subunit output to a file. | 13:17 |
| Chipaca | longsleep: that's a relief :) thank you! | 13:17 |
| fgimenez | elopio: great, only the binary encoding is missing | 13:17 |
| Chipaca | longsleep: it does make fixing the text file thing in stable more important | 13:17 |
| Chipaca | sergiusens: do we want to do the version hash thing in stable? or just workaround this there? | 13:18 |
| longsleep | Chipaca: yes - for development this can result in all kind of issues | 13:18 |
| Chipaca | yep | 13:18 |
| fgimenez | elopio: there's already a file step in the pipeline, we can remove it if needed | 13:18 |
| Chipaca | longsleep: for the time being, can you include 'snappy-remote yadda yadda remove the thing' before a same-version install? | 13:19 |
| longsleep | Chipaca: sure | 13:19 |
| Chipaca | snappy-remote --url=ssh://10.1.7.161 remove dotstar-leds && snappy-remote --url=ssh://10.1.7.161 install dotstar-leds_0.0.1-1_armhf.snap | 13:19 |
| Chipaca | or sth like that :) | 13:19 |
| longsleep | yeah should do the trick | 13:20 |
| longsleep | let me try | 13:20 |
| longsleep | Unknown command `remove'. You should use the install command | 13:20 |
| longsleep | :D | 13:20 |
| Chipaca | sergiusens: wat ^ | 13:21 |
| * Chipaca no habla snappy-remote | 13:21 | |
| ogra_ | lol | 13:21 |
| ogra_ | its just a two linne shellscript | 13:21 |
| ogra_ | :P | 13:21 |
| Chipaca | that's my mental model of it! | 13:21 |
| Chipaca | and if it were, that would've worked | 13:21 |
| Chipaca | so my mental model needs updating :) | 13:21 |
| elopio | fgimenez: oh, so what you have in parser.go is like the subunit v1 protocol, right? | 13:22 |
| ogra_ | or the shellscript needs a third line :) | 13:22 |
| Chipaca | ogra_: tomeito, tomahto | 13:23 |
| ogra_ | :D | 13:23 |
| fgimenez | elopio: yep, that should connect with the binary encoder in its next field | 13:23 |
| Chipaca | snappy-remote *only* knows install | 13:23 |
| Chipaca | longsleep: how about: ssh ubuntu@10.1.7.161 sudo snappy remove dotstar-leds && snappy-remote --url=ssh://10.1.7.161 install dotstar-leds_0.0.1-1_armhf.snap | 13:24 |
| fgimenez | elopio: and the binary encoder with the file, or stdout, in the next field | 13:24 |
| * Chipaca does not know if snappy-remote keeps keys in a nonstandard place, but maybe that'll work :) | 13:24 | |
| longsleep | Chipaca: sure | 13:25 |
| longsleep | Chipaca: that works just fine | 13:26 |
| longsleep | though i found another issue with that snap .. :/ | 13:27 |
| longsleep | problem is that SNAP_APP_TMPDIR=/tmp | 13:27 |
| longsleep | where it should be export TMPDIR="/tmp/snaps/dotstar-leds.sideload/0.0.1-3/tmp" | 13:27 |
| Chipaca | longsleep: are you sure? | 13:28 |
| Chipaca | i thought stable already had the private tmp fix? | 13:28 |
| fgimenez | elopio: not sure if the binary encoding step is a must | 13:28 |
| longsleep | Chipaca: yeah try hello-world.env | 13:28 |
| elopio | fgimenez: so I think that if we use subunit-output to generate the v2 stream, we can combine the parser.go and binary.go. Not sure if you'll like this idea though. | 13:28 |
| Chipaca | longsleep: sure, let me check | 13:28 |
| Chipaca | longsleep: stable already has the private /tmp fix | 13:28 |
| Chipaca | longsleep: all of /tmp is yours | 13:28 |
| Chipaca | longsleep: and /tmp will be actually a private mount of /tmp/snap.$UID_$APPID_$RANDOM | 13:29 |
| Chipaca | /tmp | 13:29 |
| longsleep | mhm i write stuff here SOCKET=$SNAP_APP_TMPDIR/dotstar_socket into the service | 13:29 |
| Chipaca | longsleep: so if you look at /tmp you should see a bunch of "snap.0_somthing.sideload_Xyws/ | 13:29 |
| longsleep | from the service i mean | 13:29 |
| longsleep | Chipaca: yes i see them | 13:29 |
| Chipaca | longsleep: whereas the old tmpfile was /tmp/snaps/ | 13:29 |
| longsleep | writing them from the service works fine | 13:29 |
| Chipaca | longsleep: so you'd see /tmp/snaps | 13:29 |
| Chipaca | longsleep: now | 13:30 |
| longsleep | but in the binary tmp points just to /tmp | 13:30 |
| longsleep | which does find nothing | 13:30 |
| Chipaca | longsleep: we do still set /tmp/snaps, for backwards compat, so that would be /tmp/snap.0_something.sideload_yadda/tmp/snaps/something.sideload/version/tmp | 13:30 |
| Chipaca | longsleep: ah, you mean SNAP_APP_TMPDIR is different in the service and in the binary? | 13:32 |
| Chipaca | that is entirely possible :-( | 13:33 |
| longsleep | hold on i am trying clean setup | 13:33 |
| Chipaca | longsleep: um | 13:33 |
| Chipaca | longsleep: are you expecting to find the same things in tmp from both service and binary? | 13:33 |
| Chipaca | because it'll be a _different_ tmpdir every time | 13:33 |
| longsleep | Chipaca: yes | 13:33 |
| longsleep | ah | 13:34 |
| longsleep | well, then i got a problem :) | 13:34 |
| Chipaca | longsleep: tell me more | 13:34 |
| longsleep | Chipaca: service creates a unix socket file | 13:34 |
| longsleep | Chipaca: i need that socket location from a binary | 13:35 |
| Chipaca | longsleep: $SNAP_APP_DATA_PATH ? | 13:35 |
| fgimenez | elopio: whatever works :), where can i read about subunit-output? | 13:35 |
| longsleep | Chipaca: i would prefer if that file is not persistent | 13:35 |
| elopio | fgimenez: sudo apt-get install subunit-output | 13:35 |
| elopio | subunit-output -h | 13:35 |
| longsleep | Chipaca: i thought there is a per snap temp folder | 13:36 |
| elopio | fgimenez: it even allows to attach files to the results. | 13:36 |
| Chipaca | longsleep: that's a very interesting use case, because i think ted was asking why we'd have SNAP_APP_DATA_PATH and SNAP_APP_USER_PATH at the same time, and that's one case where you'd want it (module persistence) | 13:36 |
| longsleep | Chipaca: what is how i understood the name SNAP_APP_TMPDIR | 13:36 |
| Chipaca | ted: ^^^ there you go, a use case :) | 13:36 |
| * ted reads backlog for this "use case" ;-) | 13:36 | |
| ted | Yeah, for something like that you probably want something per-snap in /run | 13:37 |
| longsleep | ted: yes - though that does not seem to exist | 13:37 |
| Chipaca | ted: yes, for socket you want a XDG_RUNTIME_DIR thing | 13:37 |
| Chipaca | ted: but you see my point about getting at the same data from service and binary? | 13:38 |
| ted | Yes, so I think that you want USER for things running as a user. But that is still useless for services. | 13:38 |
| Chipaca | sergiusens: you've been in more snappy sprints than I :) anything planned or thought on runtime dir? | 13:39 |
| ted | It seems like, in general, we need a way for frameworks to export environment variables. | 13:39 |
| ogra_ | Chipaca, the prob is that one sprint usually overrides the other ... so only the last counts ;) | 13:39 |
| Chipaca | longsleep: to unblock you right now, sadly, i don't have a better answer than (ab)using the data dir | 13:39 |
| fgimenez | elopio: ok thx looks very good, we can pipe to a exec.Command easily | 13:39 |
| Chipaca | ogra_: s/overrides/refines (sometimes with a big axe)/ | 13:40 |
| ogra_ | :) | 13:40 |
| longsleep | Chipaca: right, but could i not just write to /tmp or is that mounted to some local path all the time? | 13:40 |
| elopio | fgimenez: yes. I found the source: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/subunit/wily/view/head:/python/subunit/_output.py | 13:41 |
| Chipaca | longsleep: /tmp/ is per-process private mount of /tmp/snaps.$ID_etcetc | 13:41 |
| longsleep | Chipaca: ok - well then i stick for the persistent location for now | 13:41 |
| elopio | fgimenez: we could also call the c library from go, but it doesn't seem to have the file attach options. I think I prefer to just call this binary. | 13:41 |
| Chipaca | would having a per-appid runtime dir be enough, or do we also need to make per-appid (no rand) tmps an option? | 13:42 |
| longsleep | Chipaca: it should be similar to SNAP_APP_DATA_PATH but on tmp | 13:43 |
| longsleep | Chipaca: or on run - does not really matter | 13:43 |
| ogra_ | yeah, you want run | 13:44 |
| ogra_ | being a tmpfs by default so you have guarantees that it is clean on boot etc | 13:44 |
| ted | Generally per-appid isn't as useful as per-package | 13:44 |
| ogra_ | (and dont need to clean up etc) | 13:44 |
| ted | You could have, for instance, multiple binaries that wanted access to the same data. | 13:44 |
| Chipaca | ted: yes! i meant per package id | 13:44 |
| Chipaca | in nearly all of the above :) | 13:45 |
| Chipaca | I think the random bit was added to be careful about different forks | 13:45 |
| Chipaca | but i think those are now not going to happen? | 13:45 |
| Chipaca | in which case we could do away with it and this would just work | 13:45 |
| Chipaca | ie it's not an incompatible change | 13:45 |
| ted | I think that is an individual snap's responsibility, they own their own run/temp/etc. directories. | 13:46 |
| ted | If they don't want binaries to share, they can do that. | 13:46 |
| Chipaca | ted: yeap | 13:46 |
| Chipaca | so, two bugs: XDG_RUNTIME_DIR, and derand tmp | 13:47 |
| longsleep | Chipaca: works fine when i use SOCKET=$SNAP_APP_DATA_PATH/dotstar_socket | 13:47 |
| Chipaca | longsleep: huzzah | 13:48 |
| longsleep | Are there any thoughts on adding zram to snappy? | 13:57 |
| Chipaca | longsleep: sounds like a per-gadget thing? | 14:00 |
| longsleep | Chipaca: maybe yes - though i would consider it useful for everyone. | 14:01 |
| elopio | Chipaca: could you comment on this bug what's the status and what's missing? https://bugs.launchpad.net/snappy/+bug/1473838 | 14:02 |
| ubottu | Launchpad bug 1473838 in Snappy "can't ssh into latest snappy rolling edge" [Undecided,New] | 14:02 |
| Chipaca | elopio: the thing that should fix it got merged at r618 | 14:05 |
| Chipaca | elopio: it seems we are not shipping trunk? | 14:07 |
| Chipaca | elopio: you should have a /lib/systemd/system/snappy-wait4network.service | 14:08 |
| Chipaca | elopio: and it's not there yet | 14:08 |
| elopio | Chipaca: hum, right, I don't have that file. | 14:09 |
| elopio | where's sergio? ogra_: do you know why rolling doesn't have snappy from trunk? | 14:09 |
| Chipaca | sergio's network seems to be having a bad day | 14:11 |
| Chipaca | <elopio> where's sergio? ogra_: do you know why rolling doesn't have snappy from trunk? | 14:11 |
| Chipaca | sergiusens: ^ | 14:11 |
| sergiusens | Chipaca: I haven't been to the last 2 sprints! | 14:12 |
| Chipaca | sergiusens: but you do icky things, like talking with people | 14:12 |
| sergiusens | elopio: Chipaca I'm here, and because is fails to build, mvo has a branch but didn't create an MP last I checked. | 14:12 |
| sergiusens | Chipaca: not lately I don't | 14:12 |
| sergiusens | Chipaca: I've just catched up with what snapcraft is, it's lifecycle and what not | 14:13 |
| Chipaca | sergiusens: that's not going to get you out of being blamed for it all, you know that | 14:17 |
| elopio | sergiusens: this one? http://bazaar.launchpad.net/~mvo/snappy/snappy-fix-ftbfs7/revision/629 | 14:18 |
| * Chipaca starts an indiegogo campaign to upgrade sergiusens's network stability to ogra's, and ogra's network speed to sergiusens' | 14:19 | |
| longsleep | no commas in service description?? services description field 'Description' contains illegal 'Small, powerful, scalable web/proxy server' (legal: '^[A-Za-z0-9/. _#:-]*$') | 14:25 |
| Chipaca | longsleep: yeah | 14:27 |
| Chipaca | longsleep: i'm not sure where the restriction comes form right now. Offhand i would've said "systemd requires it", but it doesn't | 14:31 |
| lool | sergiusens: mentioned to lool: you mean how to set sysctl from kernel/platforn snaps? | 14:33 |
| lool | sergiusens: to give a bit of context, I was contributing my experience of what I saw at a customer's site as to make sure these use cases got covered somehow; you added yours, that's great; we have NOT done any design of the kernel snap/platform snap right now, I guess the closest is just mapping device tarball / gadget snap to whatever we want | 14:34 |
| lool | sergiusens: we did discuss updated boot layout, so that will influence the kernel/platform snaps | 14:34 |
| lool | also, we are trying to get a bit away from bootloader | 14:34 |
| lool | not sure how much we will manage, but a bit | 14:34 |
| lool | longsleep, ogra_:this smc thing (this is why my rpi is dropping packets!): could we fix this in the kernel properly? | 14:35 |
| lool | longsleep, ogra_: like a blacklist / hardware db in the kernel for that specific smc chip on this specific platform | 14:36 |
| lool | longsleep, ogra_: if that's possible, then I think ppisati would help us deliver a working one | 14:36 |
| lool | we could even hardcode it in a kernel specific to the rpi2 IMO, but that's not as nice as it would never go upstream | 14:36 |
| Chipaca | longsleep: we're passing all of a service's strings through the same checker, hence that error. bug 1484982. | 14:38 |
| ubottu | bug 1484982 in Snappy "service description whitelist unnecessarily strict" [Undecided,New] https://launchpad.net/bugs/1484982 | 14:38 |
| lool | ppisati: ^ see rpi smc discussion above :-) | 14:38 |
| longsleep | lool: well you can change things in the kernel only per driver right. But drivers might require different settings for a more exact hardware match while the driver might be a generic one | 14:39 |
| lool | longsleep: yup; I just don't know whether the rpi2 smc chip can be told apart from the other ones | 14:39 |
| lool | longsleep: like, it's a different device id somewhere, or it shows up with this or that registers set to this etc. | 14:40 |
| sergiusens | lool: away from the bootloader, like using our own chainloaded one (like I did when experimenting) or away completely | 14:41 |
| sergiusens | ? | 14:41 |
| longsleep | lool: yes - while i do not know so much about this particular problem for rpi, i know that for the odroid once wants to set plenty of kernel variables. Those are specific to that exact platform and will be very hard to implement in the kernel as defaults or something. | 14:41 |
| lool | sergiusens: more like chainloading and knowing as little as possible about the first one | 14:41 |
| longsleep | lool: for example binding interrupts to CPU's and such stuff | 14:41 |
| lool | longsleep: I see; we could shove these on the kernel cmdline though? | 14:42 |
| longsleep | lool: here are some examples from the odroid: http://paste.ubuntu.com/12079772/ | 14:43 |
| sergiusens | lool: well, that's what I did ;-) (using grub to multiboot to grub) | 14:43 |
| longsleep | lool: i do not know if this can be set on kernel cmdline | 14:44 |
| lool | sergiusens: I was mainly interested in killing the ARM variability TBH | 14:44 |
| lool | sergiusens: the x86 case is simlper | 14:44 |
| sergiusens | lool: right, u-boot->grub ;-) | 14:45 |
| lool | sergiusens: the main reason this came up again is with the boot layout updates and squashfs and how bootloaders vary between platforms | 14:45 |
| lool | sergiusens: yup | 14:45 |
| sergiusens | was next in the list of things to do | 14:45 |
| lool | sergiusens: totally on the same page :-) | 14:45 |
| longsleep | lool: and there is even more general stuff like http://paste.ubuntu.com/12079784/ which cannot be changed as defaults in kernel | 14:45 |
| longsleep | lool: i am pretty sure the rpi2 and other platforms require similar settings to get optimal performance | 14:46 |
| lool | longsleep: so I'm not super hot on the odroid stuff; it seems to be work load specific tweaking rather than device enablement | 14:46 |
| ogra_ | lool, well, thats a question to ppisati | 14:47 |
| longsleep | lool: yes and no - without these settings the device does not work properly - even dhcp might fail | 14:47 |
| ogra_ | you want the vm.min_free_kbytes have a bigger default | 14:47 |
| lool | longsleep: this is very generic stuff; we need a way for end devices to set these for this or that use case, but it's not platform enablement | 14:47 |
| longsleep | lool: yes technically it is not platform enablement, but some platforms require these settings to work properly | 14:48 |
| ogra_ | lool, blacklisting would mean you cant use the device indeed | 14:48 |
| lool | it would fit an admin use case or a gadget / platform use case when building a specific product (like a media center) but not the rpi or odroid enablement | 14:48 |
| lool | longsleep: ack; totally get what you mean; makes sense | 14:48 |
| lool | longsleep: it's totally in line with the use cases I brought back from a customer | 14:48 |
| lool | we need a facility for these | 14:49 |
| longsleep | lool: ok great - right now i add all this stuff into initrd to have it as early as possible so there are no problems with DHCP | 14:49 |
| ogra_ | well, editing the initred is rather bad | 14:49 |
| longsleep | lool: so please consider to make it possible to have per platform hooks in initrd. | 14:49 |
| ogra_ | sergiusens is working on having the modules outside of the initrd and loop mounted from an img file | 14:50 |
| ogra_ | i suppose we could provide something similar for platform hooks | 14:50 |
| ogra_ | without having to change the initrd binary | 14:50 |
| lool | longsleep: yeah initrd is interesting; actually I was thinking of some early boot hook instead, but initrd might be needed for some stuff | 14:57 |
| lool | it's kind of hard cause we deliver the initrd and we don't generate it on the fly | 14:57 |
| ogra_ | lool, that is fine, all the stuf sergio was working on the last weeks relates to this | 14:58 |
| ogra_ | ... single partition setup for all readonly bits, loop mounted modules ... potentially allwing other loop mounted bits etc | 14:59 |
| ppisati | lool: ok, i see you pinging but i can't find the conversation | 15:18 |
| ogra_ | ppisati, the famous revival of bug 664477 on the rpi | 15:19 |
| ubottu | bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released] https://launchpad.net/bugs/664477 | 15:19 |
| ogra_ | ppisati, can we patch the default for vm.min_free_kbytes in your build ? | 15:19 |
| ppisati | ogra_: k, i'll do | 15:19 |
| ogra_ | thx | 15:19 |
| ppisati | ogra_: i'm ats the snappy sprint | 15:19 |
| ogra_ | yeah, i know :) | 15:20 |
| ppisati | ogra_: as soon as i ends, i'll push a fix | 15:20 |
| * ppisati sets a bookmark | 15:20 | |
| ogra_ | not urgent | 15:20 |
| ogra_ | i'll only need it for the next stable release anyway ... thats still a few weeks away | 15:20 |
| ppisati | ogra_: marked | 15:21 |
| ogra_ | :) | 15:22 |
| ppisati | ogra_: and i'll probably do some more digging | 15:22 |
| ppisati | ogra_: to find the root | 15:22 |
| ogra_ | well, it is the turbo mode of the HW | 15:22 |
| ppisati | ogra_: after one week of yaml/schemas/stores/etc i NEED some kernel panics | 15:22 |
| ogra_ | iirc we dug into that ... you either disable that and it uses less ram or you keep it on and need to bump the minimal ram | 15:23 |
| ogra_ | heh, i can try to produce some for you | 15:23 |
| ppisati | ogra_: i'll probably start to package a 4.2 kernel next week | 15:24 |
| ppisati | ogra_: dunno, i cn push both so you can play with both | 15:24 |
| ogra_ | longsleep, is there a user limit in spreed-webrtc (and if so, is there a way to override that) | 15:45 |
| longsleep | ogra_: there is no limit except your bandwidth and the clients performance | 15:56 |
| longsleep | ogra_: well there is a conference size limit of 10000 hard coded in the server :) | 15:57 |
| * longsleep just have found an issue with the way he uses snapcraft :/ | 15:58 | |
| longsleep | problem is that i pull in armhf debs and run snapcraft on x86_64, snapcraft creates wrappers for stuff with x86_64-linux-gnu :( | 15:59 |
| === tai271828_ is now known as tai271828 | ||
| fgimenez | nice weekend everyone o/ | 16:12 |
| longsleep | if someone needs it, `DEB_BUILD_MULTIARCH=arm-linux-gnueabihf snapcraft ...` does the trick to create wrappers for armhf | 16:22 |
| kyrofa | sergiusens, ping | 17:45 |
| noise][ | anyone here successful in getting onewire working w/the latest rpi2 image? I'm trying to follow the instructions from ogra_ about dtoverlay in the ML post from last week, but not having any luck. | 20:11 |
| sergiusens | Chipaca: https://code.launchpad.net/~sergiusens/snapcraft/go-golang-go/+merge/268138 | 20:15 |
| ali1234 | is it possible to buld my own snappy core image? | 20:45 |
| beuno | ali1234, sure it is. You won't get updates, as they are applied through binary diffs | 20:48 |
| ali1234 | beuno: that's okay. how do i do it? | 20:48 |
| ali1234 | also, how do i generate my own binary diff updates? | 20:48 |
| beuno | ali1234, I'd ask on the mailing list, I don't really know offhand | 20:49 |
| ali1234 | i don't need a step by step guide... i just need to know where to start | 20:50 |
| ali1234 | so i build a snappy image by pointing ubuntu-device-flash at a "channel" | 21:03 |
| ali1234 | how do i make a channel? | 21:03 |
| === carlo_ is now known as Guest60105 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!