Rpi-imager: RPi Imager 1.6.1 (e superior) não pode ser instalado no Ubuntu 18.04

Receio que 20.04 LTS seja o novo mínimo, porque atualizei para isso. :-)
Ainda deve ser capaz de executar "debuild" a partir do git.

Tenho certeza de que não posso ser a única pessoa ainda executando o Ubuntu 18.04 :wink: E embora eu possa executar o debuild, tenho certeza de que existem muitos usuários menos técnicos que não podem?
Você poderia construir dentro de uma VM ou algo assim?

Eu mantenho um snap do rpi-imager e acabei de instalá-lo no Ubuntu 20.04, mas é instalável no Ubuntu 18.04 (na verdade, até 14.04 e 16.04) e outras distribuições também.

Como um ponto de dados interessante sobre "quem ainda executa o 18.04?" questão, ainda há um número razoável sobre ele. Entre os usuários de snap do RPI Imager, ~ 13% estão no Ubuntu 18.04, com ~ 56% no 20.04 e até ~ 2,7% no Ubuntu 16.04!

A menos que https://github.com/popey/imager-snap/issues/8 tenha sido resolvido, infelizmente o snap não suporta o conjunto completo de recursos do Imager. IIRC, você também precisa habilitar algumas permissões adicionais para evitar outros erros. Não é óbvio que você precisa fazer isso ou como. Dado que o gerador de imagens destina-se a simplificar as coisas, o snap parece apresentar obstáculos.

Idealmente, seria ótimo nos repositórios normais do apt.

A menos que o popey/imager-snap#8 tenha sido resolvido

Está funcionando melhor em 1.6.1?

