[Silvan]

Ciao,
non ci sono attualmente risposte specifiche alla domanda su come contribuire al progetto.

openmamba ha le caratteristiche di una distribuzione Linux e quindi idealmente sono richieste tutte le attività normalmente inerenti questo tipo di progetto.

Prendendo in considerazione gli aspetti tecnici è necessario ad esempio produrre pacchetti software integrati in modo da fornire un sistema operativo funzionante negli ambiti previsti dal progetto (principalmente Desktop, secondariamente server o ambienti rootfs) e che sia modulare attraverso l’installazione di pacchetti. La produzione di pacchetti per una distribuzione Linux richiede conoscenze tecniche più o meno elevate ma anche disponibilità temporale per il mantenimento di quanto prodotto e la coerenza nelle caratteristiche e stili applicati ai file di specifiche. Altre distribuzioni ben organizzate forniscono documentazione con linee guida che però su openmamba non ci sono ed allora l’unico modo è di studiare lo status-quo ed agire coerentemente quando si producono i propri contributi.

Un altro ambito in cui gli utenti possono contribuire, sia volontariamente che involontariamente, è il testing. Il testing involontario è forse l’unica forma di contributo esterno che openmamba riceve recentemente e consiste nel fatto che gli utenti che usano openmamba segnalino di aver riscontrato problemi specifici. In questi casi viene fornito supporto che sia utile per l’utente ma dal punto di vista di openmamba tale operazione ha rappresentato un contributo per il miglioramento del sistema e di quanto troveranno i successivi utenti. Il testing potrebbe anche esserve volontario, ad esempio rendendosi disponibile ad effettuare verifiche di corretto funzionamento dei supporti live che vengono aggiornati e pubblicati con base mensile.

Chi contribuisce ad un progetto open source dovrebbe anche avere chiare quali siano le motivazioni. Dal punto di vista di chi sviluppa e mantiene openmamba un contributo dovrebbe essere utile a migliorare un ecosistema globale di software libero per l’interesse di tutta la collettività globale oltre che un’opportunità di imparare ed aumentare le proprie conoscenze su questo mondo, che poi potrebbero avere utilità anche in possibili sbocchi professionali. Escluderei invece come motivazioni il fatto di ottenere riconoscimenti, apprezzamenti e guadagni diretti perché non è il caso, soprattutto in un progetto di nicchia come openmamba.

Alcuni contributi, di qualunque tipo siano, arrivano spontaneamente, chi produce il contributo è consapevole delle proprie conoscenze, capacita e volontà e tempo disponibile e si propone di studiare e produrre autonomamente un proprio specifico contributo. Come manutentore di questo progetto non ho l’impostazione per chiedere un “curriculum” per analizzare e collocare un candidato come farebbe un ufficio personale di un’azienda. Chi vuole contribuire secondo me potrebbe individuare un’esigenza, proporsi di attivarsi per colmarla ed eventualmente interagire se l’interesse sia di integrare il proprio lavoro negli ambiti “ufficiali” di openmamba.

In questo mondo, vedo ad esempio la comunità di sviluppo del kernel Linux o di KDE Plasma, difficilmente qualcuno ha la disponibilità di qualcun’altro (né vuole averla) per aspettarsi che faccia cose o che possa ricevere dei compiti, ognuno si auto candida: impara da solo a fare cose e poi le propone per l’integrazione e accettazione a chi mantiene, si discute cosa vada bene e cosa vada modificato.

Come manutentore di openmamba rimango sempre disponibile a fornire informazioni specifiche che riguardino come sono certe cose specifiche del progetto openmamba. Essendo openmamba una distribuzione Linux come altre mille, il 99% delle cose sono conoscenza collettiva e distribuita ed in questo senso ci si aspetta che chi contribuisca sia in grado di documentarsi ed imparare da solo.

[Silvan]

