Forum Ubuntu-it

SaulGoodman ha scritto: ↑

domenica 12 gennaio 2025, 2:49

woddy68 ha scritto: ↑

domenica 12 gennaio 2025, 0:08

SaulGoodman ha scritto: ↑

sabato 11 gennaio 2025, 16:59

xavier77 ha scritto: ↑

sabato 11 gennaio 2025, 16:42

Tutto già è scritto: InternetRete/Navigazione/GoogleChrome#Da_pacchetto_deb, in cui c'è il link a AmministrazioneSistema/InstallareProgrammi/PacchettiDebian in cui sono presenti tutti i metodi per installare i pacchetti deb.

Il primo comando con l'indirizzo esatto da cui scaricare il file .deb non è specificato nel wiki, e farebbe comodo sopratutto nel caso in cui uno (per sbaglio o disattenzione) abbia disinstallato firefox snap prima di installare Chrome, come è successo a me qualche giorno fa e si trovi solo col terminale a disposizione e un cellulare. In questi casi specificando l'URL diretto, si rendono le cose un po' piu semplici e si evita all'utente di cercare altrove (finendo sul sito di Aranzulla ). Ma vedete voi.

xavier77 ha scritto: ↑

sabato 11 gennaio 2025, 16:42

Inoltre non sempre l'ordine in cui sono scritte le procedure rappresenta l'ordine di importanza o priorità (ogni utente decide in base alle proprie esigenze e preferenze).

Certo, ma perché non evidenziare in alto quello che è piu semplice e alla portata di mano, anziché la soluzione più Machiavellica? Magari non tutti sono capaci di decidere bene, sopratutto se hanno fretta. Magari rendiamogli la vita piu facile. Non si fa un gran servizio altrimenti, secondo me.

Questo è un classico in Linux ed è vero, spesso è proprio quello che spaventa i nuovi utenti.
Se guardi i wiki di Windows prima viene spiegato come farlo semplicemente via grafica, poi al limite spieghi come farlo da Prompt. Ma qui hanno tutti l'ossessione del terminale, che in molte occasioni è comodo, ma personalmente utilizzo solo di rado in caso di problemi.

Qui non è questione di terminale o non terminale. Qui è questione di privilegiare una procedura che prevede due passaggi anziché una che ne prevede 6 di cui 4 superflui. Poi se vogliamo far girare a zonzo le persone, ok. Anzichè magari facilitare l'utente specificando l'url da cui scaricare direttamente un pacchetto che contiene TUTTO. Ma comunque, io la mia l'ho detta... Decidono altri.

È chiarissimo come la pensi.
Due soli passaggi sono anche scaricare il pacchetto dal sito e farci clic sopra.
La procedura da te indicata fa esattamente la stessa cosa, ma col terminale.

) Salve, @xavier77 in effetti in questa wiki InternetRete/Navigazione/GoogleEarth, ch'è l'altra metà del cielo della wiki in oggetto, il sottoparagrafo Da file deb viene prima del sottoparagrafo Da repository Google.

A dattilografarla tutta manca la specificazione Google nella wiki InternetRete/Navigazione/GoogleEarth, che sarebbe il caso di specificare trattandosi di repository ufficiale.

:: Ciao

wilecoyote ha scritto: ↑

domenica 12 gennaio 2025, 11:22

) Salve, @xavier77 in effetti in questa wiki InternetRete/Navigazione/GoogleEarth, ch'è l'altra metà del cielo della wiki in oggetto, il sottoparagrafo Da file deb viene prima del sottoparagrafo Da repository Google.

A dattilografarla tutta manca la specificazione Google nella wiki InternetRete/Navigazione/GoogleEarth, che sarebbe il caso di specificare trattandosi di repository ufficiale.

:: Ciao

Ok, ma qui è OT.

Questa guida è ridondante e problematica.

Con le ultime versioni del browser, viene distribuito direttamente il file sources formato deb822
Come si vede è impostato per leggere la chiave sotto /usr/share/keyrings/ e non sotto /etc/apt/keyrings/. Seguendo la procedura "Da repository Google" invece si configura una chiave sotto /etc/apt/keyrings/ . Al primo aggiornamento, però, il pacchetto procederà alla riscrittura del file google-chrome.sources e alla duplicazione della chiave che metterà sotto /usr/share/keyrings/ .

