[06:27] <dholbach> good morning
[06:30] <didrocks> hey dholbach, how was your week-end?
[06:30] <dholbach> salut didrocks
[06:30] <dholbach> great - how was yours?
[06:32] <didrocks> at jdll on the ubuntu both, presenting snappy, giving a small workshop and such
[06:32] <didrocks> + fixing some snapcraft copy plugin over the week-end
[06:32] <dholbach> wow
[06:33] <dholbach> I hope you're going to be able to free up some time this week to take it easy then :)
[06:33] <didrocks> well, can't swap: on holidays on Wednesday and thing to finish up first
[06:37] <dholbach> ah yes, you're going to be on holidays :)
[06:37] <dholbach> nice
[07:18] <zyga> good morning
[07:28] <JamieBennett> Morning all
[07:30] <mvo> hey JamieBennett, good morning!
[07:31] <dholbach> hey JamieBennett
[07:31] <zyga> JamieBennett: hey :)
[07:43] <didrocks> good morning JamieBennett
[07:43] <ara> Hello! is there a place (i.e. URL) where I can get a list of the env variables in snappy for developers?
[07:43] <ara> (like SNAP_DATA)
[07:44] <fgimenez> morning JamieBennett :)
[07:44] <didrocks> ara: there are some, but it's not always up to date. The easiest for now is to run hello-world.env
[07:45] <ara> didrocks, that "some", where are those? :)
[07:46] <didrocks> ara: in the snapcraft guys, they are introduced one after another if you read the whole content: https://developer.ubuntu.com/en/snappy/build-apps/
[07:47] <didrocks> ara: but not a definitive list, hence my "you should for now point to this command"
[07:48] <ara> didrocks, thanks
[07:48] <didrocks> yw
[07:59] <zyga> ara: one sec
[08:00] <zyga> ara: https://github.com/ubuntu-core/snappy/blob/master/snap/snapenv/snapenv.go
[08:00] <zyga> ara: look at around lines 62, 76
[08:00] <zyga> ara: it is not final
[08:01] <ara> zyga, OK, thanks
[08:01] <zyga> ara: we're still changing that area as other parts land
[11:20] <kyrofa> Good morning
[11:35] <didrocks> hey kyrofa!
[11:36] <kyrofa> Hey didrocks, good day so far?
[11:37] <didrocks> kyrofa: yeah! rushing things before my holidays actually :)
[11:39] <davidcalle> didrocks: hey, I remember you were trying to snap vlc, right?
[11:41] <didrocks> davidcalle: not vlc, but the ascii streaming of it, yeah
[11:42] <davidcalle> didrocks: ok, I thought at some point you were also trying vlc and building it is a bit painful, nevermind then, I'll dig further :)
[11:43] <didrocks> good luck! :)
[11:43] <didrocks> davidcalle: I was reusing the deb from the distro FTR
[11:43] <davidcalle> didrocks: that's cheating :p
[11:45] <didrocks> davidcalle: well, vlc takes 6h to build on the pi2, I didn't want the "create your first snap" to be 6h25 minutes :p
[11:48] <davidcalle> :)
[11:49] <asac> classic for arm64 not there yet?
[11:50] <ogra_> asac, nope, still not :(
[11:55] <asac> ogra_: can i convince udf to use 32-bit rootfs?
[11:56] <asac> and dragonkernel
[11:57] <davidcalle> kyrofa: https://github.com/ubuntu-core/snapcraft/blob/master/docs/intro.md refers to "snappy try", but "snappy try" doesn't seem to exist anymore, what can we use instead?
[12:00] <kyrofa> davidcalle, I'm not sure it ever did (if so it was before my time). I think it's still something we're wanting to make
[12:02] <davidcalle> kyrofa: ok, thanks
[12:05] <qengho> I got a Raspberry Pi 3. I assume it's pretty close to the 2.
[12:06] <qengho> I used these instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
[12:06] <qengho> And it never progresses past the power-on rainbow square.
[12:06] <qengho> Are those instructions verified?
[12:08] <kyrofa> qengho, ogra_ has the rpi3 working with the rpi2 gadget, but I'm not sure it's been released just yet
[12:10] <adaw> Suppose I have a web app on my own cloud server. I want to use snappy to build a gateway such that  only traffic from this gateway can communicate  with my server. Can such a security feature be achieved with snappy?
[12:10] <adaw> the server web app somehow recognizes some hardware mac address from the snappy iot gateway. can this be done?
[12:11] <qengho> adaw: Where is the server, physically related to the device?
[12:11] <zyga> adaw: you could write a snap that controls networking on the device
[12:11] <qengho> Same room, or across the country?
[12:11] <adaw> qengho: i intend to use this server from digitalocean, a cloud provider
[12:11] <zyga> adaw: to implement a firewall that restricts it as you described
[12:12] <zyga> adaw: you'd use the firewall-control interface
[12:12] <adaw> zyga: pardon my ignorance. what is a snap?
[12:12] <zyga> adaw: I suggest you read about snappy first
[12:12] <zyga> adaw: snap is the smallest package in a snappy ecosystem
[12:12] <adaw> the firewall is on the server or snappy?
[12:12] <zyga> adaw: on the device running snappy
[12:12] <qengho> adaw: You know that the link address, MAC in this case, is only used to communicate with things on the same link? So, it's used from your device to the everything connected on that Ethernet link, but after that, it's not part of communicating?
[12:13] <adaw> qengho: if that's the case, is there any way to do hardware authentication?
[12:13] <zyga> (that is another issue)
[12:13] <zyga> adaw: TPM?
[12:14] <zyga> adaw: depends on what you really want to achieve in the end
[12:14] <qengho> adaw: No. There's no hardware that's shared. You're going to have to share a secret in software somehow.
[12:14] <adaw> so, to do hardware authentication, there has to be some sort of security chip. Nothing to do with snappy, right?
[12:15] <qengho> adaw: We haven't begun talking about Snappy yet. This is just the reality of networking.
[12:15] <zyga> adaw: it depends on what you want, perhaps an SSL cert is enough
[12:16] <adaw> TPM is a chip for hardware authentication.  correct?
[12:16] <zyga> for your snap to check that we're talking to a given server
[12:16] <zyga> but snappy will still talk to other places
[12:16] <adaw> suppose i want my server web app to be able to talk to only 1 single gateway in the world. Can this be achieved without using TPM?
[12:16] <qengho> adaw: Here's my opinionated idea: You should fabricate a secret key there, and install OpenVPN on your server, and on your device.
[12:17] <adaw> qengho: so, in this way, i can achieve my objective using software means only?
[12:17] <qengho> The local, snappy end, of your VPN is both the OpenVPN client and whatever app you wish to run on it.
[12:18] <qengho> Yes, software only.
[12:18] <adaw> qengho: u're a genius! by the way, why don't other folks adopt your solution? why use a more expensive and cumebrsome solution like TPM?
[12:19] <qengho> People do. They might not if they don't control servers. TPM is rare.
[12:20] <adaw> Let me understand u correctly. I install OpenVPN server on the cloud server.  Then, install OpenVPN client on the snappy gateway. Finally, open a secure VPN link between them. Correct?
[12:20] <zyga> TMP is really for different things than this IMHO
[12:20] <zyga> openvpn and tpm have almost nothing in common
[12:20] <ogra_> quengho, kyrofa, there is an image with the pi3 gadget though
[12:20] <zyga> you can use TPM for many interesting and useful things that openvpn cannot do
[12:21] <qengho> ogra_: Yay. I was hoping for a 16.04~ thing anyway.
[12:22] <qengho> adaw: You got it. You have to make the OpenVPN client as part of making your snap. Assemble all the pieces together and package it.
[12:22] <qengho> adaw: snapcraft parts. One is your app. Another is the VPN code.
[12:22] <adaw> qengho: can I just use normal Ubuntu instead of snappy to do this openVPN client stuff?
[12:23] <ogra_> qengho, http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
[12:23] <qengho> adaw: I have to warn you, it might be hard. Making a snap listen for network connections isn't usually allowed.
[12:23] <zyga> adaw, qengho: I'd suggest waiting
[12:23] <qengho> adaw: No. Snappy is a whole new world.
[12:23] <zyga> I'm sure that openvpn uses network-manager and I know some people are looking at that already
[12:24] <adaw> qengho: since it is just a VPN client, wouldn't using normal UBuntu and then running python scripts be easier?
[12:24] <zyga> qengho: to listen for network connection all you need is the network-bind interface
[12:24] <qengho> Ah$
[12:24] <zyga> adaw: ubuntu snappy and ubuntu classic are two different worlds; if snappy virtues appeal to you or your use case, use snappy
[12:25] <adaw> besides raspberry pi, what are the hardware boards that can run snappy today?
[12:26] <ogra_> dragonboard, beaglebone, minnowboard ...
[12:27] <adaw> am i right to say the most value-for-money board is Rpi today?
[12:27] <zyga> adaw: for what money?
[12:27] <zyga> adaw: for the price?
[12:27] <ogra_> depends on the usecase reallt
[12:27] <ogra_> *really
[12:27] <adaw> any commercial boards instead of the hobbyist boards?
[12:27] <zyga> adaw: such as?
[12:27] <adaw> something from Intel?
[12:28] <zyga> adaw: you can use certified kernels on any x86/amd64 devices
[12:28] <zyga> adaw: dell announced support for snappy on some devices, you might want to check that
[12:28] <zyga> adaw: https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
[12:29] <ogra_> adaw, there is the dell gateway that comes preinstalled with snappy (still 15.04 though)
[12:29] <adaw> What are situations to use Snappy Ubuntu Core instead of Ubuntu Classic? i'm rather confused here
[12:29] <zyga> adaw: snappy has transactional updates
[12:29] <zyga> adaw: snappy updates automatically
[12:29] <zyga> adaw: snappy is a greate way to build an unattended product
[12:30] <zyga> adaw: classic is a great workstation
[12:30] <zyga> adaw: and a great server
[12:30] <adaw> for ubuntu, I just do "apt-get update and upgrade". u mean for snappy, it just updates automatically without needing to run commands?
[12:30] <zyga> adaw: snappy is something you'd use for mass-market devices due to reliability and resiliance
[12:30] <zyga> adaw: and then you get a debconf prompt
[12:31] <zyga> adaw: and all your devices in the field got the same debconf prompt, half of your users input wrong value, the other half had no UI and update was fronzen until the next power-cycle where the device didn't boot
[12:31] <zyga> adaw: snappy makes that  better
[12:31] <zyga> anyway, good luck
[12:32]  * zyga -> hacking
[12:32] <olli> end
[12:32] <ogra_> adaw, debs always have full root access to your system ... (a postinst script from some PPA can easily replace your kernel with some malicious binary) ... snaps cant do that
[12:33] <adaw> if snappy updates automatically, wouldn't that be dangerous? Someone can hake and  automatically several snappy boards at the same time.
[12:33] <ogra_> if you only stick to the ubuntu archive thats indeed moot, but as soon as you need some newer version of some SW that some guy offers in a PPA you already giave him full root access
[12:35] <adaw> u folks are convincing. snappy sounds better. why doesn't UBuntu just migrate to snappy?
[12:36] <ogra_> because snappy is still very young and not all bits are solved yet ...
[12:36] <ogra_> i.e. you can easily package an app ... but it is hard to package something that integrates with ... say a desktop that you ship as snap
[12:36] <adaw> andywojo: are there commercial applications using snappy today? is it mature enough?
[12:37] <adaw> ogra_: so, snappy are for embedded devices, right?
[12:37] <ogra_> not generally .... 16.04 desktop will have snappy support by default
[12:37] <ogra_> and you should be able to run desktop apps that are packaged as snaps
[12:37] <adaw> ogra_: wow. so, ubuntu is indeed going to migrate to snappy. in 16.04
[12:38] <ogra_> a snappy img today will rather be focused on embedded though
[12:38] <ogra_> and not ship a desktop
[12:38] <adaw> ogra_: so, in 16.04, when i do apt-get, i will be getting snaps?
[12:38] <ogra_> not migrate .... but support
[12:38] <ogra_> when you apt-get you update your system
[12:39] <ogra_> when you use snappy your snappy app will run in a container and interface with the desktop
[12:39] <ogra_> there will still be a few releases til you see a full snappy based desktop
[12:40] <ogra_> today snappy in deskop is an addon ... you will be able to use snappy apps but your desktop is still the good old thing you know
[12:40] <adaw> ogra_: are there other linux distributions that are copying snappy features? Windows?
[12:41]  * ogra_ doesnt know
[12:41] <adaw> for iot, snappy will be ideal for iot gateways, right?
[12:41] <ogra_> yes
[12:41] <ogra_> also for NAS ... or routers/switches ...
[12:42] <adaw> any iot gateways in commercial use today that is using snappy?
[12:42] <ogra_> at some point we should have a kodi snap so you could easily build a kodi appliance image
[12:42] <ogra_> things like that will surely show up soon
[12:42] <adaw> u mean, not at the moment yet?
[12:42] <zyga> adaw: snappy is generally better than ubuntu except not features are supported yet so you can expect the scope of supported things to increse which in turns unlocks more places where snappy is appropriate
[12:42] <ogra_> yes, the dell gateway ... and i think there are more in teh works with various partners
[12:42] <zyga> s/ubuntu/classic/
[12:43] <ogra_> kyrofa worked on an owncloud image for teh rpi that seemingly will be used by WD for their diskstation+rpi project
[12:49] <adaw> Intel NUC works on snappy. https://insights.ubuntu.com/2016/03/02/intel-and-canonical-continue-to-build-large-iot-gateway-ecosystems/
[12:50] <ogra_> yep
[12:50] <ogra_> basically all x86 based devics should work more or less
[12:50] <adaw> even my PC?
[12:51] <ogra_> sure
[12:51] <ogra_> would be a bit more fiddly to install thogh :)
[12:51] <ogra_> (boot from USB stick and dd to internal disk ...)
[12:51] <adaw> So, i can install ubuntu classic and snappy on top on it on my virtual machine on virtualbox?
[12:52] <ogra_> by release day you should just be able to install ubuntu-desktop and automatically have snappy support in there
[12:52] <adaw> Confused by the instructions here. Why install ubuntu classic and not snappy? https://developer.ubuntu.com/en/snappy/start/intel-nuc/?_ga=1.260177357.1317873563.1456655626
[13:00] <davidcalle> adaw: to have a system running somewhere (from a live USB in this case), from which you will install snappy on the nuc.
[13:01] <adaw> davidcalle: i see. thanks.
[13:01] <adaw> can snappy be installed onto a virtual machine on virtualbox?
[13:02] <davidcalle> adaw: see https://developer.ubuntu.com/en/snappy/start/#snappy-local
[13:03] <ogra_> kvm is easier though
[13:03] <ogra_> (no need to convert anything)
[13:04] <davidcalle> adaw: sorry, I meant https://developer.ubuntu.com/en/snappy/start/#ova
[13:05] <adaw> thanks all. I have much to learn. Don't even know what's the difference between virtual machine and container at the moment.
[13:25] <mvip> hey guys, have anyone spent any cycles on remote logging for Snappy? Are there any guidelines there?
[13:26] <mvip> For us it's important to capture these logs, but rsyslogd isn't ideal to use natively (as it's somewhat messy to setup with TLS).
[13:27] <mvip> Ideally I want to ship logs over HTTPS (to avoid additional port requirements).
[13:27] <mvip> I'm thinking something like Fluent (https://github.com/fluent/fluentd) would do well, but I wanted to check with you guys before I start diving into this too far.
[14:20] <qengho> How do you folks build snapcraft packages on armhf?
[14:20] <ogra_> snappy shell classic ..
[14:20] <qengho> Ah.
[14:22] <zyga> qengho: there's some limited support for cross compilation in snapcraft for certain plugins
[14:23] <zyga> qengho: but ogra gave the correct and generic answer
[14:23] <ogra_> only for kernel AFAIK
[14:23] <zyga> ogra_: I read that someone got go plugin to cross compile
[14:23] <ogra_> ah, never used that
[14:25] <qengho> Yeah, it's close to working. I started a C/C++ support patch for autotools and make, but found I wasn't doing it the right way and aborted.
[14:45] <kyrofa> ogra_, the launchpad builders work now too
[14:45] <kyrofa> ogra_, and are way WAY faster
[14:45] <kyrofa> qengho, ^^
[14:46] <ogra_> kyrofa, not for armhf/arm64
[14:46] <qengho> You tease.
[14:49] <kyrofa> ogra_, qengho you should be able to enable those if you edit the snap. Just check the boxes
[14:49] <kyrofa> ogra_, qengho also exposed via the python API. Can't wait to get travis builds firing off
[14:50] <qengho> kyrofa: Edit how? I have a bzr branch. Snapcraft config mentions no architecture. "Request builds" in snap packaging on LP asks "amd64 or i386?"
[14:50] <kyrofa> qengho, click on the snap and say edit details
[14:51] <kyrofa> qengho, see more arch options there?
[14:51] <qengho> I sure do. The defaults perplex me. Thanks!
[14:52] <kyrofa> qengho, note that the builders only have internet access in the pull step
[14:52] <kyrofa> qengho, also note that Snapcraft 1.x is used if targeting vivid, Snapcraft 2.x is used if targeting xenial
[14:53] <qengho> Cool. I pushed it up the hill and let go. I'll see what happens.
[15:10] <kyrofa> didrocks, by the way, any progress on that unversioned directory in snappy?
[15:16] <didrocks> kyrofa: I was hoping to start getting to it this week. More work was dumped on me. I'll have a try but if I can't (and if that's urgent), I'm happy to warn if I can't get to it before my holidays
[15:17] <kyrofa> didrocks, yeah let me know if you don't mind :)
[15:17] <didrocks> sure!
[15:49] <qengho> kyrofa: The LP snap integration is still a mystery to me. My packages compiled well. Yay! But, where did they go? How do I use them?
[15:50] <didrocks> qengho: you have a link to download them
[15:51] <didrocks> if you click on each ones
[16:01] <qengho> Okay, then. I downloaded, then uploaded to the same place my earlier "snapcraft upload" emitted as the URL to manage my package, once for i386, arm64, and armhf. That felt weird.
[16:03] <qengho> Seems to have worked, though.
[16:03] <qengho> Thanks, didrocks, all.
[16:18] <qengho> I welcome feedback. tor-middle-relay.chadmiller  Now for ARM too!
[16:35] <qengho> Service crash at startup. "seccomp_load failed with -22" "seccomp_load_filters failed with -22. errmsg: Invalid argument"
[16:40] <asac> qengho: https://bugs.launchpad.net/snappy/+bug/1561920
[16:40] <asac> ogra_: any idea when we will get that fix?
[17:12] <ogra_> asac, i would assume as soon as the kernel moves out of proposed (where it sits since the 22nd)
[17:12] <ogra_> you have to ask the kernel team what keeps it stuck there
[17:18] <qengho> Between #1564369 and #1561920, my first day with new RPi3 is a sad one.
[17:20] <ogra_> qengho, well, the first one has a workaround at lest
[17:20] <ogra_> *least
[17:20] <qengho> ogra_: does it?  Bind mount, or the correction?
[17:21] <ogra_> not much we can do about the second one except waiting for the kernel to go to the archive (though i'm not sure that one actually has the fix already, ppisati would know)
[17:21] <ogra_> bind mounting /dev/pts
[17:22] <ogra_> you could bribe mvo to do an extra nightshift to fix all the mounting issues we have with the classic shell now though :)
[17:22] <ogra_> (there is a bunch since a week or so)
[17:51] <kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/421 easy review
[18:40] <elopio> kyrofa: sorry, I still haven't figured out notifications on irssi.
[18:40] <elopio> looking at your pr
[18:40] <kyrofa> elopio, hahaha
[18:40] <kyrofa> elopio, no problem, thanks for taking a look :)
[18:52]  * elopio <- lunch
[19:26] <asac> ogra_: guess i cant switch channel to downgrade to 4.3 kernel?
[19:26]  * asac prepares a reflash
[19:32]  * asac goes back to stable channel to get work done (TM)
[19:33] <asac> how does/will it work in 16 to get top level cli entries? like docker?
[19:37] <sergiusens> asac, name the app like the snap
[19:38] <sergiusens> asac, that is already working
[19:42] <asac> ic thanks sergiusens
[19:42] <sergiusens> elopio, back?
[20:16] <ogra_> asac, you can snappy install the older kernel snap
[20:17] <ogra_> (with --allow-unauhenticated)
[20:17] <asac> oh...ok... didnt know that
[20:17] <asac> next time :)
[20:17] <asac> pretty cool
[20:18] <asac> now just switching channels then easy
[20:18] <asac> ogra_: the pi3 ... is that working well?
[20:20] <ogra_> so so... we have an issue with the serial console when using the pi3 uboot on a pi2 still (we want a shared image)
[20:20] <ogra_> and the wlan firmware is missing
[20:21] <ogra_> beyond that the pi3 is fine
[20:21] <asac> graphics?
[20:21] <ogra_> never tried
[20:21] <ogra_> (neither on the pi2)
[20:26] <qengho> I have a Pi3! I skipped the Pi2. I will help test or debug.
[20:39] <dduffey> if I have a custom kernel snap, and downloaded a os.snap, what do I use for the gadget snap (standard amd64)?  or the full command line for ubuntu-device-flash
[20:43] <kyrofa> dduffey, probably canonical-pc.canonical
[20:45] <kyrofa> dduffey, https://github.com/zyga/devtools/blob/master/ubuntu-image may interest you
[21:03] <mhall119> hey guys, I'm trying to play around with snapcraft, but "snapcraft add-part" says: No module named 'snapcraft.commands.add_part'
[21:03] <mhall119> am I missing something?
[21:03] <mhall119> snapcraft --help shows it
[21:04] <dduffey> kyrofa, awesome ... I'm getting the following error (which is the same error when I try to run ubuntu-device-flash by hand)
[21:04] <dduffey> expected 3 partitons but found 0
[21:05] <qengho> mhall119! 'Sup. I want to say that's going away, but I could be wrong. In any case, sounds like a bug to report.
[21:05] <dduffey> same if I use the ubuntu-image script and just select "pc", or run the following:
[21:05] <dduffey> ./ubuntu-device-flash core rolling --channel edge --gadget canonical-pc.canonical --os xenial-preinstalled-core-amd64.os.snap --kernel kernel.snap/45-kernel_4.5_amd64.snap -o custom.img
[21:23] <qengho> mhall119: I hate to say it, but I found the most instructive thing was to look at the snapcraft source code in  /usr/lib/python3/dist-packages/snapcraft /
[21:26] <mhall119> qengho: heh, that's not ideal :)
[21:26]  * zyga agrees with qengho
[21:26] <zyga> mhall119: we should have solid manual pages
[21:26] <zyga> mhall119: developer docs on the website are always out-of-sync
[21:27] <zyga> mhall119: snapcraft is great when it works, utterely confusing when your file is wrong and you have no help to follow
[21:27] <qengho> mhall119: You're using snapcraft on 16.04 yes?
[21:27] <qengho> Silly question, I know.
[21:28]  * zyga is supper happy about what's landing in snappy
[21:28] <mhall119> qengho: yes
[21:28] <zyga> jdstrand: all four backends are in place, I need to tweak apparmor slightly but I'm not only working on integrating with install/remove/upgrade
[21:28] <mhall119> ok, next question, how do I specify a git branch name in a cmake plugin part?
[21:29] <mhall119> oh, source-branch, dug
[21:29] <mhall119> ignore me
[21:30] <qengho> I just published my first package on 4 architectures, so I'm already pretty happy with it.
[21:33] <qengho> zyga: Give a changelog precis?
[21:35] <zyga> qengho: ?
[21:37] <qengho> zyga: You're excited about changes in snappy. What changes?
[21:37] <zyga> qengho: interfaces are an inch/cm away from working
[21:37] <zyga> qengho: I'll blog about this heavily when it goes live
[21:37] <zyga> qengho: (on g+ and planet ubuntu)
[21:38] <mhall119> is there a way to not use `--depth 1` in the git plugin?
[21:39] <zyga> mhall119: read the source :-(
[21:40] <mhall119> yeah, I edited the source, I feel bad
[21:41] <zyga> mhall119, sergiusens: is doing an amazing job coding but I feel that a tech writer could make snapcraft x10 more discoverable to everyone in a month
[21:42] <mhall119> zyga: I agree, and I believe davidcalle is working on that
[21:42] <zyga> oh, that's great to hear
[21:42] <mhall119> when I'm not stealing him to work on the devportal deployments
[21:42] <zyga> I know some people have been looking for technical training on snapcraft
[21:42] <qengho> mhall119: When you make a plugin that extends git, you know you are pro.
[21:42] <mhall119> or dholbach is stealing him to work on devportal docs importers
[21:42] <mhall119> or dpm isn't stealing him to run scopes showdowns.....
[21:43] <sergiusens> zyga, mhall119 not sure if davidcalle is just making our existing docs land into d.u.c
[21:43] <mhall119> qengho: for not I just modified the code in /usr/lib/python3/dist-packages/snapcraft, so I just feel like a vandal :)
[21:43] <sergiusens> they ones on d.u.c are outdated
[21:43] <zyga> sergiusens: use readthedocs
[21:43] <sergiusens> mhall119, why do you need to not use --depth 1?
[21:43] <zyga> sergiusens: at least you'll have control
[21:43] <mhall119> sergiusens: it causes the git clone to fail
[21:43] <zyga> sergiusens: and you can have them built live
[21:44] <sergiusens> zyga, I prefer md and just github, it is fully navigational as is
[21:44] <zyga> sergiusens: well, whatever works
[21:44] <sergiusens> mhall119, how so? I'll leave that to kyrofa but you must log a bug ;-)
[21:45] <sergiusens> zyga, https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md
[21:45] <mhall119> sergiusens: kyrofa: git clone --depth 1 --recursive --branch Subsurface-branch git://git.subsurface-divelog.org/marble /home/mhall/projects/Ubuntu/snaps/snappy-playpen/subsurface/parts/marble/src
[21:45] <mhall119> try running that
[21:45] <zyga> sergiusens: perhaps you could use github pages
[21:45] <zyga> sergiusens: that's give you snapcraft.github.com, right?
[21:46] <zyga> sergiusens: (sorry, that'd be ubuntu-core.github.io)
[21:46] <qengho> You can cname too, so could be snapcraft.ubuntu.com
[21:46] <zyga> sergiusens: e.g. http://zyga.github.io/git-lp/
[22:11] <sergiusens> mhall119, I see it; I wonder why it doesn't work though