diff --git a/.dvd+rw-tools.metadata b/.dvd+rw-tools.metadata new file mode 100644 index 0000000..bdee673 --- /dev/null +++ b/.dvd+rw-tools.metadata @@ -0,0 +1 @@ +6400e013934ff589b4b224eced03fd9f42ed719b SOURCES/dvd+rw-tools-7.1.tar.gz diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..b7bba60 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +SOURCES/dvd+rw-tools-7.1.tar.gz diff --git a/SOURCES/dvd+rw-tools-7.0-dvddl.patch b/SOURCES/dvd+rw-tools-7.0-dvddl.patch new file mode 100644 index 0000000..c1c6fb3 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0-dvddl.patch @@ -0,0 +1,13 @@ +--- ./growisofs_mmc.cpp.joe 2006-04-27 20:45:00.788446635 +0200 ++++ ./growisofs_mmc.cpp 2006-04-27 20:46:01.666824300 +0200 +@@ -1412,9 +1412,7 @@ + blocks += 15, blocks &= ~15; + + if (blocks <= split) +- fprintf (stderr,":-( more than 50%% of space will be *wasted*!\n" +- " use single layer media for this recording\n"), +- exit (FATAL_START(EMEDIUMTYPE)); ++ fprintf (stderr,":-? more than 50%% of space will be *wasted*!\n"); + + blocks /= 16; + blocks += 1; diff --git a/SOURCES/dvd+rw-tools-7.0-glibc2.6.90.patch b/SOURCES/dvd+rw-tools-7.0-glibc2.6.90.patch new file mode 100644 index 0000000..49742d3 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0-glibc2.6.90.patch @@ -0,0 +1,11 @@ +diff -up dvd+rw-tools-7.0/transport.hxx.glibc2.6.90 dvd+rw-tools-7.0/transport.hxx +--- dvd+rw-tools-7.0/transport.hxx.glibc2.6.90 2007-08-15 12:56:17.000000000 +0200 ++++ dvd+rw-tools-7.0/transport.hxx 2007-08-15 12:56:42.000000000 +0200 +@@ -11,6 +11,7 @@ + #include + #include + #include ++#include + #include + #include + #include diff --git a/SOURCES/dvd+rw-tools-7.0-reload.patch b/SOURCES/dvd+rw-tools-7.0-reload.patch new file mode 100644 index 0000000..49352e5 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0-reload.patch @@ -0,0 +1,12 @@ +diff -Nrup dvd+rw-tools-7.0/growisofs_mmc.cpp dvd+rw-tools-7.0_mod/growisofs_mmc.cpp +--- dvd+rw-tools-7.0/growisofs_mmc.cpp 2006-09-23 20:45:49.000000000 +0800 ++++ dvd+rw-tools-7.0_mod/growisofs_mmc.cpp 2007-11-19 18:20:46.000000000 +0800 +@@ -138,7 +138,7 @@ int media_reload (char *name=NULL,struct + cmd[0] = 0x1B; // START/STOP UNIT + cmd[4] = 0x2; // "Eject" + cmd[5] = 0; +- if (cmd.transport()) return 1; ++ cmd.transport(); + } + #if defined(__sun) || defined(sun) + else if (volmgt_running()) diff --git a/SOURCES/dvd+rw-tools-7.0-wctomb.patch b/SOURCES/dvd+rw-tools-7.0-wctomb.patch new file mode 100644 index 0000000..56bd725 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0-wctomb.patch @@ -0,0 +1,11 @@ +--- transport.hxx~ 2008-03-25 21:24:47.000000000 -0400 ++++ transport.hxx 2008-03-25 21:25:36.000000000 -0400 +@@ -116,7 +116,7 @@ + extern "C" char *plusminus_locale() + { static class __plusminus { + private: +- char str[4]; ++ char str[MB_LEN_MAX]; + public: + __plusminus() { setlocale(LC_CTYPE,ENV_LOCALE); + int l = wctomb(str,(wchar_t)(unsigned char)'�'); diff --git a/SOURCES/dvd+rw-tools-7.0-wexit.patch b/SOURCES/dvd+rw-tools-7.0-wexit.patch new file mode 100644 index 0000000..e7910cb --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0-wexit.patch @@ -0,0 +1,11 @@ +--- dvd+rw-tools-7.0/dvd+rw-format.cpp.wexit 2007-06-21 12:42:30.000000000 +0200 ++++ dvd+rw-tools-7.0/dvd+rw-format.cpp 2007-06-21 12:44:13.000000000 +0200 +@@ -245,7 +245,7 @@ int main (int argc, char *argv[]) + alarm(1); + while ((waitpid(pid,&i,0) != pid) && !WIFEXITED(i)) ; + if (WEXITSTATUS(i) == 0) fprintf (stderr,"\n"); +- exit (0); ++ exit (WEXITSTATUS(i)); + } + #endif + diff --git a/SOURCES/dvd+rw-tools-7.0.manpatch b/SOURCES/dvd+rw-tools-7.0.manpatch new file mode 100644 index 0000000..cbbade4 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.0.manpatch @@ -0,0 +1,27 @@ +diff -ur dvd+rw-tools-7.0/Makefile.m4 dvd+rw-tools-7.0-manpatch/Makefile.m4 +--- dvd+rw-tools-7.0/Makefile.m4 2006-09-24 19:55:19.000000000 +0200 ++++ dvd+rw-tools-7.0-manpatch/Makefile.m4 2006-10-09 10:44:31.000000000 +0200 +@@ -191,7 +191,7 @@ + LINK.o =$(LINK.cc) + + prefix?=/usr/local +-manprefix?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac) ++mandir?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac) + + bin_mode?=0755 # yes, default is *no* set-uid + minus_o:=$(shell [[ `id -u` == 0 ]] && echo "-o root") +@@ -199,10 +199,10 @@ + install: dvd+rw-tools + [[ -d $(prefix)/bin ]] || mkdir -p $(prefix)/bin + install $(minus_o) -m $(bin_mode) $(CHAIN) $(prefix)/bin +- [[ -d $(manprefix)/man1 ]] || mkdir -p $(manprefix)/man1 +- install $(minus_o) -m 0644 growisofs.1 $(manprefix)/man1 +- -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin; : +- -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin; : ++ [[ -d $(mandir)/man1 ]] || mkdir -p $(mandir)/man1 ++ install $(minus_o) -m 0644 growisofs.1 $(mandir)/man1 ++ -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin || : ++ -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin || : + ]) + + # common section diff --git a/SOURCES/dvd+rw-tools-7.1-bluray_pow_freespace.patch b/SOURCES/dvd+rw-tools-7.1-bluray_pow_freespace.patch new file mode 100644 index 0000000..3b56282 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-bluray_pow_freespace.patch @@ -0,0 +1,14 @@ +diff -up wrk/growisofs_mmc.cpp.wrk wrk/growisofs_mmc.cpp +--- wrk/growisofs_mmc.cpp.wrk 2014-11-14 13:22:49.579552118 +0100 ++++ wrk/growisofs_mmc.cpp 2014-11-14 13:35:36.779730963 +0100 +@@ -410,7 +410,9 @@ static unsigned int get_2k_capacity (Scs + } + + nwa = 0; +- if (buf[7]&1 && !bdr_plus_pow) // NWA_V ++ //if (buf[7]&1 && !bdr_plus_pow) // NWA_V ++ //!bdr_plus_pow patched out for Fedora ++ if (buf[7]&1) // NWA_V + { nwa = buf[12]<<24; + nwa |= buf[13]<<16; + nwa |= buf[14]<<8; diff --git a/SOURCES/dvd+rw-tools-7.1-bluray_srm+pow.patch b/SOURCES/dvd+rw-tools-7.1-bluray_srm+pow.patch new file mode 100644 index 0000000..8fc1a6d --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-bluray_srm+pow.patch @@ -0,0 +1,12 @@ +diff -up dvd+rw-tools-7.1/growisofs_mmc.cpp.wrk dvd+rw-tools-7.1/growisofs_mmc.cpp +--- dvd+rw-tools-7.1/growisofs_mmc.cpp.wrk 2013-06-24 14:18:38.898344970 +0200 ++++ dvd+rw-tools-7.1/growisofs_mmc.cpp 2013-06-24 14:20:00.428025541 +0200 +@@ -756,6 +756,8 @@ static void bd_r_format (Scsi_Command &c + + wait_for_unit (cmd); + ++ bdr_plus_pow = 1; ++ + cmd[0] = 0x35; // FLUSH CACHE + cmd[9] = 0; + cmd.transport(); diff --git a/SOURCES/dvd+rw-tools-7.1-format.patch b/SOURCES/dvd+rw-tools-7.1-format.patch new file mode 100644 index 0000000..c8a7d11 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-format.patch @@ -0,0 +1,251 @@ +diff -up dvd+rw-tools-7.1/dvd+rw-format.1.format dvd+rw-tools-7.1/dvd+rw-format.1 +--- dvd+rw-tools-7.1/dvd+rw-format.1.format 2012-08-23 17:30:20.001822268 +0200 ++++ dvd+rw-tools-7.1/dvd+rw-format.1 2012-08-24 09:37:14.549094680 +0200 +@@ -0,0 +1,132 @@ ++.TH DVD+RW\-FORMAT 1 "24 Aug 2012" "dvd+rw\-tools 7.1" ++.SH NAME ++dvd+rw\-format \- formatting and blanking DVD and BD media program. ++.SH SYNOPSIS ++.B dvd+rw\-format ++[\fB\-force\fP[\fB\=full\fP]] ++[\fB\-lead\-out|\-blank\fP[\fB\=full\fP]] ++[\fB\-ssa\fP[\fB\=none|default|max|XXXm\fP]] ++.I /dev/dvd ++ ++.SH DESCRIPTION ++\fBdvd+rw\-format\fP is a part of \fBdvd+rw\-tools\fP suite and allows to ++format virgin DVD+RW or BD\-RE media for the first use or blank already ++written DVD\-RW. ++Typical use cases of using \fBdvd+rw\-format\fP is formatting DVD\-RW to ++make them over\-writable, blanking used DVD\-RW to make them sequentially ++writable from scratch, formatting BD\-RE and DVD\-RAM with custom ++spare area sizes or re\-formatting BD\-RE and DVD\-RAM to change their spare ++size. ++It is not possible to format CD\-RW by \fBdvd+rw\-format\fP, ++you can use \fBcdrskin\fP, \fBxorriso\fP or \fBwodim\fP utilities to blank ++them or cdrwtool to format them instead, see section \fBEXAMPLES\fP. ++ ++A DVD\-RW accepts two disc modes: the \fISequential Recording\fP ++and the \fIRestricted Overwrite\fP. If a DVD\-RW medium is in the latter one, ++it will behave much like DVD+RW. ++By default DVD\-RW discs are in Sequential Recording mode, but ++can be put into Restricted Overwrite mode using \fBdvd+rw\-format\fP ++when no options given. ++Be aware, that only \-blank=full, which lasts as long as full writing, ++makes a used sequential DVD\-RW capable of performing multi\-session, ++while fast blanked DVD\-RW can only do Disk\-At\-Once. ++ ++Virgin DVD\-RW can be directly written without ++the need of a formatting operation, however a non\-virgin DVD\-RW in ++Sequential Recording mode needs to be blanked before writing a new ++initial session. Since a DVD\-RW medium in the Restricted Overwrite ++mode behaves much like DVD+RW, it can be written again without prior ++formatting the media. ++ ++Virgin BD\-RE and DVD+RW media may be initially formatted prior ++usage. Any\-time later, \fBgrowisofs\fP program will take care of formatting ++it automatically whenever appropriate, while further formatting is not ++recommended, however it is possible. ++ ++.SH OPTIONS ++.TP ++.BI \-force[\=full] ++Perform formatting even if the medium is formatted already. This is not ++recommended for BD\-RE and DVD+RW media, since they need to be ++formatted only once. Use \fB\-format=full\fP to perform full (lengthy) ++reformat in case of DVD\-RAM or (lengthy) Full Certification in case of ++BD\-RE. ++.TP ++.BI \-lead\-out ++Relocates the lead\-out next to outermost written sector as well as makes ++sure there is no virgin surface before it. This can make the medium more ++compatible with some DVD players. Previously written data is not ++affected by this operation. ++.TP ++.BI \-blank[\=full] ++Wipe data from DVD\-RW media. Data on BD\-RE and DVD+RW will we overwritten ++automatically, so there is no need to blank them explicitly. ++Use \fB\-blank\=full\fP to change DVD\-RW back to Sequential Recording mode. ++.TP ++.BI \-ssa[\=none|default|max|XXXm] ++Grow, eliminate, reset to default or maximize \fISupplementary Spare Area\fP. ++ ++.SH EXAMPLES ++Actual device names vary from one operating system to another. We use ++\fI/dev/dvd\fP as a collective name or as symbolic link to the actual ++device if you wish. Under Linux it will most likely be a ++device such as "/dev/sr0" or "/dev/hda" for older Linux 2.6. ++ ++To blank a CD\-RW, you have to use another utility, e.g. wodim: ++ ++ \fBwodim\fP \fBblank=fast\fP \-immed dev=\fI/dev/cdrom\fP ++ \fBcdrskin\fP \fBblank=all|fast|as_needed\fP \-immed dev=\fI/dev/cdrom\fP ++ \fBxorriso\fP \fB\-outdev\fP \fI/dev/cdrom\fP \fB\-blank all|fast|as_needed\fP ++ ++To format CD\-RW, you can use cdrwtool: ++ ++ \fBcdrwtool\fP \fB\-d\fP \fI/dev/cdrom\fP \fB\-q\fP ++ ++To blank a DVD\-RW and put in the incremental sequential mode, run: ++ ++ \fBdvd+rw\-format\fP \fB\-blank=full\fP \fI/dev/dvd\fP ++ ++To blank a DVD\-RW and put in the Restricted Overwrite mode, run: ++ ++ \fBdvd+rw\-format\fP \fB\-force\fP \fI/dev/dvd\fP ++ ++To overwrite data of BD\-RE, DVD+RW, DVD\-RW or DVD\-RAM run: ++ ++ \fBgrowisofs\fP \fB\-Z\fP \fI/dev/dvd\fP\=\fI/dev/zero\fP ++ ++To blank a DVD\-RAM, you can use: ++ ++ \fBdd\fP if\=\fI/dev/zero\fP of\=\fI/dev/dvd\fP ++ ++To relocate lead\-out sector, run: ++ ++ \fBdvd+rw\-format\fP \fB\-lead\-out\fP \fI/dev/dvd\fP ++ ++.SH NOTES ++Note that DVD+RW re\-formatting procedure does not substitute for ++blanking. If you want to nullify the media, e.g. for privacy reasons, ++do it explicitly with 'growisofs \-Z \fI/dev/dvd\fP\=\fB/dev/zero\fP'. ++ ++When growisofs "runs into" blank Blu\-ray Disc media or BD\-RE, ++it gets pre\-formatted with minimal spare area size of 256MB. ++ ++.SH SEE ALSO ++Most up\-to\-date information on dvd+rw\-tools is available at ++http://fy.chalmers.se/~appro/linux/DVD+RW/. ++.PP ++.BR growisofs (1), ++.BR cdrskin (1), ++.BR xorriso (1), ++.BR wodim (1), ++.BR cdrwtool (1) ++ ++.SH AUTHORS ++Andy Polyakov stands for programming and on\-line ++information. ++ ++This manpage was created by Honza Horak and consulted by ++Thomas Schmitt . ++ ++.SH LICENSE ++\fBdvd+rw\-format\fP is distributed under GNU GPL. ++ +diff -up dvd+rw-tools-7.1/growisofs.1.format dvd+rw-tools-7.1/growisofs.1 +--- dvd+rw-tools-7.1/growisofs.1.format 2008-03-01 11:40:06.000000000 +0100 ++++ dvd+rw-tools-7.1/growisofs.1 2012-08-24 09:35:55.550780073 +0200 +@@ -113,7 +113,7 @@ recordings. + Actual device names vary from one operating system to another. We use + \fI/dev/dvd\fP as a collective name or as symbolic link to the actual + device if you wish. Under Linux it will most likely be an ide\-scsi +-device such as "/dev/scd0." Under NetBSD/OpenBSD it has to be a ++device such as "/dev/sr0." Under NetBSD/OpenBSD it has to be a + \fIcharacter\fP SCSI CD\-ROM device such as "/dev/rcd0c." Under Solaris + it also has to be a \fIcharacter\fP SCSI/ATAPI CD\-ROM device, e.g. + "/dev/rdsk/c0t1d0s2" or "/vol/dev/aliases/cdrom0." And likewise in +@@ -210,11 +210,19 @@ DVD\-RAM or Blu\-ray Disc, as volumes ar + When growisofs "runs into" blank Blu\-ray Disc media, BD\-RE or BD\-R, + it gets pre-formatted with minimal spare area size of 256MB. + ++A DVD\-RW accepts two disc modes: the \fISequential Recording\fP ++and the \fIRestricted Overwrite\fP. If a DVD\-RW medium is in the later one, ++it will behave much like DVD+RW. ++By default DVD\-RW discs are in Sequential Recording mode, but ++can be put into Restricted Overwrite mode using \fBdvd+rw\-format\fP. ++See \fBdvd+rw\-format (1)\fP for more info. ++ + .SH SEE ALSO + Most up-to-date information on dvd+rw\-tools is available at + http://fy.chalmers.se/~appro/linux/DVD+RW/. + .PP +-The manpage for \fBmkisofs\fP. ++.BR mkisofs (1), ++.BR dvd+rw\-format (1) + + .SH AUTHORS + Andy Polyakov stands for programming and on-line +diff -up dvd+rw-tools-7.1/growisofs.c.format dvd+rw-tools-7.1/growisofs.c +--- dvd+rw-tools-7.1/growisofs.c.format 2008-03-04 10:15:03.000000000 +0100 ++++ dvd+rw-tools-7.1/growisofs.c 2012-08-23 17:30:20.028822506 +0200 +@@ -3433,8 +3433,15 @@ int main (int argc, char *argv[]) + else if (isatty (0)) warn_for_isofs |= 2; + + if (no_tty_check || (warn_for_isofs&2)) +- fprintf (stderr,"WARNING: %s already carries isofs!\n",in_device), ++ { ++ fprintf (stderr,"WARNING: %s already carries isofs!\n",in_device); ++ /* we cannot re-write a DVD-RW media in Sequential mode */ ++ if ((int)(mmc_profile&0xFFFF) == 0x14) ++ fprintf (stderr,"FATAL: DVD-RW medium is in Sequential mode, you " ++ "need to blank it before writing again.\n"), ++ exit(FATAL_START(EBUSY)); + printf ("About to execute '"); ++ } + else + fprintf (stderr,"FATAL: %s already carries isofs!\n",in_device), + exit(FATAL_START(EBUSY)); +diff -up dvd+rw-tools-7.1/Makefile.format dvd+rw-tools-7.1/Makefile +--- dvd+rw-tools-7.1/Makefile.format 2008-02-27 14:11:27.000000000 +0100 ++++ dvd+rw-tools-7.1/Makefile 2012-08-23 17:30:20.037822589 +0200 +@@ -22,6 +22,7 @@ pkg: + $(DIST)/Makefile.m4 \ + $(DIST)/dvd+rw-tools.spec \ + $(DIST)/growisofs.1 \ ++ $(DIST)/dvd+rw-format.1 \ + $(DIST)/transport.hxx \ + $(DIST)/mp.h \ + $(DIST)/win32err.h \ +diff -up dvd+rw-tools-7.1/Makefile.m4.format dvd+rw-tools-7.1/Makefile.m4 +--- dvd+rw-tools-7.1/Makefile.m4.format 2012-08-23 17:30:19.971822000 +0200 ++++ dvd+rw-tools-7.1/Makefile.m4 2012-08-23 17:30:20.038822597 +0200 +@@ -32,6 +32,7 @@ BIN_MODE?=0755 + install: dvd+rw-tools + install -o root -m $(BIN_MODE) $(CHAIN) /usr/bin + install -o root -m 0644 growisofs.1 /usr/share/man/man1 ++ install -o root -m 0644 dvd+rw-format.1 /usr/share/man/man1 + ]) + + ifelse(OS,MINGW32,[ +@@ -68,6 +69,7 @@ BIN_MODE?=04755 + install: dvd+rw-tools + install -o root -m $(BIN_MODE) $(CHAIN) /usr/local/bin + install -o root -m 0644 growisofs.1 /usr/local/man/man1 ++ install -o root -m 0644 dvd+rw-format.1 /usr/local/man/man1 + ]) + + ifelse(OS,SunOS,[ +@@ -103,6 +105,7 @@ LDLIBS=-lvolmgt -lrt -lpthread -ldl + install: dvd+rw-tools + /usr/ucb/install -o root -m 04755 $(CHAIN) /usr/local/bin + /usr/ucb/install -o root -m 0644 growisofs.1 /usr/local/man/man1 ++ /usr/ucb/install -o root -m 0644 dvd+rw-format.1 /usr/local/man/man1 + ]) + + ifelse(OS,HP-UX,[ +@@ -141,6 +144,7 @@ LDLIBS=-lrt -lpthread + install: dvd+rw-tools + /usr/sbin/install -o -f /usr/local/bin $(CHAIN) + /usr/sbin/install -o -f /usr/local/man/man1 growisofs.1 ++ /usr/sbin/install -o -f /usr/local/man/man1 dvd+rw-format.1 + ]) + + ifelse(OS,IRIX,[ +@@ -178,6 +182,7 @@ BIN_MODE=04755 # set-root-uid + install: dvd+rw-tools + /sbin/install -u root -m $(BIN_MODE) $(CHAIN) /usr/local/bin + /sbin/install -u root -m 0644 growisofs.1 /usr/local/man/man1 ++ /sbin/install -u root -m 0644 dvd+rw-format.1 /usr/local/man/man1 + ]) + + ifelse(OS,Linux,[ +@@ -202,6 +207,7 @@ install: dvd+rw-tools + install $(minus_o) -m $(bin_mode) $(CHAIN) $(prefix)/bin + [[ -d $(mandir)/man1 ]] || mkdir -p $(mandir)/man1 + install $(minus_o) -m 0644 growisofs.1 $(mandir)/man1 ++ install $(minus_o) -m 0644 dvd+rw-format.1 $(mandir)/man1 + -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin || : + -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin || : + ]) diff --git a/SOURCES/dvd+rw-tools-7.1-lastshort.patch b/SOURCES/dvd+rw-tools-7.1-lastshort.patch new file mode 100644 index 0000000..da225d4 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-lastshort.patch @@ -0,0 +1,12 @@ +diff -up dvd+rw-tools-7.1/growisofs_mmc.cpp.lastshort dvd+rw-tools-7.1/growisofs_mmc.cpp +--- dvd+rw-tools-7.1/growisofs_mmc.cpp.lastshort 2012-04-13 18:09:31.047641524 +0200 ++++ dvd+rw-tools-7.1/growisofs_mmc.cpp 2012-04-13 18:09:34.451763587 +0200 +@@ -540,7 +540,7 @@ ssize_t poor_mans_pwrite64 (int fd,const + // own higher HZ value and disrespects the user-land one. + // Sending them down as milliseconds is just safer... + // +- if (!(errcode=cmd.transport (WRITE,(void *)buff,size))) ++ if (!(errcode=cmd.transport (WRITE,(void *)buff,nbl*2048))) + break; + + //--- WRITE failed ---// diff --git a/SOURCES/dvd+rw-tools-7.1-noevent.patch b/SOURCES/dvd+rw-tools-7.1-noevent.patch new file mode 100644 index 0000000..19c8c66 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-noevent.patch @@ -0,0 +1,19 @@ +diff -up dvd+rw-tools-7.1/transport.hxx.debug dvd+rw-tools-7.1/transport.hxx +--- dvd+rw-tools-7.1/transport.hxx.debug 2012-03-07 10:55:07.167322839 +0100 ++++ dvd+rw-tools-7.1/transport.hxx 2012-03-07 15:44:34.384202747 +0100 +@@ -1795,9 +1795,12 @@ static int handle_events (Scsi_Command & + break; + case 5: ret |= 1<<5; break; // Multiple Initiators + case 6: // Device Busy +- if ((event[4]&0xF)==1 && // Timeout occured +- (event[5]&0x3)!=0) +- { poll(NULL,0,(descr&0xFFFF)*100+100); ++ if ((event[4]&0xF)==1) // Timeout occured ++ { ++ if ((event[5]&0x3)==0) // No Event ++ return 0; // Ready to accept any command ++ ++ poll(NULL,0,(descr&0xFFFF)*100+100); + cmd[0] = 0; // TEST UNIT READY + cmd[5] = 0; + if ((err=cmd.transport())) diff --git a/SOURCES/dvd+rw-tools-7.1-sysmacros.patch b/SOURCES/dvd+rw-tools-7.1-sysmacros.patch new file mode 100644 index 0000000..409d0a2 --- /dev/null +++ b/SOURCES/dvd+rw-tools-7.1-sysmacros.patch @@ -0,0 +1,24 @@ +From 02d3c9a60421741c0cdd2808d5fa18a1b53f32e1 Mon Sep 17 00:00:00 2001 +From: Jakub Martisko +Date: Mon, 6 Aug 2018 10:07:07 +0200 +Subject: [PATCH] include sysmacros header + +--- + growisofs.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/growisofs.c b/growisofs.c +index 8b71935..a5cde82 100644 +--- a/growisofs.c ++++ b/growisofs.c +@@ -440,6 +440,7 @@ + #include + #include + #include ++#include + #include + #include + #include "mp.h" +-- +2.14.4 + diff --git a/SOURCES/index.html b/SOURCES/index.html new file mode 100644 index 0000000..1e39c4e --- /dev/null +++ b/SOURCES/index.html @@ -0,0 +1,1295 @@ + + + + +Blu-ray Disc/DVD+RW/+R/-R[W] for Linux + + + + + + + + + +

