| liuxg | hi, I have my raspberry pi 2 device. I do not have a HDMI display yet for it. I have flashed the Snappy software for it at the instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/. Now, I boot it, how can know it is booted? I connect it to my TTPlink router. I want to find its IP address to ssh login | 01:12 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:59 |
| clobrano | morning all | 08:02 |
| fgimenez | good morning | 08:06 |
| shuduo | morning, anyone has made mir working as snap on arm platform like RPi2 or BBB? | 08:11 |
| Chipaca | shuduo: not yet | 08:20 |
| Chipaca | shuduo: that's blocked on mir having a software renderer i think? | 08:20 |
| shuduo | Chipaca: can it be rendered by software render with bad performance? | 08:22 |
| Chipaca | shuduo: I don't think it can, at present, but I'm not entirely sure. | 08:23 |
| shuduo | Chipaca: :( | 08:27 |
| === Guest42341 is now known as supadupa | ||
| supadupa | ?????? | 08:34 |
| dholbach | mvo, the diff in https://code.launchpad.net/~mvo/click-reviewers-tools/snappy/+merge/275058 looks like it has a conflict - I also had a question about the recommends: wouldn't it be better to just make it depends instead? | 08:46 |
| mvo | dholbach: let me fix the conflict | 08:47 |
| mvo | dholbach: not sure about the depends/recommends, I have no strong opinion | 08:48 |
| dholbach | mvo, I just thought that if it's a recommends c-r-t would need a check if the tools are actually available | 08:49 |
| mvo | dholbach: yeah, it will fail to unpack a squashfs and error in this case. I'm happy to make it a depends | 08:49 |
| dholbach | oh ok... if we have the check, then I guess it's fine - I don't have a strong preference either | 08:50 |
| mvo | dholbach: maybe you can mention it in the review and jamie can decide what he prefers? | 08:51 |
| dholbach | sure | 08:51 |
| dholbach | mvo, good work | 08:55 |
| Chipaca | top of the morning, people! | 08:57 |
| * Chipaca 's coffee kicked in | 08:57 | |
| dholbach | hey, good morning Chipaca | 08:57 |
| Chipaca | dholbach: how's things? | 08:57 |
| dholbach | good good - just scheduling UOS sessions :) | 08:58 |
| dholbach | how about you? | 08:58 |
| Chipaca | dholbach: no, not scheduling uos sessions :) | 08:59 |
| dholbach | yeah, that would have surprised me :) | 09:00 |
| JamesTait | Good morning all; happy Tuesday, and happy Cranky Co-Workers Day! 😃 | 10:12 |
| ogra_ | mvo, oops, sorry, i only landed the modules bits in wily it seems | 10:20 |
| mvo | ogra_: no worries, I uploaded it to vivid now | 10:21 |
| * ogra_ sighs, so much email backlog | 11:02 | |
| ogra_ | mvo, sergiusens, so if i understand the oem snap change correctly i now need to ship all the files that would live under /boot/overlay/* in the toplevel, need to mention each of them separately in the yaml and define a dst /boot/overlay/foobar.dtb ? | 11:17 |
| sergiusens | ogra_, heh, mvo is working on it, not me ;-) | 11:17 |
| sergiusens | ave you heard, I'm not doing provisioning anymore :-P | 11:17 |
| ogra_ | sergiusens, ah, i thought it was also a u-d-f feature | 11:17 |
| sergiusens | it is ;-) | 11:17 |
| ogra_ | oh, not at all ? | 11:17 |
| ogra_ | k | 11:18 |
| sergiusens | well I am helping out, but not driving features anymore | 11:18 |
| mvo | ogra_: its a u-d-f feature but sergiusens is sneaking away from it. so I think /boot/overlay was not working at all before | 11:18 |
| mvo | ogra_: now it works, would you prefer a glob? I'm not sure I understand the question, what will be needed? i.e. what should /boot/overlay/ look like eventually? | 11:19 |
| ogra_ | mvo, no, it wasnt, which is why i simply shipped a tarball of it on the RPi that the admin can extract | 11:19 |
| mvo | ogra_: ok, now it does | 11:19 |
| ogra_ | mvo, the binary blob expects the overlay dtb's in the overlay subdir relative to where itself is stored (in oyur case /boot/overlay) | 11:20 |
| mvo | ogra_: ok, thats support by u-d-f now, snappy does not yet have it | 11:20 |
| ogra_ | err | 11:20 |
| ogra_ | sorry | 11:20 |
| ogra_ | /boot/uboot/overlay | 11:20 |
| mvo | oh | 11:20 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ ls /boot/uboot/over* | 11:20 |
| ogra_ | /boot/uboot/overlays.tgz | 11:20 |
| mvo | /boot/uboot/overlay should already work | 11:20 |
| ogra_ | this is what i ship now | 11:21 |
| ogra_ | so you ave to cd /boot/uboot/ and tar xf that file | 11:21 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:/boot/uboot$ sudo tar xf overlays.tgz | 11:22 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:/boot/uboot$ ls -l overlays|wc -l | 11:22 |
| ogra_ | 40 | 11:22 |
| mvo | ogra_: so you want a glob to avoid to list the 40 things idividually? | 11:22 |
| ogra_ | it would indeed be good to have globbing, so i dont need 80 extra lines in the yaml ... | 11:22 |
| ogra_ | but at least it is better than before if i can somehow ship them by default without the untarring | 11:23 |
| mvo | ogra_: hm, so if the target is /boot/uboot/overlay that should work now already, what am I missing? what failure do you get? | 11:23 |
| ogra_ | mvo, i'm not getting any failure :) i was asking if this works now | 11:28 |
| ogra_ | so i can change the build setup for the oem | 11:28 |
| ogra_ | (and get rid of the untarring) | 11:28 |
| mvo | ogra_: it should also work before, it requires the files to be listed individually though | 11:28 |
| ogra_ | (before it simply ignored /boot/uboot/overlay completely, it didnt show up at all) | 11:29 |
| mvo | ogra_: you can give it a "target: overlay/new-name" iin the yaml | 11:29 |
| ogra_ | ok, thats what i tried in the past and didnt work ... | 11:29 |
| ogra_ | if that works now i'm fine | 11:30 |
| ogra_ | (dirs were completiely ignored) | 11:30 |
| mvo | ogra_: it should, lets talk after lunch | 11:30 |
| ogra_ | ok | 11:30 |
| mvo | ogra_: no glob support yet though, that would have to be added | 11:30 |
| ogra_ | that would surely be helpful ... but i'm also fine defining two lines for each file | 11:31 |
| ogra_ | mvo, but we need to talk about dtb handling on RPi anyway ... since the dtb needs to be loaded by the blob before uboot and we have no way to make that happen from /boot/uboot/a|b ... | 11:32 |
| ogra_ | (so kernel upgrades will not work) | 11:32 |
| Facu | Hola :) | 12:42 |
| ogra_ | hey hey :) | 12:42 |
| Facu | sergiusens, so, what do you mean with "my cache"? in my host? | 12:42 |
| ogra_ | Facu, do you run multiple snappy installs in your lan (with each of them having a webdm) ? | 12:43 |
| sergiusens | Facu, mdns is just multicast dns; something multicasts a name (webdm.local) and the clients cache it | 12:43 |
| Facu | ogra_, no, only one (a raspi) | 12:43 |
| ogra_ | mDNS can indeed only assign that name once | 12:43 |
| sergiusens | Facu, the cache should be as the ttl of the multicast dns entry (iirc) | 12:44 |
| noise][ | fwiw, we've seen that IP bug in a few different environments now | 12:45 |
| noise][ | cprov and I have both run into it as well, and for some odd reason it seems to resolve properly from OS X hosts but not from Ubuntu hosts | 12:46 |
| ogra_ | sounds like our avahi client setup might be buggy | 12:53 |
| mvo | ogra_: yeah, maybe we can talk after the standup? | 12:59 |
| ogra_ | mvo, sure | 12:59 |
| ogra_ | btw ... could we probably fix the schedule somehow ? | 13:00 |
| mvo | ogra_: sure, just create a meeting | 13:00 |
| ogra_ | i mean the standup one :) | 13:00 |
| mvo | ogra_: oh | 13:00 |
| mvo | ogra_: fix in the sense of moving it 1h later? | 13:00 |
| ogra_ | when brazil got DST it moved by 1h ... now that germany got DST it moved by another hour | 13:00 |
| ogra_ | so effectively (for me at least) it moved 2h | 13:01 |
| ogra_ | (15:00 local time for me instead of the former 17:00) | 13:01 |
| sergiusens | ogra_, move one hour into the future again would not hurt :-) | 13:02 |
| ogra_ | i mean, i'm fine if we keep it that way but i think thats a bit early for the western countries | 13:02 |
| ogra_ | sergiusens, yeah | 13:02 |
| sergiusens | ogra_, that way, it would be steady all year long for the saner countries ;-) | 13:02 |
| ogra_ | well, sane countries are rare in this case ... thats the prob :) | 13:03 |
| longsleep | +1 for the snappy timezone | 13:04 |
| mvo | fgimenez, elopio: if its trivial for you, it woudl be great if you could stop tarmac. the git move is happening today. if you are busy I can try to find the right card and do it myself (stop cron) | 13:15 |
| longsleep | urgs snapcraft now has JSON schema | 13:17 |
| fgimenez | mvo, ok on it | 13:19 |
| mvo | thanks a lot fgimenez | 13:19 |
| fgimenez | mvo, i've commented out the crontab entry, now it should be disabled | 13:21 |
| mvo | fgimenez: \o/ | 13:22 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | ogra_: why have bip and kiwi in the same snap? wouldn't them being separate be just as easy? | 13:42 |
| ogra_ | Chipaca, to make install and maintenance easier ... | 13:43 |
| Chipaca | ogra_: ok :) | 13:43 |
| plars | is there a good way to pass ssh options to snappy-remote? | 13:43 |
| ogra_ | Chipaca, i wouldnt drop the standalone ircproxy bip snap ... this would be more a "irc-client-phone-backend" project snap that actually bundles everything needed and has all bits hardwired | 13:44 |
| ogra_ | i.e. an "application backend" that ships all parts pre-configured already | 13:44 |
| ogra_ | indeed there could be standalone a kiwi snap too | 13:45 |
| Chipaca | ogra_: three snaps: one bip snap, one kiwi snap, one ogra-badass-oem snap to tie them up and config them | 13:48 |
| ogra_ | Chipaca, i dont want to build an appliance | 13:49 |
| ogra_ | (you make it sound like i could just use oem as "metapackage" replacement) | 13:49 |
| Chipaca | ogra_: i'm *shocked* you'd even *hint* at me saying something like that | 13:50 |
| * Chipaca tries to deliver that without smiling | 13:50 | |
| ogra_ | heh | 13:50 |
| plars | sergiusens: is snappy-remote intended to be a supported tool? seems to be in a junk branch? | 14:01 |
| plars | sergiusens: or should I just bypass it and do everything over ssh | 14:01 |
| ogra_ | plars, isnt it the same as ssh ... ? | 14:02 |
| * ogra_ doesnt really see the advantage over just plain ssh | 14:02 | |
| plars | ogra_: I could do the same by just doing scp the package, install over ssh, yes | 14:02 |
| sergiusens | ogra_, as soon as we use the rest api it will add more value | 14:03 |
| plars | ogra_: it's just a convenience thing, and if it's a supported tool I'm happy to use it | 14:03 |
| ogra_ | ah | 14:03 |
| plars | ogra_: but that's why I asked. I'm getting the impression I should just ignore it | 14:03 |
| plars | for now at least :) | 14:03 |
| ogra_ | i surely do :) | 14:04 |
| Facu | sergiusens, ogra_, noise][, it seems that webdm is answering the bad IP | 14:07 |
| Facu | sergiusens, ogra_, noise][, remember, first ping webdm.local goes to 192.168.100.130, second one goes to 254.86.90.140 | 14:08 |
| Facu | sergiusens, ogra_, noise][, and this is the multicast dns response from the raspi: http://linkode.org/U6Tclhm1i4S9VcbmNjMEM6 | 14:09 |
| Facu | see line 98 there | 14:09 |
| noise][ | interesting | 14:11 |
| Chipaca | Facu: what logs do you get from webdm? the Publish <....> are the ones i'm interested in | 14:13 |
| Chipaca | Facu: sudo snappy service logs webdm | 14:13 |
| Facu | Chipaca, http://linkode.org/DnzzdEWN8dffBE3FkpCzk2 | 14:14 |
| Facu | Chipaca, see the IPv6 in the last line of the logs, the weird IPv4 returned in the mdns response, and this: | 14:16 |
| Facu | >>> 0xfe, 0x56, 0x5a, 0x8c | 14:16 |
| Facu | (254, 86, 90, 140) | 14:16 |
| Chipaca | that was what i was looking at just now, indeed | 14:16 |
| Facu | it looks like it's adapting the IPv6 to a IPV4 to fit in the mdns response using... a hammer? | 14:17 |
| Chipaca | Facu: yes, but i'm not sure who 'it' is in that sentence | 14:17 |
| Facu | Chipaca, neither do I, for sure | 14:18 |
| sergiusens | Facu, that is why I asked for the webdm logs ;-) | 14:19 |
| sergiusens | Chipaca, we need to skip ::1 | 14:19 |
| sergiusens | Chipaca, and we can probably just ignore ipv6 in general | 14:20 |
| Facu | sergiusens, who is "we"? | 14:21 |
| noise][ | i disabled ipv6 on my trusty vm and it gets the right IP after | 14:21 |
| Chipaca | it's webdm building the wrong rr | 14:21 |
| Chipaca | using a instead of aaaaaaaaaaahrgh | 14:22 |
| sergiusens | elopio, care to rejoin? | 14:31 |
| elopio | sure | 14:36 |
| elopio | mvo: your msg branch needs a po update. | 14:38 |
| mvo | elopio: will do that, thanks! | 14:41 |
| dholbach | ppisati, can we do something about https://bugs.launchpad.net/snappy/+bug/1506480? | 14:45 |
| ubottu | Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New] | 14:45 |
| elopio | ogra_: we are getting the watchdog config error, the one that says it's read-only. | 14:53 |
| elopio | But I see that the last wily commits are your fixes | 14:55 |
| Chipaca | Facu: noise][: can i give you a new webdm to try? | 15:00 |
| noise][ | sure, probably in 20' or so | 15:01 |
| Facu | Chipaca, yes, please | 15:04 |
| Chipaca | Facu: noise][: http://people.canonical.com/~john/webdm_0.9.4_multi.snap | 15:05 |
| Facu | Chipaca, is there a way to install it directly into the raspi? | 15:06 |
| Chipaca | Facu: sudo snappy install http.chipaca | 15:06 |
| Facu | awesome | 15:06 |
| Chipaca | Facu: http.GET http://people.canonical.com/~john/webdm_0.9.4_multi.snap > webdm.snap | 15:06 |
| * Facu installs a chipaca | 15:06 | |
| Chipaca | Facu: sudo snappy install ./webdm.snap | 15:07 |
| Facu | Chipaca, no http.GET or wget in the raspi | 15:07 |
| Chipaca | Facu: but you just got it by installing http.chipaca | 15:08 |
| Facu | oh, right | 15:08 |
| Facu | sorry | 15:08 |
| Chipaca | :) | 15:08 |
| Facu | Chipaca, just because it may be useful for you: 2015/10/27 15:15:48.720387 verify.go:85: Signature check failed, but installing anyway as requested | 15:16 |
| sergiusens | Chipaca, elopio initial thoughts? https://code.launchpad.net/~sergiusens/snapcraft/help/+merge/275858 | 15:16 |
| Chipaca | Facu: yep, that's expected | 15:16 |
| Facu | Chipaca, it doesn't want to install it because there's other package already installed with same name... should I remove the old one, or do an upgrade? | 15:16 |
| Chipaca | Facu: remove it, yeh | 15:17 |
| ogra_ | elopio, which one exactly, there were two | 15:19 |
| Chipaca | sergiusens: the “can be used in any part irrespective of the plugin” seems to be stronger than what you were describing yesterday | 15:25 |
| sergiusens | Chipaca, there are two; what I was describing yesterday is what is in sources | 15:26 |
| sergiusens | Chipaca, those are builtin keywords | 15:26 |
| sergiusens | oh and ted https://code.launchpad.net/~sergiusens/snapcraft/help/+merge/275858 | 15:27 |
| Chipaca | sergiusens: print(getattr(_TOPICS[module_name], '__doc__')) | 15:27 |
| Chipaca | sergiusens: why not _TOPICS[module_name].__doc__ instead of the getattr? | 15:27 |
| sergiusens | Chipaca, hah, that is indeed better | 15:27 |
| Chipaca | sergiusens: the getattrs are getting to you :) | 15:28 |
| clobrano | I'm having a problem with a snap that contains both a binary and a shell script. I'm using security-template: unconfined, but when the binary (called by the script) tries to access an assigned serial device I got this error: ubuntu-core-launcher: error while loading shared libraries: cannot apply additional memory protection after relocation: Permission denied. Any idea? | 15:28 |
| sergiusens | Chipaca, the only sucky thing, and elopio pointed it out is if I do a 'help' against this I get a mix of markdown and whatever python's help does | 15:29 |
| Chipaca | clobrano: sounds like you're doing a double-wrap | 15:29 |
| Chipaca | clobrano: your binaries should just call your binaries | 15:29 |
| sergiusens | clobrano, as in the non exported ones; also read as, the internal ones | 15:30 |
| jdstrand | or put another way. call them from SNAP_APP_DATA | 15:30 |
| Chipaca | SNAP_APP_PATH | 15:30 |
| jdstrand | meh | 15:31 |
| Chipaca | :) | 15:31 |
| jdstrand | yes, SNAP_APP_PATH | 15:31 |
| jdstrand | :) | 15:31 |
| Chipaca | although some people are copying the whole snap to SNAP_APP_DATA because their binaries write stuff (?) | 15:31 |
| Facu | Chipaca, http://linkode.org/DnzzdEWN8dffBE3FkpCzk2/XoBMe0RVZe8azht6zd0061 | 15:31 |
| sergiusens | if you built it with snapcraft some things inside there are already in your PATH (./bin, ./usr/bin) | 15:31 |
| Facu | Chipaca, doing multiple pings now it works!!! | 15:31 |
| Facu | Chipaca, I assume that the mdns response comes ok | 15:31 |
| Chipaca | Facu: shocking!! :) | 15:31 |
| Facu | Chipaca, you'll publish this new webdm? | 15:32 |
| Chipaca | Facu: i'll have sergiusens check the code, and then ask him to publish it, yes :) | 15:32 |
| sergiusens | mvo, about the comment from gustavo, I feel it might be good to use target-absolute instead of dst; are we too late to change that? | 15:32 |
| jdstrand | clobrano: do you have snappy-debug installed? you could run in another console 'sudo snappy-debug.security scanlog' and it will give you suggestions (your case here is detected) | 15:32 |
| Facu | Chipaca, gracias :) | 15:32 |
| mvo | sergiusens: we can do that, I think target-abolute is better indeed | 15:33 |
| noise][ | Chipaca: many thanks for the quick fix there | 15:34 |
| clobrano | jdstrand: unfortunately snappy-debug crashes with an UnicodeDecodeError... | 15:34 |
| sergiusens | mvo, I approved the size one btw | 15:34 |
| mvo | sergiusens: ta | 15:34 |
| Chipaca | sergiusens: https://code.launchpad.net/~chipaca/webdm/mdns-nicer-with-ipv6/+merge/275866 when you have a mo | 15:34 |
| sergiusens | mvo, but I leave the addition of the commit message to you | 15:35 |
| sergiusens | Chipaca, I have moments now, idling waiting for comments on that help branch now ;-) | 15:35 |
| jdstrand | clobrano: interesting. can you file a bug? alternatively, can you paste the output of 'sudo grep audit /var/log/syslog' | 15:35 |
| jdstrand | ? | 15:35 |
| clobrano | jdstrand: sure I'll do it | 15:36 |
| jdstrand | clobrano: if you file a bug, please attach /var/log/syslog | 15:36 |
| clobrano | jdstrand: SNAPP_APP_PATH is? I tried all the dirs starting from /apps/<package-name>/, but the result's the same | 15:36 |
| sergiusens | Chipaca, no need for reverse lookups? | 15:37 |
| jdstrand | SNAP_APP_PATH | 15:37 |
| clobrano | jdstrand: yep, typo, SNAP_APP_PATH | 15:37 |
| Chipaca | sergiusens: you weren't doing them before, so ¯\_(ツ)_/¯ | 15:37 |
| jdstrand | it is /apps/<pkgname>/<version>/ | 15:37 |
| sergiusens | Chipaca, hah, touche | 15:38 |
| clobrano | jdstrand: ok, tried but still the same | 15:38 |
| Chipaca | clobrano: how are you exec'ing the other program, in your program? | 15:39 |
| Chipaca | sergiusens: http://people.canonical.com/~john/webdm_0.9.4_multi.snap <- publish plz :) tested by facu | 15:40 |
| clobrano | Chipaca: is <programname>.<programname> inside the script | 15:40 |
| Chipaca | clobrano: why programname.programname? | 15:41 |
| Chipaca | clobrano: say you have two programs | 15:41 |
| Chipaca | clobrano: one in bin/foo, one in bin/bar | 15:41 |
| Chipaca | clobrano: say foo is a shellscript | 15:41 |
| Chipaca | clobrano: to run bar, you do: $SNAP_APP_PATH/bin/bar | 15:42 |
| elopio | ogra_: sorry, they started cutting down the power here :@ | 15:42 |
| Chipaca | clobrano: bin/bar doesn't even need to be in your package.yaml, even | 15:42 |
| elopio | ogra_: so I see your two fixes in the wily package in the ppa. | 15:42 |
| ogra_ | right | 15:42 |
| clobrano | Chipaca: it's the opposite, actually. Is the script that calls the binary. So I have bin/foo, which I can call typing pkgname.foo. Inside foo I call the binary using pkgname.bar | 15:44 |
| Chipaca | clobrano: yes, you do, and that's why it fails | 15:44 |
| ogra_ | elopio, so show me the exact error .... | 15:44 |
| Chipaca | clobrano: that's what i'm telling you | 15:44 |
| Chipaca | clobrano: don't do that | 15:44 |
| elopio | ogra_: Error: open /etc/default/watchdog.HXUWIktPalrj: read-only file system | 15:45 |
| clobrano | Chipaca: get it, $SNAP_APP_PATH/bin/bar is the right way to do it? | 15:45 |
| Chipaca | clobrano: yes | 15:45 |
| * clobrano tries | 15:46 | |
| ogra_ | elopio, and /etc/default/watchdog is a link to /etc/writable/default/watchdog ? | 15:46 |
| elopio | ogra_: give me a second to check that. | 15:47 |
| clobrano | Chipaca, jdstrand: that works, thank you. Of course I have another problem now :D but not sure is cause by snappy | 15:47 |
| Chipaca | clobrano: i'm sure it is :-p | 15:47 |
| === kyrofa_ is now known as kyrofa | ||
| clobrano | Chipaca: ahaha, don't know. Just the binary is blocked opening the device :| | 15:48 |
| clobrano | Chipaca: might be the device | 15:48 |
| fgimenez | elopio, have you seen IS email? we can finally access scalingstack from canonistack's lcy01 \o/ | 15:49 |
| elopio | fgimenez: yes :) | 15:49 |
| elopio | fgimenez: have you tried it? | 15:49 |
| fgimenez | elopio, yep, i've been playing around, the key is in tarmac's host | 15:50 |
| elopio | ogra_: there is no /etc/writable/default | 15:50 |
| elopio | and /etc/default/watchdog is not a link. | 15:50 |
| elopio | fgimenez: great, thanks! | 15:50 |
| ogra_ | thats the issue then | 15:50 |
| ogra_ | is that a recent image ? | 15:50 |
| fgimenez | elopio, we need to make some adjustments in snappy-tests-job, i'll prepare a branch | 15:50 |
| * ogra_ goes to check the rootfs build logs if anything with the linking went wrong | 15:51 | |
| fgimenez | elopio, there are no snappy images in scalingstack, we must upload our own, snappy-cloud-image fits here well :) | 15:51 |
| elopio | fgimenez: just in time :D | 15:51 |
| ogra_ | hmm | 15:51 |
| ogra_ | I: Moving /etc/watchdog.conf to /etc/writable/ | 15:52 |
| ogra_ | I: Linking /etc/watchdog.conf to /etc/writable/ | 15:52 |
| ogra_ | I: Moving /etc/default/watchdog to /etc/writable/default | 15:52 |
| ogra_ | I: Linking /etc/default/watchdog to /etc/writable/default | 15:52 |
| ogra_ | the log for the last stable image looks fine | 15:52 |
| Chipaca | sergiusens: sorry this review is taking long -- getting sidetracked a lot | 15:52 |
| ogra_ | elopio, we are talking about stable, right ? | 15:53 |
| elopio | ogra_: this is rolling edge #208 generic amd. | 15:53 |
| ogra_ | oooh | 15:53 |
| ogra_ | elopio, bah, sigh ... the change went to the PPA livecd-rootfs because the distro was in final freeze, seems that even though it was frozen, a newer livecd-rootfs ended up in wily ... | 15:54 |
| ogra_ | i'll bump the version | 15:55 |
| niemeyer_ | Folks, I'm starting the dance to move the code into GitHub.. | 15:56 |
| niemeyer_ | mvo: Is Tarmac frozen? | 15:57 |
| * tedg hopes this is like a rain dance | 15:57 | |
| elopio | thanks ogra_ | 15:57 |
| elopio | niemeyer_: yes, tarmac is not running. | 15:57 |
| niemeyer_ | tedg: Pretty much :) | 15:57 |
| niemeyer_ | elopio: Thanks | 15:57 |
| ogra_ | niemeyer_, videos please :) | 15:58 |
| clobrano | jdstrand: where's the right place to file the bug? Under the snappy project itself? | 15:59 |
| niemeyer_ | ogra_: Ah, that wouldn't work.. the vcs gods don't like soul-stealing devices | 15:59 |
| ogra_ | lol | 15:59 |
| jdstrand | clobrano: yes, that's fine | 15:59 |
| clobrano | jdstrand: ook | 15:59 |
| ogra_ | elopio, i assume it was fine in stable when you tested for the release (just to make sure) | 16:02 |
| ppisati | dholbach: i commented lp1506480 | 16:05 |
| dholbach | thanks ppisati | 16:05 |
| sergiusens | Chipaca, no worries, I'm going for lunch; my only big regret and open is handling markdown and python help | 16:05 |
| sergiusens | oh, elopio told me to reach out to alecu for that | 16:06 |
| Chipaca | oh, i dunno, alecu is a *manager* now | 16:06 |
| Chipaca | we are not worthy | 16:06 |
| Chipaca | :-D | 16:06 |
| sergiusens | alecu, do you know how to write fancy titles in python docstrings | 16:06 |
| sergiusens | you have to come full circle, right? :-) | 16:07 |
| dholbach | ppisati, brilliant - I'll change it | 16:07 |
| mvo | niemeyer_: yes, tarmac is out of cron | 16:08 |
| sergiusens | mvo, ah, you kill all of tarmac and not just lp:snappy? That explains why other projects aren't landing ;-) | 16:09 |
| niemeyer_ | Hmm.. strange.. | 16:10 |
| niemeyer_ | Got a complaint about tags | 16:10 |
| niemeyer_ | 14:09:10 WARNING: not creating tag u'\t' pointing to non-existent revision G1szODs1OzIyNm0bWzQ4Oz...... | 16:10 |
| niemeyer_ | and the output of "bzr tags" indeed seems dirty | 16:10 |
| mvo | sergiusens: you move as well, no? | 16:10 |
| niemeyer_ | Is it just me? | 16:10 |
| mvo | niemeyer_: uh, indeed | 16:10 |
| elopio | ogra_: yes, stable passes the test. | 16:11 |
| ogra_ | phew | 16:11 |
| Chipaca | sergiusens: reviewed! phew | 16:21 |
| Chipaca | niemeyer_: no, it's not just you | 16:21 |
| Chipaca | niemeyer_: that's my fault, or bzr's fault | 16:21 |
| Chipaca | niemeyer_: you can delete those two tags locally | 16:21 |
| Chipaca | but lp seems to resurrect them | 16:21 |
| niemeyer_ | Chipaca: Ok, no worries.. the import process seems to have filtered out exactly the bad ones | 16:21 |
| clobrano | jdstrand: I had a look at snappy-debug, a possible fix would be to open the codecs adding the argument errors='replace' (codecs.open(path, 'r', encoding="UTF-8", errors='replace')). | 16:21 |
| Chipaca | niemeyer_: ah, good | 16:22 |
| jdstrand | clobrano: thanks! | 16:22 |
| clobrano | jdstrand: I mean, with that change, the crash does not occur anymore on my env, but I'm not sure t'is acceptable as solution | 16:22 |
| jdstrand | I'll take a look | 16:22 |
| jdstrand | clobrano: can you also add the output of this to the bug: set|egrep '(LC_|LANG)' | 16:24 |
| clobrano | jdstrand: sure | 16:24 |
| * clobrano done | 16:27 | |
| Chipaca | jdstrand: have you been able to look at https://code.launchpad.net/~c-lobrano/snappy/hw-assign-symlink/+merge/274908 at all? | 16:46 |
| sergiusens | Chipaca, thanks for the review | 16:47 |
| Chipaca | sergiusens: you say that, but :) | 16:48 |
| ogra_ | elopio, i kicked off a new rolling build | 16:52 |
| Chipaca | jdstrand: sys:1: PyGIWarning: Click was imported without specifying a version first. Use gi.require_version('Click', '0.4') before import to ensure that the right version gets loaded. | 16:52 |
| elopio | :) | 16:52 |
| === davidcalle is now known as davidcalle_afk | ||
| jdstrand | Chipaca: re click-apparmor. I can fix that. fyi, still chipping away at removing click-apparmor/go rewrite | 17:12 |
| Chipaca | jdstrand: i never doubted it | 17:12 |
| longsleep | Hey folks, anyone knows when/if the /tmp/snap.* folders are supposed to be cleaned up? | 17:13 |
| Chipaca | jdstrand: that warning is brought to you from xenial, btw | 17:13 |
| Chipaca | longsleep: right now, never | 17:13 |
| longsleep | Chipaca: ok - simple enough answer | 17:13 |
| Chipaca | longsleep: eventually, we want something like tmpreaper | 17:13 |
| Chipaca | longsleep: but it's not there yet | 17:13 |
| longsleep | Chipaca: any suggestions what i could do in the meantime? | 17:13 |
| Chipaca | longsleep: if it's becoming an issue, file a bug and let us know | 17:14 |
| Chipaca | longsleep: we've only not done anything because it's not been an issue | 17:14 |
| Chipaca | and, priorities | 17:14 |
| longsleep | Chipaca: well, every command run does create a new temp file when that command is from a snap | 17:14 |
| longsleep | temp folder i mean | 17:14 |
| longsleep | run hello-world.env 1000 times - you have 1000 temp folders | 17:15 |
| Chipaca | longsleep: yes. otoh /tmp is tmpfs, so you're not going to run out of inodes or anything | 17:16 |
| Chipaca | you will eventually run out of space though | 17:16 |
| longsleep | Chipaca: right, but if there are files in it it eats ram | 17:16 |
| Chipaca | longsleep: care to file a bug? | 17:17 |
| jdstrand | Chipaca: regarding that branch-- fyi, I didn't write the hw-assign udev bits and I wasn't sure how this fit into the future direction for hw assignment, which is why I haven't been looking at it. I figured a snappy core/architect would look at it and I could be pulled in to verify (ie, once the implementation and approach was deemed ok) | 17:17 |
| longsleep | Chipaca: sure | 17:17 |
| Chipaca | jdstrand: good point. ok. | 17:18 |
| Chipaca | oh, wait | 17:20 |
| Chipaca | longsleep: hold on | 17:20 |
| Chipaca | longsleep: we might actually be doing automatic cleanup already | 17:20 |
| Chipaca | longsleep: AFAIUI we're running systemd-tmpfiles --clean once a day | 17:21 |
| longsleep | Chipaca: oh? i just filed bug #1510638 which is slightly different from automatic cleanup | 17:21 |
| ubottu | bug 1510638 in Snappy "Per process tmp folders in /tmp/snap.0* are not removed" [Undecided,New] https://launchpad.net/bugs/1510638 | 17:21 |
| alecu | sergiusens: Chipaca: I didn't get the bit about me helping with python docstrings... | 17:23 |
| alecu | I thought nessita was the authority there | 17:23 |
| Chipaca | alecu: sergiusens is a struggling artist of the docstring scene | 17:24 |
| sergiusens | Chipaca, ok just pushed your review fixes | 17:27 |
| sergiusens | alecu, heh, elopio said either or :-P | 17:27 |
| elopio | alecu: I imagined you had something to do with the u1 clients man. | 17:28 |
| longsleep | whooohooo https://github.com/ubuntu-core/snappy !! Now if snapcraft would move to GitHub too - that would be aweseome! | 17:30 |
| sergiusens | hey elopio neither you or me show up as contributors :-P | 17:57 |
| elopio | sergiusens: we are not wanted :'( | 17:58 |
| sergiusens | elopio, we do show up in the commits though :-P | 17:58 |
| elopio | sergiusens: I see my face in some commits. | 17:58 |
| sergiusens | alecu, nessita so as the docstring folk I'd like to ask: is there an easy straighforward way to override 'help' so it doesn't show the __<atrib-name>__'s such as __weakref__ et. al.? The other one is, are there any formatting rules I can use? | 18:01 |
| elopio | sergiusens: I think it's because I am missing the canonical email in my account | 18:01 |
| sergiusens | elopio, ah | 18:01 |
| * sergiusens tries | 18:01 | |
| sergiusens | elopio, nope | 18:04 |
| nessita | sergiusens, never done that... google does not know? | 18:04 |
| sergiusens | nessita, google might know, I'm sure I just haven't done the right search :-) | 18:05 |
| sergiusens | there is no way google can't know :-P | 18:05 |
| alecu | sergiusens: elopio: I think after changing/adding emails in github it takes a while until contributions start showing properly. | 18:10 |
| sergiusens | seems I need to fork pydoc which I don't want to :-) | 18:10 |
| alecu | sergiusens: formatting rules: https://www.python.org/dev/peps/pep-0257/ | 18:11 |
| alecu | sergiusens: and, if help(dict) shows all the __xxx__ methods, why do you worry about not showing yours? | 18:12 |
| sergiusens | alecu, right, all good with the peppy stuff ;-) Just wondering if there was a way to say "bold" :-) | 18:14 |
| sergiusens | alecu, I don't want to show them because elopio asked me not to :-P | 18:14 |
| alecu | sergiusens: elopio: I just did "import httplib; help(httplib)" and I can see *a lot* of __weakref__'s | 18:16 |
| elopio | alecu: right, but they don't show them in the man page. | 18:16 |
| elopio | sergiusens is trying to autogenerate the man from docstrings. And I think it's showing too much info. | 18:16 |
| elopio | sergiusens: I think you can generate the man with sphinx. So you choose the format and what to show. | 18:17 |
| alecu | sergiusens: elopio is right, sphinx is what you want there. | 18:18 |
| alecu | also, define the __all__ list at the toplevel of the module, so only those symbols are "public" and I guess the doc generators have some smarts regarding that. | 18:20 |
| sergiusens | elopio, oh, I don't want to generate a man page | 18:20 |
| elopio | well, a help page. Almost the same :) | 18:21 |
| sergiusens | elopio, but with --devel as a switch ;-) | 18:22 |
| ogra_ | argh | 18:22 |
| ogra_ | mvo, seems we cant build rolling anymore | 18:22 |
| ogra_ | the builds already point to xenial and that completely fails | 18:23 |
| sergiusens | alecu, elopio is it easy to generate documentation on the fly with sphinx? | 18:23 |
| sergiusens | all the intros I've seen require a lot of setup | 18:23 |
| alecu | sergiusens: no idea there | 18:28 |
| alecu | sergiusens: it seems that a little of markup is allowed on python docstrings: http://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html | 18:28 |
| alecu | and https://pythonhosted.org/an_example_pypi_project/sphinx.html#full-code-example | 18:29 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | elopio, Chipaca so for the general case I'm not going to worry about sphinx as this looks good to me http://paste.ubuntu.com/12981760/ | 18:50 |
| ogra_ | mvo, so i did a final wily image build manually now ... nightly rolling will build xenial by default then | 18:50 |
| ogra_ | mvo, tomorrow we need to check what we want to copy around in the PPA and what should instead go to the archive, i think this is the moment to clean up the PPA bits for the next release :) | 18:51 |
| elopio | ogra_: \o/ xenial | 18:51 |
| ogra_ | heh | 18:52 |
| elopio | sergiusens: that looks good. I'm not quite sure about starting with a new line, but looks nice. | 19:03 |
| sergiusens | elopio, oh, it is because my docstrings are not right after """ I can fix that | 19:12 |
| sergiusens | elopio, ok, pushed that, I'll wait for your review | 19:23 |
| elopio | sergiusens: I would leave the deprecated comment for when you do the deprecation. | 19:25 |
| sergiusens | elopio, ok | 19:25 |
| sergiusens | elopio, done | 19:26 |
| elopio | sergiusens: the key is the internal filename whilst the value *IS* the exposed filename | 19:28 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | elopio, ah, there used to be a comma there... :-) | 19:29 |
| sergiusens | done | 19:30 |
| elopio | sergiusens: on the topic docstring, you are using ''' instead of """ | 19:30 |
| sergiusens | elopio, where? I thought I switched, but habits :-) | 19:31 |
| elopio | sergiusens: do you want the review here or in the branch? | 19:31 |
| elopio | l192 | 19:31 |
| sergiusens | elopio, done | 19:32 |
| elopio | sergiusens: l222, s/exists/exist/ | 19:33 |
| === davidcalle_afk is now known as davidcalle | ||
| elopio | sergiusens: l251, s/topis/topics/ | 19:34 |
| elopio | sergiusens: The maven plugin is useful for building parts that use the maven. | 19:36 |
| elopio | I supposed you are missing a word after the second maven, but I doubt it will fit in 88 chars. | 19:36 |
| sergiusens | elopio, let me rephrase | 19:37 |
| elopio | maybe: The plugin is useful for building parts that use maven. | 19:37 |
| sergiusens | elopio, word! :-) | 19:37 |
| elopio | sergiusens: and feel free to top-approve after that, because I'm starving. | 19:39 |
| * elopio leaves for lunch. | 19:39 | |
| alecu | So, it's *the* Dan Kegel (of C10K fame) the one asking about binary video drivers packaged for snappy... | 19:43 |
| alecu | I wonder if he wants to use snappy for mezzanine: http://www.oblong.com/ | 19:44 |
| alecu | it looks really slick | 19:44 |
| sergiusens | elopio, great I had already pushed ;-) | 19:48 |
| sergiusens | elopio, is tarmac on again? | 20:02 |
| sergiusens | mvo, or was it you driving tarmac disabling/enabling? | 20:04 |
| tedg | alecu: I hope so, I think we'll need test system though... to help with... collaboration. | 20:08 |
| mvo | sergiusens: I was driving the disable | 20:08 |
| mvo | sergiusens: I mean, I asked for it | 20:08 |
| mvo | sergiusens: if we just disable snappy, thats all I need | 20:08 |
| sergiusens | mvo, great, your goget branches are stuck too btw ;-) | 20:09 |
| alecu | sergiusens: btw, it seems that the dev portal is already using sphinx for some of our APIs: | 20:57 |
| alecu | https://myapps.developer.ubuntu.com/docs/api/click-purchases.html | 20:57 |
| alecu | https://myapps.developer.ubuntu.com/docs/api/iap.html | 20:57 |
| alecu | sergiusens: that means that all the styling bits should be solved | 20:57 |
| alecu | sergiusens: I understand that the deploy bits too, but I'm guessing you want this to be run on 3rd party devels build environments. | 20:58 |
| sergiusens | alecu, yes, I want it to be interactive and local. In any case; we've moved to the model of writing markdown and d.c.c pulls that in automatically for actual portal docs. With the popularity of github I've seen some projects drops sphinx in favor of githubs internal renderer which to be honest is the perfect balance between simplicity and elegance | 23:07 |
| AlekMabry | Hello! | 23:26 |
| AlekMabry | When you create a snappy app, can you add applications installed with apt-get to it? | 23:28 |
| AlekMabry | I am making an application that relies on flite, installed with 'sudo apt-get install flite' | 23:28 |
| AlekMabry | But I don't know how to include flite in my snappy application | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!