Re: Instalação em Português (Era Potato now Stable)
Enquanto o pessoal da Debian não disponibiliza os disquetes de
inicialização e raíz internacionalizados, eu deixei disponível
o sistema de instalação estável compilado em Português em:
ftp://ftp2.escelsanet.com.br/debian/binary-i386
Lá estão disponíveis todas as imagens de disco exceto os dos disquetes
de 1.2MB e imagens El Torino de 2.88 MB. Baixem e distribuam por ai :-)
Abraços
Paulo Henrique Baptista de Oliveira wrote:
>
> Debian 2.2 (potato) lançada.
>
> ----- Forwarded message from Anthony Towns <aj@azure.humbug.org.au> -----
>
> Date: Tue, 15 Aug 2000 07:41:42 +1000
> From: Anthony Towns <aj@azure.humbug.org.au>
> To: debian-devel-announce@lists.debian.org
> Subject: Potato now stable
> Organisation: Lacking
> X-Mailing-List: <debian-devel-announce@lists.debian.org> archive/latest/595
>
> Hello world,
>
> Well, as some of you might have noticed:
>
> ajt@auric:/org/ftp.debian.org/ftp/dists$ ls -l Debian2.2r0 stable
> lrwxrwxrwx 1 troup debadmin 6 Aug 14 13:06 Debian2.2r0 -> stable
> lrwxrwxrwx 1 troup debadmin 6 Aug 14 13:06 stable -> potato
>
> CD images and the archive are being mirrored more or less as I type.
>
> So you can expect the prepared announcement to go out soon (it's scheduled
> for the "official release time" of 00:00 GMT).
>
> Some things that won't make the "real" announcement follow. First, some
> thanks are due to some of the people without whom potato wouldn't have
> made it through these final stages:
>
> * Branden Robinson, Ben Collins, Steve Gore, and Mike Renfro for
> tracking down and fixing some X problems at the 11th hour.
>
> * Daniel Jacobowitz, for somehow getting PowerPC support from
> shaky to first class, and tracking down and fixing problems
> right up until the 11th hour and fiftieth minute.
>
> * Ben Collins and Steve Gore, for making sure potato's sparc
> support is as good as possible, and tracking down and fixing
> problems right up until the 11th hour and fifty-fifth minute.
>
> * Martin Schulze, for tidying up some security fixes at very
> short notice.
>
> * Adam Di Carlo and Josip Rodin, for keeping our release notes as
> up to date as possible.
>
> * Phil Hands for getting complete CD sets up and mirrored
> almost as quick as you can say "oh my god, cdimage.debian.org
> has crashed again!"
>
> * James Troup, who kept the archive in tip-top shape throughout.
>
> By omission, this does a fairly impressive injustice to everyone else
> who helped with development, testing, fixing bugs, documenting problems
> and work arounds, giving support, and everything else everyone's done
> in the past months, so, well, thanks everyone!
>
> So that means we can start really focussing on the next release: woody.
>
> Well, after focussing on partying like it's the year after 1999, perhaps.
>
> Once we get to woody, though, there are probably two things that are
> particularly worthwhile doing. As per usual, we should probably have a few
> weeks discussing "release goals" for woody to see what sort of direction
> we want to head (and then going ahead and implementing whatever we feel
> like anyway). As well, (and here's where you might be able to pick up
> the fact I've been reading too many management books recently [0]),
> I think it's probably a good idea if we go over some of the things that
> went wrong this time and see what we can to fix them, and which things
> went right so we know to keep doing it.
>
> So, first, here's a rough idea of some of the things I think went wrong and
> right. (Technical followups to debian-devel@lists.debian.org)
>
> * Tasks are great, but task-* packages suck when some of the
> packages included have release critical bugs. (Remove the
> package, the entire task breaks)
>
> * boot-floppies, kernels (and modules), and release notes are
> all a pain to get uploaded and installed.
>
> * Working out which bugs are really release-critical and fixing
> their severity so we know where we're at is overly time
> consuming.
>
> * Getting security updates installed is suboptimal: some don't get
> built properly; some don't get put in incoming for dinstall
> to process.
>
> * Testing updates to frozen is suboptimal: updates go into
> incoming, wait there for a while, get added to frozen,
> we discover they introduce as many release critical bugs
> as they solve, rinse, repeat. The "wait for a while" part
> is particularly suboptimal, but without it, it's not really
> a freeze.
>
> * boot-floppies needs huge amounts of time to get into a
> functional state: from November or so 1999 to June 2000 this
> time, roughly.
>
> * debian-cd scripts seem to be working great: the "minimal
> rsync" to update the images between test cycle three and the
> release seem to be working fine, and the separate non-us CD#1
> seems like a great idea to me.
>
> * The autobuilders cope *really* well with most updates. The
> security team also seem to have perfected getting updates
> recompiles really quickly on all architectures when it's
> necessary too. All very impressive.
>
> There's probably lots more good things too, the above is probably
> hopelessly biassed towards the bad.
>
> In addition, here's my understanding of goals already being worked on for
> woody (and who's working on it, and where to talk about it). Technical
> discussion should go to debian-devel@lists.debian.org.
>
> * New "testing" distribution
> This is a (mostly finished) project that will allow us
> to test out distribution by making it "sludgey" rather
> than frozen: that is, a new distribution is added between
> stable and unstable, that is regularly and automatically
> updated with new packages from unstable when they've
> had a little testing and now new RC bugs.
>
> (Anthony Towns; debian-devel)
>
> * Dinstall Rewrite / Package Pools
> There's a lot of interest in updating dinstall to better
> cope with our archive and the various new ideas we want to
> deal with. A new layout of the archive itself, and a
> new process for packages to enter the archive and become
> members of some of our distributions are probably involved.
>
> (Anthony Towns, Jason Gunthorpe, Richard Braakman, among
> others; debian-pool)
>
> * Debconf Integration
> Most of the debconf infrastructure is now written,
> and it's already in production use with potato. It
> will hopefully be finished, and extended to handle all
> installation I/O.
>
> (Joey Hess; debian-devel / config@kitenet.net)
>
> * Automated Installation
> With debconf integration, hopefully we should be able to
> go a little further and support non-interactive installs
> with woody.
>
> (debian-devel / config@kitenet.net)
>
> * Apt Frontends
> dselect replacements like console-apt, gnome-apt, and
> aptitude should probably should probably be standard.
>
> (debian-devel)
>
> * IPv6 Support
> A continuing goal is more complete support for IPv6. Hopefully
> we can get some of the IPv6 patches available from various
> places mainlined in woody.
>
> (debian-ipv6)
>
> * Modular Install
> The boot-floppies are being redesigned, so as to be
> more modular (and hence not require five disk images
> when you only need a couple of megabytes for your
> particular setup) and hopefully more maintainable.
>
> (Joey Hess; debian-boot)
>
> This is excluding all the usual improvements to individual packages, of
> course.
>
> As a rough guide, and presuming woody is in good shape, we'll consider
> freezing again in roughly six months, so think mid-February or so. Note
> that this'll require, among other things, completely operational
> boot-floppies for all the architectures we'll be releasing.
>
> That's about it. Have fun!
>
> --
> Anthony Towns <ajt@debian.org> (Acting Release Manager), for
> Richard Braakman <dark@debian.org> (Debian Release Manager)
>
> [0] ie, one.
>
> ----- End forwarded message -----
>
> --
> To UNSUBSCRIBE, email to debian-user-portuguese-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
---------------------------
Gleyson Mazioli da Silva
gleydson@escelsanet.com.br
gleydson@linuxbr.com.br
Reply to: