| === beuno_ is now known as beuno | ||
| === devil is now known as Guest90181 | ||
| === chihchun_afk is now known as chihchun | ||
| === Guest90181 is now known as devil_ | ||
| dholbach | good morning | 07:34 |
|---|---|---|
| didrocks | Guten Morgen dholbach | 07:38 |
| dholbach | salut didrocks | 07:46 |
| dholbach | kgunn, in your mir-snaps article I removed the references to the snappy tools ppa - it should be available everywhere in xenial | 07:54 |
| pitti | zyga: sorry, this PR does not really say much to me -- except for two comments it doesn't seem udev related at all? | 07:58 |
| zyga | good mornign | 08:05 |
| zyga | pitti: hey, thanks for looking at it | 08:06 |
| zyga | pitti: this how snappy will reload udev rules when something security-related changes | 08:06 |
| zyga | pitti: (we write or remove some udev rules) | 08:06 |
| zyga | pitti: this is just a sanity check review | 08:06 |
| noizer | Good morning | 09:12 |
| noizer | I think i encountered an issue while making mine own apparmor profile | 09:12 |
| noizer | the error looks like Mar 11 09:08:30 localhost kernel: [64990.973666] audit: type=1400 audit(1457687310.712:69): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/ubuntu/snaps/ad.sideload/LScnlHLRglbn/snaps/" pid=4159 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 09:13 |
| dpm | mvo, Trevinho, did the u7 .desktop file support land yesterday? I wasn't sure which package to look at | 09:55 |
| mvo | dpm: it landed but stuck in xenial-proposed due to a build failure | 09:55 |
| mvo | on powerpc | 09:55 |
| Trevinho | linkedinyou: dpm the package is the snappy one though | 09:56 |
| Trevinho | Ouch... Autocompletion... | 09:57 |
| dpm | mvo, Trevinho, ok, thanks 'ubuntu-snappy', then? | 09:57 |
| dpm | mvo, While I have you here: I don't quite understand how upgrades for the ubuntu-core snap work on the desktop. Do they happen automatically or do I need to upgrade it manually? | 09:57 |
| mvo | dpm: there is a systemd job that will auto-update ubuntu-core | 09:58 |
| dpm | aha! | 09:58 |
| dpm | I was getting confused | 09:58 |
| dpm | I had tried | 09:58 |
| dpm | $ sudo snappy update ubuntu-core | 09:58 |
| dpm | the given snap is not installed | 09:58 |
| mvo | dpm: hm, that is a bug, I think because we use channels now in some internal api | 10:04 |
| dpm | mvo, where is the best place to file bugs for snappy, as the one you've just mentioned? | 10:11 |
| mvo | dpm: the launchpad https://bugs.launchpad.net/snappy | 10:12 |
| dpm | great, thanks | 10:12 |
| mvo | dpm: and pining us also helps | 10:12 |
| cr0nx | Hi Snappy users. I have a question about adding 3rd party kernel module to the snappy kernel. Is it an easy task or I have to rebuild the whole image? | 10:14 |
| ogra_ | cr0nx, you have to rebuiold the kernel snap | 10:16 |
| dpm | mvo, ok, filed http://pad.lv/1556018 | 10:17 |
| ubottu | Launchpad bug 1556018 in Snappy "Cannot manually update ubuntu-core snap" [Undecided,New] | 10:17 |
| cr0nx | ogra_ do you have any recommeded document about how to rebuild kernel snap? | 10:18 |
| ogra_ | cr0nx, snapcraft offers a kernel plugin ... though that builds completely from source | 10:21 |
| ogra_ | if you want to add a binary module http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the device tarballs that are used as input for our kernel snaps ... they are all based on deb packages from the ubuntu archive ... | 10:22 |
| ogra_ | https://launchpad.net/~mvo/snappy/mksnap-os-kernel has the scripts to turn a device tarball into a snap (note: requires xenial's snappy) | 10:23 |
| cr0nx | perfect! thank you for your help. These are my first steps with snappy, but it seems to me as a great option for dedicated appliance I am working on. Do you know if somebody using snappy in a production env/product ? | 10:26 |
| ogra_ | dell seels its industrial gateways perinstalled with snappy | 10:27 |
| ogra_ | *sells | 10:27 |
| ogra_ | and there are several drone manufacturers shi9pping snappy based drones | 10:27 |
| cr0nx | wow, exciting! And also last question: do you have any experience running snappy kernel with grsecurity patch ? | 10:33 |
| ogra_ | nope, but note that we use seccomp, cgroups and apparmor massively in snappy ... not sure if the grsecurity patches change their behavior | 10:34 |
| cr0nx | better ASLR is always better | 10:35 |
| cr0nx | ok ogra_ | 10:35 |
| cr0nx | thank you very much for your help. I appreciate | 10:36 |
| ogra_ | here is a snapcraft.yaml for use with the snapcraft kernel plugin https://github.com/sergiusens/snapcraft/blob/feature/1552168/kernel-plugin/examples/kernel/snapcraft.yaml | 10:36 |
| ogra_ | (you'd just create a wrokdir, put that yaml file in there and run "snapcraft" ... the rest is automatic | 10:37 |
| ogra_ | ) | 10:37 |
| cr0nx | coool! | 10:39 |
| ogra_ | (though there is no concept of pathes i think, which means you might need your own git tree with your patch on top) | 10:39 |
| ogra_ | *patches | 10:39 |
| ali1234 | is there a click package for mythtv on ubuntu-core? | 10:45 |
| ali1234 | where do i even go to find packages? | 10:45 |
| ogra_ | click package ? this isnt #click :P | 10:48 |
| ogra_ | https://uappexplorer.com/ offers a search option for snaps in the store | 10:48 |
| ali1234 | well i specifically need a click package that works on snappy ubuntu core | 10:49 |
| ali1234 | i'm not sure what the difference is | 10:49 |
| ogra_ | that doesnt exist | 10:49 |
| ali1234 | oh? | 10:49 |
| ogra_ | click is deb based, snap is something completely new | 10:49 |
| ogra_ | there is no compatibility | 10:49 |
| ali1234 | https://myapps.developer.ubuntu.com/dev/click-apps/?format=snap | 10:50 |
| ali1234 | what does this URL mean? | 10:50 |
| ali1234 | this is where you end up at the end of the snappy tour | 10:50 |
| ogra_ | that shows your snappy packages in the store if you have any ... | 10:51 |
| ogra_ | and is the place to upload them if you produce any | 10:51 |
| ali1234 | why does it contain "click" | 10:52 |
| ogra_ | no idea, i never looked at the url | 10:52 |
| ogra_ | it is what you get to when clicking on "Ubuntu Core" at the top menu on the page | 10:52 |
| ali1234 | this is why i thought i needed a click package | 10:52 |
| ali1234 | in snap format | 10:52 |
| ogra_ | for actual click packages you'D go to "Ubuntu Personal" ... | 10:53 |
| ali1234 | the tour doesn't actually explain any of this, which is why i am reduced to guessing based on urls | 10:53 |
| ogra_ | well, the store UI is far from being complete ... i guess the web devs just re-used the click UIs for now | 10:54 |
| ogra_ | ali1234, https://lists.ubuntu.com/archives/snappy-app-devel/2016-March/000636.html | 10:55 |
| ogra_ | that is what you want when creating snaps nowadays ... i guess docs will updated on release day | 10:55 |
| ogra_ | *will get | 10:56 |
| ali1234 | i don't want to create a snap though | 10:56 |
| ali1234 | i want someone else to have already done it for me | 10:56 |
| ogra_ | heh | 10:56 |
| ali1234 | according to the tour, it is recommended to use 14.04, but "this" version of snapcraft only works on 16.04 (what "this" version means is not explained) | 10:57 |
| cr0nx | ogra_: BTW: why docker version is so old? are you using backporting or it is really 1.6.2 version ? | 10:57 |
| ogra_ | ali1234, all older snapcrafts and older images will be obsolete with 16.04 | 10:58 |
| ogra_ | cr0nx, no idea, i dont maintain that snap | 10:58 |
| ogra_ | (and have never used it) | 10:58 |
| ogra_ | ali1234, 16.04 is essentially snappys "1.0" release | 10:59 |
| ali1234 | great, but 1604 isn't released, therefore i am not running it | 10:59 |
| ogra_ | well, you have to ... or at least have to use a chroot if you want to build snaps for 16.04 | 11:00 |
| ali1234 | i don't want to build snaps for 16.04 | 11:00 |
| ali1234 | i want to build snaps for the current release, because that is what i will be deploying | 11:00 |
| ogra_ | well, then you have to use the old manual ways | 11:00 |
| cr0nx | ok | 11:01 |
| ogra_ | but that it will be EOL in 5 weeks | 11:01 |
| ali1234 | but my main point is that the tour literally contradicts itself | 11:01 |
| ogra_ | *note that | 11:01 |
| ogra_ | yes, it will be overhauled for release, as i said | 11:01 |
| popey | Do we support the Odroid devices (yet)? like http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438 ? | 11:13 |
| ogra_ | popey, longsleep (from spreed) did maintain one ... not sure hw has a 16.04 version and he wasnt around for some days | 11:14 |
| ogra_ | *not sure if | 11:14 |
| popey | hm, okay. | 11:14 |
| ali1234 | can i run snapcraft on snappy core? is there a snappy package for it? | 11:17 |
| ogra_ | you can run: sudo snappy enable-classic; snappy shell classic | 11:18 |
| ogra_ | and then just apt-get install snapcraft | 11:18 |
| ali1234 | is that a good idea? | 11:19 |
| ogra_ | that is the purpose of the classic mode, so yes | 11:19 |
| ogra_ | (it runs a container on top of the readonly rootfs that just adds the missing pieces for a "normal" dpkg based rootfs) | 11:19 |
| ali1234 | where can i get a snappy 16.04 image for raspberry pi 2? | 11:22 |
| ogra_ | http://people.canonical.com/~mvo/all-snaps/ | 11:22 |
| ali1234 | what does "all" refer t in the filename? | 11:23 |
| ogra_ | either grab the pre-made one ... (thats a few days old though) or grab ubuntu-device-flash from there to build your own | 11:23 |
| ogra_ | thats the new "all-snaps" image format, it means that everythiong is now a snap | 11:23 |
| ali1234 | does building my own require 16.04? | 11:23 |
| ogra_ | (rootfs, kernel, gadget (which is bootloader and device definitions)) | 11:24 |
| ogra_ | no, ubuntu-device-flash is a static binary ... you should be able to use it on older releases | 11:25 |
| ali1234 | if i have a pi3, is the arm64 version a good idea? | 11:25 |
| ogra_ | (it probably makes sense to apt-get install ubuntu-devcie-flash first, there are some deps like kpartx) | 11:25 |
| ogra_ | no | 11:25 |
| ogra_ | the pi3 can not run arm64 code yet | 11:25 |
| ogra_ | that waits for a binary blob update from broadcom | 11:25 |
| ali1234 | oh yeah, i heard about that | 11:26 |
| ogra_ | (the currtent bootloader initializes the board in 32bit mode yet) | 11:26 |
| ogra_ | and for snappy i'm also waiting for a u-boot port ... thats also not completely done yet | 11:26 |
| ali1234 | it can initialize in 64 bit mode, but the kernel will fail when it tries to talk to the 32 bit videocore code | 11:26 |
| * ogra_ has 2 pi3's lying here but not all bits exist yet) | 11:26 | |
| ogra_ | right | 11:27 |
| ali1234 | something to do with kernel pointers being passed through videocore | 11:27 |
| ogra_ | i definitely plan to have an image for it ... | 11:27 |
| ogra_ | and once arm64 works fully on it, even an arm64 image | 11:27 |
| ogra_ | today the only arm64 board we support is the dragonboard though | 11:28 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | Good morning | 12:02 |
| techraf | Good morning @21:22 in Osaka | 12:23 |
| techraf | how can I get a .snap file of a snap from a store? | 12:24 |
| techraf | is it possible to get the URL of a snap? | 12:24 |
| techraf | for example to check where `snappy-debug` will be downloaded from? | 12:25 |
| ogra_ | techraf, there is uappexplorer.com ... not sure if it provides download links though | 12:33 |
| beeray | hi, I am just hearing about snappy, just want to know the difference between it and docker | 12:36 |
| techraf | ogra_, I'm not sure if these are the same apps that I was thinking of.. | 12:37 |
| techraf | @ogra_, I'm not sure if these are the same apps that I was thinking of... | 12:37 |
| nothal | techraf: No such command! | 12:37 |
| ogra_ | snappy isnt a container system (you can use containers in it) | 12:37 |
| ogra_ | techraf, there is a search option for snappy | 12:37 |
| popey | techraf: there is an api for the store. you could poke that and get the url to the snaps | 12:37 |
| ogra_ | https://uappexplorer.com/apps?sort=relevance&type=snappy | 12:37 |
| popey | techraf: or you might find them in my mirror http://popey.mooo.com/mirror/clicks/2016/03/2016-03-11-050001/ | 12:37 |
| kyrofa | techraf, you can use the store API from the terminal | 12:38 |
| kyrofa | popey, argh, you're too fast | 12:38 |
| techraf | oh, these _are_ the same apps and store indeed shows a direct link to https://public.apps.ubuntu.com/anon/download/canonical/docker.canonical/docker.canonical_1.6.2.005-16.04.1-1_all.snap | 12:39 |
| popey | that's the one | 12:39 |
| kyrofa | techraf, curl http://search.apps.ubuntu.com/api/v1/package/snappy-debug | 12:39 |
| kyrofa | beeray, welcome! | 12:40 |
| techraf | does _all.snap mean all architectures? Actually I was looking for armhc | 12:40 |
| kyrofa | beeray, Docker and Snappy solve completely separate problems | 12:40 |
| ogra_ | techraf, yes, all means all arches (that can mean it only contains scripts, but also that it ships binaries for all of them and switches according to the arch you run it on) | 12:41 |
| kyrofa | beeray, Docker is a virtualization technology, and Snappy/Ubuntu Core is an operating system | 12:41 |
| kyrofa | beeray, may I ask what you read that led you to believe they were similar? | 12:42 |
| beeray | ok , thanks so much guyz | 12:42 |
| beeray | so that mean I can use it to develop app, and it means it can run docker container as well | 12:43 |
| ogra_ | yeah | 12:43 |
| kyrofa | beeray, you got it | 12:43 |
| beeray | Just want to ask, is it faster than running docker on main ubuntu or other linux distros | 12:43 |
| popey | ali1234: I have snappy on a pi2 here, and have two ssh sessions to it, one in 'snappy' mode, and one in 'classic' mode. I use classic to build snaps using snapcraft, and then switch to the 'snappy' mode session to test install them, as they share the same $home | 12:44 |
| ogra_ | most likely, since you can run apps in a securely confined way natively ... without having to have a container layer underneath | 12:44 |
| ali1234 | popey: that sounds like what i need | 12:44 |
| ogra_ | ali1234, see, we thought of you :) | 12:45 |
| popey | although I did run out of space at one point | 12:45 |
| popey | does snappy auto expand to fill the sd card? | 12:45 |
| ali1234 | i am going to use a 32Gb card | 12:45 |
| ogra_ | it should, yes | 12:45 |
| ogra_ | check with df, i heard recently that the auto-resize diidnt work for someone | 12:46 |
| ogra_ | (i'm currently re-writing it though) | 12:46 |
| popey | /dev/mmcblk0p2 3.4G 3.2G 90M 98% /home | 12:46 |
| popey | it's a 16GB sd card | 12:46 |
| ogra_ | looks fine | 12:46 |
| techraf | thank you ogra_, popey, kyrofa - I got to do a homework with downloaded .snap now :) | 12:46 |
| popey | so looks like it didn't | 12:47 |
| ogra_ | oh | 12:47 |
| ogra_ | yeah, then it didnt | 12:47 |
| popey | /dev/mmcblk0p2 270336 31250000 30979665 14.8G 83 Linux | 12:47 |
| ogra_ | there should be logs in /run/initramfs | 12:47 |
| popey | reported by fdisk | 12:47 |
| popey | 1454620756: start | 12:48 |
| popey | writable: clean, 41877/229824 files, 618695/917504 blocks | 12:48 |
| popey | 1454620757: end | 12:48 |
| popey | does classic have a limited amount of space? | 12:48 |
| ogra_ | nope | 12:48 |
| popey | hmm | 12:48 |
| ogra_ | but it can only use as much space as your writable partition has indeed | 12:49 |
| popey | my other one running edge, seems to have worked /dev/mmcblk0p2 29G 947M 26G 4% /home | 12:49 |
| ogra_ | please file a bug against initramfs-tools-ubuntu-core that the resize didnt work | 12:49 |
| popey | (32GB card in that one) | 12:49 |
| popey | So i guess no bug needed if it's fixed in edge? | 12:49 |
| ogra_ | not sure it is fixed in edge :) | 12:49 |
| beeray | currently working on virtualization with docker, just want to ask if I can install docker on it, and then run container through the docker. OR is it possible like I read to develop app test it and run it on snappy without the need for container | 12:50 |
| popey | hm | 12:50 |
| ogra_ | beeray, both is possible :) | 12:50 |
| beeray | pls explain, you know each app is independent in container , how do they work in docker | 12:51 |
| ogra_ | there is a docker snap you can install an use if you want ... to just run your app in | 12:51 |
| beeray | and also regarding RPi , can snappy replace the raspian or debian or ubuntu that we do install in RPi. if so what are the benefits | 12:52 |
| ogra_ | at the same time you can use snapcraft and just develop a snap for your app that runs it natively | 12:52 |
| ogra_ | it is really up to you ... | 12:53 |
| ogra_ | though by experience i'd not really run docker on something as underpowered as a rpi | 12:54 |
| ali1234 | does the rpi2 image work on rpi3? | 12:58 |
| ogra_ | transactional updates are surely a big benefit (of the OS as well as of the snaps) ... the very high level of security and reliability are surely also putting it far above a deb based system (readonly filesystem apps are completely confined and cant just access stuff on the OS etc) | 12:58 |
| ogra_ | ali1234, nope | 12:59 |
| ogra_ | as i said, needs u-boot to be finished | 12:59 |
| ogra_ | i know srwarren is on it, shouldnt take long til he has something stable | 12:59 |
| ali1234 | is it expected that the SD activity led does not work? | 13:00 |
| ali1234 | oh nvm, it does work, it's just really slow | 13:00 |
| ogra_ | after the rootfs booted it works | 13:00 |
| ogra_ | the first boot takes a while since it resizes the OS and does some basic setup via cloud-init | 13:00 |
| ogra_ | subsequent boots are a lot faster | 13:01 |
| beeray | thanks guyz | 13:01 |
| ali1234 | what is cloud-init? i don't like the sound of that | 13:01 |
| ogra_ | ali1234, it creates ssh keys and sets up the default user (in snappys case, it can generally do a lot more we dont use) | 13:02 |
| ali1234 | so it's basically oem-setup for the cloud? | 13:03 |
| ogra_ | right | 13:03 |
| ali1234 | okay, makes sense | 13:03 |
| ogra_ | well, in actual cloud-setups it does a lot more (installing debs and such, partitioning the cloud instance etc etc) | 13:03 |
| ogra_ | more like d-i | 13:03 |
| ogra_ | but as i said, snappy only uses the user setup and ssh key generator | 13:03 |
| techraf | sorry to jump in | 13:09 |
| beeray | So what is the difference between snappy and main Ubuntu | 13:09 |
| techraf | for ubuntu-core on RPi - before "sudo snappy enable-classic; snappy shell classic" | 13:10 |
| techraf | do I need to install ubuntu-classic? | 13:10 |
| JamesTait | mvo, did you by chance see bug #1555569 - is there a human-readable name in snap.yaml equivalent to title in a Click manifest? Would that be summary? | 13:11 |
| ubottu | Error: Launchpad bug 1555569 could not be found | 13:11 |
| techraf | or it's not yet official? | 13:14 |
| ogra_ | techraf, nope, it should work by default (in the 16.04 images) | 13:15 |
| ogra_ | well, it needs to download the container content (which "sudo snappy enable-classic" does) | 13:16 |
| techraf | ogra_, that explains why it does not work here on 15.10 :) | 13:22 |
| ali1234 | okay it must have finished booting by now | 13:29 |
| ali1234 | how do i log in? | 13:30 |
| popey | ubuntu/ubuntu | 13:34 |
| ali1234 | what is the IP? | 13:34 |
| popey | dhcp | 13:34 |
| popey | or plug into a display and keyboard and login locall of course | 13:34 |
| ali1234 | okay i am logged in | 13:36 |
| ali1234 | it doesn't have a hostname | 13:36 |
| ali1234 | probably explains why avahi doesn't work | 13:36 |
| ali1234 | ubuntu@localhost:~$ | 13:36 |
| ali1234 | /dev/mmcblk0p2 3.4G 158M 3.1G 5% /writable | 13:36 |
| kyrofa | ali1234, if webdm is installed try webdm.local | 13:37 |
| ali1234 | what is webdm | 13:37 |
| ali1234 | i tried wemdb.local from the tour, but it does not work | 13:37 |
| kyrofa | ali1234, a web-based package manager, if you will | 13:38 |
| ali1234 | .local is avahi | 13:38 |
| ali1234 | there is no avahi address associated with the IP | 13:38 |
| ogra_ | kyrofa, webdm isnt ported to interfaces yet | 13:38 |
| kyrofa | ali1234, .local is just a convention. avahi is one of many ways to get mdns | 13:38 |
| kyrofa | ogra_, ahh | 13:39 |
| * ogra_ is waiting for that too | 13:39 | |
| ali1234 | so the writable partition didn't resize either | 13:39 |
| ogra_ | kyrofa, btw, what abotu an owncloud update ? :) | 13:39 |
| ogra_ | ali1234, yeah, thats a bug | 13:39 |
| kyrofa | ogra_, amd64 has been rebuilt, but my rpi2 is crapping out on me | 13:40 |
| ali1234 | can i just e2resize it? | 13:40 |
| ogra_ | you can file it against initramfs-tools-ubuntu-core ... i'm working on fixing that though | 13:40 |
| kyrofa | ogra_, I'm not sure if it's my SD card, the flash drive I'm using for swap, or a hardware issue | 13:40 |
| ogra_ | :( | 13:40 |
| kyrofa | ogra_, the video gets all weird, like the text is garbled. It works for another half hour or so, then it's just gone | 13:41 |
| ogra_ | wow | 13:41 |
| ogra_ | that sounds very broken | 13:41 |
| kyrofa | ogra_, yeah, feels like hw | 13:41 |
| ogra_ | ali1234, any logs in /run/initramfs/ ? | 13:42 |
| kyrofa | Unfortunately it's the only arm I have... so I'm crossing my fingers for LP to finish allowing internet access in its builders | 13:42 |
| ali1234 | yes, resize-writable.log | 13:42 |
| ogra_ | any errors in there ? | 13:42 |
| ali1234 | yes, e2fsck errors | 13:42 |
| ogra_ | ah | 13:43 |
| ali1234 | http://paste.ubuntu.com/15347369/ | 13:43 |
| ogra_ | k, that gives me some pointer what to look for | 13:43 |
| ogra_ | well, but it finished fine ... lparted should have kicked in next ... weird that it didnt | 13:44 |
| ogra_ | -l | 13:45 |
| ali1234 | also these http://paste.ubuntu.com/15347403/ | 13:47 |
| ogra_ | hmm | 13:48 |
| ogra_ | where does that BYT come from | 13:48 |
| ali1234 | "i dunno lol" | 13:48 |
| ali1234 | where does any of that output come from? | 13:49 |
| ogra_ | initrd | 13:49 |
| kyrofa | ogra_, rebooting the rpi2, I have evbug lines all over my syslog | 13:49 |
| ogra_ | there is an awfully ugly resize script | 13:50 |
| ogra_ | kyrofa, lovely ... sounds like kernel then | 13:50 |
| mvo | JamesTait: I think the best we have is indeed summary | 13:51 |
| ogra_ | (well, awfully ugly for GPT disks ... pretty standard for mbr ones) | 13:51 |
| kyrofa | ogra_, should I log a bug, then? | 13:51 |
| ogra_ | kyrofa, yeah and attach the syslog ... against linux-raspi2 for the start | 13:51 |
| ali1234 | would it help if i did it again with a serial console? | 13:52 |
| ogra_ | no, all output is redirected to the log files ... you would only see some echos "resizing foo ..." | 13:52 |
| ogra_ | as i said, i'm working on it | 13:53 |
| ogra_ | since thats just an mbr disk you can easily resize it with gnome-disks or gparted in your PC for now .... to work around the bug | 13:53 |
| techraf | ogra_ where can I get ubuntu core 16.04 for RPi? | 13:57 |
| ali1234 | http://people.canonical.com/~mvo/all-snaps/ | 13:57 |
| ogra_ | techraf, http://people.canonical.com/~mvo/all-snaps/ | 13:57 |
| techraf | thank you | 14:00 |
| ali1234 | uh... something weird just happened | 14:05 |
| ali1234 | http://paste.ubuntu.com/15347526/ | 14:06 |
| ali1234 | i didn't do anything | 14:06 |
| ogra_ | ali1234, auto update notification :) | 14:06 |
| ali1234 | so it just reboots any time by default? | 14:07 |
| ogra_ | if autoupdate is enabled, yes | 14:07 |
| ali1234 | i'll need to automatically defer that | 14:08 |
| ogra_ | (which it is by default) | 14:08 |
| ali1234 | if mythtv is recording something it should wait until the recording finishes, then reboot | 14:08 |
| ogra_ | so you disable it with snappy config ubuntu-core ... | 14:10 |
| ogra_ | echo -e "config:\n ubuntu-core:\n autoupdate: false\n" | sudo snappy config ubuntu-core -- - | 14:12 |
| ogra_ | that should do | 14:12 |
| ogra_ | (note the spaces are essential, it is yaml) | 14:12 |
| ali1234 | i don't want to disable it though. i just want to make sure the system doesn't reboot while it is doing something important | 14:14 |
| ogra_ | well, its an on/off thing currently | 14:14 |
| ogra_ | i agree that tthere should be finer grained inhibition ... but thats not there yet | 14:15 |
| ogra_ | (there migh be a way via the REST api though) | 14:18 |
| kyrofa | elopio, standup? | 14:33 |
| elopio | kyrofa: I'm trying to join. | 14:33 |
| kyrofa | Oh google | 14:33 |
| ysionneau | How am I supposed to debug a snap with gdbserver ? | 14:36 |
| ogra_ | from the classic shell you can attach to the pid | 14:36 |
| ysionneau | the program crashes at startup | 14:36 |
| ysionneau | s/program/snap/ | 14:37 |
| ogra_ | ah, then probably by using strace from your startup script or some such ... | 14:37 |
| ysionneau | and if I run gdbserver in the confined env, it is killed because of syscall 136 (personnality) | 14:37 |
| ogra_ | (which indeed requires re-snapping) | 14:37 |
| ogra_ | i think jdstrand had some clever way of using an overlayfs from classic, so you can dynamically hack your shell scripts in the snap dir etc | 14:39 |
| ysionneau | from the startup script I've put something like if [ "$DEBUG" = "1" ]; then exec gdbserver :1234 $SNAP/usr/bin/wifid; else exec $SNAP/usr/bin/wifid; fi | 14:39 |
| ysionneau | but gdbserver does not like being sandboxed | 14:39 |
| JamesTait | mvo, so we're currently discussing the removal of the tagline field from click packages - I had mistakenly thought it was a field that we parsed from the click manifest, when in fact the upoader has to enter it in the upload form. | 14:40 |
| JamesTait | mvo, the intention originally was to finally split it out into a separate field, and parse summary from snap.yaml into there - it sounds like a better approach might be to drop tagline entirely and parse summary into what clicks call title. | 14:41 |
| elopio | fgimenez: I rewrote the dep8 test to use the test deps from source, but I still can't find them if I'm not inside the tests directory. | 14:47 |
| elopio | I don't understand what I'm doing wrong. This should be the same as when we compile the tests binary. | 14:48 |
| elopio | huh, weird. It works if I first generate the binary. | 14:51 |
| fgimenez | elopio, mm we do this when building the binaries "command.Dir = filepath.Join(os.Getenv("GOPATH"), projectSrcPath)", are you using shell script for the dep8 test? | 14:51 |
| elopio | shell script. | 14:52 |
| elopio | but it worked, I think I'm happy with this. Not as ugly as before. | 14:52 |
| elopio | I'll propose the branch for you to see. | 14:52 |
| zyga | jdstrand: hey | 14:54 |
| jdstrand | zyga: hey | 14:54 |
| jdstrand | I saw the emails, I'm discussing it with the team | 14:55 |
| zyga | jdstrand: thanks | 14:57 |
| zyga | jdstrand: let's sync before EOD, I'd like to know what I stand on | 14:57 |
| === ahayzen_ is now known as ahayzen | ||
| jdstrand | zyga: yes, that is why I started discussing it immediately after I came on :) | 15:05 |
| === chihchun_afk is now known as chihchun | ||
| elopio | mvo: https://github.com/ubuntu-core/snappy/pull/646 | 15:24 |
| elopio | autopkgtest. | 15:24 |
| mvo | elopio: thats wonderful, thanks a lot! | 15:24 |
| jdstrand | didrocks: hey, I can't help but comment since you sent the reminder-- the timing for surveying people on 16.04 snappy development is interesting since I imagine everyone is going to be incredibly frustrated since a ton of things are still in flight | 15:25 |
| jdstrand | and that is going to continue for at least a couple of weeks | 15:26 |
| jdstrand | 2 cents | 15:26 |
| ogra_ | are we re-defining interfaces again next week ? | 15:26 |
| ogra_ | :P | 15:26 |
| jdstrand | not plugs/slots/etc but yes in that now that that is settled, the actual interfaces are going to land | 15:27 |
| kyrofa | jdstrand, yeah I'm prepared for angry responses :P | 15:27 |
| didrocks | jdstrand: yeah, that's what I first told to Daniel about the timing | 15:27 |
| jdstrand | and old-security/caps names are not going to be the same as the os slots | 15:28 |
| didrocks | but at least, we can measure, reassess, progress | 15:28 |
| didrocks | yeah, I look forward to that, I lost a build because of a trailing "," in a json security.override | 15:28 |
| didrocks | and no angryness on install! :p | 15:28 |
| jdstrand | I guess in one sense you will have a nice baseline-- your next survey should have an overwhelmingly more positive response, so it'll look great then! :) | 15:29 |
| kyrofa | Hahaha | 15:29 |
| jdstrand | didrocks: click-review whould've noticed that | 15:29 |
| jdstrand | should've | 15:29 |
| jdstrand | didrocks: but security-override was literally *horrible* in 15.04 :) | 15:30 |
| jdstrand | didrocks: I think you are the only person who used it | 15:30 |
| kyrofa | jdstrand, not so! I've used it now | 15:30 |
| jdstrand | yay? | 15:31 |
| kyrofa | :P | 15:31 |
| jdstrand | :) | 15:31 |
| jdstrand | I mean, it does stuff... | 15:31 |
| didrocks | it does somewhat worked yeah :) | 15:36 |
| didrocks | but I'm happy we move to something more modern | 15:36 |
| didrocks | kyrofa: speaking of which, you have an answer on http://askubuntu.com/questions/744696/how-to-create-snappy-nodejs-web-application :) | 15:37 |
| kyrofa | didrocks, heh | 15:39 |
| stgraber | jdstrand: any chance you can approve lxd 2.0.0 rc3? | 16:01 |
| jdstrand | ogra_, ysionneau: fyi, this is in my notes: http://paste.ubuntu.com/15348328/ | 16:01 |
| jdstrand | ogra_, ysionneau: obviously the technique can be extended in various ways | 16:02 |
| jdstrand | stgraber: I thought I did? | 16:02 |
| ogra_ | *if* yoour kernel has overlayfs | 16:02 |
| ogra_ | :) | 16:02 |
| jdstrand | stgraber: is this a new one or from earlier this week? | 16:02 |
| jdstrand | ogra_: indeed | 16:02 |
| stgraber | jdstrand: that was rc2, I pushed rc3 last night | 16:02 |
| jdstrand | ah | 16:02 |
| jdstrand | yes, I can do that | 16:02 |
| rajen | Hi Folks. I am experimenting with custom Snappy o/s image creation for our hardware. I was able to use "mk-snappy" scripts to create a custom kernel snap. I am picking up os snap from nightly builds. I used device-flash to create the .img file | 16:09 |
| rajen | But I observe that ubuntu-core cannot be updated to newer versions as it is shown as sideloaded. | 16:10 |
| rajen | http://pastebin.com/wLehLKHZ | 16:10 |
| rajen | Any idea how we can overwrite sideload'ed apps with signed version from snappy store? | 16:10 |
| ogra_ | you cant | 16:10 |
| ogra_ | upload your snaps to the store ;) | 16:11 |
| ogra_ | (and push your updates through it too) | 16:11 |
| rajen | okay..I am using the os snap provided. | 16:11 |
| rajen | But it still shows up as sideloaded. | 16:11 |
| ogra_ | you make ubuntu-device-flash use it from the store ? | 16:12 |
| ogra_ | or did you download it locally | 16:12 |
| rajen | Got it. I am downloading the snaps and tar balls locally and creating the img file using device-flash. | 16:13 |
| ogra_ | thats your issue :) | 16:13 |
| rajen | I see what you are saying, if I tell device-flash to use o/s snap directly from store it will allow me to upgrade it. | 16:13 |
| ogra_ | you just want: --os ubuntu-core.canonical | 16:14 |
| rajen | You see, we want our own customer kernel snap to be sideloaded. But ubuntu-core, we want it from the store. | 16:14 |
| ogra_ | that will download the signed one from the store and it will not be marked as sideloaded | 16:14 |
| rajen | okay let me modify the scripts to do --os ubuntu-core.canonical | 16:15 |
| rajen | Thanks for the tip ogra_ ! | 16:15 |
| ogra_ | if you want to upgrade your kernels you should consider uploading them too though | 16:15 |
| rajen | W.r.t kernel, yeah we will get there soon. | 16:16 |
| rajen | ogra_: What about gardget snap? canonical-pc? | 16:16 |
| rajen | --gadget ??? | 16:17 |
| dholbach | mvo, ogra_: do you know when snappy 16.04 images will live on cdimage.u.c? | 16:25 |
| ogra_ | dholbach, no | 16:25 |
| dholbach | do we know who's working on this? | 16:25 |
| ogra_ | me if in doubt | 16:25 |
| ogra_ | we have the fragments on http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ (kernel and os snap) but these need to be automatically pulled into the store .... and thnen we need some automated way to run u-d-f | 16:26 |
| ogra_ | and as i just said in my mail we need the new all-snaps u-d-f to land first in the archive | 16:27 |
| ogra_ | as i also said in my mail i could do an alpha release manually ... but since the interfaces are still not final i'm not sure thats such a good idea | 16:27 |
| ogra_ | (people will have to re-do their snaps again once it is stable) | 16:28 |
| dholbach | mh | 16:28 |
| ogra_ | mvo, when will the u-d-f for all-snaps land ? any reason to hold it back ? | 16:29 |
| rajen | ogra_, Yes. Now I am able to see ubuntu-core snap installed with correct version and Developer. | 16:36 |
| ogra_ | great :) | 16:36 |
| rajen | Cool. But, I have question now. | 16:37 |
| rajen | The reason why were doing custom o/s snap was to work around a problem in Snappy. | 16:37 |
| ogra_ | a custom os snap is definitely the wrong way to work around any problems :) | 16:37 |
| rajen | Our C application residing inside our snap package is allergic to dash and wants bash as default shell. | 16:38 |
| rajen | Now is there a way in Snappy to specify /bin/sh to be bash for a Snap application. | 16:38 |
| ogra_ | we might remove bash from the image at some point | 16:38 |
| rajen | I believe this is a feature that needs to be exported by the Snappy infrastructure. | 16:38 |
| ogra_ | andf your snaps should realyl not rely on anything in the os snap | 16:38 |
| rajen | okay..here is the catch. | 16:39 |
| rajen | "/bin/sh" is hardcoded when system("") libc API is used. | 16:39 |
| ogra_ | i think the right way would be to allow snapcraft to ship a /bin/sh override so you can ship your own shell insuide and the ubuntu-core-launcher would just point to whatever your snap ships | 16:39 |
| rajen | So we do not want to hack libc to point to some other /bin/xxxx. | 16:39 |
| ogra_ | jdstrand, ^^^ | 16:40 |
| arges | Hi. Does a golang client library exist for the snappy REST api? or should i just use net/http. | 16:40 |
| ogra_ | jdstrand, and idea if it is possible to override /bin/sh from the launcher for a snap ? | 16:40 |
| ogra_ | i could imagine people shipping ksh scripts or tcsh scripts in their snaps would want that too | 16:41 |
| ysionneau | is there a capability to allow a snap to use mount ? | 16:51 |
| ogra_ | i dont think so | 16:52 |
| ysionneau | I'd like to have some rw directory accessible from several snaps | 16:52 |
| ysionneau | I wanted to mount -o bind some /writable/parrot directory in /tmp/parrot (the sandboxed /tmp) for each snap | 16:53 |
| ogra_ | i think the interfaces model will offer that (you would have a disk-provider snap or some such that your other snaps can consume) but thats not there yet | 16:53 |
| ysionneau | but no luck :p | 16:53 |
| ogra_ | probably zyga can tell where we stand with that | 16:54 |
| ysionneau | ok thanks! | 16:54 |
| ogra_ | i know he works on interfaces | 16:54 |
| ogra_ | but i doubt you will be able to actually use mount :) | 16:54 |
| ysionneau | well mount is not mandatory I just wanted some solution to share some files | 16:55 |
| ysionneau | and actually right now I want to share a named unix socket | 16:55 |
| ogra_ | yeah | 16:55 |
| * ogra_ usually just dumps all bits that need to share a dir into one snap | 16:55 | |
| ogra_ | i.e. http://bazaar.launchpad.net/~ogra/+junk/upnp-server/files .... ships minidlna and lighttpd that share the same dir | 16:56 |
| ysionneau | yes that's one solution, but it's not something we can do for everything | 16:57 |
| ysionneau | that would end up like : parrot-firmware.snap | 16:57 |
| ysionneau | instead of having several snaps | 16:57 |
| ogra_ | well, whats the advantage of having several snaps ? | 16:58 |
| ysionneau | + we want to allow developers to do snaps which would be able to communicate with our autopilot running in another snap (a parrot snap) | 16:58 |
| ogra_ | (apart from requiring a lot more maintenance) | 16:58 |
| ysionneau | and that means : shared memories, udp/tcp/unix sockets | 16:58 |
| ysionneau | and files | 16:58 |
| ogra_ | yeah, the interfaces model will allow all that i think | 16:58 |
| ysionneau | good :) | 16:59 |
| ysionneau | is there some text somewhere describing this idea? (even if it's not implemented at the moment, I get it) | 16:59 |
| ysionneau | so that I can grab the idea | 16:59 |
| ogra_ | not sure ... since we collect all such stuff in google docs i lost the overbview | 16:59 |
| ogra_ | i'm sure there is some doc *somewhere* | 17:00 |
| jdstrand | ogra_: eek, yuck. /me notes system() is almost always unsafe.... I can't think of a way to do that in anyway that would be considered sane | 17:04 |
| jdstrand | the scripts should be adjusted to be posix compliant or the system() calls should be replaced with something that does what they want | 17:05 |
| ogra_ | well, you could have a special libc that allows an env var for /bin/sh to override the system one .... and force-seed that var to an in-snap binary | 17:05 |
| ogra_ | but thats indeed very ugly | 17:05 |
| ogra_ | jdstrand, would it be bad to make seccomp actually block system() ? | 17:06 |
| jdstrand | this all gets back to us defaulting to dash which we did in 6.10 | 17:06 |
| ogra_ | (i assume this would make half the Sw non-functional) | 17:06 |
| jdstrand | we can't block system(), that isn't a syscall | 17:06 |
| ogra_ | yeah | 17:07 |
| jdstrand | libc implements system() with execl which is ultimately the execve syscall | 17:07 |
| * ogra_ sighs ... 3rd firefox crash out f the blue in 1h ... FF 45 is really not for 15.10 it seems :( | 17:07 | |
| ogra_ | hmm, doesnt libc actually respect the SHELL env var ? | 17:08 |
| ogra_ | hmm, not according to http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html | 17:11 |
| rajen | ogra_, Jdstrand: I am reading your conversation. Interesting points! | 17:12 |
| ogra_ | rajen, we have a porting doc to make shell scripts properly POSIX compliant btw https://wiki.ubuntu.com/DashAsBinSh ... perhaps that helps ? | 17:13 |
| ysionneau | hmmm even from the same snap, if I run 2 apps, each one will get a different /tmp, right? | 17:13 |
| ysionneau | but I can share files with $SNAP_DATA :) | 17:13 |
| ogra_ | ysionneau, yeah, i think there is a bug open for that | 17:13 |
| ysionneau | ogra_: ok | 17:13 |
| rajen | Okay dash/bash for scripts. Yes we fixed all that. | 17:13 |
| rajen | The issues are with our C application. | 17:13 |
| ogra_ | /tmp should be per snap, not per app | 17:13 |
| ysionneau | agreed | 17:14 |
| rajen | jdstrand, ogra_: this is the actual problem we are trying to work around with http://stackoverflow.com/questions/35642734/ld-preload-not-applied-to-command-given-through-system-in-dash-but-working-wi | 17:14 |
| jdstrand | you could maybe LD_PRELOAD system() so it uses bash | 17:18 |
| ogra_ | that doesnt solve the general issue that snaps fully rely on the os shell though | 17:19 |
| rajen | I don't think that was possible. | 17:19 |
| rajen | jdstrand, _IO_execl ("/bin/sh", "sh", "-c", command, (char *) 0); | 17:21 |
| rajen | glibc code does this. There is no escape from this I guess. | 17:21 |
| rajen | _IO_new_proc_open() | 17:22 |
| mhall119 | hi all, where can I find documentation about the new "interfaces" in snappy and how to build a snappy that provides new ones? | 17:25 |
| ogra_ | mhall119, in someones brain :P | 17:26 |
| mhall119 | who's brain to I need to extract? :) | 17:29 |
| zyga | mhall119: mine | 17:30 |
| zyga | mhall119: what do you need | 17:30 |
| mhall119 | zyga: to learn more about snappy, but specifically I want to understand the best way of providing a single ubuntu-sdk-libs snap package that other snap application packages can depend on | 17:31 |
| zyga | niemeyer: oh, so code reuse | 17:32 |
| zyga | er | 17:32 |
| zyga | mhall119: ^^ | 17:32 |
| mhall119 | yes | 17:32 |
| zyga | niemeyer: sorry, habbit :) | 17:32 |
| niemeyer | ;) | 17:32 |
| zyga | mhall119: we discussed that times and again and the bottom line is that right now we don't have an off-the shelf solution; I'm pretty confident we could make one but that's something we're not working on now | 17:33 |
| mhall119 | zyga: with 16.04 desktop introducing snappy support, I'd like to make our new ecosystem of convergence apps available on it | 17:33 |
| zyga | mhall119: the focus is to finish what we planned and that's very much what we are doing | 17:33 |
| zyga | mhall119: I understand, it's just not ready yet | 17:33 |
| zyga | mhall119: there's a few different ways we could do that, it's a bit complex around the edges | 17:34 |
| mhall119 | ok, then where can I learn about snappy interfaces more generally? | 17:34 |
| zyga | mhall119: and we don't want to get back to debs and dependency issues | 17:34 |
| zyga | mhall119: the core idea is super simple, it's a way for two snaps to interact | 17:34 |
| jdstrand | mhall119: fyi, I think you are about 1 week early | 17:34 |
| zyga | mhall119: using a well defined "protocol" | 17:34 |
| zyga | mhall119: whatever that is (could be some actual protocol, could be just an agreement to write to a file, etc) | 17:35 |
| jdstrand | mhall119: in about that time, much of this will be landed and presumably docs/... updated | 17:35 |
| zyga | mhall119: yep, jdstrand is right | 17:35 |
| zyga | mhall119: I'm working on plugging it all together; next week we'll have that in trunk and we'll focus on docs, polish and tons of interfaces | 17:35 |
| mhall119 | jdstrand: ok, who is working on landing that and writing those docs? | 17:35 |
| zyga | mhall119: and to see what's the next focus for us | 17:35 |
| zyga | mhall119: I suspect I'll work on that though I bet jdstrand will help me a lot in actual writing proper english :) | 17:36 |
| mhall119 | zyga: ack, I will come annoy you about it next Friday then :) | 17:36 |
| zyga | mhall119: gladly! | 17:36 |
| zyga | mhall119: sorry, I wish I could give it to you and the world today | 17:36 |
| zyga | mhall119: (about that, time for a coffee and another pull request) | 17:36 |
| jdstrand | zyga: I can say for sure after all that is there and the old-security/caps stuff is implemented, we should look hard at the existing frameworks (docker, lxd, mir, bluez, pulseaudio and nm) | 17:37 |
| mhall119 | zyga: a week is not so bad, I can wait that long :) | 17:37 |
| jdstrand | zyga: each will likely present different challenges to work through. eg, sockets, dbus bus policy, etc | 17:37 |
| zyga-phone | jdstrand: totally agree | 17:42 |
| zyga-phone | (I cannot stand my office today, moved downstairs to see real living human beings) | 17:44 |
| zyga-phone | jdstrand: I'd like to land udev/apparmor branches that I posted | 17:44 |
| zyga-phone | jdstrand: while my attempt to reconcile snappy/security.go with interfaces failed miserably (everything is terrible ;-) I got a lot of things done | 17:45 |
| jdstrand | zyga-phone: hehe, I doubt everything is terrible. Things are coming along! be happy :) | 17:48 |
| zyga-phone | jdstrand: we parse the _name_ of the file with the apparmor profile in hw-assign, I tried to decouple that so we can rename the file but I gave up | 17:49 |
| zyga-phone | jdstrand: I'd rather implement interfaces and developer mode and burn hw-assign with fire | 17:50 |
| jdstrand | zyga-phone: hw-assign gone, sure. I am curious what we'll do for say, assigning /dev/video0 to a snap | 17:50 |
| ogra_ | voodoo | 17:51 |
| jdstrand | ie, what these interfaces will look like wrt the os and gadget slots | 17:51 |
| ogra_ | (build a little camera out of straw ... ascrifice a chicken ... and hope the app works then) | 17:51 |
| zyga-phone | jdstrand: enable developer mode, work with us on a proper interface | 17:51 |
| zyga-phone | jdstrand: doing /dev/* assignment through interfaces is trivial (i have implemented this iface locally) | 17:51 |
| zyga-phone | jdstrand: doing hw-assign requires going through a maze of legacy code | 17:52 |
| jdstrand | ok, so you implemented the hw-assign functionality as an interface (that's fine and it will probably be useful for devs in the early stages), I more meant what does a proper interface look like for these things | 17:53 |
| jdstrand | it is more pondering | 17:53 |
| jdstrand | I guess we'll see :) | 17:53 |
| zyga-phone | jdstrand: it would always depend on what is being assigned so that there's interoperability | 17:56 |
| === chihchun is now known as chihchun_afk | ||
| Ash___ | hi | 18:28 |
| Ash___ | is it possible to use smartphone as a developement board for projects | 18:28 |
| Ash___ | since...todays smartphones are built on SOC s .. | 18:29 |
| Ash___ | pls post your views | 18:29 |
| kyrofa | Ash___, sure, but aren't the bootloaders pretty locked down in most cases? | 18:31 |
| rajen | Is anyone working on this issue? https://bugs.launchpad.net/snappy/+bug/1552458 | 18:31 |
| ubottu | Launchpad bug 1552458 in Snappy "Sharing tmp directory across multiple commands in a snap app" [Undecided,New] | 18:31 |
| rajen | I hope this gets fixed soon so that we can prepare our snaps in time for 16.04 release | 18:31 |
| Ash___ | hi kyrofa.. | 18:31 |
| Ash___ | can u just dive deeper ...to get better understanding | 18:32 |
| kyrofa | Ash___, I'm not sure how much deeper we can go there. If phones were that easy to use, you wouldn't need to hack them to root them etc. | 18:33 |
| kyrofa | Ash___, you're right, all the hardware is probably there (other than stuff like GPIO etc. that's on a typical dev board) | 18:34 |
| Ash___ | yeah, we should leverage its power.... | 18:35 |
| Ash___ | Lets work together to use smarthone as a embedded system's heart | 18:36 |
| kyrofa | Ash___, honestly I'd rather use something a bit more open | 18:39 |
| Ash___ | yeah, u r correct...even me too like to use in the same way....but as we see...the prices of smartphones are becoming cheap..in terms of prices and they are loaded with all sensors...processor....display...wifi...bluetooth....4G..3g..what not... | 18:42 |
| === devil is now known as Guest86684 | ||
| === Guest86684 is now known as devil_ | ||
| === devil_ is now known as devil__ | ||
| === JanC_ is now known as JanC | ||
| popey | I'd rather use something like an arm chromebook for dev / building as it has an integral screen and keyboard, and integrated IO ports | 20:57 |
| popey | so easier to debug when it messes up | 20:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!