From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eK3V2-0008Ex-S1 for guix-patches@gnu.org; Wed, 29 Nov 2017 09:38:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eK3Uw-00084q-OR for guix-patches@gnu.org; Wed, 29 Nov 2017 09:38:08 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:55369) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eK3Uw-00084P-JH for guix-patches@gnu.org; Wed, 29 Nov 2017 09:38:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eK3Uw-000885-9n for guix-patches@gnu.org; Wed, 29 Nov 2017 09:38:02 -0500 Subject: [bug#28398] Xfburn Resent-Message-ID: Date: Wed, 29 Nov 2017 14:37:23 +0000 From: ng0 Message-ID: <20171129143723.idqsaeq3i6ab24xt@abyayala> References: <20171129091421.hjqr7prtxlwiuzi5@abyayala> <2046678405415120597@scdbackup.webframe.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dcbmvu2mjlk6icve" Content-Disposition: inline In-Reply-To: <2046678405415120597@scdbackup.webframe.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Thomas Schmitt Cc: 28398@debbugs.gnu.org --dcbmvu2mjlk6icve Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, >=20 > ng0 wrote: > > I've applied your suggestions > > and the ones Christopher had a while back in this new version > > of the patches. >=20 > The inappropriate word "mastering" is still in one of the two description > texts in the libburn patch >=20 > > + (synopsis "Library for reading and writing optical discs") > > + (description > > + "Libburn is a library for reading, mastering and writing optical = discs. >=20 >=20 > (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/c= ontrol?r1=3D428&r2=3D430 > ) >=20 > ------------------------------------------------------------------------ >=20 > With Xfburn, consider to mention BD (Blu-ray) media additionally to CD and > DVD media.=20 >=20 > > + (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.") >=20 > 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. >=20 > ------------------------------------------------------------------------ >=20 > Did we already talk about these lines in the libburn patch ? >=20 > > + `(#:configure-flags (list "--enable-libcdio"))) > > + (inputs > > + `(("libcdio" ,libcdio))) >=20 > If they shall by default let libburn use the SCSI transport mechanism of > libcdio, then better don't do this. >=20 > 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 transp= ort > on operating systems which libburn cannot handle by its own system adapte= rs. > libburn has SCSI-capable adapters for Linux The Kernel, FreeBSD, Solaris, > NetBSD, OpenBSD. >=20 > 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. >=20 > The shortcommings of libcdio towards libburn's sg-linux.c adapter are mai= nly > with receiving SCSI error conditions (aka Sense Data) from the drive and > forwarding them to libburn. >=20 > So my advise is not to configure libburn with --enable-libcdio and not to > declare libcdio a dependency of libburn. >=20 > ------------------------------------------------------------------------ >=20 > I also looked at the libisofs related patch: >=20 > > + (inputs > > + `(("zlib" ,zlib))) >=20 > If ./configure sees libacl and libattr on GNU/Linux, then libisofs will l= ink > to it and enable recording of ACL and extended file attributes. >=20 > Looking for "acl" in Guix, i found > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/acl.scm?id= =3Dv0.13.0-5000-gd2bdee8a6#n33 > which looks like what Debian packages as "libacl1" and is used by Debian's > libisofs package. >=20 > So consider to add for libisofs > ("acl" ,acl) >=20 > -------------------------------------------------------------------------= --- >=20 > GNU xorriso versus libisoburn's xorriso: >=20 > The only known application of libisofs' ACL capabilities is xorriso. It c= an > 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. >=20 > Guix currently packages GNU xorriso, which brings own source copies of > libburn, libisofs, libisoburn, and libjte. >=20 > When libburn and libisofs are established as Guix packages and the decisi= on > is made that Debian's Jigdo ISO download mechanism is not desired, one sh= ould > consider to package libisoburn and to install its dynamically linked xorr= iso > binary. >=20 > The source code and functionality of both xorrisos is the same, except th= at > Guix offers no libjte for Debian's Jigdo format. Both are maintained by m= e. > libisoburn is GPLv2+, but by using libreadline it will become GPLv3+. > GNU xorriso is always GPLv3+. >=20 > 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 insta= lled > libburn and libisofs. This provides freedom from distro decisions and del= ays. >=20 > Guix's xorriso package has at > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/cdrom.scm?= id=3Dv0.13.0-2323-g35131babc#n148 > > (inputs > > `(("acl" ,acl) > > ("readline" ,readline) > > ("bzip2" ,bzip2) > > ("zlib" ,zlib) > > ("libcdio" ,libcdio))) >=20 > 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 standal= one > binary. >=20 > 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.=20 >=20 > ------------------------------------------------------------------------ >=20 > Whew. I did not plan to write such a long mail. >=20 >=20 > Have a nice day :) >=20 > Thomas >=20 >=20 --=20 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is --dcbmvu2mjlk6icve Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEqIyK3RKYKNfqwC5S4i+bv+40hYgFAloexiMACgkQ4i+bv+40 hYhDAQ/7Bb5cVwIPLPBIV60hP+CuN/5iOu4WQ0NtN7gFTm3/P0j04CNq+xrSl/MV 1MKIof7/+gmYexY62WfQQRFKj5PXq5gFvjCL6JBp8+SHKGSdlaaVaLl/xnFTGN7v q/WE89fpqwLCD+7/2F1cdkcKPzxtEkPY9o9qvOWd5xcf9RnJZUpPRawOkSnPtgNv +I1RgtRp/8FQFvhmx628Z6jPRSR+x1GNkgng8cJsk5ZDQNL7LotuSbJiNABSuSIg xJr1RGKpysxgUYCaiTGY+p+kWC8RCyb9i7DemIGyhl0q3p6RPkmPqhIk9CUUR43c WLjk3IfVL2G1Rfg0K1HqS+H75viWamkEJKqZgoJaAv86T1JbN6LuJvaQqqkpdHfs 41o0hEh2ru2U6VaYD107ztX1I3cmQWLHrFn0U+hWnZ5x1hwXAJbzJ1zNWqn/o+rI NkR6bzKm4dVpVZ4y1GZhAn+9+DW0VW6cKGtbVLX9sy6vtmcJuaghbOvNasEZkPRL T1IiQyOaXjSiQHpKQwl1GCXAEcBN2San+AU95PL78MsarpE9qfguNLz0pLQKeyhG Rnk8aZ9kqzzm8h07ePPi8ywggTcCIA8/RXNRJWz4fVgOIZ6HC3YcUVHJO8z+6mzO /k1LmD6CilVlZsv2Qhdwr3XiaIeZfqhpw3aaZC0blOY1cIK70fY= =8FId -----END PGP SIGNATURE----- --dcbmvu2mjlk6icve--