basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] BasiliskII compilation issues

[Robert M. <mr...@gm...>]

Hello Giulio,

On 6/11/12, Giulio Paci <giu...@gm...> wrote:
> On 10/06/2012 06:59, Robert Munafo wrote:
>> You might have noticed that mysignal is part of a small C program used
>> as a test during the autoconf process.  [...]
>
> Actually I did not notice it. How is it related mysignal being part of a
> test in configure and the error I am seeing?

They both use the same name. This means that they might have both been
put in by the same programmer. If there is a history of old versions
of BasiliskII source code, then we could find out when the mysignal
got added to autoconf, and perhaps that will give a clue as to who
added it and maybe the other mysignal was added at the same time.

>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
>> Wiese suggested?
>
> I am in the same situation as Andreas: if I
> 1) undefine HAVE_DEV_PTMX and
> 2) include signal.h
> I can complete the compilation. (Although I am not able to test the
> resulting binary at the moment, because on the virtual machine I set up
> for testing, the X server is not able to start).
>
> My goal is to have the compilation working without manual intervention
> on as many Debian supported architectures as possible, so: I can accept
> the point 2 above (as it is working in the general case), but I cannot
> accept the point 1 (because I do not understand what I am tweaking and
> why. Moreover the change is probably affecting other architectures).

I suggest that you add the change in the same way that one normally
makes such changes in Debian.

This is probably done with the config files. Note that "HAVE_DEV_PTMX"
appears in:

  Unix/config.h.in
  Unix/configure
  Unix/configure.ac

I do not know how these files work, but I do remember that one or more
of them is created based on one of the others, and I'm pretty sure
this happens in the "autogen.sh" or "configure" step of the build
process.

Whichever one is the "original" configure file, needs to be edited so
that it tests for Debian and disables the define of HAVE_DEV_PTMX if
the Debian test is true.

Once you determine the best way to change the right config file, then
report the details back to this list. There are people on this list
who can update the source code server to reflect the bug fix, once
they are told what needs to be changed.

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

On 10/06/2012 06:59, Robert Munafo wrote:
> You might have noticed that mysignal is part of a small C program used
> as a test during the autoconf process. I do a MacOSX build, so I find
> it in src/MacOSX/configure.in
> 
> The test installs a signal hangler, then raises the same signal twice,
> then sees if the signal handler actually got triggered twice.

Actually I did not notice it. How is it related mysignal being part of a
test in configure and the error I am seeing?

> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
> Wiese suggested?

I am in the same situation as Andreas: if I
1) undefine HAVE_DEV_PTMX and
2) include signal.h
I can complete the compilation. (Although I am not able to test the
resulting binary at the moment, because on the virtual machine I set up
for testing, the X server is not able to start).

My goal is to have the compilation working without manual intervention
on as many Debian supported architectures as possible, so: I can accept
the point 2 above (as it is working in the general case), but I cannot
accept the point 1 (because I do not understand what I am tweaking and
why. Moreover the change is probably affecting other architectures).

Bests,
	Giulio.

Re: [B2-devel] BasiliskII compilation issues

[Robert M. <mr...@gm...>]

You might have noticed that mysignal is part of a small C program used
as a test during the autoconf process. I do a MacOSX build, so I find
it in src/MacOSX/configure.in

The test installs a signal hangler, then raises the same signal twice,
then sees if the signal handler actually got triggered twice.

What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
Wiese suggested?

Relevant code from configure.in:

dnl Check if sigaction handlers need to be reinstalled
AC_CACHE_CHECK([whether sigaction handlers need to be reinstalled],
  ac_cv_sigaction_need_reinstall, [
  AC_LANG_SAVE
  AC_LANG_CPLUSPLUS
  AC_TRY_RUN([
    #include <stdlib.h>
    #ifdef HAVE_UNISTD_H
    #include <unistd.h>
    #endif
    #include <signal.h>
    static int handled_signal = 0;
    RETSIGTYPE sigusr1_handler(int) { handled_signal++; }
    typedef RETSIGTYPE (*signal_handler)(int);
    static signal_handler mysignal(int sig, signal_handler handler) {
      struct sigaction old_sa;
      struct sigaction new_sa;
      new_sa.sa_handler = handler;
      return ((sigaction(sig,&new_sa,&old_sa) < 0) ? SIG_IGN :
old_sa.sa_handler);
    }
    int main(void) { /* returns 0 if signals need not to be reinstalled */
      mysignal(SIGUSR1, sigusr1_handler); raise(SIGUSR1); raise(SIGUSR1);
      exit(handled_signal == 2);
    }
  ], ac_cv_sigaction_need_reinstall=yes, ac_cv_sigaction_need_reinstall=no,
  dnl When cross-compiling, do not assume anything.
  ac_cv_sigaction_need_reinstall="guessing yes"
  )
  AC_LANG_RESTORE
  ]
)
AC_TRANSLATE_DEFINE(SIGACTION_NEED_REINSTALL, "$ac_cv_sigaction_need_reinstall",
  [Define if your system requires sigactions to be reinstalled.])


-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

