Bug#1066143: general/glibc(?): simple IPv6 test program fails on m68k

Package: libc6 Version: 2.36-8 Severity: normal Tags: ipv6 X-Debbugs-Cc: t...@mirbsd.de, debian-68k@lists.debian.org This error occurred first during curl’s configure in a chroot with libc6 2.37-15.1, but I could also reproduce it on a build host with libc6 2.36-8 as well, and on an even older hos

Bug#1019133: ffmpeg: Please disable filter-overlay_yuv420p10 test on all BE targets

Source: ffmpeg Version: 7:5.1.1-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: hppa m68k powerpc ppc64 sparc64 X-Debbugs-Cc: debian-68k@lists.debian.org,debian-h...@lists.debian.org,debian-powe...@lists.debian.org,debian-sp...@lists.debian.org Hello! The test filter

Re: Quick test on real hardware requested to test qemu

On 9/22/20 6:06 PM, John Paul Adrian Glaubitz wrote: > Hmm, now it fails with __alignof__(): > > (sid-m68k-sbuild)root@epyc:/# debfoster -f > debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: > AO_load: Assertion `((size_t)addr & (__alignof__(*addr) - 1)) == 0' failed. > qemu

Re: Quick test on real hardware requested to test qemu

Hi Adrian, On Tue, Sep 22, 2020 at 5:23 PM John Paul Adrian Glaubitz wrote: > On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote: > >>> That a typical bad alignment check. It should use __alignof__, not > >>> sizeof. > >> > >> Aha, I was assuming something like that already but I wasn't sure si

Re: Quick test on real hardware requested to test qemu

On 9/22/20 5:23 PM, John Paul Adrian Glaubitz wrote:> On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote: That a typical bad alignment check. It should use __alignof__, not sizeof. >>> >>> Aha, I was assuming something like that already but I wasn't sure since >>> libatomic-ops wasn't

Re: Quick test on real hardware requested to test qemu

On 9/22/20 3:27 PM, John Paul Adrian Glaubitz wrote: >>> That a typical bad alignment check. It should use __alignof__, not >>> sizeof. >> >> Aha, I was assuming something like that already but I wasn't sure since >> libatomic-ops wasn't >> updated for a while in Debian [1]. > > What would be th

Re: Quick test on real hardware requested to test qemu

On Sep 22 2020, John Paul Adrian Glaubitz wrote: > root@pacman:~# debfoster > debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: > AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed. That a typical bad alignment check. It should use __alignof__, not sizeof

Re: Quick test on real hardware requested to test qemu

On 9/22/20 3:24 PM, John Paul Adrian Glaubitz wrote: > On 9/22/20 3:22 PM, Andreas Schwab wrote: >> On Sep 22 2020, John Paul Adrian Glaubitz wrote: >> >>> root@pacman:~# debfoster >>> debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: >>> AO_load: Assertion `((size_t)addr & (s

Re: Quick test on real hardware requested to test qemu

On 9/22/20 3:22 PM, Andreas Schwab wrote: > On Sep 22 2020, John Paul Adrian Glaubitz wrote: > >> root@pacman:~# debfoster >> debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: >> AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed. > > That a typical bad al

Quick test on real hardware requested to test qemu

Hi! Could someone install the "debfoster" command please on real hardware and test whether it crashes like it does on qemu? root@pacman:~# debfoster debfoster: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)

v4.1.43 test build is available, was Re: Seeking Mac testers

On Mon, 3 Apr 2017, Stefan Niestegge wrote: > > Hi there, > > we tested this kernel today on a Performa 450 (aka LC3) > ADB works nice, dmesg shows that the kernel detected our > network card (Nubus Slot E, Mac LC Ethernet Adapter, Board_ID 0x2e) > Its an "Asante" card, but ifconfig shows only l

Re: Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

On Sat, Aug 05, 2017 at 12:01:53AM +0200, John Paul Adrian Glaubitz wrote: > On 08/04/2017 11:23 PM, Stefan Fritsch wrote: > > The bug has been open for 9 years and no m68k porter has looked at it. > > Ususally apr test failures are toolchain/kernel/libc issues, so my > >

Re: Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

