[bug#28398] Xfburn

[ng0 <ng0@n0.is>]

[-- Attachment #1: Type: text/plain, Size: 5886 bytes --]

Hi,

Many thanks for the in-depth review and hints! I don't
have the time for immediate questions or patching, so
I'll followup later. I just wanted to express my thanks.

Thomas Schmitt transcribed 5.0K bytes:
> Hi,
> 
> ng0 wrote:
> > I've applied your suggestions
> > and the ones Christopher had a while back in this new version
> > of the patches.
> 
> The inappropriate word "mastering" is still in one of the two description
> texts in the libburn patch
> 
> > +    (synopsis "Library for reading and writing optical discs")
> > +    (description
> > +     "Libburn is a library for reading, mastering and writing optical discs.
> 
> 
> (It is also still in the description of the current Debian package. But
>  that's only due to the long release cycle. The next Debian package will
>  state what is committed by
>    https://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/control?r1=428&r2=430
> )
> 
> ------------------------------------------------------------------------
> 
> With Xfburn, consider to mention BD (Blu-ray) media additionally to CD and
> DVD media. 
> 
> > +    (synopsis "GTK+ based CD and DVD burning application")
> > +    (description
> > +     "Xfburn is a simple CD/DVD burning tool based on libburnia
> > +libraries.  It can blank CD/DVD(-RW)s, burn and create iso images,
> > +audio CDs, as well as burn personal compositions of data to either
> > +CD or DVD.")
> 
> I can confirm that "xfburn version 0.5.2 for Xfce 4.10" recognizes and
> burns single layer BD-RE and BD-R media. Users of libburn report success
> with multi-layer BD-RE and BD-R media.
> 
> ------------------------------------------------------------------------
> 
> Did we already talk about these lines in the libburn patch ?
> 
> > +     `(#:configure-flags (list "--enable-libcdio")))
> > +    (inputs
> > +     `(("libcdio" ,libcdio)))
> 
> If they shall by default let libburn use the SCSI transport mechanism of
> libcdio, then better don't do this.
> 
> Without wanting to badmouth libcdio, it turned out that its SCSI/MMC layer
> is needy of modernization and that it does not provide usable SCSI transport
> on operating systems which libburn cannot handle by its own system adapters.
> libburn has SCSI-capable adapters for Linux The Kernel, FreeBSD, Solaris,
> NetBSD, OpenBSD.
> 
> In Hurd/Mach The Kernel we have no SCSI transport facility from userland to
> optical drives, i fear. There, libburn can only operate on data files and
> read-write block devices. Useful mainly as foundation for xorriso to make
> ISO 9660 filesystem images.
> 
> The shortcommings of libcdio towards libburn's sg-linux.c adapter are mainly
> with receiving SCSI error conditions (aka Sense Data) from the drive and
> forwarding them to libburn.
> 
> So my advise is not to configure libburn with --enable-libcdio and not to
> declare libcdio a dependency of libburn.
> 
> ------------------------------------------------------------------------
> 
> I also looked at the libisofs related patch:
> 
> > +    (inputs
> > +     `(("zlib" ,zlib)))
> 
> If ./configure sees libacl and libattr on GNU/Linux, then libisofs will link
> to it and enable recording of ACL and extended file attributes.
> 
> Looking for "acl" in Guix, i found
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/acl.scm?id=v0.13.0-5000-gd2bdee8a6#n33
> which looks like what Debian packages as "libacl1" and is used by Debian's
> libisofs package.
> 
> So consider to add for libisofs
>       ("acl" ,acl)
> 
> ----------------------------------------------------------------------------
> 
> GNU xorriso versus libisoburn's xorriso:
> 
> The only known application of libisofs' ACL capabilities is xorriso. It can
> record ACLs as part of backups and restore them back to disk. Operating
> systems are supposed to ignore the ACL info when mounting and reading
> libisofs made filesystems.
> 
> Guix currently packages GNU xorriso, which brings own source copies of
> libburn, libisofs, libisoburn, and libjte.
> 
> When libburn and libisofs are established as Guix packages and the decision
> is made that Debian's Jigdo ISO download mechanism is not desired, one should
> consider to package libisoburn and to install its dynamically linked xorriso
> binary.
> 
> The source code and functionality of both xorrisos is the same, except that
> Guix offers no libjte for Debian's Jigdo format. Both are maintained by me.
> libisoburn is GPLv2+, but by using libreadline it will become GPLv3+.
> GNU xorriso is always GPLv3+.
> 
> Reason for the existence of GNU xorriso is mainly that it can be compiled
> and installed by a normal user without interfering with system-wide installed
> libburn and libisofs. This provides freedom from distro decisions and delays.
> 
> Guix's xorriso package has at
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/cdrom.scm?id=v0.13.0-2323-g35131babc#n148
> >     (inputs
> >      `(("acl" ,acl)
> >        ("readline" ,readline)
> >        ("bzip2" ,bzip2)
> >        ("zlib" ,zlib)
> >        ("libcdio" ,libcdio)))
> 
> The use of "bzip2" seems wrong. libjte optionally uses libbz2 which i don't
> find in Guix. "bzip2" does not promise the library but rather the standalone
> binary.
> 
> The use of "libcdio" would have the disadvantage described above. But
> it seems that it is not enabled at configure time of GNU xorriso.
> So one should remove it from the xorriso input list, too. 
> 
> ------------------------------------------------------------------------
> 
> Whew. I did not plan to write such a long mail.
> 
> 
> Have a nice day :)
> 
> Thomas
> 
> 

-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys
  WWW: https://n0.is

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]