Menu
▾
▴
basilisk-devel
|
From: Giulio P. <giu...@gm...> - 2012-06-09 18:44:41
|
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 |
|
From: Robert M. <mr...@gm...> - 2012-06-10 05:00:00
|
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
|
|
From: Giulio P. <giu...@gm...> - 2012-06-11 16:36:50
|
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. |
|
From: Robert M. <mr...@gm...> - 2012-06-12 00:01:09
|
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 |
|
From: Giulio P. <giu...@gm...> - 2012-06-15 16:52:58
|
On 12/06/2012 02:01, Robert Munafo wrote: > 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. In autoconf files they were there since the first CVS commit, but I do not know how this can help. >>> 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 Yes, the two usual fixes are either 1) temporary patch the building system or 2) wait for an upstream patched release. > 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. config.h.in is normally generated by autoheader, configure.ac is usually the manually edited main source and configure is automatically generated by autoconf and is responsible to convert .in files into the final file (e.g., to create config.h from config.h.in). > 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. The problem is that 1) I do not understand what to check for and 2) I do not understand the implication of undefining HAVE_DEV_PTMX. It is not a matter to detect Debian, as the building procedure is already working on many Debian architectures. It is a matter of detecting freebsd kernel in a Debian OS, but why? What features is missing? As the same problem appeared long time ago in NetBSD and other *BSD, is it related to FreeBSD? > 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. Once I will determine it I will do it for sure, but I do not think I have the knowledge to determine it on my own. Bests, Giulio. |
|
From: Alexei S. <ale...@gm...> - 2012-06-15 21:47:18
|
Does it work if you replace "mysig_t" with "sig_t" and "mysignal" with "signal"? On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...> wrote: > On 12/06/2012 02:01, Robert Munafo wrote: > > 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. > > In autoconf files they were there since the first CVS commit, but I do > not know how this can help. > > >>> 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 > > Yes, the two usual fixes are either 1) temporary patch the building > system or 2) wait for an upstream patched release. > > > 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. > > config.h.in is normally generated by autoheader, configure.ac is usually > the manually edited main source and configure is automatically generated > by autoconf and is responsible to convert .in files into the final file > (e.g., to create config.h from config.h.in). > > > 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. > > The problem is that 1) I do not understand what to check for and 2) I do > not understand the implication of undefining HAVE_DEV_PTMX. > > It is not a matter to detect Debian, as the building procedure is > already working on many Debian architectures. It is a matter of > detecting freebsd kernel in a Debian OS, but why? What features is > missing? As the same problem appeared long time ago in NetBSD and other > *BSD, is it related to FreeBSD? > > > 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. > > Once I will determine it I will do it for sure, but I do not think I > have the knowledge to determine it on my own. > > Bests, > Giulio. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Alexei S. <ale...@gm...> - 2012-06-15 21:58:13
|
I've now landed a change that does that and also includes <signal.h>. Let me know if it works for you now or if there are still issues. -Alexei On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine <ale...@gm...>wrote: > Does it work if you replace "mysig_t" with "sig_t" and "mysignal" with > "signal"? > > > On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...>wrote: > >> On 12/06/2012 02:01, Robert Munafo wrote: >> > 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. >> >> In autoconf files they were there since the first CVS commit, but I do >> not know how this can help. >> >> >>> 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 >> >> Yes, the two usual fixes are either 1) temporary patch the building >> system or 2) wait for an upstream patched release. >> >> > 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. >> >> config.h.in is normally generated by autoheader, configure.ac is usually >> the manually edited main source and configure is automatically generated >> by autoconf and is responsible to convert .in files into the final file >> (e.g., to create config.h from config.h.in). >> >> > 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. >> >> The problem is that 1) I do not understand what to check for and 2) I do >> not understand the implication of undefining HAVE_DEV_PTMX. >> >> It is not a matter to detect Debian, as the building procedure is >> already working on many Debian architectures. It is a matter of >> detecting freebsd kernel in a Debian OS, but why? What features is >> missing? As the same problem appeared long time ago in NetBSD and other >> *BSD, is it related to FreeBSD? >> >> > 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. >> >> Once I will determine it I will do it for sure, but I do not think I >> have the knowledge to determine it on my own. >> >> Bests, >> Giulio. >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> basilisk-devel mailing list >> bas...@li... >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel >> > > |
|
From: Robert M. <mr...@gm...> - 2012-06-16 06:36:23
|
Dear Giulio, Thanks for writing back, and thanks for the detailed responses. It's good to have answers to at least some of the stuff that I did not understand! But I guess we're still stuck on the main problem. I was hoping you might be able to figure out how to fix it. What we need is someone who has a computer with this problem, and who is also able to figure out how to get it to build (and run!), who can tell us how the configure.ac needs to change so that it will work properly without any manual temporary patch. It's too bad -- it looks like Debian will need to remove BasII. - Robert On 6/15/12, Giulio Paci <giu...@gm...> wrote: > Yes, the two usual fixes are either 1) temporary patch the building > system or 2) wait for an upstream patched release. > [...] > config.h.in is normally generated by autoheader, configure.ac is usually > the manually edited main source and configure is automatically generated > by autoconf and is responsible to convert .in files into the final file > (e.g., to create config.h from config.h.in). > [...] > The problem is that 1) I do not understand what to check for and 2) I do > not understand the implication of undefining HAVE_DEV_PTMX. > > It is not a matter to detect Debian, as the building procedure is > already working on many Debian architectures. It is a matter of > detecting freebsd kernel in a Debian OS, but why? What features is > missing? As the same problem appeared long time ago in NetBSD and other > *BSD, is it related to FreeBSD? -- 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 |
|
From: Giulio P. <giu...@gm...> - 2012-06-16 18:34:14
|
Il 16/06/2012 08:36, Robert Munafo ha scritto: > What we need is someone who has a computer with this problem, and who > is also able to figure out how to get it to build (and run!), who can > tell us how the configure.ac needs to change so that it will work > properly without any manual temporary patch. Yes, unfortunately this is my first time with a Debian with freebsd kernel, so I am still not able to run Xorg on my virtual machine. If anybody is interested I can share the VM anyway: I have no private data there, just the Basilisk requirements. > It's too bad -- it looks like Debian will need to remove BasII. I hope we will be able to ship also a package for Debian kfreebsd, but there is no reason to remove Basilisk II for the Debian architectures that are working. :-) |
|
From: Alexei S. <ale...@gm...> - 2012-06-16 18:37:13
|
On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm...> wrote: > Il 16/06/2012 08:36, Robert Munafo ha scritto: > > What we need is someone who has a computer with this problem, and who > > is also able to figure out how to get it to build (and run!), who can > > tell us how the configure.ac needs to change so that it will work > > properly without any manual temporary patch. > > Yes, unfortunately this is my first time with a Debian with freebsd > kernel, so I am still not able to run Xorg on my virtual machine. > If anybody is interested I can share the VM anyway: I have no private > data there, just the Basilisk requirements. Can you let me know whether my changes fixed the compilation error? -Alexei |
|
From: Giulio P. <giu...@gm...> - 2012-06-16 18:47:26
|
Il 15/06/2012 23:57, Alexei Svitkine ha scritto: > I've now landed a change that does that and also includes <signal.h>. > Let me know if it works for you now or if there are still issues. It is still not working: sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function) I also have two warnings about "sig" and "strlcpy" implicit declaration. The first one is due to a wrong definition of mysignal. I do not know why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined to 1). Giulio. > On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine > <ale...@gm... <mailto:ale...@gm...>> wrote: > > Does it work if you replace "mysig_t" with "sig_t" and "mysignal" > with "signal"? > > > On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm... > <mailto:giu...@gm...>> wrote: > > On 12/06/2012 02:01, Robert Munafo wrote: > > Hello Giulio, > > > > On 6/11/12, Giulio Paci <giu...@gm... > <mailto: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. > > In autoconf files they were there since the first CVS commit, > but I do > not know how this can help. > > >>> 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 <http://config.h.in> > > Unix/configure > > Unix/configure.ac <http://configure.ac> > > Yes, the two usual fixes are either 1) temporary patch the building > system or 2) wait for an upstream patched release. > > > 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. > > config.h.in <http://config.h.in> is normally generated by > autoheader, configure.ac <http://configure.ac> is usually > the manually edited main source and configure is automatically > generated > by autoconf and is responsible to convert .in files into the > final file > (e.g., to create config.h from config.h.in <http://config.h.in>). > > > 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. > > The problem is that 1) I do not understand what to check for and > 2) I do > not understand the implication of undefining HAVE_DEV_PTMX. > > It is not a matter to detect Debian, as the building procedure is > already working on many Debian architectures. It is a matter of > detecting freebsd kernel in a Debian OS, but why? What features is > missing? As the same problem appeared long time ago in NetBSD > and other > *BSD, is it related to FreeBSD? > > > 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. > > Once I will determine it I will do it for sure, but I do not think I > have the knowledge to determine it on my own. > > Bests, > Giulio. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest > in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > <mailto:bas...@li...> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Alexei S. <ale...@gm...> - 2012-06-17 16:42:39
|
On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm...> wrote: > Il 15/06/2012 23:57, Alexei Svitkine ha scritto: > > I've now landed a change that does that and also includes <signal.h>. > > Let me know if it works for you now or if there are still issues. > > It is still not working: > sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function) > > I also have two warnings about "sig" and "strlcpy" implicit declaration. > The first one is due to a wrong definition of mysignal. I do not know > why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined > to 1). > > I've landed another couple of changes. Can you try again? -Alexei |
|
From: Giulio P. <giu...@gm...> - 2012-06-17 22:20:20
|
Il 17/06/2012 18:42, Alexei Svitkine ha scritto: > > > On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm... > <mailto:giu...@gm...>> wrote: > > Il 15/06/2012 23:57, Alexei Svitkine ha scritto: > > I've now landed a change that does that and also includes <signal.h>. > > Let me know if it works for you now or if there are still issues. > > It is still not working: > sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function) > > I also have two warnings about "sig" and "strlcpy" implicit declaration. > The first one is due to a wrong definition of mysignal. I do not know > why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined > to 1). > > I've landed another couple of changes. Can you try again? Still not working. :-( However if I include stropts.h (the only header I found on the kfreebsd system defining I_PUSH), compilation succeeds. |
|
From: Alexei S. <ale...@gm...> - 2012-06-17 23:16:01
|
I've committed another change. Let me know if it works now. On Sun, Jun 17, 2012 at 6:20 PM, Giulio Paci <giu...@gm...> wrote: > Il 17/06/2012 18:42, Alexei Svitkine ha scritto: > > > > > > On Sat, Jun 16, 2012 at 2:47 PM, Giulio Paci <giu...@gm... > > <mailto:giu...@gm...>> wrote: > > > > Il 15/06/2012 23:57, Alexei Svitkine ha scritto: > > > I've now landed a change that does that and also includes > <signal.h>. > > > Let me know if it works for you now or if there are still issues. > > > > It is still not working: > > sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this > function) > > > > I also have two warnings about "sig" and "strlcpy" implicit > declaration. > > The first one is due to a wrong definition of mysignal. I do not know > > why I see the strlcpy warning (In config.h HAVE_STRLCPY has been > defined > > to 1). > > > > I've landed another couple of changes. Can you try again? > > Still not working. :-( However if I include stropts.h (the only header I > found on the kfreebsd system defining I_PUSH), compilation succeeds. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Giulio P. <giu...@gm...> - 2012-06-18 23:31:52
|
Il 16/06/2012 20:36, Alexei Svitkine ha scritto: > > > On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm... > <mailto:giu...@gm...>> wrote: > > Il 16/06/2012 08:36, Robert Munafo ha scritto: > > What we need is someone who has a computer with this problem, and who > > is also able to figure out how to get it to build (and run!), who can > > tell us how the configure.ac <http://configure.ac> needs to change > so that it will work > > properly without any manual temporary patch. > > Yes, unfortunately this is my first time with a Debian with freebsd > kernel, so I am still not able to run Xorg on my virtual machine. > If anybody is interested I can share the VM anyway: I have no private > data there, just the Basilisk requirements. > > > Can you let me know whether my changes fixed the compilation error? Just checked and they did. I was also able to start BasiliskII and it seems to work. Thank you very much for your work. Giulio. |
|
From: Alexei S. <ale...@gm...> - 2012-06-18 23:35:00
|
Excellent! On Mon, Jun 18, 2012 at 7:32 PM, Giulio Paci <giu...@gm...> wrote: > Il 16/06/2012 20:36, Alexei Svitkine ha scritto: > > > > > > On Sat, Jun 16, 2012 at 2:34 PM, Giulio Paci <giu...@gm... > > <mailto:giu...@gm...>> wrote: > > > > Il 16/06/2012 08:36, Robert Munafo ha scritto: > > > What we need is someone who has a computer with this problem, and > who > > > is also able to figure out how to get it to build (and run!), who > can > > > tell us how the configure.ac <http://configure.ac> needs to change > > so that it will work > > > properly without any manual temporary patch. > > > > Yes, unfortunately this is my first time with a Debian with freebsd > > kernel, so I am still not able to run Xorg on my virtual machine. > > If anybody is interested I can share the VM anyway: I have no private > > data there, just the Basilisk requirements. > > > > > > Can you let me know whether my changes fixed the compilation error? > > Just checked and they did. > I was also able to start BasiliskII and it seems to work. > > Thank you very much for your work. > Giulio. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Giulio P. <giu...@gm...> - 2012-08-08 16:47:00
|
Hi to all, On 09/06/2012 20:44, Giulio Paci wrote: > 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 fixed that. For kfreebsd Alexei Svitkine committed a fix, that is working. For armel the building procedure reports: sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not declared in this scope sigsegv.cpp:1624: error: expected ',' or ';' before '{' token gmake: *** [obj/sigsegv.o] Error 1 gmake: *** Waiting for unfinished jobs.... *** Error code 2 I had a quick look to this issue, but, once again, the fix is beyond my knowledge and I found no useful information about it on the web (only people experimenting this issue, but no solution). Unfortunately I also had very few time last month, so I was not able to do anything useful about this issue. I have installed a Debian armel using qemu, so I have access to an armel system now. If anyone wants to propose a solution for this issue I will be able to try it. If anyone is interested I can also share the VM image. On Debian system libsigsegv is available as a system library. Is it possible to use it instead of the included sigsegv.cpp? Bests, Giulio. |
|
From: Alexei S. <ale...@gm...> - 2012-08-09 04:27:45
|
On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: > Hi to all, > > On 09/06/2012 20:44, Giulio Paci wrote: >> 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 fixed that. > For kfreebsd Alexei Svitkine committed a fix, that is working. > > For armel the building procedure reports: > > sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not > declared in this scope > sigsegv.cpp:1624: error: expected ',' or ';' before '{' token > gmake: *** [obj/sigsegv.o] Error 1 > gmake: *** Waiting for unfinished jobs.... > *** Error code 2 Those line numbers don't look right to me. Do you have local edits to the file? > > I had a quick look to this issue, but, once again, the fix is beyond my > knowledge and I found no useful information about it on the web (only > people experimenting this issue, but no solution). Unfortunately I also > had very few time last month, so I was not able to do anything useful > about this issue. > I have installed a Debian armel using qemu, so I have access to an armel > system now. If anyone wants to propose a solution for this issue I will > be able to try it. If anyone is interested I can also share the VM image. > Please share the VM image and I'll try to take a look at it as time permits. Thanks. > On Debian system libsigsegv is available as a system library. Is it > possible to use it instead of the included sigsegv.cpp? > > Bests, > Giulio. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Giulio P. <giu...@gm...> - 2012-08-09 14:12:45
|
On 09/08/2012 06:27, Alexei Svitkine wrote: > On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: >> Hi to all, >> >> On 09/06/2012 20:44, Giulio Paci wrote: >>> 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 fixed that. >> For kfreebsd Alexei Svitkine committed a fix, that is working. >> >> For armel the building procedure reports: >> >> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not >> declared in this scope >> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token >> gmake: *** [obj/sigsegv.o] Error 1 >> gmake: *** Waiting for unfinished jobs.... >> *** Error code 2 > > Those line numbers don't look right to me. Do you have local edits to the file? No I have not, however this report is not about the latest version in git (that is still failing with the same error message, about 800 lines below): it is about the codebase I used to build the Debian package (i.e., a CVS snapshot at the end of march). >> I had a quick look to this issue, but, once again, the fix is beyond my >> knowledge and I found no useful information about it on the web (only >> people experimenting this issue, but no solution). Unfortunately I also >> had very few time last month, so I was not able to do anything useful >> about this issue. >> I have installed a Debian armel using qemu, so I have access to an armel >> system now. If anyone wants to propose a solution for this issue I will >> be able to try it. If anyone is interested I can also share the VM image. > Please share the VM image boot.sh: a script that can be used to start the VM (using qemu) https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU boot.tar.bz2: the /boot directory containing the kernel to start the VM https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8 debian-testing-armel.qcow.bz2: the image of a current Debian testing https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8 To run the VM, install qemu with arm support, untar the boot.tar.bz2, expand debian-testing-armel.qcow.bz2 and run the script. There is a "root" user and a "debian" user. The password for both is "debian". The "debian" user already has macemu git repository in its home (~/Source/macemu), and BasiliskII has already been configured. Running make in ~/Source/macemu/BasiliskII/src/Unix should give you the error. In ~/Source/debian-packages/basilisk2 there are the sources of the Debian package. To compile it you can run "git-buildpackage --git-ignore-new", and compilation should fail with the error above. > and I'll try to take a look at it as time permits. Thanks. Thank you very much for your help. Bests, Giulio. |
|
From: Alexei S. <ale...@gm...> - 2012-08-12 17:18:27
|
This should now be fixed in TOT in the git repo. You'll need to re-run autogen.sh. -Alexei On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote: > On 09/08/2012 06:27, Alexei Svitkine wrote: >> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: >>> Hi to all, >>> >>> On 09/06/2012 20:44, Giulio Paci wrote: >>>> 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 fixed that. >>> For kfreebsd Alexei Svitkine committed a fix, that is working. >>> >>> For armel the building procedure reports: >>> >>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not >>> declared in this scope >>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token >>> gmake: *** [obj/sigsegv.o] Error 1 >>> gmake: *** Waiting for unfinished jobs.... >>> *** Error code 2 >> >> Those line numbers don't look right to me. Do you have local edits to the file? > > No I have not, however this report is not about the latest version in > git (that is still failing with the same error message, about 800 lines > below): it is about the codebase I used to build the Debian package > (i.e., a CVS snapshot at the end of march). > >>> I had a quick look to this issue, but, once again, the fix is beyond my >>> knowledge and I found no useful information about it on the web (only >>> people experimenting this issue, but no solution). Unfortunately I also >>> had very few time last month, so I was not able to do anything useful >>> about this issue. >>> I have installed a Debian armel using qemu, so I have access to an armel >>> system now. If anyone wants to propose a solution for this issue I will >>> be able to try it. If anyone is interested I can also share the VM image. > >> Please share the VM image > > boot.sh: a script that can be used to start the VM (using qemu) > https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU > > boot.tar.bz2: the /boot directory containing the kernel to start the VM > https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8 > > debian-testing-armel.qcow.bz2: the image of a current Debian testing > https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8 > > To run the VM, install qemu with arm support, untar the boot.tar.bz2, > expand debian-testing-armel.qcow.bz2 and run the script. > > There is a "root" user and a "debian" user. > The password for both is "debian". > The "debian" user already has macemu git repository in its home > (~/Source/macemu), and BasiliskII has already been configured. Running > make in ~/Source/macemu/BasiliskII/src/Unix should give you the error. > > In ~/Source/debian-packages/basilisk2 there are the sources of the > Debian package. To compile it you can run "git-buildpackage > --git-ignore-new", and compilation should fail with the error above. > >> and I'll try to take a look at it as time permits. Thanks. > > Thank you very much for your help. > > Bests, > Giulio. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Giulio P. <giu...@gm...> - 2012-08-18 14:30:07
|
Il 12/08/2012 19:17, Alexei Svitkine ha scritto: > This should now be fixed in TOT in the git repo. You'll need to re-run > autogen.sh. I confirm that the fix is working properly: both compilation and execution work. Thank you very much. > On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote: >> On 09/08/2012 06:27, Alexei Svitkine wrote: >>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: >>>> Hi to all, >>>> >>>> On 09/06/2012 20:44, Giulio Paci wrote: >>>>> 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 fixed that. >>>> For kfreebsd Alexei Svitkine committed a fix, that is working. >>>> >>>> For armel the building procedure reports: >>>> >>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not >>>> declared in this scope >>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token >>>> gmake: *** [obj/sigsegv.o] Error 1 >>>> gmake: *** Waiting for unfinished jobs.... >>>> *** Error code 2 >>> >>> Those line numbers don't look right to me. Do you have local edits to the file? >> >> No I have not, however this report is not about the latest version in >> git (that is still failing with the same error message, about 800 lines >> below): it is about the codebase I used to build the Debian package >> (i.e., a CVS snapshot at the end of march). >> >>>> I had a quick look to this issue, but, once again, the fix is beyond my >>>> knowledge and I found no useful information about it on the web (only >>>> people experimenting this issue, but no solution). Unfortunately I also >>>> had very few time last month, so I was not able to do anything useful >>>> about this issue. >>>> I have installed a Debian armel using qemu, so I have access to an armel >>>> system now. If anyone wants to propose a solution for this issue I will >>>> be able to try it. If anyone is interested I can also share the VM image. >> >>> Please share the VM image >> >> boot.sh: a script that can be used to start the VM (using qemu) >> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU >> >> boot.tar.bz2: the /boot directory containing the kernel to start the VM >> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8 >> >> debian-testing-armel.qcow.bz2: the image of a current Debian testing >> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8 >> >> To run the VM, install qemu with arm support, untar the boot.tar.bz2, >> expand debian-testing-armel.qcow.bz2 and run the script. >> >> There is a "root" user and a "debian" user. >> The password for both is "debian". >> The "debian" user already has macemu git repository in its home >> (~/Source/macemu), and BasiliskII has already been configured. Running >> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error. >> >> In ~/Source/debian-packages/basilisk2 there are the sources of the >> Debian package. To compile it you can run "git-buildpackage >> --git-ignore-new", and compilation should fail with the error above. >> >>> and I'll try to take a look at it as time permits. Thanks. >> >> Thank you very much for your help. >> >> Bests, >> Giulio. >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> basilisk-devel mailing list >> bas...@li... >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
|
From: Giulio P. <giu...@gm...> - 2012-08-18 23:28:50
|
Hi Alexei, looking at the sigsegv.cpp sources, I noticed an "#epif". Is it a typo? Bests, Giulio. Il 18/08/2012 16:29, Giulio Paci ha scritto: > Il 12/08/2012 19:17, Alexei Svitkine ha scritto: >> This should now be fixed in TOT in the git repo. You'll need to re-run >> autogen.sh. > > I confirm that the fix is working properly: both compilation and > execution work. > > Thank you very much. > >> On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote: >>> On 09/08/2012 06:27, Alexei Svitkine wrote: >>>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: >>>>> Hi to all, >>>>> >>>>> On 09/06/2012 20:44, Giulio Paci wrote: >>>>>> 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 fixed that. >>>>> For kfreebsd Alexei Svitkine committed a fix, that is working. >>>>> >>>>> For armel the building procedure reports: >>>>> >>>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not >>>>> declared in this scope >>>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token >>>>> gmake: *** [obj/sigsegv.o] Error 1 >>>>> gmake: *** Waiting for unfinished jobs.... >>>>> *** Error code 2 >>>> >>>> Those line numbers don't look right to me. Do you have local edits to the file? >>> >>> No I have not, however this report is not about the latest version in >>> git (that is still failing with the same error message, about 800 lines >>> below): it is about the codebase I used to build the Debian package >>> (i.e., a CVS snapshot at the end of march). >>> >>>>> I had a quick look to this issue, but, once again, the fix is beyond my >>>>> knowledge and I found no useful information about it on the web (only >>>>> people experimenting this issue, but no solution). Unfortunately I also >>>>> had very few time last month, so I was not able to do anything useful >>>>> about this issue. >>>>> I have installed a Debian armel using qemu, so I have access to an armel >>>>> system now. If anyone wants to propose a solution for this issue I will >>>>> be able to try it. If anyone is interested I can also share the VM image. >>> >>>> Please share the VM image >>> >>> boot.sh: a script that can be used to start the VM (using qemu) >>> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU >>> >>> boot.tar.bz2: the /boot directory containing the kernel to start the VM >>> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8 >>> >>> debian-testing-armel.qcow.bz2: the image of a current Debian testing >>> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8 >>> >>> To run the VM, install qemu with arm support, untar the boot.tar.bz2, >>> expand debian-testing-armel.qcow.bz2 and run the script. >>> >>> There is a "root" user and a "debian" user. >>> The password for both is "debian". >>> The "debian" user already has macemu git repository in its home >>> (~/Source/macemu), and BasiliskII has already been configured. Running >>> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error. >>> >>> In ~/Source/debian-packages/basilisk2 there are the sources of the >>> Debian package. To compile it you can run "git-buildpackage >>> --git-ignore-new", and compilation should fail with the error above. >>> >>>> and I'll try to take a look at it as time permits. Thanks. >>> >>> Thank you very much for your help. >>> >>> Bests, >>> Giulio. >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> basilisk-devel mailing list >>> bas...@li... >>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> basilisk-devel mailing list >> bas...@li... >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel > |
|
From: Alexei S. <ale...@gm...> - 2012-08-19 14:18:29
|
On Sat, Aug 18, 2012 at 7:28 PM, Giulio Paci <giu...@gm...> wrote: > Hi Alexei, > looking at the sigsegv.cpp sources, I noticed an "#epif". Is it a typo? Oops, yes that's a typo. Fixed now. Thanks! > > Bests, > Giulio. > > Il 18/08/2012 16:29, Giulio Paci ha scritto: >> Il 12/08/2012 19:17, Alexei Svitkine ha scritto: >>> This should now be fixed in TOT in the git repo. You'll need to re-run >>> autogen.sh. >> >> I confirm that the fix is working properly: both compilation and >> execution work. >> >> Thank you very much. >> >>> On Thu, Aug 9, 2012 at 10:14 AM, Giulio Paci <giu...@gm...> wrote: >>>> On 09/08/2012 06:27, Alexei Svitkine wrote: >>>>> On Wed, Aug 8, 2012 at 12:48 PM, Giulio Paci <giu...@gm...> wrote: >>>>>> Hi to all, >>>>>> >>>>>> On 09/06/2012 20:44, Giulio Paci wrote: >>>>>>> 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 fixed that. >>>>>> For kfreebsd Alexei Svitkine committed a fix, that is working. >>>>>> >>>>>> For armel the building procedure reports: >>>>>> >>>>>> sigsegv.cpp:1623: error: 'SIGSEGV_FAULT_HANDLER_ARGLIST' was not >>>>>> declared in this scope >>>>>> sigsegv.cpp:1624: error: expected ',' or ';' before '{' token >>>>>> gmake: *** [obj/sigsegv.o] Error 1 >>>>>> gmake: *** Waiting for unfinished jobs.... >>>>>> *** Error code 2 >>>>> >>>>> Those line numbers don't look right to me. Do you have local edits to the file? >>>> >>>> No I have not, however this report is not about the latest version in >>>> git (that is still failing with the same error message, about 800 lines >>>> below): it is about the codebase I used to build the Debian package >>>> (i.e., a CVS snapshot at the end of march). >>>> >>>>>> I had a quick look to this issue, but, once again, the fix is beyond my >>>>>> knowledge and I found no useful information about it on the web (only >>>>>> people experimenting this issue, but no solution). Unfortunately I also >>>>>> had very few time last month, so I was not able to do anything useful >>>>>> about this issue. >>>>>> I have installed a Debian armel using qemu, so I have access to an armel >>>>>> system now. If anyone wants to propose a solution for this issue I will >>>>>> be able to try it. If anyone is interested I can also share the VM image. >>>> >>>>> Please share the VM image >>>> >>>> boot.sh: a script that can be used to start the VM (using qemu) >>>> https://docs.google.com/open?id=0B7cMsawWW7uSUFFITVJnVzJEWkU >>>> >>>> boot.tar.bz2: the /boot directory containing the kernel to start the VM >>>> https://docs.google.com/open?id=0B7cMsawWW7uSMmFPdHlMaGVsVG8 >>>> >>>> debian-testing-armel.qcow.bz2: the image of a current Debian testing >>>> https://docs.google.com/open?id=0B7cMsawWW7uSTHd1LUM0VllvQW8 >>>> >>>> To run the VM, install qemu with arm support, untar the boot.tar.bz2, >>>> expand debian-testing-armel.qcow.bz2 and run the script. >>>> >>>> There is a "root" user and a "debian" user. >>>> The password for both is "debian". >>>> The "debian" user already has macemu git repository in its home >>>> (~/Source/macemu), and BasiliskII has already been configured. Running >>>> make in ~/Source/macemu/BasiliskII/src/Unix should give you the error. >>>> >>>> In ~/Source/debian-packages/basilisk2 there are the sources of the >>>> Debian package. To compile it you can run "git-buildpackage >>>> --git-ignore-new", and compilation should fail with the error above. >>>> >>>>> and I'll try to take a look at it as time permits. Thanks. >>>> >>>> Thank you very much for your help. >>>> >>>> Bests, >>>> Giulio. >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> basilisk-devel mailing list >>>> bas...@li... >>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> basilisk-devel mailing list >>> bas...@li... >>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X