+ +
+

Blu-ray Disc/DVD+RW/+R/-R[W] for Linux

+
by <appro@fy.chalmers.se>, +September 2006
+		Japanese +
+

+ +

+ + + + +
Q. What is this page (not) about?
A.  + Maybe to your disappointment it is not about + video(*). The scope of this page is primarily + computer storage applications of Blu-ray Disc and + DVD±RW/±R, things like backup, archiving, data + exchange... The downloadable files are an optional Linux 2.4 kernel DVD+RW patch and a + couple of user-land utilities dubbed as dvd+rw-tools. + +

+ + +
(*) + Though it doesn't mean that you can't burn + DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video + is "molded" in an ordinary data file system and + therefore no explicit support by the burning program is + actually required. In other words it is the DVD-Video + content preparation which is beyond the scope of this + page.
+

+ +

+ + + + +
Q. Kernel patch? This sounds too complicated + already! Can't I just use [vanilla] cdrecord? + +
A. It should be explicitly noted that the user-land + utilities, dvd+rw-tools, do suffice for BD/DVD recording + without explicit kernel support. So if they fulfill your requirements, then + patching the kernel is by all means optional. As + for [vanilla] cdrecord, non-CD recording strategies are + somewhat different, so it simply doesn't work (nor does + dvdrecord with media other than DVD-R[W], despite what RedHat + 7.3 Release Notes say). On additional note Linux kernel + version 2.6>=10 is equipped with packet + writing driver which supports even DVD rewritable media, + but I haven't tested it myself, so don't ask:-)
+ +

