Hello, George,
thank you for your response.
I just took a look and I am quite overwhelmed by the mass
of code and stuff to do.
I was about to find an implementation for the comparison
of the Iso1999Nodes.
Unfortunately I have not found reliable specs for ISO9660:1999, 9.3.
Do you have a document or source I could use, please?
Thank you very much and regards,
Sebastian
Am Donnerstag, den 02.08.2012, 12:28 +0200 schrieb George Danchev:
Just bouncing this one to serve as a reference, since I forgot to do it in
the
first place when replying. Further discissions will take plane in the pkg-
list.
On Wednesday 01 August 2012 21:28:22 bash.d wrote:
Hello, George Danchev,
I would like to help you maintaining the libisofs-package.
I already replied to the BTS entry, but have not yet received any
response. If you are interested, please answer me.
Thank you and regards,
Hi Sebastian, [I added pkg-libburnia-devel@ in CC, where Thomas Schmitt is
also subscribed]
Thank you for your offer to help, it is really appreciated. It is of course
my
fault of not paying attention close to RFH#679254, but you did it right
pinging my on private. Thanks!
The three libraries of libburn (RFH#679249), libisofs, and libisoburn
(RFH#679265) are best to be maintained together, and involve quite some
interaction with upstream, which is fortunately very responsive and helpful.
See http://libburnia-project.org for details, and the upstream list is
libburn-hack...@pykix.org.
For libisofs in particular, there is an effort to complete the hybrid fs
part,
which involves HFS+ (see libisofs/hfsplus*.c|h in bzr) and HFS (no plus) - no
code yet. ISO9660/HFS hybrid is used for the production of Debian PowerPC
images, and in order to replace the old and almost unmaintained genisoimage,
it would be nice to have this one properly implemented, verified and deployed.
(actually these are HFS#630351 and UDF#630863, the latter being a goal in the
distant future).
The libburnia libraries are covered by in-house test suite called 'releng':
See, README, TODO and CHECKLIST, as well as the code at:
http://libburnia-project.org/browser/libisoburn/trunk/releng
Extending and running this test suite is a good way to build trust that no or
less regressions would occur.
Then comes the debian-cd task, which is the largest stress-test suite for
xorriso (and resp. libisofs in particular) currently known to us, so it is
also nice to pay attention to debian-cd BTS record for relevant bugs, the
debian-cd mailing list for relevant complaints, and debian-cd live logs as
well: http://cdbuilder.debian.org/cdimage-log/ (also see analysis.html)
Last, but not least, it is also nice to try to help applications which are
trying to make proper use (or resp. abuse) of libburnia libraries to find
their
way. For instance, see brasero BTS record.
To summarize: there is a plenty of code work, thrice as much testing and bug
triaging and sorting out (coupled and decoupled) issues or non-issues... and
I'm pretty sure Thomas can add some more points as well. While it is true
that
libburn/libisofs/libisoburn currently bear almost perfectly clean BTS log
record, it took, takes, and will take a fair amount of time to preserve this
state as it is.
So, feel free to pick your niche to contribute to the project :)
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1344024158.1906.4.camel@debtop