[B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

Hi all!
	About a week ago Basilisk II has been accepted into Debian unstable.
Unfortunately the first upload is not compiling properly in most of the
supported architectures, as it is described by this compilation report:
https://buildd.debian.org/status/package.php?p=basilisk2

For ia64, mips, mipsel, sparc and powerpc it was my fault and I already
fixed that.

Currently I am trying to fix the kfreebsd build, but I am in the
situation described here:
http://permalink.gmane.org/gmane.os.netbsd.devel.pkgsrc.bugs/434

Does anyone have a solution/suggestion for this problem?
Suggestions for the other failing architectures are also welcome, but I
have no such installation at the moment, so I cannot test them easily.

Bests,
	Giulio

[B2-devel] Leggo my Eggo! (The CD-ROM eject fix)

[Robert M. <mr...@gm...>]

Hi Alexei,

Thank you for checking my work. I am glad to hear that the change can
go in sys_darwin.cpp because that makes more sense to me too.

I was starting to think that SysMediaArrived() was Darwin-only. I
searched all the code to find other references to it, and only found
the one in sys_windows.cpp (it seems to be used by video_sdl.cpp in
WIN32, but why?).

But this would mean that SysMediaArrived() should be in
sys_darwin.cpp, not sys_unix.cpp, right? (I am not suggesting that we
change it, because I realize there is a lot of lost knowledge about
the BasiliskII design... but this is why I made a wild guess that
perhaps this bug might have also affected Linux.)

- Robert

On 2012-04-21, Alexei Svitkine <ale...@gm...> wrote:
> Thanks for your investigation!
>
> I've looked at the code and decided to go with the solution of not
> even starting the media_thread when "nocdrom" is set, since
> the media_thread is only used to scan for CDs in the current
> code.
>
> This way, the emulator is won't be doing useless work when that
> pref is set. As for your concern of whether other Unixes are affected
> by the bug, it actually looks like the only caller of SysMediaArrived()
> in sys_unix.cpp is the code in sys_darwin.cpp, so the issue only
> affected the Darwin version.
>
> I've committed the change to CVS. Thanks again!
>
> -Alexei

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] Leggo my Eggo! (The CD-ROM eject fix)

[Alexei S. <ale...@gm...>]

Thanks for your investigation!

I've looked at the code and decided to go with the solution of not
even starting the media_thread when "nocdrom" is set, since
the media_thread is only used to scan for CDs in the current
code.

This way, the emulator is won't be doing useless work when that
pref is set. As for your concern of whether other Unixes are affected
by the bug, it actually looks like the only caller of SysMediaArrived()
in sys_unix.cpp is the code in sys_darwin.cpp, so the issue only
affected the Darwin version.

I've committed the change to CVS. Thanks again!

-Alexei

On Sat, Apr 21, 2012 at 2:23 AM, Robert Munafo <mr...@gm...> wrote:
> This affects both BasiliskII and SheepShaver, on Mac OS X host
> systems, when the "nocdrom" setting is set to "true".
>
> I keep lots of old files archived on CD-ROMs, and I often use these
> CD-ROMs while BasiliskII or SheepShaver is running. The CD-ROMs are
> for MacOS X, they wouldn't work in the emulator even if I tried, so I
> have "nocdrom true" in both my .basilisk_ii_prefs and
> .sheepshaver_prefs files.
>
> There has been a bug for many years that causes this setting to only
> partly work. "nocdrom true" prevents the emulator from emulating the
> CD-ROM, but if you insert a disc after launching the emulator, it
> still grabs onto the CD-ROM as if it were being used, and it never
> lets go. If you want to eject the CD-ROM, the Finder removes the icon
> from the desktop but it doesn't eject. Disk Utility tells you it can't
> be unmounted. You have to quit BasiliskII or SheepShaver before
> ejecting it.
>
> A little searching through the source code turns up the routine
> "SysMediaArrived", which is defined in sys_unix.cpp and invoked from
> sys_darwin.cpp. As you can see, it does perform an appropriate test:
>
>  if (type == MEDIA_CD && !PrefsFindBool("nocdrom"))
>
> but this test only affects whether or not it does the following
> "PrefsReplaceString("cdrom", path);" step.
>
> The rest of the actions, including in particular the call to
> "cdrom_open(fh, path)", are performed regardless of the "nocdrom"
> setting.
>
> This makes it open the CD-ROM device (such as "/dev/disk1" on one of
> the systems I tested) which is why the disc cannot be ejected.
> Unfortunately, there is no way to get it to close the device later.
> Because CD-ROM is turned off, the disc never appears inside the
> emulated MacOS, and so there is no way to ask the emulated Mac to
> eject it.
>
> The fix I decided to try is relatively simple. If "nocdrom" is true,
> the entire SysMediaArrived routine is superfluous. So I added a test
> at the very beginning of SysMediaArrived that exits:
>
>    if ((type == MEDIA_CD) && PrefsFindBool("nocdrom")) {
>        // Do nothing
>        return;
>    }
>
> With this change I am able to insert and eject as many CD-ROMs as I
> want while SheepShaver is running, without having to make SheepShaver
> quit.
>
> There are probably other ways to fix this. SysMediaArrived is called
> from media_arrived in sys_darwin.cpp, and media_arrived is installed
> by a call to IOServiceAddMatchingNotification. I suspect that one
> could put a test of PrefsFindBool("nocdrom") somewhere in here to
> prevent installing the notification handler in the first place. But I
> don't know what else that might affect (there might be other media
> that can arrive apart from CDROMs).
>
> Also, the presence of the incorrect code in sys_unix.cpp makes it look
> like this bug might also affect Linux users.
>
> Comments welcome...
>
> --
>  Robert Munafo  --  mrob.com
>  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
> mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Leggo my Eggo! (The CD-ROM eject fix)