+ + + +
Q. What is the kernel patch good for then? +
A. DVD+RW (but not DVD+R nor any DVD-dash) is a true random + write access media and therefore is suitable for housing of an + arbitrary file system, e.g. udf, vfat, ext2, etc. This, + and this alone, qualifies DVD+RW support for kernel + implementation. However, I have to recommend to + deploy it with caution, see tutorial + for further details. Also note that not all OEMs seem to live + up to the promise of true random write access. As for the + moment of this writing apparenly only 2nd generation + Ricoh-based units (see dvdplusrw.org for + generation listings) equipped with later firmware can sustain + I/O fragmentation (see Technical Ramblings below for further + details) and perform reliably. +
+ +

+ + + + +
Q. What are the dvd+rw-tools for?
A. As implied/already mentioned - to master the Blu-ray Disc and DVD media, both +RW/+R and + -R[W]. I could simply refer to the + tutorial below, but figured that couple of words about the + [original] design ideas behind growisofs, the principal + burning utility, wouldn't harm. Even though a modified + kernel can let you put for example an ext2 file system on + DVD+RW, it's probably not very practical, because you most + likely want to access the data on an arbitrary computer. + Or in other words you most likely want ISO9660. The trouble is + that you might as well want to add data now and then. + And what options do you have in the lack of multiple sessions + (no, DVD+RW has no notion of multiple sessions)? Complete + re-mastering which takes more and more time as data set grows? + Well, yes, unless you employ growisofs! Growisofs + provides the way to both lay down and grow an ISO9660 + file system on (as well as to burn an arbitrary pre-mastered + image to) all supported optical media.
+ +

+ + + + +
Q. But if they support both + and - recording + strategies, why are they called dvd+rw-tools?
A. For historical/nostalgical reasons, as originally they did + support exclusively DVD+plus. On the other hand now, when the + vast majority of DVD burners that are being introduced to the + market today are DVD+capable, the name most likely refers to + your unit in either case. And you can always consider the plus + in the name as notion of a unique quality, such as + "seamless" multisessioning, not as reference to some + particular format:-)
+ +

+ + + + +
Q. Do I still need cdrtools? +
A. Yes. It should be explicitly noted that growisofs is a + front-end to mkisofs, i.e. invokes mkisofs to perform the + actual ISO9660 file system layout. Secondly, the DVD burners + available on the market can burn even CD-R[W] media and + cdrecord is the tool for this job [and this job only].
+ + + +

