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

[Wouter Verhelst]

On Mon, May 21, 2007 at 10:25:04AM -0700, Brad Boyer wrote:
[TLS support]
> I don't think m68k would have issues with large relocation offsets. As
> long as it doesn't support the pre-68020 chips, we have a lot of choices
> of ways to handle large offsets. I presume we just need support for the
> '020, '030, '040, and '060, or do I need to look at ColdFire as well?

It would be nice if you could do that, otherwise I'll have to revamp it
if/when I get to libc with my coldfire work.

-- 
Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] gcc-4.2 (4.2-20070516-1)

[Wouter Verhelst]

On Tue, May 22, 2007 at 08:37:02PM +0200, Christian T. Steigies wrote:
> Hi,
> I've been building gcc-4.2 on my mac for about a week now. The first try
> timed out, so I decided to continue the build manually. That failed last
> night, since my router had its daily crash and I did not run the build in a
> a screen session. When I continue the build again, I am afraid it will start
> all the tests again, which takes forever... I'd prefer not to do that on a
> slow mac. Is there a faster way to finish the build or should I just give
> the package back and let a faster buildd handle it? Maybe the current build
> stage is of use to somebody? I assume if it is running tests now, that the
> actual build has succeeded?

Not really. gcc-4.2 requires its patches to be updated; currently
(almost) all m68k-specific bits are commented out.

I'm working on this, and am making some progress, although the current
patch (debian/patches/m68k-split_shift.dpatch) is proving to be quite a
challenge (it touches gcc/config/m68k/m68k.md, which is uh, rather
daunting).

-- 
Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

aranym text console

[Wouter Verhelst]

Hi Petr,

I talked to Joey Hess, who's set up a d-i testlab to run test installs
for various Debian architectures, to look into setting up aranym as one
of the used emulators so that we could have automated m68k test
installations.

Unfortunately, that isn't going to happen with the current state of
affairs, since it's impossible to get some sort of text output from the
console to a program outside of the emulator; I don't see any support
for serial lines, nor do I see the ability to disable the framebuffer
(although I imagine that the last problem is merely a restriction of the
platform).

Would it be possible to add in support for a serial line? Ideally this
would work similar to qemu's way of doing this, where you can have the
emulator allocate a PTY to which serial input and output are then
redirected. If things were arranged this way, the testlab framework
wouldn't need much extra work for aranym to be used.

Additionally, it would also be nice if the sdl usage could be disabled
with a simple command line switch, or so. Currently you have to have an
X server available, which isn't desirable for this type of usage.

Thanks,

-- 
Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aranym text console

[Wouter Verhelst]

On Thu, May 24, 2007 at 03:46:27PM +0200, Petr Stehlik wrote:
> Wouter Verhelst wrote:
> >
> >Unfortunately, that isn't going to happen with the current state of
> >affairs, since it's impossible to get some sort of text output from the
> >console to a program outside of the emulator;
> 
> there is a way of redirecting the kernel output to serial, parallel, 
> midi (standard Atari ports) or to aranym debug output. Wouldn't this 
> help?

The kernel output doesn't help, since it's the output of user space
software that's important.

> Or what kind of console output outside of the emulator you need? 

The test lab needs to verify the installer's output to make sure that
everything ran as required (or to indicate that there's a bug in the
installer if not).

It *might* also be required for it to accept input, though I'm not sure
about that bit.

> Networking is of no help here?

No. The installer cannot easily be run over the network. It is possible;
for s390, this is exactly what's done. it's an ugly hack though, and
more importantly it's not the common usage pattern for m68k either,
whereas the point of this exercise is to automatically test the
installer for the m68k platform as it'll be used there.

The alternative (keeping logs of what happens from inside the installer
and saving them on the network afterwards) isn't very helpful, either,
since that method breaks the moment something happens that wasn't
foreseen.

> >Would it be possible to add in support for a serial line?
> 
> I wouldn't like emulating another Atari chip so I'd rather add a simple 
> natfeat driver to the linux kernel, if it is acceptable.

That would work, too. As long as one can interact with the emulator
using, say, perl or expect, that's okay.

> >Additionally, it would also be nice if the sdl usage could be disabled
> >with a simple command line switch, or so. Currently you have to have an
> >X server available, which isn't desirable for this type of usage.
> 
> It's not easy to disable SDL in ARAnyM, I am afraid (perhaps the video 
> output could be disabled, but not the SDL as a whole), but Xvfb or 
> perhaps aalib SDL video driver could help here. Haven't tried that, though.

Yes, I thought of Xvfb, but that would make the whole setup rather
heavy, so it would be preferable if that wasn't necessary. But if it's
not easy to disable SDL, then that's okay -- we can cope with having to
run Xvfb, I guess.

-- 
Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] gcc-4.2 (4.2-20070516-1)

[Wouter Verhelst]

On Thu, May 24, 2007 at 01:43:42PM +0200, Christian T. Steigies wrote:
> On Tue, May 22, 2007 at 09:03:55PM +0200, Wouter Verhelst wrote:
> > 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?

Because they are commented out. If they weren't commented out, those
patches would've failed to apply, and the build wouldn't even have
started :)

-- 
Shaw's Principle:
Build a system that even a fool can use, and only a fool will
want to use it.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dballe failure on zeus

[Wouter Verhelst]

Hi,

Enrico Zini contacted me here at debcamp with a failure of his package
dballe on zeus. When he tried to investigate the error mode on crest,
all was well. Any guesses what's wrong with zeus?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[buildd] Stuff

[Wouter Verhelst]

Hi,

My BoF about m68k here at DebConf went quite well; most of the release
team was present, as was James Troup for at least part of it. One thing
that came out of the discussion is that they really, really want 'faster
buildd machines'; apparently someone in the security team (I don't
recall who exactly) is really adamant about this too, because we appear
to be delaying security updates from time to time. Having a faster
machine to build security updates therefore would seem to be necessary.
I'd suggest you go view the video, but unfortunately the power failed
while we were working, so it's probably not there.

I had a short discussion with James Troup, and he told me he'd enable
Bill Allombert's emulated buildd machine. Now that it usefully runs
faster than crest, I think that's the best way to move forward, and I
had the feeling that most of the m68k team thought about it that way,
too (right?). Perhaps we should consider getting us a few more fast i386
machines and set up ARAnyM on those as well, although I don't think it'd
be smart to phase out physical m68k hardware entirely just yet.

Also, I/we've been asked to start building for oldstable ('oldstable' in
wanna-build, as opposed to oldstable-security), since they apparently
have the ability now to do point releases of oldstable too, which they
want to do, and there's already 61 packages in needs-build for oldstable
(d-i stuff to a large extent).

I decided that since quickstep is still running 2.2 ATM, it can't be
very useful for experimental autobuilding for much longer (newer glibc
in unstable will require a newer kernel rather soonishly), so that it
might make sense to start using it for oldstable and stable. I'm
currently in the process of setting it up as such (hopefully that'll be
finished sometime during the week), and James told me he'd add the key
to wanna-build.

That however leaves us without a buildd for experimental, so I'm
thinking about resurrecting ska for that purpose (I've been having to do
that for about a year now; now seems as good a time as any), unless
someone else has a better idea (ska still couldn't run >2.4 last time I
tried; but that's been about a year ago, so it might work today)

That's about it for now, I guess. Enjoy,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] Stuff

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 10:33:26AM -0500, Stephen R Marenka wrote:
> On Mon, Jun 18, 2007 at 03:30:46PM +0100, Wouter Verhelst wrote:
> > Also, I/we've been asked to start building for oldstable ('oldstable' in
> > wanna-build, as opposed to oldstable-security), since they apparently
> > have the ability now to do point releases of oldstable too, which they
> > want to do, and there's already 61 packages in needs-build for oldstable
> > (d-i stuff to a large extent).
> 
> I'll turn that back on for zeus and poseidon. Last I checked, there
> wasn't an oldstable db, I see it now.

Yeah, James had set that up just before I spoke him.

Note that you'll need to patch sbuild to know about oldstable (it has a
hardcoded list of distributions somewhere, you need to add oldstable to
that list. It's pretty straightforward).

> I wish we could get an etch-m68k (or even stable) db too.

Talked to Ryan (on IRC) for that, he replied he's working on some code
merge for wanna-build currently which would take about a week, and that
he'd do it after that.

> > I decided that since quickstep is still running 2.2 ATM, it can't be
> 
> It looks like quickstep is a Quadra 650.

A Centris 650, actually.

> The etch-m68k or sid 2.6 kernels should run fine. I've even got a
> console on my Centris 650 and both my Quadra 950s! (I'm still
> excited.)

Oh, goody. Didn't know that. I should upgrade it first thing when I get
home then, I guess.

> > very useful for experimental autobuilding for much longer (newer glibc
> > in unstable will require a newer kernel rather soonishly), so that it
> > might make sense to start using it for oldstable and stable. I'm
> > currently in the process of setting it up as such (hopefully that'll be
> > finished sometime during the week), and James told me he'd add the key
> > to wanna-build.
> 
> Can you get him to fix/check the one for washi too?

That's Bill's machine, right? I already asked him to do that.

[...]

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] Stuff

[Wouter Verhelst]

On Mon, Jun 18, 2007 at 11:35:39PM +0200, Bill Allombert wrote:
> On Mon, Jun 18, 2007 at 03:26:41PM -0500, Stephen R Marenka wrote:
> > On Mon, Jun 18, 2007 at 06:53:46PM +, Bill Allombert wrote:
> > 
> > > I strongly suggest that the box buildding security update use 
> > > distcc+crosscc. This will speed things quite a bit with no
> > > risk of breakage since we are using a stable cross-compiler
> > > that is well tested.
> > > 
> > > In my opinion, distcc+crosscc have more potential that aranym,
> > > especially for security in term of speed gain and reliability.
> >  
> > It seems to break on objective-c code. Does it work for fortran or any
> > other languages?
> 
> It does not work for fortran (unless you use f2c) but fortran is an
> order of magnitude faster to compile than C++.
> 
> > > I believe that if there had been a concerted attempt to use
> > > distcc+crosscc on some buildd, we would have been able to get
> > > released with Etch. Actually I still believe we can relase m68k
> > > as part of etch 4.0r2 or 4.0r3 if we show a real involvement
> > > even if merely symbolical.
> > 
> > The toolchain was the root cause for our etch problems, not our buildd
> > speed. Buildd speed was contributory in that it was easy to point to.
> 
> Exactly: we were able to build every packages anyway. But we needed to
> do more: showing we have potential for being faster, even if it did not
> make a real difference at this point. That is why I said 'merely
> symbolical'.
> 
> > At the time we were punted from etch, we had not yet worked out our 
> > toolchain problems.
> > 
> > Until we resolve our current toolchain problems and get TLS working, 
> > we won't be added to lenny. I don't believe we have any chance to be
> > added to etch.
> 
> In my opinion, we have even less change to be released with Lenny than
> with Etch. Releasing Etch will certainly get us point toward releasing
> Lenny, especially if we show we are able to build security.d.o without
> slowing down the advisories.
> 
> > At the moment we don't even have a list of how etch-m68k
> > differs from etch and etch-security.
> 
> This is my attempt with quinn-diff:
> Between etch and etch-m68k:
> 
> Between etch and security.d.o: 40 source packages.
> 
> The list of package marked out-of-date:
> 
> x11/libx11_2:1.0.3-7.dsc 
> devel/mozart_1.3.2.20060615+dfsg-2.dsc 
> devel/klic_3.003-gm1-2.1.dsc 
> devel/haskelldb_0.9.cvs.601-13.dsc 
> python/python2.4_2.4.4-3.dsc 
> utils/fcitx_1:3.4.3-1.dsc 
> graphics/blender_2.42a-7.dsc 
> libs/kdelibs_4:3.5.5a.dfsg.1-8.dsc 
> libs/db4.2_4.2.52+dfsg-2.dsc 
> devel/mozart-gtk_20060615-2.dsc 
> graphics/ctn_3.0.6-10.dsc 
> admin/brltty_3.7.2-7.1.dsc 
> devel/libsigsegv_2.4-1.dsc 
> net/ejabberd_1.1.2-6.dsc 
> interpreters/sigscheme_0.6.1-1.dsc 
> devel/systemtap_0.0.20061028-2.dsc 
> math/octave2.9-forge_2006.07.09+dfsg1-8.dsc 
> interpreters/erlang_1:11.b.2-4.dsc 
> interpreters/gnu-smalltalk_2.1.8-2.1.dsc 
> web/yaws_1.65-4.dsc 
> 
> By the way, if I build them, can I upload them ? How ?

regular dupload? You may need to target etch-m68k instead of etch, I
guess. ISTR sbuild having an option for that (specifying the release to
generate .changes files for).

> Can we remove packages that should be 'not for us' ?

If they're already uploaded, asking an FTP master should be doable, I
guess. If they're not uploaded yet, that's what wanna-build is for :)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: building kernel modules packages

[Wouter Verhelst]

On Thu, Jun 21, 2007 at 10:13:48AM +0200, Bill Allombert wrote:
> Hello m68k porters,

Side note: it seems weird to talk about yourself in that way.

;-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: etch-m68k security update

