Re: Coldfire Boards

Hi, On Mon, 1 Sep 2008, Kurt Mahan wrote: > You are using an old BSP. The new BSP I released for these boards uses > uBoot, not dBug. I found m547x_8x_evb_20080811-final-ltib.iso, but it doesn't mention the M5474LITE anywhere. Is it still supported? I don't have the BDM module right now, so I'

Re: Coldfire Boards

Hi, On Mon, 1 Sep 2008, Kurt Mahan wrote: > It appears you are using M547x/M548x boards. Could you be more specific? That's the version output: ColdFire MCF547X on the M5474LITE Firmware v4a.1a.1d (Built on Dec 6 2004 11:56:58) Copyright 1995-2004 Freescale Semiconductor, Inc. Someone else n

Re: Coldfire Boards

Hi, On Monday 1. September 2008, Michael Casadevall wrote: > I'm just curious on who got what. I know Stephen gave me his board, > but I'm curious to know which boards went where. > > Anyway, here are a couple of my bootstrapping notes. Since I just got the board, I'm still stuck at dBUG prompt,

Re: nfblock vs udev

Hi, On Sat, 30 Aug 2008, Petr Stehlík wrote: > In other words: your kernel works OK with udev. Sounds like Stephen > doesn't have the latest nfblock patch? Or maybe his gcc-4.2 compiled it > differently than compiler you've used? I tried it now with the debian kernel .config and the difference i

Re: crosscompiler for etch or hardy (was Re: nfblock vs udev)

Hi, On Friday 29. August 2008, Geert Uytterhoeven wrote: > Basically I used Roman's instructions > (http://www.xs4all.nl/~zippel/crosscc/crosscc.README) I've updated this file for gcc-4.3 and latest unstable. I just reinstalled the cross compiler on my laptop, so let me know if something is mis

Re: nfblock vs udev

Hi, On Friday 29. August 2008, Petr Stehlík wrote: > I am hoping for a simple bug in the implementation of nfblock. Though > Roman surely tested it and I suppose it works for him unless it's called > from udev so it's a bit mysterious. But I believe a bunch of printk > calls here and there will r

Re: kernel

Hi, On Tue, 1 Jul 2008, Petr Stehlik wrote: > You obviously never tried to explain somebody how to copy data onto the ARAnyM > disk from host side, otherwise you'd find it useful. You obviously have never tried this under Linux... :-( > Let's finish this thread here. And thanks for your opinion

Re: kernel

Hi, On Tue, 1 Jul 2008, Petr Stehlik wrote: > The installer sees the existing partitions and can use them, correct? You > don't have to repartition an existing disk partitions in order to be able to > install Linux. Or am I wrong? It's possible, but where is the value in that? Why do you want to

Re: kernel