On 08/04/2017 11:23 PM, Stefan Fritsch wrote: > The bug has been open for 9 years and no m68k porter has looked at it. > Ususally apr test failures are toolchain/kernel/libc issues, so my > motivation to debug this for a very slow arch that has zero chance of ever > being part

Re: Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

ithout further notice? > > > I doubt that anyone is interested in debugging m68k issues > > How do you know without sending an email to debian-68k@l.d.o? The bug has been open for 9 years and no m68k porter has looked at it. Ususally apr test failures are toolchain/kernel/libc issues, s

Re: Bug#495400: apr_1.3.2-3(m68k/experimental): test suite fails

> Not sure if m68k is alive anymore. The build log urls are not reachable > anymore this bug report is no longer useful. Closing. Well, maybe you should just ask people instead of just closing bug reports without further notice? > I doubt that anyone is interested in debugging m68k issues How do

Linux mac68k v4.11 test kernel, was Re: Seeking Mac testers

Hi All, For anyone interested, I've made a new Mac kernel build available. This one is based on the latest mainline release. It is not a 4.x.y stable release... This build has patches from these two branches: https://github.com/fthain/linux/commits/mac68k-queue https://github.com/fthain/linux

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

Le 07/04/2017 à 08:04, Finn Thain a écrit : > > On Thu, 6 Apr 2017, Stefan Niestegge wrote: > >> Here are the dmesg logs of both kernels. >> > > Thank you for sending these logs. There's no real difference between the > output from the two builds. So my patch queue hasn't caused a regression.

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Thu, 6 Apr 2017, Stefan Niestegge wrote: > Here are the dmesg logs of both kernels. > Thank you for sending these logs. There's no real difference between the output from the two builds. So my patch queue hasn't caused a regression. But I'm none the wiser as to when or why your ethernet NI

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

Here are the dmesg logs of both kernels. Am 05.04.2017 um 03:47 schrieb Finn Thain: > On Tue, 4 Apr 2017, Stefan Niestegge wrote: > >> >> Well, with one of the last kernels we tried, we got the network up, but >> could only login to the Mac through serial console. Our "distro" is >> debian, iir

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

Here are the dmesg logs of both kernels. Am 05.04.2017 um 03:47 schrieb Finn Thain: > On Tue, 4 Apr 2017, Stefan Niestegge wrote: > >> >> Well, with one of the last kernels we tried, we got the network up, but >> could only login to the Mac through serial console. Our "distro" is >> debian, iir

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Tue, 4 Apr 2017, Stefan Niestegge wrote: > > Well, with one of the last kernels we tried, we got the network up, but > could only login to the Mac through serial console. Our "distro" is > debian, iirc its the tarball Th. Glaser supplied some time ago. Please also try the "4.1.39-mac_scsi-e

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

ys, 19:41, 2 users, load average: 0.00, 0.07, 0.07 > Well, this suggests that both the emulator and the kernel are stable. > > > > This looks like a very convenient way to test certain patches. Did you use > > upstream QEMU or your QEMU fork at https://github.com/vivier/

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

Am 04.04.2017 um 05:47 schrieb Finn Thain: > > On Mon, 3 Apr 2017, Stefan Niestegge wrote: >> we tested this kernel today on a Performa 450 (aka LC3) ADB works nice, > > Thanks for testing! > You're welcome! > > That really depends on your distro's network scripts and their configs. Well

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Mon, 3 Apr 2017, Stefan Niestegge wrote: > > Hi there, > > we tested this kernel today on a Performa 450 (aka LC3) ADB works nice, Thanks for testing! > dmesg shows that the kernel detected our network card (Nubus Slot E, Mac > LC Ethernet Adapter, Board_ID 0x2e) Its an "Asante" card, bu

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

uld need v2.x unless they need the SMC9194 Nubus >> network card driver. For some reason that driver only appeared in the >> v2.2 branch in the mac68k CVS and never in mainline Linux. It isn't >> likely to get a modern rewrite any time soon so I recommend replacing >>

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

