| wigleworm | anyone online | 03:09 |
|---|---|---|
| === ruenoak1 is now known as ruenoak | ||
| === chihchun is now known as chihchun_afk | ||
| elopio | wigleworm: more or less. About to leave | 05:17 |
| elopio | pitti: I think I found my problem. I'm creating a keypair for scalingstack, and then I need to pass the private key to ssh -i. But the nova script tries to connect to ssh without specifying the private key, so it times out. | 05:19 |
| elopio | I have solved it for now putting the private key in ~/.ssh/config. | 05:19 |
| elopio | now I need tons of squid exceptions, but it's running the whole suite. | 05:20 |
| pitti | elopio: right, you need to upload your ssh key to nova with keypair-create | 06:21 |
| pitti | elopio: if you only have one key in "nova keypair-list", then the setup script will use that, otherwise you have to add a --keyname option to chose the one you want | 06:22 |
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 07:37 |
| didrocks | hey dholbach! | 07:40 |
| dholbach | salut didrocks | 07:41 |
| === kickinz1|afk is now known as kickinz1 | ||
| fgimenez | good morning | 08:12 |
| ysionneau | any idea why I'm not able to ping anything from snappy? name resolution works, and I was able to snappy install nethack-armhf.ogra so network seems approximately ok | 08:46 |
| ysionneau | is there some telnet client that I can install? | 08:46 |
| didrocks | ogra_: hey! stupid question, but how is the grub.cfg taken from the gadget snap in 16.04? I don't see any bindmount or anything to it | 09:16 |
| longsleep | Hey snappy, so what is the best strategy to convert a snap for 15.04 to one for 16.04? | 09:37 |
| JamesTait | Good morning all; happy Tuesday, and happy Innovation Day! 😃 | 09:40 |
| popey | hELLO! | 09:52 |
| popey | Do I need to jump through hoops to make wifi work on the Pi2 snappy images or will it "just work"? | 09:52 |
| didrocks | popey: depends on the version :) | 09:53 |
| didrocks | popey: which one are you trying? | 09:53 |
| popey | the one from mvo's home | 09:54 |
| popey | built 4/2/16 | 09:54 |
| didrocks | ok, so 16.04, you just need to create the wlan0 file then | 09:54 |
| didrocks | uno momento | 09:54 |
| didrocks | popey: http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html | 09:55 |
| didrocks | popey: from "Create a config file for your wlan0 interface: | 09:55 |
| didrocks | " | 09:55 |
| didrocks | (ignore the above) | 09:55 |
| didrocks | popey: I don't have a wifi module, so didn't test myself | 09:55 |
| popey | hm, okay | 09:57 |
| * popey plugs into ethernet for now (I assume that works OOTB)? | 09:57 | |
| didrocks | popey: yeah, it does | 09:59 |
| didrocks | popey: I even share my laptop wifi connection through ethernet here | 09:59 |
| popey | didrocks: on wired, does it do dhcp by default or do I need to plug a physical kb/screen in before I can use it? | 10:01 |
| popey | (I don't see it listed on my dhcp server) | 10:01 |
| didrocks | popey: it does dhcp client by default | 10:02 |
| popey | hmmm | 10:02 |
| didrocks | popey: tried rebooting (unsure it has hotplug support though, even if it's auto eth0)? | 10:03 |
| popey | had to plug it into a telly and ifconfig to find out the ip | 10:05 |
| popey | for some reason it's not showing up on my dhcp server, but it has an ip | 10:05 |
| popey | most strange | 10:05 |
| popey | ubuntu@localhost:~$ | 10:05 |
| popey | \o/ | 10:05 |
| didrocks | good! :) | 10:05 |
| didrocks | (and phew, "just" have to blame your dhcp server :p) | 10:05 |
| popey | this command requires root access. Please re-run using 'sudo' | 10:06 |
| popey | that should have a capital letter at the start | 10:06 |
| popey | #justsaying | 10:06 |
| popey | 😃 | 10:06 |
| popey | ugh, all messages in errors.go are badly capitalised. My eyes! | 10:10 |
| didrocks | popey: yeah, I was looking at the same. I'm unsure this is on purpose (like combining with "Error:") or something else | 10:10 |
| popey | it can't be intentional, or if it is, it's inconsistent | 10:11 |
| popey | "this command requires root access. Please re-run using 'sudo'" - "this" lowercase "t", "Please" uppercase "P". | 10:12 |
| didrocks | well, you have a full stop in between | 10:12 |
| didrocks | the consistency is in all sentences are starting in this file with no capital | 10:13 |
| didrocks | like if they wanted to prepend "Error: {}" | 10:13 |
| didrocks | so the result would be: "Error: this command requires root access. Please re-run using 'sudo'" | 10:13 |
| didrocks | (which is consistent) | 10:13 |
| popey | okay. still looks odd (and is inconsistent with other things like the kernel). I'll not worry about that 😃 | 10:17 |
| popey | :( failed in my first step in the guide. trying to "snappy install docker hello-world" | 10:19 |
| popey | docker failed to install: can not open /tmp/docker963014042: cannot open snap: unknown header: "!<arch>\ndebian-binar" | 10:19 |
| didrocks | popey: yeah, that's the current issue with 16.04… | 10:20 |
| didrocks | popey: it's all moving right now, and the store isn't yet snap-all compatible (it shows you old snaps that are still ar-based) | 10:20 |
| popey | ah, okay. | 10:21 |
| popey | Living life on the edge :) | 10:22 |
| ogra_ | didrocks, i think u-d-f puts it in place | 10:32 |
| didrocks | ogra_: ah, so it's a copy when generating the image, but what if you update the gadget snap thus? | 10:32 |
| popey | What's the replacement for "snappy search"? | 10:33 |
| ogra_ | popey, snap find | 10:33 |
| ogra_ | didrocks, you have to ask mvo if he added cod to copy it then (i havent seen any) | 10:34 |
| ogra_ | *code | 10:34 |
| popey | that's not listed in the --help :( | 10:34 |
| popey | and snappy find doesn't work | 10:34 |
| didrocks | popey: *snap* | 10:34 |
| popey | oh, snap? | 10:34 |
| didrocks | new snappy name from what I know | 10:34 |
| ogra_ | yeah, because we like to be intuitive ;) | 10:34 |
| didrocks | even if I never saw anything written down | 10:34 |
| popey | so snappy -> apt-get, snap -> click/pkcon? | 10:35 |
| popey | kinda | 10:35 |
| didrocks | no, I think snappy will move to snap, right? | 10:35 |
| didrocks | and commands will transition one after another? | 10:36 |
| didrocks | (ogra_ probably knows more than I here, I just saw this command being mentioned once) | 10:36 |
| ogra_ | i have no idea ... it might be documented in some google doc though | 10:37 |
| * ogra_ also only picked it up from IRC conversations | 10:37 | |
| ogra_ | i assume we want to put all operations you can do directly to a snap into that command ... though looking at the --help output "find" somehow doesnt fit there | 10:38 |
| didrocks | zyga: you probably know more than us there then ^ | 10:39 |
| didrocks | zyga: snap vs snappy command (will they eventually merge into one?) | 10:39 |
| popey | dholbach: https://developer.ubuntu.com/en/snappy/build-apps/get-started/ says i should install snappy-tools to get snapcraft, I had to manually install snapcraft itself, it wasn't pulled in by snappy-tools | 10:40 |
| popey | dholbach: want me to file a bug? | 10:40 |
| zyga | popey: hey | 10:47 |
| zyga | er | 10:47 |
| zyga | didrocks: hey :) | 10:47 |
| zyga | didrocks: snap is the new version of snappy command | 10:47 |
| zyga | didrocks: snap works over the REST api and talks to snapd | 10:47 |
| zyga | didrocks: snappy is the old command that has everything inside | 10:47 |
| zyga | didrocks: snappy will be removed before 16.04 | 10:48 |
| zyga | didrocks: and we'll just have one | 10:48 |
| didrocks | I was right \o/ | 10:48 |
| didrocks | thanks for confirming zyga :) | 10:48 |
| ogra_ | ah, good to see a proper summary, thanks zyga | 10:49 |
| zyga | ogra_: lots of things are in snap today | 10:49 |
| zyga | ogra_: but daily builds are broken so we don't see that | 10:49 |
| ogra_ | ? | 10:49 |
| ogra_ | daily builds of what ? | 10:49 |
| zyga | ogra_: and daily builds are broken because of launchpad git model choking on gpg signed git commits | 10:49 |
| zyga | ogra_: of snappy itself | 10:49 |
| * ogra_ didnt see any build failures | 10:49 | |
| zyga | ogra_: mvo found this yesterday or last week | 10:50 |
| ogra_ | oh, it fails before it even attempts to build ? | 10:50 |
| zyga | ogra_: we have a backup plan to just do manual git pull github; git push launchpad | 10:50 |
| zyga | ogra_: yes, the import is stuck now | 10:50 |
| ogra_ | ah, that explains why i see no failures :) | 10:50 |
| zyga | ogra_: I'm sure we'll untangle this as the sprint develop | 10:50 |
| ogra_ | right | 10:50 |
| popey | when's that? | 10:50 |
| ogra_ | this week | 10:51 |
| zyga | popey: well, this week | 10:51 |
| popey | heh | 10:51 |
| zyga | popey: ask mvo for details | 10:51 |
| popey | no need, just wondered :) | 10:51 |
| zyga | popey: we could do a plan-B in 30 minutes or so | 10:51 |
| * popey sets expectations accordingly :) | 10:51 | |
| zyga | popey: but I wanted to sync with mvo to see who's going to do that | 10:51 |
| * ogra_ actually prefers outdated but working over landed but broken (and nobody there to fix it) state | 10:52 | |
| zyga | ogra_: daily is broken too :) | 10:53 |
| zyga | ogra_: but differently, no executable seems to run today | 10:53 |
| ogra_ | i can use it here | 10:53 |
| zyga | ogra_: as in real master, not the outdated build from lp | 10:53 |
| ogra_ | right, so just leave LP as is until everyone is back ;) | 10:53 |
| zyga | ogra_: do you have any updates on dragon kernel/gadget? | 10:57 |
| ogra_ | zyga, done, i just need to roll an image and push it up | 10:58 |
| zyga | ogra_: nice, I can offer simple testing on my board to iron our works-for-me issues :) | 10:58 |
| ogra_ | it doesnt resize yet, and systemd spills a few rfkill messages on boot ... the rest should be all fixed | 10:59 |
| ogra_ | (i ripped resize out completely for now so it doesnt break on big SD cards anymore) | 10:59 |
| ogra_ | sudo ./ubuntu-device-flash --verbose core rolling --channel edge -o dragon-all-snap-test.img --gadget canonical-dragon.canonical --kernel canonical-dragon-linux --os ubuntu-core.canonical | 11:00 |
| zyga | ogra_: yeah I've seen those | 11:00 |
| zyga | ogra_: oh that a nice touch, thanks | 11:00 |
| ogra_ | (with mvo's u-d-f binary) | 11:00 |
| zyga | ogra_: so essentially, ubuntu-image dragon :-) | 11:00 |
| * zyga rebuilds | 11:00 | |
| zyga | ogra_: building now, I'll let you know when it boot | 11:02 |
| ogra_ | good | 11:02 |
| zyga | flashing | 11:08 |
| zyga | I should write the flash tool | 11:12 |
| zyga | all I want is a freeling progress bar | 11:12 |
| zyga | ogra_: for the first time I can also measure power usage of my dragon board, if you ever want to experiment with some tweaks to the kernel, I can give that a go | 11:14 |
| ogra_ | zyga, there is godd, that has a progressbar | 11:16 |
| zyga | oh, thanks, I'll give it a try next | 11:16 |
| * ogra_ doesnt want no shitty progressbar ... i just want it to flash 10x as fast instead :P | 11:17 | |
| zyga | ogra_: booting now | 11:20 |
| zyga | ogra_: flash over usb3.0 | 11:20 |
| zyga | ogra_: on a speedy card | 11:20 |
| ogra_ | i do ... still takes ages | 11:22 |
| davmor2 | ogra_: b.....b....but without progress bars you wouldn't have a break to go make coffee | 11:22 |
| ogra_ | davmor2, true indeed :) | 11:22 |
| zyga | ogra_: boot done | 11:23 |
| zyga | ogra_: is the mac address stable now? | 11:23 |
| ogra_ | yep | 11:23 |
| zyga | ogra_: perfect, let's update my mac tables | 11:23 |
| zyga | ogra_: wifi operates too | 11:23 |
| ogra_ | i still need to make the code a bit more generic, but the function is fine | 11:23 |
| zyga | ogra_: so +1 from me, works like a charm | 11:23 |
| * zyga posted https://github.com/ubuntu-core/snappy/pull/490 and https://github.com/ubuntu-core/snappy/pull/489 | 11:58 | |
| popey | Is there any prospect of snapcraft 2.x being backported to trusty? | 12:00 |
| popey | the ppa still has snapcraft 1.x | 12:00 |
| ogra_ | no, 2.x is solely for xenial | 12:02 |
| ogra_ | use a xenial chroot, container or use the classic dimension on your xenial snappy install | 12:03 |
| popey | thats what i am doing | 12:03 |
| popey | but my laptop is 14.04 | 12:03 |
| popey | so i have a difference between them | 12:03 |
| ogra_ | between the chroots ? | 12:03 |
| popey | will create a xenial chroot on my laptop, ta | 12:03 |
| ogra_ | ah | 12:03 |
| popey | no, between 14.04 on my laptop and xenial on my pi | 12:03 |
| ogra_ | yeah | 12:03 |
| popey | nvm, it's cool :) | 12:03 |
| ogra_ | well, there is no cross building ... so after all you want to use the classic dimension on your pi to get armhf packages | 12:04 |
| popey | yeah, i was building on my laptop then copied the yaml over to the pi in classic and found the syntax differed | 12:06 |
| popey | of both the yaml and snapcraft itself | 12:06 |
| popey | which is what made me look at the versions | 12:06 |
| popey | woot, made a snap | 12:06 |
| ogra_ | yay | 12:07 |
| ogra_ | ooooh ! | 12:07 |
| * ogra_ found his next snap | 12:07 | |
| ogra_ | https://github.com/coolwanglu/BrowserHack | 12:07 |
| ogra_ | (i already packaged nethack, but this is even cooler) | 12:09 |
| popey | bah, can't find some perl libs | 12:12 |
| ogra_ | add them to stage-packages | 12:13 |
| popey | is it a comma separated list? stage-packages: [foo,bar,baz] ? | 12:15 |
| ogra_ | http://paste.ubuntu.com/15090658/ | 12:16 |
| ogra_ | thats a snapcraft 2.1 file though ... the security stuff is different now | 12:16 |
| popey | ok | 12:16 |
| * popey will play | 12:17 | |
| kyrofa | Good morning | 12:20 |
| * zyga finds classic dimension fantastic and uses it for daily work | 12:27 | |
| * ogra_ misses it on arm64 :P | 12:27 | |
| didrocks | hey kyrofa! | 12:44 |
| kyrofa | Hey didrocks, how's your week so far? | 12:45 |
| didrocks | kyrofa: it's quite good, thanks! Working on the developer website, but can't wait to be able to dive into the more technical aspect of snappy once 16.04 settles down :) | 12:45 |
| didrocks | (and be able to work more closely with you guys) | 12:46 |
| kyrofa | didrocks, awesome! Well we look forward to that, too :) | 12:46 |
| kyrofa | didrocks, how many times have you looked at a Snappy question on, say, stack overflow, become completely confused, only to realize that it's Google's snappy compression lib? | 12:48 |
| noizer | Hi the system variable for the snaps path? | 13:23 |
| didrocks | kyrofa: ah, that didn't happen yet (sorry, was on a meeting) :p | 13:35 |
| didrocks | kyrofa: for me, it was more snappy ubuntu core vs ubuntu core ;) | 13:36 |
| didrocks | (like our old named ubuntu core) | 13:36 |
| kyrofa | didrocks, ah, right | 13:36 |
| kyrofa | didrocks, well, keep an eye out if your subscriptions span more than askubuntu | 13:37 |
| didrocks | kyrofa: will do, even just for the sake of fun :p | 13:37 |
| kyrofa | didrocks, :D | 13:37 |
| dholbach | popey, I'll file a bug | 13:46 |
| ogra_ | kyrofa, pfft ... compression lib .... | 13:51 |
| ogra_ | ogra@styx:~/Devel/mycroft$ apt-cache show snappy|grep Description | 13:51 |
| ogra_ | Description-en: Powerful media player with a minimalistic interface | 13:51 |
| ogra_ | :P | 13:51 |
| kyrofa | ogra_, wait... :P | 13:51 |
| ogra_ | hmm, we dont ship hdparm in the rootfs ... i wonder if we should | 13:56 |
| popey | dholbach: okay | 14:00 |
| popey | hm, adding the perl-modules package to my stage-packages: has no effect, it doesn't get bundled into the snap | 14:02 |
| ogra_ | in a copy plugin ? | 14:02 |
| popey | ah | 14:04 |
| ogra_ | (not sure how stage-packages behave in other plugins, i always ever used them in that context ) | 14:05 |
| popey | is the "files" section documented somewhere? | 14:06 |
| ogra_ | well, "source: destination" | 14:07 |
| ogra_ | (relative paths) | 14:07 |
| popey | does it not assume same path | 14:11 |
| popey | ? | 14:11 |
| ogra_ | only for the toplevel | 14:13 |
| ogra_ | aha, found the issue with rfkill .... systemd wants a dir /var/lib/systemd/rfkill and wants that writable | 14:15 |
| ogra_ | werid though, i thought we had added that to /etc/system-image/writable-paths before ... but seems we didnt | 14:17 |
| zyga | ogra_: nice | 14:20 |
| zyga | ogra_: that's going to fix rfkill for all systems, right? | 14:20 |
| ogra_ | well, it is going to quieten the systemd error .... not sure thats enough to fix the low level | 14:22 |
| === chihchun is now known as chihchun_afk | ||
| elopio | pitti: yes, I create the keypair and pass it with --keyname. The thing is that if the keypair I create doesn't have the same private key as the entry in ~/.ssh/config there's no way to tell nova which private key it should use. | 14:44 |
| elopio | ogra_: happy birthday!!!! | 14:44 |
| ogra_ | elopio, thanks ! | 14:44 |
| === chihchun_afk is now known as chihchun | ||
| popey | Oooh! Congratulations ogra_ for clinging to this rock for another solar orbit. Well done you! | 14:45 |
| ogra_ | haha, thansk :) | 14:46 |
| ogra_ | *thanks even | 14:46 |
| pitti | hey ogra_, happy birthday! *hug* | 14:47 |
| ogra_ | thanks ! | 14:47 |
| kyrofa | Ah, happy birthday ogra_! | 14:49 |
| ogra_ | thanks ! | 14:49 |
| asac | ppisati: so i chatted to the linaro qemu guy | 14:49 |
| asac | ppisati: he said we could try to build the u-boot as the bios image | 14:49 |
| asac | to get a qemu that boots with u-boot | 14:49 |
| asac | 15:48 < pm215> build it to expect to start at address 0 with the usual ARM interrupt/exception vector table | 14:50 |
| asac | 15:48 < pm215> ie as if you were going to burn the thing into rom | 14:50 |
| asac | ppisati: ^^ means anything? | 14:51 |
| ogra_ | sound like "dd it to the start of your img file" | 14:51 |
| elopio | fgimenez: I might be 10 minutes late to our meeting. I'm running to get back on time. bbs. | 14:51 |
| asac | ogra_: right, but guess thats not all | 14:53 |
| asac | probably needs more tweaking of init values etc.? | 14:53 |
| ogra_ | depends | 14:53 |
| ogra_ | hmm ... i wonder if all-snaps supports me sideloading ubuntu-core on a running image (i.e. manual upgrade) | 14:54 |
| ogra_ | Installing ubuntu-core_16.04.0-4.arm64_arm64.snap | 14:56 |
| ogra_ | ubuntu-core_16.04.0-4.arm64_arm64.snap failed to install: package "ubuntu-core" is already installed with origin "canonical" your origin is "sideload" | 14:56 |
| ogra_ | ah, sad | 14:56 |
| ogra_ | would have been nice for testing | 14:56 |
| ppisati | asac: never faffled with uboot internals, so i don't know | 14:57 |
| ppisati | asac: qemu versatile / vexpress? | 14:57 |
| fgimenez | elopio, ok, no problem | 14:59 |
| asac | ppisati: he says we should use "virt" unless we have special requirements | 14:59 |
| asac | not sure what virt means | 15:00 |
| Dikkekip | hi there, i'm new to the whole docker infrastructure. but i'm looking for a way to make a docker webserver. but i see there are a lot off options out there. what is to be preferred? | 15:03 |
| Dikkekip | coreos | 15:03 |
| Dikkekip | vs ubuntu | 15:03 |
| Dikkekip | kubernetes vs shipyard | 15:04 |
| Dikkekip | who wins? | 15:04 |
| ogra_ | are you sure you are in the right channel ? | 15:05 |
| Dikkekip | nope | 15:05 |
| ogra_ | :) | 15:05 |
| Dikkekip | but i'm asking the guys who use ubuntu | 15:05 |
| ogra_ | sounds like you want to be in #cloud-battle :) | 15:05 |
| davmor2 | ogra_: man it seem like only yesterday you were a year younger, Congrats and Happy Birthday dude :) | 15:08 |
| ogra_ | davmor2, thanks a lot dude ! | 15:08 |
| asac | pitti: so i see a huge number of .service files in /lib/systemd/system/ | 15:59 |
| asac | are all those run ? | 15:59 |
| didrocks | asac: you need to look at the *.requires/ or *.wants/ ones | 16:00 |
| asac | didrocks: so in /lib/systemd/system is the superset of all you can use | 16:01 |
| didrocks | asac: right! | 16:01 |
| asac | and then in .wants and requires is the actual stuff linked? | 16:01 |
| asac | like mods-available and -enabled for apache? | 16:01 |
| asac | kk | 16:01 |
| didrocks | systems ones that you can't disable are in /lib/systemd/system/*.{wants,requires} | 16:01 |
| didrocks | the ones you are enabling/disabling manually are in /etc/systemd/system/ | 16:01 |
| didrocks | (and you can also creates services there) | 16:02 |
| asac | yeah. so i guess we could remove all those that we dont want/require on a snappy system from /lib/system/ and noone would notice? | 16:02 |
| didrocks | ofc, you have the socket activated ones in addition to this (and timer, but we don't use them much) | 16:02 |
| asac | e.g. cruft? | 16:02 |
| didrocks | asac: yeah, if they are enabled on a system level (in /lib) and we want to mask them, we can symlink with the same file name to /dev/null | 16:02 |
| didrocks | (again, same with path/socket/timer activation) | 16:03 |
| asac | i am not sure | 16:03 |
| asac | i thought everythign not .wants or .requires is not used at all | 16:03 |
| asac | from /lib/systemd/system/ | 16:03 |
| asac | can we not remove all of those then? | 16:03 |
| didrocks | normal services not in .wants or .requires are not activated the regular way (and will never be activated normally) | 16:04 |
| didrocks | unless a socket/path/timer activates them | 16:04 |
| didrocks | asac: if you have docker install, look at /lib/systemd/system/docker.socket | 16:04 |
| didrocks | you see PartOf=docker.service | 16:04 |
| didrocks | so docker.service can be activated by the docker.socket | 16:05 |
| didrocks | and /etc/systemd/system/sockets.target.wants/ has a link to docker.socket | 16:05 |
| didrocks | (so the socket service is activated via the sockets.target, which in turn, can activate docker.service when it receives something in the socket) | 16:06 |
| didrocks | on* | 16:06 |
| asac | didrocks: do socket activated services get killed if the socket client closes or dies? | 16:07 |
| didrocks | asac: with PartOf= yeah | 16:07 |
| didrocks | (it's double linked IIRC) | 16:07 |
| didrocks | but the service should exit after a timeout anyway | 16:08 |
| didrocks | it's the upstream recommendation | 16:08 |
| didrocks | some like docker doesn't do it IIRC though) | 16:08 |
| asac | didrocks: so systemd passes you the socket fd on startup rigth? i read it can also pass you many sockets at the same time | 16:09 |
| asac | how do you know which is for what purpose? | 16:09 |
| didrocks | asac: libsystemd pass an array, let me check back | 16:10 |
| didrocks | asac: yep: http://0pointer.de/blog/projects/socket-activation.html | 16:11 |
| didrocks | n = sd_listen_fds(0); | 16:11 |
| didrocks | so you get the number of fds (generally 1) | 16:11 |
| asac | right i read that doc | 16:11 |
| asac | and it tells it can pass you multiple | 16:11 |
| asac | but cant figure how someone might then guess which socket is what | 16:11 |
| asac | so think > 1 is just not working | 16:11 |
| asac | like in the exampleL: | 16:12 |
| asac | fprintf(stderr, "Too many file descriptors received.\n"); | 16:12 |
| didrocks | well, it's just because he expected one, what is blocking you? | 16:12 |
| asac | wonder why it even tries to pass multiple ones... i think there must be some determinism defined what goes to which array bucket | 16:12 |
| asac | i just try to understand that feature :) | 16:12 |
| asac | because the doc says youy can get multiple ones | 16:12 |
| asac | but it doesnt tell me how to ensrue that i alway sget the FD i want at position 9 | 16:13 |
| didrocks | so, what happens, imagine a service which can take multiple sockets as input/output | 16:13 |
| didrocks | oh, it does | 16:13 |
| didrocks | fd = SD_LISTEN_FDS_START + 8 | 16:13 |
| didrocks | for instance :) | 16:13 |
| didrocks | to get position 9 | 16:13 |
| didrocks | I'm unsure the name of the socket is determinist though, you just get a fd | 16:13 |
| didrocks | so between 2 boots, it may changes as being in position 0 or position 5, or position 8 (if you have 9 of them) | 16:14 |
| asac | i know i can just ask for socket 8 | 16:14 |
| asac | but i cant see how that socket 8 will always be the socket i expect it to be | 16:14 |
| asac | like i can imagine client A talks to socket 1 and client B talks to socket 2 ... how does systemd ensure that its not suddenly the other way around? | 16:15 |
| didrocks | I think it's part of the protocol rather | 16:15 |
| asac | guess some annotations that can be looked up | 16:15 |
| asac | would help | 16:15 |
| didrocks | like announcing their name | 16:15 |
| asac | part of the protocol? | 16:15 |
| didrocks | the protocol you set between your client and services | 16:16 |
| asac | ok so you say all need to be of same protocol? | 16:16 |
| didrocks | service* | 16:16 |
| didrocks | at least in the first bytes | 16:16 |
| didrocks | (that's just a guess) | 16:16 |
| asac | ok so restriction is that all sockets are on same port for INET and hence have the same server | 16:16 |
| didrocks | asac: TBH, for systemd-fskd, I just use one socket | 16:16 |
| asac | that makes more sense | 16:16 |
| didrocks | then this socket is getting client connection request | 16:16 |
| asac | right. i see | 16:16 |
| didrocks | and depending on this, I create more connections :) | 16:16 |
| asac | its for being able to buffer if multiple requests come in | 16:17 |
| asac | not to enable activation through different protocols | 16:17 |
| didrocks | so all clients use the same socket to initiate a request | 16:17 |
| asac | yeah | 16:17 |
| didrocks | then, their are connected through their own sockets that have been given back | 16:17 |
| didrocks | (by the service) | 16:17 |
| asac | didrocks: and you said that once all sockets are closed the service gets killed by systemd? | 16:18 |
| didrocks | no, sorry, I was unclear, it's when the .socket systemd service is stopped (manually) | 16:18 |
| didrocks | thanks to PartOf= | 16:18 |
| asac | ah | 16:18 |
| asac | so there is no deactivation | 16:19 |
| didrocks | I implemented a service timeout when having 0 connection | 16:19 |
| didrocks | and that's what is recommended | 16:19 |
| asac | i guess socket activated services wont get restarted thouygh until there is a client again? | 16:19 |
| asac | e.g. its the servers responsibilty to just die if all clients are gone | 16:19 |
| asac | and if a new cient comes systemd will activate again? | 16:19 |
| didrocks | exactly, another client connexion to the socket reactive the service | 16:19 |
| didrocks | right | 16:20 |
| didrocks | (and this is working well) | 16:20 |
| didrocks | also, the service status is correctly reflected | 16:20 |
| asac | what is the service status if i exit a process that got socket activated? | 16:20 |
| didrocks | depending on the exit return code | 16:21 |
| didrocks | so, basically 0, if you don't set to restart it in the .service file, you are considered as being oneshot | 16:22 |
| asac | didrocks: does systemd have an API you can use to create nbew services etc. or is the interface "put a unit file there and run reload" ? | 16:22 |
| didrocks | and so, everything is good | 16:22 |
| didrocks | asac: yeah, you need to run systemctl daemon-reload | 16:23 |
| asac | ok so no api | 16:23 |
| didrocks | that way systemd is aware of the new unit files | 16:23 |
| didrocks | well, systemctl is using systemd API | 16:23 |
| didrocks | so, there is one | 16:23 |
| didrocks | unsure how stable it is though | 16:23 |
| asac | right. nothing anyone ever said would be something for use not through CLI | 16:24 |
| * didrocks needs to run to the bank | 16:24 | |
| didrocks | yeah | 16:24 |
| didrocks | see you tomorrow guys :) | 16:24 |
| asac | thansk for giving me inducation didrocks :) | 16:24 |
| didrocks | yw asac ;) | 16:24 |
| kyrofa | elopio, excellent fix on the catkin thing-- I know exactly what the issue is | 16:26 |
| kyrofa | elopio, and I'm sad I didn't catch it in review, I'm sorry :( | 16:26 |
| elopio | kyrofa: well, nobody of us caught it. Tell me more... | 16:28 |
| kyrofa | elopio, so initially the env() function set the PYTHONPATH explicitly using the in-snap python version, and then added more items to it via ROS's setup.sh. However, in the recent refactor for the python version globbing, that explicit set line was moved AFTER the ROS setup.sh call, which wiped out the ROS environment :P | 16:30 |
| kyrofa | elopio, I have no idea how this ever passed. And indeed, I see the failure now on my dev machine. Really odd | 16:30 |
| kyrofa | elopio, anyway, so your change keeps the ROS environment, which makes it work | 16:31 |
| kyrofa | elopio, I suspect now that my working tree wasn't up to date | 16:32 |
| elopio | kyrofa: is there a nicer way to solve it? | 16:34 |
| kyrofa | elopio, no I think your solution is perfect | 16:34 |
| elopio | lucky shot. | 16:34 |
| kyrofa | elopio, all skill ;) | 16:35 |
| elopio | ah, yeah, that too ;) | 16:36 |
| elopio | kyrofa: hey, the problem with this autopkgtest job in jenkins is that it will take like an hour to run. | 16:36 |
| elopio | do you think that's too much? | 16:36 |
| kyrofa | elopio, per PR? | 16:36 |
| elopio | yes. | 16:37 |
| kyrofa | elopio, that's certainly long, and I can see it being frustrating if we really want to crank something out, but can we honestly say that ensuring quality takes too much time? | 16:37 |
| pcoca | Hi everyone, Is there any way to deploy snaps to many devices at the same time? (with snappy remote or other tool) or needs to be done with the store? | 16:38 |
| elopio | kyrofa: we can make the rule to wait for it only on the changelog PR. Ignore it for other pull requests we want to merge faster. | 16:39 |
| elopio | and I think I can run the integration and the examples tests in parallel, somehow. I'll look into it. | 16:39 |
| sergiusens | pcoca, snappy remote with a "store" name should just work | 16:39 |
| pcoca | sergiusens, then all the devices pointing at that store will get the snap? | 16:40 |
| sergiusens | pcoca, real features for multi deploys will come with landscape integrating with the rest api | 16:40 |
| sergiusens | pcoca, yes to your question | 16:41 |
| pcoca | sergiusens, thanks! :) | 16:41 |
| kyrofa | elopio, honestly most PRs sit for an hour or so anyway, I'm fine with it. sergiusens may have an opinion (morning sergiusens!) | 16:42 |
| sergiusens | morning | 16:43 |
| sergiusens | I don't mind PRs taking an hour | 16:43 |
| sergiusens | but do we have to use the main upstream or will it work in our forks? | 16:43 |
| kyrofa | sergiusens, good question | 16:44 |
| kyrofa | Oh elopio, I accepted your PR but I suppose the ROS test should have been enabled in debian/tests/exampletests | 16:57 |
| elopio | kyrofa: maybe. Let me first confirm it runs in jenkins. | 16:57 |
| elopio | we are still missing some squid rules | 16:57 |
| kyrofa | elopio, alright | 16:57 |
| jerryG | ogra: can you answer a question about coredumps ? | 16:58 |
| kyrofa | jerryG, were you ever able to enable them? | 16:58 |
| ogra_ | jerryG, not sure, try it :) | 16:59 |
| kyrofa | jerryG, https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md if you haven't seen it | 16:59 |
| jerryG | kyrofa: ogra_: I'm having trouble getting coredumps to work.... it's creating folders... but it's not creating any coredump files | 17:00 |
| jerryG | kyrofa: thanks. that's what I was using as a guide | 17:00 |
| ogra_ | jerryG, well, we dont do anything special despite using the kernel defaults ... perhaps you need to tweak something | 17:01 |
| kyrofa | jerryG, I just did it the other day doing that (though using "snaps" instead of "apps" for all-snaps) | 17:01 |
| jerryG | kyrofa: so /home/ubuntu/snaps ? | 17:01 |
| ogra_ | there is also nothing in userspace that should touch the defaults either | 17:01 |
| kyrofa | jerryG, indeed. Were you using apps? | 17:01 |
| kyrofa | jerryG, that's a bug in the documentation | 17:02 |
| jerryG | kyrofa: ok thanks. ill try that | 17:02 |
| zyga | kyrofa: hey, have you seen pad.lv/1545786 by any chance? | 17:02 |
| kyrofa | (carry-over from 15.04) | 17:02 |
| zyga | kyrofa: elopio tells me you touched the launcher lately | 17:02 |
| zyga | kyrofa: I'm trying to see what's causing that error to happen | 17:02 |
| kyrofa | zyga, no I haven't, thanks for the heads up! | 17:03 |
| zyga | kyrofa: I'm running raspberry pi with latest snappy master spliced into an image I built yesterday | 17:03 |
| zyga | kyrofa: nothing I install runs | 17:03 |
| zyga | kyrofa: I cannot find any matches on the error message so far | 17:03 |
| kyrofa | zyga, is the user data directory owned by root or anything? | 17:03 |
| kyrofa | zyga, it's an errno | 17:04 |
| zyga | kyrofa: which directory is that? I did see root owned directories in /var/lib/snap | 17:05 |
| zyga | kyrofa: older (prebuilt) were root:ubuntu | 17:05 |
| zyga | kyrofa: post-install changed were root:root | 17:05 |
| zyga | kyrofa: chgrp on that doens't help | 17:06 |
| kyrofa | zyga, no, user data directory ($SNAP_USER_DATA) | 17:06 |
| zyga | kyrofa: no, those are all ubuntu:ubuntu | 17:07 |
| kyrofa | zyga, if you can walk me through how to get on edge I can look into this. I tried the other day but it seemed that channel-changing was broken | 17:07 |
| zyga | kyrofa: (in fact, nothing in $HOME is owned by root) | 17:07 |
| zyga | kyrofa: I built an image using my small tool: https://github.com/zyga/devtools | 17:08 |
| zyga | kyrofa: https://github.com/zyga/devtools/blob/master/ubuntu-image | 17:08 |
| zyga | kyrofa: essentially ubuntu-device-flash from mvo and some defaults for pi2 | 17:08 |
| kyrofa | zyga, alright, let me check it out :) | 17:08 |
| zyga | kyrofa: cool, I'll try to strace the error in the meantime | 17:09 |
| * zyga has a bunch of straces to look at | 17:11 | |
| zyga | kyrofa: got it: | 17:13 |
| zyga | open("/", O_RDONLY|O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC) = -1 EACCES (Permission denied) | 17:13 |
| zyga | write(2, "failed to create user data direc"..., 36) = 36 | 17:13 |
| zyga | write(2, ". errmsg: Permission denied\n", 28) = 28 | 17:13 |
| zyga | kyrofa: that is ubuntu-core-launcher | 17:13 |
| zyga | elopio: ^^ | 17:13 |
| kyrofa | zyga, huh... why would that be permission denied? | 17:13 |
| zyga | jdstrand: ^^ | 17:13 |
| zyga | tyhicks: ^^ | 17:14 |
| zyga | no idea | 17:14 |
| ogra_ | / is readonly ... | 17:14 |
| kyrofa | ogra_, it's not trying to write to it. It's trying to get the fd | 17:14 |
| * ogra_ guesses thats just fallout | 17:14 | |
| ogra_ | oh | 17:14 |
| zyga | ogra_: no, I don't think you'd get EACCES for O_RDONLY open on / | 17:14 |
| ogra_ | is it ? | 17:14 |
| kyrofa | ogra_, it uses that fd with a series of openat/mkdirat calls | 17:14 |
| jdstrand | zyga: read on '/' isn't allowed by the policy | 17:15 |
| ogra_ | and it doesnt use the actual path ? | 17:15 |
| kyrofa | jdstrand, but it's done before the app is confined | 17:15 |
| zyga | ogra_: I guess using openat means it has to get the fd for / first | 17:15 |
| zyga | jdstrand, tyhicks: for context, we're trying to understand https://bugs.launchpad.net/snappy/+bug/1545786 | 17:16 |
| ubottu | Launchpad bug 1545786 in Snappy "error trying to execute snap binary" [Critical,Triaged] | 17:16 |
| jdstrand | kyrofa: did '/' get wrong permissions? is the mount wrong? | 17:16 |
| ogra_ | it is readonly | 17:16 |
| kyrofa | jdstrand, good question. zyga ? | 17:16 |
| ogra_ | since it is a squashfs | 17:16 |
| jdstrand | 'failed to create user data directory. errmsg: Permission denied' | 17:16 |
| ogra_ | but that shouldnt get you a permission denied i guess | 17:16 |
| jdstrand | 'user data directory' | 17:17 |
| zyga | ubuntu@localhost:~$ mount | grep '/ ' | 17:17 |
| zyga | /dev/loop0 on / type squashfs (ro,relatime) | 17:17 |
| zyga | is a loop-mounted squashfs from the os snap | 17:17 |
| zyga | (well, it is the os snap) | 17:17 |
| ogra_ | right | 17:17 |
| zyga | jdstrand: I straced that to ubuntu-core-launcher | 17:17 |
| jdstrand | 'ubuntu@localhost:~$ hello-world.echo' | 17:17 |
| jdstrand | zyga: yes | 17:17 |
| jdstrand | it tries to create the user data directory | 17:17 |
| jdstrand | as of recent commits (I guess they landed) | 17:18 |
| zyga | jdstrand: hello-world.echo behaves the same way (just installed it and tried the command) | 17:18 |
| jdstrand | tyhicks: might be able to provide some more insight on openat, but the security team is currently working on a critical update | 17:18 |
| jdstrand | zyga: I get that. what I'm saying is that if run as a user, it is possible that $HOME/snaps is already there with root permissions. that is a different bug | 17:19 |
| jdstrand | so checks the perms of that | 17:19 |
| zyga | jdstrand: $HOME/snaps and inside has nothing owned by root (checked now) | 17:20 |
| jdstrand | ok, good (it isn't that bug) | 17:20 |
| zyga | jdstrand: everything is ug+rwX,o=rX | 17:20 |
| jdstrand | zyga: I would guess it has something to do with the mount options | 17:21 |
| zyga | jdstrand: mount optionon /writable or / ? | 17:21 |
| zyga | *optioins | 17:21 |
| zyga | *options | 17:21 |
| jdstrand | I'm not sure | 17:22 |
| jdstrand | are there apparmor denials in syslog? | 17:22 |
| jdstrand | the launcher runs under its own profile. I wonder if it needs an update with the recent changes | 17:22 |
| tyhicks | I can't think of what would cause that failed open() | 17:22 |
| tyhicks | that is really odd | 17:22 |
| jdstrand | zyga: grep DEN /var/log/syslog | 17:23 |
| kyrofa | tyhicks, indeed | 17:23 |
| tyhicks | ah, I guess it could be the ubuntu-core-launcher AppArmor profile blocking it | 17:23 |
| zyga | http://pastebin.ubuntu.com/15094280/ | 17:23 |
| zyga | jdstrand: ^^ | 17:24 |
| jdstrand | ok, there you go | 17:24 |
| tyhicks | yeah | 17:24 |
| jdstrand | let me look at the rest of the profile and I'll commit something to the tree | 17:24 |
| zyga | jdstrand: thanks, if there is something I can tweak in my image in the end to unblock on this that would help me a lot; if not I'll just wait for the bugfix to be available and if needed, update/rebuild the image | 17:25 |
| kyrofa | jdstrand, tyhicks I'm sorry guys, I'm not sure how I didn't discover that in testing | 17:25 |
| jdstrand | zyga: so, to work around this, you'll have to add '/ r,' to the profile | 17:25 |
| zyga | jdstrand: I assume the new os snap is needed to fix this? | 17:25 |
| zyga | jdstrand: ah, easy enough, I'll try | 17:25 |
| jdstrand | zyga: well, you can't tweak in the image since it is read only, but we can test what is needed without that | 17:25 |
| jdstrand | zyga: it is | 17:25 |
| zyga | hmmm, right | 17:25 |
| jdstrand | zyga: do this: cp /etc/apparmor.d/usr.bin.ubuntu-core-launcher /tmp | 17:26 |
| jdstrand | zyga: then modify /tmp/usr.bin.ubuntu-core-launcher to have: | 17:26 |
| jdstrand | r, | 17:26 |
| jdstrand | err | 17:26 |
| jdstrand | / r, | 17:26 |
| zyga | done | 17:27 |
| jdstrand | then do: | 17:27 |
| zyga | bind mount over? | 17:27 |
| jdstrand | sudo apparmor_parser -r /tmp/usr.bin.ubuntu-core-launcher | 17:27 |
| jdstrand | no don't worry about that | 17:27 |
| zyga | ah | 17:27 |
| zyga | right, this is in-kernel | 17:27 |
| jdstrand | we can load the profile into the kernel from anywhere | 17:27 |
| kyrofa | jdstrand, ah, and that profile is path-specific? If the launcher was run from elsewhere it wouldn't be applied? | 17:27 |
| jdstrand | kyrofa: in the profile there is '/usr/bin/ubuntu-core-launcher ... {' | 17:28 |
| kyrofa | jdstrand, argh, that was my testing gap | 17:28 |
| jdstrand | kyrofa: that gives what we call binary attach | 17:28 |
| jdstrand | kyrofa: I can actually test this here | 17:29 |
| zyga | jdstrand: done, still same error, inspecting new set of strace logs | 17:29 |
| jdstrand | zyga: if you'd like to go back to sprinting, I'll assign this to myself | 17:29 |
| jdstrand | zyga: I suspect there are other similar accesses that are required | 17:29 |
| jdstrand | so I can work through those | 17:30 |
| zyga | openat(3, "home", O_RDONLY|O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC) = -1 EACCES (Permission denied) | 17:30 |
| jdstrand | yep | 17:30 |
| zyga | it seems to need to go all the way down to $HOME/snaps | 17:30 |
| jdstrand | I'll take it from here | 17:30 |
| * jdstrand nods | 17:30 | |
| zyga | jdstrand: actually, I'm not sprinting (no remote sprinting this time) | 17:30 |
| zyga | jdstrand: so I can focus on this issue to unblock myself from skill security work | 17:30 |
| zyga | jdstrand: I'll make a coffee and be back soon, | 17:31 |
| kyrofa | zyga, trying to use ubuntu-image for the pc I get "expected 3 partitons but found 0" | 17:31 |
| jdstrand | zyga: to unblock yourself, in addition to '/ r,', add '/**/ r,' | 17:31 |
| jdstrand | zyga: I'm going to do something more specific, but that should unblock you | 17:31 |
| zyga | kyrofa: oh? weird, maybe you are affected by kpartx bug? (I assume that's at the very end when it builds the image) | 17:32 |
| zyga | kyrofa: I'm running xenial daily and it works okay | 17:32 |
| kyrofa | jdstrand, I suppose /, /home/ and /root | 17:32 |
| zyga | jdstrand: perfect, thanks | 17:32 |
| zyga | kyrofa: and $HOME/snaps too in the end | 17:32 |
| jdstrand | kyrofa: yes, but I wanted to sprinkle some 'owner' matches in there too | 17:32 |
| * zyga starts to grok all the security parts involved even if they are still complex | 17:32 | |
| kyrofa | jdstrand, ah right | 17:33 |
| kyrofa | zyga, hmm... I'm on xenial, though I haven't updated for a while | 17:33 |
| elopio | jdstrand: kyrofa: zyga: we are working on a process to release ubuntu-core to edge, and run the full suite there before moving it to other channels. That should find this type of errors earlier. | 17:33 |
| kyrofa | elopio, very cool! | 17:34 |
| jdstrand | elopio: sounds excellent :) | 17:34 |
| zyga | great elopio | 17:35 |
| === kickinz1 is now known as kickinz1|afk | ||
| zyga | jdstrand: the workaround works, thank you :) | 17:37 |
| jdstrand | zyga: cool :) | 17:38 |
| zyga | wooooot, my demo works :) | 17:38 |
| zyga | very close to i2c through skills | 17:38 |
| zyga | no longer running as root :D | 17:38 |
| zyga | whee :D | 17:38 |
| elopio | zyga: \o/ | 17:44 |
| sergiusens | utlemming, https://bugs.launchpad.net/cloud-init/+bug/1546230 | 17:49 |
| ubottu | Launchpad bug 1546230 in cloud-init "change the default to the nocloud data source" [Undecided,New] | 17:49 |
| jdstrand | zyga: what are you testing this on? I don't seem to have any updates for my os snap in kvm | 17:53 |
| kyrofa | jdstrand, edge | 17:56 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | zyga: hmm, I'm on core/rolling with ubuntu-core 16.04.0-11. how did you install 'edge' | 18:06 |
| popey | If I am using snapcraft and want to wrap my executable thing in a shell script to add environment variables like setting PERL5LIB to SNAP_APP_DATA_PATH etc, how do I tell snapcraft to "install" my shell script? | 18:10 |
| kyrofa | jdstrand: | 18:10 |
| kyrofa | kyrofa> zyga, if you can walk me through how to get on edge I can look into this. I tried the other day but it seemed that channel-changing was broken | 18:10 |
| kyrofa | <zyga> kyrofa: (in fact, nothing in $HOME is owned by root) | 18:10 |
| kyrofa | <zyga> kyrofa: I built an image using my small tool: https://github.com/zyga/devtools | 18:10 |
| kyrofa | <zyga> kyrofa: https://github.com/zyga/devtools/blob/master/ubuntu-image | 18:10 |
| kyrofa | <zyga> kyrofa: essentially ubuntu-device-flash from mvo and some defaults for pi2 | 18:10 |
| zyga | jdstrand: using ^^ | 18:10 |
| zyga | jdstrand: it's magic | 18:10 |
| zyga | nobody knows how to use ubuntu-device-flash :D | 18:11 |
| kyrofa | popey, using the copy plugin | 18:11 |
| popey | ah | 18:11 |
| kyrofa | zyga, indeed! That tool got super confusing | 18:12 |
| zyga | I'm sure we'll see real ubuntu-image sometime soon but before that happens, I've just do what I do | 18:12 |
| zyga | done, well anyway | 18:13 |
| * zyga sleepy | 18:13 | |
| kyrofa | zyga, seems my kpartx is up-to-date... so I don't know what's going on with my lack of image creation abilities | 18:14 |
| jdstrand | zyga: well, there are so many different versions of udf :) | 18:14 |
| ogra_ | there is only one true one ! | 18:14 |
| ogra_ | (the latest local binary on people.u.c from the person that implemented the last feature indeed !!!) | 18:15 |
| * kyrofa hears ogra_ now: "The one that creates dragonboard images!" | 18:15 | |
| kyrofa | ogra_, hahaha | 18:15 |
| zyga | jdstrand: yeah, I'm using the build mvo makes | 18:15 |
| ogra_ | :) | 18:16 |
| zyga | kyrofa: hmm, if you want I can make an image for you | 18:16 |
| zyga | kyrofa: but otherwise no idea | 18:16 |
| kyrofa | zyga, it sounds like jdstrand is on it, but I may take you up on that offer next time I need to test something on edge if that's okay ;) | 18:17 |
| kyrofa | zyga, hopefully the channel-switching bug will be fixed at some point as well | 18:17 |
| jdstrand | I'm running ubuntu-image now. I'm expecting I'm fine | 18:17 |
| * zyga wonders if the security team is busy with http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7547.html | 18:18 | |
| ubottu | ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547) | 18:18 |
| jdstrand | its fun that the kernel snap is like 2/3 bigger than the os snap | 18:18 |
| jdstrand | zyga: yes | 18:19 |
| ogra_ | jdstrand, all that firmware ... | 18:19 |
| zyga | ah, man, security is hard work! thanks for working on this | 18:19 |
| ogra_ | kernel and modules alone would be smaller | 18:19 |
| jdstrand | I'll say "you're welcome" on behalf of the security team (/me hasn't yet done his part for that update) | 18:20 |
| jdstrand | zyga (and kyrofa): ok, have an edge image working. thanks | 18:28 |
| kyrofa | jdstrand, ah, so it worked for you? /me pouts | 18:29 |
| jdstrand | kyrofa: all I did was ./ubuntu-image | 18:30 |
| jdstrand | then it asked me some stuff and out popped a pc.img that worked | 18:30 |
| kyrofa | zyga, I'm running it in an lxc. Think that would break things? | 18:30 |
| jdstrand | kyrofa: I've occasionally found that rebooting helps | 18:30 |
| jdstrand | kyrofa: eg, if you've used udf a few times in a row, etc | 18:31 |
| jdstrand | I think I opened a bug on that | 18:31 |
| zyga | kyrofa: perhaps yes | 18:31 |
| zyga | kyrofa: actually qemu is pretty nice | 18:31 |
| * jdstrand did not run it under lxc | 18:31 | |
| zyga | kyrofa: just run xenial in qemu to build the image | 18:31 |
| ogra_ | yay | 18:42 |
| * ogra_ has a working resize script for the dragonboard ... now i just need to pull that into the initrd | 18:43 | |
| ogra_ | and since i'll have to touch the initrd package for that i'll make asac happy tomorrow and simply also add the code for a generic binary build :) | 18:43 |
| ogra_ | zyga, do you have random USB devices you could try on the dragonboard to see if they work (i tried the three USB ethernet adapters i have here but lack more stuff) | 18:46 |
| ogra_ | would be good to know they load their respective modules at least and dont throw errors in dmesg | 18:46 |
| zyga | ogra_: yes, sure | 18:50 |
| ogra_ | thanks | 18:50 |
| zyga | ogra_: trying now | 18:50 |
| zyga | ogra_: tried wifi dongle, eth dongle | 18:57 |
| zyga | ogra_: (eth dongle flaky but that's the dongle) | 18:57 |
| zyga | ogra_: trying more | 18:57 |
| ogra_ | both load modules and all ? | 18:57 |
| zyga | ogra_: yes (both work as network interfaces) | 18:58 |
| jdstrand | zyga: fyi, uploaded ubuntu-core-launcher to xenial and the image ppa for the fix | 18:58 |
| ogra_ | awesome ! | 18:58 |
| zyga | ogra_: just FYI, I still see this while bootinh | 18:58 |
| ogra_ | zyga, "this" ? | 19:00 |
| zyga | [FAILED] Failed to start Load/Save RF Kill Switch Status. | 19:00 |
| zyga | (had to reboot to see it, damn serial) | 19:00 |
| zyga | minicom over screen over classic mode pi over ssh over ssh | 19:01 |
| zyga | don't ask ;) | 19:01 |
| zyga | https://xkcd.com/908/ | 19:01 |
| zyga | applies | 19:01 |
| ogra_ | zyga, yeah, that wont be fixed before tomorrow ... needs the fix uploaded first (i havent yet) ... then a cdimage build ... and then manually snapping that and uploading to the store | 19:01 |
| ogra_ | (the rfkill stuff) | 19:02 |
| ogra_ | i was planning to do a full set of ubuntu-core snap updates tomorrow anyway | 19:04 |
| ogra_ | also to test the arm64 update (mvo claimed it should work, but nobody has tested it yet :) ) | 19:05 |
| zyga | cool | 19:07 |
| zyga | I'll gladly update tomorrow | 19:07 |
| ogra_ | it should even do that itself :) | 19:07 |
| ogra_ | (unless you disabled autoupgrade) | 19:08 |
| sergiusens | kyrofa, elopio how are things progressing on your side? | 19:30 |
| kyrofa | sergiusens, not too bad here. How's the sprint so far? | 19:32 |
| svij | ogra_: häppy börsday! | 19:37 |
| sergiusens | kyrofa, good; looking into ubuntu image more than anything else | 19:40 |
| kyrofa | sergiusens, ah good, that will be super useful :) | 19:41 |
| sergiusens | and trying to wrap up cleanbuild a bit during spare time | 19:41 |
| kyrofa | sergiusens, you have spare time? Not 8-8 meetings eh? | 19:41 |
| mvo | ogra_: sure it will work ;) | 19:43 |
| sergiusens | kyrofa, 8-8 meetings; spare time is me getting distracted or during the night ;-) | 19:45 |
| kyrofa | sergiusens, hahaha | 19:45 |
| kyrofa | ogra_, were you ever able to fix the dragonboard partition-resize-eating-itself issue? | 19:48 |
| popey | How long to snap reviews take in the store? | 23:08 |
| * popey is used to clicks being reviewed in about a minute | 23:08 | |
| zyga | popey: I may be wrong but reviews might be manual until squashfs is supported by review scripts | 23:12 |
| popey | ah okay | 23:14 |
| popey | well, I successfully uploaded my first snap to the store, so that's a milestone for me 😃 | 23:14 |
| === cprov_ is now known as cprov | ||
| === ev_ is now known as ev | ||
| === tedg_ is now known as tedg | ||
| === alecu_ is now known as alecu | ||
| === Trevinho_ is now known as Trevinho | ||
| === moul_ is now known as moul | ||
| === pitti is now known as Guest82926 | ||
| === stgraber_ is now known as stgraber | ||
| sergiusens | stgraber, hey about https://bugs.launchpad.net/snappy/+bug/1543764 do you have implementation details on how you plan to do this? | 23:57 |
| ubottu | Launchpad bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!