[ TL;DR: d-i FTBFS on sparc, what do we do now? ] Thomas Schmitt <scdbackup@gmx.net> (2013-12-10): > Cyril Brulebois wrote: > > genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and > > './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''. > > [...] > > Probably some FS-dependent fun? Anyone would have a clue about it? > > Looks like an internal error of genisoimage. > > '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01. > See ECMA-119, 6.8.2.2 Identification of directories. > These names are reserved for that purpose. > Any other colliding ECMA-119 names should be handled by mangling. Thanks, Thomas. @Kurt: did anything change on the buildd setup side? Both lebrun and spontini got that FTBFS, while that wasn't the case before: https://buildd.debian.org/status/logs.php?pkg=debian-installer&arch=sparc genisoimage comes from src:cdrkit, which wasn't exactly updated in a while: http://packages.qa.debian.org/c/cdrkit.html I've got to double check what happens on smetana, but I think I didn't get that error when trying to debug this FTBFS a few months ago. I'm not sure we want to continuously give it back until it builds (which it might on schroeder, since it didn't fail there yet)… Failing a short resolution, I'm tempted to pretend sparc isn't an issue, and maybe ask for a migration to testing + dak copy-installer. @debian-release: would that sound reasonable? @ftpmasters: I'm not sure an out-of-date build is going to be OK on the dak side. What do you think? > But why is that mini.iso produced by genisoimage at all ? > debian-7.2.0-sparc-netinst.iso was produced by xorriso. @Thomas: Probably due to historical reasons. Not sure I want to be touching that since I know nothing about architecture/image-specific settings. :/ Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature