* [PATCH 1/3] docs: translations: pt_BR: translate embargoed-hardware-issues.rst
2026-08-29 16:24 [PATCH 0/3] docs: translations: pt_BR: process documentation updates and new translation Daniel Pereira
@ 2026-08-29 16:24 ` Daniel Pereira
2026-08-29 16:24 ` [PATCH 2/3] docs: translations: pt_BR: update process translation files Daniel Pereira
2026-08-29 16:24 ` [PATCH 3/3] docs: translations: pt_BR: fix missing text and formatting in process docs Daniel Pereira
2 siblings, 0 replies; 4+ messages in thread
From: Daniel Pereira @ 2026-08-29 16:24 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 19524 bytes --]
Translate Documentation/process/embargoed-hardware-issues.rst into
Brazilian Portuguese and add it to the pt_BR process index.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../process/embargoed-hardware-issues.rst | 362 ++++++++++++++++++
.../translations/pt_BR/process/index.rst | 1 +
2 files changed, 363 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
diff --git a/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
new file mode 100644
index 000000000..ae1fda088
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/embargoed-hardware-issues.rst
@@ -0,0 +1,362 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Problemas de hardware sob embargo
+=================================
+
+Escopo
+------
+
+Problemas de hardware que resultam em problemas de segurança formam uma categoria
+de bugs de segurança diferente dos bugs de software puros que afetam apenas o
+kernel do Linux.
+
+Problemas de hardware como Meltdown, Spectre, L1TF, etc., devem ser tratados
+de maneira diferente porque geralmente afetam todos os Sistemas Operacionais ("OS")
+e, portanto, exigem coordenação entre diferentes fornecedores de SO, distribuições,
+fabricantes de silício, integradores de hardware e outras partes. Para alguns
+dos problemas, as mitigações de software podem depender de atualizações de
+microcódigo ou firmware, o que requer ainda mais coordenação.
+
+.. _pt_BR_Contact:
+
+Contato
+-------
+
+A equipe de segurança de hardware do kernel Linux é separada da equipe regular
+de segurança do kernel Linux.
+
+A equipe lida apenas com o desenvolvimento de correções para problemas de
+segurança de hardware sob embargo. Relatos de bugs de segurança de software puro
+no kernel Linux não são tratados por esta equipe, e o autor do relato será
+orientado a contatar a equipe regular de segurança do kernel Linux
+(:ref:`Documentation/admin-guide/ <securitybugs>`) em vez disso.
+
+A equipe pode ser contatada por e-mail em <hardware-security@kernel.org>. Esta
+é uma lista privada de oficiais de segurança que ajudarão você a coordenar uma
+correção de acordo com o nosso processo documentado.
+
+A lista é criptografada e o e-mail para a lista pode ser enviado criptografado
+por PGP ou S/MIME, e deve ser assinado com a chave PGP ou certificado S/MIME do
+autor do relato. A chave PGP e o certificado S/MIME da equipe estão disponíveis
+nas seguintes URLs:
+
+ - PGP: https://www.kernel.org/static/files/hardware-security.asc
+ - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
+
+Embora os problemas de segurança de hardware sejam frequentemente tratados pelo
+fabricante de silício afetado, nós acolhemos o contato de pesquisadores ou
+indivíduos que tenham identificado uma falha potencial de hardware.
+
+Oficiais de segurança de hardware
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A equipe atual de oficiais de segurança de hardware:
+
+ - Linus Torvalds (Fellow da Linux Foundation)
+ - Greg Kroah-Hartman (Fellow da Linux Foundation)
+ - Thomas Gleixner (Fellow da Linux Foundation)
+
+Operação das listas de e-mail
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+As listas de e-mail criptografadas que são usadas em nosso processo são
+hospedadas na infraestrutura de TI da Linux Foundation. Ao fornecer este
+serviço, os membros da equipe de operações de TI da Linux Foundation têm,
+tecnicamente, a capacidade de acessar as informações sob embargo, mas são
+obrigados à confidencialidade por seu contrato de trabalho. O pessoal de TI
+da Linux Foundation também é responsável por operar e gerenciar o restante da
+infraestrutura do kernel.org.
+
+O atual diretor de infraestrutura de projetos de TI da Linux Foundation é
+Konstantin Ryabitsev.
+
+
+Acordos de não divulgação
+-------------------------
+
+A equipe de segurança de hardware do kernel Linux não é um órgão formal e,
+portanto, é incapaz de celebrar quaisquer acordos de não divulgação. A
+comunidade do kernel está ciente da natureza sensível de tais problemas e
+oferece um Memorando de Entendimento em vez disso.
+
+
+Memorando de Entendimento
+-------------------------
+
+A comunidade do kernel Linux compreende profundamente a necessidade de manter
+os problemas de segurança de hardware sob embargo para a coordenação entre
+diferentes fornecedores de SO, distribuidores, fabricantes de silício e outras
+partes.
+
+A comunidade do kernel Linux lidou com sucesso com problemas de segurança de
+hardware no passado e possui os mecanismos necessários para permitir o
+desenvolvimento compatível com a comunidade sob restrições de embargo.
+
+A comunidade do kernel Linux possui uma equipe dedicada de segurança de hardware
+para o contato inicial, que supervisiona o processo de tratamento de tais
+problemas sob as regras de embargo.
+
+A equipe de segurança de hardware identifica os desenvolvedores (especialistas no
+domínio) que formarão a equipe de resposta inicial para um problema específico.
+A equipe de resposta inicial pode trazer outros desenvolvedores (especialistas no
+domínio) para resolver o problema da melhor maneira técnica.
+
+Todos os desenvolvedores envolvidos comprometem-se a aderir às regras de embargo
+e a manter as informações recebidas em sigilo. A violação do compromisso levará à
+exclusão imediata do problema atual e à remoção de todas as listas de e-mail
+relacionadas. Além disso, a equipe de segurança de hardware também excluirá o
+infrator de futuros problemas. O impacto dessa consequência é um impedimento
+altamente eficaz em nossa comunidade. Caso ocorra uma violação, a equipe de
+segurança de hardware informará as partes envolvidas imediatamente. Se você ou
+qualquer outra pessoa tomar conhecimento de uma potencial violação, por favor,
+relate-a imediatamente aos oficiais de segurança de hardware.
+
+
+Processo
+^^^^^^^^
+
+Devido à natureza globalmente distribuída do desenvolvimento do kernel Linux,
+reuniões presenciais são quase impossíveis para lidar com problemas de
+segurança de hardware. Conferências telefônicas são difíceis de coordenar devido
+a fusos horários e outros fatores, devendo ser usadas apenas quando estritamente
+necessário. O e-mail criptografado tem se mostrado o método de comunicação mais
+eficiente e seguro para esses tipos de problema.
+
+Início da divulgação
+"""""""""""""""""""""
+
+A divulgação começa enviando um e-mail para a equipe de segurança de hardware
+do kernel Linux, conforme a seção Contato acima. Este contato inicial deve
+conter uma descrição do problema e uma lista de qualquer silício afetado
+conhecido. Se a sua organização constrói ou distribui o hardware afetado,
+incentivamos você a considerar também quais outros hardwares podem ser
+afetados. A parte que faz a divulgação é responsável por contatar os
+fabricantes de silício afetados em tempo hábil.
+
+A equipe de segurança de hardware fornecerá uma lista de e-mail criptografada
+específica para o incidente, que será usada para a discussão inicial com o
+relator, divulgação posterior e coordenação de correções.
+
+A equipe de segurança de hardware fornecerá à parte divulgadora uma lista de
+desenvolvedores (especialistas no domínio) que devem ser informados inicialmente
+sobre o problema após confirmar com os desenvolvedores que eles aderirão a
+este Memorando de Entendimento e ao processo documentado. Esses desenvolvedores
+formam a equipe de resposta inicial e serão responsáveis por lidar com o
+problema após o contato inicial. A equipe de segurança de hardware apoia a
+equipe de resposta, mas não está necessariamente envolvida no processo de
+desenvolvimento de mitigações.
+
+Embora desenvolvedores individuais possam estar cobertos por um acordo de não
+divulgação por meio de seu empregador, eles não podem celebrar acordos
+individuais de não divulgação em seu papel como desenvolvedores do kernel
+Linux. No entanto, eles concordarão em aderir a este processo documentado e ao
+Memorando de Entendimento.
+
+A parte divulgadora deve fornecer uma lista de contatos para todas as outras
+entidades que já foram, ou devem ser, informadas sobre o problema. Isso serve
+a vários propósitos:
+
+ - A lista de entidades informadas permite a comunicação em toda a
+ indústria, por exemplo, outros fornecedores de SO, fornecedores de HW, etc.
+
+ - As entidades informadas podem ser contatadas para indicar especialistas
+ que devem participar do desenvolvimento da mitigação.
+
+ - Se um especialista necessário para lidar com um problema for funcionário
+ de uma entidade listada ou membro de uma entidade listada, as equipes de
+ resposta podem solicitar a inclusão desse especialista por parte daquela
+ entidade. Isso garante que o especialista também faça parte da equipe de
+ resposta da entidade.
+
+Divulgação
+""""""""""
+
+A parte divulgadora fornece informações detalhadas à equipe de resposta inicial
+por meio da lista de e-mail criptografada específica.
+
+A partir de nossa experiência, a documentação técnica desses problemas costuma
+ser um ponto de partida suficiente, e esclarecimentos técnicos adicionais são
+melhor feitos por e-mail.
+
+Desenvolvimento de mitigações
+""""""""""""""""""""""""""""""
+
+A equipe de resposta inicial configura uma lista de e-mail criptografada ou
+reaproveita uma já existente, se apropriado.
+
+O uso de uma lista de e-mail é próximo ao processo normal de desenvolvimento
+do Linux e tem sido usado com sucesso para desenvolver mitigações para vários
+problemas de segurança de hardware no passado.
+
+A lista de e-mail opera da mesma forma que o desenvolvimento normal do Linux.
+Os patches são publicados, discutidos, revisados e, se aprovados, aplicados a
+um repositório git não público que é acessível apenas aos desenvolvedores
+participantes por meio de uma conexão segura. O repositório contém o ramo
+(branch) principal de desenvolvimento contra o kernel mainline e ramos de
+retroporte (backport) para versões estáveis do kernel conforme necessário.
+
+A equipe de resposta inicial identificará outros especialistas da comunidade
+de desenvolvedores do kernel Linux conforme necessário. Qualquer parte
+envolvida pode sugerir a inclusão de outros especialistas, cada um dos quais
+estará sujeito aos mesmos requisitos descritos acima.
+
+A inclusão de especialistas pode ocorrer a qualquer momento no processo de
+desenvolvimento e precisa ser tratada em tempo hábil.
+
+Se um especialista for funcionário ou membro de uma entidade na lista de
+divulgação fornecida pela parte divulgadora, a participação será solicitada
+à entidade relevante.
+
+Caso contrário, a parte divulgadora será informada sobre a participação
+dos especialistas. Os especialistas são cobertos pelo Memorando de Entendimento
+e a parte divulgadora é solicitada a reconhecer a participação deles. No caso
+de a parte divulgadora ter um motivo convincente para se opor, qualquer
+objeção deve ser levantada no prazo de cinco dias úteis e resolvida com a
+equipe do incidente imediatamente. Se a parte divulgadora não reagir dentro
+de cinco dias úteis, isso é considerado como reconhecimento tácito.
+
+Após a equipe do incidente reconhecer ou resolver uma objeção, o especialista
+é informado e integrado ao processo de desenvolvimento.
+
+Os participantes da lista não podem se comunicar sobre o problema fora da
+lista de e-mail privada. Os participantes da lista não podem usar nenhum
+recurso compartilhado (por exemplo, fazendas de compilação do empregador,
+sistemas de IC, etc.) ao trabalhar em patches.
+
+Acesso antecipado
+"""""""""""""""""
+
+Os patches discutidos e desenvolvidos na lista não podem ser distribuídos a
+nenhum indivíduo que não seja membro da equipe de resposta, nem a nenhuma outra
+organização.
+
+Para permitir que os fornecedores de silício afetados trabalhem com suas equipes
+internas e parceiros da indústria em testes, validação e logística, a seguinte
+exceção é fornecida:
+
+ Representantes designados dos fornecedores de silício afetados têm permissão
+ para repassar os patches a qualquer momento para a equipe de resposta do
+ fornecedor de silício. O representante deve notificar a equipe de resposta
+ do kernel sobre o repasse. O fornecedor de silício afetado deve possuir e
+ manter seu próprio processo de segurança documentado para quaisquer patches
+ compartilhados com sua equipe de resposta que seja consistente com esta
+ política.
+
+ A equipe de resposta do fornecedor de silício pode distribuir esses patches
+ aos seus parceiros da indústria e às suas equipes internas sob o processo
+ de segurança documentado do fornecedor de silício. O feedback dos parceiros
+ da indústria retorna ao fornecedor de silício e é comunicado por ele à
+ equipe de resposta do kernel.
+
+ O repasse para a equipe de resposta do fornecedor de silício remove
+ qualquer responsabilidade civil ou legal da equipe de resposta do kernel
+ em relação à divulgação prematura que ocorra devido ao envolvimento das
+ equipes internas ou parceiros da indústria do fornecedor de silício. O
+ fornecedor de silício garante esta liberação de responsabilidade ao
+ concordar com este processo.
+
+Lançamento coordenado
+"""""""""""""""""""""
+
+As partes envolvidas negociarão a data e a hora em que o embargo termina. Nesse
+ponto, as mitigações preparadas são publicadas nas árvores de kernel relevantes.
+Não há processo de pré-notificação: as mitigações são publicadas publicamente e
+disponibilizadas para todos ao mesmo tempo.
+
+Embora entendamos que problemas de segurança de hardware exijam tempo de embargo
+coordenado, o tempo de embargo deve ser restrito ao mínimo necessário para que
+todas as partes envolvidas desenvolvam, testem e preparem suas mitigações.
+Estender o tempo de embargo artificialmente para cumprir datas de palestras em
+conferências ou outros motivos não técnicos cria mais trabalho e ônus para os
+desenvolvedores e equipes de resposta envolvidos, pois os patches precisam ser
+mantidos atualizados para acompanhar o desenvolvimento contínuo do kernel
+upstream, o que pode criar alterações conflitantes.
+
+Atribuição de CVE
+""""""""""""""""""
+
+Nem a equipe de segurança de hardware nem a equipe de resposta inicial atribuem
+CVEs, nem os CVEs são necessários para o processo de desenvolvimento. Se os CVEs
+forem fornecidos pela parte divulgadora, eles poderão ser usados para fins de
+documentação.
+
+Embaixadores do processo
+------------------------
+
+Para obter assistência com este processo, estabelecemos embaixadores em várias
+organizações, que podem responder a perguntas sobre ou fornecer orientações
+acerca do processo de relatórios e tratamento posterior. Os embaixadores não
+estão envolvidos na divulgação de um problema específico, a menos que seja
+solicitado por uma equipe de resposta ou por uma parte divulgada envolvida.
+A lista atual de embaixadores:
+
+ ============= ========================================================
+ AMD Tom Lendacky <thomas.lendacky@amd.com>
+ Ampere Darren Hart <darren@os.amperecomputing.com>
+ ARM Catalin Marinas <catalin.marinas@arm.com>
+ IBM Power Madhavan Srinivasan <maddy@linux.ibm.com>
+ IBM Z Christian Borntraeger <borntraeger@de.ibm.com>
+ Intel Tony Luck <tony.luck@intel.com>
+ Qualcomm Trilok Soni <quic_tsoni@quicinc.com>
+ RISC-V Palmer Dabbelt <palmer@dabbelt.com>
+ Samsung Javier González <javier.gonz@samsung.com>
+
+ Microsoft James Morris <jamorris@linux.microsoft.com>
+ Xen Andrew Cooper <andrew.cooper3@citrix.com>
+
+ Canonical John Johansen <john.johansen@canonical.com>
+ Debian Ben Hutchings <ben@decadent.org.uk>
+ Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+ Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
+ SUSE Jiri Kosina <jkosina@suse.cz>
+
+ Google Kees Cook <keescook@chromium.org>
+
+ LLVM Nick Desaulniers <ndesaulniers@google.com>
+ ============= ========================================================
+
+Se você quiser que sua organização seja adicionada à lista de embaixadores,
+entre em contato com a equipe de segurança de hardware. O embaixador indicado
+deve compreender e apoiar totalmente o nosso processo e, idealmente, estar bem
+conectado na comunidade do kernel Linux.
+
+Listas de e-mail criptografadas
+-------------------------------
+
+Usamos listas de e-mail criptografadas para comunicação. O princípio de
+operação dessas listas é que o e-mail enviado para a lista é criptografado
+com a chave PGP da lista ou com o certificado S/MIME da lista. O software
+da lista de e-mail descriptografa o e-mail e o recriptografa individualmente
+para cada assinante com a chave PGP ou certificado S/MIME do assinante.
+Detalhes sobre o software da lista de e-mail e a configuração usada para
+garantir a segurança das listas e a proteção dos dados podem ser encontrados
+aqui: https://korg.wiki.kernel.org/userdoc/remail.
+
+Listas de chaves
+^^^^^^^^^^^^^^^^
+
+Para o contato inicial, consulte a seção :ref:`pt_BR_Contact` acima. Para listas de
+e-mail específicas de incidentes, a chave e o certificado S/MIME são transmitidos
+aos assinantes por e-mail enviado a partir da lista específica.
+
+Inscrição em listas específicas de incidentes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A inscrição em listas específicas de incidentes é gerenciada pelas equipes de
+resposta. As partes informadas que desejam participar da comunicação enviam
+uma lista de potenciais especialistas para a equipe de resposta, para que esta
+possa validar as solicitações de inscrição.
+
+Cada assinante precisa enviar uma solicitação de inscrição para a equipe de
+resposta por e-mail. O e-mail deve estar assinado com a chave PGP ou o certificado
+S/MIME do assinante. Se uma chave PGP for utilizada, ela deve estar disponível
+em um servidor de chaves público e, idealmente, conectada à teia de confiança
+(web of trust) PGP do kernel Linux. Veja também:
+https://www.kernel.org/signature.html.
+
+A equipe de resposta verifica se a solicitação do assinante é válida e o
+adiciona à lista. Após a inscrição, o assinante receberá e-mails da lista de
+e-mail que são assinados com a chave PGP da lista ou com o certificado S/MIME
+da lista. O cliente de e-mail do assinante pode extrair a chave PGP ou o
+certificado S/MIME da assinatura para que o assinante possa enviar e-mails
+criptografados para a lista.
\ No newline at end of file
diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
index eda2a3fc5..969dd2407 100644
--- a/Documentation/translations/pt_BR/process/index.rst
+++ b/Documentation/translations/pt_BR/process/index.rst
@@ -72,6 +72,7 @@ gerenciamento de bugs e vulnerabilidades.
:maxdepth: 1
Falhas de segurança <security-bugs>
+ Problemas de hardware sob embargo <embargoed-hardware-issues>
CVEs <cve>
Informações para mantenedores
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH 2/3] docs: translations: pt_BR: update process translation files
2026-08-29 16:24 [PATCH 0/3] docs: translations: pt_BR: process documentation updates and new translation Daniel Pereira
2026-08-29 16:24 ` [PATCH 1/3] docs: translations: pt_BR: translate embargoed-hardware-issues.rst Daniel Pereira
@ 2026-08-29 16:24 ` Daniel Pereira
2026-08-29 16:24 ` [PATCH 3/3] docs: translations: pt_BR: fix missing text and formatting in process docs Daniel Pereira
2 siblings, 0 replies; 4+ messages in thread
From: Daniel Pereira @ 2026-08-29 16:24 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 10231 bytes --]
Fix minor typographical, punctuation, and untranslated text errors in
the Brazilian Portuguese translations of Documentation/process/2.Process.rst,
3.Early-stage.rst, 4.Coding.rst, and 5.Posting.rst to better match the
original text and improve readability.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../translations/pt_BR/process/2.Process.rst | 12 ++++++------
.../translations/pt_BR/process/3.Early-stage.rst | 10 +++++-----
.../translations/pt_BR/process/4.Coding.rst | 6 +++---
.../translations/pt_BR/process/5.Posting.rst | 12 ++++++------
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
index 5ff35f10a..03e288d46 100644
--- a/Documentation/translations/pt_BR/process/2.Process.rst
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -75,16 +75,16 @@ Como exemplo, veja como ocorreu o ciclo de desenvolvimento da versão 5.4
(todas as datas são de 2019):
============== ===============================
- Setembro 15 5.3 Lançamento estável do 5.3
+ Setembro 15 Lançamento estável do 5.3
Setembro 30 5.4-rc1, fechamento da janela de integração
Outubro 6 5.4-rc2
Outubro 13 5.4-rc3
Outubro 20 5.4-rc4
- October 27 5.4-rc5
+ Outubro 27 5.4-rc5
Novembro 3 5.4-rc6
Novembro 10 5.4-rc7
Novembro 17 5.4-rc8
- Novembro 24 5.4 Lançamento estável do 5.4
+ Novembro 24 Lançamento estável do 5.4
============== ===============================
Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento
@@ -330,7 +330,7 @@ A árvore de fontes do kernel contém o diretório drivers/staging/, onde reside
muitos subdiretórios para drivers ou sistemas de arquivos que estão a caminho
de serem adicionados à árvore do kernel. Eles permanecem em drivers/staging/
enquanto ainda precisam de mais trabalho; uma vez concluídos, podem ser movidos
-para o kernel proper Esta é uma maneira de acompanhar drivers que não estão à
+para o kernel propriamente dito. Esta é uma maneira de acompanhar drivers que não estão à
altura dos padrões de codificação ou de qualidade do kernel Linux, mas que as
pessoas podem querer usar e acompanhar o desenvolvimento.
@@ -433,7 +433,7 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
caixa de entrada principal. É preciso ser capaz de ignorar o fluxo de e-mails
por períodos prolongados de tempo.
-- Não tente acompanhar cada conversa ninguém mais faz isso. É importante
+- Não tente acompanhar cada conversa, ninguém mais faz isso. É importante
filtrar tanto pelo tópico de interesse (embora note que conversas longas
podem se desviar do assunto original sem que a linha de assunto do e-mail
seja alterada) quanto pelas pessoas que estão participando.
@@ -461,7 +461,7 @@ Existem algumas dicas que podem ajudar na sobrevivência na lista linux-kernel:
ponto de encontro geral, mas não é o melhor lugar para encontrar desenvolvedores
de todos os subsistemas.
-O último ponto, encontrar a lista de discussão correta é um lugar comum
+O último ponto, encontrar a lista de discussão correta, é um lugar comum
onde os desenvolvedores iniciantes costumam errar. Alguém que faça uma pergunta
relacionada a redes na lista linux-kernel quase certamente receberá uma
sugestão educada para perguntar na lista netdev em seu lugar, já que essa é a
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst
index 74e741766..86c228353 100644
--- a/Documentation/translations/pt_BR/process/3.Early-stage.rst
+++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst
@@ -74,7 +74,7 @@ Discussão inicial
Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
discussões com a comunidade antes de iniciar a implementação. A comunicação
-inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+inicial pode economizar tempo e problemas de várias maneiras:
- Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
que você não compreendeu. O kernel Linux é grande e possui uma série de
@@ -121,8 +121,8 @@ comunidade do kernel. Alguns exemplos incluem:
consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
manteve o AppArmor fora do kernel principal (*mainline*) por anos.
-In each of these cases, a great deal of pain and extra work could have been
-avoided with some early discussion with the kernel developers.
+Em cada um desses casos, muito sofrimento e trabalho extra poderiam ter sido
+evitados com alguma discussão inicial com os desenvolvedores do kernel.
Como encontrar os mantenedores?
@@ -200,8 +200,8 @@ prosseguir, mantendo a comunidade informada à medida que avança.
Obter a aprovação oficial
-------------------------
-Se o seu trabalho estiver sendo realizado em um ambiente corporativo como é o
-caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo, como é o
+caso da maior parte do trabalho no kernel do Linux, você deve, obviamente, ter
a permissão de gerentes devidamente autorizados antes de poder publicar os
planos ou o código da sua empresa em uma lista de discussão pública.
A publicação de código que não tenha sido liberado para lançamento sob uma
diff --git a/Documentation/translations/pt_BR/process/4.Coding.rst b/Documentation/translations/pt_BR/process/4.Coding.rst
index ca4c74774..7c7567165 100644
--- a/Documentation/translations/pt_BR/process/4.Coding.rst
+++ b/Documentation/translations/pt_BR/process/4.Coding.rst
@@ -197,8 +197,8 @@ a ferramenta certa para o trabalho. Códigos que mostrem falta de atenção à
concorrência terão um caminho difícil para entrar no mainline.
-Regressions
-***********
+Regressões
+**********
Um perigo final que vale a pena mencionar é este: pode ser tentador fazer uma
alteração (que pode trazer grandes melhorias) que faça algo quebrar para os
@@ -258,7 +258,7 @@ Note que nem todos os avisos do compilador ficam ativados por padrão. Compile o
kernel com "make KCFLAGS=-W" para obter o conjunto completo.
O kernel fornece várias opções de configuração que ativam recursos de
-depuração; a maioria delas é encontrada no submanu "kernel hacking". Várias
+depuração; a maioria delas é encontrada no submenu "kernel hacking". Várias
dessas opções devem ser ativadas para qualquer kernel usado para fins de
desenvolvimento ou teste. Em particular, você deve ativar:
diff --git a/Documentation/translations/pt_BR/process/5.Posting.rst b/Documentation/translations/pt_BR/process/5.Posting.rst
index 820a56b66..2ac7e5557 100644
--- a/Documentation/translations/pt_BR/process/5.Posting.rst
+++ b/Documentation/translations/pt_BR/process/5.Posting.rst
@@ -37,7 +37,7 @@ Antes de criar patches
----------------------
Há uma série de coisas que devem ser feitas antes de você considerar o envio
-de patches para la comunidade de desenvolvimento. Elas incluem:
+de patches para a comunidade de desenvolvimento. Elas incluem:
- Teste o código tanto quanto puder. Faça uso das ferramentas de depuração
do kernel, garanta que o kernel seja compilado com todas as combinações
@@ -106,7 +106,7 @@ que podem ajudar consideravelmente:
- Como uma forma de reafirmar a diretriz acima: não misture diferentes tipos de
alterações no mesmo patch. Se um único patch corrige uma falha crítica de
- segurança, reorganiza algumas estruturas e reformatará o código, há uma grande
+ segurança, reorganiza algumas estruturas e reformata o código, há uma grande
chance de que ele seja ignorado e a correção importante seja perdida.
- Cada patch deve resultar em um kernel que compile e funcione corretamente; se
@@ -199,7 +199,7 @@ a alteração em um sistema de controle de versão. Ele será seguido por:
diff associará os nomes das funções às alterações, tornando o patch resultante
mais fácil de ser lido por outras pessoas.
-As tags já mencionadas brevemente acima são usados para fornecer
+Os marcadores (tags) já mencionados brevemente acima são usados para fornecer
informações sobre como o patch surgiu. Eles são descritos em detalhes no
documento :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`;
o que se segue aqui é um breve resumo.
@@ -215,7 +215,7 @@ documento com uma especificação implementada pelo patch::
Link: https://example.com/somewhere.html optional-other-stuff
-De acordo com as orientações do Pinguim-Chefe, um marcador Link
+De acordo com as orientações do Pinguim-Chefe, um marcador Link:
só deve ser adicionado a um commit se ele levar a informações úteis que não
são encontradas no próprio commit.
@@ -279,7 +279,7 @@ Os marcadores de uso comum são:
Tenha cuidado ao adicionar os marcadores mencionados acima aos seus patches, pois
todos, exceto Cc:, Reported-by: e Suggested-by:, precisam de permissão explícita
-fontes da pessoa nomeada. Para esses três, a permissão implícita é suficiente se
+da pessoa nomeada. Para esses três, a permissão implícita é suficiente se
a pessoa contribuiu para o kernel Linux usando esse nome e endereço de e-mail de
acordo com os arquivos do lore ou o histórico de commits — e, no caso de
Reported-by: e Suggested-by:, se fizeram o relato ou a sugestão publicamente.
@@ -322,7 +322,7 @@ kernel incentiva as pessoas a pecarem pelo excesso, enviando cópias demais; nã
assuma que as pessoas relevantes verão sua publicação nas listas de discussão. Em
particular, as cópias devem ir para:
-- O(s) mantenedor(es) do(s) subsistema(s) afetado(s). Como descrito antes, o
+ - O(s) mantenedor(es) do(s) subsistema(s) afetado(s). Como descrito antes, o
arquivo MAINTAINERS é o primeiro lugar para procurar por essas pessoas.
- Outros desenvolvedores que estiveram trabalhando na mesma área — especialmente
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread* [PATCH 3/3] docs: translations: pt_BR: fix missing text and formatting in process docs
2026-08-29 16:24 [PATCH 0/3] docs: translations: pt_BR: process documentation updates and new translation Daniel Pereira
2026-08-29 16:24 ` [PATCH 1/3] docs: translations: pt_BR: translate embargoed-hardware-issues.rst Daniel Pereira
2026-08-29 16:24 ` [PATCH 2/3] docs: translations: pt_BR: update process translation files Daniel Pereira
@ 2026-08-29 16:24 ` Daniel Pereira
2 siblings, 0 replies; 4+ messages in thread
From: Daniel Pereira @ 2026-08-29 16:24 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 18037 bytes --]
Add a missing paragraph about code review in 6.Followthrough.rst and
fix a grammatical error. Fix formatting and translate an English snippet
in 8.Conclusion.rst. Fix several instances of omitted 'xyzzy'
placeholders in code examples, restore truncated sentences, and fix
missing links in adding-syscalls.rst. Fix typos in applying-patches.rst.
Fix a typo and fix a broken markdown link to reStructuredText format
in backporting.rst.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
.../pt_BR/process/6.Followthrough.rst | 14 ++++-
.../pt_BR/process/8.Conclusion.rst | 3 +-
.../pt_BR/process/adding-syscalls.rst | 54 ++++++++++---------
.../pt_BR/process/applying-patches.rst | 4 +-
.../pt_BR/process/backporting.rst | 4 +-
5 files changed, 47 insertions(+), 32 deletions(-)
diff --git a/Documentation/translations/pt_BR/process/6.Followthrough.rst b/Documentation/translations/pt_BR/process/6.Followthrough.rst
index d6bdaa2cb..dbdf479bb 100644
--- a/Documentation/translations/pt_BR/process/6.Followthrough.rst
+++ b/Documentation/translations/pt_BR/process/6.Followthrough.rst
@@ -58,7 +58,17 @@ fácil se você mantiver algumas coisas em mente:
de codificação e pedidos para refatorar parte do seu código em seções
compartilhadas do kernel. Uma das funções dos mantenedores é manter as coisas
com a mesma aparência. Às vezes, isso significa que aquele truque inteligente
- (*clever hack*) em seu driver para contornar um problema
+ (*clever hack*) em seu driver para contornar um problema na verdade precisa
+ se tornar um recurso generalizado do kernel, pronto para a próxima vez.
+
+O que tudo isso significa é que, quando os revisores lhe enviam comentários,
+você precisa prestar atenção às observações técnicas que eles estão fazendo.
+Não deixe que a forma como eles se expressam, ou o seu próprio orgulho, impeçam
+que isso aconteça. Quando você receber comentários de revisão em um patch,
+reserve um tempo para entender o que o revisor está tentando dizer. Se
+possível, corrija as coisas que o revisor está pedindo para você corrigir. E
+responda ao revisor: agradeça-o e descreva como você responderá às suas
+perguntas.
Note que você não precisa concordar com todas as mudanças sugeridas pelos
revisores. Se você acredita que o revisor entendeu mal o seu código, explique
@@ -67,7 +77,7 @@ sugerida, descreva-a e justifique a sua solução para o problema. Se as suas
explicações fizerem sentido, o revisor as aceitará. Contudo, caso a sua
explicação não seja persuasiva — especialmente se outros começarem a concordar
com o revisor —, reserve um tempo para repensar as coisas. Pode ser fácil ficar
-ceguificado por sua própria solução para um problema, a ponto de não perceber
+cego por sua própria solução para um problema, a ponto de não perceber
que algo está fundamentalmente errado ou que, talvez, você não esteja sequer
resolvendo o problema certo.
diff --git a/Documentation/translations/pt_BR/process/8.Conclusion.rst b/Documentation/translations/pt_BR/process/8.Conclusion.rst
index d5af31e7c..2696ea167 100644
--- a/Documentation/translations/pt_BR/process/8.Conclusion.rst
+++ b/Documentation/translations/pt_BR/process/8.Conclusion.rst
@@ -21,6 +21,7 @@ encontradas através do índice do kernel do LWN em:
https://lwn.net/Kernel/Index/
Além disso, um recurso valioso para os desenvolvedores do kernel é:
+
https://kernelnewbies.org/
E, claro, não se deve esquecer o https://kernel.org/, o local definitivo
@@ -29,7 +30,7 @@ para informações sobre os lançamentos do kernel.
Há uma série de livros sobre o desenvolvimento do kernel:
Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro
- Rubini, and Greg Kroah-Hartman). Online at
+ Rubini, e Greg Kroah-Hartman). Disponível online em
https://lwn.net/Kernel/LDD3/.
Linux Kernel Development (Robert Love).
diff --git a/Documentation/translations/pt_BR/process/adding-syscalls.rst b/Documentation/translations/pt_BR/process/adding-syscalls.rst
index cdf8b5033..37b0dd0e2 100644
--- a/Documentation/translations/pt_BR/process/adding-syscalls.rst
+++ b/Documentation/translations/pt_BR/process/adding-syscalls.rst
@@ -122,10 +122,10 @@ como o handle (identificador) para esse objeto -- não invente um novo tipo de
handle de objeto para o espaço do usuário quando o kernel já possui mecanismos
e semânticas bem definidas para o uso de descritores de arquivo.
-Se a sua nova chamada de sistema (2) de fato retornar un novo descritor de
+Se a sua nova chamada de sistema xyzzy(2) de fato retornar um novo descritor de
arquivo, então o argumento de flags deve incluir um valor que seja equivalente
a definir ``O_CLOEXEC`` no novo FD. Isso torna possível para o espaço do usuário
-fechar a janela de tempo entre a chamada ``()`` e a execução de
+fechar a janela de tempo entre a chamada ``xyzzy()`` e a execução de
``fcntl(fd, F_SETFD, FD_CLOEXEC)``, onde um ``fork()`` e ``execve()`` inesperados
em outra thread poderiam vazar um descritor para o programa executado. (Contudo,
resista à tentação de reutilizar o valor real da constante ``O_CLOEXEC``, pois
@@ -138,7 +138,7 @@ deve considerar o que significa usar a família de chamadas de sistema
pronto para leitura ou escrita é a maneira normal de o kernel indicar ao espaço
do usuário que um evento ocorreu no objeto correspondente do kernel.
-Se a sua nova chamada de sistema (2) envolver um argumento de nome de arquivo
+Se a sua nova chamada de sistema xyzzy(2) envolver um argumento de nome de arquivo
(filename)::
int sys_xyzzy(const char __user *path, ..., unsigned int flags);
@@ -152,18 +152,18 @@ o arquivo em questão; em particular, permite que o espaço do usuário solicite
funcionalidade para um descritor de arquivo já aberto usando a flag
``AT_EMPTY_PATH``, fornecendo efetivamente uma operação fxyzzy(3) de graça::
- - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a (path,...)
+ - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a xyzzy(path,...)
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) é equivalente a fxyzzy(fd, ...)
(Para mais detalhes sobre a justificativa das chamadas \*at(), veja a página de
manual :manpage:`openat(2)`; para um exemplo de AT_EMPTY_PATH, veja a página de
manual :manpage:`fstatat(2)`.)
-Se a sua nova chamada de sistema (2) envolver um parâmetro que descreve um
+Se a sua nova chamada de sistema xyzzy(2) envolver um parâmetro que descreve um
deslocamento (offset) dentro de um arquivo, mude o seu tipo para ``loff_t`` para
que offsets de 64 bits possam ser suportados mesmo em arquiteturas de 32 bits.
-Se a sua nova chamada de sistema (2) envolver funcionalidades privilegiadas,
+Se a sua nova chamada de sistema xyzzy(2) envolver funcionalidades privilegiadas,
ela precisa ser governada pelo bit de capacidade (capability) do Linux apropriado
(verificado com uma chamada a ``capable()``), conforme descrito na página de
manual :manpage:`capabilities(7)`. Escolha um bit de capacidade existente que governe
@@ -172,7 +172,7 @@ apenas uma vaga relação sob o mesmo bit, pois isso vai contra o propósito das
capabilities de dividir o poder do root. Em particular, evite adicionar novos
usos para a capacidade ``CAP_SYS_ADMIN``, que já é excessivamente generalista.
-Se a sua nova chamada de sistema (2) manipular um processo diferente do
+Se a sua nova chamada de sistema xyzzy(2) manipular um processo diferente do
processo que a chamou, ela deve ser restrita (usando uma chamada a
``ptrace_may_access()``) para que apenas um processo chamador com as mesmas
permissões do processo alvo, ou com as capacidades necessárias, possa manipular
@@ -211,7 +211,7 @@ kernel, devem sempre ser enviadas com cópia (cc'ed) para linux-api@vger.kernel.
Implementação Genérica de Chamadas de Sistema
---------------------------------------------
-O ponto de entrada principal para a sua nova chamada de sistema (2) será chamado
+O ponto de entrada principal para a sua nova chamada de sistema xyzzy(2) será chamado
de ``sys_xyzzy()``, mas você deve adicionar esse ponto de entrada com a macro
``SYSCALL_DEFINEn()`` apropriada, em vez de fazer isso explicitamente. O 'n'
indica o número de argumentos da chamada de sistema, e a macro recebe o nome da
@@ -242,7 +242,7 @@ O arquivo ``kernel/sys_ni.c`` fornece uma implementação de stub de fallback pa
cada chamada de sistema, retornando ``-ENOSYS``. Adicione a sua nova chamada de
sistema aqui também::
- COND_SYSCALL(sys_xyzzy);
+ COND_SYSCALL(xyzzy);
A sua nova funcionalidade de kernel, e a chamada de sistema que a controla, deve
normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente em
@@ -259,7 +259,7 @@ normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente
Para resumir, você precisa de um commit que inclua:
- Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
- Protótipo correspondente em ``include/linux/syscalls.h``
- Entrada na tabela genérica em ``include/uapi/asm-generic/unistd.h``
- Stub de fallback em ``kernel/sys_ni.c``
@@ -289,7 +289,7 @@ ajustar ``arch/*/kernel/Makefile.syscalls``.
Como o ``scripts/syscall.tbl`` serve como uma tabela de syscall comum para
múltiplas arquiteturas, uma nova entrada é necessária nesta tabela::
- 468 common sys_xyzzy
+ 468 common xyzzy sys_xyzzy
Note que adicionar uma entrada ao ``scripts/syscall.tbl`` com a ABI "common"
também afeta todas as arquiteturas que compartilham essa tabela. Para alterações
@@ -304,7 +304,7 @@ correspondentes também devem ser feitas em ``arch/*/kernel/Makefile.syscalls``:
Para resumir, você precisa de um commit que inclua:
- Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
- Protótipo correspondente em ``include/linux/syscalls.h``
- Nova entrada em ``scripts/syscall.tbl``
- (Se necessário) Atualizações de Makefile em ``arch/*/kernel/Makefile.syscalls``
@@ -320,11 +320,11 @@ de sistema não seja especial de alguma forma (veja abaixo), isso envolve uma
entrada "common" (para x86_64 e x32) em
``arch/x86/entry/syscalls/syscall_64.tbl``::
- 333 common sys_xyzzy
+ 333 common xyzzy sys_xyzzy
e uma entrada "i386" em ``arch/x86/entry/syscalls/syscall_32.tbl``::
- 380 i386 sys_xyzzy
+ 380 i386 xyzzy sys_xyzzy
Novamente, esses números estão sujeitos a alterações caso ocorram conflitos na
janela de mesclagem (merge window) relevante.
@@ -414,7 +414,7 @@ a versão compat; a entrada em ``include/uapi/asm-generic/unistd.h`` deve usar
Para resumir, você precisa de:
- - uma macro ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - uma macro ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
- protótipo correspondente em ``include/linux/compat.h``
- (se necessário) struct de mapeamento de 32 bits em ``include/linux/compat.h``
- instância de ``__SC_COMP``, e não de ``__SYSCALL``, em
@@ -433,11 +433,11 @@ Você precisa estender a entrada em ``scripts/syscall.tbl`` com uma coluna extra
para indicar que um programa de espaço do usuário de 32 bits rodando em um
kernel de 64 bits deve atingir o ponto de entrada compat::
- 468 common sys_xyzzy compat_sys_xyzzy
+ 468 common xyzzy sys_xyzzy compat_sys_xyzzy
Para resumir, você precisa de:
- - ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
- Protótipo correspondente em ``include/linux/compat.h``
- Modificação da entrada em ``scripts/syscall.tbl`` para incluir uma coluna
"compat" extra
@@ -454,7 +454,7 @@ compatibilidade voltadas para o espaço do usuário de 32 bits (AArch32):
``arch/arm64/tools/syscall_32.tbl``. Você precisa adicionar uma linha adicional
a esta tabela especificando o ponto de entrada compat::
- 468 common sys_xyzzy compat_sys_xyzzy
+ 468 common xyzzy sys_xyzzy compat_sys_xyzzy
Chamadas de Sistema de Compatibilidade (x86)
@@ -467,7 +467,7 @@ Primeiro, a entrada em ``arch/x86/entry/syscalls/syscall_32.tbl`` ganha uma
coluna extra para indicar que um programa de espaço do usuário de 32 bits rodando
em um kernel de 64 bits deve atingir o ponto de entrada compat::
- 380 i386 sys_xyzzy __ia32_compat_sys_xyzzy
+ 380 i386 xyzzy sys_xyzzy __ia32_compat_sys_xyzzy
Segundo, você precisa definir o que deve acontecer para a versão da ABI x32 da
nova chamada de sistema. Há uma escolha aqui: o layout dos argumentos deve
@@ -479,9 +479,9 @@ corresponder à versão de 32 bits, e a entrada em
``arch/x86/entry/syscalls/syscall_64.tbl`` é dividida para que os programas x32
atinjam o wrapper de compatibilidade::
- 333 64 sys_xyzzy
+ 333 64 xyzzy sys_xyzzy
...
- 555 x32 __x32_compat_sys_xyzzy
+ 555 x32 xyzzy __x32_compat_sys_xyzzy
Se não houver ponteiros envolvidos, então é preferível reutilizar a chamada de
sistema de 64 bits para a ABI x32 (e, consequentemente, a entrada em
@@ -518,14 +518,14 @@ Para x86_64, isso é implementado como um ponto de entrada ``stub_xyzzy`` em
``arch/x86/entry/entry_64.S``, e a entrada correspondente na tabela de syscalls
(``arch/x86/entry/syscalls/syscall_64.tbl``) é ajustada para refletir::
- 333 common stub_xyzzy
+ 333 common xyzzy stub_xyzzy
O equivalente para programas de 32 bits executados em um kernel de 64 bits é
normalmente chamado de ``stub32_xyzzy`` e implementado em
``arch/x86/entry/entry_64_compat.S``, com o respectivo ajuste na tabela de
syscalls em ``arch/x86/entry/syscalls/syscall_32.tbl``::
- 380 i386 sys_xyzzy stub32_xyzzy
+ 380 i386 xyzzy sys_xyzzy stub32_xyzzy
Se a chamada de sistema precisar de uma camada de compatibilidade (como na
seção anterior), a versão ``stub32_`` precisará chamar a versão
@@ -579,12 +579,16 @@ espaço do usuário, o cabeçalho correspondente precisará ser instalado para
compilar o teste.
Certifique-se de que o autoteste seja executado com sucesso em todas as
-arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compitado
+arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compilado
como um programa ABI x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
Para testes mais extensos e minuciosos de novas funcionalidades, você também
deve considerar a adição de testes ao Linux Test Project ou ao projeto
-xfstests para alterações relacionadas
+xfstests para alterações relacionadas a sistemas de arquivos.
+
+ - https://linux-test-project.github.io/
+ - git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
+
Página de Manual (Man Page)
---------------------------
diff --git a/Documentation/translations/pt_BR/process/applying-patches.rst b/Documentation/translations/pt_BR/process/applying-patches.rst
index 313401bc2..37a8d804d 100644
--- a/Documentation/translations/pt_BR/process/applying-patches.rst
+++ b/Documentation/translations/pt_BR/process/applying-patches.rst
@@ -12,7 +12,7 @@ Autor Original:
manualmente, você quase certamente desejará considerar o uso do Git.
Uma pergunta feita com frequência na Linux Kernel Mailing List é como aplicar
-an patch ao kernel ou, mais especificamente, a qual kernel base um patch para
+um patch ao kernel ou, mais especificamente, a qual kernel base um patch para
uma das muitas árvores/branches deve ser aplicado. Esperamos que este documento
explique isso a você.
@@ -171,7 +171,7 @@ fazer a alteração para fazê-la caber).
O arquivo resultante pode ou não estar correto, dependendo do motivo pelo qual o
arquivo estava diferente do esperado.
-Isso geralmente acontece se você tentar aplicar un patch que foi gerado contra uma
+Isso geralmente acontece se você tentar aplicar um patch que foi gerado contra uma
versão de kernel diferente daquela que você está tentando modificar.
Se você receber uma mensagem como ``Hunk #3 FAILED at 2387.``, significa que o
diff --git a/Documentation/translations/pt_BR/process/backporting.rst b/Documentation/translations/pt_BR/process/backporting.rst
index ce3f9fb4f..afcff7085 100644
--- a/Documentation/translations/pt_BR/process/backporting.rst
+++ b/Documentation/translations/pt_BR/process/backporting.rst
@@ -357,7 +357,7 @@ Processo de resolução
~~~~~~~~~~~~~~~~~~~~~
Às vezes, a coisa mais fácil a fazer é apenas remover tudo, exceto a primeira
-parteda do conflito, deixando o arquivo essencialmente inalterado, e aplicar
+parte do conflito, deixando o arquivo essencialmente inalterado, e aplicar
as alterações manualmente. Talvez o patch esteja alterando um argumento de
chamada de função de ``0`` para ``1``, enquanto uma alteração conflitante
adicionou um parâmetro totalmente novo (e insignificante) ao final da lista de
@@ -403,7 +403,7 @@ de volta (``git mv`` e commitando novamente) e, finalmente, esmagar (squash) o
resultado usando ``git rebase -i`` (veja o `tutorial de rebase`_) para que ele
apareça como um único commit quando você terminar.
-.. _tutorial de rebase: [https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec)
+.. _tutorial de rebase: https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec
Pegadinhas
----------
--
2.47.3
^ permalink raw reply related [flat|nested] 4+ messages in thread