=== robert_ancell_ is now known as robert_ancell [08:40] good morning [08:42] hey zyga [08:49] good morning! [08:57] hey :) [08:57] how are you doing [08:57] (zero days since the last terminology change ;) [08:58] put that in the topic :) [09:01] capaskillfaces ! [09:01] ogra_: now you have to read that backwards [09:01] heh [09:02] security imlpementation du jour: "interfaces with reversed plugs, 9,90€ ... kids plate, 6,50€" [09:03] ogra_: uk plugs or us plugs? [09:03] * zyga falls screaming into the abyss [09:03] doesnt matter as long as they are reversed :) [09:03] * ogra_ wishes we would actually care for some stability inseatd [09:04] ogra_: nah, this doesn't affect stability in any way [09:04] ogra_: I'm glad we changed it, it was backwards [09:04] zyga, it occupies dev rtecources [09:04] *ressources [09:05] ogra_: and saves user resources later on [09:05] i still cant use classic on arm64 ... i still can install all gadget snaps from froreign arches [09:05] (on a running system) [09:05] ogra_: well, different resources [09:05] webdm doesnt really work [09:05] etc etc [09:05] ogra_: webdm has tons of love lately [09:05] there are tonms of things that need fixing before release [09:05] ogra_: yeah, I know [09:06] but we are changing terminology of core features instead [09:06] ogra_: we're all working towards getting there [09:06] zyga, by 16.10 ? [09:06] ogra_: 16.04! [09:06] what we have today isnt release worthy yet and still needs liots of work on all levels ... [09:06] ogra_: in reality renames only affected my work [09:08] zyga, and everyone who has snaps in the store [09:08] (or who wants to have them in the store for release) [09:08] ogra_: they didn't use interfaces yet, they will but nothing in the store uses them now [09:09] all my (three yet, because i gave up packaging when there was the announcement) snaps use them with migration-skill [09:09] mmmm, okay, I give you that === zenlot6 is now known as zenlot [09:10] and i have a few more that i had to re-do from scratch three times ... [09:10] for me thats fine, but for people that want their stuff in the store for release it is probably not [09:20] ogra_, hey, I'm late to the party; my 410c boots android and can't make it boot from the sdcard (using your image on p.c.c); any ideas? [09:21] How can i make from my app a service so I can start and stop it with the rest api? [09:26] zyga [09:26] noizer: you'd have to talk to snapd and use an appropriate request, you'd also need an interface to talk to snapd in the first place (I'm making one) [09:26] noizer: a bit busy now, perhaps it's not all ready yet but that's the idea [09:28] hmmm [09:29] noizer: you want snappy services but I'm not sure if that's on the rest api today [09:30] zyga https://developer.ubuntu.com/en/snappy/guides/rest/ [09:34] noizer: always look at docs/rest.md [09:34] noizer: that's the current version [09:34] noizer: this one is probably a few days old [09:35] its the same and there i can see /2.0/snaps/name/services [09:35] https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#20snapsnameservicesname zyga [09:36] sergiusens, did you set the dip switch to SD boot at the bottom of the board ? [09:37] ogra_, no, I searched the manuals/internet for some sort of information about that [09:37] well, make sure that one switch is set to "on" [09:37] else it wont even try the Sd [09:37] ogra_, oh, now that I turn it upside down it is obvious :-P [09:39] ogra_, thanks [09:39] works ? [09:40] ogra_, yeah; well I don't see SElinux anymore and cloud-init instead ;-) [09:40] good [09:41] tell me if the upgrade works .... there are newer kernel and os snaps in the store for it [09:41] sure, let me setup wifi first [09:41] yeah [09:42] one of my cats seems to have had some bad fight tonight, she is pretty injured on one leg, i'll need to go to the vet soon [09:42] (no idea if/when i can return) [09:42] k [09:42] good luck with that [09:43] yeah [09:44] * ogra_ hopes for the best ... seems she can still stand up [09:44] ogra_, oh, that bad [09:44] yeah [09:44] i guess a dog or racoon [09:51] ogra_ do you know how that i can my apps to services. So i can start and stop my services with the REST api [09:52] i saw the mail discussion [10:00] zyga about the python api does i need to take a fork of ubuntu-core/snappy? [10:06] noizer: no, please start with an empty repo [10:06] noizer: that will make it easier to work with on pypi later [10:06] noizer: for releases / qa [10:07] noizer: start with a simple package that has all the public APIs in the client/ package today (use python conventions rather than go conventions for methods though) [10:07] noizer: and we can fill in the blanks, most of the stuff is really easy, you just have to define the input and output format (data is almost always json) [10:08] morning [10:08] o/ [10:09] stupid question: how would one put a binary (actually a shell script wrapper) in the snap package? [10:09] I mean by having this script at the same level as the snapcraft.yaml [10:09] and not cloned as a remote part [10:09] s/cloned/fetched/ [10:10] ysionneau: use a part with source: . [10:10] ysionneau: I use that all the time [10:10] zyga oooh ok. an other question about Services. when is an app a service? [10:10] right, I knew this had a simple solution, thanks!! [10:10] ysionneau: e.g. https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml [10:11] noizer: there are no services, the terminology for that is "all things are apps/applications" [10:11] noizer: some applications run in the background [10:11] ah so I should do a Makefile which will cp my wrapper in $(DESTDIR) ? [10:11] noizer: an application runs in the background if it has an extra line in the snap.yaml / snapcraft.yaml that says how exactly it runs in the background [10:11] ysionneau, you can use the copy plugin [10:11] ysionneau, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml [10:11] ysionneau: you can, there's also some snapcraft plugin for doing just that but I don't remember, would have to refer to snapcraft source code again [10:12] ysionneau, (see what it does with the README) [10:12] awesome, you guyz rock [10:12] ysionneau: but a trivial makefile with the right targets is more scalable if you don't want to remember :) [10:12] thanks ogra_ :) [10:12] makfile will indeed work as well :) [10:12] nothing like good old make [10:12] yes [10:12] * ysionneau likes makefiles [10:13] https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile [10:13] sergiusens: https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile#L3 [10:13] yep I wa son it [10:13] was on* [10:13] sergiusens: small thing I found, snapcraft ignores /usr/local and if your executables are there, it crashes [10:13] zyga why is there then in de REST api some things about services [10:14] noizer: probably legacy [10:14] noizer: we may rename the API [10:14] noizer: for now you can call it a service but most places call it background application already [10:17] zyga oooh ok so if i add something like deamon: simple it will be a background app [10:20] noizer: yes [10:20] zyga ok [10:20] noizer: (we plan to consolidate that naming so expect some changes later today/next week) but yes [10:21] zyga thats no problem it was just confusing xD [10:23] noizer: yep [10:34] Hi all! It's Renat from Screenly=) [10:35] kyrofa, hi! [10:35] I commented in snapcraft's copy plugin pull request. [10:36] I think - that if file is absolute symlink - we should copy it as a symlink. [10:36] renat, might take a bit longer until kyrofa is up [10:38] dholbach, thanks. I will visit later today. [10:59] renat: hey [10:59] zyga, hi! [11:01] zyga can I uses ports within apps because snapcraft says it was unexpected [11:02] noizer: nope, ports was removed [11:02] noizer: it never really did anything [11:02] heheeh xD [11:02] noizer: so it was either removed now (I didn't check) or it's in the queue for removal [11:03] noizer: just don't use it, nothing changes [11:03] zyga ok how can i say to my background app that he may uses some sockets because there i got a permission error? [11:04] noizer: which socket? [11:04] tcp/ip [11:04] zyga [11:05] noizer: do you want to use the network or create a network service? [11:05] noizer: (do you want to be like apache or connect to apache) in less technical terms [11:05] i needed both [11:06] noizer: ok, you need to use two interfaces for that: [11:06] * zyga looks [11:06] noizer: the new names for the interfaces are "network" (you can talk to other things on the network) and "network-bind" (they can talk to you, you can bind to ports, etc) [11:07] noizer: but I think today the only way to use them is to use old-security interface with the names "network-client" and "network-listener" [11:07] i found network-client more intuitive for the first one [11:07] zyga, of all todays, today I can't do irc; prepping for travel here; so a bug or tlaking to kyrofa would be best [11:07] "network" sounds like "globally all network features" [11:07] zyga does i need to use then slots and ect [11:07] noizer: I'll land a lot of interfaces today, but you still need to use the old-security with the images that are out there [11:08] ogra_: "you want to connect to the network" was the rationale [11:08] zyga, sure, but the other options all have suffixes [11:08] so it sounds pretyt global to me [11:08] noizer: you have to use the "slot" but next week that becomes "plug" (you plug old security into your application) [11:09] noizer: https://github.com/ubuntu-core/snappy/pull/580 [11:09] (me shuts up bfore anyone changes any names again) [11:09] noizer: virtues of a development release [11:09] ogra_: I shall name you argo [11:09] ;D [11:09] ogra_: most don't [11:09] ogra_: all the old security bits were modelled after capabilities [11:10] ogra_: and now that each connection has two sides, we can discard half of those in most cases [11:10] dam it is very confusing with all these versions [11:10] ogra_: e.g. mir is just one interface, no mir-client, mir-server [11:10] ogra_: same with docker [11:10] noizer: just wait till monday please [11:10] noizer: it's settling [11:10] zyga, lol [11:10] high hopes [11:10] noizer: we'll make the docs all up to date [11:11] ogra_: I actually like this change a lot, much better than having mir-server being provider by ubuntu-core or kernel snaps [11:11] ogra_: it's just one interface, mir [11:11] (my lol was rather about the "it's settling" ) [11:11] ogra_: you have an app that offers mir slot and many apps that plug into that [11:11] ogra_: (oh, it is, really) [11:11] i belive it when i see it [11:11] ogra_: (we had a three hour meeting yesterday and it was very productive) [11:11] ogra_: very well :) [11:15] zyga will it for now be enough to use this? http://pastebin.com/7sHfGU3Z [11:16] no, "old-security" rather than "migration-skill" [11:16] and also do "network-client" [11:16] (second cap) [11:16] because you need both [11:16] by default snaps are offline [11:24] zyga pfft {'caps': ['network-listener', 'network-client'], 'type': 'old-security'} is not valid under any of the given schemas [11:26] noizer: using snapcraft master? [11:26] i think so [11:26] didrocks [11:26] s/type/interface/ [11:26] (since yesterday late ;)) [11:26] noizer: "interface", not "type" [11:27] thanks didrocks :) [11:27] * zyga works on adding about a dozen new interfaces to snappy [11:37] Mar 4 11:35:33 localhost kernel: [ 114.926577] audit: type=1400 audit(1457091333.026:13): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=1 capname="dac_override" [11:37] Mar 4 11:35:33 localhost kernel: [ 114.926680] audit: type=1400 audit(1457091333.036:14): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=2 capname="dac_read_search" [11:37] hmm [11:37] i guess webdm needs updating :) [11:40] though this is funny since webdm loads the unconfined profile first [11:41] didrocks zyga uses: [11:41] listener: [11:41] interface: old-security [11:41] caps: [network-listener, network-client] [11:41] like that? [11:41] zyga, did the plug<->slot thing make it into edge? [11:41] * sergiusens wonders about releasing a supporting snapcraft [11:42] sergiusens: https://trello.com/c/nUsc10Ra/43-swap-plugs-and-slots-around [11:42] sergiusens: https://github.com/ubuntu-core/snappy/pull/580 [11:42] sergiusens: needs review, then needs release (I have no idea how that works yet though) [11:42] sergiusens: let's work together on coordinating this today [11:42] sergiusens: I'd like to end the week in a stable state [11:43] noizer: looking [11:43] noizer: yep [11:43] noizer: and refer to "listener" from slots in your snap, tomorrow this just changes to "plugs" [11:44] zyga what will be the syntax? [11:45] noizer: look at existing examples [11:45] noizer: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webchat/snapcraft.yaml [11:45] noizer: tomorrow we just swap slots/plugs around [11:46] noizer: and next week, old-security can be somewhat replaced by native interfaces: [network, network-bind] [11:47] noizer: I'll announce it when it can be used [11:47] ogra_: this should solve that: ttps://code.launchpad.net/~stevenwilkin/webdm/skill-to-interface-snap-yaml/+merge/287760 [11:47] noizer: snapcraft examples are the best way to learn :) [11:47] s/ttps/https/ [11:47] stevebiscuit, ah, cool [11:47] i'll just wait [11:48] oh, crap [11:48] the generic initrds are gzip compressed [11:49] zyga ok i still got an error but i am using snapcraft 2.3.2 is that not update to date? [11:49] noizer: I'm not sure [11:50] noizer: what did you exactly do and what the error was? [11:50] zyga Issues while validating snapcraft.yaml: Additional properties are not allowed ('slots' was unexpected) [11:54] noizer: o_O not sure, ask sergiusens, maybe your snapcraft is out of date [11:54] noizer: check if you can build the example I linked to [11:54] * zyga -> back to hacking [12:01] oh crap ! [12:01] pitti, so my initrd now ends up with a /lib64 dir [12:01] with the linker in it [12:01] which results in non executable binaries [12:05] yeah, moving the linker to /lib fixes it :( [12:06] argh [12:06] except ... [12:06] Begin: Running /scripts/local-premount ... wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory [12:06] wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory [12:06] damned [12:07] zyga, we never landed that [12:07] zyga, we are going to land 7 breaking changes in a row, sorry [12:08] sergiusens: 7? [12:08] I'm not the only one to fight against dynamic linker issues [12:10] ysionneau, well, i'm rather fighting fakechroot here [12:10] bug 1553110 [12:10] bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110 [12:10] ah ok [12:11] ogra_: /lib64/*ld.so* should/could just be a symlink to /lib [12:11] ogra_: that's at least how it is on amd64 [12:11] pitti, well, indeed it isnt beacuse i hacked the outer script to just have /lib64 ... whats more worrying though is that libudev doesnt end up in the initrd at all now [12:12] pitti, for the linker there is a hack in mkinitramfs for armhf already that we likely need to copy for arm64 [12:12] zyga, I was being sarcastic; I was about to release yesterday but with this change cancelled the release completely [12:12] it had a similar prob [12:12] it makes no sense to promote something that is going to be inverted [12:12] but that doesnt explain the missing libudev [12:13] I'd just tell people to use ubuntu-core/stable [12:13] ogra_, I am almost there with the logic for this :-) [12:13] sergiusens, i guess all but arm64 should work [12:14] pitti, see line 337 ff in /usr/sbin/mkinitramfs [12:14] not actually lib64 ... but the same issue [12:14] ogra_, oh I did see a lib64 in amd64's generic initrd and jumped to conclusions [12:15] with an ld symlink too [12:15] symlink ? [12:15] ogra_: so I guess it'd be best to actually fix fakechroot instead of adding further hacks [12:15] there shouldnt be one [12:15] pitti, hmpf [12:15] ogra_, $ ls -l lib64/ [12:15] total 0 [12:15] lrwxrwxrwx 1 sergiusens sergiusens 34 mar 4 06:46 ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-2.21.so [12:15] amd64 *should* and even *must* have a /lib64 [12:15] amd64 vs. arm64 confusion? :-) [12:15] pitti, i thought colin said it shouldnt [12:16] no, he said we shouldn't proliferate that to other arches like arm64 [12:16] pitti, nah; I was going by ogra's symptoms, not saying anything is wrong or right [12:17] pitti, well, not even debootstrap creates lib64 on arm64 atm [12:17] right [12:17] I thought you just created it as workaround for that fakechroot thingy [12:17] yeah [12:17] and that works fine ... for everything but wait-for-root [12:18] so maybe create the /lib64 symlink, do the fakechroot bootstrap, and remove it again before building the image? [12:18] s/image/initrd/ [12:18] you mean hacking up update-initramfs ? [12:18] the place where you added it doesn't have code which runs after the initrd build? [12:18] rpi3 arrived [12:18] hmmm [12:18] no [12:19] well, it doesnt have code that runs "inside" the initrd [12:19] thats all left up initramfs-tools hook scripts [12:19] i'm just modifying the build chroot to have the dir [12:20] ogra_: perhaps try wiht a /lib64 -> /lib symlink? [12:20] instead of a symlink or even a copy *in* /lib64/ ? [12:23] pitti, will do, but i doubt that will fix the missing libudev [12:23] i can indeed forcefully copy it in place with a hack-hook or some such [12:24] still ... not cool :( [12:26] zyga I need to upgrade my snapcraft what is the best way to do that? [12:28] noizer: please wait, we're trying to figure out when to release a compatible set of tools for everyone to use so that no confusions are spread [12:29] ok so i need to do nothing today on that? [12:29] noizer: soon you should have all the bits in master but we need to release them to make sense [12:30] zyga: ok how long does I need to wait for that? [12:30] noizer: most likely on monday, we'll decide [12:30] and announce this [12:31] OK [12:39] Good morning [12:55] pitti, hmm, isnt libudev also a thing that udevd should pull into the initrd [12:55] * ogra_ still doesnt get why it is missing ... copying it in manually makes everything work [12:56] (including the udevd that is in the initrd) [12:56] oh, wow [12:56] ogra@anubis:~/datengrab/dragonboard/all-snaps$ ldd $(which udevd)|grep udev [12:56] ogra@anubis:~/datengrab/dragonboard/all-snaps$ [12:57] so it isnt linked against the lib at all ... interesting [13:05] WTF ! [13:05] so libudev isnt in any of the initrds [13:06] * ogra_ wonders whats going on here [13:10] Hi folks [13:12] I am currently trying to ensure that I am working on porting snappy core to a new board. [13:12] I am trying to get it to give me output via the serial console on booting up [13:12] anyone know where I can do that from as I can not see a grub.cfg file in boot->grub [13:20] ogra_: right, udevd isn't meant to link against libudev, it uses an internal (richer, but unstable/non-public) API [13:20] yeah [13:20] i still dont get why the lib isnt in any of the inirds [13:21] ogra_: I suppose the only thing that needs libudev in the initrd nomrally is wait-for-root [13:21] on all arches [13:21] yeah [13:21] $ lsinitramfs /initrd.img |grep libudev [13:21] lib/x86_64-linux-gnu/libudev.so.1.6.4 [13:21] right [13:21] it isnt in any that my script built [13:21] ogra_: fakechroot b0rkage? [13:22] (i'm 100% sure it is in the phone initrds, else they wouldnt boot at akll) [13:22] the script is the same ... as is the build process [13:23] i just uploaded a test version with libfakeroot and libfakechroot in the build chroot ... lets see if that changes anything [13:23] (they will end up inside the initrd though ... which i was wanting to avoid) [13:23] ogra_: uploaded? I thought you have access to an arm64 instance to do local test builds [13:24] (I can give you one if you need) [13:24] i do, but uploading is faster :) [13:24] well.. [13:25] erm…lost connection..did anyone say anything with regards to my last post [13:31] ok, adding the t6wo libs didnt change a thing [13:31] (apart from quietening the build log) [13:32] pitti, did we ever find out what actually copies wait-for-root ? [13:32] i cant find a hook for it [13:33] ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/share/initramfs-tools/* [13:33] /usr/share/initramfs-tools/scripts/local: FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-$ARCHDELAY}) [13:33] /usr/share/initramfs-tools/scripts/local-premount/resume:SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5}) [13:33] aha [13:33] ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/sbin/mkinitramfs [13:33] copy_exec /usr/lib/initramfs-tools/bin/wait-for-root /sbin [13:34] * ogra_ bets if he adds that to some hook it will actually DTRT [13:34] ogra_: I don't think it's in a hook, it should be copied by the i-t core code [13:34] ogra_: right, that [13:34] yeah, it is hardcoded in /usr/sbin/mkinitramfs [13:35] let me try making it a hook, just for fun :) [13:36] beuno, if I want to ship a device with some custom kernel modules, I make a kernel snap (I assume). I make a snap to utilize those new modules, and upload it to the store. Is there anything preventing someone else (who doesn't have my kernel snap) from installing that snap which then breaks for them? [13:37] kyrofa, hi! [13:37] yes, interfaces! [13:37] beuno, ahh, okay [13:37] your kernel would expose interfaces for those special modules [13:37] would it ? [13:38] even if the user simply uses snappy config ubuntu-core and force-loads them ? [13:39] kyrofa, your user would have to actually create an image using u-d-f ... you can load different kernel snaps [13:39] * ogra_ tried that already [13:39] "a snap of this name is already installed" [13:39] ;) [13:39] ogra_, interesting, okay [13:40] (err: you can *not* load) [13:42] kyrofa, i dont see where interfaces come into play for modules though, but beuno might know more than I [13:42] (i mean, beyond the obvious .... accessing devices under /dev) [13:43] ogra_, I assume it would be more of a "the current kernel doesn't provide a slot for this interface, so I can't plug into it" [13:43] ogra_, you expose an interface the exposes a funcionality you don't have otherwise [13:43] right [13:43] so you can filter on it, etc [13:44] Yeah that makes sense. Even if the interface provided nothing other than the filter [13:44] Thanks beuno , ogra_ :) [13:44] beuno, right, but the module would load regardless, it is only the device access you block [13:45] (so my in-kernel-keylogger.ko would still work ;) ) [13:45] correct [13:45] ogra_, right, I was really only wondering if it was possible to upload a snap to the store that requires a custom kernel snap to run [13:45] That didn't break for everyone else [13:49] kyrofa, does it sound like a good answer to your problem? [13:49] beuno, indeed it does, thank you! [13:49] w00t [13:58] hmm, nope ... moving wait-for-root to an actual hook doesnt change anything [13:58] sigh... this is so painful [13:59] pitti, any idea what to look for in fakechroot to make it actually work ? [14:00] ogra_: not off-hand -- I'd start with stracing "fakechroot ldd" call (with -e trace=file) and see where things go haywire [14:01] hmm, k [14:01] * ogra_ will have to prepare for the vet now ... i'll try that later [14:07] zyga ogra_ < about my yesterday dynamic linker issue, now it's fixed. I added some post-processing in my alchemy snapcraft plugin so that it creates wrappers for each detected ELF dynamic executables in installdir [14:07] now it does not crash anymore o/ [14:07] yay [14:07] I should push my alchemy plugin someday when it's a bit cleaner on my github [14:07] so that people could experiment doing cross compilation of snaps [14:15] ysionneau: oh, I wasn't aware of what you were doing [14:15] ysionneau: I think this will open a lot of very nice use cases [14:17] ysionneau: so you're working on what exactly? generic cross compiler support? [14:19] I'm adding a plugin for snapcraft to support "alchemy" build system (which is some kind of buildroot/Android-build-system on steroid) [14:19] instead of Android.mk it uses atom.mk [14:19] https://github.com/parrot-developers/alchemy [14:20] ysionneau: is parrot-developers there referring to perl6 parror vm? [14:20] * zyga wonders how that's all interconnected [14:20] parrot* [14:20] the interesting fact for snapcraft is that it would allow to generate arm32/64 snaps from your amd64 machine (cross compilation) [14:20] nop it's referring to Parrot SA [14:20] ah [14:20] a French company [14:20] just ENOGOODFREENAMES [14:20]