[02:25] <liuxg> has anyone successfully turned off autopilot for a snappy device? I did exactly the same at the instructions at https://github.com/ubuntu-core/snappy/blob/master/docs/autoupdate.md, but no success. I have replaced the "autoupdate" to autopilot.
[08:04] <dholbach> good morning
[08:10] <fgimenez> good morning
[09:44] <SaMnCo-desktop> Hello! If I would like to run a set of Docker Containers and give them access to a BLE USB stick, what would be the recommended method?
[09:59] <Chipaca> liuxg: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core -
[10:00] <Chipaca> liuxg: it seems autoupdate.md is missing the -
[10:01] <liuxg> Chipaca, is it "off", or "false"?
[10:02] <liuxg> Chipaca, it should be "true" or "false". it should not be "on" or "off"
[10:03] <Chipaca> liuxg: why should it not be on/off?
[10:03] <Chipaca> liuxg: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF
[10:04] <Chipaca> liuxg: all of those are valid boolean values in yaml
[10:05] <liuxg> Chipaca, ok.　let me try it.
[10:06] <liuxg> Chipaca, sorry, I am wrong. it works. also true/false work as well. :)
[10:10] <liuxg> Chipaca, by the way, what is the use of "-" in the command?
[10:11] <Chipaca> liuxg: conventionally, specifying - for an argument that expects a file uses stdin as the file
[10:12] <liuxg> Chipaca, I got it. thanks
[10:14] <liuxg> Chipaca, I just found that the method at https://developer.ubuntu.com/en/snappy/guides/autopilot/ also worked
[10:23] <mattyw> hey folks, this new snap format, that's not landed in the repository yet has it (I just built a snap and got this when I tried to upload (failed to install: Signature verification failed: Internal error. E.g. Package corrupt, gpg failed, etc.)
[10:23] <JamesTait> Good morning all; happy Thursday and happy Cake Day! 😃  http://goo.gl/oKyw2t
[10:24] <ogra_`> mattyw, did you use the --allow-unauthenticated option to snappy install ?
[10:24] <mattyw> ogra_`, I didn't that must be a new thing?
[10:24] <ogra_`> oh, ignore me
[10:24] <ogra_`> i thought you meant you sideload a snap ... but you see that on upload
[10:24] <JamesTait> Error "failed to install" when uploading? o_O
[10:24] <ogra_`> oh, right
[10:25] <mattyw> JamesTait, ogasawara well, snappy-remote install
[10:25] <ogra_`> ah !
[10:25] <mattyw> yeah I'm sideloading
[10:25] <JamesTait> Ah!
[10:25]  * JamesTait stands down
[10:25] <ogra_`> then you want the --allow-unauthenticated option indeed
[10:25] <ogra_`> (and no, thats not new at all)
[10:26] <mattyw> ogra_`, I'll give it a go, thanks very much, sure I didn't need it a few months ago but no biggy
[10:27] <ogra_`> i'm sure you always needed it ... might be that snappy-remote did set it automatically or some such though
[10:27]  * ogra_` never uses it
[10:28] <ogra_`> (snappy-remote that is)
[10:28] <Chipaca> mattyw: a few months ago you might have been using an image in developer mode
[10:28] <Chipaca> mattyw: which imples --alllow-unauthenticated-potatos
[10:29] <mattyw> unknown flag `allow-unauthenticated'
[10:29] <mattyw> hmmm
[10:31] <mattyw> ogra_`, unknown flag, what do you use if not snappy-remote?
[10:36] <mattyw> ogra_`, just works now, maybe I did have a bad snap - all working now, sorry to trouble you
[10:49] <SaMnCo-desktop> is there a list of all caps available for users somewhere?
[10:50] <SaMnCo-desktop> eg. in https://insights.ubuntu.com/2015/07/20/prime-time-docker-juju-and-snappy-ubuntu-core/ Dustin uses "docker_client"
[10:50] <SaMnCo-desktop> where does that come from?
[10:56] <Chipaca> SaMnCo-desktop: docker itself
[10:56] <Chipaca> SaMnCo-desktop: frameworks can extend caps
[11:03] <SaMnCo-desktop> Chipaca-  ok so if I want a Docker container to have access to Bluetooth, I should have it use the framework "docker" so it can run
[11:03] <asac> so the kernel-snap thingy annouced by rtg the other day is not abouut a snapcraft plugin, but rather hard coded build logic in the kernel source tree? or did i miss something?
[11:04] <SaMnCo-desktop> and then, what cap / framework should I use to add the BLE stack?
[11:05] <Chipaca> SaMnCo-desktop: i'm not sure there's a bluez framework yet, but there might be
[11:05] <SaMnCo-desktop> Chipaca-  Is there a list of public frameworks available somewhere?
[11:06] <Chipaca> SaMnCo-desktop: i don't think so, but i'm not sure
[11:11] <Chipaca> dholbach: so, two issues with snappy docs in d.u.c
[11:11] <Chipaca> dholbach: one is the autopilot doc, which is stale
[11:11] <Chipaca> dholbach: in fact i don't think it's ever been true for a released snappy
[11:11] <SaMnCo-desktop> Chipaca-  so, is there a list of the caps available somewhere?
[11:11] <dholbach> yes, I know some are stale :-/
[11:12] <Chipaca> dholbach: the other is that I think most of those should have some kind of text that said "these are for 15.04; for rolling, go to <github/yaddayadda/docs/blah.md>
[11:12] <dholbach> yes, that's the plan
[11:12] <dholbach> the automatic importer does all of this, but it's broken and we're working with django cms upstream to get it fixed
[11:12] <Chipaca> ah
[11:12] <dholbach> what can I do for the short term? update the autopilot doc?
[11:13] <Chipaca> that'd help
[11:13] <dholbach> from the 15.04 branch?
[11:13] <Chipaca> oh, good point
[11:14] <Chipaca> let me check that :)
[11:14] <Chipaca> dholbach: is this manual or automatic?
[11:14] <dholbach> it's manual now
[11:14] <dholbach> I hope it's automatic very soon
[11:14] <Chipaca> dholbach: in any case, i think i should first fix them on the 15.04 branch and then point you at it there
[11:14] <dholbach> but I guess it'll take at least 1-2 more weeks
[11:15] <Chipaca> dholbach: i'll poke you later today when the 15.04 branch has the right autopilot docs
[11:15] <Chipaca> dholbach: thanks
[11:16] <dholbach> thanks Chipaca
[11:26] <ogra_`> asac, the kernel snap only uses binary debs
[11:27] <ogra_`> asac, it is actually rootstock hacked up :P
[11:34] <asac> ogra_`: why didnt we do the snapcraft plugin?
[11:34] <asac> was there a need to do the shortcut?
[11:35] <ogra_`> asac, it is a snapcraft plugin but using rootstock as backend
[11:35] <asac> it is?
[11:35] <asac> the git branch rt announced isnt
[11:35] <ogra_`> asac, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/
[11:35] <asac> its just a makefile in a source tree that does everything
[11:35] <asac> http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/Makefile?h=amd64-from-deb-16.04
[11:35] <asac> how is that a plugin?
[11:37] <ogra_`> build_chroot: rootstock
[11:37] <ogra_`> 	sudo sh ./rootstock -a $(ARCH) -f $(LINUX_FLAVOUR) -m $(MIRROR) -s $(SUITE) -b $(BOOTLOADER) $(PPAS) -k
[11:37] <ogra_`> 	sudo chmod +r $(CHROOT)/boot/*
[11:37] <ogra_`> the only git i see in that file is to pull the most recent rootstock script
[11:40] <ogra_`> asac, and there is no other way to do it ... you need a proper initrd which you can only get from packages
[11:41] <ogra_`> http://kernel.ubuntu.com/git/rtg/kernel-snap.git/log/?h=raspi2-from-git
[11:41] <ogra_`> this seems to first build a deb from a kernel tree and then pipes it into rootstock
[11:41] <ogra_`> but effectively it is all deb based
[11:42] <ogra_`> (in the backend processing)
[12:05] <asac> ogra_`: ok, but this is not using snapcraft... guess will have to happen still then. thanks
[12:06] <ogra_`> asac, it is a snapcraft plugin and i plan to use it in the official builds later
[12:06] <sergiusens> ppisati, hey, are you going to be able to make it to the dtb meeting I set?
[12:06] <ogra_`> (or it will become one in the end at least as i understand)
[12:06] <sergiusens> ogra_`, asac what plugin?
[12:06] <ogra_`> sergiusens, tims kernel thin
[12:06] <ogra_`> *thing
[12:07] <ogra_`> sergiusens, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/refs/
[12:07] <ogra_`> asac, as i understood tim plans to just hook it into the make plugin in the end
[12:08] <sergiusens> ogra_`, so it would be a part, not a plugin
[12:08] <ogra_`> might be ... better ask tim how he planned to integrate it
[12:09] <sergiusens> the only thing that worries me are the sudo calls
[12:09] <ogra_`> but as i understood the reason for the toplevel Makefile is to make use of the make plugin
[12:09] <ogra_`> yeah, he probably should use fakechroot
[12:09] <ogra_`> (and fakeroot)
[12:10] <asac> hmm. sounds not as cool as it could/should be, in this case snapcraft doesnt make life easier
[12:10] <sergiusens> ogra_`, can you do everything there with sudo?
[12:10] <ogra_> sergiusens, thats what i do in the touch initrd build scripts
[12:10] <ogra_> you dont need sudo at all then ... it fakes a root env
[12:11] <ogra_> asac, well ... you need the chroot bit to generate an initrd until we have any other solution ... you will always end up with scripts there ...
[12:12] <ogra_> the build wouldnt need to use a deb for the kernel itself though ... but i guess thats also more maintenance in the end
[12:12] <sergiusens> ogra_, so what's up the the talks about making initrd generic?
[12:13] <ogra_> sergiusens, i wish we could ... but that would mean a bunch of kernel changes
[12:13] <ppisati> sergiusens: yep
[12:13] <asac> ogra_: what is the other solution? who is working on it and if noone what needs doing e.g. the plan?
[12:13] <sergiusens> ppisati, great
[12:13] <ogra_> not sure we actually want squashfs and all of vfat built into every generic kernel
[12:13] <asac> if noone comes up with a better solution we have to go generic
[12:14] <asac> not sure if anyone is thinking about better solution though; hence asking
[12:14] <ogra_> asac, the only other solution would be a module-less initrtd that you can just pull from somewhere
[12:14] <ogra_> asac, but as i said above, that needs all bits we need to boot snappy built into the kernel
[12:14] <asac> sure
[12:14] <ogra_> ad as ling as we use the generic kernel thats tricky
[12:14] <asac> doesnt feel wrong to do that; who is pushing back?
[12:14] <ogra_> *long
[12:15] <ogra_> nobody is pushing back
[12:15] <asac> so vfat is surely in the kernel right now, no?
[12:15] <ogra_> not all of it
[12:15] <ogra_> codepages are mnodules
[12:16] <asac> whats that?
[12:16] <ogra_> we need all of vfat, ext4 and squashfs builtin
[12:16] <ogra_> nls codepages
[12:16] <ogra_> for being able to handle filenames
[12:16] <ogra_> vfat needs that
[12:17] <ogra_> and there are multiple (i never saw any other than iso-8859-1 used though, but there are like 30-50 of them)
[12:17] <asac> so we support some format of filenames?
[12:17] <asac> why cant we restrict us to those?
[12:17] <ogra_> vfat does
[12:17] <ogra_> its not us
[12:18] <ogra_> i dont think there is a utf-8 codepage that could cover everything
[12:20] <ogra_> asac, the prob is ... if you get a usb stick from a chinese friend it might need a different codepage ... vfat wouldnt mount it if that isnt available ... while we could build all codepages into the kernel technically that adds a huge amount of bloat
[12:21] <ogra_> OTOH i'm not sure if we could build only the codepage we use into the kernel and leave the rest as modules
[12:21] <ogra_> probably ppisati knows :)
[12:22] <sergiusens> Chipaca or mvo_ , is      security-template: network-status    a 16.04 only thing?
[12:24] <Chipaca> sergiusens: no
[12:24] <Chipaca> sergiusens: bah. it's under 15.04. let me check on actual 15.04
[12:27] <Chipaca> sergiusens: it's there in 15.04
[12:27] <Chipaca> sergiusens: /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/network-status
[12:27] <sergiusens> Chipaca, meh, then boo :-)
[12:27] <sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed
[12:27] <sergiusens> bwm-ng_0.6-3.2_amd64.snap failed to install: exit status 1
[12:27] <sergiusens> Chipaca, is it on sstable or only edge?
[12:28]  * sergiusens starts the day and checks
[12:28] <Chipaca> sergiusens: stable r10
[12:29] <sergiusens> Chipaca, hah, review tools fail for this as well with 'unsupported template'
[12:30] <sergiusens> Chipaca, this is what I'm looking at btw https://bugs.launchpad.net/snapcraft/+bug/1519251
[12:30] <ogra_> beuno, i still cant install any snaps on either of my edge installs, how long do you plan to keep it that way ?
[12:30] <ogra_> (shouldnt that be rolled back until we have a proper solution ?)
[12:34] <Chipaca> sergiusens: you should probably have a word with the jamie
[12:34] <ogra_> mvo_, what do you think about forcing LC_ALL=C in an /etc/profile.d snippet that we ship in ubuntu-core-config ?
[12:34]  * ogra_ is annoyed having to set LC_ALL=C all the time
[12:37] <beuno> ogra_, hi. We just need to make a decision on how to fix it. I'll get that decision in ~30 minutes
[12:38] <ogra_> ok
[12:53] <dholbach> hey sergiusens
[12:54] <mvo_> ogra_: +1 from me until have  a image that supports locales
[12:54] <dholbach> sergiusens, if I list a file under binaries which is a shell script, should that work and provide a valid snap?
[12:55] <ogra_> mvo_, eek ... you really want to go down that rabbit hole ?
[12:55] <dholbach> sergiusens, or do we only want to list binaries there?
[12:57] <mvo_> ogra_: I think eventually we have no choice, for now I think forcing C or C.UTF-8 is fine
[12:57] <ogra_> mvo_, we always have choice :)
[12:58] <ogra_> but yeah. i'll add that snippet
[13:02] <sergiusens> dholbach, interpreted languages are binaries(!)
[13:02] <sergiusens> dholbach, well, to the purpose of snapcraft ;-)
[13:02] <sergiusens> dholbach, the examples are full of them
[13:03] <dholbach> sergiusens, I get this:
[13:03] <dholbach> - lint:control_architecture_specified_needed
[13:03] <dholbach> 	Could not find compiled binaries for architecture 'amd64'
[13:04] <dholbach> I guess that's a bug for click-reviewers-tools
[13:04] <sergiusens> dholbach, define architetures: [all]
[13:04] <dholbach> maybe somebody could help Jamie with a review of this one too: https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218
[13:04] <sergiusens> dholbach, your snap is just one one one script?
[13:04] <dholbach> yes
[13:05] <dholbach> sergiusens, "architetures: [all]" doesn't fix it
[13:06] <sergiusens> dholbach, is there a typo there?
[13:06] <sergiusens> missing a c :-)
[13:08] <dholbach> sorry, "architectures: [all]"
[13:11] <dholbach> https://bazaar.launchpad.net/~dholbach/+junk/hello-world.snap/view/head:/snapcraft.yaml
[13:26] <dholbach> sergiusens, ^
[13:28] <sergiusens> dholbach, yeah yeah, one sec ;-)
[13:28] <dholbach> ok, no worries :)
[13:40] <beuno> ogra_, conclusion is that we'll update the edge image to point at the stable channel
[13:40] <beuno> and other things, that i'll send to the list in a little bit
[13:41] <ogra_> beuno, dont forget about stable then :)
[13:41] <ogra_> (i mean 15.04/edge, sorry )
[13:43] <beuno> yes, for 15.04 as well
[13:43] <beuno> mvo will solve all the problems, as usual
[13:43] <ogra_> ah, k, then it is in good hands
[13:44] <sergiusens> dholbach, so I guess we don't support your use case anymore
[13:44] <dholbach> ok...
[13:44] <sergiusens> dholbach, we could, we just don't
[13:44] <dholbach> I guess this might be a common one?
[13:45] <dholbach> is there another way to at least create a wrapper for scripts?
[13:47] <ogra_> sergiusens, well, as long as "snappy build" works, once can at least still build multi snaps manually :P
[13:47] <sergiusens> ogra_, snappy build will not work in 16.04
[13:48] <ogra_> sergiusens, yeah, and with that snappy loses a lot of excitement for me as maintainer ... unless you start supporting multi snaps in snapcraft
[13:48] <sergiusens> dholbach, I really doubt there will be a lot of snaps that are just scripts, but just create a bug ;-)
[13:48] <ogra_> since i have to maintain a single snap for each arch ... with a single page in the store etc etc ...
[13:48]  * ogra_ guesses that wont win us more maintainers 
[13:49] <dholbach> sergiusens, is that a snapcraft or click-reviewers-tools issue?
[13:49] <sergiusens> dholbach, snapcraft, we mark the arch as where you build it
[13:49] <dholbach> ok
[13:49] <ogra_> sergiusens, maintaining debs is easier then
[13:49] <ogra_> (which is very sad)
[13:50] <sergiusens> dholbach, if I find something to parse the tree and check if it is an actual binary we can do this automatically
[13:50] <sergiusens> ogra_, I have no idea what you are talking about ;-)
[13:51] <dholbach> sergiusens, you can probably borrow the checks from the reviewers tools
[13:51] <ogra_> sergiusens, that maintaining my stuff in a deb is abouot 10% the work it takes me to maintain 4 snaps
[13:51] <ogra_> with that new model
[13:52] <ogra_> we are making maintainer life really hard with that
[13:52] <ogra_> i.e. it wouldnt encourage me to turn my stuff into a snap as an upstream ... even thouh it is easier to set up a snapcraft.yaml vs a debian dir, the followup work is horrid
[13:52] <sergiusens> ogra_, you can take the store issues to beuno and for snapcraft, better bring in concrete problems (in the form of bugs would be nice so it's not fire and forget)
[13:53] <ogra_> sergiusens, well, thats not a store issue ... i have a few multi arch snaps
[13:54] <ogra_> (in fact node-snapper defaults to build multi)
[13:54] <ogra_> with dropping the ability to do that you make maintainer life really hard if i as maintainer want to support all arches
[13:54] <sergiusens> ogra_, as a debian package maintainer you need to create N builds for N arches; I don't understand how it is harder
[13:54] <ogra_> and i dont think a bug is the right thing for somethin "planned"
[13:55] <ogra_> sergiusens, i dont ... i upload one source package
[13:55] <sergiusens> ogra_, you should be able to build for N arches on launchpad
[13:55]  * sergiusens goes back to work
[13:56] <ogra_> sergiusens, right, but then i still need to maintin N store pages because i have not a single multi snap but N arches i need to support now
[13:56] <ogra_> i simply think it is very discouraging to drop that feature
[13:58] <sergiusens> dholbach, ping me once you have the bug
[13:59] <dholbach> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1520248
[14:13] <Chipaca> dholbach: https://github.com/ubuntu-core/snappy/blob/15.04/docs/autopilot.md is ready for you
[14:13] <dholbach> thanks Chipaca
[14:16] <dholbach> Chipaca, updated
[14:16] <Chipaca> huzzah
[14:25] <sergiusens> dholbach, this is also ready for you https://github.com/ubuntu-core/snapcraft/pull/121
[14:25] <dholbach> sergiusens, checking in a sec
[15:20] <dholbach> sergiusens, so with this branch I'm required to specify architectures, right?
[15:23] <sergiusens> dholbach, yes
[15:24] <dholbach> it'd be nice if that wasn't necessary O:-)
[15:25] <sergiusens> dholbach, oh; but then ogra_ will complain that multi is not working either
[15:25] <sergiusens> dholbach, I will add auto detect into a future branch
[15:25] <ogra_> :P
[15:25] <dholbach> I don't understand
[15:26] <dholbach> couldn't this be completely autodetected at some stage in the future?
[15:43] <sergiusens> mvo_, Chipaca mind confirming my comment? https://bugs.launchpad.net/snappy/+bug/1520253
[15:45] <ogra_> hmm ... snappy list on my rpi shows me "classic.mvo" .... i thought thats amd64 only
[15:46] <davmor2> I think mvo only called it classic so he could get people to say classic.mvo more often
[15:47] <ogra_> well, i should see ubuntu-classic-armhf.mvo i think
[15:47] <davmor2> ogra_: spoilsport
[15:50] <sergiusens> dholbach, the arch stuff in click-review only checks for binaries, I'd need to walk the full tree, might be doable
[15:50] <sergiusens> err, hmm, all_files, nevermind :-)
[15:57] <beuno> ogra_, ubuntu-classic-armhf.mvo
[15:57] <beuno> hasn't been published
[15:57] <ogra_> oh
[15:57] <beuno> not sure if by accident or not
[15:57] <ogra_> https://uappexplorer.com/app/ubuntu-classic-armhf.mvo
[15:57] <ogra_> your API thinks differently :)
[15:57] <beuno> ogra_, classic.mvo
[15:58] <beuno> is marked as architecture independant
[15:58] <beuno> which I'm sure is a lie
[15:58] <ogra_> you'd guess :)
[15:58] <beuno> that's why you get it as a result
[15:59] <beuno> ogra_, it was published and then unpublished
[15:59] <beuno> seems uappexplorer doesn't keep up with removals
[15:59] <ogra_> ah !
[15:59] <beuno> Wed 25 Nov. 2015
[15:59] <beuno> Ready to publish.
[15:59] <beuno> Tue 24 Nov. 2015
[15:59] <beuno> Published.
[15:59] <beuno> mvo is such a tease
[15:59] <ogra_> haha
[15:59] <ogra_> yeah
[16:00]  * ogra_ installs his debootstrap snap then ... who needs classic :P
[16:01] <dholbach> install the moon-buggy snap :-P
[16:06] <ogra_> hah !
[16:06] <sergiusens> dholbach, what does that do?
[16:06] <ogra_> cool
[16:06] <ogra_> someone needs to do a nethack snap too !
[16:06] <dholbach> sergiusens, it's a silly ascii art game
[16:07] <dholbach> sergiusens, I was just looking for something hello-world-esque to snap :)
[16:07] <tsimonq2> an irssi snap would be pretty badass
[16:07] <tsimonq2> or an ssh one
[16:07] <tsimonq2> (if it isn't already integrated)
[16:07] <ogra_> an ssh one ??
[16:07] <ogra_> ssh is
[16:07] <tsimonq2> ogra_: oh, ok
[16:08] <ogra_> i'm about to upload a bip snap
[16:08] <ogra_> and an approx one too
[16:08] <tsimonq2> ogra_: but an irssi one would be pretty badass, no?
[16:08] <ogra_> sure, go ahead !
[16:08] <tsimonq2> :D
[16:17] <tsimonq2> ogra_: would you happen to know how I can make myself a debootstrap Sannpy environment, instead of using a VM?
[16:17] <tsimonq2> *Snappy
[16:18] <ogra_> you mean on your PC ?
[16:19] <tsimonq2> ogra_: yep, I am using an i386 Lubuntu machine, which is old, so no Hardware Virtualization support
[16:19] <tsimonq2> ogra_: so that would probably be a way around that, right?
[16:20] <ogra_> no, it wont ... to run a snappy install you need a certain partitioning
[16:20] <tsimonq2> oh ok
[16:20] <dholbach> sergiusens, we'll go with next Wed 16 UTC, right? if you're fine with that, I'll send the announce and get it added to the calendars
[16:20] <ogra_> so some kind of vm is needed ...
[16:20] <tsimonq2> ogra_: I have a nicer machine, so when I get access to it, I will use that with a VM
[16:21] <tsimonq2> because an irssi snap would be awesome :D
[16:21] <ogra_> (unless you have actual hardware like an Rpi2)
[16:21] <tsimonq2> nope
[16:21] <ogra_> to actually build a snap you only need snapcraft installed
[16:21] <tsimonq2> oh, is that as simple as sudo apt install snapcraft?
[16:21] <ogra_> (thouh indeed, to test it you will need a VM to instal it in)
[16:21] <ogra_> yeah
[16:22] <sergiusens> dholbach, yeah, by then 0.6 might be out :-P
[16:22] <tsimonq2> ok, might as well play with it a bit, this could be awesome :D
[16:22] <dholbach> sergiusens, ok.. I'll just call it "what's new in snapcraft" :)
[16:22] <ogra_> if you have questions, just ask here
[16:23] <tsimonq2> ok, thanks ogra_
[16:27] <tsimonq2> ogra_: do you guys have support for the Raspberry Pi Zero yet?
[16:27] <ogra_> we cant
[16:27] <ogra_> it uses the same CPU arch as the RPi1
[16:28] <tsimonq2> ogra_: so NO Ubuntu on that AT ALL?
[16:28] <tsimonq2> sad :(
[16:28] <ogra_> yep
[22:14] <ogra_> sergiusens, is there any way to use a package proxy for snapcraft ?
[22:14] <ogra_> or make it use the sources.list entry from my build chroot
[23:16] <sergiusens> ogra_, USE_LOCAL_SOURCES=1
[23:16] <sergiusens> ogra_, the xenial snapcraft will always do that btw
[23:16] <sergiusens> oh, but the cache, the cache is different
[23:17] <sergiusens> the way python apt is done, it is not straightforward and haven't found time