| liuxg | if my app is running on a raspberry pi, how can I get the output message like fmt.Printlin in golang? thanks. | 03:18 |
|---|---|---|
| stgraber | Chipaca: hey, so with the new random version stuff for sideloads, how am I supposed to test framework snaps which do require predictable paths (lxd)? | 05:32 |
| stgraber | Chipaca: it's not an option for us to have everything check the environment due to some binaries being setuid which would then give the user a trivial root escalation | 05:32 |
| stgraber | I guess we could just always use the current symlink, I think we didn't do so initially because of some apparmor interactions, though since we're unconfined nowadays that probably doesn't matter so much | 05:34 |
| dholbach | good morning | 07:21 |
| === zyga-afk is now known as zyga | ||
| zyga | good morning | 07:41 |
| sabdfl | hi folks, who can help with some mail system and mailman debugging? | 08:17 |
| Chipaca | stgraber: for now, use the current symlink if you really need to | 09:20 |
| Chipaca | stgraber: wrt root escalation, i don't follow the exploit, but i haven't had your coffee yet | 09:21 |
| Chipaca | stgraber: i mean my coffee | 09:21 |
| Chipaca | see what i mean | 09:21 |
| Chipaca | stgraber: if current isn't good enough, you can airgap | 09:21 |
| Chipaca | stgraber: but that's brittle | 09:22 |
| Chipaca | stgraber: before eoy the random versions should go away, but maybe also the versions go away from the filesystem (replaced by revisions), I don't know | 09:23 |
| longsleep | Good morning snappy | 09:31 |
| JamesTait | Good morning all; happy Monday, and happy Deviled Egg Day! 😃 | 09:49 |
| Chipaca | this coffee smells like strawberries and cream | 10:15 |
| Chipaca | my senses are so confused | 10:15 |
| Chipaca | ogra_: you around? | 10:17 |
| ogra_ | pretty much, yeah :) | 10:17 |
| Chipaca | ogra_: what's the thing that does the thing? | 10:19 |
| Chipaca | :D | 10:19 |
| ogra_ | we call it the thing | 10:19 |
| Chipaca | ogra_: the handling of config files changed on upgrade | 10:19 |
| ogra_ | sabdfl, mailman -> barry, mail system -> probably lamont | 10:20 |
| ogra_ | Chipaca, how | 10:20 |
| Chipaca | ogra_: i understood you to say last week, that for individual writable /etc files, we have special magic that handles upgrades | 10:21 |
| ogra_ | right, in the initrd | 10:21 |
| ogra_ | sync_dirs() and handle_writable_paths() in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs | 10:22 |
| * Chipaca looks | 10:23 | |
| ogra_ | the prob is that we can not use that setup with /etc/writable/ because these files are usually having local changes | 10:23 |
| Chipaca | ogra_: ah, wait, so the problem is that we don't handle local changes at all? | 10:24 |
| ogra_ | if you would blindly upgrade they would always be replaced by the defaults | 10:24 |
| Chipaca | eep | 10:24 |
| ogra_ | so we do never upgrade the files in /etc/writable | 10:24 |
| Chipaca | so the problem isn't /etc/writable | 10:24 |
| Chipaca | the problem is that we don't 3-way merge | 10:24 |
| Chipaca | at all | 10:24 |
| ogra_ | the problem is the concept | 10:24 |
| ogra_ | right | 10:24 |
| Chipaca | and for some things, that is entirely correct | 10:25 |
| ogra_ | there isnt really a proper way to do that since we dont really have one specific syntax in configs | 10:25 |
| Chipaca | so our problem is that for some things it isn't | 10:25 |
| ogra_ | so you would need a handler with 100s of plugins or something to handle all 3 way cases | 10:25 |
| ogra_ | right | 10:26 |
| Chipaca | or, not expose the raw config files | 10:26 |
| Chipaca | (which is something we want to do) | 10:26 |
| ogra_ | up to now we only used files in /etc7writable that are definitely local only config files | 10:26 |
| Chipaca | now === 4 releases ago | 10:26 |
| ogra_ | like hostname, localtime and timezone | 10:26 |
| ogra_ | well, it is the only dir where atomic changes are possible | 10:27 |
| Chipaca | yes, but again, the problem isn't atomic changes or not, it's the 3-way merge | 10:27 |
| ogra_ | well, not the only one, but the only one in etc | 10:27 |
| Chipaca | so even if we drop atomic writes, we still have the problem | 10:27 |
| ogra_ | Chipaca, on the phone we have upgrade handlers in upstart jobs, so you can handle the minimal and most important caees at least ... i dont think anyone ported that part to snappy ever | 10:32 |
| Chipaca | ogra_: and the phone doesn't do rollbacks | 10:33 |
| ogra_ | right | 10:33 |
| Chipaca | so | 10:33 |
| ogra_ | for rollbacks you would need duplication of the files | 10:33 |
| === zyga is now known as zyga-afk | ||
| Chipaca | how does this sound: first, we stop exposing raw config files through config, make config more semantic (already a bug for this). Then, we store that config somewhere, and regenerate the config files from there on new core version | 10:34 |
| ogra_ | (and a still three way merge boot handler i guess) | 10:34 |
| ogra_ | *still a | 10:34 |
| Chipaca | does that sound right? | 10:34 |
| ogra_ | well, that means you will need one handler for each config file | 10:34 |
| Chipaca | we already do have that | 10:35 |
| ogra_ | thesy will all differ in format | 10:35 |
| ogra_ | for system configs ? | 10:35 |
| Chipaca | but they're just stupid :) -- we need to make them smarter | 10:35 |
| Chipaca | oh, yes | 10:35 |
| Chipaca | here, let me link ya | 10:35 |
| Chipaca | ogra_: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go | 10:35 |
| ogra_ | oh, well | 10:36 |
| Chipaca | most of them just call get/setPassthrough, which just writes it out | 10:36 |
| ogra_ | right | 10:36 |
| ogra_ | if you want to modify content you will need a function per config file | 10:36 |
| Chipaca | but i'd rather fix those, than write a 3-way-merge handler for each case, which i deem harder-to-impossible | 10:37 |
| ogra_ | but even tthen you would need a config file per rootfs | 10:37 |
| Chipaca | "a config file per rootfs"? | 10:37 |
| ogra_ | unless you want to re-write them on going back and forward all the time | 10:37 |
| ogra_ | yes, you need a writable/a and a writable/b | 10:37 |
| Chipaca | yes | 10:37 |
| Chipaca | or rewrite them every time, yes | 10:38 |
| ogra_ | well, rather not | 10:38 |
| Chipaca | i'm fine with either | 10:38 |
| ogra_ | so if you have writable/a|b it means you need to copy the contents during upgrade .... | 10:39 |
| ogra_ | but you dont want to copy all the payload data | 10:39 |
| ogra_ | which means the upgrade mechanism needs to become more intelligent | 10:40 |
| ogra_ | Chipaca, for the three way merge we should probably look at ucf | 10:41 |
| Chipaca | so, on rollback/upgrade, you'd call (say), snappy internal config-regen | 10:41 |
| ogra_ | it already handles exqactly that | 10:41 |
| Chipaca | will do | 10:41 |
| ogra_ | (and it is preinstalled) | 10:42 |
| Chipaca | wrt config-regen, whether that happens during the install process itself (ie before reboot), or after it (during boot), that's the thing i'm not worried about | 10:42 |
| Chipaca | ogra_: but ucf drops back to being interactive | 10:42 |
| Chipaca | doesn't it? | 10:42 |
| ogra_ | you can avoid that | 10:42 |
| ogra_ | (and force stuff, which can indeed be risky but i dont see a way around forcing if you want to exclude interaction) | 10:43 |
| ogra_ | i would actually like to have the handling before the reboot | 10:44 |
| ogra_ | if there is a lot to handle your first boot after upgrade might be painfully slow | 10:44 |
| ogra_ | better handle it when you actually expect the upgrade to take time anyway, because you ran the upgrade command | 10:45 |
| Chipaca | true | 10:45 |
| Chipaca | note it'd have to be the new snappy, but that's easily doable fwiw | 10:45 |
| Chipaca | anyway. Lots of work. | 10:45 |
| ogra_ | yep | 10:45 |
| Chipaca | ogra_: sounds like we move forward with using /etc/writable for everything, and handle merges "soon" | 10:46 |
| Chipaca | ogra_: is that accurate? | 10:46 |
| ogra_ | well, i'D prefer if we wouldnt use /etc/writable | 10:47 |
| Chipaca | tell me more | 10:47 |
| ogra_ | it means that the file needs to be maintained in a far more complex way at image build time | 10:47 |
| ogra_ | /etc/system-image/writable-paths is a single one liner | 10:48 |
| ogra_ | while the livecd-rootfa handling of /etc/writable means scripting for each file | 10:48 |
| ogra_ | it was never throught as a general solution | 10:49 |
| ogra_ | but as an exception for the few files that need atomic writing in a normal ubuntu system | 10:49 |
| Chipaca | how hard is that to fix? ie replacing the scripting-for-each-file with a general solution? maybe i can help? | 10:51 |
| * Chipaca fetches livecd-rootfs, prepares his stomach | 10:52 | |
| ogra_ | well, the fact that we make ourselves 100% depending on livecd-rootfs hacks bothers me here | 10:52 |
| ogra_ | a new image build system will need exactly the same hacks | 10:52 |
| ogra_ | i'd really like us to get away from that instead of adding more to it | 10:52 |
| Chipaca | ah, i hadn't understood | 10:54 |
| Chipaca | i thought the handling of /etc/s-i/w-p was in livecd-rootfs | 10:54 |
| ogra_ | no, thats in the initrd | 10:54 |
| Chipaca | if it's in s-i, maybe the other can be addressed there too | 10:54 |
| ogra_ | in the script above | 10:54 |
| Chipaca | ah | 10:54 |
| Chipaca | forgot to look at the thing that was getting that | 10:54 |
| ogra_ | (which is technically s-i client side :) ) | 10:54 |
| ogra_ | it parses writable-paths and creates the mounts and all | 10:55 |
| ogra_ | (and fstab entries for the dirs that systemd should handle (everythin but /etc)) | 10:55 |
| Chipaca | ah, the problem just hit me | 10:58 |
| Chipaca | initrd can't fix the /etc/writable usage because it can't create the symlinks | 10:58 |
| Chipaca | dumb me | 10:58 |
| ogra_ | Chipaca, technically everything in here is a hack and shouold go away for a future build system http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/files/head:/live-build/ubuntu-core/hooks/ | 10:59 |
| ogra_ | and /etc/writable is currently handled in http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/08-etc-writable.chroot .... the handling of /etc/default/watchdog just doubled the size of the script | 10:59 |
| ogra_ | well, we could probably teach it to | 11:02 |
| ogra_ | i,e, add a function just for handling that dir and have another table (/etc/system-image/atomic-files ) that has the link targets and filenames | 11:04 |
| === zyga-afk is now known as zyga | ||
| Chipaca | ogra_: you mean, initrd mounts / rw, creates symlinks, remounts ro? | 11:07 |
| ogra_ | yeah, after the sync_dirs and handle_writable_paths functions have run so that your /etc bindmount farm is already up | 11:08 |
| ogra_ | (and /etc/writable is writable) | 11:08 |
| ogra_ | it will indeed chak, if links exist it doesnt need to create them | 11:08 |
| ogra_ | thats a one time think if a new file shows up | 11:08 |
| ogra_ | *thing | 11:08 |
| ogra_ | *check | 11:08 |
| ogra_ | my go, my typing today | 11:08 |
| ogra_ | *god | 11:09 |
| * ogra_ needs new kbd soon | 11:09 | |
| Chipaca | ogra_: fwiw every mountpoint we remove drops boot time on the bbb by .1--.2s | 11:14 |
| Chipaca | ogra_: http://people.canonical.com/~john/bbb.svg | 11:19 |
| Chipaca | ogra_: ( systemd-analyze plot > bbb.svg ) | 11:19 |
| ogra_ | err | 11:19 |
| ogra_ | what is it doing these 17s ? | 11:19 |
| ogra_ | (i wish we had kept bootchart around, it was able to show the initrd delays ) | 11:20 |
| Chipaca | pondering the meaning of life | 11:20 |
| Chipaca | unpacking initrd? | 11:20 |
| ogra_ | the etc mount units need to be removed | 11:20 |
| ogra_ | for 17s ?!? | 11:21 |
| ogra_ | if that takes 2s thats much | 11:21 |
| Chipaca | just booting the kernel, afaict | 11:21 |
| ogra_ | i would like to know how much of that is actually kernel time and how much initrd | 11:21 |
| ogra_ | and what exactly in the initrd makes it so super slow | 11:22 |
| Chipaca | ah, of course, all that is hidden in there :-( | 11:22 |
| Chipaca | maybe initrd needs to log events some how so they show up in this? | 11:22 |
| ogra_ | what do etc-machine\x2did.mount and etc-systemd-system.mount do ? | 11:23 |
| * Chipaca suspects he should have shown this plot to ogra_ a lot earlier | 11:23 | |
| ogra_ | heh, yeah | 11:23 |
| ogra_ | 17s *before* systemd is realyl awful | 11:24 |
| Chipaca | etc-machine\x2did.mount is the mount for /etc/machine-id | 11:25 |
| ogra_ | underneath local-fs-pre.target everything that starts with etc must go | 11:25 |
| Chipaca | $ systemd-escape -u 'etc-machine\x2did.mount' | 11:25 |
| Chipaca | etc/machine-id.mount | 11:25 |
| ogra_ | we are handling these from initrd already | 11:25 |
| ogra_ | ah, k, thats legit then | 11:25 |
| Chipaca | and etc-systemd-system.mount is the /etc/systemd/system mount unit | 11:26 |
| ogra_ | right, thats already mounted | 11:27 |
| ogra_ | andthing starting with /etc from /etc/system-image/writable-paths is handled first from the initrd now ... bypassing fstab so that we have it available immediately if we switch to systemd | 11:28 |
| ogra_ | *anything | 11:28 |
| ogra_ | so the systemd usnits need to go to not duplicate that | 11:29 |
| Chipaca | ogra_: so that's why we're getting those warnings, i'd bet | 11:29 |
| Chipaca | i mean things like “var-lib-snappy.mount: Directory /var/lib/snappy to mount over is not empty, mounting anyway.” | 11:30 |
| ogra_ | soo ... 100s boot time ... 50 s are clout-init hogging the hwarware | 11:30 |
| ogra_ | no | 11:30 |
| ogra_ | thats because the readonly dir isnt empty :) | 11:30 |
| ogra_ | var gets handled by fstab | 11:30 |
| ogra_ | and the readonly dir has the original content still | 11:30 |
| ogra_ | if you get them for any /etc dir, that would be wron though | 11:31 |
| ogra_ | because that should be handled before systemd starts | 11:31 |
| Chipaca | ogra_: http://pastebin.ubuntu.com/13081516/ | 11:32 |
| ogra_ | why the heck do we create 15 ram devices ? | 11:32 |
| ogra_ | nothing uses them | 11:32 |
| ogra_ | Chipaca, yeah, all the etc- ones need to go | 11:33 |
| Chipaca | i don't know if i should be glad you now know how to create these plots, or concerned you now have something new to obsess over :-) | 11:33 |
| ogra_ | oh, i know how to call systemd --analyze :) i just dont do it often | 11:34 |
| Chipaca | ah, ok | 11:34 |
| Chipaca | ogra_: also: systemd-analyze blame | 11:35 |
| ogra_ | it should be part of your tests to run systemd --analyze once on a virgin image before the testing starts | 11:35 |
| ogra_ | *our | 11:35 |
| ogra_ | well, that chart shows how bad the cloud-init impact is ... half of the boot time is eaten by it | 11:37 |
| ogra_ | cloud-init-local.service (17.575s) ....cloud-init.service (13.563s) ....cloud-config.service (10.547s) ...cloud-final.service (9.292s) | 11:38 |
| ogra_ | sums up to ~50s | 11:38 |
| ogra_ | sigh | 11:38 |
| ogra_ | i wish we could drop it and have specific cloud rootfses | 11:38 |
| Chipaca | ogra_: we can | 11:39 |
| Chipaca | ogra_: it's just work :) | 11:39 |
| ogra_ | generating ssh keys should be part of the upgrade ... what else does it do ? | 11:39 |
| Chipaca | isn't cloud-init the thing copying the public key so you can ssh in on first boot? | 11:40 |
| ogra_ | you mean in --developer-mode ? | 11:40 |
| Chipaca | yes | 11:40 |
| ogra_ | i think u-d-f copies it in place, doesnt it ? | 11:40 |
| ogra_ | it definitely generates host keys ... | 11:41 |
| ogra_ | (which takes a while and shouldnt be part of the first boot but of the upgrade procesS) | 11:41 |
| Chipaca | udf copies the public keys to a place cloud-init picks them up from | 11:42 |
| ogra_ | only on a real first boot we shoudl generate them, but thats still faster done without cloud-init | 11:42 |
| Chipaca | why generate host keys on upgrade? | 11:42 |
| ogra_ | ah, well, so a simple [ -e $keypath ] || cp $keypath $keytarget | 11:42 |
| ogra_ | oh, right, we dont want to change them | 11:43 |
| ogra_ | well, still i bet you can do that in less than 50s :) | 11:43 |
| ogra_ | (and in parallel while the rest of the boot runs) | 11:43 |
| Chipaca | i thought sshd already does generate its own keys on startup | 11:45 |
| Chipaca | not sure why cloud init is doing that at all | 11:45 |
| ogra_ | the deb does :) | 11:45 |
| Chipaca | ah, on install? | 11:45 |
| ogra_ | from its postinst | 11:45 |
| Chipaca | right | 11:45 |
| ogra_ | right | 11:45 |
| ogra_ | so you would have the same key everywhere | 11:45 |
| ogra_ | looking at that chart i woder who said systemd boots faster than upstart :P | 11:47 |
| ogra_ | ubuntu-snappy.grub-migrate.service (2.174s) | 11:47 |
| ogra_ | heh | 11:47 |
| ogra_ | we should omit that on non grub systems :) | 11:48 |
| Chipaca | person 1: “systemd boots x% faster than sysv!” person 2..N: “systemd boots faster” | 11:49 |
| Chipaca | person N then goes on to implement 'snappy init', and the rest is history | 11:49 |
| ogra_ | haha | 11:49 |
| ogra_ | well, i really liked upstart and bootchart :) | 11:50 |
| Chipaca | i'd expect snappy init to have a suspiciously upstart-ish feel to it :-) | 11:50 |
| ogra_ | systemd-analyze only gets me half the info bootchart did (CPU and disk utilization were most important) | 11:50 |
| ogra_ | (i.e. the graphs at the top that bootchart generates) | 11:51 |
| ogra_ | i also dont think doing fine grained ordering o funits is possible like it was in upstart | 11:52 |
| ogra_ | systemd just tries to bluntly run everything in parallel ... thats probably fine if you have an SSD, lots of ram and CPU power ... but definitely not on low end systems | 11:54 |
| ogra_ | ... where you actually need to trade your IO and move jobs into IO gaps etc | 11:55 |
| Chipaca | ogra_: well, there is systemd-bootchart | 11:58 |
| ogra_ | yeah, i still have to try it, it needs to live in the initrd which makes it a bit awkward to use in snappy | 11:59 |
| === JamesTai1 is now known as JamesTait | ||
| === balloons is now known as Guest4533 | ||
| === Guest4533 is now known as ballons_ | ||
| === ballons_ is now known as balloons_ | ||
| === zyga is now known as watson | ||
| ogra_ | Chipaca, so our executive summary of the above: i look into moving /etc/writable handling into initrd, you look into 3 way merge integration in snappy config ? | 13:35 |
| Chipaca | ogra_: that sounds accurate. Although my "looking into" starts with "seek approval for" | 13:36 |
| ogra_ | heh | 13:36 |
| === balloons_ is now known as balloons | ||
| davidcalle | ogra_, ping | 13:43 |
| ogra_ | Chipaca, bug 1512361 for /etc/writable | 13:43 |
| ubottu | bug 1512361 in livecd-rootfs (Ubuntu) "/etc/writable should be handled by the initrd, not by rootfs builds" [Undecided,New] https://launchpad.net/bugs/1512361 | 13:43 |
| ogra_ | davidcalle, shoot | 13:43 |
| davidcalle | ogra_, will we see the raspi2 image in http://releases.ubuntu.com/15.04/ ? Or will it stay at "http://people.canonical.com/~platform/snappy/raspberrypi2/" ? | 13:44 |
| ogra_ | davidcalle, once it is build like the others it shoudl show up in the official download space | 13:44 |
| ogra_ | *built | 13:44 |
| davidcalle | ogra_, any eta? | 13:45 |
| ogra_ | i was hoping next stable release ... no promises though | 13:45 |
| ogra_ | i'll take care to update the linking | 13:45 |
| davidcalle | ogra_, actual question is... can we drop the "not official" bits on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ | 13:45 |
| ogra_ | yes | 13:45 |
| ogra_ | we should still have instructions how to create a rolling image though | 13:46 |
| davidcalle | ogra_, cool, thanks :) | 13:48 |
| ogra_ | mvo, elopio, you guys invalidated all snappy bugs in LP, i dont think we can do that, they need an upstream task and point to the github issue instead, else we cant milestone them anymore and they will vanish from all the lists | 13:50 |
| ogra_ | (i.e. they should get downstream tasks in LP) | 13:51 |
| elopio | ogra_: that was the proposed plan, they are now in milestones in github. | 13:53 |
| mvo | ogra_: we did ? https://bugs.launchpad.net/snappy looks pretty normal here. what am I missing? | 13:53 |
| ogra_ | elopio, that doesnt work | 13:53 |
| ogra_ | we maintain the milestone lists in LP | 13:53 |
| ogra_ | and as i understood sabdfl he wants to keep bug maintenance in LP ... so we nee downstream bugs there | 13:54 |
| elopio | ogra_: for snapcraft at least, the plan is to maintian the milestones in github. | 13:54 |
| ogra_ | hmm, k, was that approved ? | 13:54 |
| ogra_ | for snappy releases we cant move it over unless we move all the rest too | 13:55 |
| sabdfl | it was a valid suggestion at the time, but i have asked that we keep bug management in LP for now | 13:55 |
| sabdfl | we can sync git to LP for bug integration, i believe | 13:55 |
| sabdfl | i.e. bug closure through commit messages | 13:55 |
| ogra_ | right, thats what i meant with upstream tasks | 13:55 |
| elopio | and yeah, that message about maintaining bugs in launchpad came after gustavo told us to use github bugs. Which makes sense, because the code is for closing bugs, that we couldn't relate easily if they are kept in launchpad. | 13:55 |
| sabdfl | gustavo has the right idea of course, and i hope he'll forgive my bdfl'ing ;) | 13:56 |
| ogra_ | elopio, sure, niemeyer's concept makes sense but if we do the master management for the project in LP they need to be linked up | 13:56 |
| elopio | anything works for me. I would prefer to file bugs only once, and to have them closer to the code. | 13:56 |
| ogra_ | since snappy is onnly one component of the snappy project here | 13:57 |
| ogra_ | elopio, thats what i meant when i started the discussion ;) | 13:57 |
| elopio | but if the plan changes, I can revert the bugs. | 13:57 |
| ogra_ | we force ourselves into more work/duplication here | 13:57 |
| elopio | ogra_: btw, we just did the full bug migration for snapcraft. | 13:57 |
| sabdfl | elopio, that's what caught me by surprise, i think we're being over-enthusiastic in adoption of github | 13:58 |
| sabdfl | your colleagues colin watson and co are working hard to add git support to LP, for example | 13:58 |
| sabdfl | and the bug tracking in LP is considered better than GH, at least for OpenStack purposes | 13:58 |
| ogra_ | well, it is upstream bugs vs project bugs ... | 13:58 |
| elopio | as far as I understand, the plan is to do the same for snappy, the go package. For snappy the project, related to ubuntu-core-config and stuff like that, I think we'll keep bugs in launchpad. | 13:58 |
| ogra_ | i think it is fine to maintain the snappy (tool) upstream bugs in github if desired ... but project mgmt still happens in LP | 13:59 |
| elopio | but again, I'm just following the plan from last week. | 13:59 |
| sabdfl | let's not confuse things more than necessary, and thank you ogra but i'll decide what's fine by me ;) | 13:59 |
| ogra_ | heh, k :) | 13:59 |
| * ogra_ just tries to please both sides :) | 14:00 | |
| elopio | sabdfl: it made me a little sad to move away from launchpad, because I like it, it's free software and all... | 14:00 |
| elopio | but, with a week of being in github we are already starting to get nice things, like travis and coveralls integration. | 14:00 |
| sabdfl | that's fine for the code, enjoy | 14:00 |
| sabdfl | and please put your happy face on for the free software and all ... ;) | 14:00 |
| elopio | also, I think I've heard three of our external contributors saying: "yay github!" | 14:00 |
| sabdfl | yay github | 14:01 |
| sabdfl | can we move on please? thank you | 14:01 |
| elopio | http://ur1.ca/o84zl ;) | 14:02 |
| sabdfl | bazinga | 14:05 |
| ogra_ | lol | 14:05 |
| elopio | Chipaca: plars: I got ip4 in bbb. | 14:31 |
| ogra_ | yay | 14:31 |
| elopio | the test is running in the lab. | 14:31 |
| plars | elopio: awesome, was there a fix that went in to intentionally correct it? | 14:32 |
| plars | elopio: oh, no it's not... see my email :( | 14:32 |
| plars | elopio: MAJOR outage in taipei right now I'm afaid :( | 14:32 |
| elopio | plars: yes, Chipaca worked on it last week. | 14:32 |
| Chipaca | week before | 14:32 |
| elopio | plars: ok, I'll wait. | 14:32 |
| plars | Chipaca++ | 14:32 |
| plars | elopio: it will queue up in SPI and run if/when things come back to life | 14:32 |
| Chipaca | last week we sat around waiting for it to land on the images, which got slowed down over the move to gh | 14:33 |
| ogra_ | Chipaca, we need to make a decision what to do with interface names in rolling | 14:33 |
| Chipaca | ogra_: why? | 14:33 |
| ogra_ | for stable we force them into being "eth0" | 14:33 |
| ogra_ | or ethX | 14:33 |
| ogra_ | in rolling we dont yet | 14:33 |
| ogra_ | (via the net.ifnames=0 cmdline option) | 14:34 |
| ogra_ | if we allow non ethX names we need to take that into account in snappy config | 14:34 |
| Chipaca | ogra_: where do we restrict to ethX names in snappy config? | 14:35 |
| Chipaca | i know snappy firstboot doesn't | 14:35 |
| Chipaca | (because i wrote it :) ) | 14:35 |
| ogra_ | Chipaca, in the kernel commandline we set net.ifnames=0 ... in stable only | 14:35 |
| ogra_ | which forces the old device naming scheme | 14:35 |
| ogra_ | we dont do that in rolling yet ... which means we'll end up with the new names | 14:36 |
| Chipaca | ogra_: yes, but that's been the case since the austin sprint at least | 14:36 |
| ogra_ | (worst case a full mac address as name) | 14:36 |
| Chipaca | we've been getting ens3 in kvm since then | 14:36 |
| ogra_ | ah, and it is handled fine ? | 14:36 |
| ogra_ | i know on arm we dont get such a friendly name | 14:37 |
| Chipaca | to the point you didn't know :) | 14:37 |
| Chipaca | the bbb still gets eth0 for its ethernet port | 14:37 |
| ogra_ | (at least on rpi it will be the mac) | 14:37 |
| Chipaca | speaking of which, have you set aside a bit of time to make the bbb oem for rolling bring up the options with the right args? | 14:37 |
| Chipaca | (or should i do it) | 14:37 |
| ogra_ | yeah, the bbb has a native NIC ... rpi has a USB one | 14:37 |
| Chipaca | bbb has both | 14:38 |
| ogra_ | which options exactly ? | 14:38 |
| Chipaca | gah | 14:39 |
| Chipaca | ogra_: what was the name of the module on the bbb that made the usb connection (the one you use to charge) also be a serial port and an ethernet device and on and on? | 14:39 |
| ogra_ | oh,, that stuff ! | 14:40 |
| ogra_ | cdc_acm or cdc_composite | 14:40 |
| Chipaca | hmm, i think that wasn't it | 14:41 |
| ogra_ | acm blocks the port and claims it exclusively for serial, composite allows multi usage (serial and usbnet for example) | 14:41 |
| Chipaca | but with that i can find it in the channel log | 14:41 |
| ogra_ | they shoudl both be there as modules | 14:41 |
| Chipaca | g_multi | 14:42 |
| Chipaca | sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p1 host_addr=D0:5F:B8:A3:92:81 iManufacturer=Circuitco iProduct=BeagleBoneBlack iSerialNumber=C0-3614BBBK6053 idProduct=0 idVendor=0 luns=0 nofua=Y num_buffers=2 qmult=5 removable=Y stall=N | 14:42 |
| ogra_ | (RaspberryPi2)ubuntu@rpi2:~$ find /lib/modules/ -name '*cdc*'|grep usb | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_ncm.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_ether.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_eem.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc-phonet.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_mbim.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/cdc_subset.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/net/usb/huawei_cdc_ncm.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/usb/class/cdc-wdm.ko | 14:42 |
| ogra_ | /lib/modules/4.2.0-1008-raspi2/kernel/drivers/usb/class/cdc-acm.ko | 14:42 |
| ogra_ | (sorry for the spam) | 14:42 |
| Chipaca | right, but this is the beebeeb | 14:42 |
| ogra_ | should be the same kernel config | 14:43 |
| Chipaca | you're going to make me take it out and plug it in, aren't you | 14:43 |
| Chipaca | so evil | 14:43 |
| ogra_ | haha | 14:43 |
| ogra_ | hmm, no ppisati ... i'D love to know why composite isnt enabled | 14:44 |
| ogra_ | nor serial | 14:44 |
| ogra_ | and searching for "gadget2 doesnt reveal anything either | 14:44 |
| ogra_ | *gadget | 14:44 |
| ogra_ | neither g_serial is there | 14:46 |
| ogra_ | hmpf | 14:46 |
| ogra_ | doesnt look like gadget support is enabled at all in any of our kernels | 14:47 |
| Chipaca | ogra_: it does have cdc_ether, but loading it does nothing (and no options) | 14:50 |
| ogra_ | Chipaca, i'm happy to implement it, but i need support from the kernel team first | 14:50 |
| Chipaca | ogra_: OTOH, g_multi brings up usb0 no problem | 14:50 |
| ogra_ | yeah, cdc_ether is the PC side ... you want g_ether | 14:50 |
| Chipaca | ogra_: and that is what the debian it ships with does | 14:50 |
| ogra_ | or g_multi or g_composite | 14:50 |
| Chipaca | right, so we do have g_multi, and it works as above | 14:51 |
| Chipaca | what is missing? | 14:51 |
| ogra_ | i would assume we want that enabled in general on all devices | 14:51 |
| Chipaca | those parameters seem to be very device-dependent, to me | 14:51 |
| ogra_ | and a snappy config option to turn it on/off | 14:51 |
| Chipaca | even skipping the i* ones | 14:51 |
| ogra_ | g_multi is definitely a generic kernel module | 14:52 |
| ogra_ | it shoudl work on anything that has a usb host port | 14:52 |
| ogra_ | including x86 hardware | 14:52 |
| Chipaca | *shock* | 14:52 |
| Chipaca | ogra_: nice to know :) | 14:53 |
| ogra_ | module options are indeed device specific and should come from the device tarball | 14:53 |
| sergiusens | Chipaca, mvo so DST explains why we missed some US folk ;-) | 14:53 |
| ogra_ | oh yeah, can we please move that meeting :) | 14:53 |
| Chipaca | if you move it, make it at least +2h, not just +1h | 14:54 |
| Chipaca | please :) | 14:54 |
| ogra_ | yeah | 14:54 |
| * ogra_ likes to have it at the start or the end of the day ... currently it is an interruption in the middle of my day | 14:54 | |
| ogra_ | and we force USians to realyl get up early | 14:55 |
| Chipaca | I'm +1 to doing it at 9:30z also | 15:01 |
| Chipaca | agreed then \o/ | 15:01 |
| Chipaca | ogra_: why is there /etc/modprobe.d/modprobe.d ? | 15:07 |
| Chipaca | ogra_: on purpose, or is that a double-mount-oopie? | 15:07 |
| Chipaca | oopsie* | 15:07 |
| ogra_ | loks like a bug | 15:08 |
| Chipaca | ogra_: but the nice kind of bug | 15:11 |
| Chipaca | like a pretty butterfly | 15:11 |
| Chipaca | that flies past | 15:11 |
| ogra_ | heh | 15:11 |
| Chipaca | and lands on SOMEBODY ELSE'S PLATE | 15:11 |
| Chipaca | \o/ | 15:11 |
| * elopio upgrades to wily with one hand, and to x with the other. Fearless. | 15:19 | |
| sergiusens | Chipaca, ogra_ +2 is just at my lunch time though and a no go for mvo | 15:24 |
| ogra_ | so we want 1h ? | 15:24 |
| Chipaca | pindonga: i haven't tried that though :) | 15:31 |
| pindonga | Chipaca, like have both read/write from that server/ | 15:31 |
| pindonga | ? | 15:31 |
| Chipaca | like the transmission snap listens for torrent files on a certain port | 15:32 |
| === nessita_ is now known as nessita | ||
| Chipaca | or dbus endpoint | 15:32 |
| Chipaca | or sth | 15:33 |
| * Chipaca 's handwaving intensifies | 15:33 | |
| === a0rora_ is now known as a0rora | ||
| sergiusens | pindonga, Chipaca the other solution is maybe just put it all in the same snap? Create a product instead of just sw packages ;-) | 15:37 |
| Chipaca | yes | 15:37 |
| pindonga | sergiusens, so much for reusability :/ | 15:37 |
| pindonga | but ok | 15:38 |
| sergiusens | pindonga, you reuse the sources ;-) | 15:38 |
| sergiusens | pindonga, this is no different from how you do it on a phone | 15:38 |
| Chipaca | ogra_: shouldn't the bbb have writable /etc/modules-load.d/<something> already? | 15:39 |
| pindonga | on the phone I could probably use the media hub to store the files, couldn't i? | 15:39 |
| sergiusens | pindonga, right, and reusability, why does venv exist? | 15:39 |
| sergiusens | :-) | 15:39 |
| pindonga | what do you mean? | 15:39 |
| Chipaca | pindonga: he's trying to be mean | 15:39 |
| pindonga | I meant, someone already packaged transmission, fought apparmor, etc | 15:40 |
| pindonga | now I need to do that all over again | 15:40 |
| pindonga | and if I wanted to use deluge instead of transmission, all over again | 15:40 |
| sergiusens | pindonga, oh, then you want to write a content sharing framework, maybe called, content-hub ;-) | 15:40 |
| pindonga | aka fs? | 15:41 |
| pindonga | :) | 15:41 |
| sergiusens | pindonga, I defer to jdstrand | 15:41 |
| * pindonga understands the underlying reasons | 15:41 | |
| pindonga | maybe we could introduce the concept of data volumes? | 15:42 |
| pindonga | that snaps can bind-mount or something? | 15:42 |
| pindonga | otherwise, you'd get the same issue with a music player | 15:42 |
| pindonga | the player would have to implement nfs/smb/whatever to get access to the files to play | 15:43 |
| pindonga | instead of just focusing on playing those files | 15:43 |
| ogra_ | Chipaca, in stable it surely should ... | 15:48 |
| Chipaca | ogra_: ah, this is rolling. not in rolling then? | 15:48 |
| ogra_ | might be missing there, i have to check | 15:52 |
| Chipaca | 'ppreciated | 15:53 |
| ogra_ | add /etc/modules-load.d to writable dirs (LP: #1496419) | 15:54 |
| ubottu | Launchpad bug 1496419 in Snappy "iptable_filter and ip6table_filter do not auto load" [High,Fix committed] https://launchpad.net/bugs/1496419 | 15:54 |
| ogra_ | hmm, thats in both, wily and xenial | 15:54 |
| ogra_ | http://launchpadlibrarian.net/221767581/ubuntu-core-config_0.6.29_0.6.30.diff.gz | 15:54 |
| ogra_ | Chipaca, so rolling shoudl be fine | 15:57 |
| === You're now known as ubuntulog2 | ||
| === beuno_ is now known as beuno | ||
| snappy_ | any1 get mir running on snappy edge? | 16:34 |
| elopio | snappy_: tedg is working on that. The snap is not ready. | 16:37 |
| tedg | elopio: Not me, that's a kgunn thing. | 16:37 |
| tedg | You've confused your Texans ;-) | 16:38 |
| tedg | Okay, I've managed to confuse myself with git. | 16:43 |
| tedg | I made a branch "aws-iot" the updated version got pushed to the snapcraft repo, which wasn't what I wanted. | 16:43 |
| tedg | So I'd like to now merge it into my fork of snap craft. | 16:43 |
| tedg | How do I merge from "ubuntu-core/snapcraft/aws-iot" to "ted-gould/snapcraft/aws-iot" | 16:44 |
| tedg | I feel like Github is obfuscating Git who wasn't clear to begin with. | 16:44 |
| ogra_ | just bzr merge ... oh, wait ... :P | 16:45 |
| tedg | I do find the "you've got the whole repo" thing confusing. Not sure why they did that. | 16:47 |
| sergiusens | mvo, is there a way to know before hand what apt.Cache.fetch_archives will fetch? | 16:50 |
| sergiusens | tedg, git push to the correct remote | 16:50 |
| sergiusens | tedg, git remote add sergiusens git@github.com:sergiusens/snapcraft.git | 16:51 |
| sergiusens | tedg, git remote add ted git@github.com:tedgould/snapcraft.git | 16:51 |
| tedg | sergiusens: I don't want to push, I want to update my branch, I need to pull? | 16:52 |
| sergiusens | tedg, git push ted | 16:52 |
| sergiusens | tedg, with what is in the upstream repo? | 16:52 |
| tedg | sergiusens: yes | 16:52 |
| tedg | Specifically the aws-iot branch | 16:52 |
| sergiusens | tedg, git fetch origin; git merge [origin/branch] (or something like that) | 16:55 |
| sergiusens | tedg, I knew I gave you 'write' too early ;-) | 16:56 |
| tedg | That's what I can't figure out :-) The syntax for branches on remotes. | 16:56 |
| tedg | Heh, yes! | 16:56 |
| sergiusens | tedg, all your branches are in ubuntu-core instead of 'ted' | 16:57 |
| sergiusens | tedg, https://github.com/ubuntu-core/snapcraft/branches | 16:57 |
| snappy_ | Chipaca: do you have mir working w/ spice? | 16:58 |
| mvo | sergiusens: sort of but not really as it depends on the server, in apt experiemtnal this is better. I need to leave for hockey, but we can talk later or tomorrow | 16:59 |
| tedg | sergiusens: No, some are. | 17:01 |
| Chipaca | snappy_: me, personally? i haven't checked in ages | 17:01 |
| tedg | snappy_: Yeah, I do. | 17:02 |
| snappy_ | tedg: Chipaca: what changes do I need to make to get mir running w/ spice in kvm? | 17:08 |
| snappy_ | tedg: Chipaca: is there a tutorial anywhere? | 17:10 |
| Chipaca | snappy_: use virt-manager, set video driver to "spice" | 17:14 |
| snappy_ | Chipaca: when i run clocks demo, I get an 'connection to Mir server failed' error | 17:19 |
| Chipaca | snappy_: do you get a black screen and a pointer? | 17:19 |
| snappy_ | Chipaca: no. nothing shows after i install mir | 17:20 |
| Chipaca | snappy_: running with virt-manager, using the spice video driver thing? | 17:20 |
| snappy_ | Chipaca: hm. I was starting using kvm command in terminal. I'll try virt-manager. thx | 17:22 |
| Chipaca | snappy_: all virt-manager does, supposedly, is set options on kvm. But I gave up trying to use kvm directly for this. | 17:25 |
| tedg | Yeah, no tutorial I know of, but virt-manager usage. | 17:30 |
| tedg | QXL as well. | 17:31 |
| tedg | Okay, I got the branch, now I can't push :-( | 17:35 |
| tedg | Git makes me sad | 17:35 |
| ogra_ | until you understand it ... then bzr makes you sad it seems | 17:35 |
| ogra_ | (at least thats what i see from others :) ) | 17:36 |
| tedg | Others make me sad | 17:36 |
| ogra_ | lol | 17:36 |
| sergiusens | mvo, sure, go ahead; I was looking into using a common download location for each part, but I need to keep track of what go downloaded | 17:45 |
| sergiusens | if context helps :-) | 17:45 |
| snappy_ | Chipaca: I dont see the black screen and pointer on virt-manager with spice server. Any suggestions? | 17:48 |
| Chipaca | snappy_: check the mir service log | 17:52 |
| snappy_ | Chipaca: ubuntu-core-launcher mir_demo_server: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by mir_demo_server) | 18:00 |
| Chipaca | snappy_: there ya go then | 18:04 |
| snappy_ | Chipaca: it works in older version of snappy. Do I need to add lib to snap? | 18:05 |
| Chipaca | tedg: wasn't there a lovely libc abi breakage in ~wily? | 18:06 |
| === joc_ is now known as joc|away | ||
| snappy_ | Chipaca: how to fix? | 18:24 |
| tedg | Chipaca: Not libc, libstdc++ | 18:30 |
| tedg | snappy_: You probably want to build with either vivid or remove libstdc++ from the blocked list. | 18:31 |
| tedg | We need to revise that in snapcraft | 18:31 |
| tedg | In the end, you want to be carrying your own version of libstdc++ | 18:32 |
| snappy_ | tedg: chipaca: ok thanks. How do i remove from blocked list? If i build in vivid, do I need to compile mir.snap ? | 18:37 |
| Chipaca | snappy_: what're you building in vivid? | 18:46 |
| snappy_ | Chipaca: libstdc++ | 18:52 |
| Chipaca | snappy_: why would you do that? | 18:52 |
| ogra_ | to ship the binary in the snap | 18:53 |
| ogra_ | though i guess you could just use the deb one in LD_LIBRARY_PATH | 18:54 |
| Chipaca | but then they'd have to ship libc also | 18:56 |
| Chipaca | and libnss | 18:56 |
| Chipaca | the whole thing | 18:56 |
| ogra_ | yep | 18:57 |
| ogra_ | we'll need that anyway :) | 18:57 |
| ogra_ | as snapcraft setup | 18:57 |
| snappy_ | Chipaca: do u know an easier way? | 19:21 |
| snappy_ | Chipaca: to get mir? | 19:22 |
| Chipaca | snappy_: you've got the mir snap, right? | 19:23 |
| Chipaca | snappy_: and it's not working because the libc++ abi in your snappy system is different from the abi of the package | 19:24 |
| Chipaca | snappy_: that's a problem you _shouldn't_ have, but you do; apologies | 19:24 |
| davmor2 | Chipaca: there were incompatible gcc in wily, between 4.7 in vivid and 5.x in wily if that is the abi break you are on about | 19:25 |
| Chipaca | snappy_: have you tried a different version snappy system? I haven't looked into this at all, but maybe it'll work in 15.04? | 19:25 |
| Chipaca | snappy_: or if you're in 15.04, maybe rolling works? | 19:25 |
| Chipaca | i know tedg has been working with mir and hasn't mentioned this problem | 19:25 |
| snappy_ | Chipaca: hmm.... ill try and see if i can get a different result thx | 19:31 |
| snappy_ | Chipaca: I was able to get a different version of mir to work! | 19:40 |
| Chipaca | snappy_: there are different versions? | 19:40 |
| Chipaca | packaged i mean? | 19:40 |
| snappy_ | Chipaca: no... i compiled one | 19:40 |
| Chipaca | ah! | 19:40 |
| Chipaca | heh | 19:41 |
| snappy_ | Chipaca: how do I fix socket configuration for clocks example? | 19:41 |
| snappy_ | Chipaca: thx for help | 19:42 |
| tedg | Vivd should be find as long as you're using the 15.04 snappy. | 19:55 |
| kyrofa | Can ubuntu-device-flash be used to preload the image with snaps? | 21:23 |
| kyrofa | (or is there another way to do that?) | 21:24 |
| tedg | In theory that's what the gadget snap should do. | 21:25 |
| tedg | It should define which are the preloaded ones. | 21:25 |
| kyrofa | Ah, cool okay | 21:26 |
| kyrofa | tedg, does that actually include the specified snaps, or install them after deployment? | 21:26 |
| tedg | kyrofa: Not sure. | 21:39 |
| snappy_ | Chipaca: To get socket working w/ snap, how to fix? | 22:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
