Hi, Kai Engert wrote: > If growisofs is going to survive for another few years, then maybe it's > worth keeping the toolchain alive? (which requires genisoimage)
xorriso can substitue for mkisofs and genisoimage by help of its link "xorrisofs" and the growisofs variable "MKISOFS". man xorrisofs has an example: $ export MKISOFS="xorrisofs" $ growisofs -Z /dev/dvd /some/files $ growisofs -M /dev/dvd /more/files If no "xorrisofs" is available on your system, then you will have to create a link pointing to the xorriso binary and tell growisofs to use it. E.g. by: $ ln -s $(which xorriso) "$HOME/xorrisofs" $ export MKISOFS="$HOME/xorrisofs" > Is there a primary repository somewhere (e.g. github) that is equivalent to > the most recent cdrkit release that debian and fedora packages are based on? The original repo is gone, i fear. This here looks like going back to the fork from cdrtools in 2006: https://code.launchpad.net/ubuntu/+source/cdrkit It knows my Launchpad Id and offers git clone git+ssh://scdbac...@git.launchpad.net/ubuntu/+source/cdrkit I guess you get at least offered git clone https://git.launchpad.net/ubuntu/+source/cdrkit > Is there an official download location for the most recent tar archive, or > would it be fine to simple use the archive found in the debian package? The most recent Debian package https://packages.debian.org/unstable/genisoimage is obviously based on http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11.orig.tar.gz http://deb.debian.org/debian/pool/main/c/cdrkit/cdrkit_1.1.11-3.2.debian.tar.xz You may inspect the source online at https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/ > Maybe Sam's other changes should be ignored / kept separate. At least other changes should be kept out of the game until you unpacked the original source, applied at least the two bitrot patches from https://sources.debian.org/src/cdrkit/9:1.1.11-3.2/debian/patches/ (namely "fix_libcap_detection.patch" and "gcc10.patch".), and managed to build the binaries. > Regarding the 2038 issue and time64_t, you referred to a iso_date function > and to a filename that I cannot find in the cdrkit archive. That bug sits in the Linux kernel. Line 19 and 22 in https://github.com/torvalds/linux/blob/master/fs/isofs/util.c Line 109 in https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h > Regardless, is my understanding correct that the 2038 bug will be limited to > 32bit platforms, because on 64bit platforms time_t is already sufficiently > big to avoid the 2038 bug? The current type is int, not time_t. I don't expect that int will become 64 bit on the then mainstream architectures before kernels get compiled which are expected to be still on duty when 2038 arrives. I have a patch with demonstration of the problem by xorriso -outdev /tmp/test_date.iso \ -blank as_needed \ -map /bin/true /victim \ -alter_date m 'Oct 01 22:06:12 2040' /victim -- When mounted the kernel returns the victim's timestamp as Aug 26 1904 But i gave up on submitting Linux patches after even a kernel Oops on powerpc64 was ignored. Maybe i learn to know somebody until 2038 who has the standing to get at least a review for a patch submission. (Another isofs bug is about Rock Ridge names of byte length 254 or 255, which get shown massively truncateid by Linux - up to name collisions. More bugs are around in cdrom and sr.) Have a nice day :) Thomas