Sneaked em um commit ( https://github.com/raspberrypi/rpi-imager/commit/c8409d741939c0af32180c731a86adcdeaba802d ) que pode contornar isso, mas não teve tempo de descobrir como criar um snap para testá-lo.

O código assumia anteriormente que assim que o udisks2 (com o qual falamos no DBus) nos informava que o volume removível (partição FAT32) estava montado, poderíamos gravar na pasta de montagem.
Mas pode não ser montado dentro do snap chroot ainda nesse ponto, que parece ficar para trás.
Portanto, faça uma verificação que verifique se a pasta de montagem é um ponto de montagem e atrasa até 3 segundos se não for.

Apenas tentei e não, parece ser pior. No início, ele disse que não poderia montar a partição, então habilitei a permissão relevante. Mesmo erro, então habilitei todas as permissões que estavam desabilitadas (embora suas descrições não parecessem relevantes) (PEBCAK). Agora o imager se comporta como se tudo tivesse corrido bem, mas o cartão SD fica em branco no final.

Qt: Session management error: Could not open network socket
QObject::setParent: Cannot set parent, new parent is in a different thread
Drive: "/org/freedesktop/UDisks2/drives/Generic__USB3_2e0_CRW____SD_201506301013_1"
Device: "/org/freedesktop/UDisks2/block_devices/sdc" belongs to same drive
Device: "/org/freedesktop/UDisks2/block_devices/sdc1" belongs to same drive
Unmounted "/org/freedesktop/UDisks2/block_devices/sdc1" successfully
Repartitioning drive
Telemetry done. cURL status code = 0
Adding partition
New partition: "/org/freedesktop/UDisks2/block_devices/sdc1"
Formatting drive as FAT32
Mounting partition
Mounted new file system at: "/media/shift/F28E-8BF1"
Image URL: "https://github.com/raspberrypi/rpi-eeprom/releases/download/v2020.09.03-138a1-imager/rpi-boot-eeprom-recovery-2020-09-03-vl805-000138a1-usb.zip"
Received header: HTTP/2 302 

Received header: server: GitHub.com
...
Can't create 'README.txt'
Can't create 'pieeprom.bin'
Can't create 'pieeprom.sig'
Can't create 'recovery.bin'
Can't create 'vl805.bin'
Can't create 'vl805.sig'
Hash of compressed multi-file zip: "84b73785a93720621136e23ee766e2e56a516902baaccebe3e055106471029ff"
mountutils: Reading /proc/mounts
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Mount point /dev/sdc1 belongs to drive /dev/sdc
mountutils: Closing /proc/mounts
mountutils: Unmounting /media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmounting /var/lib/snapd/hostfs/media/shift/F28E-8BF1...
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1: EAGAIN
mountutils: Unmount MNT_EXPIRE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_DETACH /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
mountutils: Unmount MNT_FORCE /var/lib/snapd/hostfs/media/shift/F28E-8BF1 failed: Operation not permitted
Download done in 3 seconds

No geral, não é a experiência que você gostaria que qualquer usuário tivesse.

Não é possível criar 'README.txt'

/var/lib/snapd/hostfs/media/shift/F28E-8BF1 não é gravável pelo usuário snap executa o Imager como?

Devemos mover isso para https://github.com/popey/imager-snap/issues/8?

Independentemente de quaisquer problemas com os pacotes Snap, ainda acho que o imager_1.6.1_amd64.deb download em https://www.raspberrypi.org/software/ deve ser instalável no Ubuntu 18.04 (que ainda é suportado até abril de 2023).
:slightly_frowning_face:

EDIT: Bloqueado por #200

EDIT2: Para quem ainda usa o Ubuntu 18.04, aqui está uma compilação do RPi Imager 1.6.1 depois de aplicar o patch de # 200
Use por sua conta e risco: rpi-imager_1.6.1_amd64.zip
(sinta-se à vontade para excluir este @maxnet se achar que é inapropriado)

https://www.raspberrypi.org/documentation/installation/installing-images/README.md também diz "Ubuntu 18.04" :wink:

Então, se o RPi Imager definitivamente não suportará o Ubuntu 18.04 daqui para frente, acho que devemos atualizar essa documentação também? :dar de ombros:

Portanto, se o RPi Imager definitivamente não suportará o Ubuntu 18.04 daqui para frente

Não tenho certeza qual é a política de suporte oficial.

Esteja ciente de que a utilidade geral do Ubuntu 18 para desenvolvedores está diminuindo rapidamente.

• Não é mais utilizável para desenvolvimento web, já que a versão PHP com que ele vem é mais antiga do que os frameworks modernos aceitam.
• Não utilizável para desenvolvimento C de baixo nível. Por exemplo, se você quiser brincar com o Raspberry Pico, descobrirá que o CMake é muito antigo.
• A versão Qt não suporta vários métodos mais recentes. E se você usar uma versão mais recente do Qt em outras plataformas, verá que ele lança uma carga de avisos de método "obsoleto" se você usar os métodos mais antigos.

E o Ubuntu 20 LTS está fora há um ano.

Qual é a razão pela qual você ainda está usando 18?

Qual é a razão pela qual você ainda está usando 18?

Comprei um novo laptop Dell XPS há pouco mais de um ano que veio com o Ubuntu 18.04 pré-instalado e estou relutante em tentar atualizá-lo para uma versão mais recente, especialmente porque ainda é uma versão LTS com suporte ativo. Além disso, executar um sistema operacional mais antigo, mas ainda com suporte, é útil para descobrir casos extremos como este :wink:
Para coisas do Pico, atualizei para uma versão mais recente do CMake usando https://apt.kitware.com/ E quando preciso usar uma versão mais recente do GCC, basta anexar meu local-install-dir para $PATH. Para qualquer outra coisa, existe o VirtualBox.

Os lançamentos LTS são de 'nível empresarial' e focados na estabilidade. Eles são para aqueles que _não_ querem novas versões de software. As atualizações de software que você obtém para as versões LTS são apenas segurança e correções de bugs. O suporte a software antigo não é gratuito, dá trabalho e limita sua capacidade de avançar. Não é razoável esperar que um LTS antigo continue sendo uma plataforma suportada um ano após o lançamento do atual.

Eles são para aqueles que _não_ querem novas versões de software.

Sim, essa é uma posição razoável a ser tomada; Eu não teria nenhum problema com, por exemplo, o RPi Imager 1.7.x suportando apenas o Ubuntu 20.04+, com o Ubuntu 18.04 sendo restrito ao RPi Imager 1.6.x mais antigo. Só me pareceu estranho que a quebra de compatibilidade tenha acontecido na mudança de 1.6.0 para 1.6.1
Além disso, dado o nível de usuário ao qual o site Raspberry Pi se destina, acho improvável que o site ofereça diferentes opções de download para "usuários do Ubuntu 20.04+" e "usuários do Ubuntu 18.04", e foi por isso que sugeri que quando/se a decisão de abandonar o suporte para 18.04 acontecer, ela precisa ser especificamente mencionada na documentação.

:man_shrugging:

Só me pareceu estranho que a quebra de compatibilidade tenha acontecido na mudança de 1.6.0 para 1.6.1

Concordo que é estranho que isso aconteça silenciosamente em um lançamento pontual. Isso deve pelo menos ser adicionado ao changelog 1.6.1. Mas você sabe... houve um período de carência de um ano! Se for do seu interesse, meu XPS (13) roda 20.04 perfeitamente :)

