Hi,
the cd-paranoia commits look correkt to me.
But i have a long term clarity objection and believe to see the insertion
of an unreachable piece of code.
-
https://github.com/vext01/libcdio-paranoia/commits/start-track-num-n
Hi,
> WRT the review, is it possible you looked at the wrong branch?
Somehow it seems so. Looking again at
https://github.com/vext01/libcdio/commits/openbsd_fixes_to_master_for_merge
i see a more compact commit list and the commit ids do not match
my review.
Whatever, my evaluation does not ch
On Sun, Dec 16, 2018 at 11:36:40AM +0100, Thomas Schmitt wrote:
> Hi,
>
> the commit history in libcdio/commits/openbsd_fixes_to_master_for_merge
> looks good to me, as far as i can judge without testing on OpenBSD and
> NetBSD.
>
> A last bug fix about CDIOREADMSADDR in get_last_session_netbsd()
Hi,
the commit history in libcdio/commits/openbsd_fixes_to_master_for_merge
looks good to me, as far as i can judge without testing on OpenBSD and
NetBSD.
A last bug fix about CDIOREADMSADDR in get_last_session_netbsd() seems
still necessary (i proposed to initialize "int addr" to 0).
I will rev
Hi,
> Evening everyone,
Great timing. I am just done with properly failing to reproduce a xorriso
problem in a 32 bit VM. (Procrastinated since a week. Now the ball is back
in the Guix yard.)
> I've sucked Thomas' changes into my cdio-paranoia branch,
Thanks a lot for adopting them.
> ++ WAR
Evening everyone,
On Wed, Dec 12, 2018 at 02:25:54PM -0500, Rocky Bernstein wrote:
> One wonderful thing about git is that it's very hard to *totally* mess up
> the history. And because git repositories are disributed in the same way
> that blockchains work, there are multiple copies with that hav
On Wed, Dec 12, 2018 at 1:58 PM Thomas Schmitt wrote:
> Hi,
>
> i wrote:
> > > Rocky once forced libcdio commit permissions on me. (Frightening.)
>
> Rocky Bernstein wrote:
> > I assume that was a typo for Delighting
>
> You should be frightened too. :))
>
One wonderful thing about git is that i
Hi,
i wrote:
> > Rocky once forced libcdio commit permissions on me. (Frightening.)
Rocky Bernstein wrote:
> I assume that was a typo for Delighting
You should be frightened too. :))
For example i forgot how to create a new branch and dug out old attempts
of yours to make me smarter:
> ... >
On Wed, Dec 12, 2018 at 1:12 PM Thomas Schmitt wrote:
> Hi,
>
> Edd Barret wrote:
> > If you send me the URL to your git repo
>
> I don't have a remote git repo of my own. Only access to some that are
> maintained by others.
> In general i suspect that git is smarter than me.
>
>
> > I guess you
Hi,
Edd Barret wrote:
> If you send me the URL to your git repo
I don't have a remote git repo of my own. Only access to some that are
maintained by others.
In general i suspect that git is smarter than me.
> I guess you can use a similar strategy to get my libcdio changes into a
> branch on sa
On Wed, Dec 12, 2018 at 01:06:36PM +0100, Thomas Schmitt wrote:
> I assume i take profit from your work in libcdio-paranoia.
> Vice versa, my two changes should be beneficial on OpenBSD and NetBSD.
> They fix non-fatal bugs.
>
> My libcdio change is in gnu_linux.c. Not relevant for the BSDs.
>
>
Hi,
now about the other aspects of Edd's mail from yesterday:
> How independent are my changes from yours after all?
I assume i take profit from your work in libcdio-paranoia.
Vice versa, my two changes should be beneficial on OpenBSD and NetBSD.
They fix non-fatal bugs.
My libcdio change is in
Hi,
more mail will follow. This one is only about the outcome of the proposed
cd-paranoia tests.
The results look good (with my two changes for "Table of contents" and
"Attempting to determine drive endianness from data").
The long run time of "cd-paranoia -Q" with my track 1-3 CD turned out
to
On Tue, Dec 11, 2018 at 07:31:46PM +0100, Thomas Schmitt wrote:
> The following run now works for me without raising further suspicions:
>
> cd-paranoia -d /dev/sr4 -Q
>
> I could need exact instructions about what further tests to run.
Can you try the following quick tests.
1) Rip an entire
Hi,
Rocky Bernstein wrote:
> For cdio_paranoia changes, use the usual github process of submitting pull
> request.
I hope that Edd knows what is usual there. :))
Well, first he will have to test my changes.
> Also, if Edd hasn't filled out a FSF copyright release form, he should do
> that.
La
On Tue, Dec 11, 2018 at 1:48 PM Thomas Schmitt wrote:
> Hi,
>
> lagging behind my promises i today combined vetx01/libcdio with
> vext01/libcdio-paranoia.
>
> Bugs found and fixed so far:
>
> - libcdio/lib/driver/gnu_linux.c puts the highest track number into the
> track counter _img_private_t.
Hi,
lagging behind my promises i today combined vetx01/libcdio with
vext01/libcdio-paranoia.
Bugs found and fixed so far:
- libcdio/lib/driver/gnu_linux.c puts the highest track number into the
track counter _img_private_t.i_tracks (netbsd.c does it right).
This caused ill track access, but
Hi,
i wrote:
> > Do we expect any need for modern changes on GNU/Linux ?
Edd Barret wrote:
> I think thought the Linux driver was already set up
> for CDs with starting tracks not 1.
Do you get better results from
src/cd-paranoia -d /dev/... -Q
I.e. correct track start and sizes, correct TOT
On Sun, Dec 09, 2018 at 11:35:44PM +0100, Thomas Schmitt wrote:
> it comes to me that i do not have the vext01 branch of libcdio installed
> here.
>
> Don't even know what version of libcdio the script ./src/cd-paranoia
> is actually using.
> Do we expect any need for modern changes on GNU/Linux ?
Hi,
it comes to me that i do not have the vext01 branch of libcdio installed
here. Don't even know what version of libcdio the script ./src/cd-paranoia
is actually using.
Do we expect any need for modern changes on GNU/Linux ?
(Afaics, the gnu_linux.c driver was already prepared for first_track>1.
Hi,
> Are you able to do the Linux testing?
In principle, yes.
But you need to give me instructions about what to do exactly.
---
Working in advance:
git clone https://github.com/vext01/libcdio-paranoia
cd libcdio-paranoia
On Sun, Dec 09, 2018 at 08:53:35PM +0100, Thomas Schmitt wrote:
> Hi,
>
> > I've just finished a bug-finding session on cd-paranoia.
>
> What repo are you working with ?
> I'm now looking at
> https://github.com/rocky/libcdio-paranoia/tree/master
I've just made a fork so I can keep track of my
Hi,
> I've just finished a bug-finding session on cd-paranoia.
What repo are you working with ?
I'm now looking at
https://github.com/rocky/libcdio-paranoia/tree/master
--
> diff --git a/lib/cdda_interface/cddap_interface.c
> -
On Sun, Dec 09, 2018 at 05:57:20PM +0100, Thomas Schmitt wrote:
> So was the shown cd-info result from the intermediate state before
>
> https://github.com/vext01/libcdio/commit/539c52488506c5bacdfebbcafc5406034a0738fd
Correct.
> But why then didn't this yield an error message ?
>
> So get_tra
Hi,
> To clarify, before the fix I posted in my previous email:
So was the shown cd-info result from the intermediate state before
https://github.com/vext01/libcdio/commit/539c52488506c5bacdfebbcafc5406034a0738fd
?
(Pity, i had it in mind as reason for the cdparanoia complaint.)
But why then
On Sat, Dec 08, 2018 at 04:53:24PM +0100, Thomas Schmitt wrote:
> But i would really be surprised if it worked with the intermediate state
> where this was already in place:
>
> > 11: 09:41:34 043459 audio false no0no
> > 170: 09:41:34 043459 leadout (97 MB raw, 97 MB formatted)
>
Hi,
> Thanks for your on-going patience.
I was in no way bored. (And now there is a potential problem of my own
software with 32-bit GNU/Linux, at least with Guix. Grrr.)
> If I print the computed leadout for my 5-track CD starting at 7:
> ...
> Clearly the leadout track should be 12, not 6.
S
Hi everyone,
Thanks for your on-going patience.
On Mon, Dec 03, 2018 at 10:11:35AM +, Edd Barrett wrote:
> Hi guys,
>
> On Sun, Dec 02, 2018 at 10:01:48PM +0100, Thomas Schmitt wrote:
> > Edd first has to test the current state (which should show wrong info
> > about leadout if first_track >
Hi guys,
On Sun, Dec 02, 2018 at 10:01:48PM +0100, Thomas Schmitt wrote:
> Edd first has to test the current state (which should show wrong info
> about leadout if first_track > 1) and then my proposal.
>
> Well, the weekend is nearly over. $WORK will have me in the next days.
Ack. Thanks for you
Hi,
> > i think that this is now wrong:
Rocky Bernstein wrote:
> Ok. You have commit access to the repository: fix it the way you think it
> should be.
Edd first has to test the current state (which should show wrong info
about leadout if first_track > 1) and then my proposal.
I currently ponde
On Sun, Dec 2, 2018 at 3:37 PM Thomas Schmitt wrote:
> Hi,
>
> i think that this is now wrong:
> > >if (track_num == CDIO_CDROM_LEADOUT_TRACK)
> > >track_num = TOTAL_TRACKS + 1;
>
Ok. You have commit access to the repository: fix it the way you think it
should be.
> Edd Barre
Hi,
i think that this is now wrong:
> >if (track_num == CDIO_CDROM_LEADOUT_TRACK)
> >track_num = TOTAL_TRACKS + 1;
Edd Barrett wrote:
> I think that's ok after all. If we look at the definition of
> TOTAL_TRACKS, we see that it takes the starting track into account:
> #define TOTA
Edd's patch has been applied but there was a slight mistake that running
the tests caught: the value in the assignment to i should have been
CDIO_CDROM_LEADOUT_TRACK-1, not CDIO_CDROM_LEADOUT_TRACK.
On Sun, Dec 2, 2018 at 1:34 PM Edd Barrett wrote:
> Hi Thomas,
>
> On Sat, Dec 01, 2018 at 08:40
Hi Thomas,
On Sat, Dec 01, 2018 at 08:40:00PM +0100, Thomas Schmitt wrote:
>if (track_num == CDIO_CDROM_LEADOUT_TRACK)
>track_num = TOTAL_TRACKS + 1;
I think that's ok after all. If we look at the definition of
TOTAL_TRACKS, we see that it takes the starting track into account:
-
Hi,
Edd Barrett wrote:
> I've finally found some time to look at this. The following diff seems
> to work, although I don't think I have any CDs where the first track
> number isn't 1 to test with.
Commercial test candidates would be second CDs of a multi-CD album.
Self-made CDs can get arbitrar
Hi Thomas,
On Sun, Nov 04, 2018 at 06:02:31PM +0100, Thomas Schmitt wrote:
> At least the bug about the potentially wrong track number interpretation
> in get_track_msf_netbsd() and get_track_format_netbsd() should be tackled.
> See my message
> http://lists.gnu.org/archive/html/libcdio-devel/20
Hi,
Edd Barrett wrote:
> ++ WARN: ioctl CDIOREADMSADDR failed: Invalid argument
You should try to find out what get_last_session_netbsd() submits to
that ioctl. Regrettably i found not much of documentation for
CDIOREADMSADDR.
https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/cdio.h
Hi,
On Sat, Nov 03, 2018 at 05:49:10PM +, Edd Barrett wrote:
> Gregg, can you give my branch a spin with that new commit?
OK, I installed NetBSD on an old laptop for testing.
Using the head of my branch cdparanoia worked, with some messages:
---8<---
$ ../libcdio-paranoia/inst/bin/cd-parano
On Sat, Nov 03, 2018 at 05:37:11PM +0100, Thomas Schmitt wrote:
> Hi,
>
> Edd Barrett wrote:
> > https://github.com/vext01/libcdio/commit/4dab9d84e305771cebe202810e484a239fed4963
> > Are we expecting this to fix any of Gregg's issues though?
>
> Yes. At least these two should vanish, because .get
Hi,
Edd Barrett wrote:
> https://github.com/vext01/libcdio/commit/4dab9d84e305771cebe202810e484a239fed4963
> Are we expecting this to fix any of Gregg's issues though?
Yes. At least these two should vanish, because .get_track_lba() is not
offered any more and thus does not wrongly assume LBA addr
On Tue, Oct 30, 2018 at 11:46:29PM +0100, Thomas Schmitt wrote:
> (I still doubt that OpenBSD cannot deliver MSF. In the end it is about
> a field in SCSI command READ TOC/PMA/ATIP. But exploring this is a new
> adventure which we can easily avoid by result conversion.)
If my diff is correct, th
Hi,
i had a look at the other error messages reported by Greg in
http://lists.gnu.org/archive/html/libcdio-devel/2018-10/msg00011.html
assuming that
> SCIOCCOMMAND cmd 0xbe sts 3
> 010: Unable to access sector 169348352: skipping...
are now explained by the MSF-LBA confusion.
> WARN: ioctl CD
(I'm a big paged out today and not really keeping up, but wanted to
comment quickly since I was asked.)
"Thomas Schmitt" writes:
> Edd Barrett wrote:
>> Is it important, though, to offer up both addressing modes for consumers
>> of libcdio? Or is it not exposed that way?
>> Put differently, if t
Hi,
Edd Barrett wrote:
> Is it important, though, to offer up both addressing modes for consumers
> of libcdio? Or is it not exposed that way?
> Put differently, if the underlying OS supports both addressing modes,
> should we implement both callbacks in the driver.
The libcdio API has functions
On Tue, Oct 30, 2018 at 10:33 PM Edd Barrett wrote:
> On Tue, Oct 30, 2018 at 09:16:31PM +0100, Thomas Schmitt wrote:
> > A simple solution would be to throw out get_track_lba_netbsd() and
> > to set .get_track_lba to NULL.
> > Then both functions in track.c would use get_track_msf_netbsd().
> >
On Tue, Oct 30, 2018 at 09:16:31PM +0100, Thomas Schmitt wrote:
> A simple solution would be to throw out get_track_lba_netbsd() and
> to set .get_track_lba to NULL.
> Then both functions in track.c would use get_track_msf_netbsd().
> Next one would fix get_track_msf_netbsd() to take into respect
>
Hi,
i see a possible explanation for wrong LBA on NetBSD in
https://github.com/vext01/libcdio/commit/3826afab31d4d418be3f0fee1132fa61077000f5
Function get_track_lba_netbsd() assumes that read_toc_netbsd() obtains
tocent[].addr in LBA format. But on NetBSD the obtained format is MSF
(and in Ope
Hi,
independent of the reason why Edd Barrett's branch of libcdio does
not work for libcdio-cdparanoia on Greg Troxel's NetBSD, i give my opinion
about how to complete
https://github.com/vext01/libcdio/commit/e2f3919357b76d9fadb3d57f20d2b1e8198f32d1
"The TOC needs to be read in LBA format on
Hi,
Edd Barrett wrote:
> My branch is:
> https://github.com/vext01/libcdio/tree/openbsd_fixes_to_master
> To be clear, I've only changed libcdio, and not cdio-paranoia.
Ah yes. This explains much of my confusion.
But most of the messages reported by Greg do not stem from libcdio.
So back to you
On Mon, Oct 29, 2018 at 01:15:05PM +, Edd Barrett wrote:
> On Mon, Oct 29, 2018 at 01:37:45PM +0100, Thomas Schmitt wrote:
> > Please give me the URL of your cdparanoia branch.
>
> My branch is:
> https://github.com/vext01/libcdio/tree/openbsd_fixes_to_master
To be clear, I've only changed li
On Mon, Oct 29, 2018 at 01:37:45PM +0100, Thomas Schmitt wrote:
> Please give me the URL of your cdparanoia branch.
My branch is:
https://github.com/vext01/libcdio/tree/openbsd_fixes_to_master
Make sure you switch into the `openbsd_fixes_to_master` branch, as
`master` in my repo just tracks upstr
Hi,
Edd Barrett wrote:
> I'm super-happy that someone can help with this! As you can
> tell, I'm no expert.
I have few knowledge about NetBSD and cdparanoia's internals. But as
developer of libburn, i am hopefully able to recognize problems with
SCSI/MMC command parameters if i get to see them.
On Mon, Oct 29, 2018 at 12:21:26PM +0100, Thomas Schmitt wrote:
> Sorry, i did not pay attention to this thread before it became SCSI-ish.
No worries! I'm super-happy that someone can help with this! As you can
tell, I'm no expert.
There's a couple of messages on OpenBSD (on my branch) too, but n
Hi,
Greg Troxel wrote:
> > SCIOCCOMMAND cmd 0xbe sts 3
Edd Barrett wrote:
> The 0xbe messages I think are to do with setting the volume.
My theory (backed by libburn's sg-netbsd.c and
http://ftp.netbsd.org/pub/NetBSD/NetBSD-release-8/src/sys/sys/scsiio.h)
is that "cmd 0xbe" means the SCSI comm
Hi,
On Fri, Oct 26, 2018 at 01:31:55PM -0400, Greg Troxel wrote:
> Log follows, from your branch and libcdio-paranoia master:
>
> cdparanoia III release 10.2 libcdio 2.0.0 x86_64-unknown-netbsd7.1
> (C) 2001 Monty and Xiphophorus
> (C) 2004, 2005, 2008 Rocky Bernstein
> (C) 2014 Robert
It turns out while I had actually built your branch and installed it to
/usr/local, I had a release in /usr/pkg. Sorry - I should be more
careful, but I'm not so used to flipping between pkg and hand built.
I ran "gmake check" on your branch, and there's still an mmc_read issue
like on master, bu
Edd Barrett writes:
> Thanks for testing.
Glad to help - I don't expect to be really digging in, but try to pop in
and help portability here and there.
[deleting lots of this when there's no reason for me to add anything]
> On Thu, Oct 25, 2018 at 08:28:56PM -0400, Greg Troxel wrote:
>> cdda-
Hi Greg,
Thanks for testing.
On Thu, Oct 25, 2018 at 08:28:56PM -0400, Greg Troxel wrote:
> ok, but when this is merged a comment is in order, so that people
> starting to read the code will get that.
Agreed.
> I built the branch and am currently using cd-paranoia with it to rip a
> disc, and I
On Thu, Oct 25, 2018 at 8:30 PM Greg Troxel wrote:
> Edd Barrett writes:
>
> > Hi Greg,
> >
> > Thanks for getting back to us. I'm an OpenBSD developer trying to get
> > the NetBSD driver to work for OpenBSD.
> >
> > On Fri, Oct 12, 2018 at 10:02:16PM -0400, Greg Troxel wrote:
> >> 405: Option
On Thu, Oct 25, 2018 at 8:30 PM Greg Troxel wrote:
> Edd Barrett writes:
>
> > Hi Greg,
> >
> > Thanks for getting back to us. I'm an OpenBSD developer trying to get
> > the NetBSD driver to work for OpenBSD.
> >
> > On Fri, Oct 12, 2018 at 10:02:16PM -0400, Greg Troxel wrote:
> >> 405: Option
Edd Barrett writes:
> Hi Greg,
>
> Thanks for getting back to us. I'm an OpenBSD developer trying to get
> the NetBSD driver to work for OpenBSD.
>
> On Fri, Oct 12, 2018 at 10:02:16PM -0400, Greg Troxel wrote:
>> 405: Option not supported by drive
>
> I've seen this. If I remember correctly (b
Hi Greg,
Thanks for getting back to us. I'm an OpenBSD developer trying to get
the NetBSD driver to work for OpenBSD.
On Fri, Oct 12, 2018 at 10:02:16PM -0400, Greg Troxel wrote:
> 405: Option not supported by drive
I've seen this. If I remember correctly (but please double check), I
traced it
62 matches
Mail list logo