ks Laurent! It is up now for 11 days. $ uname -a Linux q800 4.1.39-mac_scsi-egret-etc+ #2 Fri Mar 17 10:35:58 AEDT 2017 m68k GNU/Linux $ uptime 12:14:01 up 11 days, 19:41, 2 users, load average: 0.00, 0.07, 0.07 > > This looks like a very convenient way to test certain patches. Did you use

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Wed, 29 Mar 2017, James Hemsing wrote: > Strangely, I haven't been able to reproduce that ADB error. Launching > the kernel is temperamental: I have to open Settings in Penguin and > reselect the same kernel so that it will boot and not hang after > ABCDEFGH, so it may have been a temporary

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

he debian m68k > > page, tar -C'ed it to a SCSI drive using an Adaptec 2930 on a modern PC. > > > > Thanks for sending these results. > > > ADB/SCSI/Ethernet seem to be working fine on Quadra 700. I will try the > > SE/30 soon, no idea if it will work at al

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

em to be working fine on Quadra 700. I will try the > SE/30 soon, no idea if it will work at all. > I never tested an SE/30, but I used to test on a Mac II with an '030 accelerator so I'm optimistic that the SE/30 will work too. > If I reboot the Quadra from Linux into Sys

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

ested on my Quadra 800. ADB/SCSI/Ethernet work fine. > > I've also tested with Q800 implementation in QEMU and works fine too. > Thanks Laurent! This looks like a very convenient way to test certain patches. Did you use upstream QEMU or your QEMU fork at https://github.com/vivier/qe

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Tue, 21 Mar 2017, Laurent Vivier wrote: > > Tested on my Quadra 800. ADB/SCSI/Ethernet work fine. > > I've also tested with Q800 implementation in QEMU and works fine too. > Thanks Laurent! This looks like a very convenient way to test certain patches. Did you use u

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

uld need v2.x unless they need the SMC9194 Nubus >> network card driver. For some reason that driver only appeared in the >> v2.2 branch in the mac68k CVS and never in mainline Linux. It isn't >> likely to get a modern rewrite any time soon so I recommend replacing >>

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

On Mon, 20 Mar 2017, James Hemsing wrote: > I can test on a Quadra 700, SE/30, and LC475 once my CD-Rs arrive, if > that would be helpful. Great! The main areas needing more testing are these: - ADB - SONIC ethernet - Various video modes - 1, 2, 4, 8, 16, 24 and/or 32 bits per pixel -

Re: Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

I can test on a Quadra 700, SE/30, and LC475 once my CD-Rs arrive, if that would be helpful. On Sun, Mar 19, 2017 at 6:49 PM Finn Thain wrote: > On Fri, 17 Mar 2017, I wrote: > > > I've just uploaded a new kernel build to the Linux Mac68k sourceforge > > project:

Seeking Mac testers, was Re: Linux Mac68k v4.1.39 test kernel build is available

on that driver only appeared in the > v2.2 branch in the mac68k CVS and never in mainline Linux. It isn't > likely to get a modern rewrite any time soon so I recommend replacing > those cards and running v4.x on any 68k Mac. > I've uploaded a second test kernel build. This on

Re: Linux Mac68k v4.1.39 test kernel build is available

On 03/17/2017 08:50 PM, Ingo Jürgensmann wrote: > What about the esp driver on Amiga (A4000 SCSI, Blizzard 2060 SCSI, > Warpengine, ...)? > Michael built a test kernel as well some years ago… Michael has actually worked on the driver a bit and made improvements. He hasn't merged

Re: Linux Mac68k v4.1.39 test kernel build is available

m mainline v4.11-rc1. For machines that need those drivers > (LC III etc.) this build should work better than previous releases. Please > let me know if you encounter any regressions. What about the esp driver on Amiga (A4000 SCSI, Blizzard 2060 SCSI, Warpengine, ...)? Michael built a test

Linux Mac68k v4.1.39 test kernel build is available

I've just uploaded a new kernel build to the Linux Mac68k sourceforge project: https://sourceforge.net/projects/linux-mac68k/files/ This build has some patches for the mac_scsi and egret drivers that were backported from mainline v4.11-rc1. For machines that need those drivers (LC III etc.) th

[PATCH 2/6] m68k/defconfig: Enable test modules

