[00:03] kyrofa: there is now https://github.com/ubuntu-core/snapcraft/pull/266/files === chihchun_afk is now known as chihchun [07:56] So here's probably an annoying question. What's the latest snappy image for a Raspberry Pi 2? [08:05] I'm going to sort of assume it's https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz. [08:07] good morning [08:09] nhaines: thats the very latest 16.04 image, its a bit rocky at this point because we are adding lots of new features [08:09] elopio, hey, still awake!? :) take a look at http://10.55.32.97:8080/log/all [08:09] nhaines: if you prefer something stable to work with, the 15.04 rpi2 image is also available [08:09] mvo: I just got an RPi2 with a PyGlow module, and was hoping to play around with it. :) [08:09] nhaines: http://releases.ubuntu.com/vivid/ubuntu-15.04-snappy-armhf-raspi2.img.xz [08:09] elopio, "Checking comment on PR #379 for job github-snappy-integration-tests-cloud" [08:10] mvo: is there no 15.10-based image? [08:10] fgimenez: yes. Everything seems correct, except that m-o can't connect :( === lu is now known as Guest98847 [08:10] elopio, http://stackoverflow.com/questions/8378235/javax-net-ssl-sslexception-java-security-invalidalgorithmparameterexception-th maybe we are missing an ssl store === l is now known as Guest57199 [08:11] mvo: I'll skip the "why" and ask where I can sort of figure out where to look for up-to-date information. [08:11] fgimenez: I installed the ca-certificates-java. [08:11] still no luck. [08:11] elopio, ok i'll take over from here, thx! and get some rest [08:17] nhaines: here is a bit of background info on the 16.04 image state https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html [08:17] nhaines: we only have 15.04 and 16.04 currently [08:18] fgimenez: ok, I give up now anyway. The old jenkins doesn't have the java certs installed anyway and it works. [08:19] elopio, maybe something is missing in trusty, i'll investigate. the current images have been built with the new keys, right? [08:20] fgimenez: the rolling edge all snaps, yes. [08:20] fgimenez: to generate the 15.04 we need snappy-cloud-image not to pass os, kernel and gadget parameters to udf [08:20] elopio, ok, i'll rebuild that one and create a new floating ip and a testing project in github [08:20] I guess we can make that the default is not to pass the parameters. [08:21] elopio, that's already done iirc, let me check [08:21] elopio, https://github.com/ubuntu-core/snappy-cloud-image/blob/master/pkg/image/image.go#L94 [08:23] fgimenez: for some reason that didn't work: http://162.213.35.179:8080/job/create-cloud-image-vivid/1/console [08:24] elopio, ok i'll check that too [08:35] mvo: gotcha. Will I be able to upgrade from 15.04 to 16.04, or will that require a reflash? [08:40] nhaines: it will require a reflash. if you want to avoid that the 16.04 image is probably better but it under heavy development :) [08:46] mvo: finished flashing the 16.04 image, ran 'snappy enable-classic', then 'snappy shell classic', ran 'sudo apt install nethack-console'. Worked but game not available. Sad. :) [08:50] Anyway, reflashing isn't currently a problem, so I'll manage either way. Thanks for the help. :) [09:44] Good morning all! Happy Wednesday, and happy Chocolate Cake Day! 🙌 🎂 [09:45] JamesTait: hey, good morning! [09:45] JamesTait: how is the snap.yaml stuff going? I would love to upload the first snaps ;) [09:48] Things are moving now I've managed to nail down the requirements. I expect to have something to land and test on staging today. [10:05] Now you made me want chocolate cake :( [11:27] hmm, ubuntu_geek is gone [11:33] kyrofa: sergiusens: wdyt of http://paste.ubuntu.com/14678463/ (and then make plugins that support, honor those global flags) [11:33] utlemming: so I tested the vagrant stuff on two machines and the "stable" image loops on both, so is pretty unusable ... [11:34] utlemming: also both machines are very different (one intel i7 one amd opteron 6272 etc.) ... [11:34] asac, i dont like "+j_count = 0" [11:34] why? [11:34] utlemming: the "edge" image seems to work though, so using that for now ... [11:34] <=0 -> use auto counrt [11:34] count :) [11:34] asac, it should check /proc/cpuinfo and default to the number of cores instead [11:35] ogra_: did you read the code? [11:35] meh [11:35] :) [11:35] didnt read to the end [11:35] search for it... its doing that [11:35] hehe [11:35] yeah [11:35] my head feels like wrapped in a 2m thick layer of cotton wool [11:35] without that its pretty sleep inducing to build a kernel :) [11:35] (hard to get through doors this way :P ) [11:36] yeah, sorry [11:36] hehe [11:36] you went to the doc? [11:36] :) [11:36] or just bad day/headaches? [11:36] ogra_: give it one meter more and you will know my current state :) [11:36] just got up after a 12h flight :) [11:36] did you guys pick up the ubuflu? [11:37] at least i only cracked my back and didnt catch a cold or ubuflu as usual [11:37] I did /o\ [11:37] dholbach: yeah, a little bit [11:37] pfft... 12h is easy :P [11:37] seb128 as well [11:37] ogra is getting old :) [11:37] lol [11:37] well, get some rest then [11:37] asac, well, over all it was a 17h tour [11:38] but yeah, getting old [11:38] better if you are available strong for less time its better than weak for long time :) [11:38] and i cant take much rest, so much to do [11:39] ... generic initrd ... all-snaps in livec-rootfs ... dragonboard images ... aall in the next 10 days [11:40] mvo, so for the initrd, when do you want to merge the two pieces ... during snap creation or earlier ? [11:40] (i assume we want to sign the file inside the snap ) [11:41] s/ sign the file inside/ a signed file inside/ [11:41] * dholbach hugs didrocks, ogra_ and seb128 [11:42] hope you're all better soon again [11:42] * ogra_ hugs dholbach didrocks and seb128 [11:42] * didrocks hugs dholbach, ogra_ and seb128 as well, (sharing germs!) [11:42] same for you :) [11:42] * ogra_ puts up a virus scanner to catch the worse bits [11:42] this is the infirmary :) [11:50] big ubuflu it seems :) [12:02] asac, set verbose seems very specific to the system (it is different on others) [12:02] asac, if you create a bug, I'm happy to look into it [12:03] sergiusens: not sure what you mean [12:04] lots of build systems have verbose flags to see the real command line [12:04] like V=1 etc. [12:05] sergiusens: look at this for an example with scons.py [12:05] sergiusens: https://github.com/asac/snapcraft/tree/multithread-and-verbose-infra [12:05] dholbach, didrocks seb128 get better! And maybe ogra_ too [12:05] * Sweet5hark stacks up on phone desinfectors ... [12:06] didrocks, I have thought of a probably better way to do pkg-config without changing pkg-config, but by wrapping the call. I'll experiment and propose [12:07] thanks sergiusens [12:07] thanks sergiusens! [12:08] thanks sergiusens :) [12:08] sergiusens: ah, not uninteresting, yeah, wrapping would be less instrusive [12:08] asac, I'm a bit skeptical about this, but we can explore [12:08] didrocks, wow, get some rest, thoes double negatives are hard to follow ;-) [12:09] sergiusens: ahah, yeah, tireness is twisting my mind! :-) [12:09] sergiusens: what makes you think? [12:09] sergiusens: a) it surely needs to be a global CLI option, no? [12:09] asac, are we philosophical today ? [12:10] b) bc, you want to be able to toggle this on and off from CLI and not hack on yaml to change behaviour [12:11] asac, lets start with `snapcraft snap`, does it work with how you did it? [12:12] sergiusens: oi if you want to talk about how to implement the global option, then yeah lets talk [12:12] asac, verbose makes sense to be global, the -j could be a yaml thing though (just because of what I mention before); if not you need to expose these globally [12:12] sergiusens, hi there... I was told you had some thoughts on the vendoring approach taken here? https://github.com/ubuntu-core/snapcraft/pull/197 [12:12] sergiusens: so thats interesting question. think right now you can only change this if you run build explicitely [12:12] which could be fine if you think about it, but i would prefer if the option woudl be everywhere [12:12] sergiusens: no -j is not yaml [12:12] its cli [12:12] you want to toggle on/off for debugging etc. [12:13] at best all are global [12:13] felt bad to put it for top level options, but we could do that [12:13] thought maybe you know a trick how a command would still parse the options [12:14] pindonga, I'm really not comfortable with vendoring; especially for things that the team is not upstream for [12:14] sergiusens: anyway, thanks for checking. what i want are those common.XXX functions that have the behaviour as its now for build, just better so it works for snap etc. [12:14] and default target [12:14] sergiusens, so what do you suggest we do? here's the problems I see [12:15] i can go and make plugisn that support these do it [12:15] 1. ssoclient is only provided as a package on xenial, thus depending on this will mean snapcraft will only work in xenial once this change lands [12:15] pindonga, can't this land in xenial? [12:15] pindonga, that is fine [12:15] pindonga, xenial is the only target for snapcraft 2.0 [12:15] 2.x [12:15] 2. the upload also requires the storeapi code, which if not vendored will also require us to package/land click-toolbelt on xenial (same caveat) [12:16] also, packaging and getting this into ubuntu seems to be taking quite some time [12:16] and I fear we'll miss feature freeze [12:16] pindonga, landing in ubuntu is part of the workflow though [12:16] pindonga, maybe ask dholbach for help with packaging, I'm sure he is more than glad to help [12:17] sergiusens, ok [12:17] beuno, fyi... looks like we'll have to go the packaging route in the end [12:17] pindonga: what do you need to get into the distro? [12:17] dholbach, click-toolbelt [12:18] * pindonga checks what the latest status of that was [12:18] r57? [12:18] sergiusens, oh, no LTS backports planned for snapcraft ? [12:18] there's no new changelog entry in debian/changelog in lp:click-toolbelt? [12:18] dholbach, yes, version 0.5.1 [12:19] is this normally uploaded through auto-landing? [12:19] dholbach, this is a new package, hasn't reached the archive yet afaict [12:19] pindonga: so r57 == 0.5.1? [12:19] so no idea what to answer there [12:19] yes [12:19] ok ; isee [12:19] let me review it [12:20] ogra_, yes, 16.04 LTS [12:20] pindonga, sergiusens, I don't understand why it needs to be pacakged? [12:20] ogra_, if it were written in go I'd be more confortable [12:20] also, I wouldn't use the name click-toolbelt if we do [12:20] it [12:21] beuno, we have no guarantees of maintainership; and it is bad practice to vendor in the archive [12:21] beuno, in that case we'll have to split the storeapi code into a diff project and package that [12:21] sergiusens, it [12:21] even more work [12:21] Hi, is it possible to use *.so files that are compiled on ubuntu lts 14.04 on a raspberry pi to make a snap and use them as a framework? [12:21] beuno, if it is a fork; then it is missing tests which was said was not necessary [12:21] beuno, this is just proper ubuntu work, nothing really out of the ordinary [12:21] I don't understand, upload is a core part of snapcraft [12:22] why would we want to have it separate? [12:22] beuno, yeah, the libraries used though, that's different [12:22] sergiusens, hmm, that creates a gap ... most people will only upgrade once 16.04.1 comes out [12:22] beuno, well, the conversation started with the fact that there are no tests as it is tested upstream, but if it indeed is a fork, then it is not vendored, but a fork [12:22] and should have all the required tests [12:23] beuno, sergiusens what's vendored is the store api code (just so we don't have to duplicate the code in both places) [12:23] I could as easily do the latter removing one thing to vendor [12:23] sergiusens, the old code is being deprecated [12:23] the other (ssoclient) would still be needed via dep (which is already in xenial) [12:23] we're keeping it around so the phone can still upload clicks for a little while [12:24] we're merging in that code into snapcraft, and killing off the other tool as soon as it's sensible [12:24] beuno, as long as you maintain this part of the code [12:24] Good morning [12:24] sergiusens, by you, you mean all of us? [12:24] I mean, this was suppose to be part of snapcraft [12:24] kyrofa hi i have an other question about snappy can you help me out a bit? [12:25] and pindonga is pitching in so more things can be done on other bits [12:25] NoiZeR, sure :) [12:25] if there are concerns about code quality, we can surely split it up and land it in chunks [12:25] beuno, if we are going to be upstream... https://github.com/ubuntu-core/snapcraft/pull/197/files#diff-175727a8f2ba0ea9e34a671983b5ad2dR36 [12:25] beuno, that is indeed wrong, why does it say `vendor`? [12:26] kyrofa so i uses a Raspberry Pi and i have some libs compiled on a Raspberry Pi with ubuntu 14.04 LTS but is it possible to make a snap of it en use it as a framework? [12:26] sergiusens, because it hasn't been clear how to pull these things together [12:26] kyrofa it is an *.so file [12:26] kyrofa thx in advance xD [12:27] sergiusens, dude, you're leading snapcraft. There was the store upload feature on the roadmap, and I volunteered to get someone to work on that code since we have some domain experts [12:27] NoiZeR, potentially. Libraries still often need other libraries, which would also need to be included in the .snap [12:27] I don't get why you'd want to try keep that split as a separate thing [12:27] NoiZeR, why are you wanting to make a framework instead of a normal .snap, by the way? [12:27] sergiusens, if you'd rather develop the feature yourself, pindonga has plenty of other things to work on [12:27] beuno, I just said, remove `vendor` add tests and it is fine [12:27] cool [12:27] ok [12:28] beuno, I am worried that when snap-ids come all this code will be useless, that's why I am worried [12:28] kyrofa im making a system where users can make some application for my application. But they need the Library that is installed on the Raspberry Pi [12:29] kyrofa so the developers can make third party modules for the device [12:29] sergiusens, I understand, we'll need to change quite a few tools around it [12:29] sergiusens, nessita is currently planning that change [12:29] sergiusens, I don't think the core of this will change (uploading) [12:29] NoiZeR, alright. Note that frameworks are more for sharing some sort of service, not sharing libraries. Not to mention frameworks won't exist in 16.04 (they're being replaced with something else) [12:29] sergiusens: beuno: i feel that some coupling of store and snapcraft is unavoidable with the consequence that there will be changes that need invest on both sides... to ensure things move smoothly, couldnt you couple store and snapcraft through integration tests that run on landings on both sides. in this way if store wants to land changes that break snapcraft they will have to facilitate that the snapcraft change also happens? [12:30] but there are plenty of things to add: assertions, name reservations, etc [12:30] and vv [12:30] NoiZeR, as i understand there are no framework snaps anymore ... but you can create library snaps that your app can consume (but nobody elses but your snaps will be able to use them, they are bound to teh developer) [12:30] we have autopackage tests enabled; but the store does not land on ubuntu so it is up to the store to implement those testing hooks [12:30] asac, ^ [12:31] NoiZeR, your users might be better served by your making some sort of snapcraft plugin to integrate your libs into their .snaps [12:31] asac, I don't think we'd be breaking each other in this case, the server might change, and if it does the client has to regardless of where it lives [12:31] NoiZeR, or just make a build system that makes it easy [12:31] sergiusens: if snapcraft already tests store interactions through autopackage tests on landings thats fine [12:31] yeah, what kyrofa said [12:31] kyrofa, a build system what do you mean with that? [12:32] kyrofa can you use snaps into snaps? [12:32] beuno: sure, just saying that snapcraft maintainer would feel less reluctant to land more code that couples store to snapcraft if i knew there are tests for the integration running in store landing process too... [12:32] NoiZeR, is your library built by a build system? e.g. cmake, autotools, etc.? [12:32] cmake [12:32] (just my way to say, i wouldnt hold back with more coupling just because something will change; we ahve to do it anyway so ratehr think how to make it efficient and not how can we wait longer) [12:32] kyrofa cmake and an other lib by qibuild but [12:32] NoiZeR, cmake is good-- snapcraft supports cmake with a plugin [12:33] kyrofa but cmake needed qibuild so i need to install the python library aswel i think [12:34] kyrofa but how thats works i don't know. Just i know its needed to be installed with pip install qibuild [12:34] asac, sure thing [12:35] pindonga: AFAICS the package is good to go, minor nits would be: the package description could be a bit longer, copyright in d/copyright could be extended to be 2013-2016, and there's no manpage for click-toolbelt - I didn't quite follow the discussion you had above about having a separate package or something.... do you know if everyone's happy with the name click-toolbelt and the placing of all bits in the code? [12:36] from a mere packaging POV I'm happy to upload if everything else is settled [12:36] dholbach, thanks but it looks like we won't need it after all [12:36] we're moving that code into snapcraft itself [12:36] ok... [12:36] let me know if I can be of any help [12:36] NoiZeR, okay I'm not familiar with that... hold on [12:36] NoiZeR, let me do some research into qibuild real quick :) [12:36] kyrofa np [12:37] kyrofa its with the NAO robot related [12:37] NoiZeR, but my point is this-- your job would be easier if you focused on building your snap with snapcraft rather than bundling the .snap yourself [12:37] NoiZeR, since .snaps must include their dependencies [12:39] kyrofa ok wait a sec :p So the i need to just add the library to my snaps and then it will work correctly? And can the other snapps uses this library? [12:39] NoiZeR, each .snap will need to include your lib and its dependencies [12:40] NoiZeR, this allows your lib to update without potentially breaking the user's snaps before they're ready for it, etc. [12:41] kyrofa but every snapp does need to get this library into there snap? [12:41] kyrofa or is it possible to share a coulple of library [12:42] NoiZeR, what exactly will your users do ? [12:42] do you expect them to build a snap themselves to make use of your project ? [12:43] (with an emphasis on *build* ) [12:43] ogra_ yes So they need to make some snaps and the other snap need to call them [12:43] cut that sentencs at "and" :) [12:44] *sentence [12:44] _ogra so you can it sea like android is my snap and they will install some snapps and that are the apps [12:44] NoiZeR, they need to build something ... why not focus on that then insteasd of binary usage [12:44] provide them the easiest way to do that build step and you win [12:45] ogra_ what do you mean exactly with that? [12:45] make that build step bundle what they need ... [12:45] into their snap [12:45] dholbach: https://developer.ubuntu.com/en/snappy/ snappy log is broken here [12:46] what is broken? [12:46] ogra_ so that they always include the needed libraries? [12:47] NoiZeR, exactly [12:49] ogra_ ok but thats one solution but is there a way in the future to share libraries just like in a normal linux? [12:49] "a normal linux" ? [12:50] just lik i install the C++ library on my Ubuntu 14.04 and i can include the files (the library is en *.so file) [12:51] and some python stuff [12:51] you can make shared library snaps today ... but only shared for *your* snaps .... i.e. they are bound to your account so you cant break our security model ... random dependencies like in other package managers wont be possible [12:51] asac: what is broken on thage page? [12:51] ogra_, and you can't really do that today-- you'll be able to in 16.04 [12:51] *that page? [12:52] NoiZeR, so for 15.04, the real answer to your question is no. Snappy is a bit different from other packaging systems-- you can't share dependencies like that [12:52] kyrofa, heh, right, my brain is still in a different TZ from my body :) [12:52] ogra_, ha! You home now? [12:52] yep [12:52] ogra_, might take you a week man, sorry :P [12:52] but brain is still over the atlantic somewhere ... following up at snail speed [12:53] yeah [12:53] ogra_ so when i install all the apps as the same user it will work correctly [12:53] ? [12:53] with shared libaries? [12:54] right, so that you can use the sname libs from a single snap ... [12:54] but others wont be able to consume them [12:54] dholbach: the snappy logo doesnt load here [12:54] right on top right [12:54] its broken image [12:55] dholbach: do you see it? [12:55] you're right -I can see the problem too [12:55] ogra_ the account is that on the snap store that you mean or just a user on the device? [12:55] NoiZeR, snap store [12:55] dholbach: good :) [12:55] asac: it wasn't clear to me that "snappy log" was supposed to be "snappy logo" :) [12:55] yeah, typos ftw [12:56] NoiZeR, if any random person would be able to put libs there that any other random person can use, you would completely break the security model of app isolation ... [12:56] asac: https://assets.ubuntu.com/sites/ubuntu/latest/u/img/cloud/tools/snappy/snappy.png was dropped it seems [12:56] davidcalle: ^ better not to rely on assets [12:56] NoiZeR, and are security wise back to deb/rpm [12:56] kyrofa, morning btw [12:56] sergiusens, hey there :) [12:56] dholbach: hmm. will you check it out? [12:57] yes [12:57] NoiZeR, meaning to give *every* person in the app store root on your device ... [12:57] ok let me know. wanted to download it for a rpesentation [12:57] :") [12:59] asac: fixed [13:00] neat [13:01] NoiZeR, i.e. in the deb/rpm world *every* package maintainer has full root access to your system ... in snappy every store account has root inside their area of the system, but not in the system itself or in other accounts ... if lib snaps would allow cross account usage that woulod mean the provider of the lib has full root access to all snaps that consume it [13:02] ok I understand that [13:02] dholbach: there also exists an orange snappy logo somewhere [13:02] that has the word snappy printed [13:02] can you browse assets etc. to see if they are there? [13:03] NoiZeR, so in the case where your users have to build something from source anyway, just focus on making that step the best experience by providing a snapcraft plugin that automatically takes care for everything [13:04] ogra_ kyrofa thx for the help when i have some questions will ask them here [13:04] so the users can concentrate on their code [13:04] great, that is why we are here :) [13:05] NoiZeR, sounds good :) [13:09] ogra_, when will the dragonboard be here: https://developer.ubuntu.com/en/snappy/start/ ? [13:10] kyrofa, within the next 10 days i hope [13:10] ogra_, awesome! I just received mine yesterday. Do you happen to have a writeup I can follow? [13:10] we need auto-builds first ... [13:11] kyrofa, http://people.canonical.com/~ogra/snappy/dragonboard/README [13:12] if you are on xenial the latest in-archive u-d-f shoudl work btw ... else you need to download the one from that dir [13:13] ogra_, excellent, thank you! [13:20] ogra_: hey, did you have to patch snapdragon u-boot for things to work with snappy? [13:20] lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files [13:20] only the config [13:20] there is also a README about all i had to do [13:20] ogra_: ok, CONFIG_SUPPORT_RAW_INITRD is what I suspected [13:21] ogra_: ah I didn't see the u-boot part in your original dragonboard README hence the Q [13:21] yeah, and support for our uboot.env [13:21] so where is the snappy command docs? I see there is a "snappy man" command than dumps a raw manpage ... but "man" doesnt seem to be available or installable on snappy? [13:21] lool, yep, that work pre-dates snappy work [13:21] lool, afaik even linaro now uses my boot setup ;) [13:21] for normal linux [13:22] ogra_: cool [13:22] urgh CONFIG_SYS_REDUNDAND_ENVIRONMENT [13:22] yeah [13:22] redundan*d* [13:22] hehe [13:23] I wonder if it's a germanism [13:23] no idea who originally created the option [13:23] asac, can you check my comment https://github.com/ubuntu-core/snapcraft/pull/257/files ? [13:24] BBB uses it which is why all other boards inherited it for having a working fw_setenv/printenv (and uboot-go) we use in snappy [13:25] ogra_: uboot-go? [13:25] (the option just adds a 4byte header to uboot.env ... not even sure why thats "redundant" in any way) [13:25] ogra_, mvo asac lool so initrd and multiple kernel snaps; mvo is thinking we should create a full initrd on kernel snap build time; that seems hard to do for snaps that we don't control though (and becomes hard to maintain) [13:26] it's also a problem for lvm, crypto and stuff [13:26] sergiusens, well, i suppose we might want to sign the initrc file inside the snap [13:26] *initrd [13:26] besides, isn't there core snappy logic setting up writable bind mounts from initrd? [13:26] so you cant really assemble at snap install time [13:26] ogra_, so if we ever update the OS, we will need to rebuild all the kernel snaps (or someone) [13:26] sergiusens: I'm not sure I'm thinking this, this is what I'm doing currently, we discussed cat'ing multiple initirds [13:26] lool, we are at the step before running the initrd :) [13:27] sergiusens, ? [13:27] sergiusens, do you plan to ship any parts of that in the os snap ? [13:27] * ogra_ wouldnt [13:27] mvo, oh, sorry, this is based on a quick SCaLE conversation with ogra_ [13:27] ogra_: btw, did you had a chance to test http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz ? [13:28] ogra_, so when talking to mvo half of the initrd would be in the OS snap; the other half in the kernel [13:28] my vision would be that we have a generic and a modules part ... and that we merge them at kernel snap creation time into one file we can sign [13:28] sergiusens: no worries [13:28] mvo, not yet ... will do so beofre EOD [13:28] ogra_: on a grub system we don't extract anything, we load directly from the squashfs [13:28] ogra_: thanks! [13:29] ogra_: so extracting and combining would be a step backward :( [13:29] sergiusens, mvo, yeah, i dont think that will fly nicely ... both parts should live in the kernel snap [13:30] the other option would be to merge them from the bootloader on the fly .... but that will likely result in very slow boots and probably also require quite some bootloader hackery [13:30] maybe I'm missing something, but why would both parts live in the kernel snap? it seems if one is in the OS snap, that is ok? as long as it has no modules or other kernel dependant stuff ? [13:30] mvo, how would you boot that ? [13:30] it seems like grub supports loading multiple initirds? [13:30] does uboot too ? [13:30] i never tried that [13:31] ogra_: grub has a concept of multiple initirds, so grub would load both, never tried it either, I'm not saying it works, just that that looks like a really good option :) [13:31] ogra_: uboot is a bit of a problem :( [13:31] that might result in horrid math stuff when you create a gadget to get all the load addresses right [13:31] ogra_: but on the upside, on uboot we need to extract the files, so we can do merging with uboot [13:31] mvo: so cat-ing multiple initrds would work technically; is this the solution we want to implement for 16.04? we could [13:31] ogra_: you mean horrible math for uboot? [13:32] yeah [13:32] lool: at least on grub it sounds like the best option we have [13:32] mvo: we tested the multiple initrds yesterday, it works [13:32] lool: \o/ [13:32] lool: you rock [13:32] where to load the bits so they dont overlaop and can be used as one file from ram etc etc [13:32] mvo: for u-boot, it's technically possible, but I personally would prefer if we did u-boot -> grub -> multiple initrds [13:32] eeek ! [13:32] ogra_: so for uboot we can extract+conact so that the bootloader does not have to do terrible math [13:32] or we just cat the initds together on disk since u-boot systems are handled specially anyway [13:33] lool: yeah, I think the later is the better option [13:33] the good thing about u-boot -> grub is that it gives us squashfs again [13:33] lool: ohhhh [13:33] lool, well, that gets us issues with signed initrds [13:33] lool: thats very interessting [13:33] lool, why would you do uboot->grup and not just grub ? [13:33] it's a recent patchset from Linaro (end of Dec) that enables the EFI interface in u-boot for grub-efi to use [13:33] ogra_: right, so if we have a signed kernel we can not concat, can we? because it has to be signed ? :( [13:33] ogra_: it's too much work for us [13:33] having two bootloaders sounds super awful [13:34] people could also do efi/tianocore instead of u-boot, but this is not our battle [13:34] lool, rhight, which is why i'D stay with uboot alone until we can do a full switch to grub [13:34] ogra_: there are always tons of firmware before us [13:34] the question is whether we want to support both u-boot and grub or only grub everywhere in some way [13:34] if we get grubs multiple-initird + direct loading from squashfs blobs, that would be a big plus. even if it means two bootloaders [13:34] I prefer the latter (grub only interface for snappy) [13:34] kyrofa, sergiusens: are we going to add a new milestone for snappy? [13:35] err, snapcraft [13:35] it will be slow and error prone to chainload [13:35]