+ + + + +
Q. Does it work with my recorder unit? +
A. If your unit is MMC compliant, + then the answer is "most likely it + just does." Well, as the probability of your unit being + non-MMC compliant is virtually zero, the answer in practice is + unconditionally "most likely." + The [core] tools were reported to work with a wide range of + drives, including [but not limited to] HP + dvd[12345]x0i, Ricoh MP512x, Philips + DVDRW[248]xx, SONY DRU-[157]x0, NEC + ND-[1234]xx0, TDK indiDVD 4x0N, + Plextor PX-[57]xx, Benq DW[48]00A, + OptoRite DD0[24]0x, Lite-On + LDW-[4816]xxS, as well as nonplus + units such as Pioneer DVR-x0[45679], LG + GxA-40[248]x, Toshiba SD-R[56]112, + Panasonic UJ-811, LF-D[35]1x, and not + the least all-mighty + SW-5582...
+ +

+ + + + +
Q. Is there a GUI front-end available for + dvd+rw-tools? +
A. K3b, version 0.10 + and later, and nautilus-cd-burner, + version 0.5.1 and later, are both hiding growisofs behind their + pretty buttons and menus:-) Keep in mind that those are not + directly related to dvd+rw-tools development + effort and GUI users should turn elsewhere for end-user + support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for + GUI frontends...
+ +

+ + + + +
Q. I don't run Linux. What are my options? +
A. Version 5.4 adds support for OpenBSD/NetBSD. + Version 5.6 adds support for Solaris 2.x [commercial licensing + terms for distribution on Solaris are to be settled with Inserve Technology]. + Version 5.8 features FreeBSD + port contributed by Matthew Dillon, FreeBSD Development Team + alumnus. Hewlett-Packard Company has donated + HP-UX 11 support for + 5.14(*). IRIX 6.x support appears in + 5.19, Win32 one - in 6.0, + while Mac OS X - in 7.0... + +

+ + + + + + +
¡ + Common usage tip! Whenever + separately available [and unless stated otherwise], do use + character-type device entry with dvd+rw-tools, + e.g. OpenBSD/NetBSD users should stick to /dev/rcdXc.
(*) + As of 5.14 HP-UX support was classified as + "initial." Version 5.18 in turn is the one which has + undergone HP quality assurance testing + and is delivered on HP + software depot.
+

+ +

+ +

Foreword

+ +

As of May 2003 I've decided to advise users to +turn to <cdwrite@other.debian.org> +on support matters. It's an open list, meaning that you don't have +to be subscribed to post +a problem report. List archives can be found at both subscribe page and mail-archive.com. +When submitting report, provide versioning information, exact +command line, exact output generated by the program and +complement it with dvd+rw-mediainfo output for +resulting recording. Do check couple of last archived months, as the +issue might have been discussed recently. If you've chosen to +contact me personally and haven't heard back within a week or so, then +you most likely overlooked something on this page. Please read it more +attentively... + +

Special thanks for hardware donations [in +chronological order]:
+ +  + +  + +  + +comm*tech  + +

+ +

Tutorial

+ +

+ +
    + +

  • If your burner unit is managed by some +Linux(*) removable media +automounting/autoplaying facility, such as autofs, supermount, +subfs/submount, magicdev, autorun or similar, take it out of its +control! I can't help you with the latter, check your system +documentation (such as google perhaps:-) for specific instructions. +Failure to take your unit out of +Linux(*) automounting/autoplaying facility +control can result in busted recording, a coaster! At the +very least you have to make sure your unit is not automounted during +recordings. + + + + +
    (*) +dvd+rw-tools support Solaris volume manager and +IRIX mediad in more gracious manner and it's safe to leave recorder +under their control.
    + +

  • Remember to consult Hardware Compatibility Notes for possible +caveats or vendor-specific instructions for your unit. Well, such +reminder belongs at the end of tutorial, but I consider it important +enough to bring it up already here:-) + +

  • If you have an IDE unit and run 2.4.x +kernel, you most likely want to "route" it through ide-scsi +emulation layer by either: + +

      +
    • passing "hdX=ide-scsi" +argument to kernel; +
    • appending following lines to your /etc/modules.conf: +
      +
      options ide-cd ignore=hdX
