Hi All,
Well, I decided to spend more time off the computer during the holiday. I
wanted to spend more time with family and relaxing. But, I did get a lot of
things knocked off “The Schedule” for the upcoming 1.3-RC5 release since my
last update. I won’t go into all the fine details for everything.
The "over the holiday" work mostly boils down to this kind of stuff…
A number of package updates.
Changing some stuff in the RBE and installer to handle the COMMAND.COM
differently (again).
Reworked the RBE to use the GitLab repositories for the package origins
instead of downloading the ibiblio repo CD. (I go into reasons for doing it
this way later on)
Changed some package lists.
Did some other modifications to the RBE and installers.
So, the all the changes I wanted or needed to make for the RBE and upcoming
release are done now. At present, I just need to do testing and look for any
bugs. With all the major changes to the RBE and installer since RC4, there may
be some bugs that creeped inside. I may also find some issues that pre-existed
and have not yet been reported or fixed. But, I don’t foresee any major issues.
RC5 will be coming in the very near future. :-)
In a previous discussion in the FreeDOS-User list in response to a user, I
confirmed that there is at least one broken/corrupt zip archive in the current
repository. I count not say if there was more than one from my memory. Only,
that one was buried inside another zip in the OpenGEM package. During a release
build, the RBE checks many things and stores warnings and errors in a log. Here
is the error log from todays test build.
2021-11-28 15:52:33-05:00 Warning: FDI using development branch
2021-11-28 16:01:31-05:00 warning: no sources detected for 'cpidos'
2021-11-28 16:07:40-05:00 warning: no sources detected for 'romos'
2021-11-28 16:08:28-05:00 warning: no sources detected for 'djgpp_bs'
2021-11-28 16:08:41-05:00 warning: no sources detected for 'djgpp_bn'
2021-11-28 16:08:50-05:00 warning: no sources detected for 'djgpp_fq'
2021-11-28 16:08:58-05:00 warning: no sources detected for 'djgpp_fx'
2021-11-28 16:09:17-05:00 warning: no sources detected for 'djgpp_db'
2021-11-28 16:09:25-05:00 warning: no sources detected for 'djgpp_mk'
2021-11-28 16:10:07-05:00 warning: no sources detected for 'djgpp_ob'
2021-11-28 16:10:14-05:00 warning: no sources detected for 'djgpp_rh'
2021-11-28 16:10:21-05:00 warning: no sources detected for 'djgpp_gc'
2021-11-28 16:10:44-05:00 warning: no sources detected for 'djgpp_tx'
2021-11-28 16:12:09-05:00 warning: no sources detected for 'djgpp'
2021-11-28 16:15:01-05:00 warning: no sources detected for 'i16budoc'
2021-11-28 16:15:36-05:00 warning: no sources detected for 'djgpp_gp'
2021-11-28 16:16:16-05:00 warning: no sources detected for 'i16gcdoc'
2021-11-28 16:18:22-05:00 warning: no sources detected for 'i16nlelk'
2021-11-28 16:20:49-05:00 warning: no sources detected for 'msa'
2021-11-28 16:26:55-05:00 warning: no sources detected for 'tinyasm'
2021-11-28 16:33:29-05:00 warning: no sources detected for 'fmines'
2021-11-28 16:33:32-05:00 warning: no sources detected for 'watcomf'
2021-11-28 16:37:06-05:00 warning: no sources detected for 'watcomc'
2021-11-28 16:46:19-05:00 warning: no sources detected for 'bladeenc'
2021-11-28 16:46:22-05:00 warning: no sources detected for 'cdp'
2021-11-28 16:47:31-05:00 package 'opengem', error extracting
'/SOURCE/OPENGEM/SOURCES.ZIP/PROGRAMMING TOOLKITS AND UTILITIES AND BUILD
TOOLS/atari gem programming library hexaid manual for games.zip'
2021-11-28 16:47:31-05:00 be74c0f6 crc, package error.
2021-11-28 16:48:49-05:00 warning: no sources detected for 'clamdb'
2021-11-28 16:50:21-05:00 warning: no sources detected for 'gnufonts'
2021-11-28 17:00:01-05:00 warning: iso image 'temp/fd-bonus0.iso' 622mb. It is
over 618mb and getting close to the 650mb limit
As you can see. On the GitLab repository, only one nested zip throws an error.
As a rule, nearly all zips and nested zips are fully extracted prior to storing
them in GitLab. But, I left that one as-is because it is broken. There a couple
other nested zips I leave intact as well. But, those are because I think they
are meant to be left that way.
Ok, now for the reasons I put support into the RBE to use GitLab for the origin
of packages. First, this allows updating or minor changes to the software
packages without the need to push an update to the Official Software Repository
on ibiblio. During a previous RC, there were a number of language, description
or simple metadata updates made that required updating version numbers. This
confused and/or upset some people. That will no longer be a problem going
forward. Such changes can be made (and a lot were for upcoming RC5) without
needing to update the ibiblio package. However, since the GitLab repo is
upstream of ibiblio, any changes there will propagate to ibiblio when we
eventually update those packages.
Further more, an additional option was added to the RBE specifically for
testing things. When the RBE is fetching things like the installer or packages
from GitHub and GitLab, it can be told to use development branches when they
exist. This allows for making large changes to the RBE, installers and packages
without breaking things for anyone who may wish to build a release.
Normally when you checkout/clone a Git project, the files get stamped with the
current date/time. This was an issue that annoyed many people (including me) in
RC4. A while back, I deployed a solution to remedy that issue. And now when the
RBE fetches those Git Packages, it adjusts the date/time stamps.
Unfortunately... Instead of just downloading a RepoCD, checkout/cloning of
projects is much slower. I knew that would be the case. However, it is a LOT
slower. Like 15x or more. So… I made some adjustments to the RBE and added
multi-threaded support in two very time consuming areas. The
cloning/timestamp/compression of packages and the metadata/analysis processes.
Those two processes make up roughly 60-70% (maybe more) of the compute time to
build a release. Personally, I am only running the RBE in a VirtualBox instance
with 1 CPU core and see little benefit from the threading. But if I was in a
hurry, I could throw more cores at it an cut down build time drastically.
Eventually, I may drop some of the other stuff the RBE does into threads as
well. Maybe someday, I’ll also do some optimizing to the metadata & analysis
process to speed it up some more. But, it works and is “good-enough” for now.
:-)
Jerome
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