It doesn't hurt to have CONFIG_TEST_* enabled as modules. Signed-off-by: Geert Uytterhoeven --- arch/m68k/configs/amiga_defconfig| 6 ++ arch/m68k/configs/apollo_defconfig | 6 ++ arch/m68k/configs/atari_defconfig| 6 ++ arch/m68k/configs/bvme6000_defconfig | 6 ++ arch

Re: Kernel 3.13-1-m68k test reports

Hi Adrian, On Thu, Apr 10, 2014 at 2:18 PM, Finn Thain wrote: >> merlin still fails to boot anything newer than the old 3.2 kernel. >> ... I suppose this is the same problem we have seen on 3.12-1-m68k when >> running on 68030, isn't it? > > Yes. The fix recently went into mainline, for 3.15, and

Re: Kernel 3.13-1-m68k test reports

On Thu, 10 Apr 2014, John Paul Adrian Glaubitz wrote: > merlin still fails to boot anything newer than the old 3.2 kernel. > ... I suppose this is the same problem we have seen on 3.12-1-m68k when > running on 68030, isn't it? Yes. The fix recently went into mainline, for 3.15, and Geert then

Kernel 3.13-1-m68k test reports

Hi! I have upgraded both elgar (68060/50/128 MB Fast) and merlin (68030/56/64 MB Fast) to the current unstable kernel 3.13-1-m68k. While elgar runs very stable and smooth so far on 3.13-1-m68k, merlin still fails to boot anything newer than the old 3.2 kernel. Init crashes with the following du

Bug#708056: ncurses: FTBFS: test/hanoi.c:234: undefined reference to `pow'

Source: ncurses Version: 5.9+20130504-1 Severity: important Tags: patch Justification: fails to build from source (but built successfully in the past) Hi! […] m68k-linux-gnu-gcc -c -I. -I/tmp/buildd/ncurses-5.9+20130504/test -I../test -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/tmp

Re: [PATCH 04/18] test/input: Fix double-aligned test in dix_valuator_alloc() on m68k

On Wed, Mar 27, 2013 at 2:55 PM, Mark Kettenis wrote: >> -#if !defined(__i386__) && !defined(__sh__) >> +#if !defined(__i386__) && !defined(__mc68000__) && !defined(__sh__) > > Any reason not to use __m68k__? That's what we tend to use in BSD land. __m68k__ is fine for me, too. Gr{oetje,eeting}

Re: [PATCH 04/18] test/input: Fix double-aligned test in dix_valuator_alloc() on m68k

> From: Geert Uytterhoeven > Date: Wed, 27 Mar 2013 14:20:37 +0100 > > On m68k, doubles are not 64-bit aligned, just like on i386 and sh. > > Signed-off-by: Geert Uytterhoeven > --- > test/input.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) >

[PATCH 04/18] test/input: Fix double-aligned test in dix_valuator_alloc() on m68k

On m68k, doubles are not 64-bit aligned, just like on i386 and sh. Signed-off-by: Geert Uytterhoeven --- test/input.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/test/input.c b/test/input.c index 90ab9ae..e2c8f4d 100644 --- a/test/input.c +++ b/test/input.c

Re: [PATCH] test/input: Replace negative architecture test by test for 64-bit

> Sender: geert.uytterhoe...@gmail.com > Date: Tue, 12 Feb 2013 14:03:50 +0100 > > On Tue, Feb 12, 2013 at 1:40 PM, Mark Kettenis > wrote: > >> From: Geert Uytterhoeven > >> Date: Tue, 12 Feb 2013 11:17:22 +0100 > >> > >> The test for doubl

Re: [PATCH] test/input: Replace negative architecture test by test for 64-bit

On Tue, Feb 12, 2013 at 1:40 PM, Mark Kettenis wrote: >> From: Geert Uytterhoeven >> Date: Tue, 12 Feb 2013 11:17:22 +0100 >> >> The test for double-aligned members in dix_valuator_alloc() currently >> depends on "if !defined(__i386__) && !defined(__

Re: [PATCH] test/input: Replace negative architecture test by test for 64-bit

Michał Masłowski dixit: >MIPS N32 needs doubles to be 8 byte aligned, while it has 32 bit longs Hrm. Well, GCC has __alignof__ and, I think, so has C11… bye, //mirabilos -- │ untested │ tut natürlich │ was auch sonst ... │ fijn ☺ -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.d