Insomma, tutta la procedura "Da repository Google" non ha più senso e andrebbe rimossa o adeguata (*), sia per semplificare la vita all'utente, sia a chi cerca di aiutarlo sul forum linkando questa guida.

Lo dico in un altro modo per farla più semplice: installando il pacchetto .deb direttamente da Google non serve fare altro (pensa a tutto lui: installa la chiave di firma, imposta il repo).

Al limite, si può aggiungere che aggiornando da terminale, la nota: o equivalente italiano, può essere ignorata. Immagino che prossimamente Google fixerà anche questo "bug" aggiungendo la direttiva "Architectures: amd64" al file .sources.

EDIT
(*) L'unico caso d'uso in cui potrebbe essere ancora utile che mi viene in mente è quello in cui un utente si trovi senza browser (magari ha rimosso firefox da snap prima di installare chrome?) e possa voler installare chrome in questa maniera, leggendo la guida da un altro dispositivo (è un caso piuttosto borderline ma a me è capitato ).

) Salve, suppongo che lo stesso metodo sarà esteso a tutti gli altri Chromium-based, o quantomeno a quelli più comuni e diffusi.

:: Ciao

wilecoyote ha scritto: ↑

mercoledì 6 maggio 2026, 21:58

) Salve, suppongo che lo stesso metodo sarà esteso a tutti gli altri Chromium-based, o quantomeno a quelli più comuni e diffusi.

Degli altri crhomium-based si discute qui o in altri thread dedicati? In ogni caso non ne ho idea.

Adesso tengo sottocchio la situazione se al prossimo aggiornamento di Chrome il file sources viene ripristinato o no.

Confermo che il file .sources viene sovrascritto con l'aggiornamento successivo, così che ogni sua modifica è sostanzialmente inutile.

Ma visto che:

# This file will not be recreated if removed.

Ora provo a rinominarlo, inserisco la direttiva "Architectures: amd64", e vediamo se regge al prossimo aggiornamento.

frapox ha scritto: ↑

sabato 9 maggio 2026, 23:05

Confermo che il file .sources viene sovrascritto con l'aggiornamento successivo, così che ogni sua modifica è sostanzialmente inutile.

Ma visto che:

# This file will not be recreated if removed.

Ora provo a rinominarlo, inserisco la direttiva "Architectures: amd64", e vediamo se regge al prossimo aggiornamento.

no. è da due anni o forse più, che gira questo bug
Ho fatto una ricerca, risultano dal 2024, ..discussioni sulla community di google su questo warning.

ivantu ha scritto: ↑

domenica 10 maggio 2026, 11:04

frapox ha scritto: ↑

sabato 9 maggio 2026, 23:05

Confermo che il file .sources viene sovrascritto con l'aggiornamento successivo, così che ogni sua modifica è sostanzialmente inutile.

Ma visto che:

# This file will not be recreated if removed.

Ora provo a rinominarlo, inserisco la direttiva "Architectures: amd64", e vediamo se regge al prossimo aggiornamento.

no. è da due anni o forse più, che gira questo bug
Ho fatto una ricerca, risultano dal 2024, ..discussioni sulla community di google su questo warning.

risulta anche che non funzioni quel workaround? Beh comunque ci metterò poco a scoprirlo... al primo aggiornamento che arriva.

) Salve, pelle modifiche richieste già provveduto a postarle in [Guida] Microsoft Edge.

D'adattare al nome del browser of course…

:: Ciao

Ho aggiornato la guida seguendo le varie segnalazioni, compresi i suggerimenti di frapox, ovviamente dopo aver fatto di persona un paio di semplici verifiche.

Ho perciò eliminato il paragrafo "da repository" (ormai ridondante) ma ho aggiunto un comando per scaricare il deb da terminale (qualora un ipotetico utente non abbia a disposizione un browser).

Grazie

xavier77 ha scritto: ↑

domenica 10 maggio 2026, 15:48

Ho aggiornato la guida seguendo le varie segnalazioni, compresi i suggerimenti di frapox, ovviamente dopo aver fatto di persona un paio di semplici verifiche.