Buongiorno,
cercare di capire come possa essere supportata la retroilluminazione della tastiera si può fare raccogliendo informazioni ed effettuando dei test sull’hardware specifico.
In prima analisi, poiché nel post non è specificato, andrebbe verificato che il supporto di basso livello per la gestione della retroilluminazione sia disponibile, il che corrisponde a verificare l’esistenza del file di tipo sysfs /sys/class/leds/smc::kbd_backlight/brightness. In caso di dubbi su come fare questa verifica posso consigliare di eseguire il seguente comando e di riportare qui l’output al fine di agevolare l’eventuale avanzamento di questa richiesta di supporto:
ls /sys/class/leds

È anche utile verificare che i moduli del kernel coinvolti nella gestione della retroilluminazione su Macbook Apple siano caricati, dovrebbero essere applesmc e hid_apple. Questo si può di nuovo verificare ed eventualmente riportare in un commento di risposta eseguendo il seguente comando, sempre da una finestra di terminale:
lsmod |grep apple

In particolare il modulo hid_apple dovrebbe configurare i tasti funzione anche per il controllo di retroilluminazione. Nel pacchetto macbook-tools (il cui target era però il modello Macbook Pro del 2006) tale modulo veniva configurato con:
options hid_apple fnmode=2

ma si potrebbero verificare le opzioni di caricamento di questo modulo al fine di verificare se vadano impostate diversamente per il Macbook Air del 2012. Tuttavia questa è un indicazione di massima che lascia a chi scrive avere o recuperare la conoscenza su come utilizzarla per provare a risolvere il problema o che eventualmente si potrà prendere in considerazione in prossimi commenti di questo post dopo aver però constatato che le verifiche di basso livello di cui sopra corrispondano intanto con quanto atteso.

• Questa risposta è stata modificata 1 weeks, 3 days fa da Silvan.

[Silvan]

Ciao,
il comando rpmbuild è il tool di più basso livello per creare pacchetti rpm ed è disponibile, insieme al comando rpm, in qualunque installazione di openmamba. A questo livello la documentazione è quella di rpm che si trova sul sito rpm.org.

rpmdevtools credo sia un progetto di Fedora che non c’è in openmamba.

Sopra rpmbuild openmamba usa autospec che permette di creare gli “specfiles” che però ha una documentazione soltanto nell’help in linea eseguendolo con:
autospec --help

Prima però va installato con:
sudo dnf install autospec

openmamba poi usa autodist e webbuild che sono anch’essi strumenti nativi ed il cui modo più semplice di utilizzarli è installando un docker container tramite il progetto openmamba-docker-buildvm. L’installazione del container fornisce già installate anche le dipendenze di base per lo sviluppo che sono elencate in questo file.

[Silvan]

Ciao, nell’ultimo aggiornamento di NetworkManager alla release 1.54.0-2mamba ho applicato una patch introdotta upstream che potrebbe essere rilevante per il problema qui segnalato.

• Questa risposta è stata modificata 1 months fa da Silvan.
• Questa risposta è stata modificata 1 months fa da Silvan.

[Silvan]

Ho corretto il comando inizialmente suggerito in:
echo -e "[connection]\nwifi.powersave = 2" | sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf

[Silvan]

Il problema potrebbe anche essere stato introdotto dall’aggiornamento di NetworkManager alla versione 1.54.0.
In questo contesto la più comune causa di possibile problematica che risulti è la gestione del powersaving del wifi, per cui posso suggerire di disattivare questa funzionalità eseguendo il seguente comando:
echo -e "[connection]\nwifi.powersave = 2" | sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf

• Questa risposta è stata modificata 1 months fa da Silvan.

[Silvan]

Ciao,
per vedere se il driver è stato aggiornato sarebbe più utile l’output di
sudo dkms status

comunque era già previsto che l’aggiornamento non fosse la soluzione.

Guardando il report noto però che sono caricati sia il driver rtw88_8822bu che 88x2bu.
Potresti provare a mettere prima uno poi l’altro in blacklist e vedere il comportamento dopo il riavvio.

Prima proverei ad usare il driver del kernel, quindi mettendo il blacklist 88x2bu:
echo "blacklist 88x2bu" | sudo tee /etc/modprobe.d/rtw88.conf