[Robert M. <mr...@gm...>]

This affects both BasiliskII and SheepShaver, on Mac OS X host
systems, when the "nocdrom" setting is set to "true".

I keep lots of old files archived on CD-ROMs, and I often use these
CD-ROMs while BasiliskII or SheepShaver is running. The CD-ROMs are
for MacOS X, they wouldn't work in the emulator even if I tried, so I
have "nocdrom true" in both my .basilisk_ii_prefs and
.sheepshaver_prefs files.

There has been a bug for many years that causes this setting to only
partly work. "nocdrom true" prevents the emulator from emulating the
CD-ROM, but if you insert a disc after launching the emulator, it
still grabs onto the CD-ROM as if it were being used, and it never
lets go. If you want to eject the CD-ROM, the Finder removes the icon
from the desktop but it doesn't eject. Disk Utility tells you it can't
be unmounted. You have to quit BasiliskII or SheepShaver before
ejecting it.

A little searching through the source code turns up the routine
"SysMediaArrived", which is defined in sys_unix.cpp and invoked from
sys_darwin.cpp. As you can see, it does perform an appropriate test:

  if (type == MEDIA_CD && !PrefsFindBool("nocdrom"))

but this test only affects whether or not it does the following
"PrefsReplaceString("cdrom", path);" step.

The rest of the actions, including in particular the call to
"cdrom_open(fh, path)", are performed regardless of the "nocdrom"
setting.

This makes it open the CD-ROM device (such as "/dev/disk1" on one of
the systems I tested) which is why the disc cannot be ejected.
Unfortunately, there is no way to get it to close the device later.
Because CD-ROM is turned off, the disc never appears inside the
emulated MacOS, and so there is no way to ask the emulated Mac to
eject it.

The fix I decided to try is relatively simple. If "nocdrom" is true,
the entire SysMediaArrived routine is superfluous. So I added a test
at the very beginning of SysMediaArrived that exits:

    if ((type == MEDIA_CD) && PrefsFindBool("nocdrom")) {
        // Do nothing
        return;
    }

With this change I am able to insert and eject as many CD-ROMs as I
want while SheepShaver is running, without having to make SheepShaver
quit.

There are probably other ways to fix this. SysMediaArrived is called
from media_arrived in sys_darwin.cpp, and media_arrived is installed
by a call to IOServiceAddMatchingNotification. I suspect that one
could put a test of PrefsFindBool("nocdrom") somewhere in here to
prevent installing the notification handler in the first place. But I
don't know what else that might affect (there might be other media
that can arrive apart from CDROMs).

Also, the presence of the incorrect code in sys_unix.cpp makes it look
like this bug might also affect Linux users.

Comments welcome...

-- 
  Robert Munafo  --  mrob.com
  Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com

Re: [B2-devel] Patches and contributions

[Alexei S. <ale...@gm...>]

Thanks. I've upstreamed 2003.

On Sun, Apr 1, 2012 at 12:06 PM, Giulio Paci <giu...@gm...> wrote:
> Il 01/04/2012 17:16, Alexei Svitkine ha scritto:
>> Thanks for the patches!
>>
>> I've upstreamed 1001, 1002, 2001 and 2002.
>
> This is nice!
>
>> I need to understand the purpose of 1003 and 2003 before upstreaming.
>
> I do not know the purpose of 1003 and I am not using it at the moment
> (it was included in an old version of the package, but I had no problem
> without it).
>
> The purpose of 2003 is making src/Unix/autogen.sh working on my system.
> Without the line I added I get this
>
> warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS
>
> and several other an the generated configure script is unusable.
> I did not investigate the real problem, so this patch can be considered
> a quick and dirty workaround.
>
> Bests,
>        Giulio.
>
>> On Sun, Apr 1, 2012 at 6:19 AM, Giulio Paci <giu...@gm...> wrote:
>>> Hi all,
>>>        during the Debian package development of Basilisk II I had to adapt/fix
>>> the code in the CVS tree.
>>> The changes are maintained in a set of mostly independent patches
>>> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=tree;f=debian/patches;h=cf250996bf8ab4bcdc64c49a6b15a489b0b3e48a;hb=HEAD),
>>> managed with quilt (the series files lists which of the patches and in
>>> what order, have to be applied).
>>>
>>> Are you interested in including any of those changes upstream? What is
>>> your policy about contributions?
>>>
>>> Bests,
>>>        Giulio.
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Patches and contributions

[Giulio P. <giu...@gm...>]

