liuxgif my app is running on a raspberry pi, how can I get the output message like fmt.Printlin in golang? thanks.03:18
stgraberChipaca: 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
stgraberChipaca: 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 escalation05:32
stgraberI 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 much05:34
dholbachgood morning07:21
=== zyga-afk is now known as zyga
zygagood morning07:41
sabdflhi folks, who can help with some mail system and mailman debugging?08:17
Chipacastgraber: for now, use the current symlink if you really need to09:20
Chipacastgraber: wrt root escalation, i don't follow the exploit, but i haven't had your coffee yet09:21
Chipacastgraber: i mean my coffee09:21
Chipacasee what i mean09:21
Chipacastgraber: if current isn't good enough, you can airgap09:21
Chipacastgraber: but that's brittle09:22
Chipacastgraber: before eoy the random versions should go away, but maybe also the versions go away from the filesystem (replaced by revisions), I don't know09:23
longsleepGood morning snappy09:31
JamesTaitGood morning all; happy Monday, and happy Deviled Egg Day! 😃09:49
Chipacathis coffee smells like strawberries and cream10:15
Chipacamy senses are so confused10:15
Chipacaogra_: you around?10:17
ogra_pretty much, yeah :)10:17
Chipacaogra_: what's the thing that does the thing?10:19
ogra_we call it the thing10:19
Chipacaogra_: the handling of config files changed on upgrade10:19
ogra_sabdfl, mailman -> barry, mail system -> probably lamont10:20
ogra_Chipaca, how10:20
Chipacaogra_: i understood you to say last week, that for individual writable /etc files, we have special magic that handles upgrades10:21
ogra_right, in the initrd10:21
ogra_sync_dirs() and handle_writable_paths() in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs10:22
* Chipaca looks10:23
ogra_the prob is that we can not use that setup with /etc/writable/ because these files are usually having local changes10:23
Chipacaogra_: 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 defaults10:24
ogra_so we do never upgrade the files in /etc/writable10:24
Chipacaso the problem isn't /etc/writable10:24
Chipacathe problem is that we don't 3-way merge10:24
Chipacaat all10:24
ogra_the problem is the concept10:24
Chipacaand for some things, that is entirely correct10:25
ogra_there isnt really a proper way to do that since we dont really have one specific syntax in configs10:25
Chipacaso our problem is that for some things it isn't10:25
ogra_so you would need a handler with 100s of plugins or something to handle all 3 way cases10:25
Chipacaor, not expose the raw config files10: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 files10:26
Chipacanow === 4 releases ago10:26
ogra_like hostname, localtime and timezone10:26
ogra_well, it is the only dir where atomic changes are possible10:27
Chipacayes, but again, the problem isn't atomic changes or not, it's the 3-way merge10:27
ogra_well, not the only one, but the only one in etc10:27
Chipacaso even if we drop atomic writes, we still have the problem10: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 ever10:32
Chipacaogra_: and the phone doesn't do rollbacks10:33
ogra_for rollbacks you would need duplication of the files10:33
=== zyga is now known as zyga-afk
Chipacahow 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 version10:34
ogra_(and a still three way merge boot handler i guess)10:34
ogra_*still a10:34
Chipacadoes that sound right?10:34
ogra_well, that means you will need one handler for each config file10:34
Chipacawe already do have that10:35
ogra_thesy will all differ in format10:35
ogra_for system configs ?10:35
Chipacabut they're just stupid :) -- we need to make them smarter10:35
Chipacaoh, yes10:35
Chipacahere, let me link ya10:35
Chipacaogra_: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go10:35
ogra_oh, well10:36
Chipacamost of them just call get/setPassthrough, which just writes it out10:36
ogra_if you want to modify content you will need a function per config file10:36
Chipacabut i'd rather fix those, than write a 3-way-merge handler for each case, which i deem harder-to-impossible10:37
ogra_but even tthen you would need a config file per rootfs10:37
Chipaca"a config file per rootfs"?10:37
ogra_unless you want to re-write them on going back and forward all the time10:37
ogra_yes, you need a writable/a and a writable/b10:37
Chipacaor rewrite them every time, yes10:38
ogra_well, rather not10:38
Chipacai'm fine with either10: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 data10:39
ogra_which means the upgrade mechanism needs to become more intelligent10:40
ogra_Chipaca, for the three way merge we should probably look at ucf10:41
Chipacaso, on rollback/upgrade, you'd call (say), snappy internal config-regen10:41
ogra_it already handles exqactly that10:41
Chipacawill do10:41
ogra_(and it is preinstalled)10:42
Chipacawrt 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 about10:42
Chipacaogra_: but ucf drops back to being interactive10:42
Chipacadoesn't it?10:42
ogra_you can avoid that10: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 reboot10:44
ogra_if there is a lot to handle your first boot after upgrade might be painfully slow10:44
ogra_better handle it when you actually expect the upgrade to take time anyway, because you ran the upgrade command10:45
Chipacanote it'd have to be the new snappy, but that's easily doable fwiw10:45
Chipacaanyway. Lots of work.10:45
Chipacaogra_: sounds like we move forward with using /etc/writable for everything, and handle merges "soon"10:46
Chipacaogra_: is that accurate?10:46
ogra_well, i'D prefer if we wouldnt use /etc/writable10:47
Chipacatell me more10:47
ogra_it means that the file needs to be maintained in a far more complex way at image build time10:47
ogra_/etc/system-image/writable-paths is a single one liner10:48
ogra_while the livecd-rootfa handling of /etc/writable means scripting for each file10:48
ogra_it was never throught as a general solution10:49
ogra_but as an exception for the few files that need atomic writing in a normal ubuntu system10:49
Chipacahow 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 stomach10:52
ogra_well, the fact that we make ourselves 100% depending on livecd-rootfs hacks  bothers me here10:52
ogra_a new image build system will need exactly the same hacks10:52
ogra_i'd really like us to get away from that instead of adding more to it10:52
Chipacaah, i hadn't understood10:54
Chipacai thought the handling of /etc/s-i/w-p was in livecd-rootfs10:54
ogra_no, thats in the initrd10:54
Chipacaif it's in s-i, maybe the other can be addressed there too10:54
ogra_in the script above10:54
Chipacaforgot to look at the thing that was getting that10:54
ogra_(which is technically s-i client side :) )10:54
ogra_it parses writable-paths and creates the mounts and all10:55
ogra_(and fstab entries for the dirs that systemd should handle (everythin but /etc))10:55
Chipacaah, the problem just hit me10:58
Chipacainitrd can't fix the /etc/writable usage because it can't create the symlinks10:58
Chipacadumb me10: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 script10:59
ogra_well, we could probably teach it to11: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 filenames11:04
=== zyga-afk is now known as zyga
Chipacaogra_: 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 up11:08
ogra_(and /etc/writable is writable)11:08
ogra_it will indeed chak, if links exist it doesnt need to create them11:08
ogra_thats a one time think if a new file shows up11:08
ogra_my go, my typing today11:08
* ogra_ needs new kbd soon11:09
Chipacaogra_: fwiw every mountpoint we remove drops boot time on the bbb by .1--.2s11:14
Chipacaogra_: http://people.canonical.com/~john/bbb.svg11:19
Chipacaogra_: ( systemd-analyze plot > bbb.svg )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
Chipacapondering the meaning of life11:20
Chipacaunpacking initrd?11:20
ogra_the etc mount units need to be removed11:20
ogra_for 17s ?!?11:21
ogra_if that takes 2s thats much11:21
Chipacajust booting the kernel, afaict11:21
ogra_i would like to know how much of that is actually kernel time and how much initrd11:21
ogra_and what exactly in the initrd makes it so super slow11:22
Chipacaah, of course, all that is hidden in there :-(11:22
Chipacamaybe 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 earlier11:23
ogra_heh, yeah11:23
ogra_17s *before* systemd is realyl awful11:24
Chipacaetc-machine\x2did.mount is the mount for /etc/machine-id11:25
ogra_underneath local-fs-pre.target everything that starts with etc must go11:25
Chipaca$ systemd-escape -u 'etc-machine\x2did.mount'11:25
ogra_we are handling these from initrd already11:25
ogra_ah, k, thats legit then11:25
Chipacaand etc-systemd-system.mount is the /etc/systemd/system mount unit11:26
ogra_right, thats already mounted11: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 systemd11:28
ogra_so the systemd usnits need to go to not duplicate that11:29
Chipacaogra_: so that's why we're getting those warnings, i'd bet11:29
Chipacai 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 hwarware11:30
ogra_thats because the readonly dir isnt empty :)11:30
ogra_var gets handled by fstab11:30
ogra_and the readonly dir has the original content still11:30
ogra_if you get them for any /etc dir, that would be wron though11:31
ogra_because that should be handled before systemd starts11:31
Chipacaogra_: http://pastebin.ubuntu.com/13081516/11:32
ogra_why the heck do we create 15 ram devices ?11:32
ogra_nothing uses them11:32
ogra_Chipaca, yeah, all the etc- ones need to go11:33
Chipacai 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 often11:34
Chipacaah, ok11:34
Chipacaogra_: also: systemd-analyze blame11:35
ogra_it should be part of your tests to run systemd --analyze once on a virgin image before the testing starts11:35
ogra_well, that chart shows how bad the cloud-init impact is ... half of the boot time is eaten by it11: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 ~50s11:38
ogra_i wish we could drop it and have specific cloud rootfses11:38
Chipacaogra_: we can11:39
Chipacaogra_: it's just work :)11:39
ogra_generating ssh keys should be part of the upgrade ... what else does it do ?11:39
Chipacaisn'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
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
Chipacaudf copies the public keys to a place cloud-init picks them up from11:42
ogra_only on a real first boot we shoudl generate them, but thats still faster done without cloud-init11:42
Chipacawhy generate host keys on upgrade?11:42
ogra_ah, well, so a simple [ -e $keypath ] || cp $keypath $keytarget11:42
ogra_oh, right, we dont want to change them11: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
Chipacai thought sshd already does generate its own keys on startup11:45
Chipacanot sure why cloud init is doing that at all11:45
ogra_the deb does :)11:45
Chipacaah, on install?11:45
ogra_from its postinst11:45
ogra_so you would have the same key everywhere11:45
ogra_looking at that chart i woder who said systemd boots faster than upstart :P11:47
ogra_ubuntu-snappy.grub-migrate.service (2.174s)11:47
ogra_we should omit that on non grub systems :)11:48
Chipacaperson 1: “systemd boots x% faster than sysv!”  person 2..N: “systemd boots faster”11:49
Chipacaperson N then goes on to implement 'snappy init', and the rest is history11:49
ogra_well, i really liked upstart and bootchart :)11:50
Chipacai'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 upstart11: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 systems11:54
ogra_... where you actually need to trade your IO and move jobs into IO gaps etc11:55
Chipacaogra_: well, there is systemd-bootchart11: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 snappy11: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
Chipacaogra_: that sounds accurate. Although my "looking into" starts with "seek approval for"13:36
=== balloons_ is now known as balloons
davidcalleogra_, ping13:43
ogra_Chipaca, bug 1512361 for /etc/writable13:43
ubottubug 1512361 in livecd-rootfs (Ubuntu) "/etc/writable should be handled by the initrd, not by rootfs builds" [Undecided,New] https://launchpad.net/bugs/151236113:43
ogra_davidcalle, shoot13:43
davidcalleogra_, 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 space13:44
davidcalleogra_, any eta?13:45
ogra_i was hoping next stable release ... no promises though13:45
ogra_i'll take care to update the linking13:45
davidcalleogra_, actual question is... can we drop the "not official" bits on https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/13:45
ogra_we should still have instructions how to create a rolling image though13:46
davidcalleogra_, 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 lists13:50
ogra_(i.e. they should get downstream tasks in LP)13:51
elopioogra_: that was the proposed plan, they are now in milestones in github.13:53
mvoogra_: we did ? https://bugs.launchpad.net/snappy looks pretty normal here. what am I missing?13:53
ogra_elopio, that doesnt work13:53
ogra_we maintain the milestone lists in LP13:53
ogra_and as i understood sabdfl he wants to keep bug maintenance in LP ... so we nee downstream bugs there13:54
elopioogra_: 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 too13:55
sabdflit was a valid suggestion at the time, but i have asked that we keep bug management in LP for now13:55
sabdflwe can sync git to LP for bug integration, i believe13:55
sabdfli.e. bug closure through commit messages13:55
ogra_right, thats what i meant with upstream tasks13:55
elopioand 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
sabdflgustavo 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 up13:56
elopioanything 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 here13:57
ogra_elopio, thats what i meant when i started the discussion ;)13:57
elopiobut if the plan changes, I can revert the bugs.13:57
ogra_we force ourselves into more work/duplication here13:57
elopioogra_: btw, we just did the full bug migration for snapcraft.13:57
sabdflelopio, that's what caught me by surprise, i think we're being over-enthusiastic in adoption of github13:58
sabdflyour colleagues colin watson and co are working hard to add git support to LP, for example13:58
sabdfland the bug tracking in LP is considered better than GH, at least for OpenStack purposes13:58
ogra_well, it is upstream bugs vs project bugs ...13:58
elopioas 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 LP13:59
elopiobut again, I'm just following the plan from last week.13:59
sabdfllet'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
elopiosabdfl: it made me a little sad to move away from launchpad, because I like it, it's free software and all...14:00
elopiobut, with a week of being in github we are already starting to get nice things, like travis and coveralls integration.14:00
sabdflthat's fine for the code, enjoy14:00
sabdfland please put your happy face on for the free software and all ... ;)14:00
elopioalso, I think I've heard three of our external contributors saying: "yay github!"14:00
sabdflyay github14:01
sabdflcan we move on please? thank you14:01
elopiohttp://ur1.ca/o84zl ;)14:02
elopioChipaca: plars: I got ip4 in bbb.14:31
elopiothe test is running in the lab.14:31
plarselopio: awesome, was there a fix that went in to intentionally correct it?14:32
plarselopio: oh, no it's not... see my email :(14:32
plarselopio: MAJOR outage in taipei right now I'm afaid :(14:32
elopioplars: yes, Chipaca worked on it last week.14:32
Chipacaweek before14:32
elopioplars: ok, I'll wait.14:32
plarselopio: it will queue up in SPI and run if/when things come back to life14:32
Chipacalast week we sat around waiting for it to land on the images, which got slowed down over the move to gh14:33
ogra_Chipaca, we need to make a decision what to do with interface names in rolling14:33
Chipacaogra_: why?14:33
ogra_for stable we force them into being "eth0"14:33
ogra_or ethX14:33
ogra_in rolling we dont yet14: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 config14:34
Chipacaogra_: where do we restrict to ethX names in snappy config?14:35
Chipacai know snappy firstboot doesn't14:35
Chipaca(because i wrote it :) )14:35
ogra_Chipaca, in the kernel commandline we set net.ifnames=0 ... in stable only14:35
ogra_which forces the old device naming scheme14:35
ogra_we dont do that in rolling yet ... which means we'll end up with the new names14:36
Chipacaogra_: yes, but that's been the case since the austin sprint at least14:36
ogra_(worst case a full mac address as name)14:36
Chipacawe've been getting ens3 in kvm since then14:36
ogra_ah, and it is handled fine ?14:36
ogra_i know on arm we dont get such a friendly name14:37
Chipacato the point you didn't know :)14:37
Chipacathe bbb still gets eth0 for its ethernet port14:37
ogra_(at least on rpi it will be the mac)14:37
Chipacaspeaking 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 one14:37
Chipacabbb has both14:38
ogra_which options exactly ?14:38
Chipacaogra_: 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_composite14:40
Chipacahmm, i think that wasn't it14:41
ogra_acm blocks the port and claims it exclusively for serial, composite allows multi usage (serial and usbnet for example)14:41
Chipacabut with that i can find it in the channel log14:41
ogra_they shoudl both be there as modules14:41
Chipacasudo 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=N14:42
ogra_(RaspberryPi2)ubuntu@rpi2:~$ find /lib/modules/ -name '*cdc*'|grep usb14:42
ogra_(sorry for the spam)14:42
Chipacaright, but this is the beebeeb14:42
ogra_should be the same kernel config14:43
Chipacayou're going to make me take it out and plug it in, aren't you14:43
Chipacaso evil14:43
ogra_hmm, no ppisati ... i'D love to know why composite isnt enabled14:44
ogra_nor serial14:44
ogra_and searching for "gadget2 doesnt reveal anything either14:44
ogra_neither g_serial is there14:46
ogra_doesnt look like gadget support is enabled at all in any of our kernels14:47
Chipacaogra_: 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 first14:50
Chipacaogra_: OTOH, g_multi brings up usb0 no problem14:50
ogra_yeah, cdc_ether is the PC side ... you want g_ether14:50
Chipacaogra_: and that is what the debian it ships with does14:50
ogra_or g_multi or g_composite14:50
Chipacaright, so we do have g_multi, and it works as above14:51
Chipacawhat is missing?14:51
ogra_i would assume we want that enabled in general on all devices14:51
Chipacathose parameters seem to be very device-dependent, to me14:51
ogra_and a snappy config option to turn it on/off14:51
Chipacaeven skipping the i* ones14:51
ogra_g_multi is definitely a generic kernel module14:52
ogra_it shoudl work on anything that has a usb host port14:52
ogra_including x86 hardware14:52
Chipacaogra_: nice to know :)14:53
ogra_module options are indeed device specific and should come from the device tarball14:53
sergiusensChipaca, mvo so DST explains why we missed some US folk ;-)14:53
ogra_oh yeah, can we please move that meeting :)14:53
Chipacaif you move it, make it at least +2h, not just +1h14:54
Chipacaplease :)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 day14:54
ogra_and we force USians to realyl get up early14:55
ChipacaI'm +1 to doing it at 9:30z also15:01
Chipacaagreed then \o/15:01
Chipacaogra_: why is there /etc/modprobe.d/modprobe.d ?15:07
Chipacaogra_: on purpose, or is that a double-mount-oopie?15:07
ogra_loks like a bug15:08
Chipacaogra_: but the nice kind of bug15:11
Chipacalike a pretty butterfly15:11
Chipacathat flies past15:11
Chipacaand lands on SOMEBODY ELSE'S PLATE15:11
* elopio upgrades to wily with one hand, and to x with the other. Fearless.15:19
sergiusensChipaca, ogra_ +2 is just at my lunch time though and a no go for mvo15:24
ogra_so we want 1h ?15:24
Chipacapindonga: i haven't tried that though :)15:31
pindongaChipaca, like have both read/write from that server/15:31
Chipacalike the transmission snap listens for torrent files on a certain port15:32
=== nessita_ is now known as nessita
Chipacaor dbus endpoint15:32
Chipacaor sth15:33
* Chipaca 's handwaving intensifies15:33
=== a0rora_ is now known as a0rora
sergiusenspindonga, Chipaca the other solution is maybe just put it all in the same snap? Create a product instead of just sw packages ;-)15:37
pindongasergiusens, so much for reusability :/15:37
pindongabut ok15:38
sergiusenspindonga, you reuse the sources ;-)15:38
sergiusenspindonga, this is no different from how you do it on a phone15:38
Chipacaogra_: shouldn't the bbb have writable /etc/modules-load.d/<something> already?15:39
pindongaon the phone I could probably use the media hub to store the files, couldn't i?15:39
sergiusenspindonga, right, and reusability, why does venv exist?15:39
pindongawhat do you mean?15:39
Chipacapindonga: he's trying to be mean15:39
pindongaI meant, someone already packaged transmission, fought apparmor, etc15:40
pindonganow I need to do that all over again15:40
pindongaand if I wanted to use deluge instead of transmission, all over again15:40
sergiusenspindonga, oh, then you want to write a content sharing framework, maybe called, content-hub ;-)15:40
pindongaaka fs?15:41
sergiusenspindonga, I defer to jdstrand15:41
* pindonga understands the underlying reasons15:41
pindongamaybe we could introduce the concept of data volumes?15:42
pindongathat snaps can bind-mount or something?15:42
pindongaotherwise, you'd get the same issue with a music player15:42
pindongathe player would have to implement nfs/smb/whatever to get access to the files to play15:43
pindongainstead of just focusing on playing those files15:43
ogra_Chipaca, in stable it surely should ...15:48
Chipacaogra_: ah, this is rolling. not in rolling then?15:48
ogra_might be missing there, i have to check15:52
ogra_add /etc/modules-load.d to writable dirs (LP: #1496419)15:54
ubottuLaunchpad bug 1496419 in Snappy "iptable_filter and ip6table_filter do not auto load" [High,Fix committed] https://launchpad.net/bugs/149641915:54
ogra_hmm, thats in both, wily and xenial15:54
ogra_Chipaca, so rolling shoudl be fine15:57
=== You're now known as ubuntulog2
=== beuno_ is now known as beuno
snappy_any1 get mir running on snappy edge?16:34
elopiosnappy_: tedg is working on that. The snap is not ready.16:37
tedgelopio: Not me, that's a kgunn thing.16:37
tedgYou've confused your Texans ;-)16:38
tedgOkay, I've managed to confuse myself with git.16:43
tedgI made a branch "aws-iot" the updated version got pushed to the snapcraft repo, which wasn't what I wanted.16:43
tedgSo I'd like to now merge it into my fork of snap craft.16:43
tedgHow do I merge from "ubuntu-core/snapcraft/aws-iot" to "ted-gould/snapcraft/aws-iot"16:44
tedgI feel like Github is obfuscating Git who wasn't clear to begin with.16:44
ogra_just bzr merge ... oh, wait ... :P16:45
tedgI do find the "you've got the whole repo" thing confusing. Not sure why they did that.16:47
sergiusensmvo, is there a way to know before hand what apt.Cache.fetch_archives will fetch?16:50
sergiusenstedg, git push to the correct remote16:50
sergiusenstedg, git remote add sergiusens git@github.com:sergiusens/snapcraft.git16:51
sergiusenstedg, git remote add ted git@github.com:tedgould/snapcraft.git16:51
tedgsergiusens: I don't want to push, I want to update my branch, I need to pull?16:52
sergiusenstedg, git push ted16:52
sergiusenstedg, with what is in the upstream repo?16:52
tedgsergiusens: yes16:52
tedgSpecifically the aws-iot branch16:52
sergiusenstedg, git fetch origin; git merge [origin/branch] (or something like that)16:55
sergiusenstedg, I knew I gave you 'write' too early ;-)16:56
tedgThat's what I can't figure out :-) The syntax for branches on remotes.16:56
tedgHeh, yes!16:56
sergiusenstedg, all your branches are in ubuntu-core instead of 'ted'16:57
sergiusenstedg, https://github.com/ubuntu-core/snapcraft/branches16:57
snappy_Chipaca: do you have mir working w/ spice?16:58
mvosergiusens: 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 tomorrow16:59
tedgsergiusens: No, some are.17:01
Chipacasnappy_: me, personally? i haven't checked in ages17:01
tedgsnappy_: 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
Chipacasnappy_: 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' error17:19
Chipacasnappy_: do you get a black screen and a pointer?17:19
snappy_Chipaca: no.  nothing shows after i install mir17:20
Chipacasnappy_: 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. thx17:22
Chipacasnappy_: all virt-manager does, supposedly, is set options on kvm. But I gave up trying to use kvm directly for this.17:25
tedgYeah, no tutorial I know of, but virt-manager usage.17:30
tedgQXL as well.17:31
tedgOkay, I got the branch, now I can't push :-(17:35
tedgGit makes me sad17:35
ogra_until you understand it ... then bzr makes you sad it seems17:35
ogra_(at least thats what i see from others :) )17:36
tedgOthers make me sad17:36
sergiusensmvo, sure, go ahead; I was looking into using a common download location for each part, but I need to keep track of what go downloaded17:45
sergiusensif context helps :-)17:45
snappy_Chipaca: I dont see the black screen and pointer on virt-manager with spice server.  Any suggestions?17:48
Chipacasnappy_: check the mir service log17: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
Chipacasnappy_: there ya go then18:04
snappy_Chipaca: it works in older version of snappy.  Do I need to add lib to snap?18:05
Chipacatedg: 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
tedgChipaca: Not libc, libstdc++18:30
tedgsnappy_: You probably want to build with either vivid or remove libstdc++ from the blocked list.18:31
tedgWe need to revise that in snapcraft18:31
tedgIn 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
Chipacasnappy_: what're you building in vivid?18:46
snappy_Chipaca: libstdc++18:52
Chipacasnappy_: why would you do that?18:52
ogra_to ship the binary in the snap18:53
ogra_though i guess you could just use the deb one in LD_LIBRARY_PATH18:54
Chipacabut then they'd have to ship libc also18:56
Chipacaand libnss18:56
Chipacathe whole thing18:56
ogra_we'll need that anyway :)18:57
ogra_as snapcraft setup18:57
snappy_Chipaca:  do u know an easier way?19:21
snappy_Chipaca: to get mir?19:22
Chipacasnappy_: you've got the mir snap, right?19:23
Chipacasnappy_: and it's not working because the libc++ abi in your snappy system is different from the abi of the package19:24
Chipacasnappy_: that's a problem you _shouldn't_ have, but you do; apologies19:24
davmor2Chipaca: 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 about19:25
Chipacasnappy_: 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
Chipacasnappy_: or if you're in 15.04, maybe rolling works?19:25
Chipacai know tedg has been working with mir and hasn't mentioned this problem19:25
snappy_Chipaca: hmm.... ill try and see if i can get a different result thx19:31
snappy_Chipaca: I was able to get a different version of mir to work!19:40
Chipacasnappy_: there are different versions?19:40
Chipacapackaged i mean?19:40
snappy_Chipaca: no... i compiled one19:40
snappy_Chipaca: how do I fix socket configuration for clocks example?19:41
snappy_Chipaca: thx for help19:42
tedgVivd should be find as long as you're using the 15.04 snappy.19:55
kyrofaCan ubuntu-device-flash be used to preload the image with snaps?21:23
kyrofa(or is there another way to do that?)21:24
tedgIn theory that's what the gadget snap should do.21:25
tedgIt should define which are the preloaded ones.21:25
kyrofaAh, cool okay21:26
kyrofatedg, does that actually include the specified snaps, or install them after deployment?21:26
tedgkyrofa: 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!