Hi,

the proposed patch for the boot sector documentation looks at the
topic from the PALO user perspective. But the perspective of the
file boot_sectors.txt is the one of an ISO 9660 producer.

So i would like to re-arrange the info.

How about this for the command line part ? Would it be technically correct ?
--------------------------------------------------------------------------
                    HP-PA via PALO header version 4
...
This format is expected by older versions of PALO unconditionally. It serves
as fallback for newer versions, which expect header version 5, if a 0-byte
is found at byte position 1024.
...
                      HP-PA via PALO header version 5
...
This format is expected by newer versions of PALO. They fall back to version 4
if a 0-byte is found at byte position 1024.
...
--------------------------------------------------------------------------

How to recognize a PALO that is "newer" ?
I see that in palo.git/tree/lib/common.h the value of PALOHDRVERSION
is still defined as 4.
In man xorriso i perkily assumed that it would be incremented to 5.


As for the compressed kernels:

If you plan to use them, then i need to populate bytes 220 to 227.

libisofs should be able to recognize gzip'ed files and to unpack
them for size determination, if zlib developement was available
at compile time.
I see that Debian enables this in its packages by requiring zlib1g:
  https://packages.debian.org/sid/libisofs6

Shall i implement automatic handling of compressed kernels ?

----------------------------------------------------------------------

There will be a new xorriso-1.3.7.tar.gz soon.

I just got a SIGSEV when playing with gzip compression via native xorriso
commands. It hits me when multi-session emulation updates the superblock.
A very fresh bug. I did not even commit it yet to SVN. But it is in the
tarball. Only good this is not a release version.

The SIGSEGV does not happen with mkisofs emulation, which disables
multi-session emulation by default. So valgrind did not find it when
i tested this morning. 


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to