Hi, On Tue, 1 Jul 2008, Petr Stehlik wrote: > > No, it wouldn't. You can easily mount filesystem images as complete block > > devices under Linux/Aranym > > Nope. If you partition the disk (image) on Atari then you can't mount it > easily on the host (unless you patch host operating system to re

Re: kernel

Hi, On Tue, 1 Jul 2008, Petr Stehlik wrote: > Why does something under Linux need to know about the simulated PTBL? That's > what I am missing. The host partitions (or partition image files) will appear > as /dev/sd[a-g]1 under Linux-m68k automagically. Linux-m68k recognizes the > simulated PTBL

Re: kernel

Hi, On Mon, 30 Jun 2008, Petr Stehlik wrote: > that was evident. Since most linux based distros don't include Atari > PTBL support in their kernels this won't help much, unfortunately. > Avoiding the PTBL incompatibilities by accessing the partitions directly > is still the better solution, IMHO.

Re: kernel

Hi, On Mon, 30 Jun 2008, Petr Stehlik wrote: > Roman, what if the nfblock had major_num 8 by default? That value is reserved, so I'm very reluctant to use it as default, but you can change it via boot command line. In either case this won't change anything about the problem, it will only chang

Re: kernel

Hi, On Mon, 30 Jun 2008, Petr Stehlik wrote: > > How exactly does one configure nfblock? What's the aranym config or > > command line needed to make it work? > > http://wiki.aranym.org/manual#single_partition_mount The key sentence is 'Plain TOS doesn't support it (yet), unfortunately.', the s

Re: kernel

Hi, On Mon, 30 Jun 2008, Petr Stehlik wrote: > we've discussed this already in PM - the [PARTITION] (nfblock) was > invented to _free_ users from creating partitions so it's ridiculous to > to say that it has a limited value because you can't create partitions > on it :-) It's not just partition

Re: kernel

Hi, On Mon, 30 Jun 2008, Stephen R Marenka wrote: > How exactly does one configure nfblock? What's the aranym config or > command line needed to make it work? There is no extra configuration needed. All [IDE?] and [PARTITION?] entries are exported this way, although the latter have only very li

Re: kernel

Hi, On Fri, 27 Jun 2008, Stephen R Marenka wrote: > I don't really know how to configure nfblock. It dies whether I use > console=nfcon or console=tty. > > | INIT: version 2.86 booting > | [5.83] printk: 181 messages suppressed. > | [5.83] ide_release_lock: bug > | Starting the h

Re: m68k Developers Meeting

Hi, On Mon, 23 Jun 2008, Christian T. Steigies wrote: > The thing I need to know fairly soon, at which dates would people be > interested in having a developer meeting. Pretty much anything should work for me in that time frame. :) bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] wit

Re: Aranym Setup

Hi, On Fri, 20 Jun 2008, Geert Uytterhoeven wrote: > On Fri, 20 Jun 2008, Roman Zippel wrote: > > On Tuesday 17. June 2008, Stephen R Marenka wrote: > > > I've put most of my aranym setup notes at > > > <http://wiki.debian.org/Aranym>. > > > >

Re: Aranym Setup

Hi, On Tuesday 17. June 2008, Stephen R Marenka wrote: > I've put most of my aranym setup notes at > . > > Please take a look and make some comments or build some buildds. :) A few comments about the network setup: First, aratapif doesn't have to be called manually

Re: Serial Console Support in Kernel

Hi, On Thu, 12 Jun 2008, Geert Uytterhoeven wrote: > > Oh, amiga-lilo is actually working? Last I heard was that it had some issues > > and development was stuck. > > I think so. IIRC Roman Zippel fixed '060 support. Yes, it works fine on 060. The only bigger issue

Re: ilmbase

Hi, On Fri, 25 Apr 2008, Michael Schmitz wrote: > objdump on testBitPatterns.o gives: > > > 005c > <_ZN63_GLOBAL__N_.._.._HalfTest_testBitPatterns.cpp__2E91A93413floatPosQNan1Ev>: > 5c: 4e56 linkw %fp,#0 > 60: f23c 4400 7fff fmoves #nan,%fp0 > 66: > 68

Re: IDE disks in Amigas

Hi, On Fri, 4 Apr 2008, Ingo Juergensmann wrote: > I think I better remove that SCSI disk for now... ;) > Is there a better SCSI driver in newer kernels? I took a kernel tarball > from one of my other Amigas to reduce built time, but when 2.6.24.x gives > me a working SCSI, it's no problem to bui

Re: FOSDEM thoughts

Hi, On Tue, 4 Mar 2008, Kurt Mahan wrote: > With respect to Floating Point there are differences within the Coldfire > V4 family. The M547x/M548x have the FPU you have been discussing. The > M5445x doesn't have any FPU hardware and requires everything to be > compiled with softfloat. Linux/m68

Re: FOSDEM thoughts

Hi, On Tuesday 4. March 2008, Wouter Verhelst wrote: > A hybrid port would just emit two opcodes in such a case, of course. > This will indeed degrade performance slightly. The incompabilities are all over the place, we would be basically restricted to a very basic instruction set and due to th

Re: debootstrapping m68k-coldfire

Hi, On Tuesday 4. March 2008, Wouter Verhelst wrote: > Anyway, the problem isn't that bootstrapping coldfire is hard; I can do > that myself if needs be, and we'd have a working port within a few > months[1]. The problem is that adding another port isn't going to be > accepted by FTP masters: I d