Il 01/04/2012 17:16, Alexei Svitkine ha scritto:
> Thanks for the patches!
> 
> I've upstreamed 1001, 1002, 2001 and 2002.

This is nice!

> I need to understand the purpose of 1003 and 2003 before upstreaming.

I do not know the purpose of 1003 and I am not using it at the moment
(it was included in an old version of the package, but I had no problem
without it).

The purpose of 2003 is making src/Unix/autogen.sh working on my system.
Without the line I added I get this

warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS

and several other an the generated configure script is unusable.
I did not investigate the real problem, so this patch can be considered
a quick and dirty workaround.

Bests,
	Giulio.

> On Sun, Apr 1, 2012 at 6:19 AM, Giulio Paci <giu...@gm...> wrote:
>> Hi all,
>>        during the Debian package development of Basilisk II I had to adapt/fix
>> the code in the CVS tree.
>> The changes are maintained in a set of mostly independent patches
>> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=tree;f=debian/patches;h=cf250996bf8ab4bcdc64c49a6b15a489b0b3e48a;hb=HEAD),
>> managed with quilt (the series files lists which of the patches and in
>> what order, have to be applied).
>>
>> Are you interested in including any of those changes upstream? What is
>> your policy about contributions?
>>
>> Bests,
>>        Giulio.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Patches and contributions

[Alexei S. <ale...@gm...>]

Thanks for the patches!

I've upstreamed 1001, 1002, 2001 and 2002.

I need to understand the purpose of 1003 and 2003 before upstreaming.

-Alexei

On Sun, Apr 1, 2012 at 6:19 AM, Giulio Paci <giu...@gm...> wrote:
> Hi all,
>        during the Debian package development of Basilisk II I had to adapt/fix
> the code in the CVS tree.
> The changes are maintained in a set of mostly independent patches
> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=tree;f=debian/patches;h=cf250996bf8ab4bcdc64c49a6b15a489b0b3e48a;hb=HEAD),
> managed with quilt (the series files lists which of the patches and in
> what order, have to be applied).
>
> Are you interested in including any of those changes upstream? What is
> your policy about contributions?
>
> Bests,
>        Giulio.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Basilisk II releases and copyright questions

[Alexei S. <ale...@gm...>]

Thanks. I missed the COPYRIGHT file changes - looking at the qemu
slirp upstream commit that I referenced, they did update that file
too. So I've made that same change in our tree as well.

-Alexei

On Sun, Apr 1, 2012 at 6:09 AM, Giulio Paci <giu...@gm...> wrote:
> Il 30/03/2012 11:03, Giulio Paci ha scritto:
>> On 30/03/2012 03:48, Alexei Svitkine wrote:
>>> I've fixed most of the license problems.
>>>
>>> The slirp files come from QEMU and have since been re-licensed there
>>> to have the 3-clause license, so I've updated the Basilisk copies in
>>> the same way.
>>>
>>> The uae_cpu files come from the UAE project -
>>> http://www.amigaemulator.org/ - which are all GPLv2 licensed, so I've
>>> added license info to them.
>>>
>>> Can you re-run the tool and let me know if there are any remaining problems?
>>
>> Thank you very much for your very quick fixes! :-)
>> I will let you know as soon as I have time to do that, but I do not
>> expect any other "copyright" issues.
>
> I found some time to update the packaging files and re-check copyright
> of the files. The only remaining "problematic" file is the slirp
> upstream src/slirp/COPYRIGHT files which reports a three clause BSD
> license, but the wrong ones (i.e., the GPL incompatible clause is still
> there).
> >From this email
> http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg01765.html,
> whose content you referenced in the changelog, the new license is clear,
> so, although confusing, I see no blocking issue there.
>
> Thank you again.
> Cheers,
>        Giulio.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

[B2-devel] Patches and contributions

[Giulio P. <giu...@gm...>]

Hi all,
	during the Debian package development of Basilisk II I had to adapt/fix
the code in the CVS tree.
The changes are maintained in a set of mostly independent patches
(http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=tree;f=debian/patches;h=cf250996bf8ab4bcdc64c49a6b15a489b0b3e48a;hb=HEAD),
managed with quilt (the series files lists which of the patches and in
what order, have to be applied).

Are you interested in including any of those changes upstream? What is
your policy about contributions?

Bests,
	Giulio.

Re: [B2-devel] Basilisk II releases and copyright questions

[Giulio P. <giu...@gm...>]

Il 30/03/2012 11:03, Giulio Paci ha scritto:
> On 30/03/2012 03:48, Alexei Svitkine wrote:
>> I've fixed most of the license problems.
>>
>> The slirp files come from QEMU and have since been re-licensed there
>> to have the 3-clause license, so I've updated the Basilisk copies in
>> the same way.
>>
>> The uae_cpu files come from the UAE project -
>> http://www.amigaemulator.org/ - which are all GPLv2 licensed, so I've
>> added license info to them.
>>
>> Can you re-run the tool and let me know if there are any remaining problems?
> 
> Thank you very much for your very quick fixes! :-)
> I will let you know as soon as I have time to do that, but I do not
> expect any other "copyright" issues.

