Integrado

ISOs edge para ARM ganham um pipeline de instalação nightly

emirb abriu e integrou omacom/omarchy-iso#282 ao quattro em 16 de outubro. A mudança adiciona um fluxo nightly edge para aarch64 que gera uma ISO, faz uma instalação sem intervenção, inicializa o sistema instalado duas vezes e repete a instalação como um N1x antes de permitir a publicação.

O pipeline publica uma ISO, uma soma de verificação e metadados dos pacotes e do kernel. Imagens de máquinas virtuais ARM continuam sem suporte nesse fluxo. Trata-se de infraestrutura no branch de desenvolvimento para builds edge, e não do anúncio de uma versão estável.

Integrado

Instalador preserva entradas de inicialização do Limine de outras instalações

birkskyum aprovou e integrou omacom/omarchy-iso#192, de jdvmi00, ao quattro em 16 de outubro. A limpeza agora verifica em conjunto o rótulo, a partição e o carregador de cada entrada de inicialização, impedindo que um rótulo compartilhado do Limine leve à exclusão da opção de inicialização de outra instalação. Falhas na limpeza são registradas em log, em vez de interromper a instalação.

github-actions[bot] relatou que os testes de instalação passaram tanto em x86_64 quanto em aarch64. A mudança foi integrada ao branch de desenvolvimento; as evidências fornecidas não demonstram que ela esteja incluída em uma versão estável.

Propostas abertas

Proposta contra reinicializações do Spark em repouso mantém a diretriz de um kernel ARM compartilhado

jdvmi00 abriu omacom/omarchy-pkgs#1191 em 16 de outubro para evitar reinicializações do NVIDIA DGX Spark em repouso. A descrição atual atribui as reinicializações à gravação de uma flag DVFSRC do firmware e propõe ignorar essa gravação quando houver uma correspondência exata com o hardware do Spark. A descrição recebeu atualizações até 19 de outubro e informa que o teste no hardware abrangido ainda está pendente.

birkskyum questionou o critério restrito de correspondência, observando que outros desktops GB10 ainda poderiam receber a gravação. Na discussão relacionada ao kernel, ryanrhughes definiu a diretriz de um único kernel linux-omarchy para todos os sistemas aarch64, e jdvmi00 concordou em continuar a investigação nessa direção. A correção das reinicializações permanece como proposta em aberto, e sua descrição atual não apresenta verificação do comportamento mais amplo em GB10 e N1x.

Integrado

Cada monitor ganha suas próprias áreas de trabalho numeradas

ryanrhughes abriu omacom/omarchy#15655 em 16 de outubro e integrou a mudança ao quattro em 18 de outubro, fora do dia coberto pela matéria. A descrição atual atribui a cada monitor áreas de trabalho com numeração local de 1 a 10, de modo que os atalhos numéricos atuem no monitor em foco e cada barra mostre as áreas de trabalho daquele monitor.

O projeto atual preserva as associações aos monitores quando eles são reconectados e reúne as áreas de trabalho em outra tela durante a desconexão, restaurando a numeração anterior quando o monitor retorna. Também documenta que os layouts salvos das áreas de trabalho não acompanham a renumeração. Esses detalhes vêm da descrição atualizada posteriormente; a integração confirma a disponibilidade no branch de desenvolvimento, e não em uma versão estável.

Propostas abertas

Escala independente por monitor avança na revisão

timothygwright propôs em omacom/omarchy#15665 um seletor de monitor acima das opções predefinidas de escala do painel de tela. A proposta de 16 de outubro também permite direcionar o comando de escala a uma saída pelo nome e, quando há várias telas ativas, salva por saída as alterações feitas por atalhos no monitor em foco. A proposta continua em aberto.

Após a revisão, timothygwright relatou correções na seleção por teclado das telas mais adiante na lista, na persistência das configurações após desconectar um monitor e na preservação dos campos de rotação em configurações separadas por ponto e vírgula. Depois, greptile-apps[bot] informou que os três problemas apontados haviam sido corrigidos. O autor também relatou ter verificado o painel em duas telas físicas; essa validação foi informada pelo próprio colaborador.

Fechado

AI Edit e Lock Screen Explorer publicam correções de segurança revisadas

A publicação de omacom/omarchy-plugin-marketplace#11847, do AI Edit, foi concluída em 16 de outubro, depois que HANCORE-linux identificou leituras da área de transferência que poderiam travar o shell compartilhado ou esgotar seus recursos. paulmiddelkoop substituiu a função nativa de colar por um leitor separado, limitado a 4 MiB e dois segundos. Uma descoberta posterior envolveu o acesso do Codex a ferramentas que poderiam enviar imagens locais além do texto selecionado; paulmiddelkoop informou ter desativado esse acesso, e HANCORE-linux confirmou as duas correções antes de github-actions[bot] anunciar a publicação.

A publicação de omacom/omarchy-plugin-marketplace#10783, do Lock Screen Explorer, também foi concluída. HANCORE-linux identificou um utilitário opcional de rotação na inicialização que poderia transformar a permissão de atualizar a tela de abertura em execução de código como root. A atualização de SirJul1337 acrescentou uma solicitação de autorização do administrador para remover o utilitário, caso estivesse instalado, durante a atualização. Depois, HANCORE-linux confirmou o fluxo de remoção, os temas de inicialização protegidos contra alterações e as correções anteriores de área de transferência e permissões, e aprovou a atualização.