Re: [PATCH] test/input: Replace negative architecture test by test for 64-bit

> From: Geert Uytterhoeven > Date: Tue, 12 Feb 2013 11:17:22 +0100 > > The test for double-aligned members in dix_valuator_alloc() currently > depends on "if !defined(__i386__) && !defined(__sh__)". This covers > m68k, where it fails. > > According to

Re: [PATCH] test/input: Replace negative architecture test by test for 64-bit

Geert Uytterhoeven writes: > The test for double-aligned members in dix_valuator_alloc() currently > depends on "if !defined(__i386__) && !defined(__sh__)". This covers > m68k, where it fails. > > According to the comment, the test should be limited to 64-bit

[PATCH] test/input: Replace negative architecture test by test for 64-bit

The test for double-aligned members in dix_valuator_alloc() currently depends on "if !defined(__i386__) && !defined(__sh__)". This covers m68k, where it fails. According to the comment, the test should be limited to 64-bit platforms only. Hence check if sizeof(long) == 8 inste

Re: Need a hand to test fdutils

Le jeudi 11 août 2011 09:15:14, Petr Stehlik a écrit : > on Atari it used to be popular (25 years ago) to use 10 or 11 sectors > per track (instead of standard 9) and up to 86 tracks (~ 968 kB on SD > floppy). If this is what superformat does then yes, it might make sense > (sort of :-) It can do

Re: Need a hand to test fdutils

