Sorry, I forgot to mention that if you pass "OPENMSX_TARGET_CPU=mipsel" to
Make, you also have to pass "OPENMSX_TARGET_OS=linux" in order to bypass the
broken autodetection.
Bye,
Maarten
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "u
Package: openmsx
Version: 0.8.2-2.1
Little endian MIPS systems were autodetected as "mips" instead of "mipsel",
which means openMSX will be built for a big endian CPU. This leads to all
kinds of runtime bugs, the most obvious of which is that all SHA1 sums for
ROMs will mismatch from those in t
Hi Carlos,
We're going to need a some more information to be able to handle your bug
report:
Did you launch openMSX via Catapult or from the command line or in a
different way? Did you pass any command line arguments to openMSX?
Does openMSX print anything before it crashes?
Does openMSX als
On Friday 27 November 2009, Cyril Brulebois wrote:
> Maarten ter Huurne (27/11/2009):
> > Instead of matching "gnu/kfreebsd" as FreeBSD and then checking for
> > glibc, maybe it would be simpler to map any system name starting
> > with "gnu/" to openMSX O
On Friday 27 November 2009, Cyril Brulebois wrote:
> your package FTBFS on GNU/kFreeBSD as follows:
> | Unsupported or unrecognised OS "gnu/kfreebsd"
Instead of matching "gnu/kfreebsd" as FreeBSD and then checking for glibc,
maybe it would be simpler to map any system name starting with "gnu/" t
Hi Cyril,
Thanks for your report and patch.
The change to detectsys.sh looks correct. I fixed it in a different way on
SVN trunk though: I ported the Python-based system detection from the
openMSX build. This will be easier for us to maintain. It also means we no
longer use the outdated config
Thank you for your bug report and patch.
I solved it in Catapult SVN, but in a slightly different way: unlike openMSX
itself, Catapult does not really have to know for which CPU it is building.
So I removed all CPU specific Makefiles, to avoid similar build problems on
other CPU types in the fu
Hi,
I had a very similar problem after upgrading my gateway machine from Etch to
Lenny. The gateway itself could do any kind of transfers to the internet,
but the PCs for which it masquerades the traffic could do very little.
ICMP worked (tested with ping), UDP worked (tested with DNS lookups)
Hi Sylvain and Manuel,
I edited logilab/astng/manager.py in the following way: (line 190)
modastng = self.astng_from_module_name(modname)
try:
return modastng.getattr(klass.__name__)[0] # XXX
except NotFoundError:
return None
This requires an addit
Hi Sylvain and Manuel,
I tested this on SUSE Linux 10.2 and got the same error, so it is probably not
Debian-specific.
pylint 0.13.2,
astng 0.17.1, common 0.22.2
Python 2.5 (r25:51908, May 25 2007, 16:14:04)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)]
Bye,
Maarten
signature
This bug corresponds to the following upstream bug:
http://bugs.kde.org/show_bug.cgi?id=138472
It was marked as a duplicate by one of the KDE developers, also saying it
should be fixed in KDE 3.5.6 when that is released.
Bye,
Maarten
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Hi,
I modified the 2.0.53 patch from the
ASF Bugzilla so that it applies to the Debian package "apache2_2.0.54-5".
No modifications were needed for going from upstream 2.0.53 to upstream
2.0.54, but the ProxyPassReverseCookiePath patch interacts with code inserted
by Debian patch "044_content_len
Hi,
The machine "C-BIOS MSX2+" is the default machine of openMSX (the machine
selected if you don't have a ~/.openMSX/share/settings.xml). So there is an
actual dependency: openMSX won't start for the first time unless C-BIOS is
installed.
Theoretically, you could work around this by manually
13 matches
Mail list logo