+pre-install sg modprobe ide-scsi
+pre-install sr_mod modprobe ide-scsi
+pre-install ide-scsi modprobe ide-cd
+
      +
    + +

    Keep in mind that once hdX +is routed through ide-scsi, you can no longer refer to /dev/hdX(*), but to corresponding +/dev/scdN only. + +

    + + +
    (*) +well, except as in hdparm -d [0|1] /dev/hdX. As for DMA settings. Several users of +NEC[-based] units have reported that their systems crash during DVD +recording. The problem appears to be related to DMA settings, at least +switching it off reportedly helps. The problem appears to be specific to +some IDE chipsets... +
    + +

  • If you have an external unit, just get +it working as CD-ROM first. I myself have no personal experience +whatsoever with USB or IEEE1394/Firewire optical storage +devices and have to direct you elsewhere for specific instructions. I +however am confident that if you manage to get your drive working +reliably as CD-ROM and CD-R[W] +burner, then you won't have any troubles with dvd+rw-tools either. USB +connected drives were reported to be working fine since eternity. +Firewire connected drives in turn were reported to fail miserably under +2.4.18. The failure didn't seem to be DVD recording related as it +reportedly failed burning even CD-R media. Firewire support was +substantially revamped in 2.4.19, and dvd+rw-tools were reported to +work with this and later kernels. + +

  • If you're running 2.4.19 or .20, consider +applying this drivers/scsi/sg.c patch. +The bug is fixed in .21. I write "consider" and not +"do" for the following reasons: + +

      +
    • dvd+rw-tools are not affected by this bug (as they don't use SG_IO +interface), cdrecord [potentially] is; +
    • I however haven't actually experienced the problem with cdrecord +(maybe yet, kernel could have managed to keep buffers neatly aligned +while talking to cdrecord those times I tried), it was VMware that has +failed miserably on me; +
    + +

    As of version 5.6 dvd+rw-tools add support for SG_IO +pass-through or in other words support for Linux 2>=5[.43], +where "generic" SCSI interface can be bypassed by issuing +SG_IO ioctl directly against block device, such as /dev/hdX. I wish it worked without need for interim +patches #1 and #2, (the latter is relative to +2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in +"last +minute" prior first 2.6 cut. As for 2.6 in more general sense. +As you can imagine this new interface renders ide-scsi layer +superfluous and "the[ir] official plan™" is to scrap +it. I'm not really fond of the idea, but not for /dev/sg* account. I +mean I [personally] would prefer to keep ide-scsi and use SG_IO +pass-through with /dev/scdN, rather than with +/dev/hdX:-) + +

    If you have to make dvd+rw-tools work under Linux +kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and +manually reward the installed binaries with set-root-uid flag. But the +"supported" recommendation is to just stay away from this +particular kernel version. As for 2.6>8, dvd+rw-tools 5.21.x is +requirement. Oh! dvd+rw-booktype utility would require set-root-uid +privilege then. Given its semi-official status and the fact that this +utility works only with limited number of units, installation procedure +abstains from installing dvd+rw-booktype set-root-uid, leaving +this security sensitive choice to the end-user. + +

  • Download, unpack and compile the the tool-chain. To build the thing do pick the +.tar.gz archive, which contains Makefile as well as .spec file. You +will need both C and C++ compilers installed. Separate +source code files found in the download catalog +are provided mainly for on-line reference purposes (such as revision history:-). + +

    If your Linux kernel supports multiple ABIs (e.g. +Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as +Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you +compile for native 64-bit ABI (which can normally be done with +'make TARGET_ARCH=-m64'). The problem here is that 64-bit +kernel has to explicitly convert ioctl structures passed by 32-bit +applications and apparently it does really lousy job when it comes to +CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools. + +

  • As new media products and brands are being +introduced to the market all the time, it apparently pays off to +periodically check for firmware updates. For elder units +firmware update might even be an absolute requirement for using +new media. Special note for HP users. HP no longer posts firmware +updates on a web-page. Instead they let some Windows auto-update gizmo +to pick firmware updates among dvd[1-6]00*.exe +files in their FTP +directory, so that readers of this page tend to miss them... + +

  • Formatting the BD and DVD+RW media. +Virgin BD and DVD+RW media needs to be initally formatted prior usage. +Once again, only virgin BD and DVD+RW media needs to be +formatted. As of version 5.10 growisofs detects blanks and applies +initial formatting procedure automatically. Otherwise same effect can +be achieved by passing the device name, e.g. /dev/scd0, as an +argument to dvd+rw-format. Well, +in BD case it does offer more flexibility than +growisofs. To make formatting process reasonably fast, less than 1 +minute, the media gets formatted only partially, as you can notice by +observing progress indicator displayed by dvd+rw-format. The final +indicator value varies from firmware to firmware, values as low as 1.6% +were observed. But it does not mean that you can only write that +little. The unit keeps formatting transparently, as you add more +data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in +salesman's GB, i.e. 10003 and not 10243. And +so is one of BD. + +

    It was observed that excessive reformats can render +DVD+RW media unusable already after 10-20 reformats. It appears to be a +firmware deficiency, not some common media defect [at least it was +perfectly possible to salvage the media in a unit of different brand], +but I don't recommend [enforced] reformat in either case. + +

    Note that re-formatting procedure does not +substitute for blanking. If you want to nullify the media, e.g. for +privacy reasons, do it explicitly with 'growisofs -Z +/dev/scdN=/dev/zero'. Otherwise just +write over previous recording as it simply wasn't there, no +re-formatting is required. + + + +

  • Burning with growisofs. There is hardly a need for +manual for growisofs. In a nutshell growisofs just passes all command +line arguments to mkisofs and dumps its output directly onto the media. +The first part means that you basically can [well, should] +consult mkisofs manual page and +accompanying reference documentation (including multisession related +section[s]) and the second part means that you shouldn't expect an +ISO-image on the standard output (nor make sure you have enough free +temporary storage:-). Differences from mkisofs command line +are: + +

      +
    • you may not use -o option; +
    • you don't have to specify -C option, growisofs will construct one +for you; +
    • there is internal -Z option for initial session recording, this +substitutes for originally suggested 'mkisofs | dd of=/dev/scd0'; +
    + +

    Otherwise everything that applies to +[multisession] mastering with mkisofs applies to growisofs as well. For +example just like with mkisofs you should make a note on which options +you used to master the initial "session" with and stick to +them, e.g.: + +

    +growisofs -Z /dev/scd0 -R -J /some/files
+growisofs -M /dev/scd0 -R -J /more/files
+
    + +

    Oh! Do make sure you have at least mkisofs 1.14 on your $PATH (mkisofs 1.14 is part of cdrtools +1.10). If you consider passing /same/files as argument, or in +other words consider deploying growisofs for incremental +multisession backups, then you shall find this '-old-root' extension to +mkisofs 2.0-2.01 simply indispensable. +The idea and implementation by Patrick Ohly is to +"graft" recording sessions as separate directories. Each +backup increment/directory is ment to contain both updated files and +references to previously backed up ones, which facilitates +comparison between increments as well as fine-graded restore. + +

    Number of users asked about opposite to +multisessioning: multivolume support. Being essentially a recording +program growisofs does not support multiple volumes by itself. There're +couple of front-ends I can recommend that arrange for this: scdbackup and +shunt. But back to +growisofs... + +

    In addition to intuitive -Z interpretation, +growisofs [version 3.3 and later] recognizes special form of -Z command +line option which permits burning of arbitrary pre-mastered images. The +"magic" command is: + +

    +growisofs -Z /dev/scd0=image.iso
+
    + +

    where image.iso represents an arbitrary +object in the file system, such as file, named pipe or device +entry. No, nothing is "growing" here and command name is +counter-intuitive in this particular context. And here is even less +intuitive:-) If you wish to burn down output generated by an +arbitrary program, you can use: + +

    +dumpsomething | growisofs -Z /dev/scd0=/dev/fd/0
+
    + +

    Burning BD-R/DVD±R implies extra limitations: + +

      + +
    • Needless to say that you have only one shot with -Z +option:-) + + + +
    • Unlike DVD+RW, DVD±R media does have notion of multiple +sessions. However! Not all legacy units can "see" +beyond the first one. Few DVD-ROM units are capable of DVD-R +multiborder playback, even fewer support DVD+R multisessioning. In +other words your DVD burner might be the only unit in your vicinity +capable to access data added at different occasions. + +
    • Even if your DVD unit does "sense" multiple sessions, +Linux kernel [2.4] sometimes fails to pull that information from the +drive:-( Till the problem is looked into and resolved you can +work it around by reloading corresponding driver, most likely +'rmmod sr_mod'. + +
    • Linux kernel 2.6<10 +users might experience problems +mounting multisession media with last session starting beyond +2.2GB boundary. As fast-acting remedy I can suggest to route your unit +through ide-scsi, the way it was under 2.4. Even though it's declared +unsupported it actually still works in 2.6 (I for one still use it). + +
    • If you go for BD-R/DVD±R multisessioning, you have to use +mkisofs from cdrtools-2.0 +or later or apply this patch. + +
    • And when it comes to DVD+R Double Layer and DVD-R +Dual Layer recordings, growisofs applies yet another limitation, +purely artificial. Taking into consideration Double Layer media prices +growisofs is programmed to refuse to perform unappendable +recordings which are less than 1/2 of blank capacity and to advice +to use single layer media instead. + +
    • DVD-R Dual Layer multisessioning is not supported for a reason +discussed on the -RW companion page. Once +again, as of the moment of this writing DVD-R Dual Layer +recordings come out unappendable and can not be grown. +
    + + +

    And once again, do keep in mind that 4.7GB are +salesman's GB, i.e. 10003 and not 10243. If +translated to "real" GB, single layer +DVD±R[W] capacity is not larger than 4.4GiB, and BD +- not larger than 23.3GiB! It should also be noted that earlier +growisofs versions did not check if there is enough space on media to +accommodate the data set to be burned, meaning that it was your sole +responsibility to make sure "overburn" condition is not +raised. As of version 5.2 growisofs performs the necessary checks +for you and refuses to start recording if "overburn" +condition appears to be unavoidable. This behaviour can be overridden +with -overburn command-line option. + +

  • If you're satisfied with growisofs, then you +should just proceed to the next chapter +and abstain from applying the optional 2.4.x kernel patch. If +you haven't stopped reading beyond this line, download the patch, apply it, rebuild the +kernel or modules and re-install (kernel or cdrom.o and sr_mod.o +modules, whichever appropriate), but don't ask me how. As you could +have noticed, patch targets SCSI CD-ROM module. This means that you +have to "route" your IDE unit through ide-scsi to get this one +working. To see it in action, insert formatted DVD+RW media and try to +access it, 'dd if=/dev/scdN count=0' +would do. Then verify that kernel logs "srN: mmc-3 profile: 1Ah". You should now be +able to 'mkisofs -pad . | dd of=/dev/scdN +obs=32k' or even 'mke2fs -b 2048 /dev/scdN' and observe kernel logging "srN: dirty DVD+RW media." + + + +

    Linux 2.6 DVD+RW kernel support is planned in +line with DVD+MRW kernel support. This [unfortunately] means that +industry has to deliver a DVD+MRW capable unit first. Yes, the last +sentence means that despite all the promises, there are no such units +available on the market yet. As of the 1st of August 2003, Ricoh MP5240A, +Philips DVDRW416K or BenQ DW400A do not actually implement +Mt.Rainier/EasyWrite support. It remains to be seen if they will offer +it in form of firmware upgrade. In either case, the [original] project +goal is not only read-write support for DVD+[M]RW capable units +themselves, but even playback of DVD+MRW formatted media in legacy +DVD-ROM units (when defect list will be read and interpreted by OS +software in opposite to Mt.Rainier firmware). + +

  • Even though kernel now +permits to build and mount arbitrary file system, there is one thing you +must keep in mind before you just proceed, no matter how +tempting it might appear. + +

    As you might know DVD+RW media can sustain only +around 1000 overwrites. The thing about fully fledged file systems +is that every read [or tight bunch of 'em] is accompanied by +corresponding i-node update or in other words a write! Now, let's say +you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This +gives you a 100 days lifetime on your mountpoint and therefore media. +Not really much, huh? So do use noatime mount option with +DVD+RW media or have it mounted read-only most of the time. However! +Every read-write mount "costs" a super-block update. So that +if you remount the media say 3 times a day, it would last for about a +year [supermount +would exhaust the "budget" way sooner]... Defect management +[in firmware, a.k.a. Mt.Rainier, +or at file system level] would improve the situation, but ideally +file system driver should definitely refrain from modifying the +super-block [marking it dirty] if nothing was actually written since +last mount. Given the development status of Linux UDF the +chances for seeing the latter implemented [for UDF] are more than just +conceivable. The request is already filed and even possible solution is +being discussed. But why not give UDF a shot already then? By default +UDF write support is unfortunately disabled and you might have to +reconfigure the kernel and rebuild modules. Alternatively [my preferred +option actually] fetch the code at SourceForge and +build the module separately. Of course you will have to fetch and build +udftools as well. But once it's done just type: + +

    +mkudffs --spartable=2 --media-type=cdrw /dev/scdN
+mount -o rw,noatime /dev/scdN /mnt/cdrom
+
    + +

    mkudffs command line options were suggested +by UDF maintainer, Ben Fennema. + +

  • Performance optimization. This paragraph +applies only if you've patched the kernel. As some of you might +remember the original recommendation was "do use obs=32k +for optimal performance." Well, it was rather naive of me to say +so, as common block device layer completely reorganizes the +stream so that '>/dev/scd0' is as good as '|dd +of=/dev/scd0 obs=32k'. It should also be noted that dumping to +/dev/scd0 puts quite a pressure on VM subsystem, as the data passes +through block buffer cache. To minimize the pressure and improve +overall system performance bind the cdrom device to a raw device, e.g. +'raw /dev/raw/raw1 /dev/scd0', growisofs will locate and use +it automatically. obs=32k makes perfect sense with /dev/raw devices, +but dd (as well as most other programs, e.g. tar) won't work as +/dev/raw expects specifically aligned buffer... As temporary +workaround, just to get you going so that you can start figuring things +out, consider this +"hacklet"... + +

+ +

 + +

Compatibility: caveat lector

+ +

+ +

This paragraph discusses "DVD-ROM +compatibility," or playability of already recorded media in legacy +units. Blank media compatibility issues, or cases such as failure to +start or fulfill recording because of poor media support by burner +firmware, are beyond the current scope. Turn to your vendor for list of +supported media and/or to the public to share your +experience. + +

In order to optimize seek times DVD[-ROM] players +calibrate their mechanics every time the media is loaded by sliding +the optical head some place, picking up the signal and noting the +physical block address underneath the lens. In order for this procedure +to work with re-writable/recordable media, that particular spot has to +be written to [or de-iced in DVD+RW terms]. Some units slide the head to +30mm [radial] to calibrate, some to 35mm. In order to keep such players +"happy," make sure that at least 1GB is written [before you +attempt to mount it in DVD-ROM unit]. + +

Other units attempt to seek to lead-out [or vicinity +of it] for calibration purposes. Now the catch is that it's perfectly +possible to produce a DVD+RW disc without lead-out. Most notably media +initially formatted with dvd+rw-format [apparently] +doesn't have any lead-out, not to mention that practically whole +surface remains virgin. If you fail to mount/play DVD+RW media, attempt +to + +

dvd+rw-format -lead-out /dev/scdN
+ +

which relocates the lead-out next to outermost +written sector as well as makes sure there is no virgin surface before +it. Previously written data is not affected by this operation. + + +

Then non-finalized DVD+R and Sequential +DVD-R[W] discs don't have lead-out either(*). +If you fail to mount/play DVD+R media and wish to sacrifice the +remaining space for immediate compatibility, just fill the media +up(**). Alternatively if you master volume in a single take +and don't plan to use it for multisessioning(***), you have +the option to invoke growisofs with -dvd-compat option and cut +the real lead-out directly after the first session. + +

+ + + + + + + + + +
(*) +Well, there are lead-outs at the session edges, but +the problem is that "End Physical Sector Number of Data Area" +field in "Control Data Zone" of the lead-in contains address +of the largest media sector, which makes affected DVD[-ROM] players +calibrate at the outermost edge instead of the first session. Actually +I fail to understand why don't they burn the address of last sector of +the first session in the lead-in even on multisession discs... +
(**) +But beware the 4GB limit! +If 4GB is already an issue, or if you don't feel like throwing +unrelated data on the media in question, then invoke 'growisofs +-M /dev/scd0=/dev/zero' (supported by 5.6 and later). +Alternative is to re-master the whole volume, naturally with +-dvd-compat option. +
(***) +E.g. when mastering DVD-Video disc:-) Note that +-dvd-video option [passed to mkisofs] engages +-dvd-compat automatically.
+ +

+ +

Then we have logical format compatibility +issue(s). Probably the very ground for all the controversy around +DVD+RW, rather around DVD+RW media not being playable in a whole range +of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even +claiming that they deliberately block playback. But the fact is that +format specifications don't explicitly say that unrecognized format +[designated by "Book Type" field in "Control Data +Zone" of the lead-in] should be treated as DVD-ROM +and [in my opinion] it was rather naive of them to claim and expect +that the media will be playable in "virtually all players." +This deficiency was recognized by practically all DVD+RW vendors [well, +apparently by "traditional" DVD+RW vendors and not +"latest generation" vendors such as Sony, NEC, TDK...] and a +secret vendor-specific command +manipulating this "Book Type" field was implemented. So if +you fail to mount/play DVD+RW media, you might have an option to + +

dvd+rw-booktype -dvd-rom -media /dev/scdN
+ +

Once again. Not all vendors support this and you +can't expect this utility to work with all recorders. + +

It's naturally not possible to manipulate the +"Book Type" field on DVD+R media, that is not after the +lead-in is written [which takes place at the moment the first session +gets closed]. But it might be possible to control how it [lead-in] is +going to be branded by programming the drive in advance: + +

dvd+rw-booktype -dvd-rom -unit+r /dev/scdN
+ +

Meaning that if you fail to play DVD+R media, you +can attempt to burn another disc with more appropriate unit settings. +For more background information about dvd+rw-booktype, see "Compatibility +Bitsettings" article at dvdplusrw.org. + +

There [potentially] are other logical +DVD+RW(*) format incompatibilities, but the "Book +Type" issue discussed above is the only one "officially" +recognized. Well, it's actually understandable as it's the only one +that can be recognized and addressed by a DVD+RW vendor alone. +Recognition of other incompatibilities would require cooperation from +DVD[-ROM] player vendors and that's something they +apparently are not willing to show referring to the fact that DVD+RW +format is not approved [and apparently never will be] by DVD Forum(**). + +

+ + + + + +
(*) +Finalized DVD+R media branded with +DVD-ROM "Book Type" is virtually identical to +DVD-ROM.
(**) +To which I say "so what?" DVD Forum is an +alliance of manufacturers just like DVD+RW Alliance is. It [or any +other party for that matter] has no authority to deny a technology +development initiative.
+ +

+ +

Finally there is a physical incompatibility issue. +They claim that there are optical pick-ups out there not being capable +to decode the track because of low reflectivity of DVD+RW media +surface. I write "they claim," because in the lack of +cooperation from DVD[-ROM] vendors it's not possible to +distinguish physical from logical format incompatibility, which I find +important to tell apart in order to make sure at least logical format +incompatibility issues don't persist over time. It might be as trivial +as following. As you surely know [already], DVD+RW has same +reflectivity as dual-layer DVD-ROM. Now the catch is that +the linear pit density in turn is same as of single-layer one. Meaning +that if player makes assumptions about linear pit density based on +reflectivity, then it won't be able to trace the track... But either +way, there is very little you can do about this one, but to try another +player... + +

+ +

Technical Ramblings

+ +

+ +

+ +

As for multisession ISO9660 [DVD] +recordings! Unfortunately, Linux ISOFS implementation had certain +deficiency which limits interoperability of such recordings. In order +to understand it, have a look at sample ISO9660 layout to the right... +Now, the problem is that isofs i-nodes(*) are 32 bits wide +(on a 32-bit Linux) and represent offsets of corresponding directory +entries (light-greens), byte offsets from the beginning of media. This +means that no directory (green areas) may cross 4GB boundary without +being effectively corrupted:-( It should be noted that in +reality it's a bit better than it looks on the picture, as mkisofs +collects all the directories in the beginning of any particular session +(there normally are no blues between greens). The first session +is therefore never subject to i-node wrap-around, but not the +subsequent ones! Once again, files +themselves may reside beyond the 4GB +boundary, but not the directories, in +particular not in further sessions. Having noted that directory entries +are actually specified to start at even offsets, I figured that +it's perfectly possible to +"stretch" the limit to 8GB. But in order to assure +maximum interoperability, you should not let any session +start past 4GB minus space required for directory +structures, e.g. if the last session is to fill the media up, it +has to be >400MB. As of version 5.3 growisofs refuses to append +a new session beyond 4GB-40MB limit(**), where 40MB is +pretty much arbitrary chosen large value, large for directory catalogs +that is. Yet it doesn't actually guarantee that you can't suffer +from i-node wrap-around. Interim fs/isofs 2.4 +kernel patch was addressed to those who have actually ran into the +problem and have to salvage the data. Even though permanent solution +for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice +effort), growisofs keeps checking for this 4GB limit in order to ensure +broader compatibility of final DVD recordings. This check is not +performed for Blu-ray Disc recordings, as probability that a member of +such user community would run something elder than 2.6.9 is considered +diminishingly low. + + + + + + +
(*) +i-node is a number uniquely identifying a single +file in a file system +
(**) +well, as DVD+R Double Layer support was introduced +in 5.20, -use-the-force-luke=4gms option was added to override +this behaviour (naturally recommended for Linux kernel 2.6>=8 users and +kernel developers only;-) +
+ +


+ +

Why media reload is performed after every +recording with growisofs? Well, it's performed only if you didn't +patch the kernel:-) But no, I do not insist on patching the kernel! +All I'm saying is that in the lack of kernel support, media reload is +performed for the following reasons. In order to optimize file access +kernel maintains so called block cache, so that repetitive requests for +same data are met directly from memory and don't result in multiple +physical I/O. Now the catch is that block cache layer remains totally +unaware of growisofs activities, growisofs bypasses the block +cache. This means that block cache inevitably becomes out of sync, +which in turn might appear to you as corrupted data. Media reload is +performed when flushing the block cache is not an option, e.g. only +privileged user is allowed to perform it. Second reason is to force +kernel to readjust last addressable block in case it was changed as +result of recording. This is done to preclude spurious "attempts to +access beyond end of device." + +


