Re: [Libcdio-devel] OS/2 patches

[Natalia Portillo]

Hi Rocky,

Setting up the VM shouldn't be difficult but giving access to it is a good 
question. Afaik only virtual box supports OS/2. I have to check if newer 
versions of KVM do.

Sent from my iPhone

> On 30/7/2014, at 11:37, Rocky Bernstein <address@hidden> wrote:
> 
> Ok. Both patches have been applied. Thanks.
> 
> Still waiting on Natalia to get OS/2 access set up for developers. If
> however you want to or set up some sort of access to OS/2 for folks to test
> on that'd be great.
> 
> (Five years ago this wasn't a requirement. Things have changed - it now is.)
> 
> 
>> On Tue, Jul 29, 2014 at 10:48 PM, KO Myung-Hun <address@hidden> wrote:
>> 
>> Hi/2.
>> 
>> Rocky Bernstein wrote:
>>> Ok, then you can be responsible for OS/2 . That means that you will be
>>> expected to test, in advance, releases. Note that this is a change from
>> the
>>> laxness we've had in the past with respect to releases.
>> 
>> No problem.
>> 
>>> If you disappear and there is no one else to take responsibility, the
>>> ability to test OS/2 disappears, then OS/2 support in libcdio may
>> disappear
>>> as well.
>> 
>> Ooops... I feel the very much responsibility. ^^
>> 
>>>> What about testing an OS getopt first ?
>>> 
>>> We have 7 or so drivers that work with the supplied getopt.c and one that
>>> doesn't. And for that one driver we have maybe two people who use that.
>>> Even here, their use is probably infrequently for say Mplayer while the
>>> uses elsewhere span audio ripping, other media players, making boot CDs
>> and
>>> lots of other things I probably don't know about. So guess which way
>> causes
>>> the least disruption to the majority of users and developers?
>> 
>> Hmmm... I don't think this is a problem of quantity. But this is not a
>> important part.
>> 
>>> Couple that with the fact currently we don't have rigorous tests either
>>> getopt routine to make sure that works.  It's possible, though that in
>> one
>>> of the larger integration tests, we might catch a malfunctioning getopt,
>>> but I wouldn't want to count on that.
>>> 
>>> If you want to start writing a test suite for getopt whether it the
>>> provided one or the OS-supplied one, we can reconsider. But given things
>>> are currently the way they are, if the supplied getopt works, it's better
>>> to to use that, because assuming the getopt.c compiles as it was
>> intended,
>>> we *know* what the intended behavior is.
>> 
>> Ok. I agree. So I approach in other way.
>> 
>> Review, please...
>> 
>>> 
>>> 
>>>> On Mon, Jul 28, 2014 at 10:12 PM, KO Myung-Hun <address@hidden> wrote:
>>>> 
>>>> 
>>>> 
>>>> Rocky Bernstein wrote:
>>>>> Sorry for the delay. Things have been busy for me.
>>>> 
>>>> No problem. ^^
>>>> 
>>>>> It is interesting to hear back after the 5 or so years. About a month
>>>> and a
>>>>> half ago we were discussing dropping libcdio's OS/2 driver altogether.
>>>> See
>>>>> http://lists.gnu.org/archive/html/libcdio-devel/2014-06/msg00004.html
>>>>> 
>>>>> What motivated this was the desire to change the API to add
>>>> get_track_isrc
>>>>> and Robert Kausch mentioned he had no way to test OS/2. In that, we
>>>>> realized that basically no one *is* actively testing OS/2.
>>>>> 
>>>>> Aside from yourself and possibly Natalia, do you know anyone else that
>> is
>>>>> using this?
>>>> 
>>>> I don't know. But those who want to build MPlayer with audio cd
>>>> supports, would be using libcdio.
>>>> 
>>>>> Given the low activity and difficulty for finding developers and
>> testers,
>>>>> I'm inclined to have this maintained by you and Natalia in separately.
>>>> She
>>>>> already has a fork on github of libcdio-paranoia.
>>>>> 
>>>>> If OS/2 is to survive in libcdio, someone needs to commit to handle
>>>>> problems and API changes as such things arise. Are you willing to
>> commit
>>>> to
>>>>> this?
>>>> 
>>>> Of course. Five years ago, it's me to submit OS/2 patches as you know.
>> ^^
>>>> 
>>>>> Lastly, on the first patch. It has to do with deciding on whether the
>> use
>>>>> the libcdio-supplied getopt.c,and this is based purely on OS. OS/2 is
>> the
>>>>> only one to not used the supplied getopt.c
>>>>> 
>>>>> Rather than have a test by OS, I'd prefer a test to compile the
>> supplied
>>>>> getopt;  if that fails, then run a test to see if there is an OS
>> getopt.
>>>> 
>>>> Ok. What about testing an OS getopt first ? I think, it's better to
>>>> consider libcdio-getopt as a fallback.
>>>> 
>>>>> 
>>>>> 
>>>>> On Sat, Jul 26, 2014 at 11:50 PM, KO Myung-Hun <address@hidden>
>> wrote:
>>>>> 
>>>>>> Ping ?
>>>>>> 
>>>>>> KO Myung-Hun wrote:
>>>>>>> Hi/2, long tiem no see. ^^
>>>>>>> 
>>>>>>> I attach the patches to build libcdio and to enhance memory usage on
>>>>>> OS/2.
>>>>>>> 
>>>>>>> Review, please...
>>>> 
>>>> --
>>>> KO Myung-Hun
>>>> 
>>>> Using Mozilla SeaMonkey 2.7.2
>>>> Under OS/2 Warp 4 for Korean with FixPak #15
>>>> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>>>> 
>>>> Korean OS/2 User Community : http://www.ecomstation.co.kr
>> 
>> --
>> KO Myung-Hun
>> 
>> Using Mozilla SeaMonkey 2.7.2
>> Under OS/2 Warp 4 for Korean with FixPak #15
>> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>> 
>> Korean OS/2 User Community : http://www.ecomstation.co.kr
>> 
>>