Re: FOSDEM thoughts

Hi, On Tue, 26 Feb 2008, Finn Thain wrote: > On Mon, 25 Feb 2008, Christian T. Steigies wrote: > > > > Getting the coldfire port working would be nice, yes... I believe that > > > would bring in fresh blood and a general boost for debian-68k/cf... > > > > We had a discussion with Aurelien, Gee

Re: Xorg on m68k

Hi, On Thu, 21 Feb 2008, Geert Uytterhoeven wrote: > I tried your suggestion yesterday evening, but it didn't seem to work > for me. E.g. when trying to ping .134, I get > > | $ ping 192.168.3.134 > | PING 192.168.3.134 (192.168.3.134) 56(84) bytes of data. > | ping: sendmsg: Operation not permi

Re: Xorg on m68k

Hi, On Wed, 20 Feb 2008, Petr Stehlik wrote: > > > [ETH0] > > > Type = ptp > > > Tunnel = tap0 > > > HostIP = 192.168.3.133 > > > AtariIP = 192.168.3.134 > > > Netmask = 255.255.255.252 > > > > > > IMO aratapif shouldn't be necessary (I use pretty much the same setup > > > with > > > qemu), bu

Re: Xorg on m68k

Hi, On Wed, 20 Feb 2008, Christian T. Steigies wrote: > > IMO aratapif shouldn't be necessary (I use pretty much the same setup with > > qemu), but aranym calls it anyway and complains if it fails. > > Does linux-m68k work with qemu? I read that coldfire is supported by qemu, > though I did not

Re: Xorg on m68k

Hi, On Wed, 20 Feb 2008, Petr Stehlik wrote: > Geert Uytterhoeven wrote: > > | Type = bridge > > | Tunnel = tap0 > > bridge + tap0 = uml_utilities and no aratapif is necessary. Here is my setup, which is specific to Debian: First the uml-utilities package is needed and then I have this entry i

Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem

Hi, On Thursday 3. January 2008, Michael Schmitz wrote: > Slightly less hackish implementation of that hack attached. This (on top > of my max_dma_address patch before) does solve the ramdisk related atafb > problems without resorting to artificial RAM limits. Stephen, please try > this patch. Y

Re: aranym vs atafb

Hi, On Tuesday 1. January 2008, Michael Schmitz wrote: > I'm getting a bit confused - the good old mach_max_dma_address variable > does not seem to get used in the recent kernels anymore at all. Could a mm > expert please unravel this mystery? It suffered from bit rot, as atari was the only real

Re: [buildd] Machines upgraded

Hi, On Tue, 18 Dec 2007, Ingo Juergensmann wrote: > On Mon, Dec 17, 2007 at 11:27:42PM +0100, Roman Zippel wrote: > > > > I've upgraded the following machines lately to kernel 2.6.23-m68k and > > > etch-m68k: > > You might want to test 2.6.22 as well. The new

Re: [buildd] Machines upgraded

Hi, On Tue, 18 Dec 2007, Finn Thain wrote: > Is there a tunable that might reduce the number of context switches? Only as a debug option, which would increase the cost even further. > (I'm > guessing that your stats reflect more switches, not more expensive > switching.) No, it's all the 64b

Re: [buildd] Machines upgraded

Hi, On Mon, 17 Dec 2007, Ingo Juergensmann wrote: > I've upgraded the following machines lately to kernel 2.6.23-m68k and > etch-m68k: You might want to test 2.6.22 as well. The new scheduler hasn't exactly been an improvement for us, here are some lmbench numbers: Context switching - times i

Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2

Hi, On Mon, 3 Dec 2007, Joseph S. Myers wrote: > __kernel_read_tp is a symbol defined in the vDSO, the glibc resolver needs > to resolve it shortly after startup and store the function pointer in a > variable in glibc. Applications do not know the address of the vDSO or > how to resolve symbo

Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2

Hi, On Fri, 30 Nov 2007, Joseph S. Myers wrote: > Kernel helpers > -- > > This TLS ABI defines a function __m68k_read_tp, provided by libc. > This returns the thread pointer in register a0 (not d0) and may > clobber other call-clobbered registers. The compiler will generate > calls

Re: Draft TLS/NPTL ABI for m68k and ColdFire, version 0.2

Hi, On Fri, 30 Nov 2007, Brad Boyer wrote: > I presume ColdFire is also missing CAS2. Do we need a 64 bit cmpxchg > equivalent as well? cas2 is an emulated instruction on 68060, so we might want to avoid direct usage on m68k as well. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]

