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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> >>
