| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| seshu | hello | 06:36 |
|---|---|---|
| zyga | good morning | 06:55 |
| dholbach | good morning | 07:06 |
| fgimenez | good morning | 07:09 |
| === zbenjamin_ is now known as zbenjamin | ||
| === chihchun is now known as chihchun_afk | ||
| dholbach | mvo, hey hey | 07:40 |
| dholbach | can you kick off a build of https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily? | 07:40 |
| dholbach | why is it not set to automatic? | 07:40 |
| dholbach | or daily | 07:41 |
| dholbach | or whatever the setting is | 07:41 |
| mvo | dholbach: sure, let me check why its not automatic | 07:43 |
| dholbach | <3 | 07:43 |
| mvo | fixed and triggered a new build | 07:44 |
| dholbach | mvo, https://code.launchpad.net/~dholbach/snapcraft/build-deps-syntax/+merge/269853 | 07:48 |
| * mvo hugs dholbach | 07:50 | |
| ogra_ | ppisati, mind to take a look at bug 1491094 ? | 07:50 |
| ubottu | bug 1491094 in linux (Ubuntu) "wifi USB dongle fails to work with musb-hdrc error" [Undecided,Incomplete] https://launchpad.net/bugs/1491094 | 07:50 |
| dholbach | mvo, once it's merged we can try to build the branch again ;-) | 07:51 |
| ppisati | ogra_: BBB? or rpi2? | 07:51 |
| ppisati | ogra_: i guess the first | 07:52 |
| dholbach | mvo, merged | 07:52 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | ppisati, yeah ... | 07:56 |
| ogra_ | ppisati, sadly rick seems to be back on US timezone, so it might take a bit to get a full syslog | 07:56 |
| ppisati | ogra_: do you know if he receive just a single warning or more than one? | 08:04 |
| Chipaca | *yawn* | 08:05 |
| Chipaca | mo'in people | 08:06 |
| ogra_ | ppisati, i had him re-plug it a few times and he said thats all that is printed in syslo | 08:09 |
| ogra_ | g | 08:09 |
| ppisati | ogra_: so just a single warning, i guess | 08:10 |
| ogra_ | as i understand it it should use the rt2800usb ... but seems the kernel doesnt even get that far | 08:10 |
| ogra_ | (we also tried plugging with the module manually loaded which according to rick made no difference at all ... ) | 08:11 |
| ppisati | and on a x6 box, it worked, right? | 08:12 |
| ppisati | testing on a vivid kernel would be awesome | 08:13 |
| ogra_ | i thinnk so ... | 08:13 |
| ppisati | *x86 | 08:13 |
| ppisati | let me add some comments to the lp bug | 08:13 |
| ogra_ | cool, thanks | 08:13 |
| ppisati | this thing | 08:13 |
| ppisati | "Product: Љ" | 08:13 |
| ppisati | this is particularli scary | 08:13 |
| ogra_ | thats minicom i bet | 08:13 |
| ogra_ | (getting the actual syslog would likely help a lot) | 08:14 |
| ogra_ | ppisati, there is another bug where your input might help ... bug 1489412 | 08:15 |
| ubottu | bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412 | 08:15 |
| ogra_ | i'm notz really sure what to do with it ... turning off turbo mode on the NIC seems to help a little, but doesnt make the issue go away | 08:15 |
| ppisati | ogra_: so, about the smsc9xx there | 08:17 |
| ppisati | ogra_: i spinned a new kernel with min_free = 32k | 08:17 |
| ppisati | and i rebased on the latest 3.19 stable | 08:17 |
| ppisati | ogra_: but i didn't update the meta yet | 08:17 |
| ogra_ | ah, cool, i'll make sure to pull that in for 15.04.3 | 08:17 |
| ppisati | ogra_: when is the release? | 08:17 |
| ogra_ | my script doesnt use the meta, it just pulls the newest binary kernel from your PPA | 08:18 |
| ogra_ | not sure | 08:18 |
| ogra_ | mvo, do we have some schedule for 15.04.3 ? | 08:18 |
| ogra_ | or ETA | 08:19 |
| mvo | ogra_: I'm not aware of one | 08:21 |
| ogra_ | ppisati, so the debian way then :) when its ready | 08:21 |
| ppisati | :( | 08:21 |
| ppisati | i would like to have some testing before we mass deploy | 08:22 |
| ppisati | you know... | 08:22 |
| ogra_ | (which means if you want something specifically, we can hold it back for that) | 08:22 |
| ogra_ | well, we can indeed ask for testing and haven people use the 15.04 edge channel | 08:23 |
| ppisati | about the first bug, i have a match for that usb vendor/product id on a 4.2 wily kernel: | 08:29 |
| ppisati | drivers/net/wireless/mediatek/mt7601u/usb.c: { USB_DEVICE(0x148f, 0x7601) }, | 08:29 |
| ppisati | but i don't have that match on 3.19 | 08:29 |
| ppisati | and | 08:30 |
| ppisati | Documentation/usb/hotplug.txt: USB_DEVICE (vendorId, productId) | 08:30 |
| ogra_ | ah | 08:32 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 | 08:57 |
| === greyback__ is now known as greyback | ||
| dholbach | hey rsalveti, I was playing around with snapcraft a bit more - do you think I should triage the list of open bugs right now and tag the ones which have to do with first user experience or something, so we can have all of them in one list? if yes, which name should we use? | 09:47 |
| dholbach | mvo, ^ too | 09:47 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 is a quick fix I could do myself :) | 09:47 |
| === chihchun is now known as chihchun_afk | ||
| guest42315 | Snappy Ubuntu Core on Banana Pi BPI-M2 http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432 | 10:00 |
| ogra_ | guest42315, nice ! | 10:23 |
| Chipaca | pitti: script -qfc | 10:33 |
| pitti | Chipaca: heh, nice trick! do you know how much overhead that has? | 10:39 |
| Chipaca | pitti: about 23 | 10:39 |
| Chipaca | maybe 24 | 10:39 |
| pitti | I mean per line/read/block | 10:39 |
| pitti | (what's that unit?) | 10:39 |
| Chipaca | pitti: sorry, i was being mean. I have no idea of overhead, but I don't think it's much. It does create a file. | 10:40 |
| pitti | script -qfc "sh -c 'sleep 30 & echo payload'" /dev/null |cat | 10:40 |
| pitti | even that works | 10:40 |
| pitti | but this unifies stdout and stderr, doesn't it? | 10:40 |
| Chipaca | hm, probably | 10:41 |
| Chipaca | is that bad? | 10:41 |
| pitti | ah yes, it does | 10:41 |
| pitti | I need to keep them separate/intact, yes | 10:41 |
| pitti | but it's a nice trick anyway for other use cases, much simpler than using redirection and tail -f | 10:42 |
| pitti | and having to clean up tail | 10:42 |
| === chihchun_afk is now known as chihchun | ||
| pitti | so thanks for the trick! | 10:42 |
| Chipaca | pitti: and if you take it deeper? | 10:43 |
| Chipaca | pitti: e.g. script -qfc '1>stdout 2>stderr commands here' | 10:43 |
| pitti | I played around with exec, redirections, fifos, bash's <(command) all morning; it's ridiculously difficult | 10:44 |
| pitti | Chipaca: yeah, and then tail -f them both; that's what autopkgtest does on the "outside", as that only needs to be set up once per test | 10:44 |
| pitti | but once for every single command is heavier (and also it's brittle as hell), so I was hoping there was something simpler | 10:44 |
| Chipaca | ah, you probably also want -e, to get the exit code of the process | 10:45 |
| pitti | it took me two months or so to get that "background tail -f" robust enough, and it's still far from perfect | 10:45 |
| Chipaca | pitti: are you ssh'ing in, or how are you running these things? | 10:45 |
| pitti | Chipaca: depends on the backend; "schroot", "lxc-attach", "ssh", or via a socket for Qemu's case (serial console) | 10:45 |
| Chipaca | uff | 10:46 |
| Chipaca | pitti: for ssh, a simple -t works | 10:47 |
| Chipaca | ie ssh -t yadda yadda | 10:47 |
| Chipaca | pitti: what you want is to have a tty | 10:47 |
| pitti | right, with PTYs there's no problem | 10:47 |
| Chipaca | pitti: but it's simple enough, i think, in C | 10:48 |
| Chipaca | pitti: so maybe you need to write a little C :) | 10:48 |
| pitti | yeah, in C it wouldn't be a problem at all | 10:48 |
| pitti | just that I can't assume that I'm able to compile anything on the target | 10:48 |
| Chipaca | then write C :) | 10:48 |
| pitti | my testbed could be a read-only phone or snappy without even a compiler | 10:48 |
| Chipaca | pitti: it's standard library C; you can cross-compile it without breaking a sweat | 10:49 |
| pitti | Chipaca: well, setting that up (lots of C code and making autopkgtest depend on lots of cross compilers and dynamically shoveling binaries to the testbed) sounds a lot harder than my ugly 15 lines of "kill leftover processes" shell hack :/ | 10:50 |
| Chipaca | arm-linux-gnueabihf-gcc-4.9 -Wall -o blah blah.c && scp/put/cp/whatevs && etc | 10:50 |
| pitti | maybe perl | 10:50 |
| pitti | perl-base is still essential | 10:50 |
| Chipaca | pitti: I'd expect you to say that two months ago, before spending two months on tail :) | 10:50 |
| ogra_ | pitti, store the PIDs in a file and loop over it with kill when the parent dies ? | 10:50 |
| ogra_ | via a trap cleanup command ... | 10:51 |
| Chipaca | pitti: perl works, also, i think | 10:51 |
| pitti | anyway, quite a number of people have answered, and I found some related discussions on various forums | 10:51 |
| pitti | so at least I'm now reasonably sure that I wasn't missing something obvious | 10:51 |
| Chipaca | ogra_: you'd have to strace -f to grab all the clones & forks | 10:52 |
| ogra_ | Chipaca, well, or just start everything through a wrapper function | 10:53 |
| Chipaca | pitti: "try" from libio-pty-perl's examples is probably a good place to start | 11:03 |
| Chipaca | anyway. to lunch. | 11:10 |
| ogra_ | ogra@anubis:~/datengrab/images/snappy$ sudo ubuntu-device-flash core --channel edge --device device-pi2-0.16.tar.xz --oem pi2.canonical --developer-mode --install webdm -o kvm-rolling.img rolling | 12:04 |
| ogra_ | [sudo] password for ogra: | 12:04 |
| ogra_ | WARNING: this option should only be used to build azure images | 12:04 |
| ogra_ | Determining oem configuration | 12:04 |
| ogra_ | great ... | 12:04 |
| ogra_ | now if it could tell me *WHICH* option "this option" is :P | 12:04 |
| ogra_ | ah, obviously --device ... | 12:06 |
| tbr | debug output is overrated | 12:12 |
| ogra_ | heh | 12:16 |
| rickspencer3 | hey, is there an easy way to change the channel that my bbb is on? | 12:26 |
| rickspencer3 | I think I'd like to get daily updates on it | 12:26 |
| ogra_ | rickspencer3, no idea if that works ... but try system-image-cli --switch (with a lot of -vvv to increase verbosity) | 12:29 |
| * rickspencer3 tries | 12:29 | |
| ogra_ | i guess switching channels will become easier as soon as we dropped system-image | 12:30 |
| rickspencer3 | ogra_, does it not need an argument for the channel to switch to? | 12:30 |
| ogra_ | sure, like on the phone | 12:30 |
| ogra_ | (up to you want you want to switch to) | 12:30 |
| rickspencer3 | ogra_, so, I want to switch to 15.04 edge, is there somewhere that shows me how to formulate that argument? | 12:31 |
| ogra_ | ubuntu-core/15.04/edge ... | 12:32 |
| ogra_ | note that this channel is on manual though | 12:32 |
| ogra_ | only gets builds if we upload changes to the PPA or before a release | 12:32 |
| rickspencer3 | manual is good for edge, I think | 12:32 |
| rickspencer3 | ogra_, oh, is there a better channel if I want to test latest bug fixes, etc...? | 12:33 |
| Chipaca | fwiw, channel switching is Not Supported | 12:33 |
| ogra_ | wily ... ubuntu-core/rolling/edge ... that has daily builds but also the highest chance of breaking | 12:33 |
| ogra_ | Chipaca, i think it worked for me last time on RPi ... but cant roll back or some such | 12:34 |
| rickspencer3 | ogra_, so, the argument is ubuntu-core/rolling/edge ? | 12:34 |
| ogra_ | yes | 12:34 |
| Chipaca | i'm not saying it won't work; i'm saying if it works, huzzah, but if it breaks oh well :) | 12:34 |
| ogra_ | yeah | 12:34 |
| rickspencer3 | and it will get automatically update each day, and maybe break a lot? | 12:35 |
| ogra_ | i dont remember what was broken on my RPi test ... but iirc it initially worked ... and either didnt upgrade or didnt roll back anymore | 12:35 |
| rickspencer3 | I guess I can just get another sd card and put a more stable version on it :) | 12:35 |
| ogra_ | yeah | 12:35 |
| rickspencer3 | looks like it is trying to upgrade it :) | 12:35 |
| rickspencer3 | [systemimage] Sep 02 12:35:29 2015 (1239) Upgrade path is 155 :) | 12:36 |
| rickspencer3 | (note the ":)" is mine | 12:36 |
| ogra_ | well, we should add more smileys to log output :) | 12:36 |
| ogra_ | you could then also indicate error severity through them ;) | 12:37 |
| ogra_ | :/ <- bad ... :( <- severely bad ... X( <- totally dead | 12:38 |
| rickspencer3 | ogra_, that would be brilliant | 12:39 |
| rickspencer3 | or just emojis | 12:39 |
| rickspencer3 | says it is rebooting, I'll take that as a good sign | 12:39 |
| ogra_ | well, UTF8 is often broken in serial terminal apps :) | 12:39 |
| ogra_ | but yeah, emojis would rock | 12:39 |
| rickspencer3 | emoticons it is, let's get the spec started ;) | 12:39 |
| rickspencer3 | well, it didn't reboot itself | 12:42 |
| * rickspencer3 reboots, braces for impact | 12:42 | |
| rickspencer3 | ogra_, so, it rebooted and my led blinking snap started! | 12:44 |
| rickspencer3 | I take that as a good sign | 12:44 |
| rickspencer3 | is there a way for me to confirm that I am now on the channel that I wanted to be on? | 12:44 |
| ogra_ | rickspencer3, sudo snappy list -v | 12:46 |
| ogra_ | abd system-image-cli -i | 12:46 |
| rickspencer3 | ubuntu-core 2015-07-29 4 ubuntu* | 12:46 |
| rickspencer3 | ubuntu-core 2015-09-02 155 ubuntu | 12:46 |
| ogra_ | seems it didnt switch | 12:46 |
| rickspencer3 | oh? | 12:47 |
| rickspencer3 | oh well, I guess I'll just set up a new sd card with the right channel later | 12:47 |
| ogra_ | * indicates the active one | 12:47 |
| rickspencer3 | at least it didn't hose my board | 12:47 |
| ogra_ | you can force the swtich ... one sec | 12:47 |
| ogra_ | fw_printenv |grep ^snappy_ab | 12:48 |
| ogra_ | what does that print ? | 12:48 |
| rickspencer3 | (BeagleBoneBlack)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab | 12:48 |
| rickspencer3 | Cannot access MTD device /boot/uboot/uboot.env: No such file or directory | 12:48 |
| ogra_ | oh | 12:49 |
| ogra_ | hmm, you said this install is old .. | 12:49 |
| ogra_ | seems it is really old :) | 12:49 |
| rickspencer3 | ogra_, if this is going to become a yak shaving exercise, I suggest that we call channel switching "unsupported" and I can flash a new sd card at my leisure | 12:49 |
| ogra_ | we *do* call it unsupported ;) | 12:50 |
| rickspencer3 | well, right, that's my point ;) | 12:50 |
| ogra_ | but you are running into issues with an ancient bootloader setup | 12:50 |
| rickspencer3 | ok, sounds like a reflash is in order anyway, then | 12:50 |
| ogra_ | it wouldnt even switch on normal upgrade i fear | 12:50 |
| ogra_ | yeah | 12:51 |
| rickspencer3 | are there any docs on how I would use use snappy config? | 12:51 |
| ogra_ | well, it isnt very user friendly yet | 12:51 |
| rickspencer3 | I want to write a snap where you can define the gpio pin to use after installing the snap | 12:51 |
| ogra_ | you need to create a yaml file and pipe it into the command | 12:51 |
| rickspencer3 | ogra_, so, I could write go code that takes an argument in a form post | 12:52 |
| rickspencer3 | uses that to write a yaml file | 12:52 |
| ogra_ | i think sergiusens had some demo code for that | 12:52 |
| ogra_ | piping from a here doc | 12:52 |
| rickspencer3 | then pipes that yaml file in snappy config? | 12:52 |
| ogra_ | oh, if you want to do it on image level you should be able to define it in the package.yaml of a custom oem snap | 12:52 |
| rickspencer3 | ogra_, no, I want to do it on the snap level | 12:53 |
| rickspencer3 | i.e. the snap is in the store | 12:53 |
| ogra_ | (where you would also define your app snap as a requirement) | 12:53 |
| rickspencer3 | then it can be configured to use the specified gpio pins | 12:53 |
| ogra_ | ah, right, yeah , then you need to create a yaml file and run snappy config manually after install | 12:53 |
| rickspencer3 | so the end user will have to edit the yaml file on the board and run the command | 12:54 |
| rickspencer3 | ouch | 12:54 |
| ogra_ | nah, it will be more userfriendly | 12:54 |
| ogra_ | but this is the status quo | 12:54 |
| ogra_ | we have to many other construction areas atm ... config is only very basic yet | 12:55 |
| rickspencer3 | ok, I'll look at sergiusens code when he wakes up if he can point me to it :) | 12:56 |
| sergiusens | rickspencer3: I don't have any code | 12:56 |
| rickspencer3 | oh | 12:56 |
| rickspencer3 | lol | 12:56 |
| * sergiusens has been awake for 3 hours already | 12:56 | |
| sergiusens | ogra_: rickspencer3 you can also do snappy install [snap] [config] | 12:56 |
| rickspencer3 | sergiusens, I meant "wake up" in a totally figurative way :) | 12:56 |
| rickspencer3 | sergiusens, is there documentation that I can use anywhere? | 12:56 |
| ogra_ | ah, thats new to me | 12:57 |
| sergiusens | ogra_: it's in the --help (snappy install --help) | 12:57 |
| rickspencer3 | so, my idea for the snap is that when the board is ready to be connected to over ssh, it blinks a led | 12:58 |
| ogra_ | sergiusens, yeah i tried "snappy help" :P | 12:58 |
| ogra_ | (no, i'm lying indeed) | 12:58 |
| rickspencer3 | is there a way that a snap could easily tell if ssh is ready? | 12:59 |
| rickspencer3 | i.e. from Go code? | 12:59 |
| sergiusens | rickspencer3: so you indeed want a config to configure where that LED is | 12:59 |
| rickspencer3 | sergiusens, yeah | 12:59 |
| sergiusens | rickspencer3: you would need special permissions to check it at the service level | 12:59 |
| sergiusens | rickspencer3: the thing you can do today is poll the port and wait for the ssh signature | 13:00 |
| rickspencer3 | there are 2 things I don't know: 1. how to determine if ssh is running, 2. how to allow the developer to config the gpio pin | 13:00 |
| rickspencer3 | sergiusens, I can't do that with just the normal network permissions? | 13:00 |
| rickspencer3 | seems like I could do a loop and just ping it over localhost? | 13:00 |
| sergiusens | rickspencer3: yes, we don't have any security in place for fine grained networking :-/ | 13:00 |
| rickspencer3 | sergiusens, yes I can do that, or yes I can't do that? | 13:01 |
| sergiusens | rickspencer3: ping over localhost or over the main interface | 13:01 |
| Chipaca | ogra_: rickspencer3: cdparanoia has emoticons for status output | 13:01 |
| sergiusens | rickspencer3: yes you can! | 13:01 |
| rickspencer3 | ok, that sounds easy enough | 13:01 |
| Chipaca | :-) Normal operation, low/no jitter | 13:01 |
| Chipaca | :-| Normal operation, considerable jitter | 13:01 |
| Chipaca | :-/ Read drift | 13:01 |
| Chipaca | :-P Unreported loss of streaming in atomic read operation | 13:01 |
| Chipaca | 8-| Finding read problems at same point during reread; hard to correct | 13:01 |
| Chipaca | :-0 SCSI/ATAPI transport error | 13:01 |
| Chipaca | :-( Scratch detected | 13:01 |
| Chipaca | ;-( Gave up trying to perform a correction | 13:01 |
| Chipaca | 8-X Aborted read due to known, uncorrectable error | 13:01 |
| Chipaca | :^D Finished extracting | 13:01 |
| ogra_ | hah | 13:02 |
| sergiusens | Chipaca: that reminds me of mac system 7 | 13:02 |
| Chipaca | c.Check(logs, DeepEquals, []map[string]interface{}{{"a": 1}, {"a": 2}}) | 13:15 |
| Chipaca | ... obtained []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}} | 13:15 |
| Chipaca | ... expected []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}} | 13:15 |
| * Chipaca goes looking for somebody to wap over the head | 13:15 | |
| mvip | Alexander -- this is Viktor from Screenly. Sorry, forgot your nick, but please just wanted to join the channel and say hi. | 13:17 |
| Chipaca | asac: ^ | 13:17 |
| mvip | Thanks :) | 13:18 |
| mvip | Oh and i see mectors is hanging out here too :) | 13:19 |
| mectors | mvip of course | 13:20 |
| mvip | :) | 13:20 |
| rickspencer3 | o/ mvip | 13:21 |
| mvip | Need to brush up on my bitchx skills. Haven't spent much time on IRC in the last decade :) | 13:24 |
| bartkusedvinas | Hello there. I need some help that I can't find yet on Google. How do I add to may #cloud-config DOCKER_OPTIONS :/ does anyone use it? | 13:29 |
| bartkusedvinas | Is it possible to write to /var/lib/apps/docker/1.6.2.003/etc/docker.conf via cloud-config? | 13:30 |
| mvip | Are there any examples out there of running X11 apps in snaps? | 13:30 |
| mvip | bartkusedvinas: isn't /var residing on /, which is mounter r/o? | 13:31 |
| bartkusedvinas | you are right, it is read only | 13:34 |
| tedg | zyga: There is a rumor that you're working (and close to completing) pip support for snapcraft. Is it true? | 13:35 |
| mvip | bartkusedvinas i'm by no mean a Snappy expert, but my guess is that it's mounted as r/o on boot. As such, you can not modify that file (unless you hackishly re-mount it *inside* cloudinit) | 13:35 |
| === chihchun is now known as chihchun_afk | ||
| tedg | bartkusedvinas: Snaps themselves have a configuration interface, which the docker framework should use. I'm not sure if it is though. | 13:36 |
| bartkusedvinas | mvip: sounds right... tho, i bet that those who are using docker want to add DOCKER_OPTIONS='-H tcp://0.0.0.0:4243' | 13:36 |
| bartkusedvinas | however i can't find what is the right approch to do so | 13:37 |
| ogra_ | bartkusedvinas, the shipped cloud-init is only used for bringing up the system ... | 13:37 |
| ogra_ | not for tinkering with snaps | 13:37 |
| tedg | mvip: I think that deb2snap was used to make some Xapps run, but I can't think of an example. | 13:37 |
| tedg | mvip: Is there are particular one you're trying to run? Many have Mir backends available as well. | 13:37 |
| ogra_ | bartkusedvinas, well, you are likely not using docker standalone ... but run something in it | 13:38 |
| ogra_ | bartkusedvinas, for that something you would create a snap that uses the docker framework | 13:38 |
| ogra_ | and in that snap you would set such options | 13:38 |
| mvip | tedg: Well, yeah, have some things in mind, but was just curious if there were any examples out there. `deb2snap` seems somewhat hackish. | 13:38 |
| tedg | mvip: It is :-) | 13:39 |
| mvip | tedg: :) | 13:39 |
| mvip | Just out of curiousity, how's Docker configured on Snappy. Is it run on the host, or is it running within a snap? | 13:39 |
| mvip | Because I saw a Docker snap when I was playing with it on the RasPi | 13:39 |
| === kickinz1|afk is now known as kickinz1 | ||
| tedg | mvip: I wrote up an examle using Qt/QML, but that is with the Mir backend: http://gould.cx/ted/blog/Creating_a_QML_snap_with_Snapcraft | 13:40 |
| ogra_ | bartkusedvinas, i guess kickinz1|afk could help (if he werent afk) he maintains the docker framework snap and also the owncloud snap that uses it | 13:40 |
| mvip | tedg: Oh cool. Thanks. | 13:40 |
| kickinz1 | mvip docker is a framework snap | 13:40 |
| mvip | kickinz1 ah ok | 13:40 |
| mvip | still getting used to the Snappy lingo | 13:40 |
| ogra_ | ha, speaking of the devil :) | 13:40 |
| bartkusedvinas | thanks. i want to try snappy as alternative to coreos | 13:41 |
| bartkusedvinas | with coreos i had the following cloud-config which would open access to docker https://gist.github.com/edvinasbartkus/8ed0e61a7c7980c087f1 | 13:41 |
| bartkusedvinas | so I would be able to use deploy tools to deploy to coreos docker's my containers | 13:42 |
| ogra_ | yeah, this is the stuff you would do in a start script of the snap i talked about | 13:43 |
| bartkusedvinas | i see | 13:43 |
| ogra_ | http://paste.ubuntu.com/12253305/ i.e. this is the start script used by the owncloud snap | 13:45 |
| ogra_ | i assume you would have something similar in a coreos-docker.snap | 13:45 |
| mvip | kickinz1 so if Docker is a Snappy framework, i then presume it is running on the host and then snappy is responsible for communicating with Docker, right? | 13:45 |
| kickinz1 | mvip, yes, docker is running on the host, there are some specific apparmor profile management. | 13:47 |
| bartkusedvinas | I was expecting to find some easy recipie like this https://gist.github.com/edvinasbartkus/a99dd8bf12f717c7c6f5 :)) | 13:47 |
| mvip | kickinz1 got it. Thanks. | 13:47 |
| bartkusedvinas | @orgra_ thanks for the hint to the script. will try to improvise my way ;) | 13:48 |
| nothal | bartkusedvinas: No such command! | 13:48 |
| kickinz1 | mvip, but for now you can connect directly to docker-daemon, be aware, that if you want to do some docker build, docker load/save, you need to have your files in $HOME/apps/docker.$VERSION/ | 13:48 |
| bartkusedvinas | @nothal yeah, i am aware :) i was expecting just to have such easy solution :P | 13:48 |
| nothal | bartkusedvinas: No such command! | 13:48 |
| kickinz1 | $HOME/apps/docker/$VERSION/ | 13:49 |
| ogra_ | bartkusedvinas, well, i'm pretty sure such an easy setup is possible too ... | 13:49 |
| mvip | kickinz1 got it. | 13:49 |
| ogra_ | bartkusedvinas, the point in snappy is that you are completely confined ... so you would never modify any of the system setup of docker but ship your own | 13:50 |
| Chipaca | pitti: question for you sir | 13:50 |
| Chipaca | pitti: what should "journalctl -q -u something-that-does-not-exist" print, given the -q? | 13:51 |
| bartkusedvinas | @ogra_ thanks | 13:52 |
| nothal | bartkusedvinas: No such command! | 13:52 |
| ogra_ | you should leave out the @ :) | 13:52 |
| bartkusedvinas | oh :) sorry for being newby | 13:54 |
| bartkusedvinas | and even spelling like a newbie :)) | 13:54 |
| pitti | Chipaca: you mean wrt. the -- No entries --? -q is documented as "Suppresses any warning messages regarding inaccessible system journals when run as a normal user.", but I see how one would want to shut up that message too :) | 13:55 |
| ogra_ | no worries ... | 13:55 |
| ogra_ | usually the ubuntu bots dont use @ but ! ... nothal is special in this channel | 13:55 |
| Chipaca | pitti: the "No journal files were found." was more the thing i was expecting it to suppress | 13:55 |
| Chipaca | as it stands -o json outputs json except when it doesn't | 13:56 |
| Chipaca | making it somewhat annoying :) | 13:56 |
| pitti | Chipaca: I don't get that | 13:56 |
| pitti | $ journalctl -q -u something-that-does-not-exist | 13:56 |
| pitti | -- No entries -- | 13:57 |
| pitti | $ | 13:57 |
| Chipaca | $ journalctl -q -u potato | 13:57 |
| Chipaca | No journal files were found. | 13:57 |
| Chipaca | -- No entries -- | 13:57 |
| dholbach | sergiusens, is there a switch for snapcraft to force-rebuild everything? or how do you normally use it? (rm -rf parts stage snap; snapcraft)? | 13:57 |
| pitti | Chipaca: but this should be fixed anyway -- "-- no entries --" is quite useless for json output/parsing too | 13:59 |
| zyga | tedg: hehe | 14:02 |
| zyga | tedg: yes, let's talk | 14:02 |
| zyga | tedg: I'm working on this hard | 14:03 |
| zyga | tedg: and I'd love to have an accomplice | 14:03 |
| tedg | zyga: Do you have a branch pushed? | 14:04 |
| zyga | tedg: no, I got into a few blockers, if you want we can sync and talk about that but I'm packed with meetings now | 14:05 |
| zyga | tedg: we could invite you to a meeting in 25 minutes (monthly catch up on snappy) | 14:05 |
| zyga | tedg: that could help as wel | 14:05 |
| zyga | well | 14:05 |
| tedg | zyga: Uhm, okay. I'm not looking for more meetings ;-) | 14:05 |
| * ogra_ notes down ... ted ... looking for more meetings ... | 14:06 | |
| tedg | Heh, thanks ogra_ | 14:07 |
| ogra_ | :) | 14:07 |
| zyga | lol | 14:07 |
| zyga | tedg: so let's just talk here | 14:07 |
| zyga | tedg: tell me about your approach | 14:07 |
| zyga | tedg: and I'll tell you what I did and what I got stuck on | 14:08 |
| tedg | zyga: I was looking at adding a field to the python projects for adding a requirements.txt | 14:08 |
| tedg | zyga: Grab it, install it, party on. ← my approach :-) | 14:08 |
| zyga | tedg: mmm | 14:08 |
| zyga | tedg: have you run into the numerous issues in python3app implementation today | 14:09 |
| zyga | tedg: it's pretty much all wrong now | 14:09 |
| zyga | tedg: it bleeds the python stuff from the system into the snap stage area | 14:09 |
| tedg | Not sure what python3app is? python3-project ? | 14:09 |
| zyga | yep | 14:09 |
| zyga | I never remember if it's -project or -application | 14:09 |
| zyga | but yes | 14:09 |
| zyga | e.g. you pip install requirements and it ignores stuff you have locally installed | 14:10 |
| tedg | Ah, I don't have anything from pip locally installed :-) | 14:10 |
| zyga | not from pip | 14:10 |
| zyga | from the system | 14:10 |
| zyga | I have patched that heavily | 14:10 |
| tedg | So it needs to restrict its search path. Sounds like an envvar? | 14:10 |
| zyga | tedg: more than that | 14:10 |
| zyga | tedg: you really need to run the python from the stage area | 14:11 |
| zyga | tedg: there's no clean way to do it otherwise | 14:11 |
| zyga | tedg: and you essentially need to do what virtualenv does to be correct | 14:11 |
| tedg | Sure, but that's handled by setting up the path correctly. | 14:11 |
| zyga | tedg: then there are some interesting issues related to that but that's | 14:11 |
| zyga | tedg: path? yeah | 14:11 |
| zyga | tedg: well | 14:11 |
| zyga | tedg: no, just running the right python explicitly | 14:11 |
| tedg | Eh, okay. That can work too. | 14:12 |
| zyga | tedg: anyway, it's clear that you just run the right python with the right extra PYTHONHOME helpers and perhaps python -S (so that site is not imported) | 14:12 |
| zyga | tedg: then you get empty python and pip install works | 14:12 |
| zyga | tedg: I ran into some other issues though | 14:12 |
| zyga | tedg: and that's where I'm stuck now (though just stuck with ENOTIME) | 14:12 |
| tedg | zyga: K, do you have a branch somewhere that I can look at? | 14:12 |
| sergiusens | dholbach: I'm rm'ing, but I do want to at least add a 'clean' statement | 14:13 |
| zyga | tedg: I have it locally but it's all teribble as I was trying to figure out how to upstream it | 14:13 |
| zyga | tedg: let me show you the diff in a sec | 14:13 |
| zyga | (really stuck in meetings) | 14:13 |
| dholbach | sergiusens, it looks like it's necessary to remove the sideloaded package in a snappy system as well when using snappy-remote and not updating the version number | 14:14 |
| dholbach | so I can't just build a new snap and snappy-remote it again | 14:14 |
| sergiusens | dholbach: oh, Chipaca fixed that, for rolling at least | 14:15 |
| dholbach | <3 | 14:15 |
| dholbach | I love you guys | 14:15 |
| ogra_ | sergiusens, oh ? including apparmor profile updating ? | 14:16 |
| ogra_ | (i thinnk that didnt work in the past) | 14:16 |
| zyga | tedg: can you tell me more about what test projects you are trying to bundle with pip? | 14:17 |
| sergiusens | ogra_: dholbach the version is basically ignored and hashed, sideloading has no upgrade paths in any case, so it is all fine | 14:18 |
| ogra_ | ah, cool | 14:19 |
| ogra_ | in the past even for locally sideloaded snaps the apparmor profile wasnt updated when i didnt bump the version | 14:19 |
| Chipaca | ogra_: the version in the file is ignored for sideloaded | 14:22 |
| ogra_ | Chipaca, yup. got that now | 14:22 |
| Chipaca | ogra_: it's a base62 hex string of the timestamp in ns | 14:22 |
| Chipaca | base 50, not base 62, sorry | 14:23 |
| Chipaca | anyway | 14:23 |
| Chipaca | it's an apparently random string of a-yA-Y | 14:23 |
| Chipaca | such that something installed later always compares as newer | 14:24 |
| Chipaca | as long as your clock isn't completely full of it, that is :) | 14:24 |
| Chipaca | this means rollback still works as expected | 14:24 |
| * sergiusens reboots to enable VT on this laptop | 14:25 | |
| tedg | zyga: Looking more at the feature genericly. I don't have a specific project I need to package. | 14:25 |
| tedg | zyga: To have something to play with I was looking at Jasper, but it's a huge thing to get working, but provides a nice example. | 14:25 |
| zyga | tedg: I think it would be healthy to set up some projects as canaries, that you can build "complex" stuff | 14:27 |
| zyga | tedg: thanks, I'll have a look at that | 14:27 |
| zyga | tedg: as a sanity check, add checkbox-ng to that list, it's very important for an ongoing project we're doing | 14:27 |
| zyga | tedg: one thing I think needs more help is building C extensions | 14:28 |
| zyga | tedg: the requirements file needs to be coupled with a list of debian packages you need on the outside to build your stuff | 14:29 |
| zyga | tedg: stanity check for that is lxml2 | 14:29 |
| tedg | zyga: How does PIP express those dependencies? | 14:30 |
| zyga | tedg: it doesn't at all :D | 14:30 |
| zyga | tedg: but it's very very important | 14:30 |
| zyga | tedg: without this you won't get important things (requests) | 14:30 |
| zyga | tedg: and it's sad but that's what it is | 14:30 |
| tedg | Guess we'll have to take those on a case by case basis. But it means having to parse the file by ourselves :-/ | 14:31 |
| ogra_ | hmm, funny ... why does the rolling initrd on my Pi not attempt to resize at all | 14:39 |
| ogra_ | oh | 14:40 |
| ogra_ | probably because i should update to the new initrd in the device tarball :P | 14:40 |
| ogra_ | super irritating that /usr/share/initramfs-tools/scripts/local-premount/resize exists in my rootfs :P | 14:41 |
| ogra_ | (but not in the binary initrd) | 14:42 |
| elopio | fgimenez: sorry, I stayed in bed a little later today. | 15:03 |
| fgimenez | elopio, np! :) we can move our meeting a bit later | 15:03 |
| elopio | fgimenez: thanks for the subunit reviews. I'll make the changes. | 15:07 |
| fgimenez | elopio, ok thanks, when you have time take a look at https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 | 15:19 |
| dholbach | tedg, do you know what's up with https://bugs.launchpad.net/snapcraft/+bug/1491301? | 15:34 |
| ubottu | Launchpad bug 1491301 in Snapcraft "qmldemo example doesn't work" [Undecided,New] | 15:34 |
| elopio | sergiusens: or somebody, do you know how to make something like a prerequisite branch in git? | 15:34 |
| elopio | fgimenez: on it. I pushed the two subunit branches. | 15:37 |
| sergiusens | elopio: I'd ask the lp guys, cjwatson maybe knows | 15:39 |
| elopio | I'll wait for them. | 15:39 |
| tedg | dholbach: Hmm, no. I'll blame sergiusens ;-) | 15:40 |
| tedg | Let me look at it. | 15:40 |
| elopio | fgimenez: wow, nice catch on that branch. Now I understand the mess. | 15:40 |
| elopio | mvo: sorry, my suggestion on https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 was wrong. I'm testing Federico's proposal now. | 15:40 |
| dholbach | thanks tedg | 15:41 |
| dholbach | another example is broken as well: https://bugs.launchpad.net/snapcraft/+bug/1491303 | 15:42 |
| ubottu | Launchpad bug 1491303 in Snapcraft "tomcat-maven-webapp example doesn't work" [Undecided,New] | 15:42 |
| mvo | elopio: no problem | 15:42 |
| elopio | ev: about my request for git, if we want to save the master configuration in a repository, we will need to run git on the master. | 15:43 |
| elopio | it's run by the plugin, so we don't need to access the shell manually. But it's not useful in this case to install git in a slave. | 15:44 |
| fgimenez | elopio, thx maybe we could try to refactor things there | 15:44 |
| elopio | fgimenez: I think it's clear. The mess is because the behaviour is different in uboot, but your new comments make that ok. | 15:45 |
| mvo | sergiusens: I plan to look into u-d-f tomorrow for bigger rootfs, I would also like to increase /boot while at it to something like 256mb, what do you think? we no longer need system-a,b | 15:53 |
| sergiusens | mvo: sounds good, you can also look at my branches in lp:~snappy and reuse those if you want (there's uflash and an import of mostly everything into lp:snappy) | 15:56 |
| mvo | ogra_: if you have some you could have a look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 at some point, just to see if there is anything obviously wrong (except for the fixmes :) | 15:58 |
| mvo | sergiusens: oh, do you think that should be the way forward? to use uflash instead of u-d-f? | 15:58 |
| sergiusens | mvo: I do, I really do; it will be easier to separate old world order from the new world order | 16:01 |
| sergiusens | mvo: http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/ | 16:01 |
| sergiusens | mvo: would need some polishing, but that's where I left things before the Lex sprint | 16:02 |
| sergiusens | mvo: I did some general snappy cleanup there (moving away from helpers) so it is not all that easy to follow; but if you want, I can get these branches up to speed with the latest trunk | 16:03 |
| ogra_ | mvo, hmm ... dont you create a bunch of loops there ? | 16:04 |
| mvo | sergiusens: ok, I check tomorrow | 16:05 |
| mvo | ogra_: probably, not sure that can be avoided | 16:05 |
| mvo | ogra_: because the os is on /writable | 16:05 |
| ogra_ | mvo, the rootfs snap should not live in the writable partition | 16:05 |
| ogra_ | yeah | 16:05 |
| ogra_ | thats a prob | 16:05 |
| ogra_ | how would i do a factory reset ? wiping writable would wipe everything | 16:06 |
| ogra_ | the rootfs should be a readonly img in /boot | 16:07 |
| ogra_ | or better in system-boot | 16:07 |
| mvo | ogra_: thats what we will do with the recovery, there will be a os/kernel in /boot to always go back to | 16:07 |
| ogra_ | in fact i'd even say the rootfs should be a readonly img in system-boot/a or b | 16:08 |
| ogra_ | mvo, yeah, but still that mount loop of bind mounting stuff on top of itself isnt good | 16:08 |
| mvo | ogra_: we also have this mandate to stay within two partitons | 16:09 |
| ogra_ | mvo, yes, readonly bits should stay in system-boot | 16:09 |
| ogra_ | so you end up with system-boot and writable | 16:09 |
| mvo | ogra_: if we put the entire os into system-boot we need a much bigger partition and it can no longer be vfat | 16:10 |
| ogra_ | oh ? | 16:10 |
| mvo | (at least until we also move to squash/ext.img) | 16:10 |
| ogra_ | the readonly img is biger than 1G ?? | 16:10 |
| ogra_ | *bigger | 16:10 |
| * ogra_ cant imagine that | 16:10 | |
| ogra_ | it should be a few 100 M | 16:11 |
| ogra_ | if at all | 16:11 |
| mvo | the core is ~90Mb and a kernel ~120Mb | 16:11 |
| ogra_ | yeah, thats far from the 2G limit for vfat | 16:11 |
| mvo | and we want to keep at least two each, so we need ~500mb | 16:11 |
| ogra_ | right, still plenty of space | 16:11 |
| mvo | right, but it also means we need to move to squashfs in one step | 16:11 |
| mvo | we can unpack on vfat | 16:12 |
| ogra_ | why would you unpack ? | 16:12 |
| mvo | because right now the kernel and the os are regular snaps and snaps are unpacked (currently) until we move to squashfs | 16:12 |
| mvo | we will get there, but not right now | 16:12 |
| ogra_ | well make it unpack a single img file then | 16:13 |
| ogra_ | you want to loop mount that anyway | 16:13 |
| ogra_ | no matter what the format is | 16:13 |
| ogra_ | i dont think the loop you create currently is safe at all | 16:14 |
| mvo | that could be a way, yes. I would prefer to keep snaps the same, this is what I dislike about the approach | 16:14 |
| mvo | ogra_: unsafe in what way? | 16:14 |
| ogra_ | dunno, i have to think about it but it makes me twitch heavily | 16:14 |
| mvo | ogra_: ok | 16:15 |
| ogra_ | i did something similar for the first iteration opf the phone and stgraber pointed out a lot of flaws with that | 16:15 |
| * ogra_ will have to dig up that conversation | 16:15 | |
| beuno | ah, you might be | 16:16 |
| mvo | ogra_: that would be nice, I obviously do not want unsafe stuff, but I also want to understand whats unsafe about it | 16:16 |
| mvo | ogra_: I can ask him directly too if thats helpful (but after dinner) | 16:16 |
| ogra_ | yeah | 16:16 |
| ogra_ | probably even better having him take a look at the code | 16:17 |
| mvo | great, I will ask him | 16:17 |
| ogra_ | it makes me twitch heavily :) | 16:17 |
| mvo | thanks for the feedback! | 16:17 |
| mvo | well, we will get to the squashfs eventually :) it will all be good. and to the recovery and all the other missing bits | 16:17 |
| ogra_ | (even though i did something similar with the loop mounted img files on the phone ) | 16:18 |
| mvo | but yeah, if its not safe, its not safe and we need to skip the step | 16:18 |
| ogra_ | i dont see a need for squashfs here | 16:18 |
| ogra_ | its a nice extra but not really necessary | 16:18 |
| ogra_ | the img files can even be ext2 | 16:18 |
| mvo | ogra_: well, s/squashfs/binary-images/ | 16:18 |
| ogra_ | (and probably should, for speed) | 16:18 |
| mvo | stgraber: so if you have a moment at some point, a quick look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 would be cool and how horrible (or not) the approach is | 16:19 |
| * mvo gets dinner | 16:19 | |
| ogra_ | mvo, one thing that comes immediately to mind is that i can indeed edit content in /writable/system-data/os/ubuntu-core.sideload/${snappy_os}/* at any time, it isnt actually readonly only the bind mount on top is | 16:25 |
| ogra_ | so i have always full write access to the original files | 16:25 |
| stgraber | commented | 16:29 |
| * ogra_ commented too | 16:45 | |
| * tedg thought some of these nicks weren't LP bots, apparently was wrong. | 16:46 | |
| sergiusens | mvo: still around? | 20:00 |
| mvo | sergiusens: yes, but almost ready for eod | 20:07 |
| sergiusens | pindonga: did you log a bug about the forking issue in the systemd unit? | 21:48 |
| pindonga | yep | 21:48 |
| sergiusens | pindonga: can I have the number? I can't find it :/ | 21:48 |
| pindonga | looking | 21:48 |
| * sergiusens sucks at bug searching in lp | 21:48 | |
| * pindonga thanks firefox for remembering seen urls | 21:49 | |
| pindonga | https://bugs.launchpad.net/snappy/+bug/1490574 | 21:49 |
| ubottu | Launchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Critical,Triaged] | 21:49 |
| sergiusens | pindonga: ah, the title was ignored by my eyes :-) I thought we just wanted to support forking processes | 21:50 |
| pindonga | sergiusens, we probably do | 21:51 |
| pindonga | it's just I didn't enough it when I filed the bug :) | 21:51 |
| pindonga | s/enough/know/ | 21:53 |
| sergiusens | tedg: btw https://code.launchpad.net/~sergiusens/snapcraft/ubuntu-core/+merge/269938 feel free to slaughter it ;-) | 21:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!