I found some time to update the packaging files and re-check copyright
of the files. The only remaining "problematic" file is the slirp
upstream src/slirp/COPYRIGHT files which reports a three clause BSD
license, but the wrong ones (i.e., the GPL incompatible clause is still
there).
>From this email
http://lists.gnu.org/archive/html/qemu-devel/2009-01/msg01765.html,
whose content you referenced in the changelog, the new license is clear,
so, although confusing, I see no blocking issue there.

Thank you again.
Cheers,
	Giulio.

Re: [B2-devel] Basilisk II releases and copyright questions

[Giulio P. <giu...@gm...>]

On 30/03/2012 03:48, Alexei Svitkine wrote:
> I've fixed most of the license problems.
> 
> The slirp files come from QEMU and have since been re-licensed there
> to have the 3-clause license, so I've updated the Basilisk copies in
> the same way.
> 
> The uae_cpu files come from the UAE project -
> http://www.amigaemulator.org/ - which are all GPLv2 licensed, so I've
> added license info to them.
> 
> Can you re-run the tool and let me know if there are any remaining problems?

Thank you very much for your very quick fixes! :-)
I will let you know as soon as I have time to do that, but I do not
expect any other "copyright" issues.

BTW: the copyright file is a manually revised version of the
automatically generated copyright_hints file
(http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=blob_plain;f=debian/copyright_hints;hb=HEAD)
and I do not see other issues there.

Cheers,
	Giulio.


> On Thu, Mar 29, 2012 at 5:33 PM, Giulio Paci <giu...@gm...> wrote:
>> Il 29/03/2012 23:13, Ronald P. Regensburg ha scritto:
>>>
>>> Op 29 mrt 2012, om 22:17, schreef Alexei Svitkine:
>>>
>>>> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
>>>>
>>>>> 1) During the package development we noticed that much time has passed
>>>>> since latest official release. Is a new official release planned?
>>>>> Official releases are not a requirement, but helps keep track of where a
>>>>> package come from.
>>>>
>>>> Unfortunately, the project does not have enough resources to make
>>>> official releases. So we have either CVS tip of tree, or unofficial
>>>> releases that are build / posted at emaculation.com from arbitrary CVS
>>>> revisions.
>>>
>>> As far as I am aware, there have not been any "official" releases of both BasiliskII and SheepShaver since 2006.
>>>
>>> In the OSX builds I post at emaculation.com, I manually edit the Info.plist file to add the cvs date to the version number to discern it from previous builds. SheepShaver has version 2.3 since May 2006. My 11 February 2012 build, posted on emaculation.com forum, identifies itself as 2.3 (2012-02-11) in Get Info String and as 2.3.20120211 in Bundle versions string, short.
>>
>>
>>> Despite that, this standstill in version numbering confuses people. A recent build is very different from the 2006 release version. I wonder if it would not be possible to draw a line from time to time, for instance after a meaningful improvement in the source code, and make the source be a next version.
>>
>> At least we are using the same strategies for the Debian Basilisk II
>> package too, so that further confusion is avoided. :-)
>>
>> Cheers,
>>        Giulio.
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Basilisk II releases and copyright questions

[Alexei S. <ale...@gm...>]

I've fixed most of the license problems.

The slirp files come from QEMU and have since been re-licensed there
to have the 3-clause license, so I've updated the Basilisk copies in
the same way.

The uae_cpu files come from the UAE project -
http://www.amigaemulator.org/ - which are all GPLv2 licensed, so I've
added license info to them.

Can you re-run the tool and let me know if there are any remaining problems?

Cheers,

-Alexei

On Thu, Mar 29, 2012 at 5:33 PM, Giulio Paci <giu...@gm...> wrote:
> Il 29/03/2012 23:13, Ronald P. Regensburg ha scritto:
>>
>> Op 29 mrt 2012, om 22:17, schreef Alexei Svitkine:
>>
>>> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
>>>
>>>> 1) During the package development we noticed that much time has passed
>>>> since latest official release. Is a new official release planned?
>>>> Official releases are not a requirement, but helps keep track of where a
>>>> package come from.
>>>
>>> Unfortunately, the project does not have enough resources to make
>>> official releases. So we have either CVS tip of tree, or unofficial
>>> releases that are build / posted at emaculation.com from arbitrary CVS
>>> revisions.
>>
>> As far as I am aware, there have not been any "official" releases of both BasiliskII and SheepShaver since 2006.
>>
>> In the OSX builds I post at emaculation.com, I manually edit the Info.plist file to add the cvs date to the version number to discern it from previous builds. SheepShaver has version 2.3 since May 2006. My 11 February 2012 build, posted on emaculation.com forum, identifies itself as 2.3 (2012-02-11) in Get Info String and as 2.3.20120211 in Bundle versions string, short.
>
>
>> Despite that, this standstill in version numbering confuses people. A recent build is very different from the 2006 release version. I wonder if it would not be possible to draw a line from time to time, for instance after a meaningful improvement in the source code, and make the source be a next version.
>
> At least we are using the same strategies for the Debian Basilisk II
> package too, so that further confusion is avoided. :-)
>
> Cheers,
>        Giulio.
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] Basilisk II releases and copyright questions

[Giulio P. <giu...@gm...>]

