libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension
Date: Tue, 25 Jul 2017 19:29:25 -0400

The beginning got truncated. It should have read something like that code
is over a decade old and
and I don't remember much about it (or what I had for lunch yesterday).

But I will try to read the discussion and code over the weekend if I can.





On Tue, Jul 25, 2017 at 7:27 PM, Rocky Bernstein <address@hidden> wrote:

> 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/z
>> isofs_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
>>
>>
>>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]