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. | 02:25 |
---|---|---|
=== 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 | ||
dholbach | good morning | 08:04 |
fgimenez | good morning | 08:10 |
=== wgrant is now known as Guest42266 | ||
=== ara is now known as Guest26179 | ||
=== tasdomas` is now known as tasdomas | ||
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:44 |
=== Chipaca` is now known as Chipaca | ||
Chipaca | liuxg: echo 'config: {ubuntu-core: {autopilot: off}}' | sudo snappy config ubuntu-core - | 09:59 |
Chipaca | liuxg: it seems autoupdate.md is missing the - | 10:00 |
liuxg | Chipaca, is it "off", or "false"? | 10:01 |
liuxg | Chipaca, it should be "true" or "false". it should not be "on" or "off" | 10:02 |
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:03 |
Chipaca | liuxg: all of those are valid boolean values in yaml | 10:04 |
liuxg | Chipaca, ok.ใlet me try it. | 10:05 |
liuxg | Chipaca, sorry, I am wrong. it works. also true/false work as well. :) | 10:06 |
=== vrruiz_ is now known as rvr | ||
liuxg | Chipaca, by the way, what is the use of "-" in the command? | 10:10 |
Chipaca | liuxg: conventionally, specifying - for an argument that expects a file uses stdin as the file | 10:11 |
liuxg | Chipaca, I got it. thanks | 10:12 |
liuxg | Chipaca, I just found that the method at https://developer.ubuntu.com/en/snappy/guides/autopilot/ also worked | 10:14 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 | |
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:28 |
mattyw | unknown flag `allow-unauthenticated' | 10:29 |
mattyw | hmmm | 10:29 |
mattyw | ogra_`, unknown flag, what do you use if not snappy-remote? | 10:31 |
mattyw | ogra_`, just works now, maybe I did have a bad snap - all working now, sorry to trouble you | 10:36 |
SaMnCo-desktop | is there a list of all caps available for users somewhere? | 10:49 |
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:50 |
Chipaca | SaMnCo-desktop: docker itself | 10:56 |
Chipaca | SaMnCo-desktop: frameworks can extend caps | 10:56 |
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:03 |
SaMnCo-desktop | and then, what cap / framework should I use to add the BLE stack? | 11:04 |
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:05 |
Chipaca | SaMnCo-desktop: i don't think so, but i'm not sure | 11:06 |
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:11 |
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:12 |
Chipaca | that'd help | 11:13 |
dholbach | from the 15.04 branch? | 11:13 |
Chipaca | oh, good point | 11:13 |
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:14 |
Chipaca | dholbach: i'll poke you later today when the 15.04 branch has the right autopilot docs | 11:15 |
Chipaca | dholbach: thanks | 11:15 |
dholbach | thanks Chipaca | 11:16 |
ogra_` | asac, the kernel snap only uses binary debs | 11:26 |
ogra_` | asac, it is actually rootstock hacked up :P | 11:27 |
asac | ogra_`: why didnt we do the snapcraft plugin? | 11:34 |
asac | was there a need to do the shortcut? | 11:34 |
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:35 |
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:37 |
ogra_` | asac, and there is no other way to do it ... you need a proper initrd which you can only get from packages | 11:40 |
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:41 |
ogra_` | (in the backend processing) | 11:42 |
asac | ogra_`: ok, but this is not using snapcraft... guess will have to happen still then. thanks | 12:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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_` is now known as ogra_ | ||
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
ogra_ | i dont think there is a utf-8 codepage that could cover everything | 12:18 |
=== happyaro1 is now known as happyaron | ||
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:20 |
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:21 |
sergiusens | Chipaca or mvo_ , is security-template: network-status a 16.04 only thing? | 12:22 |
Chipaca | sergiusens: no | 12:24 |
Chipaca | sergiusens: bah. it's under 15.04. let me check on actual 15.04 | 12:24 |
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:27 |
* sergiusens starts the day and checks | 12:28 | |
Chipaca | sergiusens: stable r10 | 12:28 |
sergiusens | Chipaca, hah, review tools fail for this as well with 'unsupported template' | 12:29 |
sergiusens | Chipaca, this is what I'm looking at btw https://bugs.launchpad.net/snapcraft/+bug/1519251 | 12:30 |
ubottu | Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete] | 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:30 |
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:34 | |
beuno | ogra_, hi. We just need to make a decision on how to fix it. I'll get that decision in ~30 minutes | 12:37 |
ogra_ | ok | 12:38 |
dholbach | hey sergiusens | 12:53 |
=== joc_ is now known as joc|lunch | ||
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:54 |
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:55 |
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:57 |
ogra_ | but yeah. i'll add that snippet | 12:58 |
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:02 |
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:03 |
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:04 |
dholbach | sergiusens, "architetures: [all]" doesn't fix it | 13:05 |
sergiusens | dholbach, is there a typo there? | 13:06 |
sergiusens | missing a c :-) | 13:06 |
dholbach | sorry, "architectures: [all]" | 13:08 |
dholbach | https://bazaar.launchpad.net/~dholbach/+junk/hello-world.snap/view/head:/snapcraft.yaml | 13:11 |
dholbach | sergiusens, ^ | 13:26 |
sergiusens | dholbach, yeah yeah, one sec ;-) | 13:28 |
dholbach | ok, no worries :) | 13:28 |
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:40 |
ogra_ | beuno, dont forget about stable then :) | 13:41 |
ogra_ | (i mean 15.04/edge, sorry ) | 13:41 |
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:43 |
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:44 |
dholbach | is there another way to at least create a wrapper for scripts? | 13:45 |
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:47 |
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:48 | |
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:49 |
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:50 |
=== joc|lunch is now known as joc_ | ||
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:51 |
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:52 |
ogra_ | sergiusens, well, thats not a store issue ... i have a few multi arch snaps | 13:53 |
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:54 |
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:55 | |
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:56 |
sergiusens | dholbach, ping me once you have the bug | 13:58 |
dholbach | sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1520248 | 13:59 |
ubottu | Launchpad bug 1520248 in Snapcraft "snap with only scripts gets wrongs architecture set" [Undecided,New] | 13:59 |
Chipaca | dholbach: https://github.com/ubuntu-core/snappy/blob/15.04/docs/autopilot.md is ready for you | 14:13 |
dholbach | thanks Chipaca | 14:13 |
dholbach | Chipaca, updated | 14:16 |
Chipaca | huzzah | 14:16 |
sergiusens | dholbach, this is also ready for you https://github.com/ubuntu-core/snapcraft/pull/121 | 14:25 |
dholbach | sergiusens, checking in a sec | 14:25 |
dholbach | sergiusens, so with this branch I'm required to specify architectures, right? | 15:20 |
sergiusens | dholbach, yes | 15:23 |
dholbach | it'd be nice if that wasn't necessary O:-) | 15:24 |
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:25 |
dholbach | couldn't this be completely autodetected at some stage in the future? | 15:26 |
sergiusens | mvo_, Chipaca mind confirming my comment? https://bugs.launchpad.net/snappy/+bug/1520253 | 15:43 |
ubottu | Launchpad bug 1520253 in Snappy "Only one of apparmor.override / seccomp.override is required" [Undecided,New] | 15:43 |
=== JanC_ is now known as JanC | ||
ogra_ | hmm ... snappy list on my rpi shows me "classic.mvo" .... i thought thats amd64 only | 15:45 |
davmor2 | I think mvo only called it classic so he could get people to say classic.mvo more often | 15:46 |
ogra_ | well, i should see ubuntu-classic-armhf.mvo i think | 15:47 |
davmor2 | ogra_: spoilsport | 15:47 |
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:50 |
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:57 |
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:58 |
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 | 15:59 |
* ogra_ installs his debootstrap snap then ... who needs classic :P | 16:00 | |
dholbach | install the moon-buggy snap :-P | 16:01 |
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:06 |
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:07 |
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:08 |
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:17 |
ogra_ | you mean on your PC ? | 16:18 |
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:19 |
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:20 |
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:21 |
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:22 |
tsimonq2 | ok, thanks ogra_ | 16:23 |
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:27 |
tsimonq2 | ogra_: so NO Ubuntu on that AT ALL? | 16:28 |
tsimonq2 | sad :( | 16:28 |
ogra_ | yep | 16:28 |
=== 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 | ||
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 | 22:14 |
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:16 |
sergiusens | the way python apt is done, it is not straightforward and haven't found time | 23:17 |
=== vrruiz__ is now known as rvr | ||
=== DanChapman_ is now known as DanChapman |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!