[Wouter Verhelst]

On Sat, Jun 23, 2007 at 08:50:41PM -0500, Stephen R Marenka wrote:
> On Sat, Jun 23, 2007 at 11:30:34PM +0200, Bill Allombert wrote:
> > Hello m68k porters,
> > 
> > I have build all etch security updates that do not build-depend on mysql:
[...]
> > Any suggestion concerning what I should do with them ?
> 
> Upload them to etch-m68k. That or we need to get the security people to
> create us a distribution. I think the former is easier.

Eh, I thought the security people wanted to do m68k builds, but I'm not
sure. Joey?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: etch-m68k security update

[Wouter Verhelst]

On Sat, Jun 23, 2007 at 10:40:11PM +, Bill Allombert wrote:
> On Sun, Jun 24, 2007 at 12:08:32AM +0200, Luk Claes wrote:
> > If you mean for etch, I guess you should upload them to etch-m68k.
> 
> I will not do that: I do binary-only upload so etch-m68k Sources file
> would not match the Packages file. Also I want to make etch-m68k identical
> to etch, so etch-m68k Sources file should stay identical to etch Sources
> file.

Just FTR, that's not the way it's implemented. Since we can't get
updates to etch anymore, etch-m68k is supposed to be a different suite,
which generates its own Sources file. You can /try/ to make them
identical, but if updates are needed, then that won't happen (because
then you really do need updates).

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] buildd.debian.org down?

[Wouter Verhelst]

On Thu, Jul 12, 2007 at 10:15:50AM +0200, Christian T. Steigies wrote:
> Hi,
> my buildds have problems accessing the wanna-build db on buildd.d.o, does
> anybody else see this?

Works for me...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] buildd.debian.org down?

[Wouter Verhelst]

On Thu, Jul 12, 2007 at 11:42:18AM +0200, Wouter Verhelst wrote:
> On Thu, Jul 12, 2007 at 10:15:50AM +0200, Christian T. Steigies wrote:
> > Hi,
> > my buildds have problems accessing the wanna-build db on buildd.d.o, does
> > anybody else see this?
> 
> Works for me...

Actually, it /doesn't/ work for me. Sorry. I mistook the sudo password
prompt for the SSH one.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] buildd.debian.org down?

[Wouter Verhelst]

On Thu, Jul 12, 2007 at 12:18:15PM +0200, Wouter Verhelst wrote:
> On Thu, Jul 12, 2007 at 11:42:18AM +0200, Wouter Verhelst wrote:
> > On Thu, Jul 12, 2007 at 10:15:50AM +0200, Christian T. Steigies wrote:
> > > Hi,
> > > my buildds have problems accessing the wanna-build db on buildd.d.o, does
> > > anybody else see this?
> > 
> > Works for me...
> 
> Actually, it /doesn't/ work for me. Sorry. I mistook the sudo password
> prompt for the SSH one.

Apparently there's a network failure on the network hosting buildd.d.o.
It should be fixed 'soon'.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k toolchain status?

[Wouter Verhelst]

On Mon, Jul 30, 2007 at 08:13:12AM -0700, Brad Boyer wrote:
> One issue is that I don't have a real copy of the ELF ABI documentation
> for m68k. I found a copy of the PPC documentation, but even that was
> difficult. Does anyone have a copy or hints on how to find it? I'm
> worried that the current ABI isn't really flexible enough to do TLS
> in a proper fashion.

ISBN 0-13-877663-6. If you can get Prentice-Hall to get it out in print
again, be sure to get me a copy. If you can't get P-H to do this, but
you do find two copies, be sure to get me one.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k toolchain status?

[Wouter Verhelst]

On Mon, Jul 30, 2007 at 06:02:38PM -0700, David D. Kilzer wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > ISBN 0-13-877663-6. If you can get Prentice-Hall to get it out in print
> > again, be sure to get me a copy. If you can't get P-H to do this, but
> > you do find two copies, be sure to get me one.
> 
> Amazon.com knows about it, but doesn't have any in stock (or used).  You may
> set up a request for a copy of the book, though, and someone may eventually
> find one to sell to you!
> 
> http://www.amazon.com/exec/obidos/ASIN/0138776636
> http://www.amazon.de/exec/obidos/ASIN/0138776636

I already did that... some years ago. Never heard anything from them.

My guess is the book is very rare at this point.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k toolchain status?

[Wouter Verhelst]

On Tue, Jul 31, 2007 at 02:30:39PM +1000, Finn Thain wrote:
> On Mon, 30 Jul 2007, Brad Boyer wrote:
> 
> > One issue is that I don't have a real copy of the ELF ABI documentation 
> > for m68k. I found a copy of the PPC documentation, but even that was 
> > difficult. Does anyone have a copy or hints on how to find it? I'm 
> > worried that the current ABI isn't really flexible enough to do TLS in a 
> > proper fashion.
> 
> I'm out of my depth here, so please take what I say with a grain of salt 
> -- but my impression is that we never followed the published standards 
> anyway:
> 
> http://c1.complang.tuwien.ac.at/cacaowiki/M68kCallingConventions
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01054.html
> 
> ...which said: "Align ints to a word boundary.  This breaks compatibility 
> with the published ABI's for structures containing ints, but produces 
> faster code on cpus with 32-bit busses (020, 030, 040, 060, CPU32+, 
> ColdFire). It's required for ColdFire cpus without a misalignment 
> module."

Yes, but that's listed above
#define MASK_ALIGN_INT (1 << 13)
#define TARGET_ALIGN_INT (target_flags & MASK_ALIGN_INT)

Which I read as it being a flag value for a compile option? Or am I
totally wrong here?

> The de facto ABI as defined by the toolchain itself may be more relevant 
> if the only published standards are obsolete.

Of course.

However, that not being written down anywhere makes it rather hard to
understand it. Your first link surely is very helpful already, but it
might be nice if we could extend that wiki page to be more detailed?

I understood from Roman that A5 has some special meaning in position
independent code; I just don't know what that is.

Those pages tell me that D0 and D1 are used for function return values.
I knew about D0, but what's with D1?

Figuring out alignment of structs shouldn't be too hard, but AFAIK it
isn't done.

etc.

Thoughts?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k toolchain status?

[Wouter Verhelst]

On Tue, Jul 31, 2007 at 10:55:01AM +0200, Wouter Verhelst wrote:
> Which I read as it being a flag value for a compile option? Or am I
  ^^
For clarity: I mean a "compile option", as in, "an option specified on
the compiler's command line".

It gets all messy if you start talking about compiling compilers...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k toolchain status?

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 11:10:32PM +0200, Geert Uytterhoeven wrote:
> On Tue, 31 Jul 2007, Wouter Verhelst wrote:
> > On Tue, Jul 31, 2007 at 02:30:39PM +1000, Finn Thain wrote:
> > > The de facto ABI as defined by the toolchain itself may be more relevant 
> > > if the only published standards are obsolete.
> > Those pages tell me that D0 and D1 are used for function return values.
> > I knew about D0, but what's with D1?
> 
> I guess returning 64-bit integer values?

Ah, d'oh. Thanks for stating the obvious :-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

meeting?

[Wouter Verhelst]

Hi,

I've been wondering whether it might be nice to hold some real-life
meeting someplace. Stuff I'd like to do:

* Meet face-to-face with you all (haven't done that yet, ever).
* Discuss upon a strategy to get m68k to be actively supported within
  Debian again.
* Swap some hardware (I stil have some machines that aren't doing
  anything useful these days, which is a shame).
* Help eachother with getting stuff to work where necessary (say,
  coldfire boards etc).
* Hack together on stuff
* ... something else?

Thoughts?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: meeting?

[Wouter Verhelst]

On Thu, Aug 09, 2007 at 05:59:21PM +0200, Christian T. Steigies wrote:
> On Thu, Aug 09, 2007 at 05:32:14PM +0200, Wouter Verhelst wrote:
> > Hi,
> > 
> > I've been wondering whether it might be nice to hold some real-life
> > meeting someplace. Stuff I'd like to do:
> > 
> > * Meet face-to-face with you all (haven't done that yet, ever).
> > * Discuss upon a strategy to get m68k to be actively supported within
> >   Debian again.
> > * Swap some hardware (I stil have some machines that aren't doing
> >   anything useful these days, which is a shame).
> > * Help eachother with getting stuff to work where necessary (say,
> >   coldfire boards etc).
> > * Hack together on stuff
> > * ... something else?
> > 
> > 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.

> And if you have a place to host two Amigas, you are especially
> welcome... then I don't have to drive them back to the far north.

Heh.

> Help with coldfire boards would be great, I just got my efika board to
> work and have a gcc-4.2 cross compiler, but I can not get distcc to
> work with 4.2 yet... my coldfire is only collecting dust right now, do
> you have instructions to get the coldfire going?

I already told you what I know, some while ago, but that didn't help;
your hardware is different from mine. This is another reason why I want
to meet up -- perhaps we can then figure out how it is different and how
you can get it to work.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: meeting?

[Wouter Verhelst]

On Fri, Aug 10, 2007 at 06:30:47PM +0200, Michael Schmitz wrote:
> > > 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 unfortunately out of the question, but there's no reason
> > why we couldn't go ahead and meet in Düsseldorf?
> >
> > If the reason is mainly financial: I believe getting some reimbursement
> > from the project is not totally out of the question; Aj said he'd set
> > aside some money each month for such things, and I don't think Sam has
> > revoked that. Or, well, if we hold it in Düsseldorf, it'll be a bus
> > ticket for you. I hope :-)
> >
> > Or is there something else?
> 
> It rather is a plane ticket for me in future. And 30+ hours of travel time
> each way.
> 
> OTOH, we can have future m68k hackers meetings in the area of Auckland, NZ
> for all I care :-) Starting September, I'll take up a job at the
> university there.

Oh. Ah. Hm.

Well, yeah, that explains :-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Buildds configuration and admins

[Wouter Verhelst]

On Fri, Aug 10, 2007 at 03:21:05PM +0200, Luk Claes wrote:
> If I want to interact with wanna-build for m68k, am I supposed to use 
> crest's access to wanna-build

Yes.

> or should I be added (centrally) to the wb-m68k group? If the latter
> can someone that has already group membership ask for my inclusion?

The wb-* groups are no longer in use. They were back when wanna-build
was running on auric, but that's two break-ins ago.

[...]
> Probably it would also be a good idea to revisit the packages in
> Dep-Wait and Failed altogether...

Yes. I often intend to do that, but I hardly ever find the time.

[...]
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: meeting?

[Wouter Verhelst]

On Fri, Aug 10, 2007 at 01:11:48PM +0200, Michael Schmitz wrote:
> > > > 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
> 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 unfortunately out of the question, but there's no reason
why we couldn't go ahead and meet in Düsseldorf?

If the reason is mainly financial: I believe getting some reimbursement
from the project is not totally out of the question; Aj said he'd set
aside some money each month for such things, and I don't think Sam has
revoked that. Or, well, if we hold it in Düsseldorf, it'll be a bus
ticket for you. I hope :-)

Or is there something else?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [mac68k] Do you want to play with a floppy ?

[Wouter Verhelst]

On Mon, Sep 03, 2007 at 11:35:26PM +0200, Laurent Vivier wrote:
>
> Le 1 sept. 07 à 01:14, Laurent Vivier a écrit :
>
>> Hi,
>>
>> EMILE, the macintosh m68k bootloader, is now able to manage "multiboot".
>>
>> If you want to play with a pre-release, download 
>> http://emile.sourceforge.net/emile-multiboot.bin
>
> It is now working with a SCSI disk:
>
> http://www.dailymotion.com/video/x2wh7g_emile-multiboot_tech
>
> you need to download .deb:
>
> http://emile.sourceforge.net/SNAPSHOT/emile_0.11_m68k.deb
> http://emile.sourceforge.net/SNAPSHOT/emile-bootblocks_0.11_all.deb
>
> You need a configuration file /boot/emile/emile.conf like this one:
>
> 8< --- cut here 
> --- >8
>
> partition   /dev/sda4
> first_level /boot/emile/first_scsi
> second_level/boot/emile/second_scsi
>
> timeout 5
> default 0
>
> title   Debian GNU/Linux, kernel 2.6.18-4-mac
> kernel  /boot/vmlinuz-2.6.18-4-mac
> argsroot=/dev/sda4 ro
> initrd  /boot/initrd.img-2.6.18-4-mac
>
> title   Debian GNU/Linux, kernel 2.2.25-mac
> kernel  /boot/vmlinuz-2.2.25-mac
> argsroot=/dev/sda4 ro

This looks suspiciously close to grub's format. I guess I'll be looking
at that to manage it. Thanks! ;-)

BTW, speaking of emile: I've been having issues getting it to work past
what's in the archive currently. I suspect compiler issues, but I'm not
sure. What are the exact compiler versions you use, currently?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Coldfire exlerator card

[Wouter Verhelst]

On Mon, Sep 03, 2007 at 09:36:14AM -0700, DataZap wrote:
> Hi,
> 
> I hope this isn't too off topic for this list.

Not really.

> Anyway, my first question is, how far along are you in porting to the
> Coldfire processor?