Poi se non risolve proverei a mettere in blacklist invece il driver integrato del kernel:
echo "blacklist rtw88_8822bu" | sudo tee /etc/modprobe.d/rtw88.conf

[Silvan]

Ciao,
il report indica che il driver in uso è rtl88x2bu fornito dall’omonimo pacchetto esternamente al kernel. Il driver riceverà un aggiornamento all’ultima versione ma il log delle modifiche nel repository github non mostra cambiamenti di rilievo in quanto solo riferite al supporto di versioni del kernel più recenti di quella in uso in openmamba.
Nel report risulta che gli aggiornamenti vengano eseguiti, almeno negli ultimi due giorni, quotidianamente. Non ci sono stati aggiornamenti recenti nel kernel e l’unico componente che potrebbe essere rilevante, confrontato con il fatto che il problema è iniziato “da qualche giorno”, è linux-firmware. Tuttavia, linux-firmware è disponibile come aggiornamento probabilmente da 1 giorno, massimo 2, inoltre una verifica delle modifiche all’ultima versione dello stesso pacchetto non mostrano anch’esse cambiamenti rilevanti ed inoltre non è chiaro se il driver rtl88x2bu carichi un firmware da questo pacchetto, anzi sembra di no.
Al momento queste sono le considerazioni disponibili.
Qui è anche disponibile il dettaglio di una conversazione in merito effettuata con ChatGPT: https://chatgpt.com/share/6898cce1-b848-800a-a5a8-31e6a515e4fb.

[Silvan]

sermor wrote:

Ok qualche altra dritta, per i file metadata.json e cmakelist.txt come posso procedere? Li faccio con kate e succesivamente li carico sul progetto, o lo creo direttamente su github? E poi, una volta fatto il resto via terminale (creazione cartelle, immagini ecc.) come lo uploado via terminale sul progetto?

Ciao, certo, puoi creare i file in locale con kate o altro editor di testo preferito. Non userei mai direttamente l’interfaccia web di github, puoi lavorare più comodamente in locale.
Ora, non ha senso che ti scriva una guida su come usare git da linea di comando, con tutta la documentazione e gli aiuti che ci sono su web e facendo domande ai prompt delle AI, quindi scrivo solo sinteticamente:

1) una volta creati dei files dentro la struttura locale del tuo clone del repository git li aggiungi con git add percorso_e_nome_del_file (sostituisci percorso_e_nome_del_file con l’effettivo percorso che vuoi aggiungere)
2) crei un commit dei file aggiunti con git commit (qui devi inserire una descrizione del commit e se usi l’editor predefinito che è vim si aprirebbe una parentesi su come usare e chiudere vim con salvataggio)
3) mandi con git push (qui si apre una parentesi sulla configurazione dei permessi)

Altro comando utile è git status che ti fa vedere lo stato dei file modificati o nuovi.
Mentre ti scrivo comprendo che potresti avere delle difficoltà, se non sei pratico con il terminale di Linux, che richiedono di diventarne pratico.

[Silvan]

sermor wrote:

Ci sono arrivato, più o meno. Adesso ho capito meglio. Dovevo intanto scaricare anche il pacchetto gh per usare github via terminale, oltre a quello che mi avevi suggerito tu. Scusa la mia idiozia, ma non sono avvezzo all’uso del terminale. Specie se sostanzialmente devi creare cartelle e sotto cartelle, e/o immagini più piccole. Aver usato Windows per un quarto di secolo circa non aiuta in questo. Nonostante usi solo linux ora, è un po’ difficle scrollarselo di dosso, anche “nel modo di pensare” (o operare, per meglio dire). XD Per fare questo però, non lo si può fare dal desktop invece che usare il terminale e poi uploadare le cartelle e i relativi files su github? O meglio, cloni il repository via terminale, e poi fai le operazioni via desktop e le uploadi direttamente via interfaccia grafica?