Il 29/03/2012 23:13, Ronald P. Regensburg ha scritto:
> 
> Op 29 mrt 2012, om 22:17, schreef Alexei Svitkine:
> 
>> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
>>
>>> 1) During the package development we noticed that much time has passed
>>> since latest official release. Is a new official release planned?
>>> Official releases are not a requirement, but helps keep track of where a
>>> package come from.
>>
>> Unfortunately, the project does not have enough resources to make
>> official releases. So we have either CVS tip of tree, or unofficial
>> releases that are build / posted at emaculation.com from arbitrary CVS
>> revisions.
> 
> As far as I am aware, there have not been any "official" releases of both BasiliskII and SheepShaver since 2006.
> 
> In the OSX builds I post at emaculation.com, I manually edit the Info.plist file to add the cvs date to the version number to discern it from previous builds. SheepShaver has version 2.3 since May 2006. My 11 February 2012 build, posted on emaculation.com forum, identifies itself as 2.3 (2012-02-11) in Get Info String and as 2.3.20120211 in Bundle versions string, short.


> Despite that, this standstill in version numbering confuses people. A recent build is very different from the 2006 release version. I wonder if it would not be possible to draw a line from time to time, for instance after a meaningful improvement in the source code, and make the source be a next version.

At least we are using the same strategies for the Debian Basilisk II
package too, so that further confusion is avoided. :-)

Cheers,
	Giulio.

Re: [B2-devel] Basilisk II releases and copyright questions

[Giulio P. <giu...@gm...>]

Hi Alexei!

Il 29/03/2012 22:18, Alexei Svitkine ha scritto:
> On Thu, Mar 29, 2012 at 4:17 PM, Alexei Svitkine
> <ale...@gm...> wrote:
>> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
>>> Hi to all!
>>>        Recently I started collaborating to package Basilisk II for Debian and
>>> now we have a working package. (Package development has been carried out
>>> in a git repository
>>> http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=summary)
>>>
>>> 1) During the package development we noticed that much time has passed
>>> since latest official release. Is a new official release planned?
>>> Official releases are not a requirement, but helps keep track of where a
>>> package come from.
>>
>> Unfortunately, the project does not have enough resources to make
>> official releases. So we have either CVS tip of tree, or unofficial
>> releases that are build / posted at emaculation.com from arbitrary CVS
>> revisions.

So there is no place where I can find sources released, right? The
current package is built on a snapshot of the CVS tree. Is there any way
to select revision that are more stable?

>>> 2) Every Debian package ships a copyright file
>>> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=blob;f=debian/copyright;h=f2a03b994a88348ebb430e50abc96b31fb4dbe0b;hb=HEAD)
>>> that reports the copyright of all the files in the package.
>>> Unfortunately we noticed that software with incompatible licenses (BSD
>>> (4 clause) and GPL-2+) or with unknown licenses are mixed together. Is
>>> there anything that can be done to fix this?
>>
>> Hopefully, we can resolve this. I'm not sure I completely understand
>> the output of this tool, so let me know if the following is correct,
>> in terms of what the tool is reporting:

You understood exactly the copyright file content.

>> 1. A bunch of the code under slip/ is using BSD 4-clause, which is not
>> compatible with GPL.
> oops typo, that should read "a bunch of code under *slirp/"

Right. After manual inspection I have seen no other BSD 4-clause file. I
also checked the files in slirp/ that have a modified BSD 4-clause
license: they have 3 clauses, but the incompatible one is still there.

>> 2. A bunch of files don't have licenses - hence the tool prints
>> "License: UNKNOWN", "FIXME".
>>
>> Is my understanding of that output correct?
>>
>> For 1, perhaps we can find a newer version of the slirp code that has
>> a 3-clause BSD license or something else compatible with the GPL. I'll
>> have to look. In the mean time, I think there is an option to
>> ./configure Basilisk to not include support for SLIRP networking,
>> which should result in that code not being used.

I would prefer the first solution, but the second one is also valid.
I do not see the option to remove slirp support in the configure script,
do you have any suggestion?

>> For 2, we'll have to track down where those files come from (I think
>> also from other projects) - most likely they should be GPL licensed.
>> I'll investigate.

Thank you very much! I really want to see Basilisk II in Debian... :-)

Cheers,
	Giulio

Re: [B2-devel] Basilisk II releases and copyright questions

[Ronald P. R. <ron...@xs...>]

Op 29 mrt 2012, om 22:17, schreef Alexei Svitkine:

> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
> 
>> 1) During the package development we noticed that much time has passed
>> since latest official release. Is a new official release planned?
>> Official releases are not a requirement, but helps keep track of where a
>> package come from.
> 
> Unfortunately, the project does not have enough resources to make
> official releases. So we have either CVS tip of tree, or unofficial
> releases that are build / posted at emaculation.com from arbitrary CVS
> revisions.

As far as I am aware, there have not been any "official" releases of both BasiliskII and SheepShaver since 2006.

In the OSX builds I post at emaculation.com, I manually edit the Info.plist file to add the cvs date to the version number to discern it from previous builds. SheepShaver has version 2.3 since May 2006. My 11 February 2012 build, posted on emaculation.com forum, identifies itself as 2.3 (2012-02-11) in Get Info String and as 2.3.20120211 in Bundle versions string, short.

