| === asac` is now known as asac | ||
| === morphis__ is now known as morphis | ||
| zyga-phone | good morning | 07:31 |
|---|---|---|
| didrocks | hey zyga-phone | 07:39 |
| zyga-phone | hey :) | 07:39 |
| dholbach | good morning | 07:54 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/598/files | 08:00 |
| didrocks | good morning dholbach | 08:01 |
| zyga-phone | hey dholbach :) | 08:02 |
| sergiusens | ogra_, you around? | 08:14 |
| dholbach | salut didrocks, hey zyga-phone | 08:16 |
| zyga-phone | :) | 08:17 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/600 (more confusing names fixed) | 08:22 |
| noizer | good morning | 08:27 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/601 | 08:32 |
| noizer | is it possible to update snapcraft? zyga-phone | 08:41 |
| sergiusens | mvo, on kernel snap install, are you doing something similar to snap.kernel.split('-')[1] ? | 08:52 |
| mvo | sergiusens: I don't think so, I think grub even only looks for vmlinuz and nothing else (and initrd.img) so best to have symlink to those | 09:02 |
| mvo | sergiusens: gustavo was also keen to move this to a convention based install instead of having keys in snap.yaml for the kernel/initrd | 09:02 |
| zyga-phone | noizer: yes, you can always use the bleeding edge version from source | 09:06 |
| noizer | zyga-phone https://github.com/ubuntu-core/snapcraft | 09:06 |
| sergiusens | mvo, I'm doing hard links; the layout of partition 8 is really weird | 09:07 |
| noizer | zyga-phone thats this one? | 09:07 |
| noizer | zyga-phone but what branche then? | 09:07 |
| sergiusens | mvo, also, I'm not doing the crazy vmlinuz rename when building for arm64 since it is an uncompressed 'Image' target | 09:07 |
| sergiusens | the debbuild for some crazy legacy reason does a blind rename to vmlinuz | 09:07 |
| zyga-phone | noizer: master, if you don't feel confident in using it then please just wait | 09:08 |
| zyga-phone | we're all working on the release | 09:08 |
| zyga-phone | so you will have fresh debs and images soon | 09:08 |
| noizer | zyga-phone I will just try it if it don't work for me I will wait for the deb packages | 09:09 |
| mvo | sergiusens: for amd64/i386 right now we hardcode vmlinuz unfortuantely but that is probably a bug. uboot should actually be flexible | 09:09 |
| sergiusens | mvo, http://paste.ubuntu.com/15326741/ | 09:16 |
| sergiusens | mvo, http://paste.ubuntu.com/15326751/ | 09:20 |
| sergiusens | mvo, so I'm not sure what is going on | 09:20 |
| sergiusens | mvo, reason I ask if there is some sort of "cut" iin the code | 09:20 |
| mvo | sergiusens: this looks good, except of course that it does not work | 09:21 |
| mvo | Bad Linux ARM64 Image magic! | 09:21 |
| sergiusens | mvo, well if you look in the `find mnt` there's a plain 'Image' file | 09:21 |
| sergiusens | mvo, that plainly does not exist in anything I provide | 09:22 |
| sergiusens | I provide Image-something | 09:22 |
| mvo | sergiusens: indeed, I think there is a split on "-" in the code somewhere | 09:23 |
| mvo | sergiusens: that explains where it comes from | 09:24 |
| sergiusens | mvo, yeah, we should not do that :-) I'm trying to do `kernel: vmlinuz` now | 09:24 |
| sergiusens | mvo, although these arm kernels are not gz'ed | 09:24 |
| mvo | sergiusens: yeah, we need to fix this | 09:28 |
| sergiusens | mvo, also I noticed the dtbs are missing | 09:28 |
| mvo | oh? | 09:28 |
| sergiusens | mvo, in the released kernel snap on the store as well | 09:28 |
| mvo | sergiusens: did you list them in snap.yaml? | 09:29 |
| sergiusens | mvo, so the <packagename>.snap/dtbs is there, but in the root there's a 'dtbs' dir that is empty | 09:29 |
| sergiusens | mvo, yeah, check the pastebin :-) | 09:29 |
| sergiusens | mvo, doh | 09:29 |
| sergiusens | mvo, no I didn't | 09:29 |
| mvo | sergiusens: I did check the pastebin first ;) | 09:29 |
| mvo | sergiusens: this is why I asked | 09:30 |
| sergiusens | mvo, I need to fix this in my snapcraft as I'm manually adding (I don't want users to do this as it might just go away) | 09:30 |
| mvo | sergiusens: it will probably go away | 09:31 |
| sergiusens | mvo, I hope so :-) | 09:32 |
| sergiusens | ppisati, hey, building the kernel for dragon board gets me 2.6GB of kernel modules; how is the one in the snap so small? | 09:32 |
| ppisati | sergiusens: we normally build with debug symbols built-in | 09:33 |
| ppisati | sergiusens: and then strip kernel and modules when creating the .deb | 09:33 |
| ppisati | sergiusens: this way from sthe same build we get the debug .deb and the normal .deb | 09:33 |
| ppisati | sergiusens: so either your build that way and later strip | 09:33 |
| ppisati | sergiusens: or simply turn off DEBUG_INFO | 09:34 |
| ppisati | sergiusens: and thus don't build the debug symbols | 09:34 |
| sergiusens | ppisati, ah so it is a config? | 09:34 |
| * sergiusens looks | 09:34 | |
| sergiusens | ppisati, this does make sense | 09:34 |
| ppisati | sergiusens: CONFIG_DEBUG_INFO=y | 09:35 |
| sergiusens | ppisati, yeah I see, thanks | 09:35 |
| ppisati | sergiusens: turn that off and your kernel / .ko will go on diet | 09:35 |
| sergiusens | ppisati, being on a diet is harsh though, now I don't want to do it :-) | 09:35 |
| sergiusens | I'll leave it on as I'm enabling | 09:36 |
| ppisati | sergiusens: +1 | 09:36 |
| sergiusens | but thanks for the tip :-) | 09:36 |
| ppisati | sergiusens: any time | 09:36 |
| sergiusens | mvo, it boots! | 09:51 |
| mvo | sergiusens: OMG! | 09:51 |
| sergiusens | sadly it seems the resize code is active | 09:51 |
| sergiusens | mvo, http://paste.ubuntu.com/15326840/ | 09:52 |
| sergiusens | I need the ogra_ :-) | 09:52 |
| sergiusens | I'll see if I have a smaller sdcard here | 09:52 |
| mvo | sergiusens: very impressive | 09:54 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/602 | 09:59 |
| ogra_ | sergiusens, did you pick the right dtb ? we need a patched one (in paolos deb it has a -snappy.dtb suffix | 09:59 |
| ogra_ | sergiusens, the resize code is moot, parted fails | 10:01 |
| ogra_ | mvo, sergiusens thats bug 1553110 ... the resize tools are missing all libs | 10:02 |
| ubottu | bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 | 10:02 |
| ogra_ | so what it prints is a lie currently ... | 10:02 |
| ogra_ | your last paste shows you are missing the modules though | 10:02 |
| ogra_ | (no squashfs) | 10:02 |
| sergiusens | ogra_, oh, is squashfs a module in the default kernel build? | 10:02 |
| ogra_ | yeah | 10:03 |
| sergiusens | darn! | 10:03 |
| sergiusens | well at least I can go back to my fast sdcard :-) | 10:03 |
| ogra_ | if the resize code would kick in you would only notice it at next boot | 10:03 |
| ogra_ | (it wipes the bootloader partition types) | 10:03 |
| ogra_ | the current boot would just go on | 10:03 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/603 | 10:27 |
| sergiusens | ogra_, what about now http://paste.ubuntu.com/15326926/ ? | 10:28 |
| ogra_ | sergiusens, still missing squashfs | 10:29 |
| sergiusens | ogra_, but it says it loaded right there | 10:29 |
| ogra_ | ? | 10:29 |
| ogra_ | where | 10:29 |
| sergiusens | ogra_, sorry, should of copied more above http://paste.ubuntu.com/15326932/ | 10:31 |
| ogra_ | mvo, how about we grep through /proc/filesystems and exiot with a proper error message when we cant find squashfs support in the initrd | 10:31 |
| sergiusens | ogra_, line 19 there | 10:31 |
| ogra_ | "unsupported RELA relocation: 275" | 10:31 |
| mvo | ogra_: who would say NO to this suggestion :-D ? +1 | 10:32 |
| ogra_ | no idea what that means, but sounds like you are missing features | 10:32 |
| sergiusens | ogra_, seems more like a bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009 | 10:32 |
| ubottu | Launchpad bug 1533009 in gcc-5 (Ubuntu Wily) "arm64: "unsupported RELA relocation"" [Undecided,New] | 10:32 |
| ogra_ | sergiusens, ah, yeah | 10:33 |
| ogra_ | in any case it seems to prevent the module from loading | 10:33 |
| ogra_ | sergiusens, if you build the kernel yourself anyway, just compile it in ;) | 10:35 |
| sergiusens | ogra_, hah, but I want the module xp | 10:35 |
| sergiusens | I can try going to gcc 4.8 | 10:36 |
| sergiusens | ppisati, do you know about "unsupported RELA relocation: 275" ? | 10:47 |
| sergiusens | I'm using gcc-aarch64-linux-gnu | 10:47 |
| sergiusens | ricmm, http://paste.ubuntu.com/15327015/ | 10:56 |
| ppisati | sergiusens: you mean the qemu warning? in case yes, i saw it, but that didn't stop from building working images using qemu | 11:02 |
| sergiusens | ppisati, no, I'm doing cross compilation (ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-) | 11:03 |
| ppisati | sergiusens: are youusing a recent xenial chroot? | 11:03 |
| sergiusens | ppisati, and during boot I get http://paste.ubuntu.com/15326932/ | 11:03 |
| sergiusens | [ 13.207166] module squashfs: unsupported RELA relocation: 275 | 11:04 |
| sergiusens | ppisati, no chroots, just my regular xenial system | 11:04 |
| ppisati | sergiusens: i thought we fixed that | 11:04 |
| ppisati | sergiusens: it was a regression in the xenial toolchain | 11:04 |
| ppisati | sergiusens: but now is fixed | 11:04 |
| sergiusens | ppisati, heh, not for me; fixed in gcc? | 11:05 |
| ppisati | sergiusens: fixed in our toolchain | 11:05 |
| ppisati | sergiusens: not sure about upstream | 11:05 |
| sergiusens | ppisati, I have http://paste.ubuntu.com/15326932/ | 11:05 |
| sergiusens | ppisati, I also see KBUILD_CFLAGS_MODULE += -mcmodel=large -mpc-relative-literal-loads in the arm64 Makefile | 11:06 |
| ppisati | sergiusens: we are carrying a patch too for that | 11:07 |
| sergiusens | ppisati, err, I have 1:5.3.1-8ubuntu2cross2 | 11:07 |
| ppisati | sergiusens: hold on | 11:07 |
| ppisati | sergiusens: if you see KBUILD_CFLAGS_MODULE += -mcmodel=large -mpc-relative-literal-loads then you have the two patches | 11:09 |
| ppisati | sergiusens: is that my tree? | 11:11 |
| ppisati | sergiusens: if you cross compile my tree, do you get that too? | 11:11 |
| sergiusens | ppisati, no, it's the 96boards one | 11:11 |
| ppisati | sergiusens: try my tree | 11:11 |
| ppisati | sergiusens: if it works, then they are missing some patch | 11:11 |
| ppisati | sergiusens: if you keep getting that, than it's your toolchain | 11:12 |
| sergiusens | ppisati, in arch/arm64/Makefile I miss that line completely, not sure what I saw before | 11:12 |
| ppisati | sergiusens: you need | 11:14 |
| ppisati | sergiusens: b6dd8e0719c0d2d01429639a11b7bc2677de240c | 11:14 |
| ppisati | sergiusens: and | 11:14 |
| ppisati | sergiusens: 6113222fa5386433645c7707b4239a9eba444523\ | 11:14 |
| ppisati | without the traliing \ | 11:14 |
| sergiusens | thanks, I iwll try | 11:14 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/604 | 11:22 |
| * zyga-phone is killing SNAP_FULLNAME | 11:22 | |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/605 | 11:41 |
| * zyga-phone is renaming SNAP_ORIGIN to SNAP_DEVELOPER | 11:41 | |
| noizer | zyga-phone where can i find the last snapcraft version? | 12:40 |
| ogra_ | in xenial | 12:41 |
| noizer | ogra_ but i want to build with some slots but for now it doesn't work (snapcraft 2.3.2) | 12:41 |
| ogra_ | you might have to wait a little more, the image and snapcraft are supposed to be released together | 12:42 |
| ogra_ | (not sure where we stand with the image release) | 12:43 |
| noizer | ogra_ Ok i heard about it but will it release today for the raspberry pi? | 12:43 |
| ogra_ | no idea | 12:43 |
| ogra_ | (i only tested the arm64 rootfs yesterday ... perhaps mvo can tell when the new stuff gets out) | 12:44 |
| noizer | is he online at this moment? because I think he is very busy at the moment | 12:49 |
| zyga-phone | noizer: on github.com/ubuntu-core/snapcraft | 13:04 |
| didrocks | noizer: just run from ^ using bin/snapcraft, it will import the correct files | 13:09 |
| noizer | didrocks does not work :s | 13:15 |
| didrocks | noizer: logs? I'm doing that daily, so I highly doubt it doesn't take the right snapcraft version :p | 13:16 |
| dholbach | davidcalle, didrocks, I put up a branch which has all the relevant bits for a demo (https://code.launchpad.net/~dholbach/developer-ubuntu-com/hero-tour-changes/+merge/287765) - maybe we can merge the template into it? | 13:23 |
| noizer | didrocks my snapcraft is 2.3.2 | 13:23 |
| dholbach | let me re-push it to the developer site dev team namespace | 13:23 |
| noizer | didrocks when I do /usr/bin/snapcraft clean i get the error where he don't find slots | 13:24 |
| didrocks | noizer: why are you using /usr/bin/snapcraft? I told you to use the github repo that zyga-phone pointed out and run bin/snapcraft | 13:24 |
| noizer | didrocks | 13:25 |
| noizer | thx i will test that | 13:26 |
| dholbach | https://code.launchpad.net/~developer-ubuntu-com-dev/developer-ubuntu-com/hero-tour-changes/+merge/288400 | 13:26 |
| dholbach | sorry, https://code.launchpad.net/~developer-ubuntu-com-dev/developer-ubuntu-com/hero-tour-changes/+merge/288401 | 13:28 |
| didrocks | dholbach: excellent! should we try to assemble something with davidcalle's current work? That way we can have a first result and see how it goes? | 13:28 |
| didrocks | dholbach: want that we catch up? (I've the first markdown pages written) | 13:29 |
| dholbach | didrocks, that's why I pushed to the team namespace | 13:29 |
| dholbach | let's wait for the template - at that point it'll make sense to get together and figure out what's still missing :) | 13:29 |
| didrocks | sure! | 13:29 |
| dholbach | great :) | 13:30 |
| didrocks | nice work :) | 13:30 |
| niemeyer | jdstrand: ping | 13:38 |
| noizer | didrocks it works fine :D is security polity available there? | 13:40 |
| noizer | *security-policy | 13:40 |
| didrocks | noizer: no idea TBH, I can just tell you it's the freshest and latest :p | 13:42 |
| noizer | didrocks ok thx a lot :D | 13:42 |
| didrocks | yw ;) | 13:43 |
| zyga-phone | jdstrand: hey, please ping me when you're around | 14:00 |
| zyga-phone | jdstrand: we'd like to have a call with you today | 14:00 |
| mvo | ogra_: I uploaded a new arm64 edge OS snap juts today | 14:04 |
| ogra_ | mvo, ok, will test later ... btw ... http://paste.ubuntu.com/15327686/ | 14:10 |
| ogra_ | i'm about to push that to the PPA and do some test builds ... if it works i'll upload it | 14:10 |
| ogra_ | (and if it works for the os snap, it should be easy to do the same for the kernel tarballs too) | 14:11 |
| mvo | ogra_: nice | 14:16 |
| mvo | ogra_: I think you can drop readme.md and package.yaml now | 14:16 |
| ogra_ | mvo, do you need the buildds today ? | 14:16 |
| noizer | is it possible to use security-override? mvo zyga-phone | 14:16 |
| noizer | in snapcraft | 14:16 |
| ogra_ | i dont want to get in your way with a potentially broken livecd-rootfs in case you need to re-build something | 14:16 |
| mvo | ogra_: probably not, I think I did enough | 14:16 |
| ogra_ | ok | 14:16 |
| ogra_ | will drop the package.yaml ... | 14:17 |
| mvo | ogra_: i.e. the current edge OS is good so far | 14:17 |
| ogra_ | mvo, what about the gadget dir ? | 14:17 |
| mvo | ogra_: if it works on amd64 as well I push to rolling/stable | 14:17 |
| mvo | ogra_: we don't need that anymore too | 14:17 |
| zyga-phone | noizer: yes | 14:17 |
| zyga-phone | noizer: through old-security | 14:17 |
| mvo | ogra_: its all under /snaps now | 14:17 |
| ogra_ | cool, dropping that as well | 14:17 |
| zyga-phone | noizer: as soon as the new release is out | 14:17 |
| mvo | ogra_: yeah, that should work. nice to see this btw | 14:17 |
| noizer | but i got now the new snapcraft | 14:17 |
| noizer | but it don't works on my snappy OS probably | 14:18 |
| ogra_ | i'm a bit worried about the apt-get install ... not sure if that works | 14:18 |
| ogra_ | but i dont really want to make snappy a hard dep of livecd-rootfs | 14:18 |
| noizer | zyga-phone | 14:18 |
| ysionneau | Hi, how do I allow a syscall in my snapcraft.yaml for an app ? | 14:18 |
| ysionneau | an if the app command is a shell script doing an exec, is the syscall autorization OK for the binary which is executed? | 14:19 |
| zyga-phone | noizer: I'm sorry I cannot help you today, we can either implement snappy or help everyone on the channel trying things out but not both; in a few days I will have more time and things will be in better shape for you to try them out; please wait for the release for now. | 14:19 |
| ysionneau | (and say the exec'ed binary is also a shell script doing an exec, etc) | 14:19 |
| ysionneau | and if the app* | 14:19 |
| ogra_ | ysionneau, there are ways to make syscall exceptions via snapcraft.yaml ... but ask jdstrand which ones will actually be allowed by the store ... (i think fchown is one of the allowed ones, not sure there are others) | 14:20 |
| ysionneau | oh, so I cannot do syscalls: [send] ? | 14:21 |
| jdstrand | no | 14:21 |
| ysionneau | fyi I get this : Mar 8 13:55:33 localhost kernel: [ 794.318819] audit: type=1326 audit(1457445333.541:13): auid=1000 uid=1000 gid=1000 ses=2 pid=1229 comm="ld-linux-armhf." exe="/snaps/wifid.sideload/LSTDgDnSXTSF/lib/ld-linux-armhf.so.3" sig=31 arch=40000028 syscall=289 compat=0 ip=0x76e9a4d6 code=0x0 | 14:21 |
| ysionneau | and 289 seems to be "send" | 14:21 |
| jdstrand | use 'snappy-debug.security scanlog' | 14:21 |
| jdstrand | that will tell you what syscall 289 is on your system | 14:21 |
| jdstrand | and will suggest a 'cap' to use | 14:22 |
| ysionneau | this tool fails with a permission denied error | 14:22 |
| jdstrand | ysionneau: is this on 16.04 or 15.04? | 14:22 |
| ysionneau | 16.04 | 14:22 |
| ysionneau | http://pastebin.com/nakZUZ6Y | 14:22 |
| jdstrand | yeah, developing on 16.04 now is difficult-- all of this is in flux | 14:22 |
| jdstrand | it hasn't been converted to the new interfaces yet | 14:23 |
| ysionneau | ok | 14:23 |
| ysionneau | so what can I do then? | 14:24 |
| rtg | ogra_, did you ever get the generic initrd package working ? | 14:24 |
| jdstrand | ysionneau: do scmp_sys_resolver 289 | 14:24 |
| jdstrand | on the machine that has the error | 14:24 |
| ysionneau | 15:24 < jdstrand> ysionneau: do scmp_sys_resolver 289 < yes, it prints send | 14:24 |
| ogra_ | rtg, yes, but only half way, there are bugs in fakechroot that are kond of blocking atm | 14:24 |
| jdstrand | send is part of 'network-client' | 14:24 |
| ysionneau | I also already give the network-client caps | 14:24 |
| jdstrand | you don't need an override | 14:24 |
| ogra_ | rtg, bug 1553110 | 14:25 |
| ubottu | bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 | 14:25 |
| jdstrand | your yaml is probably not right for the new interfaces stuff | 14:25 |
| ysionneau | so maybe the right question was : is the capability kept by the process if it does exec ? | 14:25 |
| zyga-phone | josepht: hey :-) | 14:25 |
| zyga-phone | er | 14:25 |
| zyga-phone | jdstrand: hey :) | 14:25 |
| ysionneau | I would say yes since the usual snappy way is to wrap binary calls to export env vars and do 'exec' | 14:25 |
| jdstrand | zyga-phone: hey | 14:25 |
| jdstrand | ysionneau: yes | 14:25 |
| zyga-phone | jdstrand: please check out telegram if you can | 14:26 |
| ysionneau | but I don't understand here why my capability network-client doesn't allow me to use "send" | 14:26 |
| ogra_ | rtg, beyon that the iinitrd should be usable ... it is just that some features like resize do not work atm ... you can just grab ubuntu-core-generic-initrd and pull the img from /usr/lib/ubuntu-core-generic-initrd (and then add modules and stuff) | 14:26 |
| jdstrand | ysionneau: I bet it is because your yaml is wrong for the new interfaces work | 14:26 |
| jdstrand | it is just using the default policy and ignoring everything else | 14:26 |
| rtg | ogra_, what package produces the generic initrd ? initramfs-tools-ubuntu-core ? | 14:26 |
| ysionneau | hmm at least the yaml does pass the parsing of snapcraft :o | 14:27 |
| jdstrand | I think that is what jibel and mvo were talking about earlier | 14:27 |
| ysionneau | so it seems OK according to the schema | 14:27 |
| ogra_ | rtg, yep | 14:27 |
| ysionneau | and it seems OK with the examples I see in snapcraft/examples | 14:27 |
| zyga-phone | ysionneau: it will only work with unreleased snapcraft + snappy | 14:27 |
| zyga-phone | so wait :) | 14:27 |
| jdstrand | zyga-phone: so, there is an email and tg. I will get to it, but it will be a little bit | 14:27 |
| ysionneau | zyga-phone: yes, I'm using unreleased snapcraft :) | 14:27 |
| zyga-phone | jdstrand: thanks | 14:27 |
| zyga-phone | ysionneau: and unreleased snappy? | 14:28 |
| ysionneau | I'm using snapcraft from git | 14:28 |
| ysionneau | but I'm indeed using the "devel" channel of snappy for rpi2 | 14:28 |
| ysionneau | ubuntu-core 2016-03-08 16.04.0-15.armhf | 14:28 |
| zyga-phone | ysionneau: that's not enough | 14:28 |
| zyga-phone | ysionneau: you have to wait for snappy release (today) | 14:29 |
| jdstrand | pindonga: can you pull the review tools if you haven't already-- seems the interface rename is all landing | 14:29 |
| ysionneau | allright, thanks! | 14:29 |
| pindonga | jdstrand, ack, no I haven't (so good you reminded me) | 14:29 |
| jdstrand | pindonga: thanks! | 14:30 |
| niemeyer | jdstrand: Do you have a moment for a call? | 14:33 |
| mvo | I pushed a new stable OS update with the most recent change described in https://lists.ubuntu.com/archives/snappy-devel/2016-March/001567.html | 14:33 |
| mvo | sergiusens: you have a stable OS update now with the plugs: changes | 14:33 |
| zyga-phone | \o/ | 14:42 |
| * zyga-phone hugs mvo | 14:42 | |
| zyga-phone | ysionneau, noizer: try out the fresh image and snapcraft after reading the email above ^^ | 14:42 |
| niemeyer | jdstrand? | 14:42 |
| noizer | zyga-phone I updated my ubuntu-core already xD | 14:43 |
| noizer | saw the good news from mvo :D | 14:43 |
| ysionneau | zyga-phone: thx! | 14:46 |
| ysionneau | I don't see any update after doing snappy update | 14:48 |
| ysionneau | I'm in -15 | 14:48 |
| ysionneau | or should I re-generate an image using your ubuntu-image ? | 14:48 |
| mvo | ysionneau: armhf version -15? that is ok that is the most current one | 14:49 |
| ysionneau | ah so I was already on the right one, and with latest snapcraft | 14:50 |
| ysionneau | so I don't get what's wrong | 14:50 |
| ysionneau | maybe I should use "plugs" and not "slots" | 14:50 |
| ysionneau | hmm nop snapcraft refuses it | 14:51 |
| mvo | dpm: for calculator you need to so sed -i "s/slots:/plugs:/" meta/snap.yaml | 14:51 |
| zyga-phone | ysionneau: you should use "plugs" for the snapcraft.yaml | 14:52 |
| ysionneau | hmmm is github ubuntu-core/snapcraft up to date? | 14:53 |
| ysionneau | cause I'm using that, and it refuses to parse my yaml if I use plugs :o | 14:54 |
| ysionneau | 15:52 < zyga-phone> ysionneau: you should use "plugs" for the snapcraft.yaml : I get : Issues while validating snapcraft.yaml: Additional properties are not allowed ('plugs' was unexpected) | 14:57 |
| zyga-phone | o_O | 14:58 |
| zyga-phone | old snapcraft I guess | 14:58 |
| zyga-phone | I don't know, it's just out of sync then | 14:58 |
| ysionneau | looks like I don't have the right version, yes, I'm on master branche on SHA1 6d17a601d24b7053ffe92e3cb1d58e0bb9415a36 | 14:58 |
| ysionneau | branch* | 14:59 |
| zyga-phone | ysionneau: you have to dig in for yourself for a while | 14:59 |
| ysionneau | that's the last commit I see on https://github.com/ubuntu-core/snapcraft/commits/master | 15:03 |
| * ogra_ dances around mvo | 15:11 | |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54544 | 15:11 |
| ogra_ | livecd.ubuntu-core.ubuntu-core_16.04-20160308-15:04_amd64.snap (75.9 MiB) | 15:11 |
| ogra_ | :D | 15:11 |
| mvo | ogra_: sweeeeeeeet | 15:11 |
| * mvo hugs ogra_ | 15:11 | |
| ogra_ | mvo, i see ou added the arch name to the version in the ones you upload to the store ... should i do the same ? | 15:11 |
| ogra_ | (i'm also not sure about the colon in the timestamp) | 15:12 |
| mvo | ogra_: its not longer needed, I did it because the store broke in a funny way in the past without it | 15:12 |
| ogra_ | ah, cool | 15:12 |
| mvo | ogra_: it was also useful to debug an issue where the store send me a armhf os snap when I was an amd64, I only noticed because of the version string | 15:12 |
| mvo | ogra_: but all those issues are fixed now | 15:13 |
| ogra_ | ok, cool | 15:13 |
| ogra_ | what about the colon, can that stay ? | 15:13 |
| mvo | ogra_: technically its an epoch right now | 15:13 |
| ogra_ | oops | 15:13 |
| ogra_ | indeed | 15:13 |
| mvo | ogra_: so a "-" would be nicer | 15:13 |
| ogra_ | funnny that the package actually built at 15:04 :) | 15:14 |
| mvo | ogra_: however very very soon version numbers will have no semantic meaning whatsoever | 15:14 |
| ogra_ | ok | 15:14 |
| mvo | ogra_: lol | 15:14 |
| mvo | ogra_: nice | 15:14 |
| * ogra_ changes to a dash | 15:14 | |
| mvo | ogra_: so if its trivial, please just fix the ":" for now, soon it won't matter :) | 15:14 |
| ogra_ | i386 looks fine too ... waiting for the arms then i'll push that to the archive | 15:14 |
| ogra_ | yeah, totally trivial | 15:14 |
| mvo | nice, great work! | 15:15 |
| ogra_ | heh, only the start ... the tricky part is to teack cdimage about .snap now | 15:16 |
| dpm | mvo, ok, thanks! Will do it in a couple of hours and let you know. Any news on the upload of the snapcraft version that supports these changes? | 15:16 |
| ogra_ | *teach | 15:17 |
| mvo | dpm: ups, I forgot, the last I heard from sergiusens was that he wants a stable os snap first that supports it. he is in a eastern timezone now I think so probably will read this tomorrow | 15:20 |
| ogra_ | yeah, he's probably already drowning in beer | 15:20 |
| dpm | :) | 15:22 |
| dpm | ok, thanks mvo | 15:22 |
| jdstrand | niemeyer: I will have a moment for a call yes, but I haven't yet had a moment to catch up on the thread | 15:30 |
| jdstrand | niemeyer: I'm going through this now. can I ping you in a few minutes? | 15:30 |
| jdstrand | niemeyer: can I rely on the email thread as everything I need to know or should I read through the (long) tg discussion? | 15:31 |
| niemeyer | jdstrand: The email thread+document is much better than the tg thread for context | 15:32 |
| jdstrand | ok, let me get through that and ping you | 15:32 |
| niemeyer | jdstrand: I'll step out for lunch now.. we can catch up in a couple of hours | 15:32 |
| jdstrand | that works for me as well | 15:32 |
| jdstrand | niemeyer: fyi, I left a comment on https://github.com/ubuntu-core/snappy/pull/606#issuecomment-193820189https://github.com/ubuntu-core/snappy/pull/606#issuecomment-193820189 which I'm not sure if it will affect your judgement on if it should be closed or not | 15:39 |
| zyga-phone | jdstrand: https://github.com/ubuntu-core/snappy/pull/608/files | 15:43 |
| zyga-phone | jdstrand: I'm working on cleaning up patches that take this and splice the interface snippets inside in the right places | 15:43 |
| jdstrand | cool | 15:44 |
| jdstrand | zyga-phone: fyi, I came up with a very compelling use case for the policy being in files | 15:44 |
| jdstrand | zyga-phone: the developer experience is supposed to be: snappy try <snap> (or similar) | 15:45 |
| jdstrand | zyga-phone: that puts the snap in complain mode where everything is allowed, but violations to policy are logged | 15:45 |
| jdstrand | zyga-phone: then another tool is supposed to take those violations and suggest things | 15:45 |
| jdstrand | zyga-phone: that tool can't suggest things without having access to the policy files | 15:46 |
| zyga-phone | jdstrand: I see, how does that tool work today? | 15:46 |
| jdstrand | zyga-phone: well, there are several tools that are going to need to be combined to support the way this is supposed to work (ie, snappy try doesn't do any of the above-- it has to be implemented) | 15:47 |
| jdstrand | zyga-phone: but essentially, the tools would all use libapparmor to parse the log | 15:47 |
| jdstrand | zyga-phone: then they examine the policy files | 15:48 |
| jdstrand | then they say 'add network to your plugs', etc | 15:48 |
| zyga-phone | jdstrand: snappy can easily expose those over the API | 15:48 |
| zyga-phone | jdstrand: this way the tool can actually work without changes later | 15:48 |
| jdstrand | what api? | 15:48 |
| zyga-phone | jdstrand: the rest api | 15:48 |
| zyga-phone | jdstrand: we could simply expose all of the text verbatim | 15:49 |
| jdstrand | zyga-phone: so you're saying that the tool asks the rest api to dump all of the policy for it to then examine? | 15:49 |
| zyga-phone | jdstrand: so you could essentially wget each of the text files | 15:49 |
| zyga-phone | jdstrand: something like it, the advantage is that you could work with the tool remotely as well (nice dev UX) | 15:50 |
| zyga-phone | jdstrand: and locally it would not get out of date/out of sync | 15:50 |
| jdstrand | using files it wouldn't get out of sync either-- it would only use the files on the system | 15:50 |
| jdstrand | but yes, this is an option | 15:50 |
| jdstrand | I guess it is also an answer to the auditing problem I mentioned | 15:51 |
| zyga-phone | jdstrand: well, it'd be more complex to test consistent sets IMHO | 15:51 |
| jdstrand | I don't see how | 15:51 |
| zyga-phone | jdstrand: yeah, I think we can easily expose each snippet as plain text | 15:51 |
| jdstrand | "give me all the files" vs "open all the files" | 15:51 |
| zyga-phone | jdstrand: (you just need snappy, not any other package, to be consistent) | 15:51 |
| zyga-phone | jdstrand: they come from different places | 15:51 |
| jdstrand | I know you guys are excited about all the policy in go. I am not blocking, but I am not | 15:52 |
| zyga-phone | jdstrand: this will also look more complex as snappy moves beyond 16.04 | 15:52 |
| jdstrand | cause looking at https://github.com/ubuntu-core/snappy/pull/608/files it would be just as easy for 'const defaultAppArmorTemplate = ' to be a read on a file in a known location, but I won't beat this horse any more | 15:53 |
| zyga-phone | jdstrand: I though about that and have this implemented (for a few weeks) | 15:54 |
| zyga-phone | jdstrand: but it's still more complex, e.g. on the desktop that package can be updated | 15:54 |
| zyga-phone | jdstrand: so then you now must do invalidation properly | 15:54 |
| zyga-phone | jdstrand: you have to do parsing (I'll break the template into parts so that parsing is not required) | 15:55 |
| jdstrand | I don't consider policy updates a bad thing | 15:55 |
| jdstrand | anyway, we shouldn't rehash this. you guys won | 15:55 |
| zyga-phone | jdstrand: neither do I, but in this model you restart snapd and you're consistent | 15:55 |
| zyga-phone | jdstrand: I'm not trying to convince you over random stuff, IMHO this is really easier to work with | 15:55 |
| zyga-phone | jdstrand: from a purely technical POV | 15:55 |
| jdstrand | please remember our caching discussion thouch | 15:55 |
| jdstrand | though | 15:55 |
| jdstrand | cause there are very important performance considerations | 15:56 |
| zyga-phone | yeah, I know | 15:56 |
| zyga-phone | I'll get to caching | 15:56 |
| jdstrand | ok, cool | 15:56 |
| jdstrand | that is the most important thing | 15:56 |
| jdstrand | if we handle that right, we can see how the policy stuff goes and adjust | 15:56 |
| zyga-phone | jdstrand: I'll try to make snap connect write all the security files today | 15:58 |
| zyga-phone | won't reload aa profiles but will do 90% of the work | 15:58 |
| jdstrand | cool | 15:59 |
| zyga-phone | it's a big change with the state engine but the primitives are ready | 15:59 |
| zyga-phone | just need to finish this real aa policy text to be there | 15:59 |
| === chihchun is now known as chihchun_afk | ||
| zyga-phone | jdstrand: https://github.com/ubuntu-core/snappy/pull/611 | 16:03 |
| zyga-phone | seccomp side | 16:03 |
| jdstrand | zyga-phone: so, in addition to inserting snippets in the right place, you are aware in the apparmor template that you need to also set ###VAR### and ###PROFILEATTACH###, right? | 16:11 |
| zyga-phone | jdstrand: yeah, I have that code for a few weeks | 16:11 |
| jdstrand | ok | 16:11 |
| zyga-phone | (my piglow demo behind me is a proof of that :) | 16:11 |
| jdstrand | that's fine | 16:11 |
| zyga-phone | :) | 16:11 |
| zyga-phone | I'll ask you for review though | 16:12 |
| jdstrand | just wanted to be sure | 16:12 |
| * jdstrand nods | 16:12 | |
| zyga-phone | jdstrand: can you have a look at: https://github.com/ubuntu-core/snappy/pull/612 | 16:13 |
| zyga-phone | jdstrand: this changes how we call ubuntu-core-launcher | 16:13 |
| jdstrand | yes, that is the thread I am trying to get to reading | 16:14 |
| zyga-phone | jdstrand: oh, sorry | 16:14 |
| zyga-phone | ok | 16:14 |
| jdstrand | not your fault | 16:14 |
| jdstrand | my inbox and irc backscroll is quite a lot today | 16:15 |
| niemeyer | jdstrand: ping | 16:21 |
| niemeyer | jdstrand: Can we have it now? | 16:21 |
| niemeyer | jdstrand: ? :-0 | 16:24 |
| niemeyer | :-) | 16:24 |
| jdstrand | still reading | 16:24 |
| jdstrand | I thought I had two hours :) | 16:24 |
| jdstrand | so I tended to other pressing things | 16:24 |
| jdstrand | I'm almost through it | 16:24 |
| niemeyer | jdstrand: Can you please join the hangout? mvo will be off in 40 mins | 16:26 |
| * jdstrand notes this also requires a bit of research, which I'm also doing | 16:26 | |
| niemeyer | https://plus.google.com/hangouts/_/canonical.com/snappy-devel | 16:26 |
| jdstrand | ok, forgive me if my opinion isn't as well-thought out as I'd like it to be | 16:26 |
| niemeyer | jdstrand: Don't worry, that's a friendly call to sort it out.. we can discuss questions live | 16:27 |
| elopio | fgimenez: I thikn this panics when the config is not present: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/base_test.go#L54 | 16:44 |
| elopio | https://www.irccloud.com/pastebin/kZ8l9nLL/ | 16:44 |
| elopio | fgimenez: what if I os.Stat the file, and put all this inside an if? | 16:45 |
| fgimenez | elopio, yes, that can work and keeps all very clear | 16:49 |
| elopio | plars: can you try this one please? | 17:19 |
| jdstrand | zyga-phone: you asked me to look at https://github.com/ubuntu-core/snappy/pull/612/files. is that still needed in light of the meeting we just had? | 17:23 |
| zyga-phone | jdstrand: I think not anymore :) | 17:23 |
| jdstrand | ok, that's what I thought | 17:23 |
| zyga-phone | jdstrand: thanks! | 17:23 |
| zyga-phone | jdstrand: so I see you reviewed the seccomp blob, that's great, I'll merge it | 17:24 |
| jdstrand | zyga-phone: I reviewed 611 (seccomp), do you need me to look at 608 (apparmor)? | 17:24 |
| zyga-phone | please do the same for .. .yes :D | 17:24 |
| zyga-phone | fanstastic | 17:24 |
| jdstrand | hehe | 17:24 |
| zyga-phone | I'll get this to work all the way today | 17:24 |
| zyga-phone | jdstrand: I was looking at one extra thing but that can wait for tomorrow (even for discussion) | 17:26 |
| zyga-phone | jdstrand: to have a know to switch a single snap to development mode | 17:26 |
| zyga-phone | jdstrand: so we get advisory logs, not denials | 17:26 |
| zyga-phone | jdstrand: I think I know how to do it but I'll tell you about what I think I know tomorrow :) | 17:26 |
| zyga-phone | jdstrand: when t hat is available, we can remove hw-assign | 17:26 |
| jdstrand | zyga-phone: that is actually quite easy. let me get that for you | 17:28 |
| zyga-phone | jdstrand: is that just one extra flag in the "header" of the profile? | 17:28 |
| zyga-phone | jdstrand: I read the python code that does aa-{stuff-i-forgot} from apparmor-utils | 17:28 |
| jdstrand | it is | 17:28 |
| zyga-phone | jdstrand: if that's the case I can just bake support for that right into the tooling | 17:29 |
| plars | elopio: what is it you want me to try? | 17:29 |
| zyga-phone | jdstrand: lovely, we need to think how to remember that in the state though (persistent, etc) but I think this will fly | 17:29 |
| elopio | plars: this should fix your panic. | 17:29 |
| jdstrand | zyga-phone: change this: '(attach_disconnected)' to 'flags=(attach_disconnected,complain)' | 17:29 |
| jdstrand | zyga-phone: feel free to change '(attach_disconnected)' to 'flags=(attach_disconnected' in the normal case | 17:30 |
| zyga-phone | jdstrand: noted, thanks | 17:30 |
| * zyga-phone really writes this down on paper | 17:30 | |
| jdstrand | err | 17:30 |
| jdstrand | 'flags=(attach_disconnected)' | 17:30 |
| === vrruiz_ is now known as rvr | ||
| jdstrand | zyga-phone: unfortunately for seccomp the launcher is going to need to be updated | 17:31 |
| zyga-phone | jdstrand: seccomp doesn't have anything like that, right? | 17:31 |
| jdstrand | zyga-phone: (since it is effectively the seccomp policy parser) | 17:31 |
| jdstrand | there is no parser like with apparmor | 17:31 |
| jdstrand | the launcher is the parser | 17:31 |
| zyga-phone | jdstrand: so how do you want that to work? | 17:31 |
| zyga-phone | jdstrand: right, righth | 17:32 |
| jdstrand | so the launcher needs to be updated | 17:32 |
| zyga-phone | jdstrand: ah, the wrapper script | 17:32 |
| zyga-phone | jdstrand: or the actual ubuntu-core-launcher | 17:32 |
| zyga-phone | ? | 17:32 |
| jdstrand | ubuntu-core-launcher | 17:32 |
| elopio | mterry: can I bother you for a moment? I need help with the pipeline test you wrote ages ago. | 17:32 |
| jdstrand | it is what takes the list of syscalls from our generated file, parses the file and then adds each syscall via a C api | 17:32 |
| mterry | elopio, hello | 17:33 |
| jdstrand | zyga-phone: and right now it only does enforce mode | 17:33 |
| zyga-phone | yeah, I know, let's draft the minimum required change to the launcher to support developer mode | 17:33 |
| elopio | mterry: hi. How are you? | 17:33 |
| elopio | mterry: could you first explain to me what's the idea of this test? | 17:33 |
| zyga-phone | and let's see what we can make with that | 17:33 |
| jdstrand | the good news is this all happens after dropping privs | 17:33 |
| mterry | elopio, uh... can you point me where in the code we're talking about? | 17:33 |
| elopio | mterry: https://github.com/ubuntu-core/snapcraft/blob/578fd4657218ce3e1900155a5742436b4757c8a2/examples/libpipeline/test.c | 17:33 |
| elopio | oh, wait, that's an old revision. | 17:34 |
| elopio | mterry: https://github.com/ubuntu-core/snapcraft/blob/master/examples/libpipeline/test.c | 17:34 |
| jdstrand | zyga-phone: for this to work well we need to also patch the kernel to log the security label of the process seccomp is killing/auditing | 17:36 |
| zyga-phone | jdstrand: ok, it seems that full developer mode is still a few days away then; do you have someone to do this work? | 17:36 |
| mterry | elopio, um, if I recall, it was to demonstrate that snapcraft could integrate with your locally built project too. Like you have your source tree. And then you had snapcraft grab all the dependencies and build them. And then you could run "snapcraft shell make" to build your local project pointing at the snapcraft built files. I don't know whether that concept meshes with the snapcraft of today anymore | 17:38 |
| mterry | elopio, (i.e. to demonstrate that you could build that local test.c against snapcraft's copy of libpipeline) | 17:38 |
| jdstrand | zyga-phone: I will be doing the dev mode stuff from the security team. This will not land this week. I will be focusing on enabling you to move fast on interfaces, the framework migrations and snappy on classic policies before developer mode | 17:39 |
| zyga-phone | okay | 17:40 |
| zyga-phone | kiling hw-assign is not important, I just fixed it locally | 17:40 |
| zyga-phone | so it now has $snap.$app IDs | 17:40 |
| zyga-phone | I'll follow up with one more consolidation branch that makes $snap.$app just $snap when $app == $snap | 17:40 |
| zyga-phone | I want to take a stab at Connect() today | 17:41 |
| jdstrand | since it is implemented, that sounds fine, though I'd personally like to see what the interface equivalant of hw-assign will be once the old-security/caps is migrated and old-security/security-template is gone | 17:41 |
| jdstrand | cool | 17:42 |
| elopio | mterry: well, that makes sense today too. Now I'm wondering what should be the output of the test. | 17:42 |
| mterry | elopio, I think it was designed to be run in that folder itself. And it uses a different grep pipeline than http://bazaar.launchpad.net/~mterry/+junk/pipelinetest/view/head:/test.c does, so that the test knows it's using the local test, not the remote test | 17:43 |
| elopio | mterry: it used to print https://paste.ubuntu.com/15329134/ | 17:43 |
| elopio | now it prints just the two first lines. | 17:43 |
| elopio | and I don't understand why it prints grep c when this line shows grep s: https://github.com/ubuntu-core/snapcraft/blob/master/examples/libpipeline/test.c#L9 | 17:44 |
| mterry | elopio, grep c is because you're calling the test code from lp:~mterry/+junk/pipelinetest, not the locally built test | 17:45 |
| mterry | elopio, http://bazaar.launchpad.net/~mterry/+junk/pipelinetest/view/head:/test.c | 17:45 |
| elopio | mterry: ok, so it should print grep s. Not grep c. And it should print the contents of the snap, not of your junk. | 17:48 |
| elopio | I think didrocks changed the cwd, so that explains ls not showing anything. | 17:49 |
| mterry | elopio, well the idea is that we can run both, to show that snapcraft can build a local project and a remote project against an internally built libpipeline | 17:49 |
| mterry | elopio, but yeah the cwd change would explain a new failure | 17:49 |
| zyga-phone | oho | 17:52 |
| * zyga-phone realized we need udevadm control --reload-rules | 17:52 | |
| zyga-phone | jdstrand: ^^ added to my todo | 17:52 |
| zyga-phone | along with udevadm trigger | 17:52 |
| === chihchun_afk is now known as chihchun | ||
| elopio | mterry: thanks. That was a tangled test you wrote in there :) | 17:57 |
| elopio | I'm happy for now that we are getting the "custom libpipeline called" message for now. I think we are calling the wrong test.c, but I'll dig more about it. | 17:57 |
| elopio | we might need a better command than grep to test it now that the dir is empty. | 17:58 |
| mterry | elopio, yeah that test probably could have been better documented :) | 17:58 |
| jdstrand | zyga-phone: nice | 17:59 |
| === chihchun is now known as chihchun_afk | ||
| Facu | Hi all! | 18:14 |
| Facu | I'm trying to flash a device, but ubuntu-device-flash just hangs :/ | 18:14 |
| Facu | this is the third time I run it, now I left it a couple of hours | 18:14 |
| Facu | see http://pastebin.ubuntu.com/15329318/ | 18:14 |
| Facu | is there any way to make it show progress or something? | 18:15 |
| ogra_ | Facu, you probably want the #ubuntu-touch channel | 18:16 |
| Facu | ogra_, err, you right | 18:18 |
| ogra_ | :) | 18:18 |
| plars | elopio: what is the change to make? | 18:22 |
| Facu | ogra_, thanks! | 18:24 |
| elopio | plars: https://github.com/ubuntu-core/snappy/pull/614/files | 18:26 |
| zyga-phone | ogra_: hey | 18:27 |
| plars | elopio: yeah, I thought that might be it from the backlog and had just tried it locally... doesn't *seem* to work | 18:27 |
| ogra_ | zyga-phone, yo | 18:27 |
| zyga-phone | ogra_: how can I help to update firmware and other bits needed for pi2 camera? | 18:27 |
| zyga-phone | (as in, how can I fix the problem for everyone) | 18:27 |
| plars | elopio: wait, maybe... one sec | 18:28 |
| elopio | plars: still panics? | 18:28 |
| zyga-phone | hey plars, long time no see :) | 18:28 |
| ogra_ | zyga-phone, i need to update the firmware anyway (for rpi3 support), i'll try to get to it this week | 18:28 |
| zyga-phone | ogra_: do you think you could show me how you do it | 18:28 |
| zyga-phone | ogra_: I know you can do it but I'd love to learn how this works | 18:28 |
| plars | elopio: it fails differently at least. I can get -h output now, but -check.list doesn't work. One sec and I will pastebing | 18:28 |
| plars | *pastebin | 18:28 |
| ogra_ | zyga-phone, well, i pull the upstream binary blobs from github and replace the ones in the snap ... then buuild an image with that and see if it boots | 18:29 |
| zyga-phone | in the kernel snap? check | 18:29 |
| ogra_ | no magic in that | 18:29 |
| zyga-phone | ok | 18:29 |
| ogra_ | no | 18:29 |
| ogra_ | gadget | 18:29 |
| plars | elopio: it still seems to try to run the setups | 18:29 |
| zyga-phone | and if they work, where do you commit this back? | 18:29 |
| plars | elopio: https://www.irccloud.com/pastebin/p58PGbaJ/ | 18:29 |
| zyga-phone | oh, gadget? | 18:29 |
| zyga-phone | ok | 18:29 |
| ogra_ | zyga-phone, https://github.com/raspberrypi/firmware/tree/master/boot | 18:30 |
| ogra_ | the gadget source is in the snappy-hub branch | 18:31 |
| zyga-phone | ogra_: I mean about our side, I know where the upstream blobs are | 18:31 |
| zyga-phone | ah | 18:31 |
| zyga-phone | ok | 18:31 |
| zyga-phone | ogra_: if I do it, will you review my changes? | 18:31 |
| ogra_ | it is binaries ... there is nothing to review :) | 18:31 |
| zyga-phone | ogra_: well, you can tell me that I did it right and land it :) | 18:32 |
| zyga-phone | ogra_: I just want to 1) help 2) learn | 18:32 |
| ogra_ | if you replace the binaries and manage to still boot, i'm happy to nod it off | 18:32 |
| zyga-phone | (maby 2), 1), because I'm a selfish dude) | 18:32 |
| zyga-phone | perfect | 18:32 |
| ogra_ | (essentially bootcode.bin and the dtb's, the start* files we ship and the fixup* ones we ship need replacing) | 18:33 |
| ogra_ | and make sure to use the latest license files just to be sure they are not out of date | 18:33 |
| ogra_ | hmmmmm .... | 18:34 |
| ogra_ | so i have the livefs builder spit out ubuntu-core snaps now | 18:34 |
| zyga-phone | 0o | 18:34 |
| ogra_ | but cdimage doesnt allow wildcards ... and the snap needs a version string in the name | 18:34 |
| elopio | plars: the list command shouldn't be running the set up suite. | 18:34 |
| ogra_ | tricky | 18:35 |
| elopio | plars: my pr seems to fix the init. So now I'll resurrect the list PR. | 18:35 |
| ogra_ | beuno, does the store care how my snap is named ? or does only the meta/snap.yaml data count ? | 18:36 |
| beuno | ogra_, it totally ignores i | 18:36 |
| beuno | it | 18:36 |
| ogra_ | beuno, so the snap at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54560 could be totally unversioned ? | 18:36 |
| ogra_ | (and the store would happily accept) | 18:37 |
| beuno | ogra_, yeap | 18:37 |
| ogra_ | yay | 18:37 |
| * ogra_ changes the code to rip out the version string ... perfect | 18:37 | |
| ogra_ | so tomorrow we'll have all os snaps on cdimage then :) | 18:38 |
| ogra_ | (and tomorrow evening also the kernel snaps ) | 18:38 |
| beuno | woooo | 18:38 |
| plars | elopio: I can try just cherry-picking it again in a bit, tied up with something else at the moment | 18:40 |
| plars | elopio: ok, I pulled the list fix in and it's getting better: | 19:08 |
| plars | https://www.irccloud.com/pastebin/NhcJ5PrG/ | 19:08 |
| plars | elopio: also, I think the systemctl calls should also be skipped but this is still pretty hacky as it just checks for that file. I need to check on something, but at some point we *have* to set up that file to run the tests. If that happens before we generate the list of tests, then we're back to the original troubles | 19:09 |
| elopio | wesleymason: I see you have the errbot charm. Are you using it somewhere? | 19:17 |
| elopio | plars: yes, we know we shouldn't be doing any calls in init. | 19:18 |
| elopio | the systemclt calls are easy to move, but I need to discuss with Federico because he moved them here first. | 19:18 |
| plars | elopio: sure, np | 19:18 |
| wesleymason | Will be using it in the online services channel when I have chance to build a mojo spec for it. | 19:18 |
| elopio | the others are not so easy. The wait is a workaround, so we could ignore it. | 19:18 |
| elopio | the setup snappy from branch is going to be though, but with this simple if we can push the problem for later. | 19:19 |
| wesleymason | The reactive framework has been both a pleasure and a pain. Like Fifty Shades of Juju. | 19:20 |
| elopio | wesleymason: if you have patience with me while I learn juju, I can help. | 19:20 |
| elopio | I will deploy it in my canonistack to check it out. | 19:20 |
| wesleymason | elopio: after working with juju for so long patience is all I have left ;-) | 19:23 |
| elopio | I accept the challenge leave you without even that! | 19:24 |
| elopio | *to | 19:24 |
| orby | is there a guide on how to secure a snappy core? would like to replace the ubuntu account and switch from dhcp to static. is it the same process as normal ubunutu or is there a specific process to make sure the config sticks? | 19:25 |
| ogra_ | orby, http://paste.ubuntu.com/15329884/ | 19:31 |
| ogra_ | thats a script i use to set up machines | 19:31 |
| orby | ogra_: thank you | 19:49 |
| orby | google dns eh? :) | 19:50 |
| ogra_ | i'm lazy :) | 19:54 |
| orby | what is the correct way to refer to the system, snappy, snappy core, ubuntu core? | 20:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!