Scusa, ho dato per scontato l’utilizzo di git da terminale attraverso il comando git che dovrebbe essere già disponibile, se no si installa installando il pacchetto git. Praticamente tutti gli IDE moderni supportano l’integrazione con git ma bisogna imparare ad usarli quanto la linea di comando e se non si capisce bene cosa si sta facendo si rischia di perdere più tempo, a meno che non decidi di voler dedicare il tempo per imparare a fare le cose giuste. Anche dolphin, il file manager predefinito di Plasma e openmamba può supportare l’integrazione con git attivando git nella pagina di configurazione del menù contestuale. In ogni caso per fare il commit bisogna configurare l’autenticazione con chiave privata e pubblica nella cartella .ssh (mentre magari il comando gh che hai usato usa l’autenticazione di tipo nome utente e password). Io preferisco fare tutto da terminale, se utilizzi degli strumenti ti fanno le stesse cose ma magari in modo meno chiaro ed una comprensione di base da terminale sarebbe sempre consigliata secondo me.

[Silvan]

Ciao,
per spostare i file in rispettive cartelle e creare le anteprime puoi fare così (esempio con una immagine):

mkdir -p AGreenForest/contents/images
git mv AGreenForest.png AGreenForest/contents/images/1920x1080.png
magick AGreenForest/contents/images/1920x1080.png -resize 440 AGreenForest/contents/screenshot.png
git add -A AGreenForest

Per il comando magick dovresti installare il pacchetto ImageMagick se non lo è già.

Poi ovviamente devi fare git commit, una volta fatto per tutte le immagini o se preferisci volta per volta.

Così rimangono da creare i file metadata.json e il CMakeLists.txt.

Riguardo alle immagini, c’è una certa varietà che potrebbe piacere agli utenti, a seconda dei gusti. Le immagini non sono “brandizzate” per openmamba quindi il tuo progetto potrebbe anche essere un generico progetto di sfondi per il desktop, ma magari evoluzioni future potranno giustificare il fatto che il progetto si riferisca direttamente ad openmamba.

 

• Questa risposta è stata modificata 1 months, 4 weeks fa da Silvan.

[Silvan]

sermor wrote:

Ciao, scusa la risposta tardiva, ma ho rivisto un po’ di immagini, magari da aggiungere al progetto. Per quanto riguarda il nome del repository, lo posso chiamare, e lo chiamerò openmamba-sermor-wallpapers-1080p. Così almeno si sà già che formato avranno.

Come preferisci, ovviamente, ma mettere il suffisso -1080p e dover creare repository diversi per ogni dimensione lo trovo limitante per il futuro, il repository git è proprio un territorio fatto apposta per evolversi ed accogliere modifiche future, come per aggiungere poi degli sfondi di risoluzione più alta.

sermor wrote:

Magari successivi repository di immagini potranno essere più grandi a livello di risoluzione, Per quanto riguarda la licenza, ne posso mettere svariate, ma ho opzioni limitate. Tra quelle che posso mettere ci sono: Creative Common Zero v1.0 universal, GNU General Public License v2.0, GNU General Public License v3.0. A questo punto penso che la CC0 sia la migliore delle 3. Fammi sapere cosa ne pensi. Grazie per gli altri suggerimenti. Bene, torno a mettermi a lavoro. Se ho qualche incertezza, riscrivo.

Ho dato un’occhiata a CC0 e i motivi per cui non sia stata approvata da OSI, ovvero perché menziona esplicitamente un discorso sui brevetti, che anche se con intento permissivo, OSI preferisce che non siano neanche menzionati. Comunque per la distribuzione in openmamba va bene.

[Silvan]

sermor wrote:

Silvan wrote:

Ciao! Per openmamba la cosa migliore sarebbe se creassi un repository su github (o altro servizio analogo che preferisci) dove puoi mettere e mantenere gli sfondi come tuo progetto aggiungendo la licenza.

Ok si, si può fare. Ho un account su github e posso creare un mio progetto volendo, non c’è problema. Sarebbe anche la prima volta.

