I have the DVD edition available as an iso attached to /dev/loop0, and as a VHBA mounted iso in /dev/sr1. Neither seems to be detected by this ebuild. Despite me having CONFIG_JOLIET=y in the kernel, the ebuild redundantly suggests I enable it when it fails to detect the disc. A much more reliable way to address this issue would be to expect that the iso9660 of the CD set, or DVD, or a symlink to anything that represents them (like a real drive), will be present in distfiles. What next we can do without the toil of mounting is to pluck all the files through isoinfo. By knowing the sha256s of the CD set and DVD edition, we can also make sure that we have the correct source data.
I see what the problem is. The ebuild does not support the DVD edition correctly. It seems to really want the CD edition. ``` * Call stack: * ebuild.sh, line 136: Called src_unpack * environment, line 2229: Called cdrom_get_cds 'System/UT2004.ini' 'Textures/2K4Fonts.utx.uz2' 'Textures/ONSDeadVehicles-TX.utx.uz2' 'StaticMeshes/AlienTech.usx.uz2' 'Speech/ons.xml' 'Sounds/TauntPack.det_uax.uz2' * environment, line 668: Called cdrom_load_next_cd * environment, line 703: Called die * The specific snippet of code: * die "unable to locate CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"; * * If you need support, post the output of `emerge --info '=games-fps/ut2004-data-3186-r5::gentoo'`, * the complete build log and the output of `emerge -pqv '=games-fps/ut2004-data-3186-r5::gentoo'`. * The complete build log is located at '/var/tmp/portage/games-fps/ut2004-data-3186-r5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-fps/ut2004-data-3186-r5/temp/environment'. * Working directory: '/var/tmp/portage/games-fps/ut2004-data-3186-r5/work' * S: '/var/tmp/portage/games-fps/ut2004-data-3186-r5/work' Leela ~ # for i in System/UT2004.ini Textures/2K4Fonts.utx.uz2 Textures/ONSDeadVehicles-TX.utx.uz2 StaticMeshes/AlienTech.usx.uz2 Speech/ons.xml Sounds/TauntPack.det_uax.uz2; do file /run/media/mdec/UT2004_DVD/CD1/${i}; done /run/media/mdec/UT2004_DVD/CD1/System/UT2004.ini: Generic INItialization configuration [FirstRun] /run/media/mdec/UT2004_DVD/CD1/Textures/2K4Fonts.utx.uz2: cannot open `/run/media/mdec/UT2004_DVD/CD1/Textures/2K4Fonts.utx.uz2' (No such file or directory) /run/media/mdec/UT2004_DVD/CD1/Textures/ONSDeadVehicles-TX.utx.uz2: cannot open `/run/media/mdec/UT2004_DVD/CD1/Textures/ONSDeadVehicles-TX.utx.uz2' (No such file or directory) /run/media/mdec/UT2004_DVD/CD1/StaticMeshes/AlienTech.usx.uz2: cannot open `/run/media/mdec/UT2004_DVD/CD1/StaticMeshes/AlienTech.usx.uz2' (No such file or directory) /run/media/mdec/UT2004_DVD/CD1/Speech/ons.xml: cannot open `/run/media/mdec/UT2004_DVD/CD1/Speech/ons.xml' (No such file or directory) /run/media/mdec/UT2004_DVD/CD1/Sounds/TauntPack.det_uax.uz2: cannot open `/run/media/mdec/UT2004_DVD/CD1/Sounds/TauntPack.det_uax.uz2' (No such file or directory) Leela ~ # find /run/media/mdec/UT2004_DVD -name 2K4Fonts.utx.uz2 /run/media/mdec/UT2004_DVD/CD2/Textures/2K4Fonts.utx.uz2 ```
I do care about this working so please attach the full build log.
I'd almost forgotten, but I started rewriting this ebuild 5 years ago because it doesn't use cdrom.eclass properly, which probably isn't helping here. Unfortunately, I never got around to finishing it. It was tricky because I only have the Midway Anthology.
I have a physical DVD and drive if this needs any testing with those, though the last time I reinstalled this was on a diskless machine and I had to mount it over network.
Created attachment 892690 [details] Log of trying to emerge the package The exact command used: CD_ROOT=/run/media/mdec/UT2004_DVD emerge --resume The reason why is because this is part of a full rebuild due to upgrading from 17.1 profile to 23.0 profile.
@Enne I've noticed that this package does a couple interesting things. First of all, it will try to look in CD_ROOT for viable copies. If it fails, then it will see which optical drives are mounted and then look for viable copies in all mounted optical drives. The evidence for this behavior check is that I can run it with `CD_ROOT=/absolutely/nowhere emerge --resume`, pointing to a path that doesn't exist, and then it prints this: * Searching /absolutely/nowhere * Searching /run/media/mdec/UT2004_DVD Contrary to what I said before, the package started working when I presented it with a CD_ROOT that pointed to where I mounted the ISO file directly.
For what it's worth, the DVD release I have has a sha256sum of 027b2cc4a728a92500afb3a999cb1015f665af81b266f46c1a2199646d89861c and size of 3916517376 bytes, and isoinfo -debug -d -i of it presents this info: Setting input-charset to 'UTF-8' from locale. CD-ROM is in ISO 9660 format System id: Volume id: UT2004_DVD Volume set id: Publisher id: ATARI Data preparer id: EPIC_GAMES Application id: UNREAL_TOURNAMENT_2004 Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 1912512 Root directory extent: 19 size: 2048 Path table size is: 826 L Path table start: 130 L Path opt table start: 0 M Path table start: 131 M Path opt table start: 0 Creation Date: 2004 03 04 05:02:00.00 Modification Date: 2004 03 04 05:02:00.00 Expiration Date: 0000 00 00 00:00:00.00 Effective Date: 0000 00 00 00:00:00.00 File structure version: 1 Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: '' Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: '' Joliet with UCS level 3 found. No SUSP/Rock Ridge present Meanwhile if we use the Joliet descriptor with `isoinfo -J -debug -d -i`, it prints: Setting input-charset to 'UTF-8' from locale. CD-ROM is in ISO 9660 format Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: '' Joliet escape sequence 0: '%' 1: '/' 2: 'E' 3: '' Joliet with UCS level 3 found, Joliet volume descriptor: System id: Volume id: UT2004_DVD Volume set id: Publisher id: ATARI Data preparer id: EPIC_GAMES Application id: UNREAL_TOURNAMENT_2004 Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 1912512 Root directory extent: 132 size: 2048 Path table size is: 1170 L Path table start: 265 L Path opt table start: 0 M Path table start: 266 M Path opt table start: 0 Creation Date: 2004 03 04 05:02:00.00 Modification Date: 2004 03 04 05:02:00.00 Expiration Date: 0000 00 00 00:00:00.00 Effective Date: 0000 00 00 00:00:00.00 File structure version: 1 No SUSP/Rock Ridge present This is for the sake of being certain that we as owners of the DVD release are on the same page.
I'm glad you managed to find a way around it. I can see that it actually thought you had the CD set rather than the DVD. That's ironic because the ebuild code suggests that it would always choose DVD. I'm therefore still not sure why it failed. The code is awful though, not least because it treats the DVDs as 6 separate disks rather than 1. cdrom.eclass is versatile enough to do this properly. I'll try to revisit my rewrite, but admittedly it's not top of my list.
> I'm therefore still not sure why it failed My guess is that it really doesn't like it when gvfs/udisks handles mounting. I had to manually mount the ISO, rather than let my desktop environment swoop in and automount the disc it detected in a virtual VHBA optical drive.
(In reply to James Le Cuirot from comment #8) > The code is awful though, not least because it > treats the DVDs as 6 separate disks rather than 1. It's a mess, but IIRC it was originally done that way because the DVD just has the contents of the CDs as CD[123456]/ subfolders and practically speaking it means slightly less diverging codepaths. I've tracked down my disc and `sha256sum /dev/sr0` also says "027b2cc4a728a92500afb3a9…" so I've nothing to add there. I could dump a directory/shasum listing of the disc (or just the parts the ebuild doesn't install) if it's useful to have in this bug. (In reply to Michał Dec from comment #9) > My guess is that it really doesn't like it when gvfs/udisks handles > mounting. Yeah, gvfs (or to be specific, FUSE) does weird things with filesystem permissions. By default they're completely off limits to other users, even root. I guess it's done that way because userspace encrypted fs implementations need it for security.
