I'm afraid I don't know the answer, Waldek. TBH I always thought we're building Java from source :) >From what I understand there's only a problem with symbols, perhaps zulu .so files are compiled in a way that they ship with all the symbols hence it works (but the package is bigger).
@Nadav? Dne torek, 27. februar 2018 06.04.38 UTC+1 je oseba Waldek Kozaczuk napisala: > > I am also trying to understand the difference in behavior between java and > nodejs images. In case of node.js we need to build it from source to make > it a relocatable ELF but in case of java we use JRE so files as is because > they are already relocatable. But also in case of node.js (and other apps, > node.js is just an example) we care about version of gcc, libgcc_s, etc to > make sure it is compatible with kernel. On other hand with java shared > libraries we do not have control what version of gcc, libgcc_s was used, > etc and it still works - at least with Zulu openjdk8-*. Is it because Zulu > JDK is carefully built in a way so it works on all Linux distributions? Or > I am completely misunderstanding this? > > On Monday, February 26, 2018 at 6:29:41 PM UTC-5, Waldek Kozaczuk wrote: >> >> Adding Miha back. >> >> Sent from my iPhone >> >> On Feb 26, 2018, at 18:25, Waldek Kozaczuk <jwkoz...@gmail.com >> <javascript:>> wrote: >> >> Please see my responses below. Also one question I forgot to ask was the >> cadence - how often and when to release. It could be: >> >> 1. when enough new features/bugs are added/fixed (this requires more >> planning) >> 2. when certain amount of time passes >> >> I am leaning towards the 1st approach. Should be once a month, every 3 >> months? >> >> On Monday, February 26, 2018 at 12:32:40 AM UTC-5, דור לאור wrote: >>> >>> IIRC we agreed to release a 0.25 few months ago. No problem to go >>> back to a regular cadence of releases. Waldek, we'll need you as a >>> driving force. >>> >> I thought you or Nadav mentioned somewhere else that 0.50 would be more >> appropriate. Given it has been over 2 years since 0.24 it would make more >> sense to make it 0.50 and maybe delete all old artifacts. >> >>> >>> On Sun, Feb 25, 2018 at 3:15 PM, Nadav Har'El <n...@scylladb.com> wrote: >>> >>>> >>>> On Sun, Feb 25, 2018 at 8:45 PM, Waldek Kozaczuk <jwkoz...@gmail.com> >>>> wrote: >>>> >>>>> I would like to publish new release of OSv. The last official one was >>>>> 0.24 and published on Oct 30, 2015 (a little over 2 years). I have never >>>>> released OSv so any input and suggestions are very welcome especially >>>>> from >>>>> those that did it in the past. >>>>> >>>> >>>> I agree. The antique release is just a trap for new users, who might be >>>> tempted to use that version. So we should either make a new release, or >>>> decide we don't have any releases at all and delete the links to old >>>> releases. >>>> >>>> I think it would be nice to have a new release, if you're up to it. >>>> >>>> >>>>> >>>>> There is an existing wiki page that documents how to publish new >>>>> release - >>>>> https://github.com/cloudius-systems/osv/wiki/OSv-Release-Procedure. >>>>> However I think most of the steps do not apply anymore. >>>>> >>>> >>>> I agree, and I think then whenever we decide what should apply going >>>> forward, we should change that wiki page. >>>> >>>> >>>>> I think I should follow standard Github release procedure - >>>>> https://help.github.com/articles/creating-releases/. >>>>> >>>> >>>> I'm not sure if it's relevant either - you can use git commands to make >>>> tags. And we should use ones similar to those we used in previous releases. >>>> >>>> >>>>> >>>>> I would also like to take advantage of ability to upload binaries >>>>> associated with the release. My plan is to build and attach "osv.loader" >>>>> (aka usr.img) and "osv.bootstrap" mpm file and then let users use >>>>> mikelangelo capstan in order to build new app packages. The trick is to >>>>> build it using same or similar tool chain as other capstan packages are >>>>> built. I am planning to use same or similar docker file as here - >>>>> https://github.com/mikelangelo-project/capstan-packages in order to >>>>> avoid any incompatibility issues as described here - >>>>> https://www.mikelangelo-project.eu/2017/08/the-art-of-preparing-osv-packages/. >>>>> >>>>> I think it is important to use same host system (ubuntu 14), specific gcc >>>>> and possibly specific version of other artifacts to make sure usr.img is >>>>> compatible. >>>>> >>>> >>>> Good luck with that. I think it may take a bit of experimentation to >>>> get the version compatibility issues worked around (we can also fix many >>>> of >>>> these issues at OSv itself, but this is orthogonal to the release issues). >>>> But I have to wonder, shouldn't the compiled-package repository (for >>>> Mikelangelo Capstan) and the compiled-kernel be at the same place, and the >>>> person in charge of this place responsible to compiling them all in the >>>> same environment? How will it help if we only host the kernel, and someone >>>> else hosts the applications? >>>> >>> >> I happen to have different opinion. I think that having kernel binary >> (usr.img) available as a release artifact on OSv github page makes it >> possible to try newer version of kernel with the same application Capstan >> package *as long as both have been produced by the same tool chain*. >> This can be guaranteed by using same docker container unless I am missing >> some details. Obviously the docker file has to identify specific version of >> gcc, etc like so: >> >> RUN apt-get install gcc=4:5.3.1-1ubuntu1 #assumes ubuntu >> >> Per issue https://github.com/cloudius-systems/osv/issues/743 we should >> be using compilation/linking artifacts from host system (like libgcc_s, >> boost) which would depend on the host configuration. But again if specific >> version of artifact is pinned by Docker file then it all should be >> repeatable and resulting kernel (usr.img) should be the same every time bit >> by bit. >> >> If I was to create new docker file (based on Mikeleangelo >> capstan-packages one) what specific versions of the "golden" tool chain >> elements should I use? What distribution of Linux should I use (is Ubuntu >> better than Fedora for example?). What distribution version? >> >> Maybe use the same version of tool chain elements that Jenkins build >> server uses? >> >> >>>> >>>>> >>>>> >>>>> My goal is to make it easier for OSv newcomers to try OSv. I also want >>>>> to focus on promoting OSv as a deployment platform for stateless >>>>> services. >>>>> Therefore I would like to make it easy to build images using runtimes >>>>> like >>>>> JVM, node.js, erlang, python, ruby and eventually golang. I would be also >>>>> nice to make it easy to try apps like redis, nginx, etc. >>>>> >>>>> Some outstanding questions: >>>>> >>>>> - What should be new release version - 0.50, 0.75? >>>>> >>>>> I think 0.5. >>>> >>> OK. >> >>> >>>> >>>>> >>>>> - What should be the release notes? I think it would be worth to >>>>> at least list major new features added since last release. >>>>> >>>>> >>>> We can start digging in "git log" to compile a release notes, when the >>>> time comes. >>>> I think so much time has passed, that nobody will remember what 0.24 >>>> contained, anyway :-) >>>> In any case, the release notes should mention Mikelangelo Capstan and >>>> explain how to use it, because that is a major new thing which became >>>> relevant in this release. >>>> >>> Agree. >> >>> >>>> Thanks, >>>> Nadav. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "OSv Development" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to osv-dev+u...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "OSv Development" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/osv-dev/UF3gyDgwAMg/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> osv-dev+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> >> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
