| === Ursinha_ is now known as Ursinha | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:14 |
|---|---|---|
| dfletch | morning | 08:34 |
| dfletch | can one have apt parallel to snappy? | 08:34 |
| JamesTait | Good morning all; happy Wednesday, and happy Frappe Day! 😃 | 08:50 |
| clobrano | good morning | 08:56 |
| clobrano | Chipaca: hello, I came back on Bug #1496319 :) | 09:02 |
| ubottu | bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319 | 09:02 |
| clobrano | Chipaca: problem was adding custom Udev string as hw-assign parameter. Is there a way to check whether Udev is tested enough for this? | 09:04 |
| soffokl | Hi all, we are still trying to execute Snappy on parallella board. Based on porting guilde, we have take beagebone rootof and our own kernel. After some configuring u-boot, we have managed to load system. | 09:05 |
| soffokl | But after that we failed to login by “ubuntu/ubuntu”, because of system after first boot sets /var/lib/extrausers/shadow like ubuntu:!$6$tOIJ… | 09:05 |
| soffokl | After removing “!” we can successfully login into system. But mount command shows that root mounted in “rw” mode. And seems like not all mount points mounted properly. | 09:06 |
| soffokl | ogra2, ogra_ : you are our last chance :) | 09:10 |
| Chipaca | lool: you around? | 09:15 |
| Chipaca | mwhudson: did you see pitti's reply on bug 1487010? | 09:16 |
| ubottu | bug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/1487010 | 09:16 |
| lool | Chipaca: yup | 09:16 |
| Chipaca | clobrano: i'd ask security people | 09:16 |
| Chipaca | lool: you've ported snappy to some odd places :) | 09:16 |
| Chipaca | lool: any hints for soffokl here? | 09:16 |
| clobrano | Chipaca: thanks | 09:16 |
| lool | soffokl: are you using our initrd snippets? | 09:17 |
| lool | soffokl: http://kernel.ubuntu.com/git/rtg/snappy-tools.git/ has a tool to create the device tarball from kernel .debs | 09:18 |
| Chipaca | clobrano: most of 'em are at something like utc-5 though | 09:18 |
| * clobrano checking UTC-5 | 09:19 | |
| clobrano | Chipaca: it's not a problem, I can wait :) | 09:19 |
| ogra_ | soffokl, and you used ubuntu-device-flash to create this image ? | 09:25 |
| Chipaca | an ogra! | 09:25 |
| * Chipaca faints | 09:25 | |
| ogra_ | well, inofficial still :) | 09:25 |
| Chipaca | :) | 09:25 |
| ogra_ | (but bored as hell) | 09:26 |
| soffokl | lool, we have tried to use beagleboneblack initrd, but then our kernel failed to load. | 09:26 |
| ogra_ | then youur kernel is likely missing bits that snappy needs | 09:26 |
| lool | soffokl: you need to have the right modules and options, either builtin modules or in the initrd | 09:27 |
| ogra_ | nah | 09:27 |
| ogra_ | you shouldnt need modules | 09:27 |
| lool | ogra_: either builtin or as modules :-) | 09:28 |
| ogra_ | if you use the same config we use on the beagle or on the rpi images you will have everything you need to mount the readonly root and the overlays | 09:28 |
| soffokl | ogra_, yes, we have created image with "sudo ubuntu-device-flash core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz" | 09:28 |
| ogra_ | i have booted both with module-less initrds | 09:28 |
| biezpal | ogra_, which config you mean? | 09:29 |
| ogra_ | soffokl, well, you need to create your onwn oem snap ... with the right bootloader, vmlinuz and initrd | 09:29 |
| ogra_ | biezpal, the kernel config :) | 09:29 |
| biezpal | ogra_, where can we get the "correct" kernel config? | 09:30 |
| biezpal | we are using our own kernel for parallella and seems like it doesn't have required for snappy bits.. | 09:32 |
| ogra_ | ppisati, ^^ doo you have a link for biezpal | 09:32 |
| ppisati | biezpal: kernel version? | 09:33 |
| ppisati | 3.10, 3.14 or 3.18? | 09:33 |
| ogra_ | or perhaps 4.2 ? | 09:34 |
| ogra_ | :) | 09:34 |
| ppisati | *drums* | 09:34 |
| ppisati | 4.2 would be awesome | 09:34 |
| biezpal | ppisati, 4.2.0 :D | 09:34 |
| ogra_ | soffokl, note that a readonly root is normal ... only a few selected bits are writable via bind mounted dirs and files, that is what the initrd is needed for | 09:35 |
| ogra_ | (it sets up the bind-mount-farm) | 09:35 |
| ppisati | biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_packaging | 09:36 |
| ppisati | biezpal: look at the UBUNT: [Config] commits | 09:36 |
| ppisati | biezpal: they all touch files in | 09:36 |
| soffokl | ogra_, thanks, we are keep reading about oem snap | 09:36 |
| ppisati | biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_packaging | 09:37 |
| ppisati | biezpal: cherry-picks these commits | 09:37 |
| ppisati | biezpal: then | 09:37 |
| ppisati | biezpal: $ ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/YOURCONFIG_defconfig arch/arm/configs/snappy/*.config | 09:37 |
| ppisati | biezpal: and you should get a config able to boot snappy | 09:38 |
| ogra_ | soffokl, note that we switched to use a uboot.env file for the environment, but the old uEnv.txt and snappy-system.txt stuff should still work to get something to do a first boot (just rollback and update wont, but thhats a second step for porting) | 09:38 |
| biezpal | ppisati, ok, thanks for helping.. | 09:40 |
| longsleep | yesterday i tried updating one of my test boxes to stable 6, it failed with the message that ubuntu-core was sideloaded. Is that expected? | 10:17 |
| longsleep | ogra_: Hey, are you using predictable network interface names with rpi2 image? If so, how did you enable it, kernel parameter only? | 10:23 |
| ogra_ | longsleep, i'm actually suppressing them via kernel cmdline option corrently | 10:23 |
| ogra_ | net.ifnames=0 | 10:24 |
| ogra_ | that keeps the old naming scheme | 10:25 |
| longsleep | ogra_: Ah - but that is the default in ubuntu isnt it? | 10:25 |
| ogra_ | not sure if we use it elsewhere | 10:25 |
| longsleep | ogra_: net.ifnames=1 is working to some level for me, but i was wondering if the interfaces should still be eth0 and wlan0 | 10:26 |
| ogra_ | well.... snappy config ubuntu-core defaults to eth0 currently | 10:26 |
| longsleep | right, but aside from that, i was kind of expecting crazy interface names with that change | 10:27 |
| ogra_ | yeah | 10:27 |
| ogra_ | depends on your HW | 10:27 |
| longsleep | mhm ok, USB wifi is getting wlan0 names, works fine as long as you do not replace the USB device with another one | 10:28 |
| ogra_ | http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | 10:29 |
| ogra_ | seems you are lucky and fall inot category 5 on that 1-5 list | 10:29 |
| longsleep | mhm | 10:30 |
| longsleep | this means the hardware does not provie 1, 2 or 3 or i am doing something wrong | 10:31 |
| ogra_ | right ... or you have a udev rule in place already | 10:31 |
| longsleep | i did at least expect it to use 3 | 10:31 |
| longsleep | ogra_: why do you not use it on the rpi2? just because ubuntu-core defaulting to eth0? | 10:32 |
| ogra_ | yeah, and i get a really weird name based on the mac address (4) | 10:32 |
| longsleep | oh | 10:32 |
| longsleep | yeah 4 would be bad | 10:32 |
| ogra_ | (which i shouldnt according to that doc) | 10:33 |
| longsleep | well, maybe it is enabled in the systemd build somwhere | 10:33 |
| ogra_ | iirc Chipaca said all that works fine in rolling ... never tried that | 10:33 |
| ogra_ | i added this hack to rpi specifically for 15.04 images | 10:34 |
| Chipaca | mmh? | 10:34 |
| Chipaca | i was probably lying, whatever it was | 10:34 |
| Chipaca | 's a good bet | 10:34 |
| ogra_ | lol | 10:34 |
| longsleep | anyways, i am basically fine with getting 5 - but i have some issues when an active USB wifi is removed and replaced, something is not released then and then | 10:34 |
| longsleep | mhm, from my testing setting the kernel parameter to 0 is the same as the default behavior without the parameter | 10:35 |
| longsleep | (stable channel though) | 10:35 |
| ogra_ | funny | 10:35 |
| ogra_ | is that on a first boot ? | 10:36 |
| longsleep | yes | 10:36 |
| ogra_ | (wont work on subsequent ones since the udev rule exists) | 10:36 |
| longsleep | when i remove the udev rule and reboot without the parameter it creates it again | 10:37 |
| longsleep | same is when booting with 0 as value | 10:37 |
| longsleep | when booting with 1, the udev rule is not created | 10:37 |
| ogra_ | yeah | 10:38 |
| ogra_ | but your kernel simply provides the old naming | 10:38 |
| Chipaca | is this about the creation of the file for the first ethernet card? | 10:40 |
| longsleep | ogra_: oh, so this thing depends on the kernel as well, i thought it would be systemd only | 10:40 |
| ogra_ | well, that is what the wikipage says | 10:40 |
| longsleep | Chipaca: it is about the interface names and the udev rule stores all ethernet devices ever connected to the host | 10:41 |
| * longsleep checks the wiki again | 10:41 | |
| ogra_ | 5. Classic, unpredictable kernel-native ethX naming (example: eth0) | 10:41 |
| ogra_ | kernel-native | 10:41 |
| Chipaca | ah | 10:41 |
| Chipaca | but i had nothing to do with that :) | 10:42 |
| Chipaca | all i did touching that was creation of the first-boot file for the first ethernet device | 10:42 |
| soffokl | ogra_, we are successfully loaded with initrd, thanks again :) | 10:42 |
| longsleep | ogra_: right, but any kernel should be the same right? | 10:42 |
| Chipaca | which just looks for eth* and en* | 10:42 |
| ogra_ | i'm pretty sure you worked on a snappy specific bug for it :) | 10:42 |
| ogra_ | right | 10:42 |
| longsleep | Chipaca: what file is that? | 10:42 |
| ogra_ | soffokl, \o/ | 10:42 |
| Chipaca | longsleep: /etc/networ/interfaces.d/{ethname} | 10:42 |
| longsleep | Chipaca: ah, well you should probably extend this to also support wl* | 10:43 |
| ogra_ | in the course where we discussed that bug it turned out that rolling and 15.04 behaved differently | 10:43 |
| ogra_ | which led me to use the kernel cmdline option on rpi stable | 10:43 |
| longsleep | i see | 10:44 |
| longsleep | mhm funny that i do not seem to be required to use the cmdline option though | 10:44 |
| ogra_ | i agree abouth the wl* thing though | 10:44 |
| Chipaca | longsleep: wl is wifi, sin't it? | 10:44 |
| longsleep | Chipaca: yeah | 10:44 |
| ogra_ | yep | 10:44 |
| Chipaca | isn't that more complicated? | 10:45 |
| ogra_ | buut if you are unluckly it could also be wifi0 | 10:45 |
| ogra_ | :P | 10:45 |
| * ogra_ has seen such devices before | 10:45 | |
| longsleep | really | 10:45 |
| longsleep | oh my | 10:45 |
| * Chipaca <- il ne sais rien | 10:45 | |
| Chipaca | sait* | 10:45 |
| ogra_ | rm -fr .... | 10:45 |
| longsleep | lol | 10:45 |
| * ogra_ removes the french | 10:45 | |
| Chipaca | :D | 10:46 |
| Chipaca | or, D: | 10:46 |
| Chipaca | let me get our friends out of france first! | 10:46 |
| ogra_ | heh | 10:46 |
| longsleep | wifi is more complicated true, i am currently providing wpa config in /etc/writable/wpa_supplicant.conf | 10:46 |
| longsleep | did not find any better writable mount to put it | 10:46 |
| ogra_ | there might be a network-manager framework at some point in the future | 10:47 |
| ogra_ | that should make it easier to just supply a snappy confg yaml for your setup | 10:47 |
| Chipaca | longsleep: you can't configure it via the interfaces.d thing in config? | 10:47 |
| ogra_ | only to a certain extend | 10:48 |
| longsleep | Chipaca: not if you want to be able to configure multiple networks | 10:48 |
| ogra_ | wifi config works fine via /e/n/i ... but not for the higher level encryptions | 10:48 |
| Chipaca | longsleep: i don't think multiple networks blocks this | 10:48 |
| ogra_ | i.e. enterprise WPA and such | 10:48 |
| Chipaca | ogra_: yeah, those always tripped me up :) | 10:48 |
| longsleep | Chipaca: what is not blocked by multiple networks? | 10:49 |
| ogra_ | normal personal WPA2 works fine via the file | 10:49 |
| longsleep | only for a single ssid | 10:49 |
| ogra_ | i never tried multiple :) | 10:49 |
| longsleep | if you want roaming or have it auto pick the stronges signal it will not | 10:49 |
| Chipaca | ah | 10:50 |
| longsleep | =t | 10:50 |
| Chipaca | so, let's call it "basic support" | 10:50 |
| Chipaca | :) | 10:50 |
| ogra_ | and my WIFI APs here can properly use ESSID for roaming | 10:50 |
| longsleep | hehe all right | 10:50 |
| ogra_ | (using the same SSID for all and have them send roaming info to the client about strenght etc) | 10:51 |
| longsleep | ogra_: mhm so you say i should avoid using a wpa config file mhm - not sure - then i need a way to store multiple ssid/password combinations some place else and apply them from some place else | 10:51 |
| ogra_ | but thats sadly an AP feature you dont find in the home user HW | 10:51 |
| longsleep | right, and only works for a single logical network | 10:52 |
| ogra_ | yeah | 10:52 |
| * longsleep thinks wpa-confi option is the way to go for everyone | 10:52 | |
| ogra_ | nah | 10:52 |
| longsleep | snappy even shipts wpa_passphrase to create it | 10:52 |
| longsleep | :) | 10:52 |
| longsleep | -t | 10:52 |
| ogra_ | nmcli via snappy config from your oem snap is the way to go | 10:52 |
| longsleep | nmcli oh my | 10:53 |
| * longsleep was hoping to avoid that | 10:53 | |
| ogra_ | once there is a NM framework we ship by default | 10:53 |
| ogra_ | NM offers evereything we need for GSM, LAN and WLAN | 10:54 |
| ogra_ | and whatever else | 10:54 |
| longsleep | does NM also offer link detection? I added a new comment to https://bugs.launchpad.net/snappy/+bug/1498631/comments/10 yesterday, as dhcp is running forever even if there is no link on eth0 | 10:54 |
| ubottu | Launchpad bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [High,In progress] | 10:54 |
| ogra_ | yes, it should | 10:54 |
| longsleep | Now the waiting is fixed with the release from yesterday but the dhcp keeps running and running | 10:55 |
| ogra_ | (plug a cable into your laptop ... it will DTRT) | 10:55 |
| longsleep | oh, i did some brief research about ifplugd and and did not like it very much | 10:55 |
| ogra_ | is that dhclient ? | 10:55 |
| longsleep | yes dhcclient is started for eth0 | 10:55 |
| longsleep | no matter if plugged or not | 10:56 |
| ogra_ | that should have a timeout option we can add i think | 10:56 |
| longsleep | mhm but what when you plug it after that timeout was reached? | 10:56 |
| ogra_ | i think -1 ... | 10:56 |
| longsleep | that is there | 10:56 |
| ogra_ | but that will only make it try once | 10:56 |
| ogra_ | oh | 10:57 |
| ogra_ | it should try only once for the duration of the timeout that was defined in dhclient.conf | 10:58 |
| longsleep | mhm it does have some kind of interval | 10:58 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ grep ^time /etc/dhcp/dhclient.conf | 10:59 |
| ogra_ | timeout 300; | 10:59 |
| ogra_ | so it should stop after 5min | 10:59 |
| longsleep | No working leases in persistent database - sleeping. | 10:59 |
| longsleep | and after some time it will try again | 10:59 |
| longsleep | ok maybe i was not patient enough | 10:59 |
| longsleep | nope its not me | 11:00 |
| longsleep | it just started again | 11:00 |
| longsleep | ogra_: 10:54:53 sleeping | 11:01 |
| longsleep | ogra_: 11:00:33 DHCPDISCOVER | 11:01 |
| ogra_ | uhm | 11:01 |
| longsleep | i did nothing with that device in the meantime | 11:01 |
| longsleep | just journalctl | 11:01 |
| ogra_ | pitti, any idea why that happens ? "dhclient -1 <iface>" should not make it restart, no ? | 11:02 |
| ogra_ | or i'm reading the manpage wrong ... sounds like a bug | 11:02 |
| longsleep | ogra_: well then i am reading the manpage wrong as well | 11:03 |
| longsleep | ogra_: exit with code 2 :) | 11:03 |
| ogra_ | right | 11:03 |
| daker | hi, anyone with some snappy/Ubuntu Core presentations ? | 11:03 |
| longsleep | i am out for lunch now, i will dig more on this later | 11:04 |
| ogra_ | daker, i know sergiuens held a talk, but i dont know where his slides are ... (and he is off until tomorrow) | 11:04 |
| daker | ogra_: ok, i will ask him tomorrow | 11:05 |
| Chipaca | http://summit.ubuntu.com/ubuconla-2015/meeting/22539/hola-snappy/ | 11:05 |
| Chipaca | ogra_: ^ that one? | 11:06 |
| ogra_ | oh, right | 11:06 |
| ogra_ | you might need to pipe it through skype though to get it in a sane language | 11:07 |
| ogra_ | *g* | 11:07 |
| daker | Chipaca: thanks | 11:07 |
| svij | daker: depending on your language, here's another one in not-english: https://speakerdeck.com/svij/snappy-ubuntu-core | 11:08 |
| daker | svij: thanks! | 11:08 |
| ogra_ | ppisati, err ... why do we default to "powersave" in the kernel config, thats really bad ... (first: that makes booting slow, second: we have a userspace job that forces it to ondemand after boot) | 12:09 |
| ogra_ | can we please set this back to performance by default so the boot doesnt get slowed down = | 12:10 |
| ogra_ | ? | 12:10 |
| ogra_ | (we can discuss making the usespace job configurable to then default to powersave after boot or some such) | 12:11 |
| * Chipaca goes to lunch, while pondering the genius of http://bennyhillthis.com/ | 12:19 | |
| longsleep | ogra_: so the dhclient is still trying to get an address for the not connected eth0, so i think we can say that it does not stop | 12:30 |
| ogra_ | longsleep, right, i think thats a bug .... seems pitti didnt see my ping above :) | 12:32 |
| pitti | ogra_: I didn't get to it yet; sorry, being flood-pinged | 12:32 |
| ogra_ | i would expect it to stop doing that if -1 is used and a timeout is set in dhclient.conf | 12:32 |
| longsleep | ok let me add it to the tracker then | 12:32 |
| ogra_ | perhaps something external restarts dhclient and doesnt respect "exit 2" though | 12:33 |
| longsleep | ogra_: no, the pid of that dhclient did not change since 2 hours | 12:33 |
| ogra_ | wow | 12:34 |
| ogra_ | yeah, then it sounds like dhclient doesnt even exit | 12:34 |
| pitti | I didn't follow scrollback, but -1 doesn't (seem to) be "try once and immediately exit", just "try once" (as documented) | 12:34 |
| pitti | so it might stay around until it actually succeeds? | 12:34 |
| longsleep | yet it stays around and flodding logs all 5 minutes with DHCPDISCOVER on eth0 lines | 12:35 |
| longsleep | s/yet/yes | 12:35 |
| ogra_ | pitti, well, the manpage says it does try once for the duration of the timeout thats defined in dhclient.conf | 12:36 |
| pitti | so that sounds like a bug then | 12:36 |
| ogra_ | and then it does an "exit 2" | 12:36 |
| longsleep | let me add a new bug separate from 1498631 | 12:37 |
| * pitti runs "sudo dhclient -1 -v -i lxcbr0" (which can't succeed) and lets that sit for 5 mins | 12:37 | |
| * pitti gets grumpy, changes timeout to 30s and re-runs | 12:38 | |
| longsleep | hehe | 12:38 |
| pitti | what kind of ridiculous default is "5 mins" anyway | 12:38 |
| pitti | we live in an impatient world :) | 12:39 |
| pitti | 5 mins == broken | 12:39 |
| pitti | No DHCPOFFERS received. | 12:39 |
| pitti | and exits with 0 (!) after 30 s | 12:39 |
| longsleep | Maybe its only with a lease file? | 12:39 |
| longsleep | After No DHCPOFFERS received it logs No working leases in persistent database - sleeping. | 12:39 |
| pitti | I do have a /var/lib/dhcp/dhclient.leases | 12:39 |
| pitti | right, I get the same | 12:40 |
| longsleep | mhm | 12:40 |
| pitti | Old leases are kept around in case the DHCP server is unavailable when dhclient | 12:40 |
| pitti | is first invoked (generally during the initial system boot process). In that | 12:40 |
| pitti | event, old leases from the dhclient.leases file which have not yet expired are | 12:40 |
| pitti | tested, and if they are determined to be valid, they are used until either they | 12:40 |
| pitti | expire or the DHCP server becomes available. | 12:40 |
| ppisati | ogra_: powersave is our default on every kernel/arch | 12:40 |
| pitti | so that sounds plausible | 12:40 |
| ppisati | ogra_: how much do we gain in boot time going to performance? | 12:40 |
| longsleep | mine does not exit - the pidfile got created at 10:25 utc and it still has that pid | 12:41 |
| pitti | longsleep: so does it log that it's re-using old leases then? | 12:41 |
| longsleep | pitti: no there are no leases | 12:41 |
| longsleep | (lease file is empty) | 12:41 |
| longsleep | its the first boot actually, and it never had a link on eth0 | 12:41 |
| ogra_ | ppisati, a few seconds ! | 12:42 |
| ogra_ | ppisati, who decided to drop performance in our main kernels ?!? | 12:43 |
| ogra_ | thats an essential boot speed bit | 12:43 |
| ogra_ | (worked out around lucid by keybuk) | 12:43 |
| ppisati | ogra_: let me check | 12:43 |
| pitti | CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y | 12:44 |
| ogra_ | phew ! | 12:44 |
| pitti | we still have that in wily's amd64 kernel at least | 12:44 |
| pitti | is that different on other kernels? | 12:44 |
| ogra_ | seems like | 12:44 |
| ogra_ | well, in snappy kernels | 12:44 |
| pitti | and /etc/init.d/ondemand should change it to something else after 1 min | 12:44 |
| ogra_ | yeah | 12:44 |
| ogra_ | we want full CPU and IO throughput until we are booted | 12:45 |
| ogra_ | and after that switch to ondemand | 12:45 |
| ogra_ | if we want to switch to something else in snappy thats fine, but only after booting please | 12:45 |
| pitti | FWIW, needing something like /etc/init.d/ondemand seems silly; I'd have thought the kernel's default scheduler would be clever enough by now | 12:45 |
| pitti | I mean, even with ondemand/powersave it should go to full CPU if there's load; doesn't it? | 12:46 |
| ppisati | pitti: yep | 12:46 |
| ppisati | pitti: it just tries to go down quicker | 12:46 |
| pitti | ppisati: right, I'm not advocating to keep "performance" all the time; I'm just asking why "ondemand" all the time is worse | 12:47 |
| pitti | if there is demand (and there obviously is during boot) it should certainly be as fast? | 12:47 |
| ppisati | ogra_: i was wrong, the default is still PERFORMANCE | 12:48 |
| ogra_ | i think keybuk found that it takes a bit to scale up | 12:48 |
| ogra_ | ppisati, good | 12:48 |
| ppisati | ogra_: tough in that rpi2 kernel was powersave | 12:49 |
| ppisati | ogra_: let me check another thing | 12:49 |
| ogra_ | pitti, so you run without full performance for a second or two during boot | 12:49 |
| Chipaca | jdstrand: ping | 12:49 |
| ppisati | here it is | 12:49 |
| ppisati | arch/arm/configs/bcm2709_defconfig:CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y | 12:49 |
| ogra_ | which costs precious CPU throughput at a point where you dont want to lose it | 12:50 |
| ppisati | ogra_: that was the default governor from the rpi config | 12:50 |
| ogra_ | ppisati, oh, please change that asap | 12:50 |
| ogra_ | we want ondemand after boot and performance during boot | 12:50 |
| ppisati | ogra_: let me check 4.2 | 12:50 |
| ogra_ | now i understand why it boots so sluggish | 12:50 |
| ppisati | ogra_: and i'll push a a new kernel for 3.19 | 12:50 |
| Chipaca | jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273683 | 12:50 |
| ogra_ | ppisati, why ? we dont use 3.19 anywhere anymore :) | 12:51 |
| ogra_ | snappy is 4.2 everywhere since last image | 12:51 |
| ppisati | ogra_: i'm still using it :) | 12:51 |
| Chipaca | jdstrand: marked "work in progress" because i still need to add code that uses it, but that's the crypto bits done for your guys to take a look | 12:51 |
| longsleep | ppisati, ogra_ : Added the dhcp issue as bug #1503680 | 12:51 |
| ubottu | bug 1503680 in Snappy "dhclient for eth0 does never exit and retries dhcp foerever" [Undecided,New] https://launchpad.net/bugs/1503680 | 12:51 |
| Chipaca | oh, drat, prerequisites | 12:52 |
| ogra_ | and in snappy we run cloud-init during boot *before* the ondemand governor is used ... and cloud-init is python ... which is ultra slow on ARM in itself | 12:52 |
| ogra_ | longsleep, thanks ! | 12:52 |
| Chipaca | jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684 <- fixed prereq's | 12:52 |
| ppisati | CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y is the default on 4.2 rpi2 too | 12:56 |
| ppisati | so it was just a 3.19 thing | 12:56 |
| ppisati | ogra_: when you were referring to slowness, did it apply to 4.2 too? | 12:57 |
| ppisati | ogra_: because it's correct there | 12:57 |
| ogra_ | ppisati, i didnt measure it recently ... in my initial images it was really slow (1-2min to boot) .... with the last image i mostly booted remote | 12:58 |
| ogra_ | i have to prepare a new rpi image this week (nobody told me we'd release a new stable one this week, i thought that was planned for teh 17th) | 12:58 |
| ogra_ | i'll do some stopwatching :) | 12:59 |
| ppisati | ogra_: cool | 12:59 |
| longsleep | any reason why opencryptoki is in ubuntu-core stable? I just added bug #1503681 | 13:00 |
| ubottu | bug 1503681 in Snappy "opencryptoki.service fails to start" [Undecided,New] https://launchpad.net/bugs/1503681 | 13:00 |
| ogra_ | longsleep, weird, thats fixed | 13:01 |
| * ogra_ wonders if mvo did test on all ARM arches before doing that rushed release yesterday :/ | 13:01 | |
| longsleep | mhm the image i created yesterday has it installed | 13:02 |
| ogra_ | longsleep, its a duplicate in any case, let me find the bug | 13:02 |
| ogra_ | https://bugs.launchpad.net/snappy/+bug/1500020 | 13:02 |
| ubottu | Launchpad bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] | 13:02 |
| longsleep | let me compare it | 13:03 |
| ogra_ | ah, and i didnt milestone it so that mvo could have found it because asac didnt create a milestone | 13:03 |
| jdstrand | Chipaca: ok, I added it to the card | 13:03 |
| ogra_ | i fixed it in wily | 13:03 |
| mvo | ogra_: I ran on bbb and did not touch raspi | 13:03 |
| jdstrand | s/to the/to a/ | 13:03 |
| Chipaca | jdstrand: g'morning :) | 13:03 |
| jdstrand | Chipaca: hi! | 13:03 |
| mvo | ogra_: oh, in a meeting right now, but I can check right after that | 13:03 |
| ogra_ | mvo, right, but there are plenty bugfixes missing seemingly ... i asked asac for a milestone and he missed creating one during the sprint | 13:03 |
| ogra_ | so the open bugs are all not milestoned | 13:04 |
| jdstrand | Chipaca: it will likely be a couple of days-- sarnold is swamped with other reviews | 13:04 |
| jdstrand | Chipaca: hey, do you know who implemented socket* and listen-stream? | 13:04 |
| ogra_ | mvo, but therer are some regressions due to stuff that was added for amd64 | 13:04 |
| Chipaca | jdstrand: the chipacacentric worldview is disappointed | 13:04 |
| Chipaca | jdstrand: mvo iirc | 13:05 |
| jdstrand | ok thanks | 13:05 |
| jdstrand | mvo: I know you're in a meeting. after the meeting when its convenient, can you ping me re socket* and list-stream? | 13:05 |
| jdstrand | listen* | 13:05 |
| longsleep | ogra_: i see, well the comment says that the writable path should be added, it has not been added for ubuntu-core 6 - at least the one i got | 13:06 |
| ogra_ | longsleep, yeah, thats broken | 13:06 |
| longsleep | ogra_: ubuntu-core 6 has 0.6.15 of ubuntu-core-config - thats why - fixed in 0.6.29 | 13:07 |
| ogra_ | longsleep, thats correct, as i said there is a bunch of regressions that werent fixed | 13:07 |
| ogra_ | (and vivid has 0.6.15, which is correct too) | 13:08 |
| longsleep | ok good, so how can i close 1503681 as duplicate | 13:08 |
| longsleep | ah found it | 13:09 |
| ogra_ | longsleep, done | 13:09 |
| longsleep | ok thanks :) | 13:09 |
| mvo | ogra_: do you have bugs already for the regressions? | 13:17 |
| mvo | jdstrand: ok, I will ping you | 13:17 |
| ogra_ | mvo, i have to dig them up, bug 1500020 is definitely one | 13:17 |
| ubottu | bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/1500020 | 13:17 |
| ogra_ | i had three, i think i closed two of them already | 13:18 |
| ogra_ | all regessions from the last additions of packages for the amd64 images | 13:18 |
| ogra_ | we definitely need to improve our milestone process for bugs ... perhaps just create ten in advance in LP or so so that doesnt get forgotten | 13:19 |
| mvo | jdstrand: back | 13:36 |
| jdstrand | mvo: hi! | 13:36 |
| mvo | ogra_: yeah, this time the sprint made the timing really awkward | 13:37 |
| jdstrand | mvo: I am writing up some documentation and noticed the new socket* and listen-stream directives for services. can you give me a two sentence summary of the feature? | 13:37 |
| jdstrand | (just so we are on the same page-- I think I know what's going on from the docs, but I have followup questions) | 13:38 |
| mvo | jdstrand: hm, it allows socket activated daemons with snappy | 13:38 |
| mvo | jdstrand: the patch comes from kickinz1 for docker | 13:39 |
| jdstrand | I see | 13:39 |
| mvo | jdstrand: I think its somewhat documented in meta.md | 13:39 |
| jdstrand | mvo: listen-stream says "The full path of the stream socket". is this a named socket? | 13:39 |
| * jdstrand was looking at https://developer.ubuntu.com/en/snappy/guides/package-metadata/ | 13:39 | |
| mvo | uh, its poorly documented in docs/meta.md - but at least its mentioned | 13:40 |
| mvo | jdstrand: it can be both a path or a abstract socket with @foo | 13:41 |
| mvo | jdstrand: or a port (haven't tested that though) | 13:41 |
| jdstrand | mvo: are there any checks to make sure that a named path falls within the app-specific directories? does the abstract socket use namespacing? (eg, if pkgname is foo, check that abstract matches @foo_...) | 13:42 |
| mvo | jdstrand: its essentially what SYSTEMD.SOCKET(5) is doing | 13:42 |
| mvo | jdstrand: no checks currently, no | 13:42 |
| jdstrand | ok, so I can make some review tools checks for those | 13:42 |
| jdstrand | basically, I'll say its ok if it matches the app-specific TMPDIR or SNAP_APP_DATA_PATH | 13:43 |
| jdstrand | and I'll do what I suggested for the abstract socket | 13:43 |
| jdstrand | mvo: does that sound reasonable? | 13:43 |
| mvo | jdstrand: yes! | 13:43 |
| mvo | jdstrand: thanks a lot! | 13:43 |
| jdstrand | ok | 13:43 |
| jdstrand | now, for the bit that really concerns me: socket-user and socket-group | 13:44 |
| jdstrand | we don't assign UIDs or GIDs | 13:44 |
| jdstrand | how are these supposed to work? | 13:44 |
| mvo | jdstrand: welllllll they work for docker because there is a docker user on the image, but they don't work for anything else right now | 13:45 |
| jdstrand | right | 13:45 |
| jdstrand | ok | 13:45 |
| mvo | so maybe we should not expose that option while there is no way to add users ? | 13:45 |
| jdstrand | mvo: so I will just flag those if they are specified at all. when we support UID and GID per-snap (I was thinking this would be opt-in), we can check that it matches that | 13:46 |
| mvo | makes sense | 13:46 |
| jdstrand | mvo: clearly docker needs it. it is probably a doc change | 13:46 |
| jdstrand | either don't expose it in the doc at all, or mention that it will flag a manual review | 13:47 |
| jdstrand | mvo: how about I add a bug for the review tools and add a snappy task to update the docs so there is a little more information? | 13:48 |
| jdstrand | mvo: and I'll submit an MP for that | 13:48 |
| mvo | jdstrand: +1 | 13:48 |
| jdstrand | ok. it won't be until the end of the week/next week | 13:49 |
| jdstrand | mvo: thanks for walking me through this | 13:49 |
| mvo | thats fine! thank you! | 13:49 |
| jdstrand | mvo: can listen-stream to a relative path or just absolute path? | 13:52 |
| mvo | jdstrand: I think it has to be absolute (which makes it interessting) | 13:54 |
| jdstrand | I can use current/ | 13:54 |
| * mvo nods | 13:56 | |
| jdstrand | mvo: btw, it seems that snappy build still doesn't run the tools by default | 14:03 |
| jdstrand | mvo: I thought we agreed they should? note, I think the tools ppa needs to have a review tools upload for the recent 'architectures' changes | 14:03 |
| mvo | jdstrand: let me check that, I was sure my branch got merged | 14:04 |
| jdstrand | mvo: maybe it is my local snappy that is out of date... | 14:05 |
| mvo | jdstrand: no, you are right | 14:05 |
| mvo | jdstrand: let me chase that | 14:05 |
| jdstrand | ok, I'll work to get the updated review tools into the ppa. again, it'll be a couple days (doc writing) | 14:06 |
| mvo | ok | 14:07 |
| === rickspencer3_ is now known as rickspencer3 | ||
| Chipaca | elopio: mvo: https://en.m.wiktionary.org/wiki/husk | 15:16 |
| Chipaca | anyway, i suck at names, so i'm all ears | 15:21 |
| elopio | Chipaca: call them "meta", that fixes everything :) | 15:44 |
| Chipaca | meta. | 15:44 |
| elopio | I'm ok with husks actually (after the explanation of course). I would call that peel, but what do I know? | 15:45 |
| Chipaca | elopio: thinking about it, hollejo is not the right word. Hollejo is the white thing under the orange skin and before the "gajos", for example | 15:47 |
| Chipaca | elopio: you know what chala (as in "humita en chala") is? that's a husk | 15:48 |
| Chipaca | the outer, leafy covering of corn is the husk | 15:48 |
| Chipaca | and you remove a husk by husking, which would've made it more confusing in code so i called it 'load' :-p | 15:49 |
| elopio | umm, yes. I think my mother calls hollejos the calluses in the fingers. I'm sure I've heard that somewhere, but not entirely sure where. | 15:49 |
| elopio | no, chala makes it worst. I've only heard chala rasta. I think they are from argentina. Not sure either. | 15:49 |
| Chipaca | https://upload.wikimedia.org/wikipedia/commons/1/13/Humitas_en_chala_tipicas_de_Argentina8.JPG | 15:50 |
| Chipaca | mmmmmmmmm | 15:50 |
| Chipaca | now i want some | 15:50 |
| elopio | Chipaca: you should write a husker interface, and propose it for golang upstream. I'm sure you'll be famous. | 15:50 |
| * Chipaca mumbles incoherently and gets back to work | 15:51 | |
| elopio | I think we call the "chalas of the corn" just "hojas". | 15:53 |
| elopio | and humita is something like tamal de elote. | 15:53 |
| * elopio goes for breakfast. | 15:53 | |
| mvo | Chipaca, elopio I still like something about lighweightThing, that makes it realtively easy to parse (although its a bit long :/ | 15:54 |
| * mvo gets dinner | 15:54 | |
| Chipaca | yep, long, is why i said maybe just use lightweight | 15:54 |
| Chipaca | elopio: re-review https://code.launchpad.net/~chipaca/snappy/systemimage-exported-consts/+merge/273479 if you get a moment please | 15:55 |
| elopio | exuvia | 15:56 |
| elopio | I doubt we can fix it, but I'm sure we can make it worst :) https://en.wikipedia.org/wiki/Exuvia#/media/File:Euscorpion_exuvia_2.jpg | 15:56 |
| Chipaca | exuvia works for me, but i thought it was a bit offbeat :) | 15:57 |
| Chipaca | love magicicada exuviae stuck to trees | 15:57 |
| elopio | Chipaca: approve, needs commit message. | 15:57 |
| Chipaca | on it | 15:58 |
| Chipaca | mvo: wrt https://code.launchpad.net/~chipaca/snappy/removed-pkg/+merge/273481, renamed it to RemoteManifestPath, want to take another look? | 16:08 |
| Chipaca | mvo: otherwise i'll top-approve :) | 16:08 |
| Chipaca | elopio: i didn't know exuviae is also another word for booty. +1 to exuvia. | 16:19 |
| elopio | I didn't know that either. I've learned so much today! | 16:20 |
| matiasb | hi there! quick question, if I'd want to get some review outcome for a snap package (uploaded to store, triggered manual review during auto-review), who should I ping? | 16:25 |
| elopio | matiasb: I don't understand. You want to cause your snap to trigger a manual review? | 16:27 |
| matiasb | elopio, nop, I submitted a package (a real one!), but it requires manual review, so I'm waiting for it (for a few days now) | 16:28 |
| elopio | matiasb: ah, generally it's Sergio who reviews them. | 16:29 |
| elopio | he's back tomorrow. | 16:29 |
| matiasb | elopio, ah, ok, thanks :) | 16:29 |
| elopio | beuno: can you give me permissions to look at the review queue? | 16:30 |
| beuno | elopio, they are rarely handed out. What for? | 16:40 |
| elopio | beuno: is there a staging I can look at? I just want to understand the process, and do some exploratory tests with snaps that require manual review. | 16:42 |
| beuno | elopio, they are the same ACL list. The process is: run the security scripts (lp:click-reviewer-tools), if they fail they get rejected. You can re-request a manual review, and someone clicks a button | 16:48 |
| elopio | beuno: ok, that works. matiasb is your source public? I would like to see the click-reviewer-tools failure in your branch. | 16:49 |
| beuno | elopio, click-reviewer-tools is public, the rest isn't | 16:50 |
| matiasb | elopio, I packaged transmission, so sources are public; re the errors, I can share a paste with them, but they are related to the fact that I had to tweak the default security profile | 16:51 |
| elopio | matiasb: w00t for transmission. | 16:51 |
| elopio | matiasb: yes, please paste the error. I'm just curious. I've just reviewed a branch with a test for the reviewer-tools and want to learn more about it to add more tests. | 16:53 |
| matiasb | elopio, http://paste.ubuntu.com/12706117/ | 16:53 |
| elopio | thank you. | 16:53 |
| matiasb | elopio, np, it doesn't say much, it complains I'm changing the sec profile :) | 16:54 |
| matiasb | I couldn't find another way to work around that | 16:55 |
| Chipaca | matiasb: wrt tweaking security profile, that's usually a "talk with jdstrand" | 16:58 |
| Chipaca | matiasb: and he, too, can do manual reviews, specifically for this scenario :) | 16:59 |
| matiasb | Chipaca, got it, thx; so, when jdstrand is around to take a look... :) | 17:02 |
| Chipaca | mvo: so, for when you return: 1. leave husk/Husk; 2. exuvia/Exuvia; 3. package lightweight, type PartList | 17:02 |
| Chipaca | mvo: husk.Byname -> lightweight.PartListByName, husks.All -> lightweight.AllPartLists | 17:04 |
| Chipaca | mvo: all others end up waaay too long imho :) | 17:04 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | Chipaca, matiasb: fyi, unless the app comes from a trusted vendor, we don't allow security-override or security-policy in the public store (a private store could allow it). having the source open is great, but the snap may not have been built from that source | 17:19 |
| jdstrand | matiasb: how extensive are the policy edits? perhaps they are bugs in the templated policy? | 17:19 |
| Chipaca | jdstrand: dude, we don't do "bugs". | 17:20 |
| Chipaca | they're miscomprehended teenager features | 17:20 |
| matiasb | jdstrand, understood; I had to add a few extras to the default templates, as specified in the comment there, happy to workaround if possible | 17:20 |
| jdstrand | matiasb: looking at what you put in the review, we could allow /proc/sys/kernel/random/uuid | 17:22 |
| jdstrand | matiasb: we can't allow mounts (info leak) | 17:22 |
| jdstrand | matiasb: and quotactl is potentially dangerous too. you should probably patch transmission to not need mounts and quatactl | 17:23 |
| matiasb | jdstrand, ack, got it; I'll take a look and check if that's possible | 17:24 |
| nessita | jdstrand, silly question, how would transmission workaround usage of quotactl since it needs to know if there is free space in disk to keep (or not) downloading torrents? | 17:24 |
| matiasb | jdstrand, so I guess I will let you know if I can fix that, thanks | 17:25 |
| nessita | ah, perhaps free disk space can be checked with other libraries | 17:26 |
| Chipaca | nessita: because snappy doesn't (yet? evar?) support quotas, just checking df is probably enough | 17:27 |
| ogra_ | would df work ? | 17:27 |
| ogra_ | (i guess it also needs access to /proc/mounts) | 17:28 |
| jdstrand | matiasb: the simplest would be to not perform that check at all. perhaps there is an actual alternative solution. | 17:28 |
| nessita | Chipaca, got it, thanks | 17:29 |
| ogra_ | (i mean, perhaps something like "df ." doesnt need it, never tired) | 17:29 |
| matiasb | jdstrand, probably, didn't review the sources in detail, but I guess it should be possible to work something out | 17:29 |
| Chipaca | ogra_: df . does need it :( | 17:30 |
| ogra_ | ah, sad | 17:30 |
| Chipaca | [101896.479363] audit: type=1400 audit(1444238994.246:13): apparmor="DENIED" operation="open" profile="hello-world.canonical_env_1.0.18" name="/bin/df" pid=1531 comm="env" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 17:30 |
| ogra_ | that is actually quite a drawback, i can imagine a lot usecases where apps would want to know the free space in SNAP_APP_DATA_DIR | 17:31 |
| Chipaca | maybe there's a way to allow just that? | 17:31 |
| ogra_ | i doubt any available tool can do that without /proc/mounts or at least without accessing info about the underlying disk SNAP_APP_DATA_DIR lives in | 17:32 |
| ogra_ | i could be wrong though | 17:32 |
| jdstrand | Log: apparmor="DENIED" operation="open" profile="hello-world.canonical_sh_1.0.18" name="/proc/3814/mounts" pid=3814 comm="df" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 17:33 |
| ogra_ | yeah | 17:33 |
| jdstrand | we need an out of process service | 17:33 |
| jdstrand | then we could allow talking to it | 17:33 |
| ogra_ | snappy freespace | 17:33 |
| jdstrand | df isn't in the policy now cause it needs /proc/*/mounts | 17:33 |
| jdstrand | well, not snappy | 17:34 |
| ogra_ | "SNAP_APP_DATA_DIR has 1254MB free" | 17:34 |
| jdstrand | apps can't use snappy :) | 17:34 |
| ogra_ | oh, indeed | 17:34 |
| jdstrand | snapd maybe | 17:34 |
| jdstrand | anyhoo, something our of process | 17:34 |
| jdstrand | out* | 17:35 |
| jdstrand | ogra_: hey, I have a couple of questions while I have you | 17:35 |
| * jdstrand pulls them up | 17:35 | |
| ogra_ | note that i'm not officially here :P ... but shoot | 17:35 |
| jdstrand | these are actually community type questions | 17:36 |
| jdstrand | ogra_: but please don't let me distract you from life :) | 17:36 |
| ogra_ | well, i'm on sick leave til tomorrow ... but pretty bored so just ask | 17:36 |
| Chipaca | jdstrand: that's ogra's way of saying, you've just got to make your questions more interesting that his alternatives | 17:38 |
| jdstrand | ogra_: do you know if there is a way or if we plan to enable via snappy config ubuntu-core to setup remove logging? ie, tell rsyslogd to send its logs to another syslog server? /etc/rsyslog.d is not a writable-path and systemd's journal doesn't do rfc syslog | 17:38 |
| jdstrand | for me personally, making /etc/rsyslog.d a writable-path would be sufficient | 17:38 |
| ogra_ | lets do that theen | 17:38 |
| jdstrand | but it sounds mildly interesting as an ubuntu-core config option | 17:38 |
| jdstrand | ok, I'll file a bug | 17:38 |
| ogra_ | sounds like something thats helpful in IoT cases and such | 17:38 |
| ogra_ | (and the fix is easy enough) | 17:39 |
| jdstrand | ogra_: next question. I tried to setup a static ip via snappy config ubuntu-core, and was successful. however, I didn't know how to setup the resolver. is that possible? | 17:39 |
| ogra_ | there are /e/n/i options (dns-servers ?) you should be able to use | 17:40 |
| * ogra_ checks his static snappy server | 17:40 | |
| jdstrand | oh, dns-servers are in there? I read the man page, I must've missed it | 17:40 |
| ogra_ | (amd64)ogra@aleph2:~$ grep dns /etc/network/interfaces.d/eth0 | 17:41 |
| ogra_ | dns-nameservers 8.8.8.8 | 17:41 |
| jdstrand | yeah, man interfaces doesn't have it | 17:41 |
| ogra_ | yeah, seems to work here | 17:41 |
| jdstrand | ok, awesome :) that probably needs a doc update for snappy config... | 17:41 |
| jdstrand | I'll file a bug on that too | 17:41 |
| ogra_ | well, thats not snappy specific ... i think it is resolvconf that uses it | 17:41 |
| jdstrand | right | 17:42 |
| jdstrand | but my point it, it wasn't in 'man interfaces' either | 17:42 |
| jdstrand | so I had no way to discover it | 17:42 |
| ogra_ | right, if we added it we should have patched the manpage | 17:42 |
| ogra_ | ah, wait | 17:43 |
| jdstrand | cause it wasn't there or a snappy example. there is a snappy example for static ip (which I used), but it doesn't include dns-nameservers | 17:43 |
| ogra_ | man resolvconf has it | 17:43 |
| jdstrand | which meant I got an ip address great, but couldn't do much | 17:43 |
| ogra_ | yeah | 17:43 |
| ogra_ | we should add it to the example | 17:43 |
| jdstrand | I'll file a bug | 17:43 |
| ogra_ | thx | 17:43 |
| jdstrand | next question: is there a way to setup the ntp servers? | 17:44 |
| ogra_ | hmm | 17:44 |
| jdstrand | they seem to try to reach out to the pool ones | 17:44 |
| jdstrand | with no way to point to an internal one | 17:44 |
| jdstrand | s/internal/another/ | 17:44 |
| * ogra_ reads /etc/network/if-up.d/ntpdate | 17:44 | |
| * jdstrand doesn't have that file on latest snappy stable | 17:45 | |
| ogra_ | /etc/default/ntpdate | 17:46 |
| ogra_ | oh ? | 17:46 |
| ogra_ | do we already have timedated ? | 17:46 |
| jdstrand | I don't have /etc/default/ntpdate either | 17:46 |
| jdstrand | systemd+ 488 0.0 0.0 100276 2532 ? Ssl Oct06 0:01 /lib/systemd/systemd-timesyncd | 17:46 |
| jdstrand | is that the same thing? | 17:47 |
| ogra_ | no, thats the new thing | 17:47 |
| ogra_ | which i dont know much about yet | 17:47 |
| ogra_ | ah | 17:47 |
| ogra_ | it has a -H <host> option | 17:47 |
| ogra_ | now i'm not sure where to configure it ... | 17:48 |
| jdstrand | I guess that is /etc/systemd/timesyncd.conf | 17:48 |
| jdstrand | http://www.freedesktop.org/software/systemd/man/timesyncd.conf.html | 17:48 |
| jdstrand | but it is not a writable-path | 17:48 |
| ogra_ | so we need to add that one too | 17:48 |
| jdstrand | ok, I'll file a bug for that too | 17:48 |
| ogra_ | yeah, seems you can just set NTP= | 17:49 |
| ogra_ | pointing to a server | 17:49 |
| jdstrand | the last is sshd_config. it *is* a writable path. I'm just curious if there are plans to do more with it via snappy config | 17:49 |
| ogra_ | that i dont know :) | 17:50 |
| ogra_ | wouldnt be hard to add i guess | 17:50 |
| jdstrand | well, I'm not trying to create more work | 17:50 |
| ogra_ | it is riteable because cloud-init generates the keys in that dir | 17:50 |
| jdstrand | even though I did. though just barely :) | 17:50 |
| ogra_ | well, useful work ... everything you asked about is valid :) | 17:51 |
| jdstrand | cool and thanks-- this was quite helpful | 17:51 |
| ogra_ | :) | 17:51 |
| * Chipaca adds df to the rest api | 17:51 | |
| jdstrand | ogra_: hope you feel better and try not to be too bored :) | 17:51 |
| ogra_ | i'm fine, i had drilled some screw anchors into my jaw last thu ... recovery is in the last stages | 17:52 |
| * Chipaca watches the rest api get in a race with systemd for what's left of posix | 17:52 | |
| ogra_ | we should fork systemd to systemd-posix | 17:53 |
| ogra_ | ;) | 17:53 |
| ogra_ | seems forking is in fashion currently | 17:53 |
| * ogra_ just saw the news about mjg59 | 17:53 | |
| * ogra_ goes back to icepack->cheek | 18:00 | |
| Chipaca | jdstrand: ogra_ | 21:15 |
| Chipaca | (amd64)ubuntu@localhost:~$ hello-world.env | 21:15 |
| Chipaca | /writable has 368392 blocks of 4096 bytes available (~93.390998%) | 21:15 |
| Chipaca | jdstrand: ogra_: http://pastebin.ubuntu.com/12709065/ | 21:16 |
| Chipaca | oh, also matiasb ^ | 21:16 |
| matiasb | nice! | 21:17 |
| matiasb | Chipaca, how can I use that? | 21:17 |
| * matiasb looks the pastebin | 21:17 | |
| Chipaca | matiasb: gcc -D_GNU_SOURCE -Wextra -Werror -o /tmp/fakedf /tmp/fakedf.c | 21:17 |
| matiasb | Chipaca, awesome, will try it when I get a few | 21:18 |
| Chipaca | matiasb: then, fakedf $SNAPP_APP_DATA_PATH | 21:18 |
| Chipaca | or fakedf $SNAP_APP_USER_DATA_PATH | 21:19 |
| Chipaca | s/SNAPP/SNAP/ soz | 21:19 |
| Chipaca | and apparently that's enough :) | 21:19 |
| Chipaca | matiasb: also python has statvfs which is the same call, if you're doing python | 21:19 |
| matiasb | Chipaca, this is for transmission, so C should be | 21:20 |
| Chipaca | matiasb: and man 3 statvfs for the fields in the struct if you need some other info | 21:20 |
| matiasb | Chipaca, perfect, thx! | 21:21 |
| Chipaca | np | 21:21 |
| Chipaca | maybe we should ship this :) | 21:21 |
| Chipaca | hah! we already do | 21:37 |
| Chipaca | /usr/bin/stat | 21:37 |
| Chipaca | jdstrand: ogra_: (dunno if you're still interested in this, but) e.g. “/usr/bin/stat -f -c "%a * %s" /writable/” | 21:41 |
| jdstrand | Chipaca: oh, nice! :) | 21:43 |
| Chipaca | megabytes: echo $(($(/usr/bin/stat -f -c '%a * %s/1024/1024' /writable/))) | 21:43 |
| * jdstrand add a note to update snappy-security to recommend that | 21:43 | |
| * Chipaca stops | 21:43 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