Independentemente de quaisquer problemas com os pacotes Snap, ainda acho que o imager_1.6.1_amd64.deb download em https://www.raspberrypi.org/software/ deve ser instalável no Ubuntu 18.04 (que ainda é suportado até abril de 2023).
ligeiramente_franzindo_face

~EDIT: Bloqueado por #200~

EDIT2: Para quem ainda usa o Ubuntu 18.04, aqui está uma compilação do RPi Imager 1.6.1 depois de aplicar o patch de # 200
Use por sua conta e risco: rpi-imager_1.6.1_amd64.zip
(sinta-se à vontade para excluir este @maxnet se achar que é inapropriado)

THX. funcionou no debian buster para mim, enquanto o download original e o snap falharam

Apenas um FYI que este é um problema no ChromeOS também. Se você tiver o modo de desenvolvedor Linux habilitado 1.6.1 compartilhado por @lurch funciona enquanto o download de https://www.raspberrypi.org/software/ não.

Para o benefício de quem acompanha este assunto...

Acabei de tentar compilar a tag v1.6.2 no Ubuntu 18.04 e ela não consegue compilar com:

rpi-imager/main.cpp:250:19: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                   ^~~~~~~~
                   screens
rpi-imager/main.cpp:250:49: error: ‘class QApplication’ has no member named ‘screenAt’; did you mean ‘screens’?
         if ( !app.screenAt(QPoint(x,y)) || !app.screenAt(QPoint(x+w,y+h)) )
                                                 ^~~~~~~~
                                                 screens

porque essa função foi adicionada no Qt 5.10, mas o Ubuntu 18.04 inclui apenas o Qt 5.9.5.
Portanto, parece que minha versão da v1.6.1 é "fim da linha" para usuários do Ubuntu 18.04 :wink:

Eles são para aqueles que _não_ querem novas versões de software.

Não. Eu uso LTS porque atualizar ou instalar uma nova versão consome muito tempo. Depois de instalar muito tem que ser modificado/ajustado, instalado, configurado etc. Leva muito tempo. O LTS oferece a oportunidade de usar um sistema por muito mais tempo. A partir do meu atual 18.04, não vou mais usar o Ubuntu (mas isso é outra história).

Eu uso vários PPAs + algumas imagens de aplicativos. Para coisas como PHP eu mesmo instalo.

Receio que 20.04 LTS seja o novo mínimo, porque atualizei para isso. :-)

Acredito que toda essa discussão "18.04 muito antiga" está faltando um problema enorme e mais profundo com o projeto: por que o processo de compilação está vinculado à sua versão específica? Você está compilando e publicando _yourself_? O rpi-imager não tem uma ação CI, PPA, Github ou qualquer outra ferramenta para um fluxo de trabalho de criação de nuvem?

Contanto que a ferramenta _that_ suporte 18.04 (e as fontes sejam compatíveis), o sistema operacional pessoal do @maxnet deve ser irrelevante. Um PPA pode ser compilado para _todas_ as versões atuais do Ubuntu. Travis-CI e Github podem ser construídos para muitas plataformas. Você pode até usar o Windows para desenvolvimento e deixar a nuvem ser construída para Fedora, Mac, BSD, ARM, não importa quão antiga ou avançada seja a plataforma.

