> On Nov 3, 2024, at 4:53 AM, Wilhelm Spiegl via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > Hi, > > forgot to report the following message with the Bonus CD: > > fdimples shows that fbc_help in section development is / will not be > installed. > It exits with an error message: > > "Package contains a file that already exists locally: > c:\devel\fbc\lfnfiles.zip.
Thanks. Hmmm. That was caused by having two packages that contain LFN files installing into the same directory. They sendup both having a LFNFILES.ZIP. I simply manually compressed the files in FBC-HELP into a different file called LFN-HTML.ZIP in the Help package. Should be good for T2412. > So fdimples shows the missing packet at the next start again. Speaking of FDIMPLES, the English translation file on FD-NLS has two new keys. Those new keys are for the long names of the two new package groups. :-) > > b) I will send country-fixed from Laaca to you with an extra mail. Thx, Laaca! I incorporated that update into the Kernel package on GitLab. It will be in T2412. However, you NEED to submit this to https://github.com/FDOS/kernel If you do not, when the next kernel version is released, these changes will be lost. They will be replaced by the files that are provided by a new kernel. > > rcal: So it was intention not to add a folder "rcal"? Looks a little bit > strange, but OK. > Paul Dufresne is maintaining that package and would be the one to say if it was intentional or not. Perhaps for consistency it could be moved into UTIL\RCAL\rcal.exe. But as long as it does not conflict with anything else, works properly and does not cause issues building a release, I am satisfied with where it is now. > > Willi > > > Sent: Sunday, November 03, 2024 at 1:14 AM > From: "Jerome Shidel via Freedos-devel" <freedos-devel@lists.sourceforge.net> > To: freedos-devel@lists.sourceforge.net > Cc: "Jerome Shidel" <jer...@shidel.net> > Subject: Re: [Freedos-devel] FreeDOS Interim Build T2411 > > hi > > > On Nov 2, 2024, at 3:29 PM, Fritz Mueller via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > > Hi Jerome, hi all, > thx for this great job! I always admire these FDT versions! > Every month you update several commands / files! > > Some minor important hints for the next FDT (you already know most of them): > > a) bladeenc 0.94.1 is installed, but "fnpkgk checkupdates" finds 0.94.1a and > downloads and > "updates" it with "fdnpkg install bladeenc". > The files are identical, except cwsdpmi, which is NOT delivered with the > update but with the CD. > > This is regarding the Download/Update Repository. See below. > > > b) As already reported: country.sys has a bug with CP 858 and country 49. I > have a working > country.sys + asm file from Laaca (thank you very much!) but I fear Jerome > will not accept it for > common usage. > > ? > > > b) rcal has no own folder "rcal" at C:\util. There are only the two files at > C:\util. Please do not forget to change > the link at c:\freedos\links\rcal.com in case that you change this. > > Perhaps it should be moved into a sub-directory and have its Batch Link file > updated. > > d) If you run "fdnpkg install compute" only THREE NLS files will be > installed, CZ,EN,RU, although there > are much more at Shidel's NLS Website. > > > I know I replied to this in a previous off-list email. But, I will do so > again here and in greater detail for everyone’s benefit. > > First, COMPUTE is not included in the release. It is currently an online only > package. > > This is not directly related to the interim test build. It is a > Download/Update Repository issue. > > It is a bad idea to update packages and not update the package version for > several. > > The primary reason is version identification. > > If a user already has a package installed and browses the HTML version of the > Update Repository, they will see the version number and assume it has not > been updated. > > Running FDNPKG to update the package will also not work directly. It will see > that the version number is the same and also assume it does not require an > update. > > The Repository itself should actually accept the package update because they > are not actually identical. However, it becomes confusing for us humans when > managing stuff. > > From the management standpoint, there are two possibilities. > > One… pull the existing package and replace it with the updated package. This > is not a good solution because humans and software will not recognize it as > an update. This is a long standing known problem. It is one of the primary > reasons the Repository Management Utilities insert a Modified-Date field into > the package metadata when added to a repo the first time. The intent being > that the field will be used instead of the Version field for detecting and > determining what gets updated. But, that is in the future at some much later > time. > > Second, is to artificially bump the package number. Like BladeEnc 0.94.1 to > 0.94.1a. But, this is also less than ideal. This was done to a lot of > packages a long while back when numerous NLS updates was provided. It caused > some confusion. So, Many of such had the version numbers restored to the > actual program version when we started staging packages on GitLab. But, not > all. Or, not in both locations. It is a very tedious and time consuming > process to pull and replace packages in the download/update repositories. But > simple to bump the version of a modified package. > > Bumping the version also comes with other issues. One of which is version > numbering conflicts. For example, what if tomorrow there is a real bug fix > update for BladeEnc that is version 0.94.1a. > > Like I said, there are good solutions planned. But, they will take a time > fully roll out. > > Also, we are coming up on releasing FreeDOS 1.4 in the near future. Before > that happens, a new 1.4 Download/Update repository will be created and config > files provided in the release will be pointed at that repo. The repo will > start with the package versions available on GitLab at release time. > > The 1.4 repo will probably be created and configuration adjustments sometime > in the next few days. T2412 will point to the new repo. > > e) A full installation with all programming tools requires in about 650 - 700 > MB on a HD. The standard > HD size is 500 MB. So either the programming files should be reduced in size > for more than > 150 MB or the HD size should be updated. Reason: Some People like it "to > install simply everything" > and are then shocked to see that the HD is too small.. > I am not sure if Erics proposals are enough to reduce the full Installation > to 500 MB. So there should > be a discussion if the size of the installation partition could be expanded > (at least at the versions > that support the Bonus CD). > > ? > > Per the generated report and readme, a full install requires 325Mib. Full > with sources requires 500Mib. Packages on the BonusCD are bonus packages and > are not included in that size requirement calculations. > > Possibly the Readme could be updated to say something like “Installing > packages from the BonusCD could require up to an additional 1Gib of storage > space.” > > I don’t know where you got the “500 Gib is Standard” for an installation. > > Fritz / Willi > > Jerome > > > > > > > Sent: Friday, November 01, 2024 at 12:37 PM > From: "Jerome Shidel via Freedos-devel" <freedos-devel@lists.sourceforge.net> > To: "FreeDOS Developers" <freedos-devel@lists.sourceforge.net> > Cc: jer...@shidel.net > Subject: [Freedos-devel] FreeDOS Interim Build T2411 > The FreeDOS Interim Test Build T2411 for November is now available for > download at: > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ > <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/> > > Besides all of the messages I sent to the Devel Mailing list regarding > changes that were coming in T2411, there were some package updates as well. > > 2024-10-29 15:27:01 project_FDI [unstable] (Shidel): added line break before > CD Status message > 2024-10-29 05:30:20 project_FDI [unstable] (Shidel): package group migration > 2024-10-28 13:28:17 sqlite (Shidel): updated to v3.46.1r1 > 2024-10-28 12:34:19 project_FD-NLS (Shidel): FDIMPLES: Two new group names > 2024-10-28 12:21:06 fdimples (Shidel): Added 2 new Long Package Group Names > to NLS > 2024-10-28 07:49:40 project_RBE (Shidel): package group migration > 2024-10-28 07:33:03 project_FDI-x86 [unstable] (Shidel): package group > migration > 2024-10-28 07:31:30 format [unstable] (Shidel): Format NLS is compile time, > not runtime > 2024-10-27 15:57:56 project_RBE (Shidel): Include BonusCD on FullUSB > 2024-10-27 15:49:13 project_FDI [unstable] (Shidel): Config changes, increase > FullUSB to 1 Gib > 2024-10-26 22:26:26 mtcp (Shidel): Include copy of License in project root > 2024-10-26 22:19:39 mtcp (Shidel): Updated to v2024-10-20, without HTTPSERV > or NetDrive > 2024-10-26 15:58:50 project_FD-NLS (Shidel): from W.Spiegl > 2024-10-26 15:21:53 wde (Shidel): Updated to v1.1 > 2024-10-26 14:38:58 format [unstable] (Shidel): Updated to 0.92a (pre-release) > 2024-10-26 06:56:28 project_FD-NLS (Shidel): update from W.Spiegl > 2024-10-26 05:57:23 htmlhelp [unstable] (Shidel): Turkish NLS codepage > correction > 2024-10-26 04:11:47 freedoom (Shidel): WADs updated to v0.13.0 > 2024-10-25 15:23:29 project_FD-NLS (Shidel): report update > 2024-10-25 14:55:04 project_FD-NLS (Shidel): from W.Spiegl > 2024-10-02 15:21:35 gopherus (shidel): adjusted LINKS file > 2024-10-02 12:50:51 rcal [unstable] (Paul Dufresne): fix link rcal.bat to be > on UTIL\RCAL.COM <http://rcal.com/> rather than UTIL\RCAL\RCAL.EXE > 2024-10-01 13:08:21 project_FDI [unstable] (shidel): add kittenc to BonusCD > 2024-10-01 11:09:40 utf8tocp (shidel): corrected LINK file > 2024-10-01 11:08:04 picosntp (shidel): removed LINK file > 2024-10-01 11:02:31 lame (shidel): removed LINK file > 2024-10-01 01:24:05 fdimples (shidel): update for finding new BonusCD > > :-) > > Jerome > _______________________________________________ Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <https://lists.sourceforge.net/lists/listinfo/freedos-devel>_______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <https://lists.sourceforge.net/lists/listinfo/freedos-devel>_______________________________________________ > Freedos-devel mailing list Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > <https://lists.sourceforge.net/lists/listinfo/freedos-devel>_______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
