=== 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
RlyehI replaced a fresh snappy on my BBB, updated ubuntu-core 3 to 4, installed docker and then owncloud06:36
RlyehBut owncloud is still not working on port 443! http://paste.ubuntu.com/12077510/06:36
RlyehDid I missed something?06:36
=== chihchun_afk is now known as chihchun
RlyehAnyone knows how to use owncloud?!06:40
RlyehWhen 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
RlyehNo idea for owncloud?06:51
tasdomasis 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
fgimenezgood morning07:07
tasdomasmorning, fgimenez07:08
fgimenezhey tasdomas07:08
dholbachgood morning07:32
=== erkules_ is now known as erkules
tasdomasare there any service discovery solutions for snappy? Both internally (snaps discovering other snaps) and externally (other wireless devices discovering services running on snappy10:00
ogra_well, netstat is installed by default :)10:02
ogra_(nothing hiher level yet, no)10:02
pcocaHi 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
pcocahas this something to do with the setup.py?10:06
=== greyback__ is now known as greyback
longsleepQuestion - what is the preferred way to load additional kernel modules in snappy?10:25
longsleepin normal Ubuntu i just cat them at the end of /etc/modules ...10:25
ogra_you ship them in your devce tarball10:27
ogra_or gadget snap later ...10:27
longsleepno way to do this from a snap? So stuff like that always needs oem?10:28
ogra_well, kernel/device10:28
ogra_oem is bootloader only currently10:28
ogra_for now i'd just ship system/etc/modules in the device tarball10:29
longsleepyes i can do that10:29
longsleepi read through the webcam example10:29
longsleepit seems to expect that the driver for the webcam gets loaded automatically10:29
longsleepso i was wondering if there is a way for manual driver loading for other stuff10: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 hook10:31
longsleepyes that would make sense10:31
ogra_once we have snappified the device tarball side10:31
ogra_(RaspberryPi2)ubuntu@localhost:~$ df -h|grep oem10:32
ogra_/dev/sda1                     15G  813M   14G   6% /oem10:32
ogra_16G writable space :)10:32
ogra_on USB stick10:32
longsleepso what did you do?10:32
longsleepmoved 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-writable10:33
longsleepright, so snappy auto mounts stuff?10:33
ogra_well, on boot10: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 easy10:35
ogra_i just needed to test it (i want to blog about it)10:35
longsleepah ok understand10:35
longsleepany news on getting snappy to automatically expand the partition on boot?10:36
ogra_working on it :)10:36
ogra_i hope ot have that landed next week in the rolling channel10:36
* ogra_ tries some fun stuff on the side with https://github.com/paimpozhil/DockerX2go/tree/master/xubuntu10:37
longsleepi guess i should switch to whatever becomes snappy 15.10 at some point10:37
ogra_not sure there will be a snappy 15.10, currently we are backporting all backportable bits to 15.0410:38
longsleepogra_: ok - well i do not care about the version really so long as i am on the latest10:38
ogra_could well be that we directly go to 16.04 then with the next iteration of the stable channel10:38
* ogra_ knows there are some release plans ... but i cant find them atm10:39
longsleepogra_: 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
longsleepogra_: things need to read all kinds of things from /proc for example10:40
longsleepogra_: and i am currently skipping the work to create custom profiles for this and just leave it unconfined10:41
* longsleep wonders if that is a problem10:41
ogra_i think the planned sub-store setup together with the oem snap will help here10:41
ogra_in such a sub store you can break out of confinement if you want afaik10:41
ogra_since you make the rules for it10:42
ogra_dont quote me on that though :D10:42
longsleepogra_: we will try it out for sure :)10:42
longsleepogra_: 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
longsleepnot that i am going to submit those at the moment but eventually it might be nice to have10: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 there10:44
ogra_so if adjustment to the confinement policy is needed by your oem setup that should be possible10:45
* ogra_ hopes someone corrects him if he talks rubbish :)10:46
longsleepwell let me try to avoid unconfined for the next snap, though for this need to understand the assing block in the yaml10:46
longsleepbut first - lunch!10:46
ogra_enjoy !10:46
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 frames11:04
longsleepogra_: yes - i need that - currently fusing them into initrd :/11:04
ogra_such an old bug ... :/11:04
sergiusensogra_: I did sort of mentioned that to lool11:04
sergiusensogra_: I'm just waiting for the new snap formats to show up11:04
ogra_i guess it currentrly is possible via the device tarball11:05
ogra_(shipping a file in system/etc/sysctl.d/ ....)11:05
longsleepyes - that works though is too late for some settings11:05
longsleep(thats why i currently have them all in initrd hook)11:06
ubottuLaunchpad bug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released]11:07
ogra_oh, even reported in 201011:08
longsleepand that happens on rpi2 as well?11:08
ogra_it is a hardware thing11:08
longsleepah they have the same nic11:09
ogra_well, or a kernel defaults one ...11:09
ogra_depends which way you look at it :)11:09
* ogra_ files bug 148489811:14
ubottubug 1484898 in Snappy "device tarball needs to allow setting sysctl defaults" [Undecided,New] https://launchpad.net/bugs/148489811:14
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
Chipacadholbach: python-apt upstream now includes the verbosity fix11:16
longsleeparmf vs x86_6411:16
Chipacadholbach: dunno where to go from here -- resync?11:16
Chipacadholbach: that is: it's in the debian/sid branch of debian's git thing11:16
dholbachChipaca, let's wait for mvo to land it in ubuntu then11:17
dholbachhe knows which branch to merge and what to upload11:17
ogra_longsleep, yeah11:17
Chipacadholbach: okie doke11:17
=== chihchun is now known as chihchun_afk
longsleepyay snappy has 'netcat-openbsd' available - is that intentional or accident?11:46
ogra_neither :)11:48
ogra_it is inherited from the ubuntu-core seeds11:48
longsleepso 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 there11:49
longsleepall right11:49
longsleepits 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
longsleepwell i guess all the stuff from the default aa profile is pretty much solid11:50
longsleepby 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' issues11:52
ogra_i thnk i have seen that with local sideloading too11:52
ogra_might be a general race11:53
ogra_(just exposed stronger via remote)11:53
Chipacathat sounds like a bug :)11:53
longsleepit annoys me pretty hard at the moment :)11:53
ogra_Chipaca, yes, i only noticed it yesterday when playin with my broken xorg stuff11:53
Chipaca"stop" waits11:54
Chipacaand i'm pretty sure "remove" calls stop11: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
Chipacai mean, i wrote it that way :) but maybe we broke it?11:54
longsleepif that happens one has to remote the snap two more times11:55
longsleepfirst time after the error service gets not started11: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
longsleepthird time everything works fine11:55
Chipacait sounds like that is unpacking into the current directory11:56
ogra_longsleep, thats exactly the same i have seen yesterday11:56
longsleepChipaca: syslog here: http://paste.ubuntu.com/12078774/11:57
longsleep(it does not stop the service)11:57
Chipacalovely D:11:58
Chipacasideloading is treated differently, in that the usual "is installed" check is skipped12:00
Chipacabecause otherwise it slows you down (you'd have to remove the package manually before re-sideloading it)12:00
Chipacahowever that does mean it's not really expecting this error12:00
Chipacalongsleep: how reproducible is this?12:01
Chipacalongsleep: if i'm understanding the error correctly, bumping the version would "fix" it12:01
Chipacalongsleep: where i'd consider that a workaround more than a fix, but12:01
Chipacagood enough to confirm that that is what's happening12:01
Chipacai think12:01
ogra_i have seen it a lot yesterday12:02
ogra_i would say about a third of my install attempts showed it12:02
Chipacathe unpack is done before the activate/deactivate12:02
Chipacaand in fact it's done straight to the directory it'll work from12:02
Chipacawhich makes sense, as some of the checks then rely on that12:03
Chipacathe checks done before activation12:03
ogra_the directrory is gone after the failure though12:03
Chipacahowever when sideloading it's an issue12:03
ogra_something seems to wipe it12:03
Chipacawell, yes12:03
Chipacainstallation cleans up on failure12:03
Chipacaand as it's not coping with reinstallation of the same version at all12:03
Chipaca... well, i don't need to spell it out :)12:04
Chipacaso, either we block sideloading of the same version12:04
Chipacaor we cope with it properly12:04
Chipacathe current situation is a recipe for heartache12:05
ogra_it doesnt onyl happen with the same version (i need to bump the version when changing sccomp or apparmor profiles)12:05
Chipacaogra_: wat12:05
Chipacaogra_: i'd love to see the error when it's a different version!12:06
Chipacait 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 helpful12:08
ogra_(over like 4h or so)12:08
Chipacai'll write it down to you not having had lunch until i see logs :-p12:09
longsleepChipaca: it fails very time12:10
Chipacalongsleep: and if you bump the version?12:10
longsleeplet me try12:10
longsleepthat should work i assume12:11
Chipacait failing in a different way would be interesting12:11
ogra_(RaspberryPi2)ubuntu@localhost:~$ sudo ls -lh /var/log/syslog12:11
ogra_-rw-r----- 1 syslog adm 13M Aug 14 12:10 /var/log/syslog12:11
Chipacait 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
longsleepChipaca: did not fail but now it runs twice :)12:12
longsleepChipaca: the old version still runs12:12
Chipacalongsleep: ok12:12
Chipacalongsleep: where it says "ok", read it in a tone of voice that implies serious non-OKness12:12
Chipacalongsleep: how do you stop your service?12:13
longsleepChipaca: i let systemd take care of it12:13
longsleepChipaca: i assume it just kills it12:13
Chipacait should12:13
Chipacawhat's going on12:13
Chipacalongsleep: what does systemctl status tell you?12:13
longsleepfrom what i see in the logs, the old service never was stopped12:15
Chipacaand 'systemctl stop dotstar-leds_dotstar_0.0.1-1.service' just works, yes?12:15
Chipacadammit, i can't blame it on you :-)12:16
Chipacai'll file a bug, in penance12:16
longsleepthanks :)12:16
ubottuLaunchpad bug 1484922 in Snappy "Sideloading a snap with a service does not stop the service of the old version" [Undecided,New]12:17
Chipacanow let's see if i can reproduce it12:18
longsleepbtw the reason my system is marged as degrated is none of my snaps but rather webdm because of bug 146667212:18
ubottubug 1466672 in Snappy 15.04 "webdm failed to start / Failed to listen" [Undecided,New] https://launchpad.net/bugs/146667212:18
Chipacadegraded means a unit failed12:21
Chipacasergiusens: you around?12:21
longsleepbtw 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 hackery12:23
sergiusensChipaca: yeah12:26
Chipacasergiusens: what's blocking https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 do you know/remember?12:27
Chipacalongsleep: so, i can't reproduce the issue with snappy from wily edge. you're on 15.04 stable?12:28
sergiusensChipaca: me12:28
* Chipaca hugs sergiusens 12:28
longsleepChipaca: yes12:28
longsleepChipaca: version 4 from stable channel12:29
Chipacalongsleep: 1.4?12:30
Chipacaoh, wait12:30
Chipacathis is not that12:30
* Chipaca starts another kvm12:30
longsleepChipaca: ubuntu-core   2015-07-29 4        ubuntu12:30
longsleepChipaca: channel: ubuntu-core/15.04/stable12:31
Chipacayep yep12:31
Chipacathe 1504 i had was something else :)12:31
Chipacalongsleep: also can't reproduce it with 15.04 rev 412:35
Chipacalongsleep: using the python xkcd webserver snap12:35
longsleepChipaca: do you have a service which is a binary file?12:35
Chipacathat's next12:35
longsleepi think text files can always be replaced12:35
longsleepbut at least your service should run twice when you update to a new sideloaded version12:36
longsleep(if that service can be run twice)12:36
Chipacalongsleep: this is with a different version, so replacing file should not be an issue12:37
Chipacaexactly, it's the running twice thing that i was trying for12:37
longsleepChipaca: could be also related to snappy-remote - i am running 0.4-0ubuntu1build1 on trusty12:43
Chipacais snappy-remote anything other than something that ssh's in and runns snappy with all the given args?12:43
sergiusenslongsleep: Chipaca snappy-remote just uses the snappy binary on the host12:43
Chipacai imagin it as a two-line shellscript12:44
sergiusensthe problem is in snappy itself12:44
sergiusensChipaca: dream all you want :-P12:44
Chipacasergiusens: :)12:44
Chipacasergiusens: see, if instead of having an option for the host you took it from environ, you could've made it a oneliner :-p12:45
Chipacassh ${SNAPPY_REMOTE_HOST:?Set SNAPPY_REMOTE_HOST to what to ssh to} -- "$@"12:45
Chipacadone \o/12:46
Chipacaoh, add a "snappy" before the $@12:46
* Chipaca does not have enough :-P to sprinkle into that12:46
Chipacathe go-example-webserver in snappy-examples is broken \o/12:48
Chipacaah, maybe i need to build it properly :-)12:49
Chipacapicky, pikcy12:49
Chipacai wonder if this is something on arm only?12:52
longsleepChipaca: that example is also problematic as it will fail to run twice12:53
Chipacabecause on amd64 i can't get it to break12:53
longsleep(becasue of port already in use)12:53
Chipacalongsleep: ah!12:53
* longsleep has problems with the order of letters today12:53
* Chipaca adds a ports section12:54
longsleepChipaca: well with the go service you should get the text file busy problem12:54
Chipacalongsleep: not with different versions12:55
Chipacait's two separate issues12:55
Chipacathe text file busy one is due to how we (don't) handle sideloading of the same version12:55
longsleepreally? Why - if the service would stop there would be no text file busy problem12:55
Chipacathe two services of different versions of the same app is really worrying12:55
Chipacalongsleep: on install, first we unpack, then we do some checks, then we stop the old version and start the new one12:56
longsleepChipaca: ah ok12:56
Chipacalongsleep: :)12:56
Chipacalongsleep: so one workaround for that would be to, on sideload, stop before unpack12:59
Chipacalongsleep: because sideload install is not going to happen automatically, so the downtime is more tolerable12:59
Chipacamaybe also don't clean up on sideload install failure12:59
Chipacaslightly uncomfortable about making the two so different though13:00
Chipacarsalveti: sergiusens: opinion about ^?13:00
elopiogood morning.13:03
sergiusensChipaca: I thought we wanted to kill the version on sideload installs and just create a hash13:04
Chipacawe did? i have no memory of that13:05
Chipacabut that does not mean we didn't :)13:05
sergiusensChipaca: maybe you weren't there :-P13:06
sergiusensChipaca: but the version is meaningless and this sort of solves people accidentally hardcoding stuff during development13:07
Chipacalongsleep: can i have a pastebin of you doing the snappy remote of an updated version that resulted in two services running, please?13:13
longsleepChipaca: i do not know why, but now it did stop the old service when i installed a new version13:13
Chipacalongsleep: ok13:13
longsleepChipaca: it might be related to the failure before13:13
Chipacalongsleep: so, how about this13:13
longsleeplet me try to reproduce13:13
Chipacalongsleep: you tried to install the same thing13:13
Chipacalongsleep: it aborted because of text file thing13:13
Chipacalongsleep: but cleaned up -- removed files13:13
Chipacalongsleep: service still running, because who cares the file was rm'13:14
longsleeplet me try - should be easy to replicate13:14
Chipacalongsleep: installed, snappy did not find old thing, did not try to disable service13:14
Chipacaso that would result in two services13:14
Chipacaas a consecuence of the text file thing13:14
longsleepmost likely yes13:14
Chipacawithout it being a whole separate problem13:14
longsleepi am on it13:14
Chipacathank you13:14
longsleepstarting from clean state now13:15
elopiofgimenez: 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
longsleepChipaca: yes it just failed to install, removed the stuff and the service is still running13:16
longsleepos i see the process and the file is gone13:16
Chipacathat makes sense13:17
longsleepChipaca: yes reproduced - it only runs twice when the text file busy error happend13:17
elopiofgimenez: let me know when you are done with the parsing and I can start piping the subunit output to a file.13:17
Chipacalongsleep: that's a relief :) thank you!13:17
fgimenezelopio: great, only the binary encoding is missing13:17
Chipacalongsleep: it does make fixing the text file thing in stable more important13:17
Chipacasergiusens: do we want to do the version hash thing in stable? or just workaround this there?13:18
longsleepChipaca: yes - for development this can result in all kind of issues13:18
fgimenezelopio: there's already a file step in the pipeline, we can remove it if needed13:18
Chipacalongsleep: for the time being, can you include 'snappy-remote yadda yadda remove the thing' before a same-version install?13:19
longsleepChipaca: sure13:19
Chipacasnappy-remote --url=ssh:// remove dotstar-leds && snappy-remote --url=ssh:// install dotstar-leds_0.0.1-1_armhf.snap13:19
Chipacaor sth like that :)13:19
longsleepyeah should do the trick13:20
longsleeplet me try13:20
longsleepUnknown command `remove'. You should use the install command13:20
Chipacasergiusens: wat ^13:21
* Chipaca no habla snappy-remote13:21
ogra_its just a two linne shellscript13:21
Chipacathat's my mental model of it!13:21
Chipacaand if it were, that would've worked13:21
Chipacaso my mental model needs updating :)13:21
elopiofgimenez: 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
Chipacaogra_: tomeito, tomahto13:23
fgimenezelopio: yep, that should connect with the binary encoder in its next field13:23
Chipacasnappy-remote *only* knows install13:23
Chipacalongsleep: how about: ssh ubuntu@ sudo snappy remove dotstar-leds && snappy-remote --url=ssh:// install dotstar-leds_0.0.1-1_armhf.snap13:24
fgimenezelopio: and the binary encoder with the file, or stdout, in the next field13:24
* Chipaca does not know if snappy-remote keeps keys in a nonstandard place, but maybe that'll work :)13:24
longsleepChipaca: sure13:25
longsleepChipaca: that works just fine13:26
longsleepthough i found another issue with that snap .. :/13:27
longsleepproblem is that SNAP_APP_TMPDIR=/tmp13:27
longsleepwhere it should be export TMPDIR="/tmp/snaps/dotstar-leds.sideload/0.0.1-3/tmp"13:27
Chipacalongsleep: are you sure?13:28
Chipacai thought stable already had the private tmp fix?13:28
fgimenezelopio: not sure if the binary encoding step is a must13:28
longsleepChipaca: yeah try hello-world.env13:28
elopiofgimenez: 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
Chipacalongsleep: sure, let me check13:28
Chipacalongsleep: stable already has the private /tmp fix13:28
Chipacalongsleep: all of /tmp is yours13:28
Chipacalongsleep: and /tmp will be actually a private mount of /tmp/snap.$UID_$APPID_$RANDOM13:29
longsleepmhm i write stuff here SOCKET=$SNAP_APP_TMPDIR/dotstar_socket into the service13:29
Chipacalongsleep: so if you look at /tmp you should see a bunch of "snap.0_somthing.sideload_Xyws/13:29
longsleepfrom the service i mean13:29
longsleepChipaca: yes i see them13:29
Chipacalongsleep: whereas the old tmpfile was /tmp/snaps/13:29
longsleepwriting them from the service works fine13:29
Chipacalongsleep: so you'd see /tmp/snaps13:29
Chipacalongsleep: now13:30
longsleepbut in the binary tmp points just to /tmp13:30
longsleepwhich does find nothing13:30
Chipacalongsleep: we do still set /tmp/snaps, for backwards compat, so that would be /tmp/snap.0_something.sideload_yadda/tmp/snaps/something.sideload/version/tmp13:30
Chipacalongsleep: ah, you mean SNAP_APP_TMPDIR is different in the service and in the binary?13:32
Chipacathat is entirely possible :-(13:33
longsleephold on i am trying clean setup13:33
Chipacalongsleep: um13:33
Chipacalongsleep: are you expecting to find the same things in tmp from both service and binary?13:33
Chipacabecause it'll be a _different_ tmpdir every time13:33
longsleepChipaca: yes13:33
longsleepwell, then i got a problem :)13:34
Chipacalongsleep: tell me more13:34
longsleepChipaca: service creates a unix socket file13:34
longsleepChipaca: i need that socket location from a binary13:35
Chipacalongsleep: $SNAP_APP_DATA_PATH ?13:35
fgimenezelopio: whatever works :), where can i read about subunit-output?13:35
longsleepChipaca: i would prefer if that file is not persistent13:35
elopiofgimenez: sudo apt-get install subunit-output13:35
elopiosubunit-output -h13:35
longsleepChipaca: i thought there is a per snap temp folder13:36
elopiofgimenez: it even allows to attach files to the results.13:36
Chipacalongsleep: 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
longsleepChipaca: what is how i understood the name SNAP_APP_TMPDIR13:36
Chipacated: ^^^ there you go, a use case :)13:36
* ted reads backlog for this "use case" ;-)13:36
tedYeah, for something like that you probably want something per-snap in /run13:37
longsleepted: yes - though that does not seem to exist13:37
Chipacated: yes, for socket you want a XDG_RUNTIME_DIR thing13:37
Chipacated: but you see my point about getting at the same data from service and binary?13:38
tedYes, so I think that you want USER for things running as a user. But that is still useless for services.13:38
Chipacasergiusens: you've been in more snappy sprints than I :) anything planned or thought on runtime dir?13:39
tedIt 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
Chipacalongsleep: to unblock you right now, sadly, i don't have a better answer than (ab)using the data dir13:39
fgimenezelopio: ok thx looks very good, we can pipe to a exec.Command easily13:39
Chipacaogra_: s/overrides/refines (sometimes with a big axe)/13:40
longsleepChipaca: right, but could i not just write to /tmp or is that mounted to some local path all the time?13:40
elopiofgimenez: yes. I found the source: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/subunit/wily/view/head:/python/subunit/_output.py13:41
Chipacalongsleep: /tmp/ is per-process private mount of /tmp/snaps.$ID_etcetc13:41
longsleepChipaca: ok - well then i stick for the persistent location for now13:41
elopiofgimenez: 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
Chipacawould having a per-appid runtime dir be enough, or do we also need to make per-appid (no rand) tmps an option?13:42
longsleepChipaca: it should be similar to SNAP_APP_DATA_PATH but on tmp13:43
longsleepChipaca: or on run - does not really matter13:43
ogra_yeah, you want run13:44
ogra_being a tmpfs by default so you have guarantees that it is clean on boot etc13:44
tedGenerally per-appid isn't as useful as per-package13:44
ogra_(and dont need to clean up etc)13:44
tedYou could have, for instance, multiple binaries that wanted access to the same data.13:44
Chipacated: yes! i meant per package id13:44
Chipacain nearly all of the above :)13:45
ChipacaI think the random bit was added to be careful about different forks13:45
Chipacabut i think those are now not going to happen?13:45
Chipacain which case we could do away with it and this would just work13:45
Chipacaie it's not an incompatible change13:45
tedI think that is an individual snap's responsibility, they own their own run/temp/etc. directories.13:46
tedIf they don't want binaries to share, they can do that.13:46
Chipacated: yeap13:46
Chipacaso, two bugs: XDG_RUNTIME_DIR, and derand tmp13:47
longsleepChipaca: works fine when i use SOCKET=$SNAP_APP_DATA_PATH/dotstar_socket13:47
Chipacalongsleep: huzzah13:48
longsleepAre there any thoughts on adding zram to snappy?13:57
Chipacalongsleep: sounds like a per-gadget thing?14:00
longsleepChipaca: maybe yes - though i would consider it useful for everyone.14:01
elopioChipaca: could you comment on this bug what's the status and what's missing? https://bugs.launchpad.net/snappy/+bug/147383814:02
ubottuLaunchpad bug 1473838 in Snappy "can't ssh into latest snappy rolling edge" [Undecided,New]14:02
Chipacaelopio: the thing that should fix it got merged at r61814:05
Chipacaelopio: it seems we are not shipping trunk?14:07
Chipacaelopio: you should have a /lib/systemd/system/snappy-wait4network.service14:08
Chipacaelopio: and it's not there yet14:08
elopioChipaca: hum, right, I don't have that file.14:09
elopiowhere's sergio? ogra_: do you know why rolling doesn't have snappy from trunk?14:09
Chipacasergio's network seems to be having a bad day14:11
Chipaca<elopio> where's sergio? ogra_: do you know why rolling doesn't have snappy from trunk?14:11
Chipacasergiusens: ^14:11
sergiusensChipaca: I haven't been to the last 2 sprints!14:12
Chipacasergiusens: but you do icky things, like talking with people14:12
sergiusenselopio: 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
sergiusensChipaca: not lately I don't14:12
sergiusensChipaca: I've just catched up with what snapcraft is, it's lifecycle and what not14:13
Chipacasergiusens: that's not going to get you out of being blamed for it all, you know that14:17
elopiosergiusens: this one? http://bazaar.launchpad.net/~mvo/snappy/snappy-fix-ftbfs7/revision/62914:18
* Chipaca starts an indiegogo campaign to upgrade sergiusens's network stability to ogra's, and ogra's network speed to sergiusens'14:19
longsleepno commas in service description?? services description field 'Description' contains illegal 'Small, powerful, scalable web/proxy server' (legal: '^[A-Za-z0-9/. _#:-]*$')14:25
Chipacalongsleep: yeah14:27
Chipacalongsleep: i'm not sure where the restriction comes form right now. Offhand i would've said "systemd requires it", but it doesn't14:31
loolsergiusens: mentioned to lool: you mean how to set sysctl from kernel/platforn snaps?14:33
loolsergiusens: 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 want14:34
loolsergiusens: we did discuss updated boot layout, so that will influence the kernel/platform snaps14:34
loolalso, we are trying to get a bit away from bootloader14:34
loolnot sure how much we will manage, but a bit14:34
loollongsleep, ogra_:this smc thing (this is why my rpi is dropping packets!): could we fix this in the kernel properly?14:35
loollongsleep, ogra_: like a blacklist / hardware db in the kernel for that specific smc chip on this specific platform14:36
loollongsleep, ogra_: if that's possible, then I think ppisati would help us deliver a working one14:36
loolwe could even hardcode it in a kernel specific to the rpi2 IMO, but that's not as nice as it would never go upstream14:36
Chipacalongsleep: we're passing all of a service's strings through the same checker, hence that error. bug 1484982.14:38
ubottubug 1484982 in Snappy "service description whitelist unnecessarily strict" [Undecided,New] https://launchpad.net/bugs/148498214:38
loolppisati: ^ see rpi smc discussion above  :-)14:38
longsleeplool: 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 one14:39
loollongsleep: yup; I just don't know whether the rpi2 smc chip can be told apart from the other ones14:39
loollongsleep: like, it's a different device id somewhere, or it shows up with this or that registers set to this etc.14:40
sergiusenslool: away from the bootloader, like using our own chainloaded one (like I did when experimenting) or away completely14:41
longsleeplool: 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
loolsergiusens: more like chainloading and knowing as little as possible about the first one14:41
longsleeplool: for example binding interrupts to CPU's and such stuff14:41
loollongsleep: I see; we could shove these on the kernel cmdline though?14:42
longsleeplool: here are some examples from the odroid: http://paste.ubuntu.com/12079772/14:43
sergiusenslool: well, that's what I did ;-) (using grub to multiboot to grub)14:43
longsleeplool: i do not know if this can be set on kernel cmdline14:44
loolsergiusens: I was mainly interested in killing the ARM variability TBH14:44
loolsergiusens: the x86 case is simlper14:44
sergiusenslool: right, u-boot->grub ;-)14:45
loolsergiusens: the main reason this came up again is with the boot layout updates and squashfs and how bootloaders vary between platforms14:45
loolsergiusens: yup14:45
sergiusenswas next in the list of things to do14:45
loolsergiusens: totally on the same page  :-)14:45
longsleeplool: and there is even more general stuff like http://paste.ubuntu.com/12079784/ which cannot be changed as defaults in kernel14:45
longsleeplool: i am pretty sure the rpi2 and other platforms require similar settings to get optimal performance14:46
loollongsleep: so I'm not super hot on the odroid stuff; it seems to be work load specific tweaking rather than device enablement14:46
ogra_lool, well, thats a question to ppisati14:47
longsleeplool: yes and no - without these settings the device does not work properly - even dhcp might fail14:47
ogra_you want the vm.min_free_kbytes have a bigger default14:47
loollongsleep: 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 enablement14:47
longsleeplool: yes technically it is not platform enablement, but some platforms require these settings to work properly14:48
ogra_lool, blacklisting would mean you cant use the device indeed14:48
loolit 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 enablement14:48
loollongsleep: ack; totally get what you mean; makes sense14:48
loollongsleep: it's totally in line with the use cases I brought back from a customer14:48
loolwe need a facility for these14:49
longsleeplool: ok great - right now i add all this stuff into initrd to have it as early as possible so there are no problems with DHCP14:49
ogra_well, editing the initred is rather bad14:49
longsleeplool: 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 file14:50
ogra_i suppose we could provide something similar for platform hooks14:50
ogra_without having to change the initrd binary14:50
loollongsleep: yeah initrd is interesting; actually I was thinking of some early boot hook instead, but initrd might be needed for some stuff14:57
loolit's kind of hard cause we deliver the initrd and we don't generate it on the fly14:57
ogra_lool, that is fine, all the stuf sergio was working on the last weeks relates to this14:58
ogra_... single partition setup for all readonly bits, loop mounted modules ... potentially allwing other loop mounted bits etc14:59
ppisatilool: ok, i see you pinging but i can't find the conversation15:18
ogra_ppisati, the famous revival of bug 664477 on the rpi15:19
ubottubug 664477 in Linaro Linux "System hangs due to cascade of smsc95xx errors " [Medium,Fix released] https://launchpad.net/bugs/66447715:19
ogra_ppisati, can we patch the default for vm.min_free_kbytes in your build ?15:19
ppisatiogra_: k, i'll do15:19
ppisatiogra_: i'm ats the snappy sprint15:19
ogra_yeah, i know :)15:20
ppisatiogra_: as soon as i ends, i'll push a fix15:20
* ppisati sets a bookmark15:20
ogra_not urgent15:20
ogra_i'll only need it for the next stable release anyway ... thats still a few weeks away15:20
ppisatiogra_: marked15:21
ppisatiogra_: and i'll probably do some more digging15:22
ppisatiogra_: to find the root15:22
ogra_well, it is the turbo mode of the HW15:22
ppisatiogra_: after one week of yaml/schemas/stores/etc i NEED some kernel panics15: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 ram15:23
ogra_heh, i can try to produce some for you15:23
ppisatiogra_: i'll probably start to package a 4.2 kernel next week15:24
ppisatiogra_: dunno, i cn push both so you can play with both15:24
ogra_longsleep, is there a user limit in spreed-webrtc (and if so, is there a way to override that)15:45
longsleepogra_: there is no limit except your bandwidth and the clients performance15:56
longsleepogra_: 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
longsleepproblem 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
fgimeneznice weekend everyone o/16:12
longsleepif someone needs it, `DEB_BUILD_MULTIARCH=arm-linux-gnueabihf snapcraft ...` does the trick to create wrappers for armhf16:22
kyrofasergiusens, ping17: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
sergiusensChipaca: https://code.launchpad.net/~sergiusens/snapcraft/go-golang-go/+merge/26813820:15
ali1234is it possible to buld my own snappy core image?20:45
beunoali1234, sure it is. You won't get updates, as they are applied through binary diffs20:48
ali1234beuno: that's okay. how do i do it?20:48
ali1234also, how do i generate my own binary diff updates?20:48
beunoali1234, I'd ask on the mailing list, I don't really know offhand20:49
ali1234i don't need a step by step guide... i just need to know where to start20:50
ali1234so i build a snappy image by pointing ubuntu-device-flash at a "channel"21:03
ali1234how 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!