Despite that, this standstill in version numbering confuses people. A recent build is very different from the 2006 release version. I wonder if it would not be possible to draw a line from time to time, for instance after a meaningful improvement in the source code, and make the source be a next version.

Best Regards,

Ronald.

Re: [B2-devel] Basilisk II releases and copyright questions

[Alexei S. <ale...@gm...>]

On Thu, Mar 29, 2012 at 4:17 PM, Alexei Svitkine
<ale...@gm...> wrote:
> Hi,
>
> On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
>> Hi to all!
>>        Recently I started collaborating to package Basilisk II for Debian and
>> now we have a working package. (Package development has been carried out
>> in a git repository
>> http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=summary)
>>
>> 1) During the package development we noticed that much time has passed
>> since latest official release. Is a new official release planned?
>> Official releases are not a requirement, but helps keep track of where a
>> package come from.
>
> Unfortunately, the project does not have enough resources to make
> official releases. So we have either CVS tip of tree, or unofficial
> releases that are build / posted at emaculation.com from arbitrary CVS
> revisions.
>
>>
>> 2) Every Debian package ships a copyright file
>> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=blob;f=debian/copyright;h=f2a03b994a88348ebb430e50abc96b31fb4dbe0b;hb=HEAD)
>> that reports the copyright of all the files in the package.
>> Unfortunately we noticed that software with incompatible licenses (BSD
>> (4 clause) and GPL-2+) or with unknown licenses are mixed together. Is
>> there anything that can be done to fix this?
>
> Hopefully, we can resolve this. I'm not sure I completely understand
> the output of this tool, so let me know if the following is correct,
> in terms of what the tool is reporting:
>
> 1. A bunch of the code under slip/ is using BSD 4-clause, which is not
> compatible with GPL.

oops typo, that should read "a bunch of code under *slirp/"

> 2. A bunch of files don't have licenses - hence the tool prints
> "License: UNKNOWN", "FIXME".
>
> Is my understanding of that output correct?
>
> For 1, perhaps we can find a newer version of the slirp code that has
> a 3-clause BSD license or something else compatible with the GPL. I'll
> have to look. In the mean time, I think there is an option to
> ./configure Basilisk to not include support for SLIRP networking,
> which should result in that code not being used.
>
> For 2, we'll have to track down where those files come from (I think
> also from other projects) - most likely they should be GPL licensed.
> I'll investigate.
>
> Cheers,
>
> -Alexei

Re: [B2-devel] Basilisk II releases and copyright questions

[Alexei S. <ale...@gm...>]

Hi,

On Thu, Mar 29, 2012 at 1:10 PM, Giulio Paci <giu...@gm...> wrote:
> Hi to all!
>        Recently I started collaborating to package Basilisk II for Debian and
> now we have a working package. (Package development has been carried out
> in a git repository
> http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=summary)
>
> 1) During the package development we noticed that much time has passed
> since latest official release. Is a new official release planned?
> Official releases are not a requirement, but helps keep track of where a
> package come from.

Unfortunately, the project does not have enough resources to make
official releases. So we have either CVS tip of tree, or unofficial
releases that are build / posted at emaculation.com from arbitrary CVS
revisions.

>
> 2) Every Debian package ships a copyright file
> (http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=blob;f=debian/copyright;h=f2a03b994a88348ebb430e50abc96b31fb4dbe0b;hb=HEAD)
> that reports the copyright of all the files in the package.
> Unfortunately we noticed that software with incompatible licenses (BSD
> (4 clause) and GPL-2+) or with unknown licenses are mixed together. Is
> there anything that can be done to fix this?

Hopefully, we can resolve this. I'm not sure I completely understand
the output of this tool, so let me know if the following is correct,
in terms of what the tool is reporting:

1. A bunch of the code under slip/ is using BSD 4-clause, which is not
compatible with GPL.
2. A bunch of files don't have licenses - hence the tool prints
"License: UNKNOWN", "FIXME".

Is my understanding of that output correct?

For 1, perhaps we can find a newer version of the slirp code that has
a 3-clause BSD license or something else compatible with the GPL. I'll
have to look. In the mean time, I think there is an option to
./configure Basilisk to not include support for SLIRP networking,
which should result in that code not being used.

For 2, we'll have to track down where those files come from (I think
also from other projects) - most likely they should be GPL licensed.
I'll investigate.

Cheers,

-Alexei

[B2-devel] Basilisk II releases and copyright questions

[Giulio P. <giu...@gm...>]

Hi to all!
	Recently I started collaborating to package Basilisk II for Debian and
now we have a working package. (Package development has been carried out
in a git repository
http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=summary)

1) During the package development we noticed that much time has passed
since latest official release. Is a new official release planned?
Official releases are not a requirement, but helps keep track of where a
package come from.