Ho perciò eliminato il paragrafo "da repository" (ormai ridondante) ma ho aggiunto un comando per scaricare il deb da terminale (qualora un ipotetico utente non abbia a disposizione un browser).

Grazie

Grazie a te.

frapox ha scritto: ↑

domenica 10 maggio 2026, 15:06

ivantu ha scritto: ↑

domenica 10 maggio 2026, 11:04

frapox ha scritto: ↑

sabato 9 maggio 2026, 23:05

Confermo che il file .sources viene sovrascritto con l'aggiornamento successivo, così che ogni sua modifica è sostanzialmente inutile.

Ma visto che:

# This file will not be recreated if removed.

Ora provo a rinominarlo, inserisco la direttiva "Architectures: amd64", e vediamo se regge al prossimo aggiornamento.

no. è da due anni o forse più, che gira questo bug
Ho fatto una ricerca, risultano dal 2024, ..discussioni sulla community di google su questo warning.

risulta anche che non funzioni quel workaround? Beh comunque ci metterò poco a scoprirlo... al primo aggiornamento che arriva.

Il workaround di rinominare il file sources funziona, ho verificato la procedura in un thread di supporto.

Così si evita il (per alcuni fastidioso) messaggio di notice che indica che l'arch i386 non è più supportata quando si dà apt update.

Invito @ivantu e chiunque altro a replicare la procedura e verificare che funziona, così poi eventualmente da aggiungerla alla wiki.

frapox ha scritto: ↑

giovedì 14 maggio 2026, 2:17

frapox ha scritto: ↑

domenica 10 maggio 2026, 15:06

ivantu ha scritto: ↑

domenica 10 maggio 2026, 11:04

frapox ha scritto: ↑

sabato 9 maggio 2026, 23:05

Confermo che il file .sources viene sovrascritto con l'aggiornamento successivo, così che ogni sua modifica è sostanzialmente inutile.

Ma visto che:

# This file will not be recreated if removed.

Ora provo a rinominarlo, inserisco la direttiva "Architectures: amd64", e vediamo se regge al prossimo aggiornamento.

no. è da due anni o forse più, che gira questo bug
Ho fatto una ricerca, risultano dal 2024, ..discussioni sulla community di google su questo warning.

risulta anche che non funzioni quel workaround? Beh comunque ci metterò poco a scoprirlo... al primo aggiornamento che arriva.

Il workaround di rinominare il file sources funziona, ho verificato la procedura in un thread di supporto.

Così si evita il (per alcuni fastidioso) messaggio di notice che indica che l'arch i386 non è più supportata quando si dà apt update.

Invito @ivantu e chiunque altro a replicare la procedura e verificare che funziona, così poi eventualmente da aggiungerla alla wiki.

grazie,
perché non avrebbe dovuto funzionare?? La domanda è che ti chiedo, al prossimo aggiornamento google, potrebbe ritornare comunque a riscrivere il file google-chome.sorces. e il sistema ri-mostrare il messaggio.
Comunque non metto in dubbio che il problema sia in google, fino a quando non risolve questo bug, è certo che il messaggio di architettura i386.

Una precisazione è che il messaggio sia sorto perché stanno bloccando lo sviluppo alle macchine 486, 586 etc.. fino a che non finisce questa campagna. lo ritroveremo sempre questo messaggio.

ivantu ha scritto: ↑

giovedì 14 maggio 2026, 10:25

perché non avrebbe dovuto funzionare?? La domanda è che ti chiedo, al prossimo aggiornamento google, potrebbe ritornare comunque a riscrivere il file google-chome.sorces. e il sistema ri-mostrare il messaggio.
Comunque non metto in dubbio che il problema sia in google, fino a quando non risolve questo bug, è certo che il messaggio di architettura i386.

Una precisazione è che il messaggio sia sorto perché stanno bloccando lo sviluppo alle macchine 486, 586 etc.. fino a che non finisce questa campagna. lo ritroveremo sempre questo messaggio.

Il mio workaround `e teso proprio a evitare di visualizzare il messaggio, e ha retto già un aggiornamento (come ho spiegato anche nel thread linkato NON è stato riscritto): l'invito era proprio a replicare il workaround e verificare che regga all'aggiornamento.