Not very. Grokking the compiler is my major hurdle right now.

> Secondly, I have been on the list for Coldfusion project and it looks
> like there will be a problem running Amiga OS on the Coldfire, if the
> coldfire is the only cpu.

Can you give some more detail? It's always interesting to see what other
people are running into.

> Because of this, people may lose interest in the project, but I think
> that all the work that has been done could still help people who are
> going to be running other OSes on it (like maybe LINUX).

Sure, that could always be cool. Note that you can already run Linux on
ColdFire -- just not Debian.

> Since I don't want this project to die, I am trying to get support
> anywhere I can. Would anyone be interested in buying one of these
> cards to run Debian on them?

I already have a coldfire board, but perhaps someone else...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [mac68k] Do you want to play with a floppy ?

[Wouter Verhelst]

On Tue, Sep 04, 2007 at 11:09:37PM +0200, Laurent Vivier wrote:
> Le 4 sept. 07 à 09:29, Wouter Verhelst a écrit :
>> BTW, speaking of emile: I've been having issues getting it to work past
>> what's in the archive currently. I suspect compiler issues, but I'm not
>> sure. What are the exact compiler versions you use, currently?
>
> gcc 4 generated broken code so I use gcc 3:

Darn.

> m68k-linux-gnu-gcc (GCC) 3.4.6 (Debian 3.4.6-5)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> I think I used the package toolchain from sarge to build it(and dpkg-cross 
> and apt-cross).

Well, I can't package/upload stuff if it ain't built with compilers that
are in unstable (in some way), since it has to be reproducible; but I've
been building with gcc-3.3, and that didn't work. I'll try a build with
3.4 'one of these days', see what that does.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Coldfire exlerator card

[Wouter Verhelst]

On Thu, Sep 06, 2007 at 12:12:28AM +0200, Kolbjørn Barmen wrote:
> On Tue, 4 Sep 2007, Wouter Verhelst wrote:
> 
> > Sure, that could always be cool. Note that you can already run Linux on
> > ColdFire -- just not Debian.
> 
> Any details on the linux that actually runs on it?

There's some ISO that you can download from the freescale website (after
registering, which is free)

> What kernels are these,

2.6.10, last I checked.

> which libc is used,

Not sure there.

> compatibility with "regular" m68k etc.

Not entirely, but I wouldn't be surprised if parts couldn't run
unmodified on a regular m68k machine (not the other way around, though).

[...glibc is someone else...]
-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [mac68k] Do you ant to play with a floppy ?

[Wouter Verhelst]

On Fri, Sep 07, 2007 at 11:04:05AM +1000, Finn Thain wrote:
> P.S. There is no [EMAIL PROTECTED] AFAIK.

Actually there is; it's an alias for this list.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] traveling

[Wouter Verhelst]

On Thu, Sep 20, 2007 at 07:30:25PM -0500, Stephen R Marenka wrote:
> On Thu, Sep 20, 2007 at 11:11:21PM +0200, Christian T. Steigies wrote:
> > Hi,
> > I have to go to Athens for a week and after that I might finally go on my
> > "summer" vacation to the US for a week or so. Does somebody want to handle
> > the logs for my buildds during that time?
> 
> Hopefully someone else will speak up.



-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] traveling

[Wouter Verhelst]

On Sat, Sep 22, 2007 at 08:09:55PM -0500, Stephen R Marenka wrote:
> On Sun, Sep 23, 2007 at 01:35:23AM +0200, Wouter Verhelst wrote:
> > On Thu, Sep 20, 2007 at 07:30:25PM -0500, Stephen R Marenka wrote:
> > > On Thu, Sep 20, 2007 at 11:11:21PM +0200, Christian T. Steigies wrote:
> > > > Hi,
> > > > I have to go to Athens for a week and after that I might finally go on 
> > > > my
> > > > "summer" vacation to the US for a week or so. Does somebody want to 
> > > > handle
> > > > the logs for my buildds during that time?
> > > 
> > > Hopefully someone else will speak up.
> > 
> > 
> 
> Choose from aahz, tanda, and/or kullervo. :)

Doesn't really matter. I have one machine to look after currently;
arrakis is semi-down, as are most of my own machines. If you want to
fill in for cts while he's away, take one; otherwise, I think I can
handle three machines for a couple of weeks :)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 68k programmers reference manual

[Wouter Verhelst]

On Wed, Oct 10, 2007 at 01:08:32AM -0700, Brian Morris wrote:
> hi, you guys
> 
> i downloaded today from freescale some 650 page pdf file
> it is called 68000 family programmer reference and apparently
> combines the manuals refered to in the 680x0 user manuals.
> (which are themselves good size technical books, i had seen
> the 020 before and i downloaded the 040 today).
> 
> is this the book someone could not find before ? is there difficulty
> getting it overseas because of export restrictions ?

No, I already had that one. The book I was looking for was the "System V
Application Binary Interface". However, in the mean time I did receive a
copy from a very kind soul.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

kiivi going berserk

[Wouter Verhelst]

Hi,

As most of you probably noted, kiivi went berserk the other day. It had
been misbehaving in a totally locked up state for over a week, and I
started noticing that I hadn't been receiving any mails from it anymore,
so I investigated. It appeared that it was locked up in some SSH
command, so I killed all buildd processes and hoped it'd work then.

It didn't, actually; instead, it went berserk, and it started well over
140 individual buildd processes. We've now killed buildd, I've given
back all packages, and I'll try to figure out what happened.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Wouter Verhelst]

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 the tunnel after an IP
> change).

I can recommend OpenVPN there: it'll try reconnecting every five seconds
if the link dies; it can work with SSL certificates rather than
passwords; and it's fairly reliable IME.

> I assume iptables can be tweaked to redirect port 22 for crest to port
> 2622 or whatever on sol, with similar tricks for http and smtp. I would
> have to look at some example rules to pull it off, though.

Sure. Something like this should work:

iptables -t nat -A PREROUTING -d  --dport 22 -j REDIRECT 
--redirect-to :2622

if I'm not mistaken (writing this from memory), but at the very least it
will show you what you need.

> Note that I will have to clear any of this with the biophys IT guys, and
> it would take a while to set up. Pointing crest.d.o and m68k.d.o to
> Christian's dyndns would be quicker but less functional.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Wouter Verhelst]

On Mon, Nov 12, 2007 at 04:46:51AM +0100, Michael Schmitz wrote:
> > 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 the tunnel after an IP
> > > change).
> >
> > I can recommend OpenVPN there: it'll try reconnecting every five seconds
> > if the link dies; it can work with SSL certificates rather than
> > passwords; and it's fairly reliable IME.
> 
> That would have been my first choice - haven't set it up server side yet
> but had good success with an implementation on an off the shelf firewall
> solution.
> 
> > > I assume iptables can be tweaked to redirect port 22 for crest to port
> > > 2622 or whatever on sol, with similar tricks for http and smtp. I would
> > > have to look at some example rules to pull it off, though.
> >
> > Sure. Something like this should work:
> >
> > iptables -t nat -A PREROUTING -d  --dport 22 -j REDIRECT 
> > --redirect-to :2622
> >
> > if I'm not mistaken (writing this from memory), but at the very least it
> > will show you what you need.
> 
> Thanks a bunch, I'll give that a try. I may combine tht with a tunnel on
> case the biophys guys don't feel comfortable with VPN on the firewall.

Now that it's morning rather than night: it's DNAT rather than REDIRECT

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Wouter Verhelst]

On Mon, Nov 12, 2007 at 09:09:50AM +0100, Christian T. Steigies wrote:
> On Mon, Nov 12, 2007 at 01:28:21AM +0100, Michael Schmitz wrote:
> > 
> > P.S.: new disk for kullervo? When did the old one die, then?
> 
> It did not die, none of the two tiny internal disks, nor the external disk.
> I just got tired of all the noise and weird setup, what are disks with less
> than 1GB still good for other than heating my appartment? So I finally
> bought the IDE-SCSI adapters I have been talking about for years, and a
> 250GB disk, for both crest and kullervo. crest has been using this disk for
> a least a month without any problems, other than me not being able to make
> the machine boot from the new installation, but that is probably due to the
> fact that I partitioned the disk and installed AmigaOS on it from my Amiga,
> since I have a working video out there. crest is a little picky in that
> regard (15kHz vs 31kHz modes), but I will try it again there, too, in case I
> succeed with kullervo.
> 
> Oh, ftpmaster seems to be back up, but aahz can not get packages from
> incoming anymore?
> 
> Err http://incoming.debian.org  Packages
>   403 Forbidden

Those passwords got lost. I've caught James on IRC, and he's on it.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

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

[Wouter Verhelst]

On Wed, Nov 14, 2007 at 06:17:14PM +0100, Wouter Verhelst wrote:
> On Mon, Nov 12, 2007 at 09:09:50AM +0100, Christian T. Steigies wrote:
> > Err http://incoming.debian.org  Packages
> >   403 Forbidden
> 
> Those passwords got lost. I've caught James on IRC, and he's on it.

Could anyone remind me which hosts need password access to incoming.d.o,
again? I don't know them by heart, and neither does James.

I guess these are part of them:
* Arrakis,
* Vivaldi,
* Spice
* ...?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

glibc progress?

[Wouter Verhelst]

Hi,

I recall having read on this list that someone's working on implementing
TLS support for libc/m68k currently.

How's that progressing? Do you need help?

The current situation for m68k (with us not being able to update past
glibc 2.6, IIRC) is very likely to be a dead blow to the m68k port if
that isn't fixed soon. I don't want to push that forward myself, so
here's an offer for help, if help is needed :)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Coldfire [Was: Washi]

[Wouter Verhelst]

On Sat, Nov 24, 2007 at 10:21:32PM -0800, Brian Morris wrote:
> On 11/24/07, Mark Duckworth <[EMAIL PROTECTED]> wrote:
> > Stephen R Marenka wrote:
> > > On Fri, Nov 23, 2007 at 11:56:06PM -0500, Mark Duckworth wrote:
> > >
> > >> Hello all,
> > >>
> > >> 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
> > >> again for a buildd.
> > >>
> > >
> > > Well thank you very much for the time we've had with washi. It looks
> > > like mesa is about finished, so I'll stop the buildd after that.
> > >
> > > >
> > Not the news I wanted to hear.  Could a coldfire box be of any
> > assistance?  I have a motorola coldfire EVB with the 266MHz cpu.  I'd
> > need to get some sort of USB 2.0 card for it and USB disk storage but
> > that sort of thing isn't nearly as big of an issue with linux as it is
> > for MiNT.
> 
> > Thanks
> > Mark
> >
> >
> is that a cpu that has (hardware) mmu support, or not ? I think that came
> in in 2004 and there is a 360mhz coldfire that has it, but i don't know
> about this 266. is it socketed if not ?

Yes, there are 266 ones with MMU. Mine has such a processor.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: monotone build failure - debugging help please

[Wouter Verhelst]

On Mon, Dec 10, 2007 at 01:42:11AM -0800, Zack Weinberg wrote:
> A little more than a week ago, Stephen Marenka kindly got the 68k
> buildd going on my package (monotone) and I see that a build log has
> now been uploaded for it (
> http://buildd.debian.org/fetch.cgi?pkg=monotone;ver=0.37-4;arch=m68k;stamp=1197113243
> )  Unfortunately, the build failed, due to testsuite problems.  I do
> not have access to any 68k machine so I would appreciate some help
> debugging this.  Could someone please do a trial build and investigate
> any testsuite failures you see?

I have no issue with doing this, but wouldn't you prefer doing it
yourself?

If so, I can probably fix up a machine so that you could log into that
and attempt it there.

> It appears that all the failed test cases have something to do with
> the network protocol ("netsync").  That is certainly some of the
> hairiest code in the program, but I'm kinda wondering if there is
> something unusual about the network in the sbuild environment.  (The
> test suite wants to bind a random unprivileged TCP port, on the
> loopback interface only, for every network test.)
> 
> Also, it's unlikely to be a direct cause of the problem, but I would
> like to know if the package can be persuaded to take less than 44
> hours to build by  adjusting the CFLAGS-setting logic at the top of
> debian/rules to use -O1 instead of -O2 on m68k. :)

I don't think that's very helpful. Reducing optimization to -O1 will
indeed make the build go faster, but then the resulting binary will be
quite a bit slower. I think I prefer having a faster binary over
decreasing build time.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Frame buffer use on Coldfire problem

[Wouter Verhelst]

On Wed, Dec 19, 2007 at 11:10:13AM -0500, [EMAIL PROTECTED] wrote:
> I'm running a 2.6.10 kernel on a Coldfire (M5484) and I'm trying to
> get some frame buffer graphics going.

Debian doesn't support ColdFire hardware (yet), so there's little
expertise for that hardware here. You may want to ask on the
wildrice.com ColdFire mailinglist:
https://smail.wildrice.com:7025/list/[EMAIL PROTECTED]

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug in frexp() on m68k?

[Wouter Verhelst]

