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

Re: The non-existent unofficial sarge for amd64



Anders Boström <anders@netinsight.se> writes:

>>>>>> "GvB" == Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
>
> Hi Goswin!
>
>  GvB> Anders Boström <anders@netinsight.se> writes:
>  >>>>>>> "KR" == Kurt Roeckx <Q@ping.be> writes:
>  >> 
>  KR> On Fri, Jan 07, 2005 at 04:35:28PM +0100, Anders Boström wrote:
>  >> >> 
>  >> >> As I wrote in my original question is /debian-pure64 not updated. Last
>  >> >> update was 20041215.
>
>  GvB> Small update. Q did build a few new packages but he didn't override
>  GvB> the distribution to testing in the changes file and the packages ended
>  GvB> up in sid. The sid->sarge propagation (see below) should take care of
>  GvB> that at some point so I keep them as is as testcases.
>
>  KR> Goswin seems to be rather sick at the moment.  You will have to
>  KR> wait until he's back.
>  >> 
>  KR> I can't do anything about this until he's back.
>  >> 
>  >> Another week has gone, and still no update of /debian-pure64
>  >> testing. Is the "unofficial sarge for amd64" dead?
>  >> 
>  >> Is the whole amd64 port of debian dependent of one person (Goswin)???
>
>  GvB> As for the sarge port, yes, everything is waiting for me and I'm sorry
>  GvB> for the delay.
>
> OK, I didn't realize that it was a manual process to move packets from
> sid to sarge for amd64. I thought it was an automated process as for
> the official debian architectures.

All of the archive is started from scratch and made as we went
along. Basically nothing of the very complex DAK is in use in the
debian-amd64 archive for various reasons like it being to complex and
needing to many services.

>  GvB> But the debian amd64 port is far more than the sarge port and both
>  GvB> pure64 sid and the gcc-3.4/4.0 build repository are fully staffed and
>  GvB> working.
>
>
>  GvB> If you are specifically interested in getting sarge more in sync with
>  GvB> the official sarge you can join the team and familarize yourself with
>  GvB> the existing software and help script the missing bits and pieces.
>
>  GvB> What I'm currently stuck on is getting packages build for sid to
>  GvB> progress into sarge when they do in the official sarge but only if
>  GvB> that doesn't break our sarge. If you want to help out there you should
>  GvB> be familiar with Packages/Sources file syntax and graph theory.
>
> OK, if I understand this right is the problem that some packages
> entering the official debian sarge don't work on amd64, and that in
> turn should prevent other packages from entering amd64 sarge due to
> dependences. Is that right?

I can't name any case where this happens but it might and I would
prefer if that is checked.

> /debian-pure64 sid seems to be quite up-to-date with official
> debian, so I don't understand your problem: "stuck on is getting
> packages build for sid to progress into sarge when they do in the
> official sarge". Isn't the amd64 packages built automaticly from the
> src-packages??? Or are there some packages that still isn't ported to
> amd64 correctly and need manual attention? In that case can I probably
> help somewhat. Just tell me what package I should take a look at.

There are a lot of packages that need an amd64 patch that the
maintainer doesn't yet have included. There are also a lot (some
150-200) of packages that need to be fixed or Build-Depend on
something that has to be fixed. Compared to the number of total
packages they are miniscule but on their own it is a lot. For a list
of build failures check the wanna-build status:

wget http://debian-amd64.alioth.debian.org/pure64/dists/sid/amd64-all.txt
grep failed amd64-all.txt
grep "\.pure64" amd64-all.txt
grep "\.amd64" amd64-all.txt


The problem is that I would prefer to check if moving a package from
sid to sarge makes something uninstallable before actualy moving
it. It is the same check the official Debian archive does except I
want it smarter so it needs less manual intervention. The official
script has to many false negatives.

> / Anders

MfG
        Goswin



Reply to: