[02:25] 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. === mwenning is now known as mwenning-afk === chihchun_afk is now known as chihchun === ubott2 is now known as ubottu === cprov_ is now known as cprov === rsalveti_ is now known as rsalveti === seb128_ is now known as seb128 === beowulf is now known as Guest38368 [08:04] good morning [08:10] good morning === wgrant is now known as Guest42266 === ara is now known as Guest26179 === tasdomas` is now known as tasdomas [09:44] 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? === Chipaca` is now known as Chipaca [09:59] liuxg: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core - [10:00] liuxg: it seems autoupdate.md is missing the - [10:01] Chipaca, is it "off", or "false"? [10:02] Chipaca, it should be "true" or "false". it should not be "on" or "off" [10:03] liuxg: why should it not be on/off? [10:03] 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] liuxg: all of those are valid boolean values in yaml [10:05] Chipaca, ok.　let me try it. [10:06] Chipaca, sorry, I am wrong. it works. also true/false work as well. :) === vrruiz_ is now known as rvr [10:10] Chipaca, by the way, what is the use of "-" in the command? [10:11] liuxg: conventionally, specifying - for an argument that expects a file uses stdin as the file [10:12] Chipaca, I got it. thanks [10:14] Chipaca, I just found that the method at https://developer.ubuntu.com/en/snappy/guides/autopilot/ also worked [10:23] 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] Good morning all; happy Thursday and happy Cake Day! 😃 http://goo.gl/oKyw2t [10:24] mattyw, did you use the --allow-unauthenticated option to snappy install ? [10:24] ogra_`, I didn't that must be a new thing? [10:24] oh, ignore me [10:24] i thought you meant you sideload a snap ... but you see that on upload [10:24] Error "failed to install" when uploading? o_O [10:24] oh, right [10:25] JamesTait, ogasawara well, snappy-remote install [10:25] ah ! [10:25] yeah I'm sideloading [10:25] Ah! [10:25] * JamesTait stands down [10:25] then you want the --allow-unauthenticated option indeed [10:25] (and no, thats not new at all) [10:26] 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] 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] (snappy-remote that is) [10:28] mattyw: a few months ago you might have been using an image in developer mode [10:28] mattyw: which imples --alllow-unauthenticated-potatos [10:29] unknown flag `allow-unauthenticated' [10:29] hmmm [10:31] ogra_`, unknown flag, what do you use if not snappy-remote? [10:36] ogra_`, just works now, maybe I did have a bad snap - all working now, sorry to trouble you [10:49] is there a list of all caps available for users somewhere? [10:50] eg. in https://insights.ubuntu.com/2015/07/20/prime-time-docker-juju-and-snappy-ubuntu-core/ Dustin uses "docker_client" [10:50] where does that come from? [10:56] SaMnCo-desktop: docker itself [10:56] SaMnCo-desktop: frameworks can extend caps [11:03] 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] 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] and then, what cap / framework should I use to add the BLE stack? [11:05] SaMnCo-desktop: i'm not sure there's a bluez framework yet, but there might be [11:05] Chipaca- Is there a list of public frameworks available somewhere? [11:06] SaMnCo-desktop: i don't think so, but i'm not sure [11:11] dholbach: so, two issues with snappy docs in d.u.c [11:11] dholbach: one is the autopilot doc, which is stale [11:11] dholbach: in fact i don't think it's ever been true for a released snappy [11:11] Chipaca- so, is there a list of the caps available somewhere? [11:11] yes, I know some are stale :-/ [11:12] 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 [11:12] yes, that's the plan [11:12] 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] ah [11:12] what can I do for the short term? update the autopilot doc? [11:13] that'd help [11:13] from the 15.04 branch? [11:13] oh, good point [11:14] let me check that :) [11:14] dholbach: is this manual or automatic? [11:14] it's manual now [11:14] I hope it's automatic very soon [11:14] 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] but I guess it'll take at least 1-2 more weeks [11:15] dholbach: i'll poke you later today when the 15.04 branch has the right autopilot docs [11:15] dholbach: thanks [11:16] thanks Chipaca [11:26] asac, the kernel snap only uses binary debs [11:27] asac, it is actually rootstock hacked up :P [11:34] ogra_`: why didnt we do the snapcraft plugin? [11:34] was there a need to do the shortcut? [11:35] asac, it is a snapcraft plugin but using rootstock as backend [11:35] it is? [11:35] the git branch rt announced isnt [11:35] asac, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/ [11:35] its just a makefile in a source tree that does everything [11:35] http://kernel.ubuntu.com/git/rtg/kernel-snap.git/tree/Makefile?h=amd64-from-deb-16.04 [11:35] how is that a plugin? [11:37] build_chroot: rootstock [11:37] sudo sh ./rootstock -a $(ARCH) -f $(LINUX_FLAVOUR) -m $(MIRROR) -s $(SUITE) -b $(BOOTLOADER) $(PPAS) -k [11:37] sudo chmod +r $(CHROOT)/boot/* [11:37] the only git i see in that file is to pull the most recent rootstock script [11:40] asac, and there is no other way to do it ... you need a proper initrd which you can only get from packages [11:41] http://kernel.ubuntu.com/git/rtg/kernel-snap.git/log/?h=raspi2-from-git [11:41] this seems to first build a deb from a kernel tree and then pipes it into rootstock [11:41] but effectively it is all deb based [11:42] (in the backend processing) [12:05] ogra_`: ok, but this is not using snapcraft... guess will have to happen still then. thanks [12:06] asac, it is a snapcraft plugin and i plan to use it in the official builds later [12:06] ppisati, hey, are you going to be able to make it to the dtb meeting I set? [12:06] (or it will become one in the end at least as i understand) [12:06] ogra_`, asac what plugin? [12:06] sergiusens, tims kernel thin [12:06] *thing [12:07] sergiusens, http://kernel.ubuntu.com/git/rtg/kernel-snap.git/refs/ [12:07] asac, as i understood tim plans to just hook it into the make plugin in the end [12:08] ogra_`, so it would be a part, not a plugin [12:08] might be ... better ask tim how he planned to integrate it [12:09] the only thing that worries me are the sudo calls [12:09] but as i understood the reason for the toplevel Makefile is to make use of the make plugin [12:09] yeah, he probably should use fakechroot [12:09] (and fakeroot) [12:10] hmm. sounds not as cool as it could/should be, in this case snapcraft doesnt make life easier [12:10] ogra_`, can you do everything there with sudo? === ogra_` is now known as ogra_ [12:10] sergiusens, thats what i do in the touch initrd build scripts [12:10] you dont need sudo at all then ... it fakes a root env [12:11] 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] 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] ogra_, so what's up the the talks about making initrd generic? [12:13] sergiusens, i wish we could ... but that would mean a bunch of kernel changes [12:13] sergiusens: yep [12:13] ogra_: what is the other solution? who is working on it and if noone what needs doing e.g. the plan? [12:13] ppisati, great [12:13] not sure we actually want squashfs and all of vfat built into every generic kernel [12:13] if noone comes up with a better solution we have to go generic [12:14] not sure if anyone is thinking about better solution though; hence asking [12:14] asac, the only other solution would be a module-less initrtd that you can just pull from somewhere [12:14] asac, but as i said above, that needs all bits we need to boot snappy built into the kernel [12:14] sure [12:14] ad as ling as we use the generic kernel thats tricky [12:14] doesnt feel wrong to do that; who is pushing back? [12:14] *long [12:15] nobody is pushing back [12:15] so vfat is surely in the kernel right now, no? [12:15] not all of it [12:15] codepages are mnodules [12:16] whats that? [12:16] we need all of vfat, ext4 and squashfs builtin [12:16] nls codepages [12:16] for being able to handle filenames [12:16] vfat needs that [12:17] 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] so we support some format of filenames? [12:17] why cant we restrict us to those? [12:17] vfat does [12:17] its not us [12:18] i dont think there is a utf-8 codepage that could cover everything === happyaro1 is now known as happyaron [12:20] 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] 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] probably ppisati knows :) [12:22] Chipaca or mvo_ , is security-template: network-status a 16.04 only thing? [12:24] sergiusens: no [12:24] sergiusens: bah. it's under 15.04. let me check on actual 15.04 [12:27] sergiusens: it's there in 15.04 [12:27] sergiusens: /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/network-status [12:27] Chipaca, meh, then boo :-) [12:27] 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] bwm-ng_0.6-3.2_amd64.snap failed to install: exit status 1 [12:27] Chipaca, is it on sstable or only edge? [12:28] * sergiusens starts the day and checks [12:28] sergiusens: stable r10 [12:29] Chipaca, hah, review tools fail for this as well with 'unsupported template' [12:30] Chipaca, this is what I'm looking at btw https://bugs.launchpad.net/snapcraft/+bug/1519251 [12:30] Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete] [12:30] 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] (shouldnt that be rolled back until we have a proper solution ?) [12:34] sergiusens: you should probably have a word with the jamie [12:34] 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] ogra_, hi. We just need to make a decision on how to fix it. I'll get that decision in ~30 minutes [12:38] ok [12:53] hey sergiusens === joc_ is now known as joc|lunch [12:54] ogra_: +1 from me until have a image that supports locales [12:54] sergiusens, if I list a file under binaries which is a shell script, should that work and provide a valid snap? [12:55] mvo_, eek ... you really want to go down that rabbit hole ? [12:55] sergiusens, or do we only want to list binaries there? [12:57] ogra_: I think eventually we have no choice, for now I think forcing C or C.UTF-8 is fine [12:57] mvo_, we always have choice :) [12:58] but yeah. i'll add that snippet [13:02] dholbach, interpreted languages are binaries(!) [13:02] dholbach, well, to the purpose of snapcraft ;-) [13:02] dholbach, the examples are full of them [13:03] sergiusens, I get this: [13:03] - lint:control_architecture_specified_needed [13:03] Could not find compiled binaries for architecture 'amd64' [13:04] I guess that's a bug for click-reviewers-tools [13:04] dholbach, define architetures: [all] [13:04] 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] dholbach, your snap is just one one one script? [13:04] yes [13:05] sergiusens, "architetures: [all]" doesn't fix it [13:06] dholbach, is there a typo there? [13:06] missing a c :-) [13:08] sorry, "architectures: [all]" [13:11] https://bazaar.launchpad.net/~dholbach/+junk/hello-world.snap/view/head:/snapcraft.yaml [13:26] sergiusens, ^ [13:28] dholbach, yeah yeah, one sec ;-) [13:28] ok, no worries :) [13:40] ogra_, conclusion is that we'll update the edge image to point at the stable channel [13:40] and other things, that i'll send to the list in a little bit [13:41] beuno, dont forget about stable then :) [13:41] (i mean 15.04/edge, sorry ) [13:43] yes, for 15.04 as well [13:43] mvo will solve all the problems, as usual [13:43] ah, k, then it is in good hands [13:44] dholbach, so I guess we don't support your use case anymore [13:44] ok... [13:44] dholbach, we could, we just don't [13:44] I guess this might be a common one? [13:45] is there another way to at least create a wrapper for scripts? [13:47] sergiusens, well, as long as "snappy build" works, once can at least still build multi snaps manually :P [13:47] ogra_, snappy build will not work in 16.04 [13:48] 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] dholbach, I really doubt there will be a lot of snaps that are just scripts, but just create a bug ;-) [13:48] 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] sergiusens, is that a snapcraft or click-reviewers-tools issue? [13:49] dholbach, snapcraft, we mark the arch as where you build it [13:49] ok [13:49] sergiusens, maintaining debs is easier then [13:49] (which is very sad) [13:50] dholbach, if I find something to parse the tree and check if it is an actual binary we can do this automatically [13:50] ogra_, I have no idea what you are talking about ;-) === joc|lunch is now known as joc_ [13:51] sergiusens, you can probably borrow the checks from the reviewers tools [13:51] sergiusens, that maintaining my stuff in a deb is abouot 10% the work it takes me to maintain 4 snaps [13:51] with that new model [13:52] we are making maintainer life really hard with that [13:52] 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] 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] sergiusens, well, thats not a store issue ... i have a few multi arch snaps [13:54] (in fact node-snapper defaults to build multi) [13:54] with dropping the ability to do that you make maintainer life really hard if i as maintainer want to support all arches [13:54] 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] and i dont think a bug is the right thing for somethin "planned" [13:55] sergiusens, i dont ... i upload one source package [13:55] ogra_, you should be able to build for N arches on launchpad [13:55] * sergiusens goes back to work [13:56] 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] i simply think it is very discouraging to drop that feature [13:58] dholbach, ping me once you have the bug [13:59] sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1520248 [13:59] Launchpad bug 1520248 in Snapcraft "snap with only scripts gets wrongs architecture set" [Undecided,New] [14:13] dholbach: https://github.com/ubuntu-core/snappy/blob/15.04/docs/autopilot.md is ready for you [14:13] thanks Chipaca [14:16] Chipaca, updated [14:16] huzzah [14:25] dholbach, this is also ready for you https://github.com/ubuntu-core/snapcraft/pull/121 [14:25] sergiusens, checking in a sec [15:20] sergiusens, so with this branch I'm required to specify architectures, right? [15:23] dholbach, yes [15:24] it'd be nice if that wasn't necessary O:-) [15:25] dholbach, oh; but then ogra_ will complain that multi is not working either [15:25] dholbach, I will add auto detect into a future branch [15:25] :P [15:25] I don't understand [15:26] couldn't this be completely autodetected at some stage in the future? [15:43] mvo_, Chipaca mind confirming my comment? https://bugs.launchpad.net/snappy/+bug/1520253 [15:43] Launchpad bug 1520253 in Snappy "Only one of apparmor.override / seccomp.override is required" [Undecided,New] === JanC_ is now known as JanC [15:45] hmm ... snappy list on my rpi shows me "classic.mvo" .... i thought thats amd64 only [15:46] I think mvo only called it classic so he could get people to say classic.mvo more often [15:47] well, i should see ubuntu-classic-armhf.mvo i think [15:47] ogra_: spoilsport [15:50] dholbach, the arch stuff in click-review only checks for binaries, I'd need to walk the full tree, might be doable [15:50] err, hmm, all_files, nevermind :-) [15:57] ogra_, ubuntu-classic-armhf.mvo [15:57] hasn't been published [15:57] oh [15:57] not sure if by accident or not [15:57] https://uappexplorer.com/app/ubuntu-classic-armhf.mvo [15:57] your API thinks differently :) [15:57] ogra_, classic.mvo [15:58] is marked as architecture independant [15:58] which I'm sure is a lie [15:58] you'd guess :) [15:58] that's why you get it as a result [15:59] ogra_, it was published and then unpublished [15:59] seems uappexplorer doesn't keep up with removals [15:59] ah ! [15:59] Wed 25 Nov. 2015 [15:59] Ready to publish. [15:59] Tue 24 Nov. 2015 [15:59] Published. [15:59] mvo is such a tease [15:59] haha [15:59] yeah [16:00] * ogra_ installs his debootstrap snap then ... who needs classic :P [16:01] install the moon-buggy snap :-P [16:06] hah ! [16:06] dholbach, what does that do? [16:06] cool [16:06] someone needs to do a nethack snap too ! [16:06] sergiusens, it's a silly ascii art game [16:07] sergiusens, I was just looking for something hello-world-esque to snap :) [16:07] an irssi snap would be pretty badass [16:07] or an ssh one [16:07] (if it isn't already integrated) [16:07] an ssh one ?? [16:07] ssh is [16:07] ogra_: oh, ok [16:08] i'm about to upload a bip snap [16:08] and an approx one too [16:08] ogra_: but an irssi one would be pretty badass, no? [16:08] sure, go ahead ! [16:08] :D [16:17] ogra_: would you happen to know how I can make myself a debootstrap Sannpy environment, instead of using a VM? [16:17] *Snappy [16:18] you mean on your PC ? [16:19] ogra_: yep, I am using an i386 Lubuntu machine, which is old, so no Hardware Virtualization support [16:19] ogra_: so that would probably be a way around that, right? [16:20] no, it wont ... to run a snappy install you need a certain partitioning [16:20] oh ok [16:20] 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] so some kind of vm is needed ... [16:20] ogra_: I have a nicer machine, so when I get access to it, I will use that with a VM [16:21] because an irssi snap would be awesome :D [16:21] (unless you have actual hardware like an Rpi2) [16:21] nope [16:21] to actually build a snap you only need snapcraft installed [16:21] oh, is that as simple as sudo apt install snapcraft? [16:21] (thouh indeed, to test it you will need a VM to instal it in) [16:21] yeah [16:22] dholbach, yeah, by then 0.6 might be out :-P [16:22] ok, might as well play with it a bit, this could be awesome :D [16:22] sergiusens, ok.. I'll just call it "what's new in snapcraft" :) [16:22] if you have questions, just ask here [16:23] ok, thanks ogra_ [16:27] ogra_: do you guys have support for the Raspberry Pi Zero yet? [16:27] we cant [16:27] it uses the same CPU arch as the RPi1 [16:28] ogra_: so NO Ubuntu on that AT ALL? [16:28] sad :( [16:28] yep === benoitc_ is now known as benoitc === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === tsimonq2alt is now known as tsimonq2 === jeffesquivels_ is now known as jeffesquivels === |svij| is now known as svij === inaddy is now known as tinoco === mwhudson_ is now known as mwhudson === hotfuzz_ is now known as hotfuzz === tbr_ is now known as tbr === |svij| is now known as svij === jeffesquivels_ is now known as jeffesquivels === inaddy is now known as tinoco [22:14] sergiusens, is there any way to use a package proxy for snapcraft ? [22:14] or make it use the sources.list entry from my build chroot [23:16] ogra_, USE_LOCAL_SOURCES=1 [23:16] ogra_, the xenial snapcraft will always do that btw [23:16] oh, but the cache, the cache is different [23:17] the way python apt is done, it is not straightforward and haven't found time === vrruiz__ is now known as rvr === DanChapman_ is now known as DanChapman