Dito isto...

Desde que essa ferramenta suporte 18.04 (e as fontes sejam compatíveis)

1) As fontes não serão compatíveis no futuro sem a magia #ifdef.
Métodos mais novos não existem nas versões antigas do Qt.
Usar os métodos mais antigos fornece vários avisos obsoletos nas versões mais recentes do Qt 5 e desaparecerá no Qt 6

2) Este é um aplicativo que precisa ser assinado por código em pelo menos Windows e Mac OS X e não sou um grande fã de compartilhar chaves de assinatura de código com provedores de nuvem.

3) Ainda precisaria de uma instalação de cada sistema operacional para poder testar se o resultado funciona corretamente.
Esse tipo de software (com interação com serviços do sistema e hardware físico como leitores de cartão SD) não é tão adequado para frameworks de testes automatizados...

E o Ubuntu 20 LTS está fora há um ano.

E o Ubuntu 18 ainda é suportado por mais dois anos inteiros. Seu ponto?

Esteja ciente de que a utilidade geral do Ubuntu 18 para desenvolvedores está diminuindo rapidamente.
...
Qual é a razão pela qual você ainda está usando 18?

Isso... não é como lidar com esse problema. As razões particulares de @lurch para usar 18 não devem importar. Existem muitos. Como você tinha o seu para mudar para 20.04, enquanto alguns já pularam em 21.10.

Não é razoável esperar que um LTS antigo continue sendo uma plataforma suportada um ano após o lançamento do atual.

Isto é. É chamado de LTS por um motivo! Suporte de _Longo Prazo_ .

houve um período de carência de um ano!

Falso. O "período de carência do ano" só _começará_ em abril de 2022 , onde teremos _então_ um ano inteiro até _2023_ para migrar para o Ubuntu 22.04, ignorando totalmente o 20.04, enquanto ainda usamos um sistema totalmente compatível. Eu _realmente_ não quero o incômodo de atualizar todo o sistema operacional a cada 2 anos

Vamos lá pessoal... O Ubuntu acaba de abraçar totalmente o Raspberry, lançando não apenas uma edição Server, mas também Desktop, Core, toda a família. Eles adicionaram todos os pacotes específicos do Raspberry aos seus repositórios, sem mais PPAs necessários para rpi-eeprom ou vcgencmd .

Por favor, apoie totalmente também para um casamento longo e feliz :1st_place_medal:

E o Ubuntu 18 ainda é suportado por mais dois anos inteiros. Seu ponto?

"Suportado" não significa que você terá versões mais recentes do software.
Tudo em um sistema Ubuntu 18 é a versão 2018 do software, com apenas correções de estabilidade e segurança adicionadas como backports posteriormente.
Você ainda pode executar versões mais antigas do Imager nele, para corresponder ao resto do sistema.

1. Este é um aplicativo que precisa ser assinado por código em pelo menos Windows e Mac OS X e não sou um grande fã de compartilhar chaves de assinatura de código com provedores de nuvem.

A Raspberry (a empresa/organização) não fornece _qualquer_ infraestrutura ou orientação sobre isso? Quero dizer... IMHO rpi_imager é um componente chave no ecossistema da Raspi. É o próprio _ponto de entrada_ de usá-lo. Ele é exibido nos sites oficiais de _both_ Raspberry e Ubuntu como o imager endossado.

Não tenho certeza qual é a política de suporte oficial.

Dado o alto perfil deste projeto, estou realmente surpreso que não haja uma política oficial sobre isso.

"Suportado" não significa que você terá versões mais recentes do software. Tudo em um sistema Ubuntu 18 é a versão 2018 do software, com apenas correções de estabilidade e segurança adicionadas como backports posteriormente.

Ponto justo, e eu concordo. Não me importo de usar uma versão desatualizada, desde que minha versão _atual_ continue funcionando. E não foi isso que aconteceu aqui.

