[01:11] Hi [01:12] I am trying to build the Snappy Ubuntu Core amd64 image, does any of you have experience to this ? [08:12] good morning [09:48] ogra_: Hey, can you point me to some infos how you folks build the raspi2_armhf system-image channel? Is that created by the system-image or is there a cdimage somewhere for rpi2? === davidcalle_ is now known as davidcalle [11:15] Good morning all; happy Gunpowder Day, and happy Men Make Dinner Day (totally unrelated)! 😃 [11:17] hi all, i just quickly ask a problem, snapcraft will happen errors when the snapcraft.yaml only set the field of seccomp for security policy. [11:19] is it a abnormal rule i used or limitation ? [11:48] hah! http://dave.cheney.net/2015/11/05/lets-talk-about-logging [11:49] * Chipaca points out snappy's logger.Logger interface has exactly two methods :-) [11:49] Chipaca: I saw that too and I much agree, want debug in standard logger and be happy [11:49] one for things the user should see, one for debugging [11:49] even documented as such :-) [11:49] yep [11:49] so we went with Notice instead of Info, because we're awkward with names or something :-) [11:50] anyway. need to take a break from sending hard emails. [11:50] willpower running low :-) [12:05] stgraber: ping [12:06] stgraber: is there an lxd image manifest anywhere? (is that a thing?) [12:19] stgraber: and how is it (lxd image) build currently? is the script for that available somewhere [12:21] I got to https://images.linuxcontainers.org:8443/images/ubuntu/wily/amd64/default/20151105_03:49/ [12:21] but no manifest nor nothing [13:42] Day 3 of UOS starting in about 20 minutes: http://summit.ubuntu.com/uos-1511/2015-11-05/ [13:43] \0/ [13:46] no way ! [13:46] and tons of snappy topics today too ! [13:47] yeppers :) [13:50] mvo_, Chipaca: the images on images.linuxcontainers.org are auto-generated images from the lxc-* template scripts we have in LXC, those are generated daily on https://jenkins.linuxcontainers.org using the scipts at github.com/lxc/lxc-ci, no manifest content is published (we could add that though) [13:51] mvo_, Chipaca: the recommended Ubuntu LXD images are those you get by doing "lxd-images import ubuntu --alias ubuntu" or "lxd-images import ubuntu wily --alias ubuntu-dev", ... [13:51] those are cloud images and their manifest is published at https://cloud-images.ubuntu.com [13:52] LXD uses the root.tar.xz images combined with the lxd.tar.xz metadata tarball [13:52] stgraber: ah, then i think it's the latter i need for this [13:53] the lxd-images command will go away in 16.04 in favor of simplestream support directly in LXD, at which point you'll get things like "lxc launch ubuntu:lts my-container" and that will just work straight after installation, the image will be cached for you and kept up to date behind the scene [14:55] so what exactly does a snapcraft plugin do? [14:58] ali1234, everything to build a snap with a specific build tool ... [14:59] i.e. we have a cmake plugin that allows you to define the github tree for some cmake using source and then call snapcraft build to generate a snap for you [15:00] elopio: Can we ask coveralls to only fail if the coverage goes down by like a half percent or something? There seems to be a lot of noise there. === alesage_ is now known as alesage [15:01] i'm looking at my github right now and actually there is quite a few things on here that could be packaged with snappy i suspect [15:01] and also a few that just don't make any sense at all [15:02] tedg: I will check. But I like the noise, it will make you add an autotools test when you get really tired of it. [15:05] elopio: Sure, but I have an MR that gets an "x" because coveralls thinks it decreased by 0.03% [15:05] tedg: yes, it's possible, but I'm not an owner of the repo. [15:05] there's a notifications tab. [15:05] Hmm, okay. I'll look. [15:06] oh wait, I think it's possible, but the screenshot doesn't show the full controls. [15:06] ogra_: quick question, when building the raspi2 image with u-d-f how do you make it select the raspi2_armhf device channel, using the --device parameter? [15:06] longsleep, right [15:07] ogra_: ok, i was wondering if i should care that this option is listed as deprectated [15:08] longsleep, we need to drop this warning i guess ... even though sergiusens will cry :) [15:09] ogra_: ok cool, i finally had time to try out my own system image server and hat to use this parameter to make it use the odroidc channel [15:27] Another question, when you build ubuntu-core preinstalled images, does the stable line also build with ppa:snappy-dev/image ? Docs in the ppa say its only used in edge. [15:28] after 15.04 release we started using the PPA there too for fixes [15:28] (the SRU turnaround time is sometimes to slow so the PPA is used as staging area for this) [15:29] ogra_: ok, so the ppa is required currently to build 15.04 snappy images - correct? [15:29] right [15:29] ogra_: ok, thanks for confirming [15:29] but why would you do that at all [15:29] just make your s-i server import the one from the ubuntu s-i server [15:30] and only provide your own device tarball [15:30] ogra_: yeah i have that now, but now i need to change some things in the ubuntu-core rootfs [15:30] ogra_: can i do this with the system-image server? [15:30] eeek ! [15:31] only if you set up your own build env [15:31] ogra_: i am trying to avoid it still - experimenting with it [15:31] which is rather very complex [15:31] ogra_: i got that as well, i mean i can build the rootfs with cdimage and all [15:31] yeah, but you really shouldnt [15:31] ogra_: but it tages ages and that cdimage scripting has soooo many features [15:32] especially in the light that system-image is going away soon [15:32] and you will have an OS snap that contains the rootfs [15:32] ogra_: yeah - but still, i need to be able to modify the rootfs - add own key ring for example [15:33] ogra_: i have not completely understood all aspects of the system-image server scripts - maybe that one can incorporate some overlay tarball on top of the pulled upstream rootfs [15:34] not sure thats supported in snappy, the overlay thing is for the vendor tarball on phones [15:34] in snappy you would have an additional snap in the store that your oem snap pulls in [15:34] ogra_: ok - but how can that overwrite stuff which is part of the rootfs? [15:35] it cant on snappy [15:35] and on the phone it doesnt do that either, it installs to rw space and gets linked/bind mounted [15:36] ogra_: well that would be fine with me too [15:36] (or the apps simply get changed to read fro the overlay location) [15:36] it isnt a concept to use in snappy [15:36] it wont work [15:36] understood, thats why i currently have to modify the rootfs / build my own rootfs [15:36] what do you change ? [15:38] update without internet connection from own url for example, replace openssl with libressl, change client.ini to use own system image server [15:38] i am pretty sure there is more to come [15:39] btw, the client.ini might actually be a bug, or might not be used at all by snappy tool - to sure but when installed from another system image server, only default.ini has the custom server and snappy update fetches stuff from system-image.ubuntu.com (configured in client.ini) [15:39] let me know if you think it is a bug and want me to add it [15:39] it might be a bug, but as i saidm system-image is completely going away soon [15:40] for snappy that is [15:40] your rootfs will be a snap from the store with a readonly img inside [15:40] yeah - we will change whatever needs to change then - no problem [15:40] ogra_: i will be one of the first to test if you have something i can test [15:41] :) [15:41] it will happen for 16.04 [15:41] yeah i cannot wait until then [15:42] but, wouldnt there still be some bootstrapping system image which then mounds the readonly image? [15:42] ogra_: or do you want to put all this into the ramdisk? [15:43] i would love to actually use the initrd *as* the readonly rootfs (like android does) ... but i fear that wont happen (too much pr-mount stuff that we need to do) [15:43] i was pondering to bring that setup up on the mailing list though [15:44] s/pr/pre/ [15:44] yeah probably a good idea, it would be nice to have it all inside initrd to avoid having some preloader gear on disk [15:45] ogra_: if there is something outside the ramdisk and something outside that rootfs from a snap then that something will need to be changed eventually by some and the situation is not so much different from today [15:48] ogra_: i read on the ml, that you work on building the device tarball outside of cdimage - while that would be awesome i would also be interested to create a much simpler rootfs build script - do you see any problems with a simple debootstrap approach, assuming all the hooks for ubuntu-core are run? [15:49] longsleep, no, i'm building it inside of cdimage [15:50] ogra_: oh - then i misread your mail sorry [15:50] longsleep, i'm just moving it to a later point in the build and try to get rid of all tools inside the rootfs that are related to it [15:50] so that i.e. something like initramfs-tools and all its deps are not in the readonly rootfs anymore [15:51] ogra_: i see - that would be nice yes [15:51] ogra_: so your goal is to reduce the rootfs from build dependencies for the device part - understood [15:51] i'm not yet sure how we'll create it in a "all snaps" world [15:52] thats pretty similar of what i want to have, i mean i have many debootstrap minbase scripts for various targets producing a minimal rootfs - i would like to create the snappy rootfs the same way if possible [15:53] and for my case, i never need that script to produce a device tarball as this comes in extra from another source [15:54] right [15:55] i mean i totally get why you folks create the images like you currently do, existing infrastructure and all - but for an outside the cdimage approach is really complicated [15:56] especially if you only want to build for a single target and version [15:58] plars: ev: things are happening, finally: http://paste.ubuntu.com/13112950/ [15:59] well, preferably you shouldnt modify the OS snap/readonly rootfs [16:00] elopio: indeed, we are back online :) [16:00] and preferably we'd prouce an OS snap that suits you to be able to put a framework snap on top to provide your differences [16:01] plars: I will now replace the deb + unpack with installing it from the ppa, as we talked long ago. I'm sorry this is still taking so much time. [16:01] elopio: no problem, hard to iterate on it when things were down, plus there was that bug [16:02] ogra_: yeah - i am happy to provide feedback as things evolve - for now i am on the page to build that system no matter what and beeing as snappy-ish as possible without loosing possible customizations [16:02] ogra_: btw, cloud-init - we talked about this a long time ago - i want to have it gone :) [16:03] longsleep, me too, but i'm not sure it will actually happen [16:03] ogra_: same goes for systemd timesyncd as it is insecure [16:03] we might keep it and have it comppletely disabled or so [16:04] ogra_: and all that smartcard stuff - i am not even sure why that is there [16:05] ogra_: well i am listening if anyone wants to explain why snappy needs to run pkcsslotd by default [16:05] plars: can you please add the tools-proposed ppa on the agent, in case you haven't already? https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed [16:06] longsleep, cant tell you ... i was asked to seed it, thats all i know [16:06] elopio: will do, but it will only get updated when we deploy or manually update it [16:06] elopio: that's ok? [16:07] plars: can't you tell the agent to autoupdate? That's the idea, to make it easy to push a new version of the tests to the agents. [16:07] ogra_: well ok - but someone has to know :) [16:08] elopio: that's pretty risky I think... if it's infrastructure, we should be deploying a known-good, tested version [16:08] elopio: if it's for a test, it should get pushed in temporarily via the test, and abandoned at the end of the test [16:09] elopio: otherwise it could leave the test environment in an unstable condition for future tests [16:09] elopio: this if for things like ubuntu-device-flash I guess? [16:22] where were the generic-amd64 snap sources? [16:22] * Chipaca <- bad memory [16:25] https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems [16:25] got it [16:25] https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems [16:25] bah [16:25] mbuahaha [16:25] :) === ara is now known as ara_afk === ara_afk is now known as ara [16:40] elopio: what am I looking at? :) I mean I see SPI data in there (test_opportunity.json), but it’s also a wall of text [16:40] ev: you are looking at the output of the tests running in the bbb in the lab. [16:40] woohoo [16:40] running every day? [16:41] they fail because the script is taking an outdated deb, but that's good, they should fail. [16:41] hah! [16:41] ev: yes, they run every day, but for now deployed on my canonistack jenkins. [16:41] plars: sorry, I was on a hangout. [16:43] plars: let me try without a package. Just copying all the golang setup. [16:43] plars: but on travis we have the option to install packages and ppas. We are taking advantage of that in many of our tests, it would be nice if we could do it here too, somehow. [16:45] elopio: thats on your test instance, which gets created/destroyed every time, in the spi case, that is equivilent to the system running snappy, which you can absolutely do whatever you want to it [16:46] creating a new host for it each time, would require another provisioned instance in the middle of the device host, and the device itself.. it's something we could explore but would be complicated and add some additional time to the process [16:46] elopio, can you please take a look at https://github.com/fgimenez/snappy-github-plugin/pull/2 when you have time? [16:46] plars: that's the problem with this model. We need to do stuff on the test bed, and on the controller. [16:47] the way to avoid that was to package the stuff of the controller in this deb package that is on the ppa. [16:47] elopio, jenkins job triggered from github, if you could propose a PR for testing it would be great [16:47] elopio: I think we can work with what you want to do pretty easily, we just need to separate what is required/stable infrastructure from what is being tested [16:48] plars: let me first tackle the daily problem with what you have today. [16:48] elopio: and I think it might make things easier for your use case if you don't feel like you have to build everything on the test host [16:48] then we will try to solve harder problems, like testing the branches and testing snapcraft. [16:48] elopio: for example, you can do whatever you want on your jenkins, build a new version of snappy tools, ubuntu-device-flash, etc... and ship those down to the job when it runs. It would also likely cut your execution time [16:48] fgimenez: woohoo. [16:48] elopio, your user is whitelisted, so the job should be triggered automatically. you can trigger a rebuild with a comment "retest this please" [16:49] fgimenez: I need to walk with the dog because he's driving me crazy. I will try when I return. [16:49] elopio, ok thx! [16:50] fgimenez: so wait, if I propose a branch to ubuntu-core/snappy it will take it and run tests for it? [16:50] elopio, no, its only for that repo, and the build is currently a couple of echo commands [16:50] ahhh [16:50] elopio, you should fork it and PR to it [16:51] fgimenez: cool. bbs. === kyrofa_ is now known as kyrofa === ev_ is now known as ev === balloons is now known as Guest9062 [17:27] elopio: awesome! === kickinz1_ is now known as kickinz1 === Guest9062 is now known as balloons [18:49] sergiusens: would something like https://github.com/plars/snapcraft/tree/empty-plugin be welcome? I saw some discussion about possibly having something like this and/or modifying copy to make it not require files to copy... but I think that's a bit confusing (copy but don't *really* copy) [18:49] plars, we wanted to call it the 'null' plugin :-) [18:49] sergiusens: as an added bonus, it enables things like https://github.com/plars/snapcraft/commit/9118f2bb67c10c868109cdc5d3ac5052bbe28121 - testing init with parts specified [18:49] sergiusens: yeah, I tried that, but it turns out null is a special word in yaml I think :) [18:50] sergiusens: it choked on that [18:50] it reads it as NoneType [18:51] on a related note, I don't see a way to actually use snapcraft init with the partname specified with the current set. All of them seem to have required args with no way to specify. Is that an issue with snapcraft, or an issue with me not seeing how to specify it? :) [18:52] I don't see any way at the moment to specify it, but perhaps I'm just missing it [18:57] sergiusens, plars: joc_ implemented a null plugin earlier this week :) [19:01] zyga, I don't see it! :-D [19:01] plars, init with parts needs some love/refactor [19:01] sergiusens: it was merged to plainbox-provider-p... as a local plugin [19:01] sergiusens: I encouraged joc to propose it to snapcraft [19:02] sergiusens: if you want I can dig it out and push [19:02] sergiusens: no tests though [19:02] sergiusens: (it's really trivial though) [19:02] very trivial [19:03] joc_, zyga we can use it in our unit tests instead of the mocked plugins though and then, yay, tests ;-) [19:03] but deal with plars since he has one there too [19:04] joc_: see if your plugins is any different from the one plars made and let's get one landed in snapcraft [19:04] joc_: less x- the better [19:07] zyga: ah, I didn't even know that, I'm not subscribed to that I guess [19:07] joc_: you should propose then === dholbach is now known as therealpopey === therealpopey is now known as dholbach === jdstrand_ is now known as jdstrand [22:16] sergiusens: hey, leo reported something about scenarios for thest that have the same steps [22:16] sergiusens: that sounds awfully like templates which we do support [22:16] sergiusens: do you know more what he was thinking about? [22:17] elopio: ^ [22:17] tedg: ah, thanks [22:18] zyga: https://github.com/ubuntu-core/snapcraft/blob/master/integration-tests/units/examples.pxu [22:18] all the tests in there are the same, changing the dir. [22:18] zyga: tell me more about templates... [22:18] elopio: perfect :) [22:18] elopio: it's very easy, write one more job that does the equvalent of ls examples/* [22:18] elopio: and prints something like this to stdout: [22:18] elopio: name: godd\n\n [22:19] elopio: name: gopaste\n\n [22:19] elopio: etc [22:19] elopio: make that a plugin: resource [22:19] elopio: and run it to see that it works OK [22:19] elopio: then step two [22:19] elopio: take any of the example jobs [22:19] elopio: replace the name of the example with {name} [22:19] and stick this up front in the unit: [22:19] unit: template [22:19] template-unit: job [22:19] template-resource: id-of-the-resource-you-made [22:20] then last step is to stick the resource in front of the test plan [22:20] and also add one more field to the test plan: boostrap_jobs: id-of-the-resource-you-made [22:20] (you have to reference it twice for now) [22:20] elopio: I'll give you the man page with everything [22:20] zyga: I'll try when I get back and report how it went. Thanks. [22:21] elopio: http://plainbox.readthedocs.org/en/latest/manpages/plainbox-template-units.html [22:21] elopio: scroll to the example [22:21] elopio: just one gotcha, { } are expanded with python format-like system [22:22] elopio: so {{ }} are good for quoting [22:22] elopio: that's not mentioned in the man page [22:22] elopio: you will have to do quoting [22:22] elopio: or drop ${foo} in favour of $foo [22:23] elopio: try it and send me a link tomorrow, if anything needs tweaking I'll help you out [22:24] elopio: the only weird thing with templates is that with the new world we're going to (all the new tools but _not_ plainbox CLI yet), resource jobs that instantiate jobs from templates need to be listed in boostrap_include in the test plan [22:24] elopio: http://plainbox.readthedocs.org/en/latest/manpages/plainbox-test-plan-units.html [22:24] elopio: but plainbox CLI is the last thing to go and for that you still have to just list it in the plain include section [22:24] elopio: so list it twice and that will be okay