On Thu, Dec 20, 2007 at 05:08:07PM +0300, Sergei Golovan wrote:
> Hi!
> 
> Could someone confirm a bug in frexp() function. Using Debian sid in
> Aranym I run the following program:
[...]
> and get the output
> 0.55, 1
> 0.05, -2147483647
> 
> which should be
> 0.55, 1
> 0.8, -3
> 
> (The result is incorrect iff the argument is less than 1 in absolute
> value). Could it be a bug in Aranym? Where to report it better?

On my IIci I do not see this problem, but that one is running etch-m68k
(since for some reason I can't seem to be able to boot 2.6 on that
machine, so sid is not an option for now).

That being said, when I look at the disassembled version of frexp in
libc 2.3.6 (the one in etch-m68k) and the same in libc 2.5, there are no
differences; so yes, this would sound like a bug in aranym.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IIci, was Bug in frexp() on m68k?

[Wouter Verhelst]

On Fri, Dec 21, 2007 at 02:15:21PM +1100, Finn Thain wrote:
> On Thu, 20 Dec 2007, Wouter Verhelst wrote:
> 
> >...
> > On my IIci I do not see this problem, but that one is running etch-m68k 
> > (since for some reason I can't seem to be able to boot 2.6 on that 
> > machine, so sid is not an option for now).
> >...
> 
> SCSI driver problem perhaps? I don't know of any other show stopper on 
> the IIci...

No, it's way before that. It gives the ABCDE... etc output, but doesn't
go any further than that. I don't recall off-hand what the latest letter
is, but I think it's the regular one, that it just doesn't switch the
framebuffer or some such.

I can give more details if you need them, but it's at the office, and I
don't plan on getting back there any time soon ;-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Another bug in ARAnyM?

[Wouter Verhelst]

On Sat, Dec 22, 2007 at 11:34:08AM +0300, Sergei Golovan wrote:
> Hi!
> 
> While playing with Erlang m68k build in ARAnyM and debugging Erlang
> shell crash I've found code similar to the following:
[...]
> The code uses implicit conversion from long to a pointer
> (the test is available at http://sgolovan.nes.ru/tmp/test.tar.gz).
> 
> In ARAnym the test gives
> 84
> -1072577264

It does so on actual hardware, too.

> while on all other machines (non-m68k though) it gives
> 84
> 84
> 
> Is this a bug in ARAnyM or it is a difference between m68k and other
> architectures?

This is definately not a bug in ARAnyM.

On m68k, there are three sets of registers: the address registers (A0
through A7), the data registers (D0 through D7), and the floating
point registers (FP0 through FP7). The m68k ABI specifies that floating
point return values should be stored in FP0, that integer return values
should be stored in D0 (or split across D0 and D1 if it's a 64-bit
value), and that pointers should be stored in A0.

Your f() function returns a 32bit integer value, so it stores it in D0.
However, your main() function thinks f() returns a pointer, so will look
for a return value in A0. A0 does not have the value you're looking for,
but something entirely different (it happens to be a constant value,
probably some bits in libc use A0 at some point during its process
initialization bits).

In short, your code is doing stuff it shouldn't be doing.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IIci, was Bug in frexp() on m68k?

[Wouter Verhelst]

On Mon, Dec 24, 2007 at 06:45:58AM -0800, Brad Boyer wrote:
> On Fri, Dec 21, 2007 at 07:58:34PM +0100, Wouter Verhelst wrote:
> > No, it's way before that. It gives the ABCDE... etc output, but doesn't
> > go any further than that. I don't recall off-hand what the latest letter
> > is, but I think it's the regular one, that it just doesn't switch the
> > framebuffer or some such.
> > 
> > I can give more details if you need them, but it's at the office, and I
> > don't plan on getting back there any time soon ;-)
> 
> Are you using the internal video?

I don't think so. It does have a NuBus video card, but I'm not 100% sure
whether I'm actually using it. I should be, since I knew about the
memory-stealing stuff, and it's already quite low on RAM. I'll check
next time I'm near the box.

Re: RAM: it might also be just a matter of "out of memory", and that it
isn't able to completely decompress the kernel or some such. I dunno
though; just guessing here.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: wanna-build state of dpkg is bogus

[Wouter Verhelst]

On Fri, Dec 28, 2007 at 11:14:52AM +0100, Luk Claes wrote:
> Hi
> 
> Please someone start the build of dpkg, the dep-wait set by wanna-build
> is bogus.

Did that earlier today. Two seconds later, kullervo took it :-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] Access to incoming.d.o?

[Wouter Verhelst]

On Wed, Jan 02, 2008 at 11:27:28AM +0100, Ingo Juergensmann wrote:
> Hi!
> 
> It's been a long time since we lost out access to incoming.d.o. Are there
> any news to this yet? Is there a plan B already? Do we need to escalate this
> issue finally? 

With hundreds of packages in needs-build? I don't think this is very
urgent. Yes, it needs doing, but we won't die if it doesn't happen.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: find segfault

[Wouter Verhelst]

On Thu, Jan 17, 2008 at 11:15:49AM -0600, Stephen R Marenka wrote:
> In current sid executing 'find /usr/bin -type d -o -ls' results in a
> segfault. This works fine in etch-m68k.
> 
> Anyone care to followup?

Having a look at it now.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: find segfault

[Wouter Verhelst]

On Tue, Jan 22, 2008 at 07:41:04PM +0100, Wouter Verhelst wrote:
> On Thu, Jan 17, 2008 at 11:15:49AM -0600, Stephen R Marenka wrote:
> > In current sid executing 'find /usr/bin -type d -o -ls' results in a
> > segfault. This works fine in etch-m68k.
> > 
> > Anyone care to followup?
> 
> Having a look at it now.

Looks like some fine register or stack corruption somewhere.