2) Every Debian package ships a copyright file
(http://anonscm.debian.org/gitweb/?p=collab-maint/basilisk2.git;a=blob;f=debian/copyright;h=f2a03b994a88348ebb430e50abc96b31fb4dbe0b;hb=HEAD)
that reports the copyright of all the files in the package.
Unfortunately we noticed that software with incompatible licenses (BSD
(4 clause) and GPL-2+) or with unknown licenses are mixed together. Is
there anything that can be done to fix this?

Bests,
	Giulio.

Re: [B2-devel] Announcing SheepShaver Xcode build

[Ronald P. R. <ron...@xs...>]

Hi Alexei,

I tried (release configuration), but build failed with 44 errors and 142 warnings.

See posts by Cat_7 and me in Emaculation forum.

<http://www.emaculation.com/forum/viewtopic.php?p=41690#p41690>

Best Regards,

Ronald P. Regensburg.


Op 5 jan 2012, om 03:42, schreef Alexei Svitkine:

> I've committed an Xcode project to the SheepShaver repository that
> makes it easier to build SheepShaver as a Universal Binary (with 3
> architectures: i386, x86_64 and ppc).
> 
> This is an optional new build system that does not affect the existing
> autogen/configure based build system, which is still fully supported.
> The Xcode project will build SheepShaver with configuration
> "--enable-sdl-audio --enable-sdl-video --disable-vosf".
> 
> The Xcode project lives in
> SheepShaver/src/MacOSX/SheepShaver.xcodeproj and has been tested to
> work on Snow Leopard 64-bit with Xcode 3.2.6 and the 10.4 SDK
> installed.
> 
> To use it, you need the following:
> 
> 1. A side-by-side checkout of SheepShaver and BasiliskII CVS
> repositories (this is normal).
> 2. Having run 'make links' from SheepShaver/ root.
> 3. SDL installed as a framework in /Library/Frameworks/SDL.framework.
> 4. You do not need to run autogen.sh / configure to use the Xcode
> project. If you've done so already, you should remove or temporary
> move/rename src/Unix/config.h, as the presence of that file currently
> conflicts with the Xcode build and will cause errors in Xcode.
> 
> With the above all set, you should be able to launch the Xcode project
> and build SheepShaver, resulting in a UB build containing SDL as a
> private framework in the bundle. The result will be located in either
> SheepShaver/src/MacOSX/build/Debug or
> SheepShaver/src/MacOSX/build/Release directories, depending if you do
> a Debug or Release build.
> 
> Let me know if it works for you!
> 
> Cheers,
> 
> -Alexei
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> 

[B2-devel] Announcing SheepShaver Xcode build

[Alexei S. <ale...@gm...>]

I've committed an Xcode project to the SheepShaver repository that
makes it easier to build SheepShaver as a Universal Binary (with 3
architectures: i386, x86_64 and ppc).

This is an optional new build system that does not affect the existing
autogen/configure based build system, which is still fully supported.
The Xcode project will build SheepShaver with configuration
"--enable-sdl-audio --enable-sdl-video --disable-vosf".

The Xcode project lives in
SheepShaver/src/MacOSX/SheepShaver.xcodeproj and has been tested to
work on Snow Leopard 64-bit with Xcode 3.2.6 and the 10.4 SDK
installed.

To use it, you need the following:

1. A side-by-side checkout of SheepShaver and BasiliskII CVS
repositories (this is normal).
2. Having run 'make links' from SheepShaver/ root.
3. SDL installed as a framework in /Library/Frameworks/SDL.framework.
4. You do not need to run autogen.sh / configure to use the Xcode
project. If you've done so already, you should remove or temporary
move/rename src/Unix/config.h, as the presence of that file currently
conflicts with the Xcode build and will cause errors in Xcode.

With the above all set, you should be able to launch the Xcode project
and build SheepShaver, resulting in a UB build containing SDL as a
private framework in the bundle. The result will be located in either
SheepShaver/src/MacOSX/build/Debug or
SheepShaver/src/MacOSX/build/Release directories, depending if you do
a Debug or Release build.

Let me know if it works for you!

Cheers,

-Alexei

Re: [B2-devel] [sheepshaver] build errors with current cvs (2012-01-01)

[Alexei S. <ale...@gm...>]

Thanks. I've committed fixes for both issues.

-Alexei

[B2-devel] [sheepshaver] build errors with current cvs (2012-01-01)

[Douglas M. <dou...@gm...>]

Here are build errors:

g++ -I../include -I. -I../slirp -DHAVE_CONFIG_H -D_REENTRANT
-DDATADIR=\"/usr/share/SheepShaver\" -g -O2  -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/powerpc-linux-gnu/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnu/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/cairo   -c main_unix.cpp -o
obj/main_unix.o
main_unix.cpp: In function ‘void get_system_info()’:
main_unix.cpp:530:11: error: ‘str’ was not declared in this scope
main_unix.cpp: In function ‘bool init_sdl()’:
main_unix.cpp:690:24: error: ‘SDL_Init’ was not declared in this scope
main_unix.cpp:692:64: error: ‘SDL_GetError’ was not declared in this scope
main_unix.cpp:696:9: error: ‘SDL_Quit’ was not declared in this scope
make: *** [obj/main_unix.o] Error 1

For str, I have a fix (patch is attached). For SDL, I don't know how to fix it.