It seems that all the split distributions of Schily's tools have been replaced by a single huge schily-tools tree [1]. After reporting a bug to star, the author told me to use the latter. I suppose we'll need to migrate all our packages to them then, and figure out how to version and build them sanely. [1]:https://sourceforge.net/projects/schilytools/
The schily-tools exist for quite some time now. It just seems smake, star and cdrtools are not released separately any more. If I remember correctly I tried to build from the schily-tools but eventually gave up. Versioning should not be a problem, we can just use the release date can't we? Building all this stuff sanely will be the bigger issue.
By versioning, I meant we'd have to check whether the new version includes any (possibly indirect?) changes to the tool in question.
Schilytools exist since December 2007. Since it is hard to create frequent separate releases for various tools, it is easier to mostly concentrate on one consistent release of schilytools. Platforms that like to install the libraries from the schilytools as shared libraries need to use schilytools anyway since this is the only way to maintain consistency in the library versions. Note that there recently has been a need to introduce incompatible library changes in libfind and libschily thsat resulted in a new major version for these libs.
*** Bug 678914 has been marked as a duplicate of this bug. ***
*** Bug 678918 has been marked as a duplicate of this bug. ***
Martin Väth already put some effort in creating an ebuild for schily-tools.
We _really_ should schily-tools into Gentoo soon. There is now another problem with the old, standalone Schily ebuilds - app-cdr/cdrtools fail to build on riscv - and while I haven't checked if schily-tools build there yet, at least that upstream is still active.
It would be interesting, whether cdrtools fail to build on riscv because someone used the non-automake aware gnu-make or whether there are real problems. Since smake is including special automake features, it is possible to auto-create platform specific definitions with make rules. If you like to be fast and report problems before the next release, I encourage you to download the current z/OS test tarball schily-dist-os_390-test.tar.bz2 and check whether it works for you. Note that the next regular release will be ready in a few days. That mainly depends on how long it takes to make SunPro Make working on z/OS. Important: Unless you handcraft the make command line, a make on the top level directory of schilytools always uses a bootstrap smake that is compiled first. This is mainly because gmake is nearly unmaintained and e.g. fails in parallel mode because it misses to implement concepts for serialization for certain cases. Smake also gives much more portability than gmake and thus (even as a serial make) still is the reference make implementation. BTW: If you like to compile in parallel mode, I recommend to compile and install SunPro Make that is part of the schilytools. See README.compile on how to use "dmake" (SunPro Make) in the schilytools top level directory.
Pinging this bug one last time. Jörg Schilling is gone. RIP.
Should have updated this earlier. The schilytools have new maintainers and the project is now hosted at https://codeberg.org/schilytools/schilytools. They did contact distribution maintainers about the new situation but until now I did not get back to them. I have something based on Martins work which should be installable but I am not sure it meets our standards. Can attach it later. However I think this would be a good time to get in close contact with the new maintainers. Maybe it is possible to clean up this little monster. To be sure, I don't think I have the time or the will to do this myself.
*** Bug 885073 has been marked as a duplicate of this bug. ***
Created attachment 848452 [details] schily-tools-2023.01.12.ebuild Ebuild for the most recent version based on https://github.com/vaeth/mv-overlay/tree/main/app-shells/schily-tools from Martin Väth.
(In reply to Daniel Pielmeier from comment #12) > Created attachment 848452 [details] > schily-tools-2023.01.12.ebuild > > Ebuild for the most recent version based on > https://github.com/vaeth/mv-overlay/tree/main/app-shells/schily-tools from > Martin Väth. It's pure horror and violation of multiple QA rules.
(In reply to Michał Górny from comment #13) > (In reply to Daniel Pielmeier from comment #12) > > Created attachment 848452 [details] > > schily-tools-2023.01.12.ebuild > > > > Ebuild for the most recent version based on > > https://github.com/vaeth/mv-overlay/tree/main/app-shells/schily-tools from > > Martin Väth. > > It's pure horror and violation of multiple QA rules. So no big difference to the cdrtools. :-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d479020a18c69c066f3ec1e8862e30d3c84422ee commit d479020a18c69c066f3ec1e8862e30d3c84422ee Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-16 08:22:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-16 08:23:55 +0000 app-cdr/cdrtools: apply modern C workaround, correctness fixes * Apply modern C workaround (build with -std=gnu89 for now). No point in trying to patch this at least until we're up to date (see bug #672060) which has its own complications. * Filter LTO & pass -fno-strict-aliasing. The code isn't even close to being compatible with either. Bug: https://bugs.gentoo.org/672060 Closes: https://bugs.gentoo.org/884771 Closes: https://bugs.gentoo.org/898582 Closes: https://bugs.gentoo.org/903876 Signed-off-by: Sam James <sam@gentoo.org> app-cdr/cdrtools/cdrtools-3.02_alpha09-r5.ebuild | 309 +++++++++++++++++++++++ 1 file changed, 309 insertions(+)
Is there an upstream bug at https://codeberg.org/schilytools/schilytools/issues to allow us to follow the (eventual) progress? Thanks
