| === chihchun_afk is now known as chihchun | ||
| sergiusens | ogra_, any ideas about http://paste.ubuntu.com/15333155/ ? | 06:21 |
|---|---|---|
| sergiusens | ah missing firmware | 06:28 |
| dholbach | good morning | 07:26 |
| zyga-phone | Good morning | 07:52 |
| didrocks | hey zyga-phone | 07:54 |
| zyga-phone | :-) | 07:59 |
| ogra_ | sergiusens, https://launchpad.net/~p-pisati/+archive/ubuntu/embedded you want dragon410c-firmware | 08:13 |
| sergiusens | ogra_, yeah, thanks, I figured it out 6 minutes after pinging you (like in the message) | 08:18 |
| ogra_ | :) | 08:18 |
| sergiusens | ogra_, I grabbed from upstream though | 08:18 |
| sergiusens | https://developer.qualcomm.com/hardware/dragonboard-410c/tools | 08:18 |
| ogra_ | well, the package has the filesystem structure, which is why i prefer it | 08:19 |
| ogra_ | just a dpkg -x *deb /target/dir is enough ... i dont need to bother where the files go | 08:19 |
| sergiusens | ogra_, right, the upstream stuff just needs to get dumped in lib/firmware | 08:20 |
| ogra_ | yep | 08:20 |
| sergiusens | ogra_, I'll be sending out an email later today | 08:21 |
| sergiusens | once the demo stuff is done I can focus on releasing a snapcraft with that interfaces swap | 08:21 |
| ogra_ | :) | 08:21 |
| didrocks | dholbach, davidcalle: any time to HO and try the new template + content import? :) | 09:05 |
| dholbach | didrocks, maybe some time after lunch? | 09:06 |
| === chihchun is now known as chihchun_afk | ||
| davidcalle | didrocks: dholbach: anytime wfm | 09:07 |
| didrocks | dholbach: davidcalle: 2:30PM? | 09:07 |
| dholbach | sure | 09:07 |
| davidcalle | +1 | 09:08 |
| didrocks | invitations sent! | 09:09 |
| noizer | Goodmorning | 09:10 |
| * zyga-phone throws more branches out | 09:24 | |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/621 | 09:24 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/618 | 09:24 |
| zyga-phone | https://github.com/ubuntu-core/snappy/pull/620 | 09:24 |
| zyga-phone | and a biggie: https://github.com/ubuntu-core/snappy/pull/617 | 09:25 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | mvo, hey, so looking at kernel snaps from livecd-rootfs i'm wondering what we do with azure | 10:06 |
| ogra_ | (today thats just a cp of the amd64 tarball iirc, for snaps we cant really do that since it will need different meta data .... should azure use the normal amd64 one or should i produce a *.azure.kernel.snap separately ?) | 10:08 |
| dpm | mvo, quick question on your e-mail to snappy-devel: "3. The icon location has changed - It is now in meta/gui/icon.png instead of meta/icon.png". So far I've specified the icon location in snapcraft.yaml, so I'm not sure what effect that has for snaps that specify a particular path to the icon. Or is this just the default location icons will be searched for if they're not specified in snapcraft.yaml? | 10:36 |
| mvo | dpm: if you use snapcraft it will take care of everything for you | 10:39 |
| mvo | dpm: at least that is my understanding unless sergiusens_ corrects me :) | 10:40 |
| dpm | mvo, I'm not sure I understand it at all. My icon lives in the upstream code under app/icon.png, and that's what I specify on snapcraft.yaml. So do I need to do any changes to snapcraft.yaml or the icon location in the tree after the latest snappy changes? | 10:41 |
| dpm | e.g. http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snapcraft.yaml | 10:41 |
| noizer | how does security-overide works? | 10:43 |
| sergiusens_ | dpm, mvo that's not landed yet | 10:44 |
| sergiusens_ | won't happen this week at least | 10:44 |
| sergiusens_ | this week it is all about the kernel | 10:44 |
| dpm | sergiusens_, thanks. So when it lands, are there any changes that need to be done to that snapcraft.yaml file? ^^ | 10:47 |
| sergiusens_ | dpm, none | 10:48 |
| dpm | ok, cool, thanks | 10:48 |
| dpm | sergiusens_, mvo, another question related to the announced change of the snap startup directory is now $SNAP_DATA instead of $SNAP: I'm using the copy plugin to install a config file with a relative path: http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snapcraft.yaml#L30 | 10:51 |
| dpm | The file itself is http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snappy-qt5.conf | 10:51 |
| dpm | so I guess I'll now have to change the ./ path to $SNAP explicitly on the config file | 10:52 |
| dpm | is there any plugin to do variable replacements in files specified in snapcraft.yaml? Or a simpler way to do it? | 10:52 |
| sergiusens_ | dpm, instead of bin/calculator do 'calculator' or '$SNAP/bin/calculator' | 10:55 |
| * zyga-phone triest to implement the first manager in the overlord | 10:55 | |
| dpm | sergiusens_, thanks. So just that change and the .conf file can stay as it is with its ./relative path? | 10:56 |
| ogra_ | mvo, did you see my ping abov ? | 11:12 |
| ogra_ | *above | 11:12 |
| mvo | ogra_: sorry, I did not | 11:15 |
| ogra_ | <ogra_> mvo, hey, so looking at kernel snaps from livecd-rootfs i'm wondering what we do with azure | 11:15 |
| ogra_ | <ogra_> (today thats just a cp of the amd64 tarball iirc, for snaps we cant really do that since it will need different meta data .... should azure use the normal amd64 one or should i produce a *.azure.kernel.snap separately ?) | 11:15 |
| mvo | ogra_: hm, I think azure need no special handling anymore but ben howard will know for sure | 11:17 |
| ogra_ | ok, i'll leave that out for now | 11:17 |
| ogra_ | mvo, btw http://paste.ubuntu.com/15333996/ ... is what i have so far | 11:18 |
| * ogra_ will do a test build soon | 11:18 | |
| ogra_ | oops ... just noticed an error | 11:19 |
| mvo | ogra_: nice | 11:20 |
| === chihchun is now known as chihchun_afk | ||
| noizer | ogra_: Do you know more about the apparmor? | 12:27 |
| === chihchun_afk is now known as chihchun | ||
| === devil is now known as Guest30973 | ||
| ogra_ | noizer, not really | 12:29 |
| noizer | ogra_: Do you know somebody that have more experience? | 12:29 |
| ogra_ | jdstrand for example | 12:30 |
| noizer | ogra_: Do you have any clue when he will be available? | 12:30 |
| ogra_ | nope | 12:30 |
| === Guest30973 is now known as devil_ | ||
| ogra_ | (if you just dump your question in the channle probably someone else can answer ... dont be so tied to specific persons ;) ) | 12:32 |
| ogra_ | channel | 12:32 |
| noizer | ok xD | 12:33 |
| noizer | I'm making a snap that doesn't need to be available in the store. This snaps needs to be able to start (execute an other snaps wrapper) an other snap. So I thought to change the AppArmor a little. But i got some issue about this. Can anyone help me out with it? | 12:34 |
| * ogra_ wonders why the arm64 builders seem to work at half speed today | 12:42 | |
| zyga-phone | noizer: not today, I'm deep in integrating skills with the system | 13:13 |
| beuno | ogra_, maybe someone needs to press the Turbo button? | 13:14 |
| ogra_ | haha | 13:14 |
| ogra_ | beuno, well, seems the build is jumping between bare metal and scaling stack ... seems a build on the latter takes abotu 1h while on the former it taks between 20-30min | 13:15 |
| noizer | zyga-phone: No problem i will try further | 13:31 |
| ogra_ | zyga-phone, skills ? | 13:36 |
| zyga-phone | ogra_: you caught me :) | 13:36 |
| * ogra_ prepares mail announcing the new name change :P | 13:36 | |
| zyga-phone | ogra_: no it's not renamed | 13:36 |
| zyga-phone | ogra_: interfaces | 13:36 |
| zyga-phone | ogra_: just stale cache in my head | 13:36 |
| ogra_ | week is over ... new name imminent | 13:36 |
| ogra_ | snappy security ... best before: next week | 13:37 |
| ogra_ | :P | 13:37 |
| ogra_ | utlemming, yo | 14:23 |
| ogra_ | utlemming, do the cloud images already use all-snaps (asking because we currently treat azure images special on the image builders and i'd like to know what to do ... specifically for the former device tarball (now kernel.snap) ) | 14:26 |
| utlemming | ogra_: the cloud images do not use all-snaps | 14:28 |
| ogra_ | utlemming, oh ? how will they work in xenial then (system-image isnt supported anymore) | 14:28 |
| ogra_ | do we drop snappy in the cloud for xenial ? | 14:29 |
| utlemming | ogra_: the work to do that has not been scheduled | 14:29 |
| ogra_ | heh, well, 5 weeks to release ... :) | 14:30 |
| utlemming | ogra_: ack, understood | 14:30 |
| ogra_ | (and PPAs arent allowed anymore ... changes would have to be SRUed ... i assume you know what pain that can be) | 14:30 |
| ogra_ | WHEEE ! | 14:35 |
| ogra_ | livecd.ubuntu-core.raspi2.kernel.snap livecd.ubuntu-core.os.snap livecd.ubuntu-core.kernel.snap | 14:36 |
| ogra_ | https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54636 | 14:36 |
| ogra_ | :D | 14:36 |
| ogra_ | now to teach cdimage to publish that to cdimage.ubuntu.com | 14:39 |
| ogra_ | hmm, and perhaps i shoul dbuild a test image from these snaps :) | 14:40 |
| noizer | is it possible that the security-override doesn't works? | 15:44 |
| dpm | mvo, so I updated http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/view/head:/snapcraft.yaml and built it with snapcraft trunk, which succeeded. But upon installation, there seems to be some issues finding the qmlscene binary. I'm not sure there is any path changes that might have happened behind the scenes | 15:45 |
| dpm | $ ubuntu-clock-app.clock | 15:45 |
| dpm | qmlscene: could not exec './usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene': No such file or directory | 15:45 |
| dpm | That's the output of the newly built and sideloaded app now ^ | 15:45 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | dholbach, anything on the agenda ? | 15:51 |
| jdstrand | noizer: things are always possible, especially lately with all the code and yaml updates. do you have a specific question? | 15:53 |
| dholbach | ogra_, I'll move the call to another time for next week - it clashes with our community team meeting | 15:53 |
| dholbach | so better let's chat next week | 15:53 |
| jdstrand | dpm: use $SNAP/... instead of ./ | 15:53 |
| ogra_ | dholbach, ok, sounds good | 15:53 |
| jdstrand | they changed the working directory recently | 15:54 |
| jdstrand | dpm: or, 'cd $SNAP' | 15:54 |
| jdstrand | before hand | 15:54 |
| noizer | jdstrand: Yes ok I will make a snapp thats not be available in the store. So I want to that the app can execute the binaries from /snaps/bin/. So then can he acces other snaps. | 15:55 |
| jdstrand | noizer: that isn't possible | 15:55 |
| noizer | jdstrand: So i tought i will do some changes on the apparmor so a can execute these snaps. | 15:55 |
| dpm | jdstrand, but the "./" appears on a .conf file. I'm not sure how to do variable substitution there | 15:56 |
| jdstrand | the reason why is /snaps/bin are shell scripts that call the launcher, which needs priviliges to set up the sandbox. those privs can't be granted to apps | 15:56 |
| jdstrand | dpm: then do a cd $SNAP | 15:56 |
| jdstrand | dpm: I can't really advise how to implement the fix, I'm just saying that people decided to change the working directory and your snap need to do something about that | 15:57 |
| dpm | I'm a bit lost to what I need to do here, just cd $SNAP in the wrapper script? (I appreciate the help, thanks jdstrand!) | 15:58 |
| jdstrand | dpm: yes | 15:58 |
| jdstrand | dpm: right at the top of your script | 15:58 |
| jdstrand | dpm: fyi, 'Subject: Internal format updates' on snappy-devel. in addition to the working directory it talks about icon and desktop | 16:02 |
| noizer | jdstrand: how can i make it possible then? | 16:03 |
| dpm | jdstrand, yeah, that's why I started doing the changes | 16:03 |
| ogra_ | mvo, http://paste.ubuntu.com/15335324/ whats that "Removing unneded" message about ? (do i need to worry ? ) | 16:05 |
| ogra_ | the resulting image boots fine | 16:05 |
| jdstrand | noizer: it is only going to be possible if you do security-policy and have a very lenient profile, but this is going against how snappy works. typically, you bundle what you want in one snap. it is possible to do stuff with frameworks on 15.04, but frameworks are going away in favor of interfaces. the interfaces work is very much still being worked out, but at some point there will be a way for you to approach Canonical for new interfaces and then C | 16:06 |
| mvo | ogra_: hm, that looks a bit scary. image boots and has all the snaps you expect it to have? | 16:08 |
| ogra_ | mvo, yeah | 16:08 |
| ogra_ | mvo, the snaps are from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54634 | 16:08 |
| mvo | ogra_: aha, I do remember now, its fine | 16:08 |
| ogra_ | cool ! | 16:08 |
| mvo | ogra_: sorry, its a misleading message | 16:08 |
| ogra_ | then the livecd-rootfs built snaps all work :) | 16:09 |
| mvo | ogra_: \o/ | 16:09 |
| ogra_ | cdimage publishing pending :) | 16:09 |
| noizer | jdstrand: so it will be possible in the future? but can I have now the solution because then i can test further with my code. | 16:11 |
| noizer | jdstrand: I know its not how snappy works but it would be awesome for me that i would make 1 snap with some other priviliges. | 16:14 |
| ogra_ | you can surely make a completely unconfined snap and sideload it | 16:15 |
| noizer | ogra_: how can i do that? | 16:18 |
| elopio | ping ogra_: what triggers this? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image | 16:19 |
| elopio | an update in the PPA? | 16:19 |
| ogra_ | noizer, not sure how you do it in this weeks seciroty model ... two weeks ago i could do http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml | 16:20 |
| ogra_ | elopio, a cron job on "nusakan" (which is what outsoders know as cdimage) | 16:20 |
| ogra_ | *outsiders | 16:21 |
| elopio | ogra_: awesome. That is solving half of the unknowns I had :D | 16:21 |
| ogra_ | elopio, well, or a manual call from a member of the cdimage team (like i did a few yesterday and today tomake the new snap bild code work) | 16:21 |
| jdstrand | ogra and nozier: with ogra_'s example, do 's/uses/plugs/' and 's/type: migration-skill/interface: old-security/' | 16:22 |
| ogra_ | jdstrand, thanks ! (saves me from looking it up) | 16:22 |
| elopio | ogra_: cron is alright. A url we can trigger would be even better, but nothing to worry about now. We hope to have solved the dput into the ppa by friday. I'll get back to you after. | 16:23 |
| ogra_ | elopio, if you clock on one of the last "Successfuly built" links you now find os and kernel snaps there | 16:23 |
| noizer | jdstrand: ogra_ huh i don't understand it very good | 16:23 |
| ogra_ | *click | 16:23 |
| ogra_ | (note "last" means at the top) | 16:24 |
| elopio | ogra_: yes, that's what I saw and that's why I'm happy. | 16:24 |
| elopio | thank you. | 16:24 |
| jdstrand | noizer: every place you see 'uses' in ogra_'s example, use 'plugs' instead | 16:24 |
| ogra_ | elopio, i currently work on making them show up on http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ... and then hope the store can pull them into the edge channel from there | 16:25 |
| jdstrand | noizer: and every place you see 'type: migration-skill', use 'interface: old-security' instead | 16:25 |
| elopio | ogra_: we can pull them from jenkins, and push them from there too. I'm not sure what's best yet. | 16:25 |
| jdstrand | mvo: is this cause for concern: http://paste.ubuntu.com/15335485/ | 16:28 |
| ogra_ | elopio, well, i like the idea that you could manually pull them from cdimage and test them ... its our canonical place for all official image fragments | 16:28 |
| noizer | jdstrand: just a stupid question whats de difference between slots and plugs | 16:29 |
| * jdstrand wonders why we are so emphatic with the developer ("canonical!") | 16:29 | |
| jdstrand | noizer: one is the providing side and one is the consuming side | 16:29 |
| jdstrand | you provide a slot for a plug | 16:29 |
| elopio | ogra_: I think I like that too. The only detail I'm thinking about is beta. I think that if we put the better tested beta in that daily folder, the testers would get a better experience than with edge. | 16:29 |
| ogra_ | elopio, i dont really care how they get into the store after this :) but we need them in the store to test upgraeability (snappy refuses to upgrade sideloaded packages) | 16:30 |
| elopio | but we can adjust everything. | 16:30 |
| jdstrand | ths os provides the old-security interface as a slot that apps may plug into | 16:30 |
| elopio | we have all this blocks, it's easy to move them around. | 16:30 |
| ogra_ | yeah | 16:30 |
| jdstrand | noizer: see the snappy-devel mailing list for more info | 16:30 |
| jdstrand | noizer: but my summary is hopefully good enough | 16:31 |
| noizer | jdstrand: an unconfined app i cant execute then the snaps/bin executables :s | 16:31 |
| jdstrand | using the 'unconfined' template won't give you enough cause you need to be able to change profiles, etc | 16:32 |
| elopio | ogra_: we are testing upgradeability with a fake store and a fake snap. That was really cool by mvo. | 16:32 |
| elopio | We do need to test real updates and we have all the jobs ready, so yes, we need to upload to the store. But that's my least concern, we are already uploading snaps in the snapcraft suite (also a cool thing by pindonga). | 16:32 |
| jdstrand | you need security-policy with unrestricted seccomp and lenient policy. you would need to look at /etc/apparmor.d/usr.bin.ubuntu-core-launcher for some of the perms | 16:33 |
| jdstrand | fyi, this isn't the proper way to do things-- you're going to be quite on your own here | 16:33 |
| ogra_ | elopio, hmm, i thought we'd now work by store channels only ... | 16:33 |
| noizer | jdstrand: then i can change some profiles from seccomp and apparmor? | 16:36 |
| jdstrand | noizer: you do something like this | 16:37 |
| jdstrand | plugs: | 16:37 |
| jdstrand | "my-confinement": | 16:37 |
| jdstrand | interface: old-security | 16:37 |
| elopio | ogra_: well, not only. We can't upload the snap from pull requests to the store because they will be generally broken and conflicting and confusing. At that stage, we fake. | 16:37 |
| jdstrand | apparmor: path/to/apparmor/profile | 16:37 |
| elopio | once we land into master/edge, we test the real thing. | 16:37 |
| jdstrand | seccomp: path/to/seccomp/profile | 16:37 |
| beuno | elopio, ogra_, so, apps that are uploaded but not published to any channel are accessible by specified users | 16:38 |
| beuno | you can CI it in every real sense without putting it in a channel | 16:38 |
| elopio | beuno: that's interesting. | 16:38 |
| jdstrand | noizer: put @unrestricted in path/to/seccomp/profile, and then adjust path/to/apparmor/profile to be what you want. you might start with what is in /usr/share/apparmor/easyprof/templates/ubuntu-core/16.04/unconfined | 16:39 |
| elopio | beuno: are we going to be able to select a channel or not channel from snapcraft upload? | 16:39 |
| beuno | elopio, getting a snap into the store involves 2 steps: upload & publish | 16:39 |
| beuno | when you upload, you get back a revision which makes it accessible if you have upload rights to the snap | 16:40 |
| jdstrand | noizer: if you ignore the package.yaml stuff in this page, there are things that might help: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy | 16:40 |
| beuno | publishing is what actually makes it distributable via a channel | 16:40 |
| jdstrand | noizer: at this point, you are far outside the snappy system and I've got to focus on the snappy system atm. good luck! | 16:40 |
| noizer | jdstrand: hahah ok thx. but why can people start services and stop services from any snap they want with a REST api? | 16:41 |
| jdstrand | noizer: because that breaks application isolation. apps aren't supposed to be able to mess with other snap's apps | 16:42 |
| elopio | beuno: ok, I'll check again. So, no snapcraft publish command? We'll have to go to the URL. | 16:42 |
| beuno | elopio, snapcraft still needs to grow the publish command, yes | 16:43 |
| jdstrand | noizer: this isn't a reimplementation of the traditional linux distro, this is a new way of doing things | 16:43 |
| elopio | great, that's even better :) | 16:43 |
| jdstrand | noizer: you are free to stop and start your own services of course. the snap rest api may provide things for stopping and starting services. you might talk to Chipaca on if it does | 16:43 |
| elopio | sudo snappy service ... | 16:44 |
| jdstrand | noizer: if the snappy rest api allows for that, you can use: | 16:44 |
| jdstrand | interface: old-security | 16:44 |
| jdstrand | caps: [snapd] | 16:44 |
| * jdstrand notes that old-security/caps is going away soon in favor of native interfaces | 16:45 | |
| noizer | jdstrand: but is it possible then to say to the service that he don't start while booting | 16:45 |
| jdstrand | noizer: I don't think so, no | 16:45 |
| jdstrand | maybe | 16:45 |
| noizer | jdstrand: when this is possible i can start an application over services | 16:45 |
| * jdstrand didn't design or implement the snappy rest api | 16:45 | |
| ogra_ | beuno, elopio, well, we are talking about image testing ... so i guess ubuntu-device-flash will be involved ... i'm not sure it can currently deal with unpublished snaps apart from treating them as sideloaded | 16:46 |
| ogra_ | i know it can download from edge if i pass /edge to the snap name though | 16:47 |
| elopio | ogra_: I'm sorry, I'm talking about everything at once. | 16:47 |
| ogra_ | but then the snap has already been published to the edge channel | 16:47 |
| elopio | in particular, this unpublished thing is great to test the snapcraft examples. But I might find it useful in the snappy suite to. | 16:47 |
| elopio | too | 16:47 |
| ogra_ | elopio, right, my focus is more on images currently :) | 16:47 |
| elopio | ogra_: I know. That's why I'm not yet with you. Figuring out the earlier steps first. | 16:48 |
| ogra_ | well, snapcraft wont be involved in our image builds | 16:48 |
| ogra_ | (the builder doesnt really have access to the outside world beyonf the ubuntu archive) | 16:49 |
| ogra_ | (on purpose) | 16:50 |
| elopio | ogra_: that's the part we need to figure out where to put. I want that a new OS snap is published to beta only if all the snapcraft examples pass on it. | 16:50 |
| elopio | we don't need to generate an image for this tests | 16:50 |
| ogra_ | how else would you use the os snap if not in an image ? | 16:50 |
| elopio | we will generate it only if the tests pass and the snap is promoted to a higher channel. | 16:51 |
| ogra_ | mount the squashfs and chroot ? | 16:51 |
| ogra_ | you kind of need to test the os snap in context (if the initrd doesnt set up your bind-mount farm to get you writable bis you cant boot etc etc) | 16:52 |
| elopio | ogra_: hah, three possible tricks. The one we are using now is just calling a different snappy binary, not installed. The second option is to build the snap and get it installed through the fake store, or something. The third would be to generate our own image with udf and upload it to scalingstack, but I'm trying to avoid this one. | 16:52 |
| ogra_ | i cant imagine how to test that without at least generating an imge and boot it in a VM or some such | 16:52 |
| ogra_ | elopio, i think the last one is the only valid one ... else you will never test in real context | 16:53 |
| ogra_ | you need to knwo the boot process works, the env is correct after booting and ... well, then test the binaries etc | 16:54 |
| elopio | ogra_: remember that I'm this week on the early stages. The focus is to test the snappy commands they are adding to the master branch, not the bootloader or the kernel. | 16:54 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | ah, so only the snappy binary itself ... ok | 16:54 |
| elopio | we have jobs in place to test the whole image in later stages. We need to add more coverage there, but we have a basic verification in place. | 16:54 |
| ogra_ | i thought you meant the os snap | 16:54 |
| elopio | yes, I excused myself because I'm throwing all the topics at once. | 16:55 |
| elopio | for this week, the least context and most isolation we can get, the better. | 16:56 |
| ogra_ | heh, i'm just slow in understanding today :) | 16:56 |
| ogra_ | to much cdimage code in my brain for the last two days ... that does weird things to you | 16:56 |
| noizer | Chipaca is it possible to disable starting on boot a service? | 16:57 |
| Chipaca | noizer, deactivate the snap? | 16:58 |
| elopio | weird is the new cool. | 16:58 |
| elopio | I'm happy not looking at cdimage though. | 16:58 |
| noizer | Chipaca no no the app needs to be active but services (background-app) start automatically | 16:58 |
| Chipaca | noizer, disable the service then | 16:59 |
| noizer | can i start it later? | 16:59 |
| Chipaca | noizer, or stop shipping it, if you don't want it to run :-) | 16:59 |
| Chipaca | noizer, 15.04, or 16? | 16:59 |
| noizer | Chipaca no i want to start it later with the REST api | 16:59 |
| noizer | Chipaca it is 16 | 16:59 |
| Chipaca | noizer, enable/disable using the rest api | 17:00 |
| Chipaca | noizer, e.g., http.POST snapd:///2.0/snaps/snap.mine/services/a-service action=disabe | 17:01 |
| Chipaca | noizer, using http.chipaca | 17:01 |
| Chipaca | disable* | 17:01 |
| Chipaca | noizer, that'll probably change before 16 GA, moving to not need the .mine there | 17:02 |
| Chipaca | noizer, enabling is with action=enable, obvs | 17:03 |
| noizer | Chipaca hmmm can i init that so thats disabled by default? | 17:04 |
| Chipaca | noizer, no | 17:04 |
| noizer | Chipaca ok | 17:04 |
| noizer | Chipaca Thx for the help | 17:04 |
| Chipaca | noizer, if you need that feature, file a bug? but we're all full of things to do for 16 so i doubt we'd be able to do it any time soon | 17:05 |
| noizer | Chipaca ok or maybe make it myself? | 17:06 |
| === jkridner|work is now known as jkridner_ | ||
| === jkridner_ is now known as jkridner__ | ||
| === jkridner__ is now known as jkridner_ | ||
| Chipaca | noizer, what do you mean? | 17:07 |
| noizer | Chipaca the disable function of services? | 17:07 |
| ogra_ | write a patch ? | 17:07 |
| beuno | ogra_, I'm sure u-d-f could be taught to access snaps by revision | 17:11 |
| beuno | and then you just make sure it has the right credentials | 17:11 |
| ogra_ | beuno, indeed it could, i was just talking about the status quo | 17:11 |
| ogra_ | it needs code :) and that needs someones time | 17:12 |
| beuno | luckily, I'm ignorant about a lot of quo's | 17:12 |
| ogra_ | haha | 17:12 |
| === chihchun is now known as chihchun_afk | ||
| dpm | jdstrand, it worked! :) | 17:21 |
| dpm | cd $SNAPPY, that is | 17:21 |
| dpm | thanks a lot for the pointer | 17:21 |
| jdstrand | dpm: woo! | 18:33 |
| lool | kyrofa: hey! around? | 19:18 |
| lool | All, when using multiple python2 parts in snapcraft, each part pulls a python2 runtime and then the parts clash when installing; what's the most elegant way of dealing with this? | 19:19 |
| ssweeny | I'm working on building location-service for snappy and running into an interesting issue. When linking against apparmor it's picking the static lib in /lib/<triplet> which fails because everything else is built shared with -fPIC. I can work around by removing /lib/<triplet>/libapparmor.a or adding an unversioned .so symlink to the .so there but I'd like to solve the problem a bit more elegantly if possible :) | 20:39 |
| ssweeny | this is snapcraft on xenial | 20:39 |
| ssweeny | I notice that there is a .so symlink in /lib/<triplet> when the apparmor-dev package is installed but not in the staged version in my snap | 20:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!