Come prima cosa consiglierei un nome specifico del progetto, ad esempio sermor-wallpapers o, se applicabile solo ad openmamba, openmamba-sermor-wallpapers (un nome generico come openmamba-wallpapers  andrebbe in conflitto con un pacchetto già eistente).

sermor wrote:

Silvan wrote:

Nel caso puoi fare riferimento al progetto plasma-workspace-wallpapers. Qui puoi vedere che la licenza è GPL3, inoltre se volessi prendere spunto dal file CMakeLists.txt per adattarlo ai tuoi wallpaper sarebbe ottimo per me per creare un pacchetto per oopenmamba. Poi eventualmente uno o più di questi wallpapers potrebbero diventare predefiniti in openmamba nei periodi futuri.

Ok, si può fare. Metterò la licenza GPL3. Volendo si posso prendere spunto da quel file, ma mi serve qualche dritta.

In realtà GPL è la licenza del progetto principale ma poi nei file metadata.json di plasma-desktop-wallpapers le licenze sono più idonee per questo tipo di opera, come ad esempio CC-BY-SA-4.0, ovviamente decidi tu.

sermor wrote:

Silvan wrote:

Posso cercare di aiutarti se avessi bisogno di alcune dritte su come creare il progetto git.

Beh, qualche dritta non farebbe male. Creerò il mio progetto, ma volendo creare un file CMakeLists.txt, come lo imposto? Non ho mai fatto script fin’ora, se non copiare qualcosa e basta. Inoltre, non ho file di metadata.json delle mie immagini, devo crearle, oppure va bene senza, e basta che ci sia il file CMakeLists.txt?

La cosa più semplice per me è clonare il repository plasma-desktop-wallpapers, crei una cartella per ogni tuo wallpaper a immagine e somiglianza delle cartelle presenti (che poi cancelli). Sì, ci vuole un file metadata.json dove dai un nome ad ogni sfondo e metti le tue informazioni, autore, licenza ecc. Non c’è bisogno delle traduzioni in tutte le lingue, basta un Name in ogni sezione. Nel CMakeCache.txt cambi PROJECT_VERSION (es. 1.0.0) e le righe di install in modo da corrispondere alle cartelle con i tuoi wallpapers. Ci vuole anche uno screenshot.jpg per permettere agli utenti di vedere l’anteprima. Per iniziare non importa che si siano tutti i formati, se li hai fatti 1920×1080 basta mettere quel formato. Certo, uno sfondo predefinito di openmamba che sia bello per tutti sarebbe bene se fosse 3840×2160 o 2560×1440 ma per iniziare va bene così. Quando hai fatto tutto puoi cancellare la cartella .git del clone iniziale prima di aggiungere e fare il primo commit su github. Visto che usi l’IA se hai dubbi sul formato di questi files e altre cose tecniche puoi anche chiedere, ChatGPT e altri, di solito rispondono molto bene e velocemente.

[Silvan]

Ciao!

Per openmamba la cosa migliore sarebbe se creassi un repository su github (o altro servizio analogo che preferisci) dove puoi mettere e mantenere gli sfondi come tuo progetto aggiungendo la licenza. Nel caso puoi fare riferimento al progetto plasma-workspace-wallpapers. Qui puoi vedere che la licenza è GPL3, inoltre se volessi prendere spunto dal file CMakeLists.txt per adattarlo ai tuoi wallpaper sarebbe ottimo per me per creare un pacchetto per oopenmamba. Poi eventualmente uno o più di questi wallpapers potrebbero diventare predefiniti in openmamba nei periodi futuri.

Posso cercare di aiutarti se avessi bisogno di alcune dritte su come creare il progetto git.

[Silvan]

Ciao,
il problema, se corrisponde con quanto già noto, è sorto con l’aggiornamento di libxml2 alla versione 2.14. Il consiglio è di effettuare una-tantum l’aggiornamento da una finestra di terminale con il comando:

sudo dnf update --refresh

in quanto il problema risulta limitato soltanto al sottosistema di gestione degli aggiornamenti nell’ambiente grafico (PackageKit).

[Autore]

Articoli