Problems like this appear when a software is not updated..
Debian already did miss 10 smake releases :-(
meanwhile smake icludes a lot more features and compiles
all software that does not depend on gmake bugs or features.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353
Martin Michlmayr [EMAIL PROTECTED] wrote:
* Paul Eggert [EMAIL PROTECTED] [2005-11-04 10:56]:
The POSIX guidelines say that options like -b and -f that take
arguments can be spelled either like this, with a space before
the option-arguments:
tar -cvb 20 -f x.tar file1 file2
or
Any reason why a bug that has been fixed 10 months ago
is still listed in debian Bugs?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/
URL:
Your problem may be a result of the patches applied by Debian..
90% of all bug reports against cdrtools on Linux are caused by the
unneded abd broken patches applied by various Linux distributions.
A recent k3b and a recent unmodified cdrtools (where cdrecord is installed suid
root)
This is doubtlesly a Linux Kernel bug.
Except, in case that you did not wait an hour to check whether
the drive is doing a full erase at minimum speed. In this case
it would be a drive firmware bug.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED]
If you don't like the numbers, send a bug report to the Linux
kernel folks. Note that doing this in a way that people expect
is not simple.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED]
Gabor Kiss [Bitman] [EMAIL PROTECTED] wrote:
If you don't like the numbers, send a bug report to the Linux
kernel folks. Note that doing this in a way that people expect
is not simple.
Hi Jörg,
I guess this is not a kernel problem.
Mkisofs runs entirely in user space and its output
Gabor Kiss [Bitman] [EMAIL PROTECTED] wrote:
Mkisofs does things right (the only possible way), if you don'nt like the
Are you sure mkisofs is Orange Book compliant?
Yes, it hast been checked for compliance by Kodak.
And in case you are really interested: Usual multi session CDs made on
Goedson Teixeira Paixao [EMAIL PROTECTED] wrote:
Em Ter, 2006-12-05 Ã s 14:45 +0100, Joerg Schilling escreveu:
Before you sare starting to guess about possible reasons, I recommend to
upgrade to a recent mkisofs
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and test again ;-)
Hi
Goedson Teixeira Paixao [EMAIL PROTECTED] wrote:
Em Qua, 2006-12-06 Ã s 00:37 +0100, Joerg Schilling escreveu:
Applying the patch in the attachment is all that's needed to (always)
use -iso-level 4. I'll work on a better patch that will adapt the
options used according to the depth
The burn package has dependencies on packages of cdrecord. It would be best
if burn's dependencies were changed to wodim | cdrecord and
genisoimage | mkisofs to allow it to work with the DFSG-compliant cdrkit
fork. Presumably no changes to the actual code would be necessary.
Please inform,
Hi,
check the latest 2.01.01a23-pre in ftp://ftp.berlios.de/pub/cdrecord/alpha/.
It contains an enhanced CUE sheet parser that allows you to write the
Zeta CD.
Note that it is pure luck that I did see your report. Sending Bugs reports to
Debian is a bad idea as Debian does not forward these
Package: mkisofs
Version: 4:2.01+01a03-5
Severity: normal
There is bug in options handling. It should not matter in which order
the options are given. See below for demonstation.
-rJf ERROR
-frJ ok
Hi Jari,
your problem is caused by a bug in the option parser (GNU
Eduard Bloch [EMAIL PROTECTED] wrote:
your problem is caused by a bug in the option parser (GNU getopt_long).
The mkisofs version you are using is very old ( 1.5 years). Three months
ago, mkisofs has been converted to use the more mature and older (starting
1982)
getargs(). This
Eduard Bloch [EMAIL PROTECTED] wrote:
This is not related to my text above and mkisofs _does_ give an error
message.
The problem I was referring to above will cause that string options will
silently get wrong parameters. And BTW: getargs allows you to contol the
behavior - GNU
Hi,
your problem has been fixed some time ago
Try out the latest official cdrtools from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work)
Hi,
your problem has been fixed!
Check out the latest official cdrtools at:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog:
Hi,
a lot of new features have been added to cdrtools during the past
two years.
RAW mode writing for the CDRWIN CUE file mode has been added recently and
supports already nearly all sector types. Please test the latest cdrtools from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and report
I was running in the same problem as described here, but mine is a bit
different.
After trying Mr. Schilling's last cdrecord version, things improved, but now I
have this instead:
[snip]
2005.cue: line 1: TITLE: command not found
2005.cue: line 2: SONGWRITER: command not found
2005.cue: line
Don Armstrong [EMAIL PROTECTED] wrote:
On Sun, 10 Dec 2006, Joerg Schilling wrote:
Stop abusing the Debian Bug tracking system!
First and foremost, the maintainer(s) of a Debian Package are wholy
responsible for determining the state of bugs assigned to their
packages in the BTS unless
Daniel Baumann [EMAIL PROTECTED] wrote:
the attached patch adds the needed rules to build succesfully on amd64.
However, I took it from sfind which ships a more updated rules-set.
Unfortunately, it is licensed under CDDL only, and sdd is GPL only,
hence the patch is incompatible.
Don't be
The option -C dir is not processed by star_fat,
may its a good idea not to create the link
from /bin/gnutar to /bin/star_fat unless this
option works. Gnutar is often used in Makefiles and
if -C source won't work the make failed.
This is not true: star of course handles the -C option.
The -C
Eduard Bloch [EMAIL PROTECTED] wrote:
#include hallo.h
* Martin Vlk [Fri, Nov 10 2006, 12:18:15PM]:
Hi, I wonder should this bug's priority be rised so that it is fixed before
etch? The tool is unusable like that so it is a pretty serious bug.
Why do you ask us? Ask Joerg Schilling, he
Daniel Baumann [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
Please read the DFSG, if you believe that you cannot do this, then the
License
that might prevent it is not a free license acording to DFSG.
this is not the place to discuss this again. cdrtools are purged from
Debian, you
Daniel Baumann [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
The program 'sdd' and The Schily Makefile system are independent projects
(GPL speech: works). As the GPL is an OSI aproved license, it must not
contaminate other projects like The Schily Makefile system, so
Daniel Baumann [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
You (yourself) did take the project independend make code from a different
project's tarball. Maybe, you should just educate those people inside
Debian who
did not understand DFSG § 9.
for a patch, there is nothing
Hi,
Debian now has the chance to verify whether they intend to create a fork
or whether they just like to do malicious agression
If they like to create a true fork, they should finally rename _all_
programs from cdrtools. If this doesn't happen, it is obvious that
there never was an
Eduard Bloch [EMAIL PROTECTED] wrote:
#include hallo.h
* Joerg Schilling [Thu, Nov 02 2006, 10:49:41AM]:
Hi,
Debian now has the chance to verify whether they intend to create a fork
or whether they just like to do malicious agression
If they like to create a true fork
the open source
community and Joerg Schilling. He may be a difficult person, but at least
As I am a member of the Open Source community, it is obvious that there
cannot be such a conflict.
There is however a conflict between the Open Source community and Debian
caused by the fact that Debian
Jan Willem Stumpel [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
As I am a member of the Open Source community, it is obvious
that there cannot be such a conflict.
There is however a conflict between the Open Source community
and Debian caused by the fact that Debian does not like
Before you sare starting to guess about possible reasons, I recommend to
upgrade to a recent mkisofs
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and test again ;-)
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
Yor problem is caused by either a Linux kernel bug or by
a defective libscg in the Debian fork of cdrtools.
I recommend to first uograde to a recent version of cdrtools
ftp://ftp.berlios.de/pub/cdrecord/alpha/
if the error
/usr/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no
If you are having problems with DVD writing, I recommend to
upgrade to a programt hat supports DVD writing:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED]
Your report is not really useful as it does not mention what hapens.
For a real bug report, you need to report the problem in a tracable way:
http://cdrecord.berlios.de/old/private/problems.html
Trying to guess what you may want so say.
If your problem is that there is an error condition
Michelle Konzack [EMAIL PROTECTED] wrote:
Am 2006-07-09 13:48:14, schrieb Joerg Schilling:
Eduard Bloch [EMAIL PROTECTED] wrote:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
have been verified to work correctly when installed suid-root on Linux and
Linux definitely requires cdrecord
Apple may or may not follow the standards here...
Your primary problem seems to be Linux kernel related and
it seems to be important to verify the filesystem image for
standard compliance. If the filesystem is not standard compliant,
you need to send a bug report to Apple. If the filesystem
Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2007-12-24 12:17:42 +0100, Joerg Schilling wrote:
Apple may or may not follow the standards here...
Since isoinfo detect errors (or do you mean that isoinfo may be
isoinfo is based in mkisofs technology.
The original Author of the Apple
Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2007-12-24 12:17:42 +0100, Joerg Schilling wrote:
Not all problems seen in cdrkit are present with the original
software, so it may be helpful to check therecent original cdrtools first.
ftp://ftp.berlios.de/pub/cdrecord/alpha/
I could
Vincent Lefevre [EMAIL PROTECTED] wrote:
I've attached an archive containing a directory dir (all the files
are empty, but what's important is their filename and if they are
present or not), the corresponding ISO image obtained on Mac OS X
with:
What happens if you mount this filesystem on
Vincent Lefevre [EMAIL PROTECTED] wrote:
The log messages just say:
Dec 25 21:01:32 vin kernel: loop: module loaded
Dec 25 21:02:01 vin kernel: ISO 9660 Extensions: Microsoft Joliet Level 1
Dec 25 21:02:01 vin kernel: ISO 9660 Extensions: IEEE_P1282
Dec 25 21:03:46 vin kernel: ISO 9660
$ gdb genisoimage
(gdb) set args -C 312032,365680 -M /dev/cdrom -v -v -print-size -JR -uid 0
-gid
0 -graft-points users/ivan/archives/=/.../users/ivan/archives/
Nothing strange (AFAICT) in /.../users/ivan/archives/. I may
specify another directory and it will segfault, too.
GOTO Masanori [EMAIL PROTECTED] wrote:
Nod. Joerg, it seems you know Linux kernel files well, so I guess
you're the best person to fix this issue. Debian packages usually
uses e2fslibs-dev, so this problem might have been hidden.
I am currently working heavily on my SchilliX an OpenSolaris
I am sorry, but there is no relation betwee your problem
and cdrercord.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I am sorry, but there is no relation between your problem and cdrercord.
Your problem is either caused by an ill-designed kernel (in
a decently designed kernel, all ioctl function codes are different
and for this reason, sending an ioctl to an improper device
will just cause a kernel error code
... GNU coding stadards suggest some thing and Microsoft coding standards
suggest to create a pop up window
Both are irrelevant for cdrtools.
UNIX tradition is to send the output of a prg -help call to stderr.
If yor shell does not support a pipe on stderr, it's time to look
for a new
Package: kernel
DISTRIB_ID=3DDebian
DISTRIB_RELEASE=3D3.1
DISTRIB_CODENAME=3Dsarge
DISTRIB_DESCRIPTION=3DDebian GNU/Linux
uname -a
Linux debian 2.6.8-pegasos #1 Wed Aug 18 16:40:30 CEST 2004 ppc GNU/Linux
When compiling star, I get error messages like:
=3D=3D COMPILING fflags.o
In file
GOTO Masanori [EMAIL PROTECTED] wrote:
uname -a
Linux debian 2.6.8-pegasos #1 Wed Aug 18 16:40:30 CEST 2004 ppc GNU/Linux
When compiling star, I get error messages like:
=3D=3D COMPILING fflags.o
In file included from /usr/include/linux/ext2_fs.h:20,
Tim Baverstock [EMAIL PROTECTED] wrote:
Hi.
I'm running the Debian/Woody package for both cdrecord and 2.4
kernel-sources, so the ioctls should be compatible (even if they're 4 years
old). So far as I know, I'm not using any GUI-based volume management (I use
fvwm2, not Gnome or KDE) but
GOTO Masanori [EMAIL PROTECTED] wrote:
I know that the Linux kernel developers are unwilling to fix their bugs but
if Debian does not push them to fix their junk, they will never start to
make Linux usable. the Linux kernel developers will just continue
rejecting
to learn
Tim Baverstock [EMAIL PROTECTED] wrote:
On Wednesday 30 March 2005 3:53 pm, you wrote:
'dev=/dev/cdrom' would have been confusing, but something like
Impossible SCSI address [-2, -2, -2] - have you specified dev=
properly? would have been good.
Well, first you did call cdrecord with
Horms [EMAIL PROTECTED] wrote:
When compiling star, I get error messages like:
=3D=3D COMPILING fflags.o
In file included from /usr/include/linux/ext2_fs.h:20,
from fflags.c:41:
/usr/include/linux/ext2_fs_sb.h:48: error: parse error before u32
Eduard,
if you have no clue about SCSI and kernel design, please do not comment
things you do not understand.
Using something like dev=ATA:2,0,0 still gives you
SCSI emulation, right?
There is not SCSI emulation at all!
Read README.ATAPI:
Well first a statement: There is no
I cannot understand why Debian does not tread outdated bug reports.
This bug has been fixed in May 2004 wuth cdrtools-2.01a29.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED](work) Blog:
If you use a program in contrary to the recommendations
of the man page (it is even on the first page) you cannot expect
it to work correctly.
If this Debian likes to keep this bug, it needs to be moved to
the list of kernel bugs.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353
Cdrecord needs to be run suid root (works only with non broken Linux kernels)
or as root.
As the relation between the /dev/sg* device nodes on Linux and the
real hardware is not constant over time, cdrecord needs to open all
/dev/sg* wntries and search for the drive.
If you run cdrecord with
In case cdrecord has no problems with the first session,
then your problem is a result of completely non-deterministic behavior
of the Linux Kernel.
While it is well known that Linux-2.6.8.1 or newer grade SCSI commands
into good commands and bad commands without a knowledge on the background
of
dev=ATA and dev=/dev/hdX are definitely not supposed to do the same thing.
Check the cdda2wav(1) man page.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED](work) Blog:
Linux is a constantly moving target.
Once the Linux kernel maintainers did decide on a device filesystem
implementation that will survive 2 years, it may make sense to
check whether it makes sense to implement support for it.
I am sory, but a major problem with Linux is that if you start
to
I am sorry but both cdrecord readcd just use libscg to set up the DMA
size. Libscg _exactly_ implements the interface that has been specified
by Douglas Gilbert (the person who did add this interface to Linux).
If Jens Axboe adds a new driver he would need to meet the specifications
of the
It took a long time to fix the original mkisofs code from the
original Author to make it work correctly.
Please do not try to expect any extra value in the behavior.
Use
isoinfo -i mycd1.iso -l
and
isoinfo -i mycd1.iso -l -R
to understand what happens.
If you like to write a CD for a mp3
This problem is caused by two facts:
- The Linux Kernel developers refuse to create a single
and orthogonal interface that allows to send SCSI commands to
any device that speaks SCSI.
Instead of fixing well known bugs in the 'old' interfaces,
they
Richard van den Berg [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
If you like to write a CD for a mp3 player it is good practice
to prepent the file name by something line 001_ 002_,
Instead of prepending, I use the following scheme (note that this bug
appeared when using a DVD
Andreas Metzler [EMAIL PROTECTED] wrote:
On 2005-02-26 Joerg Schilling [EMAIL PROTECTED] wrote:
dev=ATA and dev=/dev/hdX are definitely not supposed to do the same thing.
Hello,
What is the correct devicename on Linux 2.6, if I want DMA?
This is the wrong question:
If you like to have DMA
Eduard Bloch [EMAIL PROTECTED] wrote:
Using something like dev=ATA:2,0,0 still gives you
SCSI emulation, right?
There is not SCSI emulation at all!
As said... Setzen, Sechs.
If this is meant for Eduard Bloch, I will concur.
Read README.ATAPI, it is _the_ FAQ and it exists for a
Eduard Bloch [EMAIL PROTECTED] wrote:
Moin Joerg!
Joerg Schilling schrieb am Sonntag, den 27. Februar 2005:
If you like to have a decent CDDA extraction you need to use
generic SCSI and this is done by using the SCSI address syntax
instead of filnames.
Oh my...
man causality
man
Richard van den Berg [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
There is no bug in mkisofs.
I beg to differ.
I am sorry, but mkisofs definitely does nothing wrong here.
You are trying to request extra features from mkisofs that
go beyond what the stanards grant you
If the file
Byron Clark [EMAIL PROTECTED] wrote:
On Sat, Feb 26, 2005 at 09:40:51PM +0100, Joerg Schilling wrote:
Your problem is either caused by a kernel bug or by a bug
in the ATAPI - USB adaptor.
If you like to help,
run cdrecord -V to check the time and error codes of
a single read buffer
Linus Torvalds did call the incompatible interface change to the
SCSI generic intercase (he applied last year around August)
a Security Fix.
The modification was done by him overnight and without disussion
with the involved authors/maintainers. He was told at that time
that there was a better
The feature you are looking for is available since a November 2006:
cdrecord dev=4,0,0 -minfo
Cdrecord-ProDVD-ProBD-Clone 2.01.01a32 (i386-pc-solaris2.11) Copyright (C)
1995-2007 Jörg Schilling
scsidev: '4,0,0'
scsibus: 4 target: 0 lun: 0
Warning: Using USCSI interface.
Using libscg version
Just upgrade to a original cdrtools version.
Cdrecord auto-formats maiden dvd+rw since April 2004.
Cdrecord does not have the bugs from wodim..
http://cdrecord.berlios.de/
If you are looking for a debian compatible package, look here:
mkisofs is the actively maintained original software.
It makes no sense to advertize for defective forks like genisoimage
that are based on obsolete code.
Look into the debian bug tracking system to find a list of genisoimage bugs
that are not present in the original.
Here is the official
Hi,
it seems that you are a victim of a missunderstanding.
You cannot expect support from a dead fork that did never
do own code development.
The official support mailing list for cdrecord is here:
[EMAIL PROTECTED]
and BTW: cdrecord supports the the feature you are intereested for a
long
Peter Samuelson [EMAIL PROTECTED] wrote:
[Joerg Schilling]
You cannot expect support from a dead fork that did never
do own code development.
Please stop spamming our users and our bug tracking system. We don't
advertise our efforts on _your_ support channels. Kindly do us the
same
Peter Samuelson [EMAIL PROTECTED] wrote:
[Joerg Schilling]
Please do not try to ignore reality. The user I was responding
was interested in cdrecord and not in a defective fork.
Maybe you call it trying to convince our users to use your product
instead; I call it spam. We don't do
Brent S. Elmer, Ph.D. [EMAIL PROTECTED] wrote:
I replaced wodim and family and made symbolic links to cdrecord and
mkisofs as can be seen here:
[EMAIL PROTECTED]:~$ wodim -version
Cdrecord-ProDVD-ProBD-Clone 2.01.01a33 (i686-pc-linux-gnu) Copyright (C)
1995-2007 Jörg Schilling
[1]+ Done
Brent S. Elmer, Ph.D. [EMAIL PROTECTED] wrote:
I'm not sure what you mean. Are these not the versions of cdrecord and
mkisofs I should be using? I got them from the link in your email.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a33 (i686-pc-linux-gnu) Copyright (C)
1995-2007 Jörg Schilling
Ond??ej Surý [EMAIL PROTECTED] wrote:
Joerg,
please stop filling our BTS with comments which are useless for debian
users.
Please do not try to create confusion. I am helping people who believe that they
use my software. This of course needs to include to inform people about bugs
that are
This bug has been introduced by Debian.
Upgrade to a recent original version from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and it will go away.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED]
The original mkisofs includes the feature you like via the build in
find(1) since 1.5 years:
Get a recent original from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
and call
mkisofs -find . -xdev
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED]
Hi,
you are not using cdrecord but a bastardizd variant that
does not really support to write DVDs.
To verify a real problem, you would first need to upgrade to a
recent version of the official source:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Make sure to install cdrecord suid root.
Further
DaVinci [EMAIL PROTECTED] wrote:
El miércoles 13 de diciembre, Joerg Schilling escribió:
Hi,
your problem has been fixed!
Check out the latest official cdrtools at:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Thank you. But I don't know how this affect to Debian branch
Don Armstrong [EMAIL PROTECTED] wrote:
I did already explain recisely what the problem is.
I've read the logs, and I still have no idea what you're talking
about.
What information do you need?
Let me spell it out the process even more clearly:
1) Send mail explaining precisely what
Peter Samuelson [EMAIL PROTECTED] wrote:
[Joerg Schilling]
I did give an example: use what(1) on a binary compiled from the
source before and after the change to see the difference.
If you did look at the SVN, if you did have a look at the most recent
changes. it would be easy
Sune Vuorela [EMAIL PROTECTED] wrote:
On Saturday 16 December 2006 12:44, Joerg Schilling wrote:
The removed text is needed in order to allow people to check the original
version information and Copyright for all relevent files using the what(1)
command.
Until this bug, I had no clue
Eduard Bloch [EMAIL PROTECTED] wrote:
Developers can retrieve the copyright information in cdrkit easily.
Users can retrieve the copyright information in cdrkit easily.
Have I forgotten someone?
You had the chance to ask me for the permission to remove this code.
Instead, you decided to
You do not need to understand the background.
You just need to remember that you are not allowed to remove Copyright
information.
This is a week sence I did inform you about the Copyright violation.
Note that today, you have to either remove your project from the server or
to undo the
Hi,
the best way to deal with your problem is to just install an
original version of cdrtools from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
recent versions include a workaround to include the ATA drives
in the SCSI namespace. This allows cdrecord to again find all
drives via cdrecord
Stephen Gran [EMAIL PROTECTED] wrote:
This one time, at band camp, Joerg Schilling said:
You do not need to understand the background.
You just need to remember that you are not allowed to remove Copyright
information.
This is a week sence I did inform you about the Copyright
Stephen Gran [EMAIL PROTECTED] wrote:
http://svn.debian.org/wsvn/debburn?op=comp[EMAIL PROTECTED][EMAIL
PROTECTED]
http://tinyurl.com/y9ld8g
So, if this is in fact the problem that Joerg is talking about, there is
no problem. No copyright notices have been removed. Some
It turns out that I'd overlooked relevant sections in the documentation
(Linux Notes in Chapter 4) and there is (or at least was) a way to use ATAPI
interface. Still it doesn't work for me, and
(thanks to Joerg pointing that out to us) it can be seen as a minor bug
in wodim --- because it says,
Stephen Gran [EMAIL PROTECTED] wrote:
I am aware of what the strings are used for. Can you point out the
section of the license that says that copyright must be conveyed as a
char string in the binary? I only see that it should be kept in the
source file, which it is. Can you please
Hi,
the cause for your problem is that the archive has not been written by
cpio but most likely by GNU cpio.
It seems that this archive ignores the fact that the official cpio program,
see:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cpio/
always writes lower case
Using this option in any way, even alone, causes star to
crash. Backtrace follows :
(gdb) run -data-change-warn
Starting program: /bin/star -data-change-warn
Program received signal SIGSEGV, Segmentation fault.
0x080704e0 in errflags ()
(gdb) bt
#0 0x080704e0 in errflags ()
#1 0x08070755 in
Julian Andres Klode [EMAIL PROTECTED] wrote:
Am Samstag, den 14.07.2007, 22:13 +0200 schrieb Joerg Schilling:
Hi,
do not expect to get any useful answer/help for your Debian bugreport.
The projct is dead.
At least it does not violate against the GPL.
BTW: I cannot see any problems
Applying a patch to /etc/default/cdrecord that introduces
content that _contradicts_ the warnings in the man page and
that caused cdda2wav to (by default) use the bad kernel based
CDDA instead of the SCSI based CDDA inside cdda2wav is a real
bad idea.
To be more explicit: using dev=
The problem has been resolved with Dave Platt more than
a year ago. He did rename his (younger) program to grunch-match.
Note that the match Schily match(1) program is more than 20 years
old and implements a grep like interface around an enhanced
version of the pattern matcher from Martin
When using -atime -ctime (to let star restore all inode times after the
dump), star with root privs undeterminably fast-forwards the system time.
This is really SERIOUS bug, which should not occur in such software.
This is probably caused by the method of restoring i-node ctime, see
The problem is caused by braindead modifications applied by Debian to
cdrtools. Please do not blaim me for bugs that are not in the official
cdrtools source.
An unmodified cdrtools (run as root as documented in the man page)
does not have this problem.
Jörg
--
EMail:[EMAIL PROTECTED] (home)
Wakko Warner [EMAIL PROTECTED] wrote:
An unmodified cdrtools (run as root as documented in the man page)
does not have this problem.
1) I sent this to debian's bug tracking. What was done with it after that
is not my fault. I found a bug, and explained it.
2) The dev=x,y,z part is
No, it definitely should not work as this would
cause cdrecord to fail.
Cdrecord even has been modified to allow 3 seconds as minimum
value in February to allow vold to calm down on the device
and to have better intercation with removable media managing.
Jörg
--
EMail:[EMAIL PROTECTED] (home)
1 - 100 of 246 matches
Mail list logo
