On Monday, May 20, 2019 at 12:30:04 PM UTC-4, Nadav Har'El wrote: > > > On Mon, May 20, 2019 at 6:48 PM Waldek Kozaczuk <[email protected] > <javascript:>> wrote: > >> In the next couple of weeks I will be trying to work on some of those >> issues. I think that eliminating external and fixing "openssl 1.0" issue >> are probably most pressing ones. I feel like we have gotten to the point >> where are some of these issues start hindering the development of the >> project. >> > > The openssl 1.0 issue is definitely annoying for me, but to be honest, it > only hurts the default module, using Lua. If you never use that, you don't > even notice it. >
It also hurts building/using anything html or node related modules/apps that use npm, which rejects working with openssl 1. Am I also right that openssl 1 has these awful vulnerabilities discovered ages ago and should not be used? > > The "external" thing is also a nusence, but we already got rid of most of > it in the past, we just need to get rid of more, and actually remove some > of the "external" options from the Makefile and whole directories from the > "external" repository. > It also makes cloning osv repo take much longer that could have been. > > Doing this properly for aarch64 cross-compilation will be more of a > challenge. I suggested some options in the issue (namely, fetch some > libraries as needed from Fedora or similar place - not from OSv's > "external" repository). > There is also a dependency on libnfs in the main makefile which I think should be refactored as a module in a similar fashion I proposed in this smb2/3 patch - https://groups.google.com/forum/#!searchin/osv-dev/smb2%7Csort:date/osv-dev/QToC22-QHiA/8EwW7uDwBgAJ . > > >> Does anybody have suggestion in what sequence we should be proceeding? >> For example even though archaic openssl causes headache, is it actually >> necessary to build kernel or run unit tests? >> > > No, it is not. It is only needed for the default "scripts/build" without > parameters, which builds Lua which needs it. > But it looks bad that our default "scripts/build" doesn't work. We could > also fix it by changing the default ;-) But the lua shell is a sensible > default. > I even have a working version of lua module that uses lua from host and only compiles lua-rocks libraries and depends on modern openssl 1.1. Should be sending patch some time soon. > > Should it be actually required in setup.py? >> >> Also recently I commited manifest_from_host.sh ( >> https://github.com/cloudius-systems/osv/blob/master/scripts/manifest_from_host.sh) >> >> script that I think can be helpful in this exercise to eliminate build from >> scratch in some of the modules by pulling artifacts from the host. >> > > Indeed. > > We can even start by having in apps/ two versions for some of the packages > - one (the existing one) which compiles from source, and another one which > just picks up the files already installed on the build machine. > > There's also a third option, similar to what we did in openjdk8-fedora: > fetch pre-compiled packages from some common Linux distributions (e.g., > Fedora or Ubuntu) and use the files from it for the image. Regardless of > what is installed on the build machine. It would be nice to work on common > scripts (like you started to manifest_from_host.sh) so new apps can be > added to apps/ easily e.g., by just calling a script and a list of Fedora > or Ubuntu packages, and the script does everything (fetching those > packages, etc.). I opened > https://github.com/cloudius-systems/osv/issues/1041 > > Thanks for that. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/0ef2db3e-5787-4fe5-926d-c7d7412ce6be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