rpi-imager , instalado a partir de snap , apenas _quebrou_ do nada, ontem. Ele parou de funcionar, com os mesmos erros $# dmesg AppArmor e unidades em branco como @lurch relatou, o que me levou até aqui. Por que uma versão incompatível foi carregada nos canais 18.04?

Ponto justo, e eu concordo. Não me importo de usar uma versão desatualizada

Então você pode tentar o 1.6.0 mais antigo: https://downloads.raspberrypi.org/imager/imager_1.6_amd64.deb

rpi-imager, instalado a partir do snap, acabou de sair do azul

Problemas de snap podem ser relatados aqui: https://github.com/popey/imager-snap/issues
Não estamos envolvidos com essa versão.

Alguns esclarecimentos possivelmente relevantes:

rpi-imager , instalado a partir de snap , apenas _quebrou_ do nada, ontem.

Talvez tenha quebrado antes. Eu tenho usado regularmente para traças, mas sempre usando a mesma imagem (em cache). Ontem eu tentei alguns novos, então talvez seja por isso que só agora o problema se manifestou. A versão instalada é 1.6.2, e IIRC tem sido assim por pelo menos algumas semanas.

Não me importo de usar uma versão desatualizada

Não é que eu não me importe. Eu faço. Mas estou ciente de que não tenho direito a nada. Eu só queria que alguns projetos adotassem uma abordagem mais conservadora quando se trata de adotar novas APIs que podem quebrar versões mais antigas (mas ainda não com EOL).

Eu, por exemplo, faço muito desenvolvimento em Python e enfrento muito o mesmo dilema: se há um recurso novo e lindo no Python 3.9, evito usá-lo mesmo que já esteja no Python 3.11, porque distribuições mais antigas como O CentoOS ainda vem com o antigo 3.6 . Pelo menos eles têm 3.8 _available_, então eu posso aumentar minha versão de fonte mínima para isso. Uma abordagem semelhante pode ser tomada aqui?

Indo mais fundo nos logs, acredito que estamos lidando com 2 problemas distintos e independentes aqui:

• De alguma forma eu sou (e sempre fui) capaz de instalar e lançar não apenas 1.6.1, mas 1.6.2 do snap. Então o que o @popey fez para compilá-lo para 18.04 funcionou, parabéns! Isso sugere que meus erros sobre o AppArmor ao escrever imagens não têm nada a ver com dependências de pacotes ou problemas de compilação do QT ao construir o .deb (esse problema _este_ parece ser), embora ambos se manifestem em 18.04

• Meu problema, e parece que o do @XECDesign também, é sobre _permissions_, e parece que esse é um problema apenas de encaixe . Então vou me mudar para lá conforme as instruções.

Para quem vem aqui com problemas como _"Uma política do AppArmor impede que este remetente envie esta mensagem..."_, _"Não foi possível abrir o soquete de rede"_ ou _"operação não permitida"_, acesse este problema , aqui não. É que há muitos problemas com 18.04 em seu título :-)

capaz de instalar e lançar não apenas 1.6.1, mas 1.6.2 do snap. Então o que o @popey fez para compilá-lo para 18.04 funcionou, parabéns!

Eu acho que o snap é um formato de embalagem "autocontido"? Portanto, provavelmente é capaz de incluir uma versão mais recente das bibliotecas Qt do que as incluídas no Ubuntu 18.04? (que a versão .deb do RPi Imager precisaria usar)

Problemas de snap podem ser relatados aqui: https://github.com/popey/imager-snap/issues
Não estamos envolvidos com essa versão.

@maxnet Parece que recebemos alguns relatórios de problemas sobre a versão instantânea do RPi Imager (provavelmente porque essa é a versão que a "loja de software" do Ubuntu instala), sobre a qual obviamente não podemos fazer nada. Talvez valha a pena usar o recurso de modelo de problema do GitHub, para direcionar as pessoas com problemas com a versão instantânea do RPi Imager diretamente para o repositório do Popey ? :dar de ombros:

A versão mais antiga 1.6.0 (referenciada por @maxnet) instalou bem no Linux Mint 19.3 (repositório biônico). THX