> That said, maybe that Steve can build weely images based on sid for m68k.
I doubt that - parts will be uninstallable at pretty much all times.
That's why it would be nice to have testing (or maybe testing-m68k, based
on etch-m68k).
Re: volunteers: I have volunteered to help Wouter with managing
> > I doubt that - parts will be uninstallable at pretty much all times.
> > That's why it would be nice to have testing (or maybe testing-m68k, based
> > on etch-m68k).
>
> testing should be based on sid.
Color me stupid, but now I don't understand the 'there is no testing for
m68k because there
> > Uh, messy. I'll try t make time for that.
>
> I don't think we will have 2.6.20 for m68k, unless somebody else jumps in.
> I committed 2.6.21 patches to the debian svn yesterday, all but one
> (633-atari_scc.diff m68k) apply fine to the debian source, but building
> fails due to a missing Modul
> > WARNING: sound/oss/dmasound/dmasound_paula.o - Section mismatch: reference
> > to .init.text: from .data after 'machAmiga' (at offset 0x54)
> > WARNING: sound/oss/dmasound/dmasound_paula.o - Section mismatch: reference
> > to .init.text:AmiMixerInit from .data after 'machAmiga' (at offset 0x80)
> > The warning did not kill the build, but I guess it is good to get rid of it
> > anyhow. Patch commited to the debian svn.
>
> I need another patch, this killed only on warning:
>
> Building modules, stage 2.
> MODPOST 401 modules
> WARNING: sound/oss/dmasound/dmasound_paula.o - Section mism
> On Sun, 13 May 2007, Christian T. Steigies wrote:
> > This just leaves atari, and some problem in the debian linux-2.6 package,
> > which does not allow me to build a deb after compiling the kernel and
> > modules.
>
> Comment out atari-rom-isa.diff, it doesn't implement 32-bit I/Os yet.
Does it
> > > Comment out atari-rom-isa.diff, it doesn't implement 32-bit I/Os yet.
> >
> > If I don't apply the patch, applying later patches fails, so I disable the
> > rom-isa driver in the config instead.
Meaning no EtherNEC module can be built. Not good.
> > Michael, your dmasound_atari patches are
> > > Comment out atari-rom-isa.diff, it doesn't implement 32-bit I/Os yet.
> >
> > Does it absolutely need to? They would have to be emulated anyway.
>
> Some things (like generic I/O) assume all variants are present.
> So even if the hardware doesn't support 32-bit accesses, you should
> still im
> php4_4:4.3.10-21 failed to build on kullervo with
> "sbuild received SIGTERM -- shutting down"
> Please investigate/fix.
Not to worry - we had to shut down everything because the lab extension
necessitates work on the lab power grid. Might happen again in the future.
(... pondering about getting
> > I don't think that is related to lessdisks, if the linux-image is not
> > properly configured you, you will have to reconfigure it. If you install the
> > latest version from my website, or the packages I am just uploading to
> > incoming, you should have the correct vmlinuz file on your machin
> 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.)
If it gets rid of the multiple definition error... it sure looks right.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTE
> Is this the document?
>
> http://people.redhat.com/drepper/tls.pdf
>
> It does seem to have quite a bit of technical detail. I'll look at it
> in more depth a little later. Thank you for the pointer.
>From my quick reading, we might have to sacrifice another register. Does
this require any speci
> > >From my quick reading, we might have to sacrifice another register. Does
> > this require any special handling at the kernel level?
> >
> > I'd look at the 386 implementation (SH seems a bit simpler but I do know
> > squat about SH - anyone?)
>
> But I guess SH looks more like m68k than ia32,
> > 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 details of the other architectures, but I'l
> > Plus we already reserve a register for the current task - we're not all
> > that squeezed, but can't we store the per thread data at a constant offset
> > from the task address which we already store in a register? Are all
> > threads separate tasks at kernel level?
>
> We already reserve a reg
Hi,
I've been forced to take the hobbes buildd offline, because installation
ot TeXLive, again, was about to fill the chroot disk. Does a simple
installation of TeXLive really need to install all language packs?
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u
> > Not really. gcc-4.2 requires its patches to be updated; currently
> > (almost) all m68k-specific bits are commented out.
>
> Then why did the build succeed? I did upload those packages, this seems to
> be the first "successful" build of gcc-4.2 for m68k?
Let's hope the first built gcc-4.2 does
> Under freemint the natfeat (native feature) concept is used to output
> console text to the console that the aranym session is running under.
> If you look into this in the source code of freemint and aranym, this
> may be what you need.
That might be similar to Linux (kernel) console output dir
> > whoops, looks you guys beat me to it. both finn's 20 and christians 21
> > have
> >
> > CONFIG_MAC_ADBKEYCODES=y
>
> That's because I used the debian config for that kernel. I build smaller
> kernels for myself, and I don't enable CONFIG_MAC_ADBKEYCODES. It doesn't
> do anything in 2.6.x. It sh
> > > > CONFIG_MAC_ADBKEYCODES=y
> > >
> > > That's because I used the debian config for that kernel. I build
> > > smaller kernels for myself, and I don't enable CONFIG_MAC_ADBKEYCODES.
> > > It doesn't do anything in 2.6.x. It should be removed from Kconfig.
> >
> > It used to work until about 2.
> Finally got 2.6.21 to compile using distcc, with CTS's config.
>
> And it only took 8 hours for a native compile. :) Is 8 hours good or
> bad?
The 8 hours native (060??) does not sound bad. With distcc, I'd be a tad
worried ...
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
w
> Xorg has a bug on processor (>68020) with out native fpu.
>
> {You just hit an inplemented fpu instruction (flogn) and (fetox)
Unimplemented, perhaps? log and exp may indeed be unimplemented yet. Time
to fix that ...
> Backtrace:
> 0: /usr/bin/X11/X(xf86 SigHandler+0x6e)[0x8007b7de]
> 1:[0xefce
> > Unimplemented, perhaps? log and exp may indeed be unimplemented yet. Time
> > to fix that ...
>
> flogn and fetox are implemented in the 68881 and 68882, but not in the
> 68040 and 68060. However, on the latter ones they should be emulated by
> the kernel.
In the LC040, it might be a case of b
> > Do amiga and atari use at keymaps for 2.6 kernels? I'm trying to cleanup
> > some d-i stuff.
>
> Can't speak for Atari, but I think Amiga uses AT keymays, yes. I vaguely
> remember having to disable my loadkeys scripts on 2.6 kernels.
I do not load a keymap on the Falcon - resulting in US key
> > While having built and uploaded things correctly for experimental, I
> > didn't do the same for unstable, which now needs some manual
> > intervention building gnat-4.1 and gcj-4.1.
>
> > gcj-4.1 (alpha arm m68k mips mipsel s390 sparc):
> >
> > - needs gcc-4.1_4.1.2 (not yet built on arm and m
Hi Geert,
> 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:
Good to hear (that your A4000 is back up now, not the breakage of course
:-)
> I've also been thinking about adding a special `amiga
> > > I see the listmasters have straightened this message out. I'm building
> > > gcj-4.1 on vivaldi.
> >
> > I'll try gnat-4.1 on washi.
>
> that doesn't make sense unless you did port gnat-4.1 for m68k.
That was a fast 'build', then. Didn't realize 'manual builds needed'
really meant 'porting n
> > > What do you think?
> >
> > We would need something like that anyway, in order to convert drivers to
> > the new generic driver model, if I understand it right (the only driver
>
> The alternative is to keep (convert to, for some) them as platform
> devices. But that means no auto-load based o
> On Mon, Jun 11, 2007 at 05:35:02PM -0500, Stephen R Marenka wrote:
>
> This
>
> > /usr/bin/ld: final link failed: Nonrepresentable section on output
>
> reminds me of this from xulrunner.
>
> gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long
> -Wall -pipe -pthread -pipe -DNDE
> > Nope - we should perhaps verify it's a real regression first. Do you have
> > a quick test case available? Does anyone have the previous known good
> > version of binutils around?
>
> Which is a good version? My apt-cache/proxy have these versions:
>
> binutils_2.17-2+b2_m68k.deb
> binutils-dev
> On Wed, Jun 13, 2007 at 08:19:23AM +0200, Christian T. Steigies wrote:
> > The package did build successfully on m68k, as you can check yourself. Maybe
> > it will give you a hint, for what is missing on your system also:
> >
> > http://buildd.debian.org/build.php?arch=m68k&pkg=iptables&ver=
> >
> > | I think I got the same with a self-compiled 2.6.17 on powerpc. The
> > problem was
> > | that the module x_tables was missing. Did you set
> > CONFIG_NETFILTER_XTABLES?
>
> If I may ask? I've been using this as an exercise in compiling and linking
> in Linux. Where would you set CONFIG_NETF
> > I use 2.6.18.dfsg.1-12 from etch-m68k. I haven't gotten it to work right
> > from an initrd (some sort of framebuffer thing), but it works fine
> > booting a disk image. I haven't had success with the 2.6.21 kernels:
> > 2.6.21-1-02 doesn't have ethernet and 04 hangs at scsi probing.
>
> Excel
> > hello.c: In function 'main':
> > hello.c:3: warning: incompatible implicit declaration of built-in function
> > 'printf'
> > hello.c:2: warning: return type of 'main' is not 'int'
> > /usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
> > (.text+0x2e): undefined reference t
> > We can try to build a pre-2.17cvs version on sid, right? I'll try that on
> > washi ...
>
> That's the conclusion I came to also.
washi is acting up; won't upgrade binutils beyond -2 :-( I'll see where I
get on this.
> It looks like from #428582 that the xulrunner problem might be gcc.
Not v
> > i wonder i have seen that there are wireless devices for scsi. don't
> > know if any available/ supported though. not sure if it would be worth
> > it.
> As scsi is the only port I have available on the quadra to hook a
> device onto, it'd be useful. The wired hub seemed to be what I
> could do
> iptables v1.3.6: can't initialize iptables table `filter': Module is
> wrong version
>
> Perhaps iptables or your kernel needs to be upgraded.
Rebuild all of your kernel versions, this looks like some modules may have
been built using module symbol versions and others (and particularly, the
kern
> > We can try to build a pre-2.17cvs version on sid, right? I'll try that on
> > washi ...
>
> That's the conclusion I came to also.
The gcc -pie problem also occurs with binutils 2.17-3 rebuilt against
current sid.
I cannot find a build log for glibc 2.5 later than -3 - that one was still
built
> > I cannot find a build log for glibc 2.5 later than -3 - that one was still
> > built using binutils 2.17-3, and does not declare a conflict on binutils
> > pre-cvs. What version of binutils were libc6 2.5-10 and -11 built with?
>
> glibc_2.5-11 was built on akire
>
> Toolchain package versions:
> > So it would seem the latter error originates with glibc. The former I'm
> > unsure about. What is the more important error here - the undefined
> > reference or the nonrepresentable section?
>
> The __init_array_* error is blocking openssh, which we actually use.
But which does not block anyth
> > Pick one, I guess.
>
> I'm currently rebuilding glibc on washi.
Chicken-or-egg, it seems:
configure:5857: checking for -fpie
configure:5868: gcc-4.1 -g -O2 -isystem
/build/mschmitz/glibc-2.5/debian/include -pie -fpie
-o conftest conftest.c 1>&5
/usr/lib/libc_no
> This probably doesn't have any relevance, however it seems that fortran
> segfaults when building r-base, except on akire, which may be the only
> buildd still running a 2.4 kernel. I probably need to validate this with
> aranym.
hobbes and washi also run 2.4.
> Unfortunately, -pie is still a p
> > ld: cannot open linker script file
> > /usr/src/linux-headers-2.6.18-4-amiga/arch/m68k/kernel/module.lds: No such
> > file or directory
>
> That's an old problem, I think a bug was filed already. This might be due to
> the cross-compiling of the kernel, but I am not sure. It would be great
> t
> > > /usr/src/linux-headers-2.6.18-4-amiga/arch/m68k/kernel/module.lds: No
> > > such file or directory
> >
> > That's an old problem, I think a bug was filed already. This might be due to
> > the cross-compiling of the kernel, but I am not sure. It would be great
> > though, if you, or somebody
> > 396220 has been around for almost a year. Before that the problem was
> > fixdep in 342248. I don't seem to generate this file for any of my
> > kernels, so I don't even know what it looks like.
>
> It's not generated, it's in the source tree (for recent kernels only).
I was speculating about
> > > It's not generated, it's in the source tree (for recent kernels only).
> >
> > I was speculating about generating the file upon make config, thinking
> > Bill had the full kernel source in order to build external modules, not
> > just the linux-headers package.
>
> In case there are any doubt
> watching the g3 closely with top while the quadra compiles. It looks
> like compiling a routine the mac takes about 20 seconds, three seconds
> on the g3 compiling and 2 seconds of the network (lights flash on my
> hub-switch). So I figure simple arithmetic this is about the best one can
> do. th
> > extern void (*__init_array_start []) (int, char **, char **)
> > attribute_hidden;
> > extern void (*__init_array_end []) (int, char **, char **)
> > attribute_hidden;
> > extern void (*__fini_array_start []) (void) attribute_hidden;
> > extern void (*__fini_array_end []) (void) attribute_h
> > For that, we'd have to build a fixed linux-headers-2.6.18-4 package set.
> > Hence my request to Christian to apply the patch. I am not involved with
> > Debian kernel packaging myself, I just provide patches.
>
> linux-headers-2.6.21-2_2.6.21-5_m68k.deb now has this:
> -rw-r--r-- root/root
> > >Try aranym CVS. On my Pentium IV at 3.2GHz, aranym CVS is about the speed
> > >of a 68060 running at 120MHZ (by comparing to the Debian buildd).
> >
> > AFAIK, aranym is still broken on ppc, and
>
> Only if you use a 64bit kernel, AFAIK. There are plenty of users of
> aranym on PPC.
Current s
Hi,
> just to let you know my attempt to send my ppc tarball to bill in
> email failed, some server unknown where to me (called yellowpig)
> rejected it although gmail took it it bounced somewhere.
>
> if someone with ppc has a drop box or anonymous ftp spot then
> I could donate it but otherwise
> > Eh, I thought the security people wanted to do m68k builds, but I'm not
> > sure. Joey?
>
> buildd.debian.org doesn't have wanna-build db's for either etch-m68k or
> etch-m68k-security. If we setup our own, we have to dedicate buildds that
> are currently running unstable. I don't think we curr
> > > Same as the oldstable buildds. Christian can bring garkin back soon I
> > > hope.
> >
> > The oldstable buildds have a wanna-buildd database on buildd.debian.org,
> > etch-m68k and etch-m68k-security don't. buildd can handle that, it can't
> > handle multiple wanna-buildd databases on differe
tname: crest.debian.org aka crest.biophys.uni-duesseldorf.de
architecture: m68k
buildd admin(s): Adam Conrad <[EMAIL PROTECTED]>
local admin: Michael Schmitz <[EMAIL PROTECTED]>
configured suites: unstable
buildd chroots: woody, sarge, etch, sid
user chroots: woody, sarge, etch, sid
hostn
> > hostname: crest.debian.org aka crest.biophys.uni-duesseldorf.de
> > architecture: m68k
> > buildd admin(s): Adam Conrad <[EMAIL PROTECTED]>
> > local admin: Michael Schmitz <[EMAIL PROTECTED]>
>
> I suppose this answers why crest never seems to be caug
Hi,
> hostname: garkin.debian.net
> architecture: m68k
> buildd admin(s): Christian T. Steigies <[EMAIL PROTECTED]>
> local admin: Christian T. Steigies <[EMAIL PROTECTED]>
> configured suites: unstable
> buildd chroots: sid
> user chroots: none
>
> All hostnames point to the same IP, since I only
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Debian stuff)
+
On Sat, 30 Jun 2007, Brian Morris wrote:
> On 6/29/07, Bill Allomb
Hi,
> My effort to to build etch-m68k are stalled because the packages I have
> uploaded are stuck in the new queue and I did not receive instructions
> how to upload the four rejected packages.
The reason for rejection was that the same package versions do already
exist? Maybe a binNMU could cha
> On Wed, Jul 11, 2007 at 07:51:28PM +0200, Luk Claes wrote:
> > Luk Claes wrote:
> > > Stephen R Marenka wrote:
> > >> On Thu, Jun 28, 2007 at 11:24:09AM +0200, Michael Schmitz wrote:
> > >>
> > >>> hostname: crest.debian.org aka cr
Hi,
> Greetings! I can't seem to get `pwd` to work right in a configure
> script on crest unstable:
crest appears to have rebooted spontaneously (most likely due to a power
brownout two days ago; q650 and hobbes survived the brownout so I assumed
it wasn't a total three-phase thing. Remind me to
Hi,
> [EMAIL PROTECTED]:~$ dchroot sid
> chdir: No such file or directory
Oops - home dirs were not mounted in the chroot. Fixed now.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
> Thank you so much!
Does it work OK now?
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > Oops - home dirs were not mounted in the chroot. Fixed now.
> >
>
> I've been using /usr/local/tmp as there is not enough space under
> home, yet /usr/local/tmp is not available in the chroot. Can you
> please fix this too?
Done - if that's not enough or if disk errors show on /usr/local you
> Greetings! Have not checked and am trying debugging on kullervo.
>
> The chroot appeared fine on crest, but a simple configure script lost
> track of its current directory and died.
>
> Would you like me to recheck crest?
Just tell me which directory you ran ./configure in, I'll check myself.
Hi,
> Washi suffered a liquid cooling failure which caused a pretty cool
> meltdown. I've fixed everything up, refilled it and the system is up
I always thought you were kidding about the liqid cooling ... Good to
hear it's up again.
> and running again *except*. When I boot up the 2.4 ker
> > washi needs its key to be fixed on buildd.d.o. This is a months-old
> > problem.
>
> I guess this is fixed by now?
Hmmm ...
[EMAIL PROTECTED]:~$ ssh -v -lbuildd_m68k buildd.debian.org wanna-build
--database=m68k/build-db --dist=unstable --list=needs-build
3.9p1, OpenSSL 0.9.6m 17 Mar 2004
deb
Hi,
in case anyone had jobs running on crest or kullervo: we had a heavy power
outage today. The boxes are back up but may need chroot servicing.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Michael Schmitz writes:
> > > - gcc-snapshot builds are missing for m68k.
> >
> > Bad build dependency on xulrunner, by brainfart of yours truly. I'll
> > manually queue that one as well.
>
> tell me what is wrong with
>
> libxul-dev [!kfree
> also, libc6 is two points behind (one major and one minor),
> 2.6 came out several weeks back and another upgrade of it
> last weekend.
Patches welcome.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> whats up with m68k?
unstable moving faster now that we're no longer holding everyone back, and
we're not keeping pace? glibc 2.6 needs porting to m68k first before we
can switch?
> - the last gcc-4.1 upload did fail to build
> http://buildd.debian.org/fetch.cgi?&pkg=gcc-4.1&ver=4.1.2-14&arch=m6
Hi,
> > Anyway, I remeber we investigated the ld failure with a simple test case
> > at that time and could not find out where the problem originated. Can't
> > find the mails right now, but I think Stephen came up with the test case
> > (mid-June).
>
> This pretty much sums up our current proble
> > > also, libc6 is two points behind (one major and one minor),
> > > 2.6 came out several weeks back and another upgrade of it
> > > last weekend.
> ?
>
> 1) there is an official upstream maintainer for libc6 at least
> at gnu listed as Andreas Schwab ([EMAIL PROTECTED]) ...
I wonder how much t
Just FYI: hobbes is down again, and it looks like one of the SCSI disks
bit the dust, finally. I don't know whether I will be able to get hobbes
sorted before it gets packed up for the move.
To make matters more interesting, washi is off the net as well. If anyone
still has a buildd host that coul
> > 2. is possible - fbdev complains of interlieves not supported yet -
>
> Probably Atari interleaved bitplanes are not supported at all by the new
> X server.
Seeing how interleaved bitplanes was a lot of fun to reimplement in the
kernel, I'd say most definitely support has been dropped by the
Hi,
> http://buildd.debian.org/fetch.cgi?&pkg=binutils&ver=2.17cvs20070804-1&arch=m68k&stamp=1186298213&file=log
>
> Test results, compared with installed binutils:
> W: [ld-elfvsb/elfvsb.exp] REGRESSION (PASS -> FAIL): visibility
> (protected_weak) (non PIC, load offset)
> W: [ld-elfvsb/elfvsb.e
> > It wasn't actually meant to be a serious suggestion, I hope :-) I can't
> > stay much beyond 14:00 and I'll need to lock the place after the meeting.
> >
> > I'd suggest something like the Oldenburg meeting as well. Only I won't be
> > able to attend anyway...
>
> Why not?
>
> Oldenburg is unfo
> >> What do you say Michael?
> >
> > Seconded. I can't take more buildds, either. I'll try to sort out the
> > assignment of chroots to releases first, though.
>
> For unstable crest is doing fine IMHO, though it's not used for
> oldstable(-security) as it only builds packages for a suite when
> n
> > > Thoughts?
> >
> > Sure, this saturday 9am in Duesseldorf.
>
> Eh, that might be slightly short notice. I was actually thinking about
> doing something a few months from now, like, say, late september - early
> october.
It wasn't actually meant to be a serious suggestion, I hope :-) I can't
s
> > take out one POSTPONED of the link
>
> The connection has timed out.
>
> I am not lucky..
I looked at the patch and it appears that we will still need this. But
there's a related problem with FAT support: in 2.6, the logical sector
size is not allowed to be larger than the MMU pagesize. That c
> > > For unstable crest is doing fine IMHO, though it's not used for
> > > oldstable(-security) as it only builds packages for a suite when
> > > needs-build > 10.
> >
> > That's been done to use it as a backup only. Could be changed I guess.
>
> I don't really mind one way or the other though it
> > But I think most m68k hackers are in Europe. I wouldn't mind a meeting in
> > SF, but I am not going to take my m68k boxes back to the US...
>
> I always got the impression that while most Atari and Amiga work
> happened in Europe, much of the Mac work happened in North America.
> Obviously mos
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
With buttons emulation being available via uinput event devices, do we
still need the kernel mouse button emulation? At least on powerpc, it was
declared deprecated long ago ...
A
> > Anyone using mouseemu on m68k Mac?
>
> Yes, and on powermac too. It provides the paste key for gpm and I'm quite
> fond of it. But if there's a better alternative, I'll happily try it
> instead.
Too much overhead on m68k? On powermac it never gave me trouble, but I was
surprised to hear people
Hi,
just FYI: hobbes is down for the next month or two, awaiting overseas
shipping and reassembly someplace nice in Auckland, NZ.
ETA not before October 5th, so be patient!
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL P
Hi there, guys!
Sorry for being out of the loop for so long - first it took a while to get
network connectivity sorted out at all down here, then we got seriously
bogged down by househunting, and last of all I finally discovered that
procmail did hide buildd list mail in a separate mailbox aft
Hi,
I'm trying to get washi running.
Do you still connect via evil? washi used to have a serial connection to
evil as well, we should be able to log in there.
Yes. I didn't know about the serial connection.
It may not be there anymore ... minicom tries to use ttyUSB0 without
having the ri
> > Now, I would like to change the build system such that the .cc files are
> > concatenated and only about 10 object files are built. On my current
> > system, this halves the build time. The problem is that memory
> > requirements go through the roof (I think you need more than 500 MB
> > Ram).
Hi,
> Has anyone made any progress with the following error? If not, should I
> file this as a binutils or gcc bug?
>
> BTW: I'm queueing gcc-4.2 on vault13, now that binutils has built.
Does the error still happen with the new binutils? In that case I'd blame
gcc.
Michael
> Thanks,
>
Hi,
> >
> Washi keeps losing internet connectivity. It's something to do with the
> network card. It could either be fried or need reseating. I'm not sure
> yet. If I run a simple ping to the gateway I get very strange error
> messages like "wrong data byte #45 should be 0x2d but was 0x2f" and
Hi,
> > EtherNAT driver, and ARAnyM did not work on my Powerbook last time I
> > tried. I'm stil planning to work on it, come next month.
>
> Speaking of which, debian linux 2.6.22-4 gives me some of the following
> errors when using aranym.
>
> | blk_queue_max_hw_segments: set to minimum 1
Yep,
Hi Mark,
> I did fiddle with it, and it is working now for days. I'd say it'll
> probably be fine for a while again. I took am moving so washi will have
> to come down for probably a week in early december.
I'm glad that it was a connector problem only, apparently. Incidentially,
what kernel ve
> > With the move of kullervo and crest, crest.debian.org and
> > m68k.debian.org no longer resolve to anything. Should we punt these
> > addresses or fix them?
>
> As I understood Christian, Debian was looking for new hosting facilities and
> the hosting behind the DSL (dynamic IPs) will only be
Following up on the crazy idea:
> > Correct. So the IP numbers will have to change sometime, once we have new
> > hosting, but I wont promise that this will be possible this year...
>
> Either way, let's fix the DNS - and keep the TTL low so a change will be
> instantaneous.
>
> I'm just wondering
> On Mon, Nov 12, 2007 at 01:28:21AM +0100, Michael Schmitz wrote:
> > Routing/VPN off Duesseldorf would give you a quasi static address (we
> > would need to put a similar mechanism in place to update the route entry,
> > whereas for VPN you would just have to reopen t
Hi,
> aahz, tanda, garkin
> and as long as they are hosted by me, also crest and kullervo
> (hosts with static IP do not need a password?)
>
> I guess q650 (still in Duesseldorf) and hobbes (with Michael in NZ) will
> need passwords, too?
Positive. q650 is mostly dead these days though.
Hi Mark,
> Washi will be killed on Sunday (2 days from now). It will not be made
> available again for the immediate future and even shortly after as I
> want to run MiNT on it again so I can help with the native OS atari
> community again. I will let you know if I decide to run debian on it
> a
> > One problem I had previous which I
> > think has since been solved is that I was unable to remote display
> > aranym. It wanted to do many screen refreshes a second which the
> > network was unhappy about.
>
> Mark, this is perfectly configurable... Set it to 1 FPS and your network
> should be
> > > SETUP -> VIDEO -> Videl Refresh rate.
>
> > Have you checked that this is in fact being honored by the Linux
> > framebuffer driver? In video=keep mode it should be, but otherwise Linux
> > might reprogram the VIDEL "registers" at boot.
>
> ARAnyM VIDEL emulation ignores refresh rate programm
Hi,
> So I will (re)move the floppy in kullervo, so that the IDE disk/converter
> can be mounted internally. The cover should fit on the case again then. The
> floppy drive seems to be broken, so it will probably not be missed.
I never used the floppy, but I may have disconnected it accidentially
> Has anybody heard about passwords for buildding out of incoming?
>
> It would seem that it's been long enough to generate some new passwords.
I have heard nothing so far. I have brought hobbes back up recently and
did upload the first couple of packages now, so access to incoming is
getting more
1 - 100 of 1062 matches
Mail list logo
