[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When will amd64 be allowed in sid?

On Fri, May 07, 2004 at 08:38:00AM +0200, Kurt Roeckx wrote:
> > I've put together a pure64 chroot right now, but
> > 	a) libc6-dev (and thus all other lib<...>-dev) is not installable
> > 	b) dpkg-dev is not installable either, which turns building any
> > packages on that puppy into a very interesting exercise, to put it mildly.
> There is a dpkg-dev on alioth that should work.

... if you have perl and perl-modules (available on your site, but not
elsewhere, AFAICS)
> Why isn't libc6-dev installable?

Depends: linux-kernel-headers, same story as above.

> > After some digging around I've found (your, AFAICS) collection of packages
> > including the missing stuff, but...   Could you upload them on alioth?
> > Would help to avoid a lot of PITA...
> I am currently uploading alot of packages too alioth.  Please let
> me know which are missing there so I can upload them.

	Well, the obvious candidates are perl{,-modules,-base} and
linux-kernel-headers.  You already have them and they are needed for
pretty much any build.

> > Al, still not at the point when building the kernel on pure64 would be
> > possible (biarch setup allows to do that fine).
> I was able to compile a kernel on it ages ago but I don't think
> you currently can build it with IA32 emulation.

It builds once the missing packages are added.  IA32 emulation works fine -
outside of that chroot I have current testing/i386 and there had been no
problems with it.

BTW, I've looked into the situation with lilo.  *Ouch*.  I've got bin86
to build, actually (other packages from the same source need work on
porting, but that one is not a big deal).  However, lilo itself... ;-/
Too many places relying on sizeof(long) == 4, unholy mess of random uses
of int and long for pretty much anything - time_t, dev_t, block numbers,
on-disk data of all sorts...

It's not even that hard to fix.  The thing is, patch will be very large.
It is trivial, but it touches a lot of lines all over the place.  And
upstream is, AFAICS, interested in bogus features and not much else;
he definitely hadn't bothered to clean the codebase up.  Hell knows - I
might just fork the damn thing, make sure it produces the same binaries
on i386 and works on amd64.  I'll look into that; AFAICS it's either
a fork or just declaring lilo hopeless and switching to syslinux on amd64

Reply to: