Hi,
On Sat, 9 Dec 2006, Mike Hommey wrote:
> Tha patch contains a bad bugzilla bug reference. Could you point to the
> real one, please ;)
What do you mean? I changed it to the bts number of the orignal report
with the first version of the patch.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAI
Hi,
On Sat, 9 Dec 2006, Matthias Klose wrote:
> Roman, do you intend to provide a fix for gcc-4.1?
Attached, it's an update to the m68k-fpcompare patch.
For the log: Allow any fp constant as any immediate operand during and
after reload, even for special constants in case reload can't find a fr
Hi,
On Fri, 8 Dec 2006, sean finney wrote:
> you happen to know if php4 suffers from a similar problem wrt this?
I don't think so, the problem was introduced with 5.2.0.
> i'll probably wrap this up with a couple other loose things for an
> upload this weekend.
Thanks.
bye, Roman
--
To UNS
Package: linux-2.6
Severity: important
Hi,
External kernel modules currently fail to build as can be seen here:
http://buildd.debian.org/fetch.cgi?&pkg=linux-modules-extra-2.6&ver=2.6.18-2&arch=m68k&stamp=1165225409&file=log
To fix the problem please include the arch/m68k/kernel/module.lds file
i
Package: git-core
Severity: important
Tags: patch
Hi,
git currently fails to compile as it fails the self test.
I looked into this and with the help of the author there is now a patch
for this to fix the problem:
http://marc.theaimsgroup.com/?l=git&m=116522648806237&q=raw
bye, Roman
-- System
Package: xulrunner
Version: 1.8.0.8-1
Severity: important
Tags: patch
Hi,
Currently epiphany-browser fails to build as seen here:
http://buildd.debian.org/fetch.cgi?&pkg=epiphany-browser&ver=2.14.3-3&arch=m68k&stamp=1163307325&file=log
The problem is the XPTC_InvokeByIndex() function, gcc can as
Hi,
On Mon, 4 Dec 2006, Troy Heber wrote:
> On 12/01/06 00:40, Roman Zippel wrote:
> > A few structures are not evenly dividable by word_t and thus too
> > little memory is allocated.
>
> I'm trying to figure out how this is a bug in Judy. It seems like the
> all
Hi,
On Fri, 1 Dec 2006, sean finney wrote:
> @@ -373,6 +373,11 @@
> #ifndef ZEND_MM_ALIGNMENT
> # define ZEND_MM_ALIGNMENT 8
> # define ZEND_MM_ALIGNMENT_LOG2 3
> +#elif ZEND_MM_ALIGNMENT < 4
> +# undef ZEND_MM_ALIGNMENT
> +# undef ZEND_MM_ALIGNMENT
> +# define ZEND_MM_ALIGNMENT 4
> +# define
Hi,
Here is also how it's officially fixed now in CVS:
http://news.php.net/php.zend-engine.cvs/5437
Please release a new package with this patch.
Thanks.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: php5
Severity: important
Tags: patch
Hi,
php5 currently fails to compile because it crashes in the allocator. The
basic problem is, that the used alignment is to small. The allocator
needs two bits for type information, but the alignment is set to two on
m68k. The attached patch fixes t
Package: judy
Severity: important
Tags: patch
Hi,
An alignment problem in judy causes other packages to fail (e.g.
miredo). A few structures are not evenly dividable by word_t and thus
too little memory is allocated. The attached patch fixes this problem.
An alternative solution is to round up t
alpha and powerpc [1].
>
> [1] http://buildd.debian.org/build.php?pkg=monotone
>
> One suggested workaround (by Roman Zippel above) is to remove
> -DBOOST_SP_DISABLE_THREADS. The ChangeLog indicates that Nathaniel
> added this feature on 2005-09-30.
>
> So, my questions fo
Hi,
On Thu, 16 Nov 2006, Bill Allombert wrote:
> On Sat, Oct 21, 2006 at 06:19:20AM -0700, Matthias Klose wrote:
> > Source: gcc-4.1
> > Source-Version: 4.1.1ds2-17
> >[Roman Zippel]
> >* debian/patches/m68k-secondary-addr-reload.dpatch: Add secondary reloads
Hi,
On Sun, 22 Oct 2006, Rob Browning wrote:
> > I looked into this problem and with the attached patch I can
> > successfully compile the package. The most important part is the
> > SHORT_ALIGN define, as m68k has different alignment rules.
>
> I noticed that you increased the stack limit, but
Package: hula
Severity: important
Tags: patch
Hi,
hula current fails to compile on m68k and the problem is caused by the
different alignment rules m68k has. The _TemplateStruct structure isn't
properly padded, as it's expected by mwcomp.c. The attached patch fixes
this and let's hula successfully
Package: pyinotify
Severity: important
Tags: patch
Hi,
pyinotify currently fails to build m68k as it lacks the support for it.
The attached patch adds the necessary support. It adds the missing
system call numbers as they can also be found in the upstream sources.
Please apply, thanks.
bye, Roma
Package: python-gnome
Severity: important
Tags: patch
Hi,
python-gnome currently fails to build because it touches some of the
autoconf files, which messes up the time stamps, so the generated
Makefile might attempt to regenerate them again. The attached patch
touches these files in the correct o
Package: lyskom-tty-client
Severity: important
Tags: patch
Hi,
lyskom-tty-client currently fails to build because it touches some of
the autoconf files, which messes up the time stamps, so the generated
Makefile might attempt to regenerate them again. The attached patch
touches these files in the
tags 362032 patch
thanks
Hi,
The attached patch touches the autoconf files in the correct order, so
this won't happen. Please apply, thanks.
bye, Roman
diff -ur progsreiserfs-0.3.0.5.org/debian/rules
progsreiserfs-0.3.0.5/debian/rules
--- progsreiserfs-0.3.0.5.org/debian/rules 2006-10-21
Package: kaptain
Severity: important
Tags: patch
Hi,
kaptain currently fails to build because it touches some of the
autoconf files, which messes up the time stamps, so the generated
Makefile might attempt to regenerate them again. The attached patch
touches these files in the correct order, so t
Package: bfbtester
Severity: important
Tags: patch
Hi,
bfbtester currently fails to build because it touches some of the
autoconf files, which messes up the time stamps, so the generated
Makefile might attempt to regenerate them again. The attached patch
touches these files in the correct order,
tags 353853 patch
thanks
Hi,
The attached patch touches these files in the correct order, so this won't
happen. Please apply, thanks.
bye, Romandiff -ur gnobog-0.4.3.org/debian/rules gnobog-0.4.3/debian/rules
--- gnobog-0.4.3.org/debian/rules 2006-10-21 01:42:38.0 +0200
+++ gnobog
Package: squid3
Severity: important
Tags: patch
Hi,
The squid3 currently fails to build on m68k and the problem is simply a
missing pair of parentheses. The attached patch fixes the issue, so it
will build fine on m68k.
bye, Roman
-- System Information:
Debian Release: testing/unstable
APT pr
Package: gnusound
Severity: important
Tags: patch
Hi,
gnusound currently fails to build on m68k and the basic problem is that
float32_to_le() incorrectly attempts to convert a big endian float to a
little endian float. I guess on other big endian ports the value is
silently converted to an intege
Hi,
On Tue, 17 Oct 2006, Paolo Bonzini wrote:
> > The other problem is that the configure script doesn't configure the fault
> > handler correctly, the m68k check is too late and CFG_FAULT already has been
> > set fault-posix.h.
> >
> This means that, in theory, the fault-posix.h handler was f
Package: gauche
Version: 0.8.7-4
Severity: important
Tags: patch
Hi,
gauche currently fails to build, if it hits a buildd running 2.6. The
problem is the included libgc and the separate libgc package already has
the same patch. Please include the patch, so gauche works properly.
Thanks.
bye, Rom
Hi,
I looked into the build problems and with the attached patch I can
successfully build the package and even the test complete successfully.
The main problem is with heap_block in alloc.h, which causes all following
structures to be misaligned.
The other problem is that the configure script do
Hi,
On Mon, 16 Oct 2006, Brian Nelson wrote:
> To what file should those lines be added? There isn't a buildd log for
> m68k on buildd.d.o, so I can't see the actual error.
Sorry, I indeed forgot to mention that. m68k is missing in the list at
src/corelib/io/qfilesystemwatcher_inotify.cpp
bye
Hi,
I looked into this problem and with the attached patch I can successfully
compile the package.
The most important part is the SHORT_ALIGN define, as m68k has different
alignment rules. I also synced the m68k gc_os_dep.c with the current
Debian boehm-gc definitions.
I tested it with debug op
Hi,
Is there any progress here?
If there is anything I can do help with this problem, please ask, but
_please_ don't ignore this bug. It makes a number of other packages
unusable, I provided the necessary information to fix the problem, so
please don't delay this more than necessary.
Thanks.
b
Hi,
Is there any progress here?
_Please_ release a fixed package, which includes the patch. The patch is
entirely m68k specific, so it won't do any damage to the other ports, but
it would help m68k.
Thanks.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscri
Hi,
Is there any progress here?
If there is anything I can do to help, please ask, but please don't ignore
this bug...
Thanks.
bye, Roman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: qt4-x11
Severity: important
qt4-x11 currently fails to build as it misses some defines for the
inotify system calls on m68k, adding this should fix the problem:
#elif defined (__mc68000__)
#define __NR_inotify_init 284
#define __NR_inotify_add_watch 285
#define __NR_inotify_rm_wat
Package: linux-kernel-headers
Version: 2.6.18-1
Severity: important
Tags: patch
Hi,
The current kernel header break a few packages on m68k, e.g. binutils
trips over the NBPG define, others like qt4-x11 need more system call
defines. I included patches for these. The user.h change is already in
Li
Hi,
Would someone please take a look at this bug and apply this patch?
It currently keeps stlport from compiling and keeps wasting the time of
the buildd by doing nothing.
If there's anything I can do to help, please ask, but don't ignore this
bug!
Thanks.
bye, Roman
--
To UNSUBSCRIBE, email
Hi,
On Tue, 3 Oct 2006, Stephen R Marenka wrote:
> binutils fails to build from source on m68k.
>
> Here are selected excerpts from the buildd log.
>
>
> | Automatic build of binutils_2.17-3 on aahz by sbuild/m68k 85
> | Build started at 20061003-0403
> |
> ***
Hi,
I looked into this and it turns out to be a problem in orbit2 (see #390516
for more info). The problem is that gconfd-2 fails to start up and
gconftool-2 waits forever for it.
It might be a good idea to make gconftool-2 a bit more robust and let it
check that gconfd-2 started up properly an
Package: orbit2
Severity: important
Tags: patch
Hi,
orbit2 is currently on m68k seriously broken and makes packages like
gconf2 unusable (see #336289 and #348010).
The reason is that m68k has some rather unusual alignment rules and this
breaks several alignment assumptions in the orbit2 code.
The
Hi,
I debugged the problem a bit and the problem seems to be the
BOOST_SP_DISABLE_THREADS define and monotone being linked against the
multithreaded boost libraries. boost and monotone have a different idea
of the sp_counted_base class, so that it gets initialized within monotone
non-threaded
Package: mcmcpack
Severity: normal
Hi,
mcmcpack currently fails to build and the basic problem is that the
configure script doesn't find the trunc() function, because it looks in
the wrong library. An easy solution is to add the line "AC_CHECK_LIB(m,
trunc)" to configure.ac before the trunc check
Package: gjdoc
Version: 0.7.7-3
Severity: important
Hi,
I'm in the process of getting Java fixed for m68k and since gjdoc is
blocking a large number of packages, I'm using it for testing. With my
changes to gcj it currently aborts with this message:
$ gjdoc --help
Exception in thread "main" java
Hi,
On Tue, 19 Sep 2006, Richard B. Kreckel wrote:
> Roman Zippel wrote:
>
> > I checked the compile failure and it seems to be an assembler problem,
> > but the constructor/desctructor hack is not completely blameless.
> > It seems the assembler doesn't know how
Hi,
I looked at it and it's not really a gcc bug, it's more of a binutils bug,
but cln plays some rather weird games, which finally confuses as, so it's
not completely faultless.
I submitted a patch to cln (#388000) which avoids the problem, so this bug
can be closed.
bye, Roman
--
To UNSUB
Package: cln
Severity: important
Tags: patch
Hi,
I checked the compile failure and it seems to be an assembler problem,
but the constructor/desctructor hack is not completely blameless.
It seems the assembler doesn't know how to generate the GOT entry for
the duplicated jump destination.
Luckily
Package: subversion
Version: 1.4.0
Severity: serious
Tags: patch
Justification: no longer builds from source
Hi,
I looked at the failing self tests. The first one is a bug in the
created wrapper. The basic problem is that in
svn_delta.c:_wrap_svn_txdelta_apply_wrapper() the value of temp3 is not
Package: glibc
Severity: important
Tags: patch
Hi,
stlport currectly produces a deadlock in its testsuite, due to a
deadlock in __pthread_spin_lock(). The attached patch fixes it.
bye, Roman
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unst
Hi,
I attached a slighty different version of the previous patch, which simply
tries to open the port. It also correctly waits for a possible exit of the
server.
bye, Romandiff -ur subversion-1.3.2.org/subversion/bindings/swig/ruby/test/util.rb
subversion-1.3.2/subversion/bindings/swig/ruby/te
Package: libgc
Severity: important
Tags: patch
Hi,
The attached patch fixes a few bugs, which keeps the package from
working properly on m68k.
- the thread suspend handler has to save all registers
- change STACKBOTTOM to LINUX_STACKBOTTOM so it works with 2.6 kernel
- reenable MPROTECT_VDB, it s
Tags: patch
Hi,
The attached patch adds the missing m68k support and seems to work
fine according to the self test.
bye, Roman- align AO_t
- fix AO_test_and_set_full: it operates on bytes, better asm constraints
- add AO_compare_and_swap_full and AO_or_full
Index: libatomic-ops-1.1/src/atomic_
Hi,
On Sun, 14 Aug 2005, Marco d'Itri wrote:
> Compiling tin 1.7.10+20050727 on m68k fails.
>
> gcc -DHAVE_CONFIG_H -I. -I../include -I/usr/include
> -DLOCALEDIR=\"/usr/share/locale\" -I../include -DUSE_CANLOCK -D_GNU_SOURCE
> -g -O2 -c ./save.c
> ./save.c: In function 'uudecode_line':
> .
Hi,
Joshua Kwan wrote:
> gcc-4.0 ICEs on m68k while trying to build flac 1.1.2-3.
This bug is fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01677.html
Bugs 318292, 322532, 328453, 323016 are basically all caused by this
problem.
bye, Roman
--
To UNSUBSCRIBE, email to [EM
51 matches
Mail list logo