Andreas Schwab píše v St 10. 08. 2011 v 23:21 +0200: > Matteo Cypriani writes: > > > We have two very old bugs about superformat (from the fdutils package) not > > working on sparc and m68k architectures. > > Does it actually make sense on any non-PC hardware? on Atari it used to be popular (2

Re: Need a hand to test fdutils

Le mercredi 10 août 2011 23:21:52, Andreas Schwab a écrit : > Matteo Cypriani writes: > > We have two very old bugs about superformat (from the fdutils package) > > not working on sparc and m68k architectures. > > Does it actually make sense on any non-PC hardware? Why not? Once upon a time, it

Re: Need a hand to test fdutils

Matteo Cypriani writes: > We have two very old bugs about superformat (from the fdutils package) not > working on sparc and m68k architectures. Does it actually make sense on any non-PC hardware? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756

Re: Need a hand to test fdutils

Matteo Cypriani dixit: >the bugs with a recent version of fdutils (the last one if possible, which is >5.5-20060227-5). While I don’t have the hardware, I’ll compile and upload that version of fdutils now. I hope one of the porters can then try it out and come back to you. bye, //mirabilos --

Need a hand to test fdutils

have access to this hardware, I'm looking for people to reproduce the bugs with a recent version of fdutils (the last one if possible, which is 5.5-20060227-5). The test is very simple: just install the fdutils package, find a floppy out there, try to format it with superformat /dev/fd0, and r

Re: test suites, was Re: status report (intermediate)

On Sat, Oct 30, 2010 at 16:50, Finn Thain wrote: > I imagine that pressure for faster turn-around might cause a release > architecture (like hppa) to disable them, but this would not apply to us(?) JFYI, hppa was dropped, cfr. Debian Project News 2010-10-04 and http://lists.debian.org/debian-deve

Re: test suites

Finn Thain dixit: >looks at the results. But if m68k build logs were (once again) made >available at then there would be an argument >for enabling tests. (Though perhaps it is best if some build machines skip Yes, but they are put there by a buildd, and the buildds

test suites, was Re: status report (intermediate)

Thanks for the update. This is great progress. I appreciate all your effort! Regarding test suites; you are right that they are pointless if no-one looks at the results. But if m68k build logs were (once again) made available at <http://buildd.debian.org/> then there would be an argumen

RE: Test & Keep an Apple Apple iPad! - Details Inside

If you been kicking around the idea of getting an iPad here is something to take advantage of. The ipad is flying off the shelf and apple is having trouble keeping up with demand. And here is your chance to get one for free! They are now looking for feedback from users to begin updating firmware

Re: test

tested! This address is used to send SPAM to mailing lists. Google it. Damned SPAMMERs. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.neb.4.64.1003181758070.2

Re: test

tested! 2010/3/18 Gabrielle Hemphill : > test > > > -- > To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/925fecc31003180731j64bedc

test

test -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/925fecc31003180731j64bedc02t64defdd53c02d...@mail.gmail.com

Re: 68LC040 test program, was: list of elligible computers to debian-68k

pu before which I did but forgot I did. Its socketed unlike the books. > > No command line arguments are needed. No initrd is needed either since it > uses an initramfs. The test program runs upon boot, and no interaction is > necessary (or possible). > > It quickly detects an FPU

68LC040 test program, was: list of elligible computers to debian-68k

needed. No initrd is needed either since it uses an initramfs. The test program runs upon boot, and no interaction is necessary (or possible). It quickly detects an FPU emulation issue on my LC 475 (68LC040 mask set 2E23G). Whereas, even after 10 minutes or so, no problem was detected with m

Re: D-I Beta 3 - release update - please test

ed updates in debian-cd have been made and successful builds for all types of CD images are now available. A fair amount of changes were needed, so please test CD-based installs. > All this does mean that the current lowmem levels need serious review > for all architectures. The good news i

Re: help with an upstream test suite problem?

On Thu, 2005-11-24 at 09:42 +1100, Finn Thain wrote: > FIX_ENDIAN_INT32_INPLACE is inside the ifdef, and it is used by > testFixEndian() in endian.cpp, which is why the actual = 0x12345678, and > not 0x78563412. I'm so blind, thanks for that. -- bye, pabs http://wiki.debian.org/PaulWise si

Re: help with an upstream test suite problem?

On Wed, 23 Nov 2005, Paul Wise wrote: > On Thu, 2005-11-24 at 00:21 +1100, Finn Thain wrote: > > > A quick look at the rest of the code shows that util.h tests > > #ifndef __BIG_ENDIAN__ > > which probably doesn't work because it needs the right header. > > True, but I don't think that is rele

Re: help with an upstream test suite problem?

On Thu, 2005-11-24 at 00:21 +1100, Finn Thain wrote: > A quick look at the rest of the code shows that util.h tests > #ifndef __BIG_ENDIAN__ > which probably doesn't work because it needs the right header. True, but I don't think that is relevant to SWAP_ENDIAN_INT32 because it is outside that #i

Re: help with an upstream test suite problem?

ote: > Hi, > > I recently enabled my upstream's cppunit test suite in an upload to > experimental and the endianess test failed on m68k. The test is > basically like so: > > #define SWAP_ENDIAN_INT32(x) ( \ > (((x)&0xFF00) >> 24) | \ > (((x

help with an upstream test suite problem?

Hi, I recently enabled my upstream's cppunit test suite in an upload to experimental and the endianess test failed on m68k. The test is basically like so: #define SWAP_ENDIAN_INT32(x) ( \ (((x)&0xFF00) >> 24) | \ (((x)&0x00FF) >> 8) | \ (((x)&

Please help test new atari-bootstrap

Roman Hodek has agreed to allow me to help co-maintain the atari-bootstrap package. Please test the following bootstrap executable <http://people.debian.org/~smarenka/d-i/bootloaders/atari/bootstra.prg>. It would be nice to know that the program works, especially on CT60, CT

Re: [EMAIL PROTECTED]: Re: mpfr 2.0.3: bugfix for test suite]

On Wed, 2004-10-27 at 20:17, Michael Fedrowitz wrote: > On Wed, 2004-10-27 at 12:56 -0400, Steve M. Robbins wrote: > > The M68k buildd machine fails the test suite (see below for log > > URL) and it appears that the underlying problem is that the machine > > doesn't suppo

Re: [EMAIL PROTECTED]: Re: mpfr 2.0.3: bugfix for test suite]

On Wed, 2004-10-27 at 12:56 -0400, Steve M. Robbins wrote: Hi, > The M68k buildd machine fails the test suite (see below for log > URL) and it appears that the underlying problem is that the machine > doesn't support IEEE-754 floating point. This might be the old excess pre

[vincent@vinc17.org: Re: mpfr 2.0.3: bugfix for test suite]