+ +

What does [kernel] "DVD+RW support" +really mean? Even though DVD+RW has no notion of [multiple] +sessions, to ensure compatibility with DVD-ROM it's essential to issue +"CLOSE TRACK/SESSION (5Bh)" MMC command to +terminate/suspend background formatting (if any in progress) whenever +you intend to eject the media or simply stop writing and want better +read performance (e.g. remount file system read-only). This is what the +patch is basically about: noting when/if media was written to and +"finalizing" at unlock door. + +

Secondly, whenever you employ fully fledged +file system, I/O requests get inevitably fragmented. +"Fragmented" means following. Even though you can address the +data with 2KB granularity, it [data] is physically laid out in 32KB +chunks. This in turn means that for example writing of 2KB block +involves reading of 32KB chunk, replacing corresponding 2KB and writing +down of modified 32KB chunk. "Fragmented requests" are those +that are smaller than 32KB or/and cross the modulus 32KB boundaries. In +order to optimize the process certain caching algorithm is implemented +in unit's firmware. Obviously it can't adequately meet all possible +situations. And so in such unfortunate situations the drive apparently +stops processing I/O requests returning "COMMAND SEQUENCE ERROR +(2Ch)" ASC. This is the second essential of "DVD+RW +support," namely injecting of "SYNCHRONIZE CACHE (35h)" +MMC command in reply to the error condition in question. The command +flushes the cached buffers which makes it possible to resume the data +flow. + +

Unfortunately the above paragraph doesn't +seem to apply to the 1st generation drives, Ricoh MP5120A and +derivatives:-( "SYNCHRONIZE CACHE (35h)" doesn't +seem to be sufficient and the unit keeps replying with "COMMAND +SEQUENCE ERROR (2Ch)" going into end-less loop. This makes it +impossible to deploy arbitrary file system. I'm open for +suggestions... Meanwhile the I've chosen to simply suspend I/O till the +media is unmounted. Even 2nd gen unit were reported to exhibit similar +[but not the same] behaviour under apparently extremely rare +circumstances. At least I failed to reproduce the problem... The problem +reportedly disappears with firmware upgrade... + +

Then some [most?] of post-2nd gen units, from +most vendors, seem to not bother about complying with +DVD+RW specification, "true random write with 2KB +granularity" part in particular. Instead they apparently expect +host to apply procedure pretty much equivalent to DVD-RW +Restricted Overwrite. To be more specific host seems to be expected to +coalesce 2KB requests and perform aligned writes at native DVD ECC +blocksize, which is 32KB. Formally this should not be required, but +it's the reality of marketplace:-( + +