Re: crest.d.o and m68k.d.o

Hi, On Sun, 18 Nov 2007, Geert Uytterhoeven wrote: > Roman Zippel did write a mkaffs tool a long time ago, which I use once. > > But Debian doesn't have it, I don't seem to have it installed anymore, and > I cannot find it with Google (all I find is emails mentioning it

Re: gcc 4.3 and -m68020

Hi, On Fri, 14 Sep 2007, Finn Thain wrote: > > On Thu, 13 Sep 2007, Rolf Anders wrote: > > > With option -v gcc should output all the command lines of programs it > > starts. > > Thanks. > > That shows that -m68020 is being passed to gas. I'm guessing that this is > a side-effect of the col

Re: Atari disk (was: Re: meeting?)

Hi, On Thu, 9 Aug 2007, Geert Uytterhoeven wrote: > Speaking about Atari disks, is > http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-patches-2.6/POSTPONED/POSTPONED/134-atari-fat.diff > still needed? IIRC this patch used to be a little more invasive, now it's relatively simple, so IMO we could j

Re: [PATCH/RFC 0/2] Zorro modalias support

Hi, On Mon, 11 Jun 2007, Geert Uytterhoeven wrote: > Most other `system bus' hardware doesn't have to be probed (in the ISA > bang-a-few-ports-and-we'll-see sense) on m68k. We use > {amiga,atari,mac}_hw_present to find out if something exists. > > So we could easily have in arch/*/config.c: > >

Re: [PATCH/RFC 0/2] Zorro modalias support

Hi, On Sun, 10 Jun 2007, Geert Uytterhoeven wrote: > I've just upgraded my poor old A4000 (which had been in in storage for 2.5 > years) from Debian woody to sarge, but hotplug and udev break havoc on it: > - The presence of hotplug causes an out-of-memory during boot-up (only > 12 MiB of F

Re: TLS support [was Re: Unidentified subject!]

Hi, On Mon, 21 May 2007, Brad Boyer wrote: > I'd like to avoid following in the footsteps of the i386 style support > particularly because it does require more extensive kernel support than > most of the other architectures. I'm still looking over the documentation > and the implementation detail

Re: gcc-4.1.2 ffi.c

Hi, On Sun, 20 May 2007, Stephen R Marenka wrote: > Looking at 425011, I found that the following patch will allow gcc-4.1.2 > to compile. Does it make sense? (No idea, I was just looking at what > other archs did.) Almost. :) Current gcc (4.3) already has the fix, so another backport could sol

Re: Future of m68k - Etch and beyond

Hi, On Tue, 27 Feb 2007, Ingo Juergensmann wrote: > I agree with you that dpkg and other tools are dog slow. I got the feeling > that especially scripts are very slow on m68k (interpreted languages). > The performance difference between AmigaOS and Linux is enourmous, even when > you consider th

Re: Future of m68k - Etch and beyond

Hi, On Mon, 26 Feb 2007, Stephen R Marenka wrote: > To me it seems clear that compiling all of kde and gnome to run on > traditional > m68k hardware is a waste of time and cycles. However, how do we carve up > the dependency tree so that we can support what we want without killing > ourselves?

Re: Future of m68k - Etch and beyond

Hi, On Mon, 26 Feb 2007, Wouter Verhelst wrote: > This is a confusion in wording on my part, I'm afraid. When I say > "classic m68k", I mean "non-coldfire m68k processors supported by > Linux", i.e., at least the 68020 :) Well, you seem to a have broader definition of "near-strict subset" than

Re: Future of m68k - Etch and beyond

Hi, On Mon, 26 Feb 2007, Wouter Verhelst wrote: > > It's probably not impossible, but I highly question whether it's really > > desirable. The instructions sets are already quite different > > This is not true. The ColdFire V4e instruction set is a near-strict > subset of the m68k one. The only

Re: Future of m68k - Etch and beyond

Hi, On Sat, 24 Feb 2007, Wouter Verhelst wrote: > At this point, though, I'm still convinced that it's possible to create > a port which will work on both coldfire and "classic" m68k; and with a > glibc that has TLS support (which we still need as well), it doesn't > even have to slow down things

Re: Future of m68k - Etch and beyond

Hi, On Fri, 23 Feb 2007, Ingo Juergensmann wrote: > > > How will the m68k cope with the glibc problem for Lenny in the future? > > > How is the Coldfire port going on? > > I think Aranym is a better prospect than ColdFire. Without revisiting the > > ISA differences etc, Aranym wins on availabil

Re: Future of m68k - Etch and beyond

Hi, On Fri, 23 Feb 2007, Ingo Juergensmann wrote: > My question is now: > What is the *exact* plan for m68k for Etch and beyond? IMO as long as there are few people who have the power to veto m68k out of existence, I don't see much further hope for m68k within Debian. The absolutely worst mist

Re: Erlang in Debian on m68k architecture

Hi, On Thu, 25 Jan 2007, Sergei Golovan wrote: > Warning: if you use the -malign-int switch, GCC will align struc- > tures containing the above types differently than most published > application binary interface specifications for the m68k. > > Can the issue with

Re: Erlang in Debian on m68k architecture

Hi, On Thu, 25 Jan 2007, Sergei Golovan wrote: > After some research, we've found that erlang relies on the alignment > of some global variable. The following patch fixes it: > -- > --- erlang-11.b.2.orig/erts/emulator/beam/binary.c

Re: running iceweasel on m68k

Hi, On Tue, 19 Dec 2006, Bill Allombert wrote: > Hello Debian m68k porters, > > Has anyone managed to get icedove and iceweasel to start on real > m68k hardware ? > > This question has something to do with epiphany-browser FTBFS. Well, once 402011 is fixed, epiphany-browser will work. Unfortu

Re: Buildd

Hi, On Sun, 17 Dec 2006, Michael Schmitz wrote: > > > Do we have a new regression here? binutils, or gcc? > > > > It's unlikely a toolchain problem, please retry on a different machine > > (preferably which isn't overclocked). > > OK, shooting for slow now: the build is running on q650. I also

Re: Buildd

Hi, On Sat, 16 Dec 2006, Michael Schmitz wrote: > > > I retried perl on another CT60 and it failed the same way. What machine > > > did you build on? > > > > Also a 060, but at 50MHz, although it fails a bit later with some weird > > build error, but I don't get the test failures. > > Do we have

Re: [buildd] distcc candidates

Hi, On Thu, 14 Dec 2006, Bill Allombert wrote: > On Sat, Dec 09, 2006 at 06:48:20PM -0600, Stephen R Marenka wrote: > > Would someone please try ace and openvrml on a distcc machine? > > Both done, and uploaded. > > Maybe I could update the crosscompiler to gcc-4.1.1-21 and build > openscenegr

Re: Buildd

Hi, On Fri, 15 Dec 2006, Michael Schmitz wrote: > I retried perl on another CT60 and it failed the same way. What machine > did you build on? Also a 060, but at 50MHz, although it fails a bit later with some weird build error, but I don't get the test failures. bye, Roman -- To UNSUBSCRIBE,

Re: Buildd

Hi, On Mon, 11 Dec 2006, Michael Schmitz wrote: > I've forced them back to needs-build (no idea why fportfolio wasn't; the > dep-wait was on the current fbasics versiion which was marked as > installed). ldapvi is another one, the dependency changed and is available now. bye, Roman -- To UNS

Re: Buildd

Hi, On Mon, 11 Dec 2006, Michael Schmitz wrote: > > I'm a little worried about hobbes, it now failed a few packages I can't > > anything wrong with, e.g. I checked nzb, tar and mailutils, which build > > fine here and from the log I can't find anything wrong with perl or > > python2.5 either... >

Re: Buildd

Hi, On Mon, 11 Dec 2006, Michael Schmitz wrote: > > I'm a little worried about hobbes, it now failed a few packages I can't > > anything wrong with, e.g. I checked nzb, tar and mailutils, which build > > fine here and from the log I can't find anything wrong with perl or > > python2.5 either... >

Re: Buildd

Hi, I'm a little worried about hobbes, it now failed a few packages I can't anything wrong with, e.g. I checked nzb, tar and mailutils, which build fine here and from the log I can't find anything wrong with perl or python2.5 either... A few other packages can be given back: fbasics, gnome-pyt

Re: [buildd] - Hardinfo

Hi, On Tue, 5 Dec 2006, Agney Lopes Roth Ferraz wrote: > on hardinfo 0.4-2 the upstream author removed 68k support, but after > some requests we work together and add this support. But buildd is still > ignoring my package. how can I proced to remove not-for-us from m68k > buildd ? It's still fa

Re: Buildd

Hi, On Thu, 30 Nov 2006, Stephen R Marenka wrote: > > These could maybe use some longer timeouts/a big machine: > > - ace > > - openvrml > > This just timed out on akire after 3000. Try it on a machine with distcc? bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "

Re: Buildd

Hi, Another one to retry with new gcc: runit (works here) bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Buildd

Hi, I've went to through some of failed packages and they are a few which could/should be retried. These could maybe use some longer timeouts/a big machine: - ace - openvrml - epiphany-browser - missingh (won't benefit much from distcc due to gch6) kiivi specific problem?: - r-base - zope3 de

Re: Buildd

Hi, On Mon, 27 Nov 2006, Michael Schmitz wrote: > > I would say that it would get updated at dinstall. Hmmm, it's not in > > incoming and it's not in the archive. > > Makes me wonder what happened with the upload. I'll have to set up a scp > upload queue somewhere ... Now that -20 is installed,

Re: Buildd

Hi, On Wed, 22 Nov 2006, Michael Schmitz wrote: > On the upside: gcc-4.1 is finally building. May take up to five days to > finish. I'll set up a watchdog cronjob touching the log every hour to make > sure it's not hit by a timeout. gcc-4.1 is still stuck in Failed?! bye, Roman -- To UNSUBSC

Re: bug status

Hi, On Mon, 6 Nov 2006, Stephen R Marenka wrote: > > emacs21: somehow got magically fixed, just retry with new gcc > > still failing on the buildds The weird build system had me confused there. Anyway, I fixed one gcc bug, but now it's failing a bit later and it's rather hard to get something

Re: bug status

Hi, On Mon, 6 Nov 2006, Stephen R Marenka wrote: > > > There is a new binutils, so binutils/insight should compile now. > > binutils built. > insight fails with: warning: argument 'info' might be clobbered by 'longjmp' > or > 'vfork' This one should be fixed with -20, so it would be good to re

Re: gcc-4.1 -19

Hi, On Thu, 2 Nov 2006, Stephen R Marenka wrote: > Someone with a burly machine want to retry gcc-4.1? > > It's not clear to me why it failed from the buildd log, but all the > other archs built it fine. There will be soon a -20, so it's not worth the effort. bye, Roman -- To UNSUBSCRIBE, e

Re: Why are these Not-For-Us?

Hi, On Tue, 31 Oct 2006, Goswin von Brederlow wrote: > adacontrol No ada on m68k? Nope. > cacao Looks like it needs serious porting work. > cynthiune.appWas Dep-Wait, for what? > edos-debcheck Should work. > liblinux-inotify2-perl Easily portable. > libpam-encfs

[buildd] mlgmp/ocamlcreal

Hi, I think I know now what's wrong with ocamlcreal, I've also rebuilt mlgmp at the same time and it seems the time stamps are a little messed up. If you look in the build log of mlgmp, gmp.mli should be older or as old as gmp.cmi and due to this ocamlreal tries to rebuild it. A rebuild of mlgm

Re: First package build on aranym+distcc+NFS

Hi, On Mon, 30 Oct 2006, Ingo Juergensmann wrote: > > Lets add firefox and perhaps ghc to that. My mac has network problems, > > so using distcc there to build firefox is a no-go. And the amiga just > > decided to crash after building ghc for four days. I am not sure if > > distcc would help ther

Re: [buildd] failed packages

Hi, BTW these two packages are without maintainer, unless someone does a NMU I don't expect much to happen: - gnobog#353853 - python-gnome #394581 bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[buildd] failed packages

Hi, I looked through the packages that only failed on m68k and these are the ones, that should work again: csound gdome2-xslt kaffe chicken synopsis log4cxx yacas vtk xpilot-ng snort glosstex scummvm boost stlport5 stlport5.1 xserver-xorg-video-mga ragel asymptote blender binutils mozilla wxwind

Re: m68k release future

Hi, On Fri, 27 Oct 2006, Anthony Towns wrote: > On Fri, Oct 27, 2006 at 12:47:19PM +0200, Roman Zippel wrote: > > On Fri, 27 Oct 2006, Anthony Towns wrote: > > > Personally, I think m68k would be better served by having a testing-m68k > > > and taking occassional s

Re: m68k release future

Hi, On Fri, 27 Oct 2006, Anthony Towns wrote: > Personally, I think m68k would be better served by having a testing-m68k > and taking occassional snapshots which serve as the supported stable-m68k > release, rather than worrying about something equivalent to etch itself. Why should we do this? A

Re: [buildd] gcc-4.1/crosscc

Hi, On Fri, 27 Oct 2006, Roman Zippel wrote: > IMO gs-gpl might be a good choice, we need a new version anyway to fix > tex problems and it has been built a few times recently, so 6h are to > beat. :) Or if you look for something big: firefox (75h although on crest). :) bye, Roman

Re: [buildd] gcc-4.1/crosscc

Hi, On Fri, 27 Oct 2006, Christian T. Steigies wrote: > I set this on in the user chroot on aahz using my notebook as crosscompiler, > I don't have anything faster currently. It seems to work, I've test-built > two small packages. But since a buildd is running in the background, it is > hard to j

[buildd] gcc-4.1/crosscc

Hi, The new gcc-4.1 is installed, which includes a number of m68k specific fixes, so please upgrade as soon as possible. At http://www.xs4all.nl/~zippel/crosscc/ I also uploaded a package for the crosscc tool, so it can now be easily installed and removed. Once installed it diverts all calls o

Re: bug status

Hi, On Tue, 24 Oct 2006, Stephen R Marenka wrote: > On Fri, Oct 20, 2006 at 01:57:30AM +0200, Roman Zippel wrote: > > > ocamlcreal: somehow ocamldep is broken, a recompile of ocaml did fix > > this here. > > So something must be different. Should I retry ocaml with

Re: [buildd] binutils failure

Hi, On Tue, 24 Oct 2006, Michael Schmitz wrote: > Hi, > > binutils failed on q650 due to undeclared PAGE_SIZE. Ideas, anyone? Upgrade linux-kernel-headers. bye, Roman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ICE on linux-2.6 (2.6.18, official debs)

Hi, On Tue, 24 Oct 2006, Ingo Juergensmann wrote: > It's still a question how to integrate a distcc/crosscc into our existing > buildd environment. I doubt that we want to do this all by manual builds... > ;) It's quite simple to make this transparent using dpkg-divert, then no changes to the

Re: ICE on linux-2.6 (2.6.18, official debs)

Hi, On Tue, 24 Oct 2006, Christian T. Steigies wrote: > > toolchain-source is pretty much obsolete, use the gcc and binutils source > > directly, both contain a README.cross on how to produce a cross compiler. > > Right, this works very well. I did use cross-tool for a while, as described > som

Re: bug status

Hi, On Mon, 23 Oct 2006, Michael Schmitz wrote: > > Scheduling it on a machine with more memory and giving it some time should > > help, it finished here. I've seen a generated file, which was preprocessed > > 5.7MB and even with a cross compiler it takes a few minutes (without > > swapping). >

Re: ICE on linux-2.6 (2.6.18, official debs)

Hi, On Mon, 23 Oct 2006, Goswin von Brederlow wrote: > "Christian T. Steigies" <[EMAIL PROTECTED]> writes: > > > On Fri, Oct 20, 2006 at 08:11:30AM +0200, Goswin von Brederlow wrote: > >> > >> Could someone tell me how the official images were build? > > Same question for linux-2.6.16 (in buil

Re: bug status

Hi, On Mon, 23 Oct 2006, Stephen R Marenka wrote: > > (bug was in libgc), gnuradio-core (no log, but it generates some huge > > None of my buildds seem to be able to handle it. Scheduling it on a machine with more memory and giving it some time should help, it finished here. I've seen a gener

Re: [CRITICAL] Toolchain TLS support

Hi, On Mon, 23 Oct 2006, Geert Uytterhoeven wrote: > > > Which alignment do you mean? 32-bit values aligned on a 2-byte boundary? > > > > Yes, it causes all kind of stupid bugs, which only trigger on m68k... > > But if you change it, how much software that does handle it correctly now will > br

Re: [CRITICAL] Toolchain TLS support

Hi, On Sun, 22 Oct 2006, Geert Uytterhoeven wrote: > On Sun, 22 Oct 2006, Roman Zippel wrote: > > The next big question will be then how we're going to make the transition > > to the TLS support. IMO it would be very benefical, if we could fix our > > ABI at the sam

Re: bug status

Hi, Another update: For the timestep problems I filed a number of bugs or added neccessary patches: - bfbtester: #394565 - gnobog: #353853 - kaptain: #394575 - lyskom-tty-client: #394578 - progsreiserfs: #362032 - python-gnome: #394581 Other bugs: - hula: another alignment bug, #394592 - pyino

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Sun, 22 Oct 2006, Michael Schmitz wrote: > > However I also experimented using a cross-compiler through the use > > of distcc. Results are on debian-68k archives and are positive. > > This would allow packages to build much more quickly. > > The use of distcc (running ./configure and test

Re: [CRITICAL] Toolchain TLS support

Hi, On Sun, 22 Oct 2006, Aurélien GÉRÔME wrote: > If only I had the time... Several people have talked about TLS support > for m68k, but it seems nobody has done it so far. I replied to your > post, because it seems to have been ignored and I felt a bit ashamed > of that. ;) > > Anyway, I will t

Re: buildd machines?

Hi, On Thu, 19 Oct 2006, Brad Boyer wrote: > On this note of buildd capability, does anyone know for sure what the > main bottleneck is on the compiler for m68k? If it's disk-bound, the > 840AV (and 660AV) have the possibility of a big boost in this area in > the future. We currently aren't using

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Fri, 20 Oct 2006, Steve Langasek wrote: > > The m68k porters have been firmly against cross-compiling in the past, > > it's their call on whether this sort of approach is suitable. > > FWIW, it's my understanding he intends to run aranym on these systems, > thereby making this native buil

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote: > Roman Zippel <[EMAIL PROTECTED]> writes: > > >> I do care about it. But I see no particular reason for urgency about > >> the particular bug, and obviously, the m68k team doesn't either. > > >

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Sat, 21 Oct 2006, Anthony Towns wrote: > On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote: > > Assumed m68k would be able to kill (most of) the backlog in time, what would > > prevent m68k from becoming releasable? > > - It didn't sustain the `95%' rate during the last

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote: > > Hmm and here I thought you would care about this package, the way you > > constantly asked about its status... > > I do care about it. But I see no particular reason for urgency about > the particular bug, and obviously, the m68k team doe

Re: m68k not a release arch for etch; status in testing, future plans?

Hi, On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote: > > PS: 4 days and still no response to guile-1.6 patch... > > Maybe you should ask the guile-1.6 maintainer? I'm not responsible > for the package. Hmm and here I thought you would care about this package, the way you constantly asked about

  1   2   >