[06:15] <vmayoral> Morning!
[06:15] <vmayoral> Some might be interested on https://www.indiegogo.com/projects/erle-spider-the-ubuntu-drone-with-legs.
[06:40] <dholbach> good morning
[07:05] <fgimenez> good morning
[07:38] <dholbach> https://code.launchpad.net/~dholbach/snapcraft/1491303/+merge/270363
[07:56] <ogra_> mvo_, hmm, vivid images stopped building, seems the ubuntu-snappy source doesnt build the ubuntu-snappy binary anymore
[07:57] <ogra_> resulting in:
[07:57] <ogra_> The following packages have unmet dependencies:
[07:57] <ogra_>  ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.0.1-1+467~ubuntu15.04.1) but it is not going to be installed
[07:57] <ogra_> E: Unable to correct problems, you have held broken packages.
[07:57] <ogra_> P: Begin unmounting filesystems...
[07:59] <ogra_> oh, failed on amd64 ...
[08:00] <ogra_>    dh_install -O--buildsystem=golang -O--fail-missing
[08:00] <ogra_> cp: cannot stat 'debian/tmp//usr/bin/xgettext-go': No such file or directory
[08:00] <ogra_> dh_install: cp -a debian/tmp//usr/bin/xgettext-go debian/golang-snappy-dev///usr/bin/ returned exit code 1
[08:00] <ogra_> make: *** [binary] Error 2
[08:22] <ogra_> Chipaca, any idea about the above ? seems it comes from backporting https://code.launchpad.net/~chipaca/snappy/delayed-service-start into 15.04 (why is there xettext in that merge at all ?)
[08:22] <ogra_> *xgettext
[08:33] <JamesTait> Good morning all; happy Tuesday, and happy Physical Therapy Day! 😃
[09:32] <Chipaca> ogra_: not entirely sure, no; mvo patched up the xgettext thing for it to work
[09:46] <livcd> Hi what exactly is ubuntu Core ? I have obviously read the description page but still fail to understand the purpose
[09:46] <livcd> is it meant to be a "container OS" for a docker like environment
[09:46] <livcd> or a base system running docker images ? :3
[09:46] <livcd> or both
[09:47] <ogra_> it is meant to be a core of any kind of OS
[09:48] <ogra_> (even a desktop install is planned)
[09:49] <livcd> ok so what do you think about a base host for docker and docker containers ? :D
[09:50] <Chipaca> whither mvo?
[09:50] <Chipaca> livcd: grab snappy ubuntu core, then "sudo snappy install docker"
[10:12] <ogra_> pitti, is there an easy way to find that sysvinit scripts are in use via systemctl ?
[10:12] <ogra_> s/that/which/
[10:12] <pitti> ogra_: you mean that a unit was generated from a sysvinit script?
[10:12] <ogra_> yep
[10:13] <ogra_> (we just seeded ppp in the image and that doesnt ship any systemd stuff)
[10:13] <pitti> $ systemctl show -p SourcePath networking.service
[10:13] <pitti> SourcePath=/etc/init.d/networking
[10:13] <pitti> something like that?
[10:13] <ogra_> ah, perfect
[10:14] <ogra_> event works with a wildcard :D
[10:14] <pitti> ogra_: I assume this is for a script -- as a human, looking at systemctl status foo is a bit more obvious, and simpler to remember
[10:15] <pitti> ● networking.service - LSB: Raise network interfaces.
[10:15] <pitti>    Loaded: loaded (/etc/init.d/networking)
[10:15] <ogra_> pitti, well, i was not sure if snappy ships the sysvinit generator at all
[10:15] <pitti> ogra_: oh, ambitious :)
[10:16] <pitti> (but indeed that does sound achievable)
[10:16] <ogra_> and pppd ships a /etc/init.d/pppd-dns script ... we need to be sure this still works (ppp doesnt seem to have any kind of native systemd integration)
[10:20] <ogra_> ricmm, seems watchdog is completely configured via /etc/default/watchdog that should be easy
[10:20] <ogra_> and its is already shipping proper systemd service files too ...
[10:21] <ricmm> ogra_: perfecto
[10:21]  * ogra_ guesses there is nothing to do for watchdog except adding writability for the confi
[10:21] <ogra_> g
[10:49] <Chipaca> ogra_: arch seems to have pppd systemd scripts :)
[10:49] <Chipaca> ogra_: otoh, systemd was working on pppd support
[10:49] <Chipaca> as part of networkd though
[10:49] <ogra_> yeah, but thats for later
[10:50] <ogra_> the sysvinit script it ships is a one liner:
[10:50] <ogra_> [ -x /etc/ppp/ip-down.d/0000usepeerdns ] \
[10:50] <ogra_>         && exec /etc/ppp/ip-down.d/0000usepeerdns
[10:50] <Chipaca> ah. meh :)
[10:50] <ogra_> also pretty debian/ubuntu specific too
[10:51] <ogra_> i think we're fine shipping it as is for now ... just need /etc/ppp/ writable
[10:51] <ogra_> (and if needed have snappy config modify/add/remove files in there)
[11:12] <sergiusens> good morning from the americas!
[11:13] <ogra_> yo yo!
[12:19]  * ogra_ sees that ubuntu-snappy has finally built and triggers a new 15.04 image
[12:42] <livcd> is there a generic image i can get ?
[12:43] <livcd> i plan to use it with vbox
[12:47]  * Chipaca shakes his fist at classes that use private globals for configuration you should change for testing use of the class
[12:47] <Chipaca> livcd: yes, you probably want the amd64 15.04 stable image
[12:47] <guest42315> livcd,  wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz ?
[12:47] <Chipaca> livcd: https://developer.ubuntu.com/en/snappy/start/
[12:48] <livcd> Chipaca: is that the one ?
[12:48] <livcd> is not that the one for KVM ?
[12:49] <Chipaca> livcd: the url guest42315 pointed at works with kvm, yes
[12:50] <Chipaca> livcd: i assume vbox is virtualbox, in which case I understand it also can work with that image, but I haven't tested this myself
[12:50] <livcd> oh i think i have to convert that one first
[12:50] <livcd> i have seen on the page a "larger" multipurpose image for vmware,vbox,etc
[12:51] <Chipaca> livcd: get the OVA file
[12:52] <Chipaca> livcd: from the page i pointed you at
[12:52] <Chipaca> livcd: probably the easiest way
[12:53] <livcd> the ova file
[12:53] <livcd> yeah that's the one
[12:53] <livcd> ok
[12:53] <livcd> though i wanted the smallest image possible :D
[13:22] <yashi_> hello
[13:26] <rickspencer3> jdstrand, I noticed that I am getting this error when I try to use certain pins on my bbb
[13:26] <rickspencer3> Sep 08 13:25:36 localhost.localdomain ubuntu-core-launcher[1090]: open /sys/class/gpio/gpio44/direction: permission denied
[13:26] <Chipaca> yashi_: hello
[13:27] <yashi_> just tried to run ubuntu-device-flash under systemd-nspawn container and found out that oem handler runs `udevadmin control --reload` which is not possible under nspawn containers.  installOemHardwareUdevRules seems to assume that environment it's called is runtime env, but not a host with u-d-f
[13:27] <Chipaca> rickspencer3: https://bugs.launchpad.net/snappy/+bug/1488618 ?
[13:27] <rickspencer3> I added this to my apparmor profile to try to hack around it, but it didn't work
[13:27] <rickspencer3>   /sys/class/gpio/gpio44/direction rw,
[13:28] <rickspencer3> Chipaca, well, that is another bug I found perviously
[13:28] <rickspencer3> not sure if this is the same or related
[13:28] <Chipaca> ah
[13:28] <Chipaca> me neither :)
[13:28] <rickspencer3> is there a way for me to tell my bbb to update to the latest daily image?
[13:29] <ogra_> sudo snappy update ubuntu-core
[13:29] <ogra_> shoudl work
[13:30] <rickspencer3> arg, ogra_ maybe I didn't get onto rolling when I made the image :(
[13:30] <ogra_> ah, thats the hacked channel image ?
[13:30] <yashi_> it seems to me that what u-d-f want is to install udev rules but not activation.  does anyone know around this?
[13:30] <rickspencer3> is says I am on version 4
[13:30] <ogra_> yeah, that might not just work
[13:31] <rickspencer3> aaarg
[13:31] <ogra_> you can force it in the bootloader config to switch to the other partition
[13:32] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab
[13:32] <ogra_> snappy_ab=a
[13:32] <Chipaca> yashi_: sorry, what?
[13:32] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo fw_setenv snappy_ab b
[13:32] <ogra_> then reboot
[13:33] <ogra_> ((unless your image is really really old ... in which case you dont have the right bootloader setup and actually need to re-flash)
[13:34] <yashi_> Chipaca: have you run ubuntu-device-flash under systemd nspawn containers?
[13:34] <Chipaca> yashi_: I have not. What for?
[13:34] <yashi_> Chipaca: using a container for lightweight vm, nothing more.
[13:35]  * ogra_ guesses the typical ubuntu user uses lxc instead of nspawn :)
[13:36] <Chipaca> yashi_: and you run u-d-f _inside_ the container, and ... something about udev?
[13:36] <yashi_> ogra_: oh
[13:37]  * Chipaca isn't getting where udev comes into it
[13:37] <ogra_> yeah, sounds weird
[13:37] <ogra_> is that when you are executing it ?
[13:37] <Chipaca> at first i thought you were trying to use the output of u-d-f inside an nspawn (which wouldn't work) :)
[13:37] <yashi_> Chipaca: yeah, in short u-d-f does not work inside the container.  reason: no access to systemd-udevd
[13:37] <ogra_> or do you refer to the u-d-f package shipping rules
[13:37] <ogra_> ah
[13:39] <jdstrand> rickspencer3: let me look at the bug again
[13:39] <yashi_> but i thought u-d-f does not need to / should not access systemd-udevd via udevadm.
[13:39] <jdstrand> sigh
[13:40] <ogra_> well, it creates partitioned images ... i havent seen the source but it might talk to udevd to determine loop devices and whatnot
[13:40] <ogra_> sergiusens, ^^^^ ?
[13:40] <Chipaca> that's probably the oem setup?
[13:40] <jdstrand> it is related but the fix isn't broad enough. unfortunately, I've never done gpio so not sure of all the paths. I am going to suggest going broader to cover this
[13:40] <ogra_> Chipaca, yeah
[13:41] <yashi_> ogra_: hmm.  I'l check about loop device
[13:41] <yashi_> Chipaca: yes, it's activateOemHardwareUdevRules() in oem.go
[13:41] <Chipaca> yup
[13:42] <Chipaca> oh. lunch.
[13:42]  * Chipaca ~> lunch
[13:49] <jdstrand> mvo_: hey, I just filed bug #1493389 on rickspencer3's behalf. it is essentially the same bug as the one you fixed before but for a different path. In the bug, the fix I suggested should prevent this bug in the future for any path in /sys/class/gpio
[13:49] <nothal> Bug #1493389: cannot specify /sys/class/gpio/*/direction with hw-assign <Snappy:New> <Snappy 15.04:New> <Snappy trunk:New> <http://launchpad.net/bugs/1493389>
[13:50] <jdstrand> mvo_: I took the liberty of triaging it to match bug #1488618 (without assigning you)
[13:50] <nothal> Bug #1488618: cannot specify /sys/class/gpio/export with hw-assign  <http://launchpad.net/bugs/1488618>
[13:50] <sergiusens> yashi_, ogra_ what u-d-f are you using, the udev rules are not supposed to be triggered, just layed out
[13:51] <ogra_> sergiusens, well, it seems to actually try to call udevd
[13:51] <sergiusens> yashi_, that is inhibited from u-d-f (activateOemHardwareUdevRules)
[13:58] <mvo_> thanks jdstrand
[14:00] <yashi_> sergiusens: do you mean u-d-f shouldn't call activateOemHardwareUdevRules() ?
[14:02] <sergiusens> yashi_, it shouldn't and I'm sure I added code for that
[14:02] <sergiusens> yashi_, I'm checking now
[14:02] <ogra_> yashi_, are you actually using the latest u-d-f from the snappy-tools PPA =
[14:02] <ogra_> ?
[14:02] <ogra_> just to make sure :)
[14:03] <yashi_> sergiusens: i've checked the u-d-f from the snappy official ppa and bzr
[14:04] <yashi_> ogra_: I noticed errro with the official binary so did `go get` and built u-d-f myself
[14:06] <yashi_> ogra_: i'm not bzr guy so not sure which branch is the tip, but i've built the one in goget-ubuntu-touch revno 61
[14:08] <yashi_> sergiusens: which branch should I checkout to see your change?
[14:08] <Chipaca> yashi_: i suspect the change has gotten lost, as I don't see code in tip to not do the activate
[14:08] <sergiusens> yashi_, I was looking at bzr logs to figure out where the change went
[14:09]  * Chipaca hugs sergiusens 
[14:09] <sergiusens> seems I did something similar, but not to this
[14:09] <ogra_> and on a sidenote https://code.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk is trunk :)
[14:09] <sergiusens> Chipaca, seems it's not there, we need to either split write and install or pass in inhibitHooks
[14:09] <Chipaca> mhmm
[14:09]  * Chipaca runs back to his own code
[14:10] <yashi_> ogra_: thanks!
[14:12] <sergiusens> Chipaca, no, please stay ;-)
[14:18] <rickspencer3> jdstrand, I applied your work around, but I am still getting denied
[14:18] <rickspencer3> maybe I need a different hw-assign?
[14:18] <rickspencer3> Sep  8 14:14:58 localhost kernel: [   69.578787] audit: type=1400 audit(1441721698.017:10): apparmor="DENIED" operation="open" profile="ssh-ready.sideload_ssh-ready_0.1" name="/sys/devices/platform/ocp/4804c000.gpio/gpio/gpio44/direction" pid=1098 comm="ssh-ready" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[14:23] <jdstrand> rickspencer3: yes, you need an additional hardware assign
[14:24] <rickspencer3> jdstrand, so, weird that it always works fine on pin 67 and 68
[14:24] <jdstrand> rickspencer3: do remember that if you do hw-assign again, you'll have to re-add the workaround rule
[14:25] <Chipaca> mvo_: ogra_: hadn't we fixed the thing where we create vmlinuz-$version and initrd-$version?
[14:26] <Chipaca> because wily edge 166 still has it, right now
[14:26] <ogra_> Chipaca, i think sergio did the u-d-f side to ssuport the versioned binaries ... and i think mvo_ recently added code that makes sure everything is removed from /boot
[14:26] <sergiusens> Chipaca, the part missing is that system-image would need to generate the yaml
[14:26] <mvo_> Chipaca: I have a branch for this up for review right now
[14:26] <rickspencer3> jdstrand, ack
[14:26] <ogra_> it might be that we still have unversioned duplicates in the oem snap
[14:27] <Chipaca> mvo_: you have a lot of branches waiting on the integration test runner, it seems
[14:27] <Chipaca> mvo_: is that thing working?
[14:27] <mvo_> Chipaca: I think so, I tested it on some kernel change image iirc
[14:27] <zyga> hey everyone
[14:27] <zyga> tedg: I'd like to sync with your on python support
[14:28] <Chipaca> mvo_: i meant the integration test runner thing
[14:28] <tedg> zyga: Morning, I have a branch, but it needs to get updated with sergiusens' fixes.
[14:28] <zyga> tedg: can I have a look?
[14:29] <zyga> tedg: maybe your approach is easier to land than mine :)
[14:29] <mvo_> Chipaca: it seems its not right now, we probably should ask fgimenez :)
[14:30] <tedg> zyga: No, it is a secret. What ever you do, don't click on this link! https://code.launchpad.net/~ted/snapcraft/python-pip
[14:31] <zyga> tedg: thanks
[14:32] <fgimenez> mvo_, you mean this branch https://code.launchpad.net/~mvo/snappy/snappy-lp1476129-boot-ok/+merge/269224 right? we can keep the rc local failover test commented
[14:33] <Chipaca> fgimenez: there are a number of branches that are waiting for the integration test +1
[14:33] <Chipaca> fgimenez: is that working? because it's been a week for some of them
[14:34] <Chipaca> fgimenez: so if you think it's working, you think wrong :)
[14:34] <yashi_> sergiusens: gotta go, it's late here.  let me know if you need a tester for it,  i have some time tomorrow
[14:35] <fgimenez> Chipaca, it's not enabled yet afaic, probably some of the jenkins instances kept requesting the review, while the jobs weren't triggered
[14:36] <Chipaca> mvo_: top approve 'em all!
[14:36] <Chipaca> go go go
[14:36] <ogra_> shell shell shell
[14:36] <sergiusens> yashi_, sure, just remind me tomorrow
[14:36] <sergiusens> thanks
[14:38] <mvo_> Chipaca: :) yay
[14:38] <elopio> ogra_: how do I generate the init img from this initramfs-tools-ubuntu-core branch?
[14:38] <Chipaca> elopio: first, you take a black rooster on a full moon
[14:38] <mvo_> elopio: the initrd.img  ? find .|cpio -o -H newc|xz -c -9 --check=crc32
[14:39] <mvo_> elopio: after you unpacked it to "." of course
[14:39] <mvo_> elopio: and yes, full moon also helps ;)
[14:39] <elopio> Chipaca: that's easy to get.
[14:39] <ogra_> elopio, make a chroot ... install initramfs-tools and initramfs-tools-ubuntu-core in it ... chroot into it ... sudo update-initramfs -kfoo -c
[14:39] <Chipaca> elopio: your neck of the woods, sure
[14:39] <mvo_> oh, what ogra_ said works too to build it afresh, my suggestion works when modifying a existing one
[14:40] <ogra_> right, you can as well unpack and re-pack
[14:40] <ogra_> and replace the right bits
[15:49] <elopio> fgimenez: do you have ssh access to that instance that failed on the free space test?
[15:50] <fgimenez> elopio, yep, let me add your key
[15:52] <fgimenez> elopio, the jenkins container is running at 10.55.32.36, you should be able to access now, sudo docker exec -ti snappy-jenkins bash to enter the container
[15:53] <elopio> fgimenez: I meant to the snappy instance.
[15:53] <elopio> sorry for not being clear.
[15:53] <fgimenez> elopio, the instance itself where the tests run is deleted, but you can spin it up again with nova
[15:53] <fgimenez> yep, np :)
[15:54] <elopio> fgimenez: I have started a couple of instances and can't reproduce it.
[15:54] <elopio> I think this will help, for sure: https://code.launchpad.net/~elopio/snappy/parted_script/+merge/270421
[15:54] <elopio> but I'm not sure if it will fix your problem. Does it happen on all the runs from jenkins?
[15:55] <fgimenez> elopio, these are the results http://10.55.32.36:8080/job/snappy-daily-1504-canonistack/, fails with each execution
[15:55] <elopio> fgimenez: great, so let me try with this branch from a jenkins instance. Thanks.
[15:56] <fgimenez> elopio, maybe it's because it's running against 15.04?
[15:56] <fgimenez> let me try rolling too
[15:57] <elopio> fgimenez: if ogra has not backported this, then the image doesn't have parted installed. Let me check.
[15:57] <ogra_> elopio, right, not backported yet
[15:58] <ogra_> i was waiting for test feedback first ...
[15:58] <elopio> fgimenez: ^ so the test is rolling only.
[15:59] <fgimenez> elopio, ogra_ ok thanks, now running it
[16:17] <tedg> Uhg, this sucks. bug 1306991
[16:17] <tedg> Finally found the issue, but not sure how to work around it.
[16:19] <tedg> Frustrating, but ironic, to run into the issue that people have working with Ubuntu packages while trying to build Snappy
[16:34] <sergiusens> tedg, maybe just easy_install pip and forget the ubuntu package?
[16:45] <elopio> ogra_ or sergiusens: when do we need the dtbs? only for uboot?
[16:46] <sergiusens> elopio, yes; for arm
[16:49] <ogra_> elopio, what sergiusens said ... depneding on the device you need them earlier or later
[16:50] <ogra_> (BBB only needs them in uboot, RPi already in the first stage loader)
[17:12] <tedg> sergiusens: Yeah, working through that... directories become fun.
[18:43] <mhall119> hi everyone, is there a way yet to use snapcraft on my (x86) laptop to build a package for (armhf) RPi2?
[18:43] <mhall119> using a .deb from the archives
[18:44] <beuno> mhall119, are you subscribed to snappy-app-devel?
[18:45] <mhall119> probably not
[18:45] <beuno> mhall119, if you do, and if you look at the latest thread
[18:46] <beuno> you will get your answer!
[18:46]  * beuno doesn't want to spoil the ending
[19:03] <tedg> beuno: You're such a tease!
[19:45] <tedg> Ha, I think it works.
[20:04] <rickspencer3> jdstrand, does this mean I need to do hw-assign /sys/devices/ ?
[20:04] <rickspencer3> Sep  8 20:03:12 localhost kernel: [19340.684890] audit: type=1400 audit(1441742592.719:445): apparmor="DENIED" operation="open" profile="pan-tilt-camera.sideload_pan-tilt-camera_0.1" name="/sys/devices/" pid=1852 comm="pan-tilt-camera" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[20:15] <jdstrand> rickspencer3: that one is annoying. does the app not work correctly without that access?
[20:15] <rickspencer3> jdstrand, well, it threw that error constantly in a loop
[20:15] <rickspencer3> then, I granted the app access to /sys/devices
[20:16] <rickspencer3> not more error, but the app is not working
[20:16] <rickspencer3> also, I just burned out a servo by plugging it into the wrong pin
[20:16] <jdstrand> right. if it wants /sys/devices/ it is perhaps looking for something
[20:16] <jdstrand> ouchie
[20:16] <rickspencer3> jdstrand, I think it is a pwd port
[20:17] <rickspencer3> as in, I think the port support pwd
[20:18]  * rickspencer3 notes to be more careful with servos
[20:18] <rickspencer3> there's $3 I'll never see again
[20:18] <jdstrand> hehe
[20:18] <rickspencer3> jdstrand, so I am not seeing any denials or errors
[20:19] <rickspencer3> it's just not working
[20:19] <rickspencer3> and I have no idea where to start
[20:19] <rickspencer3> nothing in pwm
[20:19] <jdstrand> hrm
[20:19]  * rickspencer3 goes to google
[20:20] <jdstrand> I'm going to allow access to /sys/devices/ so you won't have to worry about that
[20:20] <rickspencer3> h man, I plugged it into the totally wrong pin
[20:39] <rickspencer3> criminy
[20:40] <rickspencer3> ogra_, anything I need to know before using pwm on my bbb?
[20:40] <rickspencer3> for example, "how to make it work" ;)
[21:24] <sergiusens> tedg, can you peek at https://code.launchpad.net/~sergiusens/snapcraft/filesets/+merge/270455 (work in progress) and get some initial thoughts in? I'd also appreciate if you can look at all the prereqs to this which are under actual review :-)
[21:34] <tedg> sergiusens: Not a fan of "!include"
[21:34] <sergiusens> tedg, well, that is part of the spec ;-)
[21:34] <tedg> sergiusens: Means that you have two "languages" in the same file. YAML and a string lang.
[21:34]  * sergiusens wasn't there
[21:35] <tedg> Eh :-/
[21:35] <sergiusens> tedg, also, ! means something in yaml so you have to explicitly cast the string with quotes :-/
[21:35] <tedg> Nice.
[21:35] <tedg> What does "!" mean in YAML?
[21:36] <sergiusens> tedg, ready for the irony...?
[21:36] <sergiusens> tedg, it is some form of 'include'
[21:36] <sergiusens> :-P
[21:37] <tedg> Oh, an it seems !! allows for typing.
[21:37] <sergiusens> tedg, I'll be writing an email about this
[21:40] <tedg> Wow, YAML is kinda crazy on this.
[21:40]  * tedg had no idea
[21:46] <tedg> sergiusens: Not sure I have useful comments... it matches the spec :-) The spec is a bit odd in this case.
[21:46] <tedg> It feels like we're real close to needing regular expressions.
[21:47] <tedg> Which I don't think is a good place to be.
[21:49] <sergiusens> tedg, ;-) well you can review the prereqs I guess :-P
[21:50] <tedg> We effectively have sets of globs which use to generate sets of files.
[21:51] <tedg> I can't figure out a way to resolve it, but it feel yucky.
[21:53] <tedg> sergiusens: Didn't we have something autobuilding the MRs?
[21:53]  * tedg doesn't see a comment
[21:55] <sergiusens> tedg, after approval iirc
[21:55] <sergiusens> elopio, ^ ?
[21:57] <tedg> sergiusens: Why can't tabs be in a snapcraft.yaml?
[21:57] <tedg> sergiusens: It seems like valid YAML.
[21:57] <sergiusens> tedg, It is not; tabs can't start a line like that
[21:58] <sergiusens> tedg, http://www.yaml.org/faq.html
[21:58] <sergiusens> tedg, it made it to the two question faq :-P
[22:00] <tedg> sergiusens: Hmm, I think that Juju allows them atleast, I'm sure I've used them :-)
[22:01] <tedg> sergiusens: Interestingly they can be used for spacing values but not indentation.
[22:02] <sergiusens> tedg, the golang based parser doesn't care; snappy doesn't care either
[22:03] <sergiusens> tedg, it is just not following the spec, that's all
[22:03] <sergiusens> tedg, I would rather ont patch python3-yaml to not follow the spec :-P
[22:04] <sergiusens> seems to be the wrong direction :-)
[22:04] <tedg> sergiusens: You could patch the YAML spec ;-)
[22:04]  * tedg wants to move things the right direction
[22:05]  * sergiusens would make all code just use tabs
[22:05]  * sergiusens walks away for a bit
[22:05] <tedg> I like tabs for YAML files because you can just set your tabstop to 10 and see what the indentation really is.
[22:06] <tedg> I'm going to have to go soon.