github-actions[bot] descreveu a verificação da publicação do AI Edit como automatizada e a do Lock Screen Explorer como revisada por um mantenedor. Ambos os avisos restringem a verificação ao snapshot exato do marketplace e deixam explícito que ela não equivale a uma auditoria de segurança.

Propostas abertas

Proposta de DNS para VPN ganha reprodução por um agente executor e concentra a discussão em uma questão mais específica de compatibilidade

A proposta omacom/omarchy#14350, de Alumniminium, ainda em aberto, substitui a sobreposição global de DNS do NetworkManager por configurações do provedor nos perfis de Wi-Fi e Ethernet, junto com um hook do dispatcher. O objetivo é manter o provedor de DNS público escolhido e, ao mesmo tempo, permitir que as conexões VPN forneçam resolvedores para nomes privados.

Em 16 de outubro, Alumniminium concordou em atualizar um teste existente. Mais tarde, omarchybot relatou uma reprodução feita por um agente executor: nomes privados do WireGuard não eram resolvidos com a implementação do quattro, mas passaram a ser resolvidos com a proposta, enquanto a Ethernet manteve o DNS da Cloudflare. O bot também relatou uma correção no tratamento de famílias de endereços cujos métodos do NetworkManager rejeitam configurações de DNS.

A proposta ainda aguarda uma decisão de um mantenedor sobre conexões de uplink do tipo bridge, bond e VLAN, que a implementação relatada mantém com o DNS fornecido por DHCP, além de coordenação com alterações que se sobrepõem a ela. omarchybot relatou aprovação nos testes específicos, mas também falhas na suíte mais ampla do shell. Assim, as evidências indicam avanços pontuais, e não uma suíte inteiramente aprovada.

Propostas abertas

Investigação de falha na tela de bloqueio reproduz remoção imediata de uma saída de vídeo

MarlonAzevedo acrescentou a omacom/omarchy#9156 um relato de 16 de outubro sobre um notebook AMD cujo shell falhou depois que um monitor e um hub USB foram conectados enquanto a sessão estava bloqueada. Após se recuperar, o bloqueio indicava um estado seguro, mas a tela continuava preta, exigindo uma reinicialização forçada.

Em seguida, omarchybot relatou ter reproduzido uma falha por erro de protocolo com pacotes mais recentes ao criar e remover imediatamente uma saída de vídeo virtual sem monitor físico enquanto a sessão estava bloqueada. O rastreamento apontou uma condição de corrida entre uma solicitação de superfície de bloqueio e a remoção da saída. O bot atribuiu essa falha ao Hyprland, mas deixou explícito que o comportamento posterior de tela preta continuava sem explicação.

A issue continua aberta. O bot relatou que a investigação não produziu uma correção de escopo restrito no Omarchy e deixou a decisão entre evitar o desligamento da tela ou manter uma saída de vídeo virtual sem monitor físico a cargo de um mantenedor.

Propostas abertas

Eyes propõe descrições locais da tela, com verificações de privacidade ainda em revisão

Chessing234 abriu omacom/omarchy#15660 em 16 de outubro. A descrição atual propõe o Eyes, um comando acionado para capturar a tela e pedir a um modelo de visão local que a descreva, responda a uma pergunta ou localize um objeto sem clicar nele. A descrição foi atualizada após o período coberto e relata testes com substitutos simulados, em vez de testes de ponta a ponta com um modelo real.

Nos comentários de revisão de 16 de outubro, greptile-apps[bot] identificou um intervalo entre a verificação de foco no gerenciador de senhas e a captura, além de capturas temporárias que permaneciam após o cancelamento. Esses são achados de revisão da versão examinada, e não uma comprovação independente do comportamento da implementação atual. A proposta continua aberta.

Commit registrado

Super mais Shift mais S passa a ser um atalho para capturas de tela

O commit omacom/omarchy@51bfd1dbaa1b do quattro adiciona Super mais Shift mais S para capturas de tela e transfere o Google Maps para Super mais Shift mais Alt mais S. TripleU613 aparece na lista de participantes; o nome de autor atribuído ao commit é TripleU.

O histórico de commits registra o abandono de uma migração proposta que reescreveria os atalhos pessoais, pois as atualizações dos pacotes substituem os arquivos de atalhos padrão. Trata-se de uma alteração registrada no ramo de desenvolvimento, e não de evidência de uma versão estável.

Commit registrado

Kernel Aurora passa a permitir inicialização na máquina virt do QEMU

omacom/omarchy-pkgs@1cc8d4436ab3 incorporou ao master o suporte a controlador host PCIe genérico e a console PL011. A alteração permite que o kernel Aurora reconheça discos virtuais e recursos de rede e disponibilize um console na máquina virt do QEMU, inclusive na configuração do UTM em Apple Silicon.

malik-na aparece na lista de participantes, e o nome de autor atribuído ao commit é Naeem Malik. A revisão do pacote sobe para 12, mantendo a mesma versão fixada do código-fonte; a descrição do commit afirma que os drivers adicionados se vinculam a nós da árvore de dispositivos ausentes das descrições de hardware da Apple.