| 1 |
tis 2001-12-04 klockan 21.33 skrev Dan Armak: |
| 2 |
> Hi all, |
| 3 |
|
| 4 |
Hi! |
| 5 |
|
| 6 |
Sorry for the late answer. |
| 7 |
|
| 8 |
> I've fixed a bug in the cdrtools ebuilds, now they install the readcd binary |
| 9 |
> correctly. xcdroast will now work again (it hadn't since we replaced |
| 10 |
> app-cdr/cdrecord with cdrtools). |
| 11 |
|
| 12 |
Great! |
| 13 |
|
| 14 |
> However, for it to start the -n parameter is needed, which turns off cdrecord |
| 15 |
> version checking. Otherwise it won't start unless a cdrecord of a specific |
| 16 |
> version number, which is hardcoded into the source code, can be located. |
| 17 |
> |
| 18 |
> I don't know of any problems that may be caused by using a newer version of |
| 19 |
> cdrecord than the one it wants, but there may have been a good reason to make |
| 20 |
> it work that way. If we ascertain that it works OK with the newer versions, |
| 21 |
> we'll need to to decide on a way to tell users to use the -n flag, or even to |
| 22 |
> patch the source to make it unnecessary. Info? Ideas? |
| 23 |
|
| 24 |
Worked fine here. I think it would be ok to patch xcdroast (or can we |
| 25 |
set some configure/compile-time flag to remove this check?) |
| 26 |
|
| 27 |
I don't *think* it'll break the burning in the middle, it's probably to |
| 28 |
ensure that flags are there and such, so we could always remove our |
| 29 |
patch if versions of cdrecord start showing up that isn't supported. |
| 30 |
|
| 31 |
Regards, |
| 32 |
Mikael Hallendal |
| 33 |
|
| 34 |
-- |
| 35 |
|
| 36 |
Mikael Hallendal |
| 37 |
Gentoo Linux Developer, Desktop Team Leader |
| 38 |
CodeFactory AB, Stockholm, Sweden |
Archives