Hi Wolf & Tom, > On Dec 2, 2024, at 4:00 PM, tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > Hallo Herr Wolf Bergenheim via Freedos-devel, > > am Montag, 2. Dezember 2024 um 21:01 schrieben Sie: > >> Hey, > >> Changelog says DOG was upgraded to 0.8.5b but >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/dog.html >> says 0.8.4b and on that page it also links to somthing called 0.8.3c??
The unstable and 1.3 update repositories have not been updated with the latest version of Dog at preset. 0.8.3c would have been some changes made to the 0.8.3b version. It got a version bump so it would not be confused with the existing 0.8.3b package by any of the programs that update packages. > > so that answers my earlier question: > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.4/util/dog.zip > > has a "last modified date" of 2024-11-03 03:41, > but contains 0.8.4b from Jun 2024, and is NOT the newest release. > > additionally, > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.4/base/kernel.zip/doc/readme.md > describes > > See the DOCS directory for more documentation and information > about > the FreeDOS Kernel. > > Contents of release zip files: > ke20xx_16.zip : binaries for 8086, FAT16 > ke20xx_32.zip : binaries for 8086, FAT16, FAT32 > ke20xxsrc.zip : sources for the kernel > > where > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.4/base/kernel.zip/bin > > has only (without further description) KERNL86.SYS, KERNL86N.SYS and > KERNL386.SYS with whatever functionality. While the (1.2, 1.3, 1.4 and unstable) repositories manage themselves, there is no automation to upload packages from the GitLab Archive. All packages for the release media and the update repositories are first staged there. Then when I have the time, I hand those packages over to the repositories to deal with. For technical reasons regarding meta data consistency, I usually first give them to my server at http://fd.lod.bz and let it perform the modifications to the metadata. Then, I will fetch them back from my server and post them to various repositories on IBIBLIO. The modifications to the metadata are involving the Modified-date field in the LSM file. Normally, this field does not already exist in that file. When a repository receives a package without this field, it dynamically creates it based on the current date + a revision number. It then inserts this into the LSM file. If this field exists, it will be left unmodified. Eventually, I would like to see this field be what is used to determine if a package is newer or older than the one currently installed. This insertion can only be performed by one machine. Zipping and unzipping on different machines with different versions of external utilities results in different hash values. As I said, I let my server perform that insertion. I do that for two reasons. First, my server updates it’s repository hourly. IBIBLIO is configured to do it once a day. Second, I have only one repository on my server. IBIBLIO has 4 different managed repositories. For the most part, the 1.2 repository only receives critical updates. After 1.4 is released, I think 1.2 will be considered end-of-life. The 1.3 repository receives nearly all updated packages. After 1.4, this will get critical updates only. The unstable get most (but not all) package updates. The 1.4 repository is not officially online yet. If you look at the index page for the repositories, you will see it is not listed! https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html> It will not officially be online until FreeDOS 1.4 is released. At some point after each interim build, I delete the entire 1.4 repository and copy the packages from the FullUSB to that repository and tell the management software to rebuild it. I did not do that until a few minutes ago. It should be up to date now. However, the process will be different when FreeDOS 1.4 is released. Because I manually jammed the packages into that repo, they do not have the additional metadata for the modified-date inserted into them. When 1.4 comes out, I will use the management software to add them and therefore they will get the additional field data inserted. As for the 1.3 and unstable repositories lagging behind on updates… I will get around to them eventually when I have the time and energy to update them. Part of the problem is that when a package is updated, it MUST get an updated version number. This is not an issue with the repository itself. They don’t actually care and can deal with duplicate version numbers. The problem is that the clients will not see them as being an update. Version numbers is also a minor issue for the CI/CD on GitLab. While updates can be merged and committed without changing the version number, the CI/CD will see that the version has not “changed” and not create a new “release”. This is not a problem for the RBE3 (or RBE4). They do not download those package release files. The RBE checks out the project and builds its own package based on the branch being used for the OS build. The RBE could not care less about actual version numbers. > What a mess... While things could be better, it is not too bad. Too say management of this stuff is short-staffed is a huge understatement. Therefore some things are going to fall behind from simple prioritization. As I have mentioned several times in the past, I have only so much time I can devote to FreeDOS. Unfortunately, that will be even less in the future. The situation would be quite dire if I had not automated most of the package management and release building processes. > And the list has nothing better to do then having lenghty arguments about UPX > licensing... Agreed. While it is important to try and clear up any licensing confusion, there are other things that we can do that are beneficial to FreeDOS. Anything that helps save me time doing all this stuff is a big plus. For example, when there is an update to a program, update the package at GitLab and issue a merge request. While many are easy to update, others are not. They all take time. Time that could be freed up for me to do other things. Like update the repository packages, work on RBE4, improve my own FreeDOS programs like FDIMPLES, run down some odd edge case issues, etc. There are number of really cool projects which I have started that end up being pushed onto a shelf for later because of the lack of time. V8Turbo, Blinky’s Adventure and the FD-NLS Desktop app are to just name a couple. There are many ways the community can contribute to make everything better. FreeDOS is an open source community project. > > > Tom > Jerome
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