Core was generated by `find /usr/bin/ -type d -o -ls'.
Program terminated with signal 11, Segmentation fault.
#0  0x80007cba in ?? ()
(gdb) x/i $pc
0x80007cba <[EMAIL PROTECTED]>: unlk %fp
(gdb) p $fp
$1 = (void *) 0x82f888
(gdb) p $sp
$2 = (void *) 0xef82f870
(gdb) 


Unh. For some reaason, the leading byte is stripped off the frame
pointer. This is reproducable; in concurrent runs, every time the frame
pointer loses the 0xef in the beginning. Of course dropping a stack
frame is very problematic if your frame pointer is broken.

The entire subroutine looks like this:


(gdb) disass 0x80007c8e 0x80007cbd
Dump of assembler code from 0x80007c8e to 0x80007cbd:
0x80007c8e <[EMAIL PROTECTED]>: linkw %fp,#0
0x80007c92 <[EMAIL PROTECTED]>: movel 0x8001e58c ,[EMAIL PROTECTED]
0x80007c98 <[EMAIL PROTECTED]>: movel 0x8001e9bc,[EMAIL PROTECTED]
0x80007c9e <[EMAIL PROTECTED]>: movel 0x8001e9b2,[EMAIL PROTECTED]
0x80007ca4 <[EMAIL PROTECTED]>: movel %fp@(12),[EMAIL PROTECTED]
0x80007ca8 <[EMAIL PROTECTED]>: movel 0x8001e9d8,[EMAIL PROTECTED]
0x80007cae <[EMAIL PROTECTED]>: movel %fp@(8),[EMAIL PROTECTED]
0x80007cb2 <[EMAIL PROTECTED]>: bsrl 0x800093ce <[EMAIL PROTECTED]>
0x80007cb8 <[EMAIL PROTECTED]>: moveq #1,%d0
0x80007cba <[EMAIL PROTECTED]>: unlk %fp
0x80007cbc <[EMAIL PROTECTED]>: rts


If I set a breakpoint somewhere before that bsrl and inspect the
registers, everything is fine. At 800093ce, a somewhat longish
subroutine starts, with the rts at 800097ea, and many jumps in between;
and somewhere in there, that byte is lost.

Debugging this is going to be fun.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: find segfault

[Wouter Verhelst]

On Tue, Jan 22, 2008 at 08:37:36PM +0100, Wouter Verhelst wrote:
> On Tue, Jan 22, 2008 at 07:41:04PM +0100, Wouter Verhelst wrote:
> > On Thu, Jan 17, 2008 at 11:15:49AM -0600, Stephen R Marenka wrote:
> > > In current sid executing 'find /usr/bin -type d -o -ls' results in a
> > > segfault. This works fine in etch-m68k.
> > > 
> > > Anyone care to followup?
> > 
> > Having a look at it now.
> 
> Looks like some fine register or stack corruption somewhere.

Found it.

0x800093f2: 422e    clrb %fp@(-1)

Or: let's corrupt our caller's frame pointer.

Now to figure out /why/ it's doing that.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: find segfault

[Wouter Verhelst]

On Tue, Jan 22, 2008 at 11:04:34PM +0100, Wouter Verhelst wrote:
> On Tue, Jan 22, 2008 at 08:37:36PM +0100, Wouter Verhelst wrote:
> > On Tue, Jan 22, 2008 at 07:41:04PM +0100, Wouter Verhelst wrote:
> > > On Thu, Jan 17, 2008 at 11:15:49AM -0600, Stephen R Marenka wrote:
> > > > In current sid executing 'find /usr/bin -type d -o -ls' results in a
> > > > segfault. This works fine in etch-m68k.
> > > > 
> > > > Anyone care to followup?
> > > 
> > > Having a look at it now.
> > 
> > Looks like some fine register or stack corruption somewhere.
> 
> Found it.
> 
> 0x800093f2:   422e    clrb %fp@(-1)
> 
> Or: let's corrupt our caller's frame pointer.
> 
> Now to figure out /why/ it's doing that.

Turns out it's a simple off-by-one. Bug#462224.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

EMILE package testers sought

[Wouter Verhelst]

Hi,

I'm having a bit of an issue: the EMILE packages have had RC bugs filed
against them for a while now. They're small problems, but in order to be
able to fix them, I need something which I don't appear to have: a
machine able to run unstable on a 2.6 kernel. What I have is this:

- a IIci, which (AFAIK) does not run 2.6
- A Centris 650; same problem
- A Quadra 700. This one *does* run 2.6, but the kernel I've installed
  does not support the network; and apparently I can't seem to be able
  to boot its 2.2 kernel anymore (no clue why), so I can't fix the issue
  that way
- A Quadra 950. Support for this machine has always been poor, so I'm
  not really using it these days. Also, the emile build which is in the
  archive today and which worked on my IIci didn't work on the Quadra
  950, so I'm reluctant to use this machine for testing.

... that's it, I guess. If I'm mistaken, and either the Centris 650 or
the IIci should be able to run 2.6 with networking (the IIci has a NuBus
network card), then please let me know. If the most recent kernel
supports networking on the Quadra 700, please also let me know, and I'll
try that.

In case none of the above helps, I'd appreciate it if anyone could
please try out the emile packages which I've just built and are
available at [1]; if they work, I'll upload them to Debian.

Thanks,

[1] http://people.debian.org/~wouter/emile/

(Note that, apparently, I forgot to make sure the .orig.tar.gz was near
the emile directory when I built it on kiivi, so a new build is
upcoming; it should however only differ in this not being a native
package)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


signature.asc
Description: Digital signature

Re: EMILE package testers sought

[Wouter Verhelst]

On Tue, Jan 29, 2008 at 12:05:42PM +1100, Finn Thain wrote:
> On Mon, 28 Jan 2008, Wouter Verhelst wrote:
> 
> > Hi,
> > 
> > I'm having a bit of an issue: the EMILE packages have had RC bugs filed 
> > against them for a while now. They're small problems, but in order to be 
> > able to fix them, I need something which I don't appear to have: a 
> > machine able to run unstable on a 2.6 kernel. What I have is this:
> > 
> > - a IIci, which (AFAIK) does not run 2.6
> 
> At the moment I'm working on replacing the mac_esp SCSI driver, since the 
> the SCSI developers are eager to remove it from 2.6.25... I will check out 
> the IIci problem after the new driver is finished.

Great.

> > - A Centris 650; same problem
> 
> Strange. The boot failure you described recently on the IIci was one I've 
> never seen on Q650's. They generally work fine. Is this an FPU emulation 
> issue perhaps? What CPU does Penguin report?

No, that's not what I meant. Last I tried (which was a while back,
admittedly), 2.6 didn't boot properly on my Centris 650. I believe I
reported that at the time, and haven't since seen any news which would
convince me that 2.6 would now work on the Centris. Hence, "AFAIK", 2.6
wouldn't boot there.

However, if you're telling me that it should work, then that sounds as
if I should try again :-)

I'll do so later today. Thanks.

> Also, it sounds like your IIci and C650 fail early, so I'd check for 
> problems on the MacOS side: e.g. boot MacOS without extensions (hold down 
> shift when you hear the chime, release it when you "extensions disabled"). 
> Enabling virtual memory might help (see the Memory control panel).

I could try that.

> > - A Quadra 700. This one *does* run 2.6, but the kernel I've installed 
> >   does not support the network; and apparently I can't seem to be able 
> >   to boot its 2.2 kernel anymore (no clue why), so I can't fix the issue 
> >   that way
> 
> I tested my Q700 when I was working on ADB (so I think 2.6.22 works). I 
> also sent a patch for DP8390 ethernet around the same time, to bring it up 
> to par with 2.2.25.
> 
> If 2.2.25 doesn't boot, then try disabling extensions etc. If that doesn't 
> help, I'd need to know where it fails.

Okay. I'll try it and let you know where it fails -- but this might be a
while.

> > - A Quadra 950. Support for this machine has always been poor, so I'm 
> >   not really using it these days. Also, the emile build which is in the 
> >   archive today and which worked on my IIci didn't work on the Quadra 
> >   950, so I'm reluctant to use this machine for testing.
> 
> Again, my Q950 works fine except for the external SCSI bus. My new ESP 
> driver should fix that issue though.

Yes; but the main problem here isn't the kernel, it's emile. When I was
testing emile 0.10, it would work on the IIci, but not on the Q950; so
while it might be that 2.6 works flawlessly on the Q950, that doesn't
help me to test emile :-)

> > ... that's it, I guess. If I'm mistaken, and either the Centris 650 or 
> > the IIci should be able to run 2.6 with networking (the IIci has a NuBus 
> > network card), then please let me know. If the most recent kernel 
> > supports networking on the Quadra 700, please also let me know, and I'll 
> > try that.
> > 
> > In case none of the above helps, I'd appreciate it if anyone could 
> > please try out the emile packages which I've just built and are 
> > available at [1]; if they work, I'll upload them to Debian.
> 
> I'd prefer to help get your machines working than spend time on EMILE 
> right now.

Yes, that is a perfectly sane attitude. I'd prefer that too; testing by
proxy isn't the best way to maintain a package. It's just that I really
need to get emile fixed in Debian sooner rather than later, otherwise
it'll get kicked out.

Perhaps I should've chosen a better $SUBJECT. Oh well.

> I had thought that all relevant patches made it into one debian kernel or 
> another. Anyway, I think the best approach is: I shold build a kernel, 
> test it on the same hardware, and then send it to you (after I finish with 
> mac_esp that is...)

I will try a recent kernel on the Centris 650 today, and see whether
that fixes it. If not, I'll come back to you.

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: EMILE package testers sought

[Wouter Verhelst]

On Sun, Feb 03, 2008 at 11:52:31PM +0100, Eugen Paiuc wrote:
> Eugen Paiuc wrote:
>> > After upgrade to sid , I'll test emile 0.11-1 on the SCSI disk on a  
>> quadra 630 .
> q630's password:
> Linux localhost 2.6.24-1-mac #1 Fri Feb 1 00:14:53 CET 2008 m68k
> $ dpkg -l | grep emile
> ii  emile0.11-1  the Early Mac Image  
> LoadEr
> ii  emile-bootblocks 0.11-1  Boot blocks for  
> EMILE, the Early Mac Image L
>
> Emile is booting my quadra 630 , from SCSI disk.

Thanks. I've been working on getting the Centris 650 to work with 2.6,
but $WORK and FOSDEM organization intervened. Thanks for helping me
test; I'm uploading these packages as I write this.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "Illegal instruction" for most trivial of programs

[Wouter Verhelst]

On Sat, Feb 02, 2008 at 12:23:39PM -0800, James Kimble wrote:
> 
> I'm running kernel 2.6.10 on a Coldfire (5484) that I ported from a
> Freescale BSP for this family of processors.
> 
> Everything seems to work OK but I keep getting the message "Illegal
> instruction" after the execution of any program I run. For example:

You are aware that the instruction set differs between ColdFire and
"classic" m68k? I've been working on modifying the toolchain so that a
common subset would be used for Debian, allowing it to work on both
"classic" hardware and ColdFires, but that work hasn't been finished yet
(in fact, it hasn't made much progress, since I'm currently on this all
by myself). If you're trying Debian binaries, then obviously this won't
work; if you want to run Linux, you need to use the toolchain from the
Freescale BSP.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: EMILE package testers sought

[Wouter Verhelst]

On Tue, Feb 05, 2008 at 01:47:12PM +1100, Finn Thain wrote:
> What is /debian/boot? Is that part of the initrd? Or are you saying that 
> /boot could be initialized as HFS during partitioning? Penguin can use a 
> kernel on HFS of course -- I wonder if emile can?
> 
> If you make /boot HFS, the kernel is limited to a read-only mount, and so
> you'd need special tools to write to it: hfsprogs, hfsplus and/or 
> hfsutils. So installing kernel debs isn't going to be much easier.

Eh, it's not? I've been writing to HFS file systems since I first
installed Linux/m68k.

But symlinks wouldn't work; that much is true.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

FOSDEM thoughts

[Wouter Verhelst]

Hi all,

After going to a conference, I'm usually filled with ideas, and FOSDEM
is no different in that regard. Also, it was nice to finally meet cts :-)

Matthias Klose was at FOSDEM too, and he asked me whether/when we want
to make gcc-4.3 be the default compiler. I said I'd throw it on the
mailinglist; I'd think we'd want to do some testing first? Or do people
know whether it's a good idea? At least we got it to build, so that in
itself should be good :-)

The next item is some wild idea that I'd like throw up for discussion.

As I mentioned on this list before, I've been thinking it might be good
to hold a real-life meeting somewhere to discuss the future of the m68k
port; not just for Debian/m68k people, but for all Linux/m68k people
who're interested. Such a meeting hasn't happened yet, but I still think
we ought to do it; there are many things that we'd need to set a
strategy for. The obvious problem with that is that it would involve a
lot of people, and doing such a meeting might be too hard or expensive
to organize.

After watching the video team do live streaming to the world from
FOSDEM, however, I was thinking that if a real-life meeting with
everyone involved is indeed infeasible or going to be too expensive, we
might want to consider doing a video conference or some such; we could
perhaps have some people meet somewhere in Europe (Christian, Aurelien
Gérome, Ingo, Geert, Petr, Roman, ...), some in the US somewhere
(Stephen, Brad Boyer, ...), and perhaps some in some site "down under"
(Finn, Michael, Adam Conrad, ...). This would avoid the complexity of
having to multiplex a dozen video streams while still not having to fly
people around the globe (across a continent, at worst). I also (still)
think that a face-to-face meeting (even if only with the help of
technology) can /really/ help for this type of in-depth discussions, and
that it's pretty hard for us to do this over mail; but if we want to do
this with every one of us in one place, this may require some of us to
take some days off, whereas if we do this using the video conference
plan, we could do it during a weekend or some such.  We'd have to be
careful of the timezones, though, but that's obviously not impossible to
overcome.

Obviously the list of people that I gave above isn't extensive; I'm also
mentioning people such as Aurelien and Adam who both have one of the
donated ColdFire machines that we may want to decide to do something
with. They need not necessarily show up at the meeting, but perhaps we
may want them to either be involved, or give their coldfire boards to
someone else; I tried doing this alone, but that's just plain
impossible.

I was told that Debian apparently has also received an offer for holding
some meetings at Google sites, and they reportedly have equipment to
make this kind of video conferences possible; if not, I'm sure we can
find some interested people to help us somehow. It's not as if we'd have
to figure this out all by ourselves, or so.

Thoughts?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Mon, Feb 25, 2008 at 11:56:10PM +1100, Finn Thain wrote:
> On Sun, 24 Feb 2008, Wouter Verhelst wrote:
> 
> > As I mentioned on this list before, I've been thinking it might be good 
> > to hold a real-life meeting somewhere to discuss the future of the m68k 
> > port; not just for Debian/m68k people, but for all Linux/m68k people 
> > who're interested. Such a meeting hasn't happened yet, but I still think 
> > we ought to do it; there are many things that we'd need to set a 
> > strategy for.
> 
> What's on the agenda?

That would need to be worked out too, obviously, but these things spring
to mind:

* Deciding on whether we will continue to build everything, or not; and
  if not, what to limit ourselves to
* What to do with the coldfire stuff
* What to do with glibc/TLS (anyone hear from CodeSourcery?)
* Figuring out how we see the future for the port, long-term.
* And, well, getting to know eachother's faces! ;-)

I'm sure there's more, but I don't know all the questions (let alone the
answers ;-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Tue, Feb 26, 2008 at 08:41:32AM -0500, Michael Casadevall wrote:
> QEMU can emulate a coldfire processor. I'm looking into the feasibility
> of using qemu to kickstart the coldfire port.
> Michael

Yes, but it's a non-MMU coldfire emulator, last I checked. That's not
entirely helpful.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debootstrapping m68k-coldfire

[Wouter Verhelst]

On Sat, Mar 01, 2008 at 11:50:08PM -0500, Michael Casadevall wrote:
> Well, it's been discussed time and again. It's overdue; its time we 
> bootstrap the coldfire port. Roman convienced me in his email that having 
> coldfire as a seperate binary distrubution is without a shadow of a doubt 
> the only SANE way we can support both coldfire and classic m68k.

I disagree. I explained why in a reply to Roman's mail, but before it
got sent out, my laptop's hard disk died on me. Perhaps I'll still be
able to recover that, but I'm not sure.

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 don't recall who exactly, but an FTP master
did tell me that a coldfire port in Debian would only be accepted if it
was either part of the m68k port, or replaced it entirely.

To me, the latter is not acceptable, so that leaves us with the former.

You did raise a point that arm was able to have two or three ports in
the archive. This is not correct: the armel port is only accepted
because it was made clear that the arm port will be dropped after lenny;
and the armeb port, for which I've done some buildd work in the past, is
now well and truly dead. A second example is the SH port: that got
killed off because the SH porters found that the only way to proceed
forward was to split the port into two (or four) different ports, and
that was not accepted.

> I'm willing to do the grunt work on bootstrapping the port. I figure I
> should try and point out why not old a seperate port is a better way
> to go, why it won't kill classic m68k.
> 
> Reasons for having a seperate port:
>   * We can optimize to each specific architecture

- Debian is not Gentoo. Optimization is cool if we can do it, but it
  should not be an argument for or against doing something.
- AIUI, with a working TLS implementation it is possible to compile an
  optimized library, and store it under /lib/tls/ so that the
  dynamic linker will pick it up depending on the subarchitecture you're
  running on. This will not make the optimization problem go away, but
  will at least mitigate it.

>   * It can be done now; we don't need to keep monkeying around with
> binutils.
>   * We don't need to worry about any weird errors come from the
> binaries due to the different opcodes and such

These two are correct.

> Reasons why the seperate port won't kill us:
>   * Almost all work done on coldfire can easily be used on classic
> m68k; including kernel TLS and glibc porting (assuming CS ever
> comes through for us)
>   * By generating interest in the coldfire port, we can probably
> find more people who can fix gcc bugs in not only
> coldfire, but classic m68k (the backend code for GCC is pretty
> similar; 90% of it is more or less shared, with a few minor
> differences).

These also hold for any hybrid port.

>   * Freescale probably going to point to the fact that Debian runs
> on coldfire (they did give us evalution boards), and might end
> up commiting things towards the project once it gets off the
> ground.

Correct, but only as far as ColdFire goes. If we have two separate
ports, then the m68k port itself will not get that interest from
Freescale or anyone else.

My main reason for asking for the ColdFire boards was so that the m68k
port could be spared from eventual, but certain, death. By creating a
separate ColdFire port, this goal will not be achieved.

Now if everyone thinks this is the right thing to do, then I won't
object. But I just don't think it /is/ the right thing to do.

Something else: I contacted Andrew Pollock, who once offered to ask
within Google whether Debian people could hold meetings there, and he
replied, confirming that this is still possible. The only problem, of
course, is going to be the timezone issue: it's going to be possible to
get us inside a Google campus, and hooked up with eachother through
teleconferencing equipment; it's not going to be so easy to do this at
3AM local time, however. The best I seem to be able to find is to have
something start at 21:00 in Europe, which is 07:00 in Sydney and 15:00
in New York (the US time could of course differ depending on the exact
campus used there). That requires staying up late in Europe and getting
up early down under; but everything else is far worse.

Thoughts are welcome.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Tue, Feb 26, 2008 at 06:49:09PM +, Joseph S. Myers wrote:
> On Tue, 26 Feb 2008, Wouter Verhelst wrote:
> 
> > * What to do with glibc/TLS (anyone hear from CodeSourcery?)
> 
> We are currently working with Freescale's kernel engineers on finalizing 
> the kernel interface for TLS and NPTL.  We expect the toolchain and kernel 
> implementations to be completed, and contributed to FSF binutils / FSF GCC 
> / EGLIBC / kernel.org, some time this year.

That's great to know, thanks!

> Obviously Debian would then need to backport patches to the relevant 
> versions of the various components, although it's likely we will do a 
> backport to GCC 4.3 for our own use at some point.  The binutils changes 
> are likely to overlap heavily with changes for multi-GOT support for 
> ColdFire we have completed and will be contributing before starting the 
> TLS work, so backporting TLS without also backporting multi-GOT may be 
> tricky.

Given the fact that lenny is supposed to release near the end of this
year, and that the toolchain is going to be frozen sometime next month,
integrating your work into lenny is not going to be possible anymore.
Therefore, I think it's best if we just wait until your work is merged
upstream and trickles into Debian, but look out for any incompatibility
issues that might arise.

A heads-up when you're doing merges into the toolchain's respective
upstreams would be appreciated.

> (Multi-GOT addresses the issue mentioned in the ABI proposal of memory 
> address offsets on ColdFire being limited to 16 bits while avoiding the 
> larger and slower code sequences mentioned to use 32-bit offsets there.  
> Either multi-GOT, or GCC support for generating such larger code sequences 
> (also implemented and to be contributed), is needed to build some large 
> pieces of software such as PHP for ColdFire.)

Right, that makes sense

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Fri, Feb 29, 2008 at 06:18:39PM +0100, Roman Zippel wrote:
> 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, Geert and Sven about coldfire. The 
> > > consensus was that we should not make cf a separate port, since we would 
> > > probably loose all m68k developers in that case. I personally am 
> > > interested in cf only if it can help m68k,
> > 
> > That is my interest too. But surely that argues against your first 
> > statement about losing developers?
> 
> As much as I understand to keep as much as possible common, I don't have 
> much hope if I look at it from the technical perspective. IMO a common 
> port would have too much restrictions and neither could use any of the 
> advantages either architecture has to offer.

This is not entirely accurate. AIUI, a working TLS implementation will
allow us to build optimized libraries that will be chosen by the dynamic
linker at run time. If we build, say, a C library optimized for
coldfire, one for 68040, and one for 68060, I think that will greatly
improve performance already. Some more libraries (e.g., libssl, libm,
...) could benefit from this type of multi-identity stuff, too.

Of course any hybrid port will suffer from performance degradation; but
I think having any port which works on classic m68k is, by far,
preferable over not having any port, at all, that would work on classic
m68k, which is what our eventual fate will be if we don't do anything to
prevent that.

> > What concerns me is that both 680x0 and CF code would be compromised if 
> > one port were to try to support both.
> > 
> > I don't know if anyone can confirm this example, but it looks like no-one 
> > gets to use div without adding compatibility code,
> > 
> > http://acp.atari.org/articles/mcf5407eval/mcf5407eval.html#Modifications%20of%20the%20MiNT%20kernel
> 
> CF doesn't have the divul.l instruction, it has a remu.l instruction, 
> which unfortuately has the same opcode as divul.l (so the some machine 
> instruction will return quotient/remainder on m68k, but only the 
> remainder on CF).
> The trick used there produces a signed and an unsigned divide, so that gcc 
> won't merge both operations into a single instruction.

A hybrid port would just emit two opcodes in such a case, of course.
This will indeed degrade performance slightly.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Wed, Mar 05, 2008 at 05:47:43AM +0100, Roman Zippel wrote:
> 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/m68k assumes a FPU to be present, CF doesn't even know about the 
> extendend fp precision (long double), but it's currently used by m68k.

Where?

Yeah, m68k allows extended fp precision, but that doesn't mean you have
to use it. The opcodes to talk to the FPU in the other two precisions
are the same across CF and m68k, anyway; the only difference is in
FMOVEM, but that's only useful if you want to save registers on a stack,
anyway. If you just assume that it'll be taking 80 bytes per register,
even on coldfire, you'll be fine.

Of course, I might be missing something, but in that case please do
point me to it.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FOSDEM thoughts

[Wouter Verhelst]

On Wed, Mar 05, 2008 at 12:30:59AM -0500, Michael Casadevall wrote:
> Maybe this is a stupid question (and maybe unrelated), but how does 
> Debian/ARM handle FPU issues.

The FPU differences between v4 and v5 ARM is one of the main reasons the
arm port is now being replaced. The current ABI assumes an FPU and
requires the kernel to provide FPU emulation in case it's not available
(which is the case for *every* modern ARM processor). The armel ABI
assumes no FPU and requires softfloat in libraries.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ilmbase

[Wouter Verhelst]

Hi,

ilmbase failed to build properly; the test suite failed.

libilmbase-dev is a build-dependency of openexr, and libopenexr-dev is a
build-dependency of kdelibs4c2a, which lies at the root of a whole slew
of other build-deps. kdelibs4c2a is built against an outdated version of
openexr, which makes it uninstallable currently, and with it everything
that uses something related to KDE. In order to fix that situation,
ilmbase would need to be fixed.

The maintainer of ilmbase (Adeodato Simo) told me he's not very familiar
with the code (he only maintains it because some package he cares about
needs it). Anyone feel up to investigating what's going wrong?

(I'd do it, but since I'm moving currently, I have little time, if any)

On a side note, I wrote a piece of perl recently that will walk the
dependency tree until it finds a package that is uninstallable. I found
it very helpful in doing stuff I used to do manually. You can get it at
http://comp.uter.be/perl-Packages/ -- first feed a Packages file to
cache-packages; then run check-dep-waits, and specify a package name --
the script will output a suggested dep-wait line. Note that if it's a
library, you need to verify the suggestion; if the package is
uninstallable because of a soname change, then the dep-wait line is
wrong, by definition.

Also see my blog post on the subject, at
http://www.grep.be/blog/en/computer/debian/dep-wait-parser

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centris 650: buildd candidate?

[Wouter Verhelst]

On Mon, Apr 14, 2008 at 04:04:26PM -0700, Brad Boyer wrote:
> On Mon, Apr 14, 2008 at 04:12:11PM -0500, Joel Ewy wrote:
> > I recently hauled a couple carloads of computer junk away from my old
> > college, ranging from 68030 macs to Athlon 1700XP+ systems, plus WiFi
> > gear and lots of other stuff.  One of the things I received was a
> > Centris 650, which is a 25MHz 68040.  The CPU speed isn't all that
> > great, but it does have 4 72-pin SIMM sockets and I was able to get it
> > up to 136M, which is pretty good for a machine of this age.  I have a 9G
> > SCSI drive with a 50-pin connector.  The guy from the college said they
> > had lots of trouble with those 9G IBM drives, so I don't know if it's
> > any good or not, but should be useful if it works.
> 
> The extra RAM is good for builds. However, the SCSI performance on these
> systems hasn't always been particularly good.

Not too bad either. Quickstep.nixsys.be (experimental autobuilder) is a
Centris 650, too, and has the same amount of RAM (or was that 138M? Not
sure). 

It's not the fastest machine out there for sure, but it's reasonable.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Centris 650: buildd candidate?

[Wouter Verhelst]

On Tue, Apr 15, 2008 at 05:55:25PM +1000, Finn Thain wrote:
> > Even the fastest real 68k hardware would only have about double or 
> > triple the real CPU power of that system, but some of them have much 
> > better disk I/O. It might be worth seeing how long some compiles take 
> > just as a comparison.
> 
> I think the Centris 650 is a bit slower than the Quadra 650 due to system 
> bus speed? The LC040 chip in the Centris may present a problem too.

Centris 650 does not have an LC040, it has a full 040.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Coldfire PCI going to VGA/Nvidia initial Console.

[Wouter Verhelst]

On Fri, Apr 25, 2008 at 09:43:32AM -0500, John Jeffers wrote:
> Hi
>
> I have a Coldfire V4E m54455evb with MMU that runs PCI bus.  In essence  
> this would be identical to a 68060 with PCI bus but no built in frame  
> buffer and no math co-processor.

Doesn't that thing have a builtin graphical card? I know my 5475 eval
board that I got from Freescale does have a VGA connector...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ilmbase

[Wouter Verhelst]

Seems we didn't Cc the maintainer on this conversation...

On Sat, Apr 26, 2008 at 05:14:15AM +0200, Michael Schmitz wrote:
 Want me to try it with the same versions on aranym?
>>>
>>> That's probably not worth it. Do you stil have the build tree?
>>
>> No for t2 (aranym), but yes for spice (040). Something I can dump for
>> you?
>
> Just testBitPatterns.o in the HalfTest build directory would be enough.
>
> Using -O0 the test succeeds. Considering NaN handling is correct even  
> though the precise bit patterns are not preserved (by gcc, mind you) I'd  
> say these extra pedantic tests need to be disabled on m68k.

Dato, could you please do that?

> I'll see if I can find my 68881 manual (not sure it moved to NZ with
> me - I thought I'd never need that again).

Also, is this the only test that's failing?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ilmbase

[Wouter Verhelst]

On Mon, Apr 28, 2008 at 02:56:23AM +0200, Michael Schmitz wrote:
> Hi,
>
>>> Also, is this the only test that's failing?
>>
>> Nope, there was another one later on IIRC. I'll disable the PosQNan2 
>> and NegQNan* checks and investigate.
>
> It so turns out that NaN handling by the testsuite was all that fails on  
> my machine, due to compiler and binutils assumptions about what's 
> counting as NaN on m68k. Basically, cpp does substitute anything that it 
> knows to not represent a valid float by a const nan of positive sign.
>
> The following patch to the HalfTest suite makes the testsuite failure go  
> away. Please apply. In the alternative, please indicate whether a binNMU  
> would be in order.

Dato told me on IRC yesterday that it would be okay for us to do so.
Please proceed.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ilmbase

[Wouter Verhelst]

On Mon, Apr 28, 2008 at 05:15:15PM +0200, Wouter Verhelst wrote:
> On Mon, Apr 28, 2008 at 02:56:23AM +0200, Michael Schmitz wrote:
> > Hi,
> >
> >>> Also, is this the only test that's failing?
> >>
> >> Nope, there was another one later on IIRC. I'll disable the PosQNan2 
> >> and NegQNan* checks and investigate.
> >
> > It so turns out that NaN handling by the testsuite was all that fails on  
> > my machine, due to compiler and binutils assumptions about what's 
> > counting as NaN on m68k. Basically, cpp does substitute anything that it 
> > knows to not represent a valid float by a const nan of positive sign.
> >
> > The following patch to the HalfTest suite makes the testsuite failure go  
> > away. Please apply. In the alternative, please indicate whether a binNMU  
> > would be in order.
> 
> Dato told me on IRC yesterday that it would be okay for us to do so.
> Please proceed.

Hmm. It was pointed out to me on IRC that you've done a binary-only
upload, without the source changes that are needed to build the package.
That makes this build non-reproducible, which is a big no-no.

Can you reupload, this time with source (and version number bump)?
Thanks.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] Implications of DSA-1571-1

[Wouter Verhelst]

On Tue, May 13, 2008 at 08:00:53PM +0200, Ingo Juergensmann wrote:
> Hi!
> 
> http://lists.debian.org/debian-security-announce/2008/msg00152.html
> 
> The latest SSL remote "problem" has some serious issues for the buildds: 
> 
> | Permission denied (publickey,keyboard-interactive).
> | May 13 18:02:27 buildd: wanna-build --list=needs-build --dist=unstable
> | failed; status 255/0
> 
> Because of all *.d.o machines have disabled SSH pub key logins now, no
> buildd is able to build packages anymore - until the new SSL version is
> installed and all buildds have regenerated keys and have those keys uploaded
> and installed on the wanna-build host again. 
> 
> Well, those machines that were installed before etch, should be safe. Can
> anyone confirm this?

Only if you have an RSA key. DSA (as in, Digital Signature Algorithm)
keys should be considered compromised, too, since they use the OpenSSL
randomizer, which is buggy.

DSA (as in, Debian System Administration) is however aware of the
problem, and it should probably be fair to say that they'll give this
higher priority than other issues currently.

> Is there already a fixed version available in etch-m68k?

Not that I know of. We should work on that.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] Implications of DSA-1571-1

[Wouter Verhelst]

On Thu, May 15, 2008 at 02:16:25AM +0200, Michael Schmitz wrote:
>>> Well, those machines that were installed before etch, should be safe. Can
>>> anyone confirm this?
>>
>> Only if you have an RSA key. DSA (as in, Digital Signature Algorithm)
>> keys should be considered compromised, too, since they use the OpenSSL
>> randomizer, which is buggy.
>
> q650 has libssl0.9.7 0.9.7e-3sarge1 - the advisory said the bug was 
> introduced with 0.9.8c. So it would seem sarge installs are in the clear. 
> Can we confirm that in some way?

Ah, yes, that's true.

> Can we backport the fixes to sarge if necessary?

It isn't.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] getting w-b access back?

[Wouter Verhelst]

On Tue, Jun 10, 2008 at 08:51:22AM -0500, Stephen R Marenka wrote:
> On Sun, Jun 08, 2008 at 10:06:17AM -0500, Stephen R Marenka wrote:
> 
> > If I can be of any service in helping to get the m68k buildds access to
> > buildd.d.o again or anything else, please let me know.
> 
> Ryan replied back, so here we go. He wants new keys and updated email
> addresses. I plan to generate new keys and I have email addresses for
> all the current buildds except hobbes, quickstep, and jazz. The latter 
> two of which I don't know if they're still functioning or not.

Quickstep is working as an experimental buildd currently. Probably best
to keep it at that. Since experimental building requires patched sbuild
and buildd, mixing it with unstable is also not a very good idea.

Jazz I haven't powered on in a looong time. I'm also not sure whether
2.6 even runs on that machine, since it's been so long (Quadra 950)

I'll probably revive ska some time soon. It was shut down when its hard
disk died a while back, but I have more disks...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: m68k Developers Meeting

[Wouter Verhelst]

On Sat, Jun 28, 2008 at 02:25:26PM +0200, Martin Schulze wrote:
> Wouter Verhelst wrote:
> > On Tue, Jun 24, 2008 at 11:17:07AM +0200, Ingo Juergensmann wrote:
> > > On Wed, Jun 18, 2008 at 05:14:37PM +0200, Christian T. Steigies wrote:
> > > 
> > > > We should ask all m68k developers (Geert?, Roman?). With sufficient 
> > > > warning
> > > > even people from outside europe might be able to attend. What about the
> > > > aranym developers? CT60 people?
> > > 
> > > How about oversea-developers? Would it be possible to get some money spent
> > > by the project to fly in a developer? 
> > 
> > I don't think that's too unreasonable. I'll ask our DPL about it; if he
> > agrees, I think we should at least invite Stephen too, and some of the
> > overseas Kernel hackers.
> 
> Ack.  Did Steve respond yet?

He did; I thought I'd forwarded that, but apparently not so--sorry about
that. He's tentatively agreed on doing this, provided we don't overdo
it; reimbursing one or two people should be okay, (much) more is not
likely to.

We should probably fly Stephen across; is there anyone else?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Lenny release plans

[Wouter Verhelst]

On Wed, Aug 06, 2008 at 05:17:14PM -0400, Michael Casadevall wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I figure since lenny is now frozen, its time to talk about our plans
> for a lenny-m68k release. Talking with Stephen, the current plan of
> attack is something as follows:
> 
> 1. Install dak on a machine on nemesisnetworks (sorta done, still
> needs some configuration).
> 2. Import GPG keys of anyone who should have upload rights. (we can
> limit this to 68k buildd admins, or just dump the entire debian
> keyring here)

I think it's best if we just dump the entire debian keyring, yeah. If
push comes to shove, we can always add our own keys.

> 3. Import the unstable snapshot from the day of the lenny freeze into dak

I'd think a testing snapshot is better (or should at least also be part
of it). Unstable on the day testing is frozen is going to be extremely
different from testing...

> 4. Create a wanna-build tracking lenny-purposed-updates, and
> lenny-security (I have scripts that do this already)
> 5. Find voluteers to run autobuilders for both branches (we will
> likely also have a temporary tree lenny-transition or something
> handling the changes from the unstable snapshot until now).

I can probably revive a few machines.

> 6. Setup packages.nemesisnetworks.com again
> 7. Find people who can mirror off my server
> 8. Rebuild d-i with our mirrors list.
> 9. Select archive admins to handle managing the NEW queue, especially
> w.r.t to m68k specific patches to lenny.
> 10. Maybe offer the same services to other ports that are not
> releasing with lenny since the infrastructure will already be in
> place.

Sounds reasonable.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Lenny release plans

[Wouter Verhelst]

On Mon, Aug 11, 2008 at 10:50:09AM +0200, Michael Schmitz wrote:
> Hi,
>
>> On Wed, Aug 06, 2008 at 05:17:14PM -0400, Michael Casadevall wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> I figure since lenny is now frozen, its time to talk about our plans
>>> for a lenny-m68k release. Talking with Stephen, the current plan of
>>> attack is something as follows:
>>>
>>> 1. Install dak on a machine on nemesisnetworks (sorta done, still
>>> needs some configuration).
>>> 2. Import GPG keys of anyone who should have upload rights. (we can
>>> limit this to 68k buildd admins, or just dump the entire debian
>>> keyring here)
>>
>> I think it's best if we just dump the entire debian keyring, yeah. If
>> push comes to shove, we can always add our own keys.
>
> Yup - after all, anyone can build their own m68k packages on ARAnyM if  
> they feel like it.

Exactly. Or on live hardware, if they have any.

>>> 3. Import the unstable snapshot from the day of the lenny freeze into dak
>>
>> I'd think a testing snapshot is better (or should at least also be part
>> of it). Unstable on the day testing is frozen is going to be extremely
>> different from testing...
>
> The testing snapshot is what we need, unless you talk about a separate 
> unstable-m68k as well (are we being kicked out yet?)

By the sound of what I hear here at Debconf, we probably will be after
Lenny is released (though we'll still have a chance of getting in again
if we can get our libc fixed and our unstable/testing into shape)

>>> 4. Create a wanna-build tracking lenny-purposed-updates, and
>>> lenny-security (I have scripts that do this already)
>>> 5. Find voluteers to run autobuilders for both branches (we will
>>> likely also have a temporary tree lenny-transition or something
>>> handling the changes from the unstable snapshot until now).
>>
>> I can probably revive a few machines.
>
> I can add lenny-security and -p-u to hobbes' chroot list (or run ARAnyM  
> for that purpose).

Just for reference the "few machines" I was thinking about were ska (VME
box that I got as a donation a few years back, not sure we still have a
working kernel?) and jazz (Quadra 950 which I recently updated so that
it runs 2.6 now)

>>> 6. Setup packages.nemesisnetworks.com again
>>> 7. Find people who can mirror off my server
>>> 8. Rebuild d-i with our mirrors list.
>
> Can we leave most of the mirrors in place, and just add dedicated m68k  
> mirror / package list for the patched m68k packages? I.e. if we can use  
> something from main, don't bother duplicating?

Probably, but we'll need to rebuild d-i anyway if we want to use a
separate mirror list.

[...]
>>> 10. Maybe offer the same services to other ports that are not
>>> releasing with lenny since the infrastructure will already be in
>>> place.
>
> Separate admins needed here?

It's probably good to remember that debian-ports already exists...

Something entirely different: Debconf is being followed by quite a few
people through the video streams (see http://video.debconf.org:8000/ if
you care to peek), and I was thinking that it could be a good idea to
set up a stream such as that one in Kiel, too. If we can get a camera
with Firewire-connection and a desktop that's powerful enough and has
enough diskspace to store the recording (13G per hour), and the network
connection is good enough (don't expect that to be a problem at a
university) then that would give us two benefits:
- videos for posterity (we'll probably be able to convince holger that
  it's a good idea to host them on meetings-archive.debian.net)
- allowing those who can't make it to Kiel to join to some extent
  through IRC and the video stream.

What do other people think?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Lenny release plans

[Wouter Verhelst]

On Mon, Aug 11, 2008 at 09:42:01PM -0400, Michael Casadevall wrote:
> By the unstable snapshot, I meant a snapshot of unstable from the day
> lenny was frozen. As of now, I have the packages list setup imported,
> but I'm having trouble with the dak import script. I'm mulling over
> using mini-dak for the time being instead of its big brother (I'll
> replace it with dak if/when we decide to run a normal testing).
> Roughly 600-700ish packages need to be built since we don't have
> matching lenny revisions, and we need to go through and determine what
> packages we need to upgrade ourselves (known: gcc and friends, since
> lenny has 4.3-2, and we're at 4.3-8 which has quite a few good fixes).
> 
> For versioning, we should probably mark any m68k specific changes like
> the way Ubuntu does it. Roughly speaking, if we're taking gcc-4.3-8
> and replacing it with whats in lenny, make it gcc_4.3-8m68k1 or
> something like that. This also

This also... what? ;-)

> I do know about d-ports (they'll be hosting our w-b database if
> aurel32 made the changes to allow that), but they run mini-dak, which
> will making having both an unstable and a stable hosted with them
> somewhat difficult. If we ever want to have a "normal" testing
> archive, we also need to switch to dak since it generates a LOT of
> metadata britney needs to run (that, or someone needs to rip the
> urgency and bugscanner code out of it, and extend mini-dak).
> 
> We have some packaging tasks we need to do, anyone want to voluteer on
> any of these?
> 
> 1. glibc 2.5 needs to be repackaged as a separate package so we can
> properly make fixes to it
> 
> 2. The previously methoned changes to d-i.
> 
> 3. gcc and friends need to be imported; we need to figure out some
> sorta policy on how to handle these.
> 
> 4. sbuild and buildd need to be extended to upload source packages so
> I don't need to manually import every source package. (Ideally, we'll
> have a crontab that runs quinn-diff against our lenny-m68k Packages
> file, and the Sources file from Debian lenny, all the buildds will
> have two deb-src lines, our mirrors, and the debian mirrors, and
> simply upload the source package as they build things).
> 
> sbuild already has an -s switch to include source, but it generates a
> Debian native package. To fix this, someone needs to simply make sure
> the original tarball gets copied to /build/buildd next to the source
> directly. Its a simple change, but I suck with perl, so I'm not the
> man for this task.

I could look into this, I guess; but I'm not very wide on time these
days.

> 5. Someone needs to make sure debootstrap works right once the
> glibc2.5 package is in place, and marked Essential: Yes.

glibc should not be marked essential: yes, otherwise we won't be able to
upgrade to glibc 2.7 afterwards. Think about it! :-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Discussions

[Wouter Verhelst]

Hi,

Ingo will be arriving around 12:00 to 12:30, which is one hour from now.
Given that 12:30 is 22:30 in New Zealand, we were hoping that Michael
could join in around that time.

Michael, could you join the channel, and shout? If you see this mail too
late, we can do something else, surely.

(Yeah, we probably should have been deciding that earlier -- sorry about
that)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

xemacs21

[Wouter Verhelst]

Hi,

I was going to build xemacs21 to try and figure out why it's segfaulting
on startup, but then found that I can't currently access any of my
non-buildd machines, and that the Needs-Build queue is mostly empty, so
I've just put it in needs-build again. It will most likely segfault, as
it did before; would whoever gets to have to deal with the logs kindly
*not* throw out the build tree, but tar it up and put it online
somewhere for me to debug?

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Discussions

[Wouter Verhelst]

On Sat, Aug 30, 2008 at 06:55:35PM +0200, Michael Schmitz wrote:
> Hi All,
>
>> Ingo will be arriving around 12:00 to 12:30, which is one hour from now.
>> Given that 12:30 is 22:30 in New Zealand, we were hoping that Michael
>> could join in around that time.
>>
>> Michael, could you join the channel, and shout? If you see this mail too
>> late, we can do something else, surely.
>
> Sorry, I _did_ see the mail too late by six hours :-( TBH, I caugt some  
> sort of bug and decided to sleep it off.

Aha.

Well, we did postpone the stuff about the future of m68k, since we
hadn't seen a reply from you. Possible options would've been 'when
Michael wakes up', or 'tomorrow, around 10:00 CEST' (which would be
20:00 NZST).

Since we're about to eat now, I guess the latter will be what we'll do.
That okay with you?

>> (Yeah, we probably should have been deciding that earlier -- sorry about
>> that)
>
> NP - I can perhaps join later. When do you plan to go for dinner break?

Now, approximately; Stephen and cts are firing up the barbeque.

In fact I did see you join the channel about an hour ago, but I was
_just_ too late to say hi. By two seconds. :-)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2008 M68k Porter Meeting

[Wouter Verhelst]

On Fri, Sep 05, 2008 at 07:29:29PM +0200, Riccardo wrote:
> Hey,
>
> nice you had your meeting. I tried all three days to log into  
> #debian-68k on freenode, but it was always empty.

We were on OFTC...

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Coldfire Boards

[Wouter Verhelst]

On Mon, Sep 01, 2008 at 05:38:09PM -0400, Michael Casadevall wrote:
> I should have been more clear. These boards did come with BDM modules,
> but my board came second hand from another developer who either lost it
> or simply forgot to send it along (I'm hoping its the later). The board
> I received was in a shoebox with a few papers, the mini-ITX baseboard,
> and the Fire Engine itself and its power adapter. No cabling or the BDM
> was included.
> 
> Woutcher (youpi) to my knowledge is using the latest BSP (and so am I

Just to make something clear: my name is Wouter, and my IRC nickname
(which I prefer to avoid whenever possible) is 'Yoe' :-)

> when I built my kernel and JFFS2 image), but he's also unwilling to
> override dBUG so he's using u-boot 2 beta which seems to have issues
> booting the kernel.

I'm not unwilling to do that; but I've never played with this BDM thing
before, so I'm only going to do it when I have the time to deal with it
if necessary.

> Our boards in general are from 2004-ish, and were acquired from
> Freescale when we told them we wished to port Debian to Coldfire. We got
> roughly a mix of boards if previous posts are correct, mine is a m5478 I
> believe if I read the specs right. I can't say what anyone else got.
> Michael.

You have an M5475EVB, as do I. An M5474Lite was shipped to Christian,
and and has now been given to Roman. An M5485EVB was shipped to Adam
Conrad, but we're going to ask him to ship it to Michael Schmitz.
Finally, another board was originally shipped to Sven Luther and is now
with Aurélien Gérome; I don't recall what type of board that is (I
*think* it's also an M5474Lite).

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push

[Wouter Verhelst]

On Thu, Sep 04, 2008 at 11:57:56PM +0200, Michael Schmitz wrote:
> Regarding performance afforded by having a 100 Mbit PHY instead of a 10 Mbit
> one:
>
> EtherNAT: 210 KB/s out, 140 KB/s in (scp of a 35 MB vmlinux file)
> EtherNEC: 175 KB/s out, 128 KB/s in (same file)
>
> Hardly worth it, eh?

Well, if you're going to do scp, you're CPU-bound rather than NIC-bound,
since SCP needs to encrypt. What happens if you use something less
taxing on the CPU, like HTTP or some such?

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [buildd] moving to dports, volume 1

[Wouter Verhelst]

On Thu, Sep 04, 2008 at 12:35:15PM -0500, Stephen R Marenka wrote:
> debian-ports has a limited number of GPG keys allowed to upload
> packages.
> 
> Should any other dd's (like to) be on this list?

I was under the impression we were just going to rsync from
keyring.debian.org?

At least for sourceful uploads, I do think that's a good idea.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: people.debian.org/~cts/ site missing

[Wouter Verhelst]

On Tue, Sep 30, 2008 at 07:36:32PM +0200, Christian T. Steigies wrote:
> On Wed, Sep 24, 2008 at 08:26:40PM -0500, Stephen R Marenka wrote:
> > On Wed, Sep 24, 2008 at 03:39:49PM -0500, Lance Tagliapietra wrote:
> > > Christian,
> > > 
> > > I noticed that your http://people.debian.org/~cts/ pages are not
> > > available anymore.   I was looking at the wiki.debian.org/M68k and
> > > noticed the link to your home page was broken.
> > > 
> > > Just thought you'd like to know.
> > 
> > people.d.o moved from gluck to ravel. I'm guessing Christian hasn't
> > had time to move his stuff yet. :)
> 
> Move stuff? I just came back from my vacation, there is just a little bit of
> travel left for the rest of the year. I heard about a new people machine,
> but I have to copy my files to that machine?

Actually, it's there, but in a /org/oldpeople or something directory.
You just need to mv stuff to where you want it.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: exim performance hint

[Wouter Verhelst]

On Wed, Oct 01, 2008 at 07:07:36AM +0200, Ingo Juergensmann wrote:
> On Tue, Sep 30, 2008 at 05:19:05PM -0500, Lance Tagliapietra wrote:
> 
> > Looking closer, exim is run by a cron task periodically, to try to
> > re-send email that could not be sent, or was queued for some reason.  If
> > the message could not be delivered, it sits in the queue.  Due to a
> > mis-configuration of exim, I had system messages to root sitting in
> > there, all the mail to support popularity-contest, and others, for about
> > 6 years!  There were about 1000 files there to be processed, each time,
> > which simply took time.
> > [...]
> > Note that all this time I was able to send email/ receive email and
> > didn't really know about much system generated email.
> 
> You could run exim -d -qff  to see why those mails in the queue are
> failing. 
> 
> I suffered from a similar problem once and wrote a little Python script to
> deal with this problem. It tries to flush the queue and depending on the
> error code it gets back, it either tries to deliver the mail again, spool it
> again or simply delete it. If it can't send mails for a certain amount of
> time in the queue, it deletes the mail as well. 

Actually, exim can do that itself. Just set 'timeout_frozen_after' to a
sane value (say, '1 month' or some such), and exim will remove all
frozen mails that it can't deal with after a while.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Architecture usertags

[Wouter Verhelst]

Hi,

I've often thought that it would be useful to have tags in the BTS so
that users or maintainers could mark a bug as specific to a particular
architecture. This way, when I have some spare time, I could go to the
BTS, fetch a list of bugs that are specific to an architecture I care
about, and see what I can do about them, or give some feedback if that
would help.

Using a set of usertags under my own email address on the BTS wouldn't
really work for that, since it kindof defeats the whole purpose; I want
to use these tags to find bugs that I care about in the first place, but
in order for me to be able to add a usertag, I would have to know about
the bug before I could find it. Kind of a chicken-and-egg problem.

So I suggested to Don Armstrong that he add a set of
architecture-specific regular tags; but he seemed averse to this, as the
current informal policy of the debbugs maintainers is to require that a
usertag is used for a particular purpose before they add a new regular
tag; this is so that no tags get created which won't be used. I guess
this is a worty goal.

After a short discussion on IRC, we came up with another option: a set
of publically documented usertags, the definition of which would be
announced on debian-devel-announce and linked to from the BTS homepage,
so that maintainers could apply them to architecture-specific bugs when
necessary. The format, suggested by Steve Langasek, was to use the
porters mailinglist as the user, and the architecture name as the
usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
tag).

Before I'll fire off an email to d-d-a announcing that, does anyone have
any comments, objections, or suggestions to improve this proposal?

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


signature.asc
Description: Digital signature

Re: Architecture usertags

[Wouter Verhelst]

On Thu, Mar 05, 2009 at 11:22:19AM +0100, Peter Palfrader wrote:
> On Tue, 03 Mar 2009, Wouter Verhelst wrote:
> 
> >The format, suggested by Steve Langasek, was to use the
> > porters mailinglist as the user, and the architecture name as the
> > usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
> > tag).
> 
> Or debian-po...@lists.debian.org as user.

I did not think that would be a good idea, since the AFAIK the bts will
send out a mail to the mail address listed as user when a usertag is
set; it is okay if adding a 'powerpc' tag causes a mail to be sent to
the powerpc mailinglist; I do not think it is okay if that would cause a
mail to be sent to _all_ porter mailinglists.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

perl?

[Wouter Verhelst]

Hi,

I've got perl held at 5.8.something; I vaguely remember it being because
5.10 was broken for us, but I don't remember the details.

Is this still the case, or should I just drop the 'hold' status?

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

libc6/libgcc2/kiivi

[Wouter Verhelst]

Hi,

(not 100% sure that this hasn't already been mentioned here; I vaguely
seem to remember that -- but better say it once too often rather than
not at all).

I thought to update kiivi. Since it was proving troublesome, I thought
it best to remove build-essential 'temporarily' so that I could update,
and then reinstall it.

Turns out libc6 requires libgcc2, which is no longer available (unless
one installs stable). Since upgrading gcc to a fairly recent version now
conflicts against libgcc2, too, upgrading would require throwing libc6
off the system, which obviously won't happen.

This means we have to do a binNMU of libc6, which is going to be fun.

How do we proceed?

(NB: the above obviously also means that kiivi won't be building until
I get a working compiler on it again. Hints are welcome).

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: m68k sources

[Wouter Verhelst]

On Mon, Jun 22, 2009 at 11:19:41PM +0200, Riccardo wrote:
> Hi fellow debianers,
> 
> what do you use for sources for apt?

You need to use the debian-ports.org mirror network; other things will
not work.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: m68k interpreter

[Wouter Verhelst]

On Wed, Mar 17, 2010 at 11:34:45PM +0100, Xavier Oswald wrote:
> Hi folks,
> 
> Im looking for a m68k interpreter and an assembly compiler under linux and
> even better under debian.

Do you mean an emulator?

There's ARAnyM, which is packaged, if it may help you. Not sure if
that's what you're looking for.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100317230403.gd15...@celtic.nixsys.be

gcc 4.5 and TLS

[Wouter Verhelst]

Hi all,

GCC 4.5 was released not so long ago, and one of the new features listed
on its changes page[1] is TLS support for m68k/ColdFire.

Does anyone know what the status of this support is in libc? If so,
could we look into re-bootstrapping the port and starting to build
up-to-date packages again?

Or have we collectively lost interest and should we just let it die?

[1] http://gcc.gnu.org/gcc-4.5/changes.html

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100419094329.gi28...@celtic.nixsys.be

Re: gcc 4.5 and TLS

[Wouter Verhelst]

On Mon, Apr 19, 2010 at 12:05:39PM +0200, Ingo Jürgensmann wrote:
> On Mon, Apr 19, 2010 at 11:43:29AM +0200, Wouter Verhelst wrote:
> 
> > Or have we collectively lost interest and should we just let it die?
> 
> Well, motivation is somewhat lower after not being an official part of
> Debian anymore, but I still like m68k and would keep my machines running.

I could revive some hosts, too, though it would involve some work.

But the point is not machines; if they are set up, in general they will
keep running (module age issues). The point is how much time we're
willing to put in. I'm still interested in getting this hybrid ColdFire
thing working, but not if I end up being the only one to work on it
again. I'd also need to get a fairly up-to-date environment to work on
my coldfire board.

> So, when there's a chance to have an up-to-date archive, I would welcome it. 
> Though, we should consider to not build everything just for the sake of
> being able to do so. 

We should be careful in how we prioritize packages. We should not let
buildd hosts sit idle if there are things they might be able to build.

Also, adding more computing power is, in general, just a scalability
issue. Adding more manpower is something else.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100419110138.gj28...@celtic.nixsys.be

Re: gcc 4.5 and TLS

[Wouter Verhelst]

On Mon, Apr 19, 2010 at 09:33:54PM +1000, fth...@telegraphics.com.au wrote:
> 
> On Mon, 19 Apr 2010, Wouter Verhelst wrote:
> 
> > Does anyone know what the status of this support is in libc?
> 
> This was the situation a month ago--
> http://lists.debian.org/debian-68k/2010/03/msg00014.html

Right. I should've been a bit more awake. Guess the DPL vote took too
much of my attention...

> It appears that the eglibc repo has the patches in HEAD now.

Cool. That means we'll have to wait for that to trickle down then,
before we'll be able to make things work again.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100419130620.ga6...@celtic.nixsys.be

FOSDEM?

[Wouter Verhelst]

Hi,

Anyone here who'll be at FOSDEM? I think it'd be nice to meet up and see
what we can do for the future.

(I know, I've not been very active in the m68k port lately, but I'd like
to pick that up again...)

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20110121144957.gd20...@celtic.nixsys.be

d-i built (but not tested)

[Wouter Verhelst]

Hi,

I spent some time fighting with d-i, and have eventually come up with a
successful build:

http://people.debian.org/~wouter/di-m68k/

It's not been tested, however; people willing to do that would be most
welcome.

Note that unstable is very much incomplete currently. You should be able
to install a very basic base system with this, but I can't guarantee
much beyond that. Hopefully with these installer images (if they work),
we'll be more easily able to resurrect some buildd hosts and fix that
problem.

Regards,

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


signature.asc
Description: Digital signature

Re: d-i built (but not tested)

[Wouter Verhelst]

On Thu, Aug 11, 2011 at 01:48:31PM +1000, Finn Thain wrote:
> 
> Hi Wouter,
> 
> On Wed, 27 Jul 2011, Wouter Verhelst wrote:
> 
> > Hi,
> > 
> > I spent some time fighting with d-i, and have eventually come up with a 
> > successful build:
> 
> Thanks for doing this.

You're welcome. Thanks for testing; I hadn't found the time myself yet
(but this should happen soon, I hope).

> > http://people.debian.org/~wouter/di-m68k/
> > 
> > It's not been tested, however; people willing to do that would be most 
> > welcome.
> 
> First thing I found was that the mac kernel has the serial console 
> disabled. Is that normal for di kernels?

d-i kernels are no different from 'regular' kernels (they're repacked,
but not recompiled). If the serial console doesn't work from d-i, it
won't work from the installed system, either--unless the serial driver
is compiled as a module or some such and not packaged for d-i, but I
doubt that's the case.

> My first boot attempt wasn't very successful -- my powerbook switches 
> itself off after the kernel logs this:
> Trying to unpack rootfs image as initramfs...
> 
> I'm sure I have seen powerbooks do this before. Too long ago to recall the 
> details though. The only remedy I could think of was the ramdisk_size 
> kernel argument but it didn't help. This bug also affects the mainline 
> kernel, BTW.

ramdisk_size helps for actual ramdisks, but not for an initramfs (an
initramfs is dynamic in size, and only uses as much memory as it needs
to).

> As a workaround, I converted the initrd from cpio to ext2 image.

And then it worked? Weird.

> Next I ran into the mac_scsi bug (which also affects the mainline kernel), 
> so I built a 2.6.39 kernel with serial console, ATAoE and no mac_scsi.
> 
> This got me to the installer (in low memory mode as this is only a 36 MB 
> machine).

Great.

> The syslog below is for the cdrom installer. I also tried nativehd and 
> hd-media; everything seems to work (serial console and fb console) up to 
> the point that an ISO is required.

Hrm.

I was under the impression that we had at least one flavour which would
allow you to install by downloading stuff from the internet, as in the
netboot option, without requiring the use of a local ISO, but I'm not
sure which variant that would be.

Stephen? Do you have any idea? Or am I just dreaming here?

> > Note that unstable is very much incomplete currently. You should be able 
> > to install a very basic base system with this, but I can't guarantee 
> > much beyond that. Hopefully with these installer images (if they work), 
> > we'll be more easily able to resurrect some buildd hosts and fix that 
> > problem.
> 
> Is there an ISO image -- or some way to install without one (besides 
> debootstrap)?

In theory, the installer should allow you to install from the Internet,
if you can select the debian-ports.org mirror -- but like I said, I'm
not sure.

At any rate, this:

[...]
> Aug 11 12:50:33 main-menu[494]: INFO: Menu item 'load-cdrom' selected
> Aug 11 12:50:35 anna[623]: grep: /cdrom/dists/stable/Release: No such file or 
> directory
> Aug 11 12:50:35 cdrom-retriever: error: No components listed in 
> /cdrom/dists/stable/Release.
[...]
> Aug 11 12:50:45 anna[623]: WARNING **: bad d-i Packages file

... is promising. It finds no Packages file, but that's expected, as
there isn't any; but the fact that we even get this far (after some
prodding) is good.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20110811135119.gb26...@grep.be