[RFR] wml://www.debian.org/devel/testing.wml
Segue o arquivo para revisão. É uma revisão longa e técnica,sugiro reservar por ITR. Abraços, Thiago Pezzo (Tico) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, May 31, 2020 7:30 PM, Thiago Pezzo wrote: > Começando mais uma tradução para o sprint. > > Abraços, > Thiago Pezzo (Tico) > > Sent with ProtonMail Secure Email. #use wml::debian::template title="A distribuição Debian testing" BARETITLE=true #include "$(ENGLISHDIR)/releases/info" #use wml::debian::translation-check translation="ff05f695462dd08fe524856384ed03a2dbb6763f" translation_maintainer="Felipe Augusto van de Wiel (faw)" Para informações básicas aos(à s) usuários(as) sobre a distribuição testing, veja a FAQ do Debian. Uma coisa importante a ser notada, tanto para usuários(as) regulares quanto para desenvolvedores(as), é que as atualizações de segurança da testing não são gerenciadas pela equipe de segurança. Para mais informações veja a FAQ da Equipe de Segurança. Esta página cobre, fundamentalmente, os aspectos da testing que são importantes para desenvolvedores(as) Debian. Como a testing funciona A distribuição testing é uma distribuição gerada automaticamente. Ela é gerada a partir da distribuição instável (unstable) por um conjunto de scripts que buscam mover pacotes que provavelmente não possuem bugs crÃticos ao lançamento (release-critical). Eles o fazem de modo a garantir que as dependências dos outros pacotes na testing sempre possam ser satisfeitas. Um pacote, de uma determinada versão, se moverá para a testing quando ele satisfizer todos os seguintes critérios: Ele precisa estar na instável (unstable) por 10, 5 ou 2 dias, dependendo da urgência do upload; Ele precisa estar compilado e atualizado em todas as arquiteturas nas quais ele foi anteriormente compilado na instável (unstable); Não pode haver nenhum bug crÃtico (release-critical), o que também se aplica à versão atualmente na testing (veja abaixo para mais informações); Todas as suas dependências precisam ser satisfeitas, ou pelos pacotes que já estão na testing, ou pelo grupo de pacotes que serão instalados ao mesmo tempo; A operação de instalação do pacote na testing não deve quebrar qualquer outro pacote na testing (Veja abaixo para mais informações.) Um pacote que satisfaz as três primeiras condições acima é considerado um Candidato Válido (Valid Candidate). O script de atualização mostra quando cada pacote deve mover-se da instável (unstable) para a testing. A saÃda é dividida em duas partes: As https://release.debian.org/britney/update_excuses.html;>\ justificativas de atualização (update excuses) [https://release.debian.org/britney/update_excuses.html.gz;>\ compactadas com gzip]: listam todos as versões candidatas dos pacotes e o estado básico de sua propagação para a testing; é um pouco mais curto e mais agradável que A https://release.debian.org/britney/update_output.txt;>\ saÃda de atualização (update output) [https://release.debian.org/britney/update_output.txt.gz;>\ compactada com gzip]: a saÃda completa, pouco refinada, dos scripts da testing conforme eles passam pelos candidatos Questões Feitas/Respondidas Frequentemente # Nota para tradutores: estes dois primeiros itens são quase idênticos ao # https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq O que são bugs crÃticos ao lançamento (release-critical), e como eles são contados? Todos os bugs de severidades altas são considerados https://bugs.debian.org/release-critical/;>crÃticos ao lançamento por padrão; atualmente, esses bugs são denominados de crÃticos (critical), graves (grave) e sérios (serious). Presume-se que tais bugs tenham um impacto nas probabilidades do pacote ser lançado com a versão estável do Debian: em geral, se um pacote tem bugs crÃticos ao lançamento, ele não irá para a testing, e consequentemente não será lançado na estável (stable). A contagem de bugs na testing é constituÃda de todos os bugs crÃticos ao lançamento (release-critical) que, marcados para serem aplicados como combinações pacote/versão, ficam disponÃveis na testing para lançamento em uma determinada arquitetura. Como a instalação de um pacote na testing poderia quebrar os outros pacotes? A estrutura dos repositórios da distribuição é tal que ela pode conter somente uma versão de um pacote; um pacote é definido por seu nome. Assim, quando o pacote-fonte acmefoo é instalado na testing, junto com seus pacotes binários acme-foo-bin, acme-bar-bin, libacme-foo1 e libacme-foo-dev, a versão antiga é removida. No entanto, a versão mais antiga pode também ter provido um pacote binário com um soname antigo de uma biblioteca, como libacme-foo0. Remover o acmefoo antigo removerá o libacme-foo0, quebrando qualquer pacote que
[RFR] wml://www.debian.org/devel/testing.wml
Boa Noite, correção em anexo. Obrigado. -- Wagner Marcuci On Sat, 2020-05-16 at 19:58 -0300, Wagner Marcuci wrote: > Boa Noite, > > estarei atualizando a página acima em Outdated translations. > > https://www.debian.org/devel/website/stats/pt#outdated > > Obrigado. > > -- > Wagner Marcuci > diff --git a/portuguese/devel/testing.wml b/portuguese/devel/testing.wml index 7634c2efb67..91813c708c0 100644 --- a/portuguese/devel/testing.wml +++ b/portuguese/devel/testing.wml @@ -1,6 +1,6 @@ #use wml::debian::template title="A distribuição Debian testing" BARETITLE=true #include "$(ENGLISHDIR)/releases/info" -#use wml::debian::translation-check translation="dff9a7e24a95a70c3a3ceb430a8a02e9f3afb7d0" translation_maintainer="Felipe Augusto van de Wiel (faw)" +#use wml::debian::translation-check translation="ff05f695462dd08fe524856384ed03a2dbb6763f" translation_maintainer="Felipe Augusto van de Wiel (faw)" Para informações básicas, orientadas ao usuário, sobre a distribuição testing, veja a FAQ do @@ -33,9 +33,9 @@ ele satisfizer todos os seguintes critérios: Ele precisa estar compilado e atualizado em todas as arquiteturas nas quais ele foi anteriormente compilado na instável (unstable); - Ele precisa ter menos bugs críticos ao lançamento - (release-critical) ou o mesmo número que a versão atualmente na - testing (veja abaixo para mais informações); + Ele não deve ter release-critical no lançamento que também não se aplicam a +a versão atualmente em testing (veja abaixo para + mais informações ); Todas as suas dependências precisam ser satisfeitas ou pelos pacotes que já estão na testing ou pelo grupo de @@ -49,8 +49,8 @@ ele satisfizer todos os seguintes critérios: Um pacote que satisfaz as três primeiras condições é considerado um Candidatos Válido. -O script de atualização mostra quando cada pacote deve mover-se da instável -(unstable) para a testing. A saída é dividida em duas partes: + O script de atualização mostra quando cada pacote pode passar de unstable para + testing . A saída é dupla: As https://release.debian.org/britney/update_excuses.html;>\ @@ -58,8 +58,7 @@ ele satisfizer todos os seguintes critérios: [https://release.debian.org/britney/update_excuses.html.gz;>\ compactadas com gzip]: listam todos as versões candidatas dos pacotes e o estado básico de sua - propagação para a testing; ele é um pouco mais curto e mais - agradável + propagação para a testing; ele é um pouco mais curto e mais agradável A https://release.debian.org/britney/update_output.txt;>\ saída de atualização (update output) @@ -72,6 +71,9 @@ ele satisfizer todos os seguintes critérios: Questões Feitas/Respondidas Freqüentemente +# Note to translators: these two first items are almost the same as +# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq + O que são bugs críticos ao lançamento (release-critical), e como eles são contados? @@ -85,12 +87,11 @@ ser lançado com a versão estável do Debian: em geral, se um pacote tem bugs críticos ao lançamento, ele não irá para a testing, e conseqüentemente não será lançado na estável (stable). -A contagem de bugs na testing de um pacote é considerada como -aproximadamente a contagem de bugs no último momento no qual a versão na -testing era a mesma da instável (unstable). Os bugs com tag - ou - não serão contados. No entanto, -bugs com a tag sid serão contados. + + A contagem de erros testing são todos erros críticos para o lançamento que + estão marcados para serem aplicados às combinações pacote/versão + que estão disponíveis em testing para uma versão da arquitetura. + Como instalar um pacote na testing poderia quebrar os outros pacotes? @@ -133,23 +134,23 @@ instalar o pacote vai quebrar algum outro pacote. Lembre-se de considerar as dependências do seu pacote. Suponha que o seu pacote depende da libtool, ou libltdlX. Seu pacote não -irá para a testing até que a versão correta da libtool esteja pronta -para ir com ele. +irá para a testing até que a versão correta da libtool esteja pronta para ir com ele. Do mesmo modo, isso não irá ocorrer até que a instalação da libtool não quebre pacotes que já estão na testing. Em outras palavras, até que todos os outros pacotes que dependem da libltdlY (onde Y é a versão anterior) tenham sido recompilados, e todos os seus bugs críticos ao -lançamento estiverem corrigidos, etc, nenhum destes pacotes entrará na -testing. +lançamento estiverem corrigidos, etc, nenhum destes pacotes entrará na testing. -É aqui que a -https://release.debian.org/britney/update_output.txt;>saída de +É aqui que a https://release.debian.org/britney/update_output.txt;>saída de texto [https://release.debian.org/britney/update_output.txt.gz;>\ compactada com gzip] é útil: ela dá dicas (embora bastante resumidas) de quais pacotes quebram -quando um candidato válido é adicionado à testing.
Re: [RFR] wml://www.debian.org/devel/testing.wml
Olá Este arquivo (diff) tb está em dia, para a versão 1.31. Alguém pode revisar? Um abraço Claudio Em 21 de maio de 2012 17:15, Claudio Filho filh...@gmail.com escreveu: Olá Mais um arquivo. Desculpa a demora. Arquivo: http://anonscm.debian.org/viewvc/webwml/webwml/portuguese/devel/testing.wml?revision=1.12view=markup Claudio -- To UNSUBSCRIBE, email to debian-l10n-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC=mjxdlwytyc0dpyntnyhnknfrvznckhonhzwwiqw6dqz4...@mail.gmail.com