Hello folks, I recently uploaded package mpfr (multiple precision floating point), which runs a test suite after building. The M68k buildd machine fails the test suite (see below for log URL) and it appears that the underlying problem is that the machine doesn't support IEEE-754 floating

Re: m68k gcc-3.3 __fixunsdfdi problem (Re: Bug#278135: gawk: FTBFS on m68k: clobber.awk test fails with "internal error")

by this bug? Regards, Fumitoshi UKAI > Fumitoshi UKAI writes: > > clone 278135 -1 > > reassign -1 gcc-3.3 > > retitle -1 gcc-3.3: __fixunsdfdi problem on m68k > > severity -1 critical > > retitle 278135 gawk: FTBFS on m68k: clobber.awk test fails with "internal

Re: m68k gcc-3.3 __fixunsdfdi problem (Re: Bug#278135: gawk: FTBFS on m68k: clobber.awk test fails with "internal error")

e 278135 -1 > reassign -1 gcc-3.3 > retitle -1 gcc-3.3: __fixunsdfdi problem on m68k > severity -1 critical > retitle 278135 gawk: FTBFS on m68k: clobber.awk test fails with "internal > error" with gcc-3.3 > thanks > > I confirm RC Bug#278135 on crest.debian.or

m68k gcc-3.3 __fixunsdfdi problem (Re: Bug#278135: gawk: FTBFS on m68k: clobber.awk test fails with "internal error")

clone 278135 -1 reassign -1 gcc-3.3 retitle -1 gcc-3.3: __fixunsdfdi problem on m68k severity -1 critical retitle 278135 gawk: FTBFS on m68k: clobber.awk test fails with "internal error" with gcc-3.3 thanks I confirm RC Bug#278135 on crest.debian.org's dchroot unstable, so I tra

Re: test 2.6.8.1 on AMiga

On Tue, 31 Aug 2004, Storm66 wrote: > If the init.d/keymaps.sh is inhibited (as said by Geert) it works with > an QWERTY lay out, but I do not know how to load (and what) to install > a "better" keyboard. `loadkeys fr'? (don't know how the Amiga keymaps are called, at least the French PC layout sh

test 2.6.8.1 on AMiga

Hello, If the init.d/keymaps.sh is inhibited (as said by Geert) it works with an QWERTY lay out, but I do not know how to load (and what) to install a "better" keyboard. The system seems more "responsive" with the 2.6 kernel than with the 2.4 one, but I think that more memory is used as free memor

Re: Test 2.6.8.1 compil on AMiga

On Wed, 18 Aug 2004, Storm66 wrote: > Or is it a problem with "as" as I use recent packages for binutils : > > as --version > GNU assembler 2.15 > > Is it a bug in the "as" in its 2.15 version ? Looks like it. I could assemble a file containing only bclr #7,-2134913024+0--2147483648 movew

Test 2.6.8.1 compil on AMiga

Hello, I download and try to compile, but the result is not so good : AS arch/m68k/kernel/head.o arch/m68k/kernel/head.S: Assembler messages: arch/m68k/kernel/head.S:2865: Error: bad expression arch/m68k/kernel/head.S:2866: Err

Re: Please Help Test debian-installer rc1 on m68k

> > Okay, so do you think that section 5 is the place for that or section 2 > (installation media)? > my 2c - Section 5 -- --- David Howe www.qednet.biz davidATqednet.biz ---

Re: Please Help Test debian-installer rc1 on m68k

On Wed, Aug 11, 2004 at 09:33:28AM +1000, david howe wrote: > hi all > > The Installation manual (sect 5.1) describes booting from macos, but > unless you rtfm completely, I could imagine a newbie thinking it is > possible to boot from a cd (there is a sentence that explains the only > machine to

Re: Please Help Test debian-installer rc1 on m68k

hi all The Installation manual (sect 5.1) describes booting from macos, but unless you rtfm completely, I could imagine a newbie thinking it is possible to boot from a cd (there is a sentence that explains the only machine to boot from cd is a BVME6000 - whatever that is:) I think it might be clea

Re: Please Help Test debian-installer rc1 on m68k

On Wed, Aug 11, 2004 at 08:49:18AM +1000, david howe wrote: > A quick perusal of the cd reveals some newbie type problems.. > > how do you install onto a mac without the penguin booter (which doesnt > appear to be included)? Is there a kernel file? The included > documentation seems to suggest the

Re: Please Help Test debian-installer rc1 on m68k

Marenka wrote: > Please help test debian-installer rc1 for m68k. This release supports > amiga, atari, and mac. You probably need 32MB RAM and 200MB disk. > > <http://www.debian.org/devel/debian-installer/>. > > Please report both successful and unsuccessful attempts to

Please Help Test debian-installer rc1 on m68k

Please help test debian-installer rc1 for m68k. This release supports amiga, atari, and mac. You probably need 32MB RAM and 200MB disk. <http://www.debian.org/devel/debian-installer/>. Please report both successful and unsuccessful attempts to [EMAIL PROTECTED] I'd appreciate it if yo

Re: Call for m68k/atari debian-installer test [update]

I am now building atari with the regular daily builds and it will release with d-i rc1. After some non-atari-specific breakage, I think we have good images at . The iso's are at

Re: Call for m68k/atari debian-installer test

On Thu, May 27, 2004 at 10:10:01AM +0200, Szymanski, Frank-Peter (DMT) wrote: > Well, on my machine it does not finish. > Configuring APT sources Could you please try the images from ? I'm now building atari with the regular dailies. U

RE: Call for m68k/atari debian-installer test

> > I must always mount the partition on target myself, but now > > I can use hda8 ! The new installer has finished his work. > So I guess that means we need more than 150MB(?) to install base? > Thanks, that's great news! Well, on my machine it does not finish. These are the results on console

Re: Call for m68k/atari debian-installer test

On Thu, May 20, 2004 at 09:52:16AM +0200, Didier MEQUIGNON wrote: > Errors were encountered while processing > > man-db > > umount /target/dev/pts: No such file or directory > umount /target/dev/shm: No such file or directory may be problems with kernel configuration, those most be enabled whe

Re: Call for m68k/atari debian-installer test

On Thu, May 20, 2004 at 12:10:45PM +0200, Didier MEQUIGNON wrote: Because I have found no free bytes on the zip cartridge, I have tried again on an old MiNT partition ext2 /hda8 1GB size on the IDE drive. I must always mount the partition on target myself, but now I can use hda8 ! The new insta

Re: Call for m68k/atari debian-installer test

On Thu, May 20, 2004 at 12:10:45PM +0200, Didier MEQUIGNON wrote: > Because I have found no free bytes on the zip cartridge, I have tried > again on an old MiNT partition ext2 /hda8 1GB size on the IDE drive. > I must always mount the partition on target myself, but now I can use > hda8 ! The ne

Re: Call for m68k/atari debian-installer test

On Tue, May 18, 2004 at 08:47:39PM +0200, Didier MEQUIGNON wrote: >>Unforunately, it turns out that I didn't pay enough attention to the >>way the "old" partition formatter/mounter (partconf) works. It uses >>parted to list out partitions. In other words, both the new and the old > >>code that

Re: Call for m68k/atari debian-installer test

On Tue, May 18, 2004 at 08:47:39PM +0200, Didier MEQUIGNON wrote: >>Unforunately, it turns out that I didn't pay enough attention to the >>way the "old" partition formatter/mounter (partconf) works. It uses >>parted to list out partitions. In other words, both the new and the old > >>code that

Re: Call for m68k/atari debian-installer test

On Tue, May 18, 2004 at 08:47:39PM +0200, Didier MEQUIGNON wrote: >>Unforunately, it turns out that I didn't pay enough attention to the >>way the "old" partition formatter/mounter (partconf) works. It uses >>parted to list out partitions. In other words, both the new and the old > >>code that

Re: Call for m68k/atari debian-installer test

On Tue, May 18, 2004 at 08:47:39PM +0200, Didier MEQUIGNON wrote: > >>Unforunately, it turns out that I didn't pay enough attention to the > >>way the "old" partition formatter/mounter (partconf) works. It uses > >>parted to list out partitions. In other words, both the new and the old > > > >>code

  1   2   >