This one really beats me. Sometimes the unit +simply stops writing signaling a vendor specific positioning error, +03h/15h/82h to be specific. Especially if the media is newly formatted. +Couple of work theories. One is that block buffer cache reorders +requests so that they are not sequential anymore, "FLUSH +CACHE" might do the trick. Another one is that under +"underrun" condition background formatting kicks off and has +to be explicitly stopped. "Underrun" is in quotes because +the unit is supposed to handle temporary data stream outages +gracefully. If you run into this (you most likely will), try to +complement growisofs command line with [undocumented] +-poor-man option (which has to be first in the command line). +This option eliminates request reorders and minimizes possibility for +"underrun" condition (by releasing the pressure off VM +subsystem). + +


+ +

The original idea was to implement DVD+RW support in +drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private +"writeable" flag controlling the ability to issue WRITE +commands. The flag is impossible to reach for from the Unified CD-ROM +driver. But why am I talking about SCSI when there are only IDE units +out there (at least for the time being)? Well, as you most likely want +to occasionally burn even CD-R[W] with cdrecord you want it to go +through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM +driver is the one to aim for even for DVD+RW. + +

Unfortunately it was not possible to implement it +completely in sr_mod.o:-( Minor drivers/cdrom/cdrom.c +modification was required to sense the media before decision about +whether or not to permit write open. That's because DVD+RW drives are +morphing their behaviour after currently mounted media and it's +essential to identify newly inserted media. + +

Special comment about "what a dirty +hack!!!" To my great surprise it turned out that time-out value you +pass in cdrom_generic_command is simply ignored and time-out is set to +pre-compiled value of 30 seconds. Unfortunately it's way too low for +formatting purposes and I had to do something about it. Alternative to +"the dirty hack" was to add another argument to sr_do_ioctl +and modify all the calls to it... I've chosen to take over those 31 +unused bits from the "quiet" argument instead of modifying +all the calls (too boring). + +

But even if time-out value passed down to kernel +(with either CDROM_SEND_PACKET or SG_IO ioctl) is taken into +consideration, it's apparently not interpreted as user-land code +expects it to. As I figured... There is no documentation on +CDROM_SEND_PACKET, but following the common sense most programmers +(including myself:-) expect it to be interpreted in at least +platform-independent manner, such as milliseconds maybe? SG_IO timeout +in turn is documented +to be measured in milliseconds... Neither of this holds true! Kernel +treats these values as "jiffies," which is a +platform-dependent value representing time elapsed between timer +interrupts. But if we attempt to send down "jiffies," it +might turn out wrong too [at least for the moment of this writing]. The +catch is that [IA-32] kernel developers figured it's cool to shorten +"jiffy," but didn't care to provide user-land with actual +value (well, not of actual interest, too much legacy code to deal with) +nor scale timeouts +accordingly in respect to the legacy value of 10ms. + +

There is another kernel "deficiency" I ran +into while working on the (original version of) dvd+rw-format utility. +The drive provides background formatting progress status, but +unfortunately it's impossible to access it. That's because progress +counter is returned [in reply to "TEST UNIT READY"] as +"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense +bytes but with "GOOD" status. Apparently any sense data with +"GOOD" status is discarded by the common SCSI layer. + + + +

It was pointed out to me that DVD+RW units work with +Acard SCSI to +IDE bridges. + +

+ +

What does plus in DVD+RW/+R +stand for? Originally this paragraph started as following: + +

The key feature of DVD+RW/+R media is +high [spatial] frequency wobbled [pre-]groove with addressing +information modulated into it. This makes it possible to resume +interrupted [or deliberately suspended] burning process with accuracy +high enough for DVD[-ROM] player not to "notice" anything at +playback time. Recovery from buffer underrun condition in DVD-RW/-R +case in turn is way less accurate procedure, and the problem is that +the provided accuracy is very much what average player can tolerate. +Now given that both provided and tolerated inaccuracies are +proportional to respectively writing and reading velocities there +basically no guarantee that DVD-RW/-R recording that suffered from +buffer underrun will be universally playable.

+ +

Well, it turned out that I was wrong about one +thing. I failed to recognize that DVD-R[W] +groove also provides for adequately accurate recovery from +buffer underrun condition/lossless linking. Not as accurate as DVD+RW, +but accurate enough for splices to be playable in virtually any +DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording +specificaton apparently insists that you choose between + +

    +
  • buffer underrun protection and +
  • full DVD-ROM/-Video compatibility. +
+ +

The specification asserts that the latter is +achieved only in Disc-at-once recording mode and only if data-stream +was maintained uninterrupted throughout whole recording. Once again. +Even though most vendors implement lossless linking in DAO +mode(*), full DVD-ROM/-Video compatibility is +guaranteed only if recording didn't suffer from buffer underruns. The +problem is that "offended" sectors are denoted with certain +linking chunk appearing as degraded user data, few bytes, which +are supposed to be "corrected away" by ECC +procedure(**). DVD+ splices are in turn only few bits large +and are "accounted" to sync patterns, not to user data +area. So that even if suffered from buffer underrun, DVD+ sector is +logically indistiguishable from DVD-ROM. Which is why it's commonly +referred to that DVD+RW/+R combine DVD-ROM/-Video compatibility with +[unconditional] buffer underrun protection. + +

As already mentioned, DVD+ groove has +"addressing information modulated into it," ADIP (ADress In +Pre-groove). This gives you an advantage of writing DVD+RW in truly +arbitrary order, even to virgin surface and practically instantly +(after ~40 seconds long initial format procedure). In addition, DVD+RW +can be conveniently written to with 2KB granularity(***). +DVD-RW in turn can only be overwritten in arbitrary order. +Meaning that it either has to be completely formatted first (it takes +an hour to format 1x media), or initially written to in a sequential +manner. And it should also be noted that block overwrite is +never an option if DVD-RW media was recorded in [compatible] +Disc-at-once or even Incremental mode, only whole disc blanking is. + +

Unlike DVD-R[W], DVD+R[W] recordings can be +suspended at any time without any side effects. Consider following +scenario. You have a lot of data coming in [at lower rate], which is to +be recorded into one file. Meanwhile it turns out that you have to +retrieve previously recorded data. This would naturally require +suspention of recording. Most notably in DVD-R [and naturally DVD-RW +Sequential] case it would result in a hole in the file being recorded. +So called linking area, most commonly 32KB gap, has to be introduced. +So that you either have to wait till the file is complete or figure out +how to deal with holey files. Thanks to ADIP, DVD+R recording is +resumed from the very point it was suspended at. In DVD-RW Restricted +Overwrite case no gaps are introduced, but if the media was formatted +only minimally, suspension/resuming procedure has to be applied and it +takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming +is instant regardless media state. + +

What does all of the above mean in practice? Well, I +was actually hoping that readers would [be able to] figure it out by +themselves. Apparently a couple of "guiding" words are +needed... It means that it's trivial to employ DVD+RW for housing of +live and arbitrary file system, no special modifications to target file +system driver are required... Real-time VBR (Variable Bit Rate) Video +recordings are children's game... + +

Sometimes DVD+RW/+R recording strategy is referred +to as packet writing. I myself am reluctant to call it so (or +TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W] +provides for lossless linking (within a packet/extent only), +packets/extents are still denoted with certain linking information +which distinguishes it (recording mode in question) from e.g. +Disc-at-once. Now the point is that written DVD+RW/+R media, rather its +Data Zone, does not contain any linking information and is +logically indistinguishable from one written in DVD-R[W] Disc-at-once +mode (or DVD-ROM for that matter). + +

It's maintained that signal from DVD+ groove (the +one essential for recording, not reading) is much stronger, which makes +it quite resistant to dust, scratches, etc. + +

Now we can also discuss differences between +Double/Dual Layer implementations. DVD+R Double Layer permits for +arbitrary layer break positioning yet maintaining contiguous logical +block addressing. In other words address of the block following the +break is always address of the block preceding one plus 1, even for +arbitrarily positioned break. DVD-R Dual Layer on the +other hand implies unconditionally disjoint logical block addressing +[for arbitrarily positioned layer break that is]. This is because block +addresses as recorded by unit are pre-defined by DVD-dash +groove structure. In practice it means that file system layout has to +effectively have a hole, which "covers" twice the space between chosen +layer break position and outermost edge of the recordable area. And in +even more practical terms this means that mastering programs have to be +explicitly adapted for DVD-R layer break positioning. +Unlike DVD+plus that is. + +

+ + + + + + + +
(*) +According to Mt. Fuji draft +buffer underrun protection is not even an option in DVD-R DAO: "If a +buffer under-run occurs, the logical unit shall stop +writing immediately and the logical unit shall start +writing of Lead-out." Protection is defined in Incremental Sequential +mode and DVD-RW context. By the way, note that earlier versions of this +draft also discuss DVD+RW. You should be aware that they refer to +abandoned version which has very little to do with DVD+RW/+R +implementation being discussed here.
(**) +ECC redundancy does permit for more degradation, +more that this linking chunk that is, so that it hadly affects the +playability.
(***) +DVD "native" block size is 32KB, and 2KB +granularity is nothing but a trick, but you're excused from playing it, +i.e. reading 32KB, replacing corresponding 2KB and writing 32KB +back.
+ +

+ + + + + diff --git a/SPECS/dvd+rw-tools.spec b/SPECS/dvd+rw-tools.spec new file mode 100644 index 0000000..736b760 --- /dev/null +++ b/SPECS/dvd+rw-tools.spec @@ -0,0 +1,278 @@ +Summary: Toolchain to master DVD+RW/+R media +Name: dvd+rw-tools +Version: 7.1 +Release: 27%{?dist} +License: GPLv2 +Group: Applications/Multimedia +Source: http://fy.chalmers.se/~appro/linux/DVD+RW/tools/dvd+rw-tools-%{version}.tar.gz +Source1: index.html +Patch1: dvd+rw-tools-7.0.manpatch +Patch2: dvd+rw-tools-7.0-wexit.patch +Patch3: dvd+rw-tools-7.0-glibc2.6.90.patch +Patch4: dvd+rw-tools-7.0-reload.patch +Patch5: dvd+rw-tools-7.0-wctomb.patch +Patch6: dvd+rw-tools-7.0-dvddl.patch +Patch7: dvd+rw-tools-7.1-noevent.patch +Patch8: dvd+rw-tools-7.1-lastshort.patch +Patch9: dvd+rw-tools-7.1-format.patch +Patch10: dvd+rw-tools-7.1-bluray_srm+pow.patch +Patch11: dvd+rw-tools-7.1-bluray_pow_freespace.patch +Patch12: dvd+rw-tools-7.1-sysmacros.patch +URL: http://fy.chalmers.se/~appro/linux/DVD+RW/ +Requires: mkisofs >= 2.0 +BuildRequires: kernel-headers m4 + +%description +Collection of tools to master DVD+RW/+R media. For further +information see http://fy.chalmers.se/~appro/linux/DVD+RW/. + +%prep +%setup -q +%patch1 -p1 -b .manpatch +%patch2 -p1 -b .wexit +%patch3 -p1 -b .glibc2.6.90 +%patch4 -p1 -b .reload +%patch5 -p0 -b .wctomb +%patch6 -p0 -b .dvddl +%patch7 -p1 -b .noevent +%patch8 -p1 -b .lastshort +%patch9 -p1 -b .format +%patch10 -p1 -b .pow +%patch11 -p1 -b .freespace +%patch12 -p1 -b .sysmacros + +install -m 644 %{SOURCE1} index.html + +%build +export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" +export CXXFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" +export LDFLAGS="$RPM_LD_FLAGS" +make WARN="-DDEFAULT_BUF_SIZE_MB=16 -DRLIMIT_MEMLOCK" %{?_smp_mflags} + +%install +# make install DESTDIR= does not work here +%makeinstall + +%files +%doc index.html LICENSE +%{_bindir}/* +%{_mandir}/man1/*.1* + +%changelog +* Mon Aug 06 2018 Jakub Martisko - 7.1-27 +- Include sys/sysmacros header in the growisofs.c file +- Some macros have been moved from sys/types to sys/sysmacros which lead to FTBFS +- Resolves: 1611716 + +* Fri Feb 23 2018 Florian Weimer - 7.1-26 +- Use LDFLAGS from redhat-rpm-config + +* Wed Feb 07 2018 Fedora Release Engineering - 7.1-25 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild + +* Wed Aug 02 2017 Fedora Release Engineering - 7.1-24 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild + +* Wed Jul 26 2017 Fedora Release Engineering - 7.1-23 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild + +* Fri Feb 10 2017 Fedora Release Engineering - 7.1-22 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild + +* Wed Feb 03 2016 Fedora Release Engineering - 7.1-21 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild + +* Fri Oct 09 2015 Frantisek Kluknavsky - 7.1-20 +- serious typo in spec file - patch10 applied twice, patch11 not at all + +* Wed Jun 17 2015 Fedora Release Engineering - 7.1-19 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild + +* Sat May 02 2015 Kalev Lember - 7.1-18 +- Rebuilt for GCC 5 C++11 ABI change + +* Fri Nov 14 2014 Frantisek Kluknavsky - 7.1-17 +- added dvd+rw-tools-7.1-bluray_pow_freespace.patch, + based on https://bugzilla.redhat.com/show_bug.cgi?id=1082360 + count nwa (next writeable address) even in pow (pseudo overwrite) mode + +* Sat Aug 16 2014 Fedora Release Engineering - 7.1-16 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild + +* Sat Jun 07 2014 Fedora Release Engineering - 7.1-15 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild + +* Sat Aug 03 2013 Fedora Release Engineering - 7.1-14 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild + +* Mon Jun 24 2013 Frantisek Kluknavsky - 7.1-13 +- when formating blu-ray as srm+pow, handle it later correctly as srm+pow, not srm +(credits Thomas Schmitt) + +* Wed Feb 13 2013 Fedora Release Engineering - 7.1-12 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild + +* Mon Aug 27 2012 Honza Horak - 7.1-11 +- Spec file cleanup +- Print error in case we want to write already written DVD-RW in Sequential + Recording mode (bug #810838) +- Add man page for dvd+rw-format + +* Wed Jul 18 2012 Fedora Release Engineering - 7.1-10 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild + +* Mon Apr 16 2012 Honza Horak - 7.1-9 +- Allow buffer length of the block to be shorter than multiple of 16, + even in case of DAO writing (replaces the previous fix) + Resolves: #810483 + +* Fri Apr 06 2012 Honza Horak - 7.1-8 +- Align blocks count to multiple of 16 also in case of DAO writing + Resolves: #810483 + +* Wed Mar 07 2012 Honza Horak - 7.1-7 +- applied patch from Petr Sumbera to handle Teac DVD drive timeout issue + Resolves: #799299 + +* Fri Jan 13 2012 Fedora Release Engineering - 7.1-6 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild + +* Wed Jun 23 2010 Roman Rakus - 7.1-5 +- Compile with -fno-strict-aliasing CFLAG + +* Fri Jul 24 2009 Fedora Release Engineering - 7.1-4 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild + +* Tue Feb 24 2009 Fedora Release Engineering - 7.1-3 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild + +* Wed Dec 17 2008 Roman Rakus - 7.1-2 +- Allow burn small images on dvd-dl + Resolves: #476154 + +* Fri Aug 15 2008 Roman Rakus - 7.1-1 +- new version 7.1 + +* Wed Mar 26 2008 Harald Hoyer 7.0-11 +- fixed widechar overflow (bug #426068) (patch from Jonathan Kamens) + +* Mon Feb 18 2008 Fedora Release Engineering - 7.0-9 +- Autorebuild for GCC 4.3 + +* Tue Nov 20 2007 Harald Hoyer - 7.0-8 +- added a patch to fix a reload problem on some drives, + after a successful burn + +* Fri Aug 31 2007 Matthias Saou 7.0-7 +- Minor spec file cleanups (tabs vs. spaces, etc.). +- Use install instead of cp for the html file to avoid umask differences. + +* Fri Aug 17 2007 Harald Hoyer - 7.0-6 +- changed license to GPLv2 + +* Wed Aug 15 2007 Harald Hoyer - 7.0-5 +- added limits.h to transport.hxx + +* Thu Jun 21 2007 Harald Hoyer - 7.0-4 +- fixed exit status (#243036) +- Allow session to cross 4GB boundary regardless of medium type. + Add a -F option (used instead of -M or -Z), which displays + next_session offset and capacity. (#237967) + +* Tue Feb 27 2007 Harald Hoyer - 7.0-3 +- fixed specfile issues (#209985) + +* Thu Dec 14 2006 Harald Hoyer - 7.0-0.4 +- set pthread stack size according to limit (#215818) + +* Wed Dec 13 2006 Harald Hoyer - 7.0-0.3 +- use _SC_PHYS_PAGES instead of _SC_AVPHYS_PAGES to determine available memory +- Resolves: rhbz#216794 + +* Fri Nov 03 2006 Harald Hoyer - 7.0-0.2 +- define RLIMIT_MEMLOCK, which should resolve the memlock problems + +* Thu Oct 26 2006 Harald Hoyer - 7.0-0.1 +- new version 7.0 + +* Wed Jul 12 2006 Jesse Keating - 6.1-4.1 +- rebuild + +* Tue Jun 13 2006 Harald Hoyer - 6.1-4 +- more build requirements + +* Tue Apr 18 2006 Harald Hoyer - 6.1-2 +- compile with smaller buffer size +- removed O_EXCL patch + +* Fri Mar 24 2006 Harald Hoyer - 6.1-1 +- version 6.1 + +* Fri Feb 10 2006 Jesse Keating - 5.21.4.10.8-6.2.1 +- bump again for double-long bug on ppc(64) + +* Tue Feb 07 2006 Jesse Keating - 5.21.4.10.8-6.2 +- rebuilt for new gcc4.1 snapshot and glibc changes + +* Fri Dec 09 2005 Jesse Keating +- rebuilt + +* Wed Mar 02 2005 Harald Hoyer +- rebuilt + +* Wed Feb 16 2005 Harald Hoyer - 5.21.4.10.8-5 +- built with RPM_OPT_FLAGS + +* Wed Feb 09 2005 Harald Hoyer +- rebuilt + +* Thu Nov 18 2004 Harald Hoyer - 5.21.4.10.8-4 +- removed wget dependency + +* Wed Sep 01 2004 Harald Hoyer - 5.21.4.10.8-2 +- added dvd+rw-tools-5.21.4.10.8-excl.patch to open O_EXCL + +* Wed Sep 01 2004 Harald Hoyer - 5.21.4.10.8-1 +- version 5.21.4.10.8 + +* Mon Jul 26 2004 Harald Hoyer - 5.20.4.10.8-1 +- version 5.20.4.10.8 + +* Wed Jun 16 2004 Harald Hoyer - 5.19.1.4.9.7-1 +- version 5.19.1.4.9.7 + +* Tue Jun 15 2004 Elliot Lee +- rebuilt + +* Fri Feb 13 2004 Elliot Lee +- rebuilt + +* Thu Jan 29 2004 Harald Hoyer - 5.17.4.8.6-1 +- version 5.17.4.8.6 +- fixes 110740 110700 + +* Wed Oct 8 2003 Harald Hoyer 5.13.4.7.4-1 +- version 5.13.4.7.4 + +* Mon Sep 08 2003 Harald Hoyer 5.12.4.7.4-1 +* updated to version 5.12.4.7.4 + +* Wed Jun 04 2003 Elliot Lee +- rebuilt + +* Tue Apr 15 2003 Harald Hoyer 5.3.4.2.4-1 +- updated to version 5.3.4.2.4 + +* Mon Feb 3 2003 Chris Kloiber +- Updated version to 5.1.4.0.4 +- Requires mkisofs 2.0 + +* Thu Nov 4 2002 Andy Polyakov +- Minor growisofs update. Uninitialized errno at exit when + -Z /dev/scd0=image.iso is used. + +* Thu Nov 3 2002 Andy Polyakov +- Initial packaging. Package version is derived from growisofs, + dvd+rw-format and dvd+rw-booktype version. 4.0.3.0.3 means + growisofs 4.0, dvd+rw-format 3.0 dvd+rw-booktype 3. +