Brief what I had for lunch. That said, I'll try to look at the code over the weekend and read the comments and suggestions here in more detail.
> > If so: > > What do you think about relying on SUSP entry "SP" instead of the > currently implemented traversal ? > Sure, if no one has any objections. > I hope that this prevents the bug and makes the whitelist of SUSP > entries obsolete. > > Do you, or anybody else here, have a copy of SUSP 1.10 ? > I don't. > Is "SP" declared mandatory already there ? > I have only SUSP 1.12. But RRIp has a version 1.10. So i expect that > for SUSP, too. > > > ----------------------------------------------------------------------- > > Second a short distraction over the Wikipedia topic. :)) > Third section will be about interaction with Kali. > > > Natalia Portillo wrote: > > If you create an interesting tool and/or structure specification > whatever, > > YOU CANNOT create the wikipedia page yourself, > > The advantage of this rule is that the one or two levels of quotation > can filter out the idiosyncrasies of manuals written by the developers > or very experienced users. > The disadvantage is that misunderstandings can sneak in, to which the > original experts would never come. > > Maybe i would have tried to tunnel underneath that rule if i had suspected > that AAIP causes problems with readers. > > > > I'm in the same situation having done DiscImageChef > > Yeah. Sometimes it is painful to see under-representation or even > mis-representation of one's work. > > Apropos: > Looking at https://github.com/claunia/DiscImageChef i miss a reference > to the El Torito boot pointers of ISO images. Is this included in the > topic "ISO 9660" ? > (One may also find MBR, GPT, Sun Disklabel, APM, MIPS Volume Header, > DEC Bootblock, PReP, CHRP, or HP-PA PALO inside ISO 9660 images. > I have a byte-level description in > https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/ > boot_sectors.txt > ) > > > Pete Batard wrote: > > Would you have a conflict of interest in editing the pages that aren't > > related to AAIP and 'AL'? > > Not really. But i am the paragon of idiosyncrasy. Nearly 10000 lines of > indigestible man pages. > > At least zisofs entry "ZF" should be mentioned. I wrote byte-level > documentation doc/zisofs_format.txt. If GitLab lets you, see: > https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/ > zisofs_format.txt > So the second party publication exists. > Now we'd need somebody to quote it into Wikipedia. > > Is there a way to approach moderators in advance ? I could submit a plan > how to restructure the Rock Ridge article and disclose my conflicts of > interest. > > > > I wasn't clear whether AAIP was to be > > considered as a something that might fall outside established standards. > > I am all in for written interfaces and established standards. > > > ----------------------------------------------------------------------- > Now for Kali: > > Pete Batard wrote: > > I can try to get back to the Kali maintainers on that, but I'm not > > sure how much they're gonna like being asked about this for the 3rd time > in > > a row... > > Is that conversation public ? I would chime in. After all they use my > software and the statement that their ISOs are like Debian's is not > really realistic. (cough) (cough) > > > > I was hoping the Kali people could point me in the right direction first. > > If the difference is indeed the use of option --hardlinks, then i am > to blame, too. The man page of xorrisofs gives no direct hint that it is > related to extended attributes inside the ISO. > > Again, i would have been more verbous if i ever suspected that a whitelist > would be implemented for SUSP fields. > > > > I'll take that as a cue to point out > > that, from what they reported, xorriso and genisoimage decided to drop > what > > they considered one of the most useful feature from mkisofs, which was to > > store the options being passed to the commandline application into the > ISO > > itself. > > Funnily i am just today busy with explaining to an ISOLINUX user why > i decided against publishing the xorrisofs options without explicit > consent by the user. > The Debian based genisoimage developers decided for the same, > independently. > > Kali stems from Debian and still does not have a file /.disk/mkisofs inside > the ISO 9660. > How did they cut this out of Debian ISO production ? > > Hrmmpf. Ubuntu does not have that file either. > > > > Maybe something that could be added to xorriso in the future? ;) > > Very firmly, with my GNU xorriso maintainer hat on: Not by default. > > I dimly remember to have read statements by FSF that we do not rat out > our users. They have to do this themselves. We may help, of course. > Any user of xorriso can fill the desired info into some data file > and let xorriso record it into the ISO. > > I propose that everybody uses the Debian protocol of /.disk/mkisofs. > Maybe with some extra info from > xorriso -version > Especially if the default Preparer Id of xorriso gets overwritten. > > Kali's ISO bears as preparer > LIVE-BUILD 1:20170213KALI1; HTTP://LIVE-SYSTEMS.ORG/DEVEL/LIVE-BUILD > > But e.g. debian-live-8.4.0-i386-standard.iso has > LIVE-BUILD 4.0.5-1; HTTP://LIVE-SYSTEMS.ORG/DEVEL/LIVE-BUILD > and no AAIP in it. > > http://www.live-systems.org redirects to landing.premiumsale.com and > yields a 504 time-out. > > > > > Trying to read e.g. > > > http://git.kali.org/gitweb/?p=live-build-config.git [...] > > > I'm not sure there's much to find in live-build-config. > > http://files.akeo.ie/live-build-config/ > > Hrmpf, nothing to see of mkisofs options or a xorriso run. > > > Have a nice day :) > > Thomas > > >
