Fwd: Debian Installer etch beta 1 released

Robert Millan rmh at aybabtu.com
Mon Nov 14 11:30:08 UTC 2005


On Mon, Nov 14, 2005 at 11:04:00AM +0100, Petr Salinger wrote:
> Moreover the distribution of unported packages is not uniform.
> Order taken from http://popcon.debian.org/source/by_inst:
> 
> top  500	  59 packages	=> 12% 
> top 1000	 139 packages	=> 14%
> top 2000	 340 packages	=> 17%	
> top 5000	1044 packages	=> 21%

Nice.  I think we should focus on the ~5 packages in base that are still
pending.  I'll reply to my previous reports about them, I think they need an
update.

> I would say that today kfreebsd-i386 is missing namely rebuildable glibc,
> based on glibc-2.3.5 or better 2.3.6. Since it will probably change more 
> frequently than stock debian/linux glibc, it might be better to have it in 
> completely separate source package. This also allow to have linux glibc 
> 2.4-based and kfreebsd glibc still 2.3-based. Another bonus is separated BTS.

Sounds like a good idea.  It'd be very difficult/impractical to apply it to
glibc-2.3 (doesn't build, etc), but for recent versions it makes more sense.  I
think it'd also depend on how much does upstream support us when we start
merging.

> It would be nice, if all other specific kfreebsd-i386 packages 
> have already BTS. It is the best place for patches from 
> unexperienced kfreebsd developers (as I am).

Yes.. that'd be great.  But, do you think the ftp assistants would accept
packages that are only useful for a port that doesn't exist yet in their
archive?  For other packages like freebsd5-buildutils or kfreebsd-5 we had
excuses for justifiing their usefulness on GNU/Linux.  What about the others?

And even if they agree to set the overrides, how would they be uploaded?  dak
rejects kfreebsd-i386 uploads, and source-only uploads too.  How would you
upload, say, kldutils?

> To have source packages in official debian archive will be needed also 
> for plan c) from 
> http://lists.alioth.debian.org/pipermail/glibc-bsd-devel/2005-October/000568.html

Uhm yes.  But atm I think it's more important to decide which of the three plans
I proposed in that mail we're going to follow.  I think it didn't get any reply
back then..  what's your opinion?

> It will also prevent threads like 
> http://lists.debian.org/debian-devel/2005/11/thrd2.html#00541 .
> I am afraid, that today kfreebsd glibc is not only unrebuildable, 
> but it is also without source, even in svn changelog is not 2.3-1+kbsd.11 mentioned.

What do you mean?  The source is in svn, and also in the gnuab archive:

  http://ftp.gnuab.org/debian/pool-kfreebsd-i386/main/g/glibc/

> Could be i.e. kfreebsd-kernel-headers uploaded into experimental now ?
> I think that NEW queue processing takes some days/weeks.

Maybe we can convince them with experimental, but:

  a) Technical problems with dak persist.  What would you put in the
  Architecture field?

  b) We need stuff in unstable.  Having it in experimental is less useful than
  having it in unreleased.

-- 
Robert Millan



More information about the Glibc-bsd-devel mailing list