Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension

[Rocky Bernstein]

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
>
>
>