Articoli su aldolat.it

Spostare in cima il pannello degli allegati di Thunderbird

Aldo Latino (aldolat@gmail.com) — Sun, 19 Apr 2026 17:15:00 +0200

Ci sono persone che si perdono gli allegati di un messaggio in Thunderbird perché non si accorgono della loro presenza in fondo al messaggio. Una possibile soluzione potrebbe essere quella di spostare questo pannello sotto l'intestazione e sopra il corpo del messaggio, proprio come fanno Evolution e Outlook.

* * *

Non tutti apprezzano che Thunderbird mostri gli allegati in fondo al messaggio e una delle motivazioni addotte è che non si accorgono della loro presenza lì in basso, con tutte le conseguenze che ciò può comportare. Sarebbe ottimo dare agli utenti la possibilità di scegliere dove mostrarli e ricordo che diedi questo consiglio al gruppo di sviluppo di questo client, ma non se n’è fatto nulla. Ultimamente su Reddit (ma anche in passato, se fate una ricerca) qualcuno ha chiesto come si possa fare questa modifica e ho voluto provarci. L’esito è abbastanza buono, anche se non perfetto: credo che per un uso generale possa andare bene. Questa è la situazione dei pannelli alla fine delle modifiche:

Figura 1. Come appare Thunderbird spostando la barra degli allegati più in cima.

Abilitare l’uso dei CSS

Anzitutto è necessario abilitare l’uso dei CSS in Thunderbird. Nelle impostazioni, scheda Generale, fare clic su Editor di configurazione e cercare:

toolkit.legacyUserProfileCustomizations.stylesheets

Impostare su true il valore. Chiudere Thunderbird.

Gli stili

Nella cartella del proprio profilo Thunderbird, creare la directory chrome e, al suo interno, creare il file userChrome.css. Incollarvi queste regole:

/******
 * Email reading
 */

#messagepanebox {
    display: flex !important;
    flex-direction: column !important;
}

#singleMessage {
    order: 1 !important;
}

#attachmentView {
    order: 2 !important;
}

#messagepane {
    order: 3 !important;
    flex: 1 1 auto !important;
}

#attachment-splitter {
    display: none !important;
}

/******
 * Email composing
 */

#composeContentBox {
    display: grid !important;
    grid-template-columns: var(--contactsSplitter-width, 222px) auto 1fr !important;
    grid-template-rows: auto auto auto 1fr !important;
    height: 100% !important;
}

#contactsSidebar {
    grid-column: 1 !important;
    grid-row: 1 / -1 !important;
    min-height: 0 !important;
    overflow: hidden !important;
}

#contactsSplitter {
    grid-column: 2 !important;
    grid-row: 1 / -1 !important;
}

#MsgHeadersToolbar {
    grid-column: 3 !important;
    grid-row: 1 !important;
}

#attachmentArea {
    grid-column: 3 !important;
    grid-row: 2 !important;
}

#FormatToolbox {
    grid-column: 3 !important;
    grid-row: 3 !important;
}

#messageArea {
    grid-column: 3 !important;
    grid-row: 4 !important;
    min-height: 0 !important;
    overflow: hidden !important;
}

#headersSplitter {
    display: none !important;
}

#attachmentSplitter {
    display: none !important;
}

#attachmentBucket {
    max-height: 120px !important;
    overflow-y: auto !important;
}

Salvare e chiudere. Avviare Thunderbird: nelle email ricevute gli allegati dovrebbero vedersi sopra il testo del messaggio. Stesso discorso se provate a comporre un nuovo messaggio e ad allegarvi qualcosa.

Kernel 6.16 in arrivo su Arch Linux e i driver nVidia 390

Aldo Latino (aldolat@gmail.com) — Fri, 08 Aug 2025 08:26:23 +0200

Come già sapete dai post precedenti, la mia scheda video obsoleta non è supportata dai driver nvidia presenti nei repo ufficiali di Arch, motivo per cui devo rivolgermi al pacchetto nvidia-390xx-dkms presente in AUR. Questo significa che, per ogni nuovo kernel rilasciato, bisogna vedere se questi driver vecchissimi vengono compilati correttamente.

Proprio l’altro ieri nella pagina AUR del pacchetto giunge la notizia che il nuovo kernel 6.16 è approdato in testing e che quindi a breve arriverà per tutti: funzionerà questo driver? Il buon @drankinatty ha chiesto nella pagina del pacchetto se qualcuno poteva fare qualche test e la domanda mi ha stuzzicato. Come posso farlo? L’unica cosa che mi è venuta in mente era di provare in una macchina virtuale tra quelle che dedico ad Arch. Sono sicuro che non è questo il metodo standard per questo tipo di prove ma alla fine penso che possa essere sufficiente per il mio scopo.

Quello che ho fatto nella macchina virtuale è stato semplicemente attivare i repository testing e procedere a un aggiornamento di sistema, compreso il kernel versione 6.16. A seguire ho riavviato la macchina virtuale e quindi ho scaricato il PKGBUILD con:

git clone https://aur.archlinux.org/nvidia-390xx-utils.git

e l’ho compilato:

makepkg -s

La compilazione è terminata con successo. Ho quindi installato i pacchetti risultanti:

sudo pacman -U *.zst

che sono stati installati senza problemi. Speriamo davvero che questa volta non sarà necessaria una patch.

Rimuovere oggetti da PDF con Inkscape via terminale

Aldo Latino (aldolat@gmail.com) — Wed, 06 Aug 2025 09:26:12 +0200

Avete uno o mille PDF e in tutti ci sono uno o più livelli e oggetti che bisogna rimuovere. Una soluzione possibile è usare Inkscape, ma da terminale. In questo post racconto come, grazie a un piccolo script, siamo riusciti a portare a termine un'operazione che altrimenti avrebbe richiesto un sacco di tempo.

* * *

Ci è capitato in questi giorni di mandare in stampa presso un servizio specializzato online un PDF con alcuni appunti. Così com’era, però, il file non veniva accettato perché presentava uno sfondo giallo chiaro su tutte le pagine. O, per meglio dire, la stampa sarebbe costata di più. Poiché non posso pubblicare lo screenshot di una pagina reale, vi basti questa ricostruzione di fantasia che però rende l’idea di cosa avevamo davanti:

Figura 1. Un esempio di pagina con lo sfondo giallo chiaro da rimuovere.

Il PDF è composto da 358 pagine: come fare per rimuovere quello sfondo colorato, lasciando intatto tutto il resto?

La prima soluzione che mi è venuta in mente era di estrarre singolarmente le pagine dal PDF e darle in pasto a ImageMagick, dicendogli di applicare una correzione dei livelli di colore in modo da eliminare lo sfondo. Ma abbiamo scartato subito questa ipotesi perché il file risultante, composto interamente da immagini raster, sarebbe stato enorme.

Mi viene un’idea. Se i file sono vettoriali (cosa che ancora non sapevamo) e se lo sfondo giallo chiaro sta su un suo livello separato o, per meglio dire, è un oggetto separato da tutti gli altri, forse possiamo eliminarlo. Apriamo una pagina con Inkscape e scopriamo che i file sono effettivamente vettoriali e che lo sfondo è un oggetto separato, chiamato path1 (vedi fig. 2). Ma non solo: scopriamo anche che i quadretti (che avremmo desiderato pure togliere) stanno tutti assieme in un gruppo chiamato g27514, quindi un facile obiettivo per la rimozione di massa.

Figura 2. I due oggetti di pagina 62, indicati dalla freccia, contenenti lo sfondo e i quadretti. In Inkscape è attualmente aperto un file PDF composto da due pagine.

Questi nomi di oggetti, per ovvie ragioni, non vengono mantenuti se apriamo con Inkscape più pagine del PDF. Nella figura 2, ad esempio, abbiamo aperto con Inkscape due pagine, cioè la 62 e la 63: come si vede dall’immagine, lo sfondo della prima pagina (la 62) si chiama path1, così come il gruppo dei quadretti si chiama g27514, ma non così dalla seconda pagina (la 63, vedi fig. 3) in poi, perché questi nomi sono, nel nostro caso, anche degli ID che devono identificare univocamente un oggetto.

Figura 3. I due stessi oggetti ma di pagina 63, con nomi diversi rispetto alla pagina precedente.

Proviamo quindi a dividere il file PDF di 358 pagine in tanti file quante sono le sue pagine e a verificare se gli ID dello sfondo e del gruppo vengono sempre mantenuti: sì, vengono mantenuti! A qusto punto siamo pronti per mettere all’opera Inkscape, ma non per via grafica, che comporterebbe un sacco di tempo e un incredibile mal di testa, ma da terminale.

Estrazione delle pagine dal pdf

La prima operazione è, quindi, quella di suddividere l’intero PDF in 358 file, cioè un file per ogni pagina:

pdftk input.pdf burst

Rimozione degli oggetti

Mettiamo ora mano alla creazione di uno script Bash semplicissimo che processi tutti i PDF di una directory mediante Inkscape. Ci siamo dovuti spulciare il manuale di Inkscape (man inkscape) per capire quali comandi (che lui chiama actions) potevano fare al caso nostro. Quello che è venuto fuori è questo script:

 1#!/bin/bash
 2# Script per rimuovere oggetti da un PDF tramite ID.
 3
 4OBJECT_TO_REMOVE1=path1
 5OBJECT_TO_REMOVE2=g27514
 6
 7mkdir -p modified
 8
 9for pdf in *.pdf; do
10  echo "Processo: $pdf"
11
12  inkscape --actions="select-by-id:$OBJECT_TO_REMOVE1;
13  delete-selection;
14  select-by-id:$OBJECT_TO_REMOVE2;
15  delete-selection;
16  export-filename:modified/$pdf;
17  export-do" "$pdf" > /dev/null 2>&1
18
19  echo "Completato: modified/$pdf"
20done

Dopo aver definito gli ID dei due oggetti da rimuovere (righe 4 e 5), lo script, per ogni PDF che trova, esegue il comando inkscape con alcune azioni in sequenza:

seleziona il primo oggetto per ID;
elimina l’oggetto selezionato;
seleziona il secondo oggetto per ID;
elimina l’oggetto selezionato;
imposta il nome del file da esportare;
esegue l’esportazione.

Infine, abbiamo anche reindirizzato l’output su /dev/null per evitare di vedere un sacco di righe inutili al nostro scopo e, una volta salvato il file, stampa a video il messaggio di conclusione per quel singolo file.

Questo è il risultato di una pagina dopo l’esecuzione dello script:

Figura 4. Un esempio di pagina senza lo sfondo giallo né i quadretti.

Riunione finale delle pagine in un unico file

Per riunire, alla fine, tutti i PDF basta dare:

pdftk modified/*.pdf cat output pdf_finale.pdf

Con poche righe di Bash e gli strumenti giusti, abbiamo risolto un problema concreto in poco tempo: è stata necessaria un’ora per il mio vecchissimo PC per fare questo lavoro. Il terminale, ancora una volta, si dimostra uno strumento insostituibile per chi lavora con tanti file. E ancora, dopo vent’anni d’uso di Linux, riesco a meravigliarmi per quello che abbiamo a disposizione!

L'uno alternativo nel font EB Garamond

Aldo Latino (aldolat@gmail.com) — Sun, 29 Jun 2025 11:38:21 +0200

Come se ne sarà accorto chi ama la bellezza dei caratteri tipografici, il font principale di questo sito, è l’EB Garamond, il meraviglioso carattere frutto del lavoro fatto da Georg Duffner e poi ripreso da Octavio Pardo, basandosi sullo Specimen composto nel 1592 da Conrad Berner, genero di Christian Egenolff e suo successore presso la fonderia Egenolff-Berner, da cui quindi il nome «EB Garamond». Attualmente questo font è disponibile in due versioni: quella di Duffner e quella di Pardo. La prima è ancora in fase di lavorazione e per poterla usare va compilata, mentre la seconda è più completa (anche se mancano le dimensioni ottiche), presenta più stili ed è disponibile pronta all’uso. In questo sito sto usando la versione di Pardo, versione che però non è del tutto identica a quella di Duffner e presenta una differenza in particolare, cosa che è oggetto di questo post.

Quando si usano i numeri minuscoli (o ‘saltellanti’), spessissimo l’‘uno’ non appare nella sua forma cui tutti siamo abituati, ma è simile a una ‘i’ in maiuscoletto. Ecco un esempio:

Glifo	Descrizione
i	‘i’ in maiuscoletto
1	‘uno’ minuscolo classico
1	‘uno’ minuscolo alternativo
i11	tutti e tre i glifi in sequenza

Tabella 1. I tre glifi a raffronto.

Alcuni editori preferiscono che l’‘uno’ abbia la sua forma propria, ben distinguibile dalla ‘i’ in maiuscoletto: 1. Sia nella versione di Duffner che in quella di Pardo è presente il glifo nelle due versioni, ma mentre in quella del primo è possibile accedervi, in quella del secondo no. Per chi conosce un po’ di tecnicismi della creazione dei font, possiamo dire che manca una tabella di lookup per la sostituzione del glifo quando richiesto.

Vista questa lacuna, mi sono modificato il font, aggiungendo questa tabella di sostituzione per ogni stile usato in questo sito:

Figura 1. La tabella di lookup per il numero 1 oldstyle.

Ed ecco la differenza (ripeterò il numero uno più volte, perché è quello che fa vedere meglio la differenza tra i numeri tabulari e non):

Numeri proporzionali maiuscoli

011123456789

Numeri tabulari maiuscoli

011123456789

Numeri proporzionali minuscoli oldstyle

011123456789

Numeri tabulari minuscoli oldstyle

011123456789

Numeri proporzionali minuscoli con l’uno alternativo

011123456789

Numeri tabulari minuscoli con l’uno alternativo

011123456789

Spero davvero che Duffner riesca a completare il suo magnifico lavoro: sembra che abbia ripreso in mano il progetto nel 2023 in vista della versione 2, con una bella lista di cose da fare, delle quali per altro alcune già fatte. Questo è quanto scrive sul suo repo GitHub in risposta a chi gli aveva chiesto informazioni del rapporto tra il suo repository e quello di Pardo:

I want to reconcile both versions, mainly using Octavio’s splines but readding the complete feature set. On the way there I want to fix issues reported on Octavio’s as well as the ones reported here.

I’ve done some work on the glyphs already and a good amount of the features but I’m stuck with otf <> fontforge round-tripping. Somewhere in the process the splines were damaged…¹

Buon lavoro, Georg! Aspettiamo con ansia la versione 2. :–)

Georg Mayr-Duffner, Todo list for v2. ↩︎

Ripristino dei pacchetti a una data specifica con Arch

Aldo Latino (aldolat@gmail.com) — Sat, 14 Jun 2025 12:48:57 +0200

A lcuni giorni fa, stanco dopo una giornata impegnativa, ho lanciato un aggiornamento del sistema. Quando aggiorno, guardo sempre quali pacchetti saranno interessati, ma quella sera non l’ho fatto. Tra questi aggiornamenti c’era anche il kernel alla versione 6.15.1.arch1-2 che sapevo avrebbe dato errori col driver nvidia-390xx, come vi ho raccontato — per la versione precedente — in Downgrade del kernel in Arch e in Driver nVidia 390 su kernel 6.14 in Arch Linux. Il processo di aggiornamento, ovviamente, è andato male:

<snip>
:: Esecuzione degli hook di post-transazione...
( 1/14) Reloading system manager configuration...
( 2/14) Restarting marked services...
( 3/14) Reloading device manager configuration...
( 4/14) Arming ConditionNeedsUpdate...
( 5/14) Updating module dependencies...
( 6/14) Install DKMS modules
==> dkms install --no-depmod nvidia/390.157 -k 6.15.1-arch1-2

Error! Bad return status for module build on kernel: 6.15.1-arch1-2 (x86_64)
<snip>

Era la sera del 10 giugno e la stanchezza mi impediva proprio di analizzare la situazione. Subito mi è venuto in mente il consiglio che mi diede @Lone_Wolf sul forum di Arch, vale a dire di riportare i pacchetti a una certa data, così abbiamo la certezza che tutto torni a funzionare, come se non avessimo lanciato quell’aggiornamento. Non avevo mai provato questo comando di pacman prima di allora, per cui «Quale migliore situazione di questa?», pensai. E mi sono lanciato!

Modifica del repository

La prima cosa da fare è modificare il repository:¹

sudo nano /etc/pacman.d/mirrorlist

e commentare quelli attuali attivando questo:

Server=https://archive.archlinux.org/repos/ANNO/MESE/GIORNO/$repo/os/$arch

Al posto di ANNO, MESE e GIORNO inserire le date nel formato AAAA/MM/GG. Nel mio caso ho usato:

Server=https://archive.archlinux.org/repos/2025/06/08/$repo/os/$arch

Salvare e chiudere il file.

‘Aggiornamento’ del sistema

Adesso lanciare un ‘aggiornamento’ (si fa per dire!) del sistema con pacman:

sudo pacman -Syyuu

Il sistema riporterà la versione dei pacchetti installati a quella del giorno indicato prima.

Nel mio caso tutto è andato secondo le aspettative e al riavvio tutto era al proprio posto. Chiaramente era una situazione temporanea che mi consentiva l’uso del PC in attesa della creazione della patch per il driver nVidia 390. Patch che puntualmente è stata pubblicata, grazie ai manutentori del pacchetto su AUR. Dopo la pubblicazione bisogna riportare il file mirrorlist alla situazione originale oppure fare un bel refresh dei repository con reflector:

sudo reflector --verbose --country Italy,Germany --protocol https --age 6 --sort rate --latest 5 --save /etc/pacman.d/mirrorlist

Quello descritto è uno dei due metodi previsti. Nel wiki di Arch sono spiegati entrambi in dettaglio. ↩︎

Git squash e la contrazione di più commit

Aldo Latino (aldolat@gmail.com) — Sun, 11 May 2025 11:38:31 +0200

Oggi mi sono accorto che il lastBuildDate del mio feed RSS non veniva aggiornato ogni volta che ce n’era bisogno. Ho sistemato la cosa e, già che c’ero, ho messo mano ad alcune piccole migliorie sparse nel codice del file rss.xml. Siccome il sito è sotto controllo Git e avevo fatto diversi commit su più o meno lo stesso argomento, volevo semplicemente riunirli in modo da avere una storia più pulita. In questi casi, Git offre la possibilità di fare lo squash dei commit, cioè comprimerli in uno solo, così da mantenere appunto una cronologia più ordinata e leggibile. Questa pratica è particolarmente utile quando si lavora in gruppo o semplicemente perché si vogliono evitare più commit tutti incentrati su un unico aspetto. Contrariamente a quanto ci si potrebbe aspettare, però, non esiste un comando diretto git squash, ma l’operazione si esegue attraverso il comando interattivo git rebase -i. Non è complicato, ma è abbastanza tecnico da meritare qualche appunto pratico, che annoto qui sia per me sia per chi volesse provarci.

Nel mio repository avevo questi commit e volevo unificare gli ultimi 5, qui evidenziati in rosso in figura 1:

Figura 1. I commit da contrarre.

Da terminale ho eseguito:

$ git rebase -i HEAD~5

Git mi ha mostrato l’editor di testo con gli ultimi 5 commit, uno per riga, e all’inizio di ogni riga la parola pick, come si vede in figura 2:

Figura 2. L’editor con i commit da modificare. L’ordine è inverso rispetto al log tradizionale di Git o a come mostrato in figura 1.

A questo punto bisogna dire a Git quali commit comprimere. Basta lasciare pick sul primo commit in cima (il più vecchio tra i 5) e sostituire pick con squash o s sugli altri, come in figura 3:

Figura 3. I commit da comprimere, con s al posto di pick.

Salviamo e chiudiamo. Si aprirà una nuova schermata dell’editor con tutti i messaggi dei commit coinvolti, così da poterli mantenere, modificare o cancellare:

Figura 4. I messaggi originali dei commit.

Nel mio caso, ho scritto un messaggio breve riassuntivo come oggetto del commit e, sotto, un elenco dettagliato delle modifiche, come mostrato in figura 5:

Figura 5. Il messaggio finale del commit unificato. Una riga vuota separa l’oggetto del commit dal resto del messaggio.

Dopo aver salvato, Git ha eseguito il rebase. Se ora controlliamo la cronologia dei commit, vedremo che i 5 sono stati unificati:

Figura 6. I 5 commit ora risultano fusi in uno solo.

La stessa situazione da terminale:

$ git log
commit 175a196eb64d0af98957dc813b5072169c177e4f (HEAD -> master)
Author: Aldo Latino <email@tld.com>
Date:   Sun May 11 06:59:49 2025 +0200

    Corretta data lastBuildDate in feed RSS, migliorie varie

    - Fix lastBuildDate in feed RSS
    - Changed Date to PublishDate in RSS pubDate
    - Changed RSS content escaping, removed attribution
    - Removed trailing dashes in RSS source
    - Added leading dashes

commit 1f45056753e6bf8bb9f65b3bfbc96e9f17a75ef9
Author: Aldo Latino <email@tld.com>
Date:   Sun May 11 06:08:51 2025 +0200

    Aggiornato un link

commit 9a32ad1c8cc08dc1103410cc686b397de4416157 (origin/master, origin/HEAD)
Author: Aldo Latino <email@tld.com>
Date:   Sat May 10 18:12:34 2025 +0200

    Abilitato feed RSS solo in home
[...]

Lo squash dei commit è un ottimo modo per tenere ordinata la cronologia di un progetto. Dopo questa operazione, il repository risulta più leggibile e ordinato, specialmente quando si lavora in gruppo o si prepara una pull request. Un comando di Git che può tornare senza dubbio utile, anche se si lavora a un progetto del tutto personale.

Driver nVidia 390 su kernel 6.14 in Arch Linux

Aldo Latino (aldolat@gmail.com) — Fri, 09 May 2025 21:29:12 +0200

In questo post proseguo quanto scritto in quello precedente, dove — ricorderete — non riuscivo a far convivere i driver legacy per la mia vecchia scheda video nVidia GeForce 605 con il nuovo kernel 6.14.4-arch1-2 o meglio, cosa che ho scoperto dopo, gcc versione 15 non riusciva a compilare per il nuovo kernel. Ho monitorato costantemente sia il forum che la pagina dedicata su AUR e ho visto che @bufferunderrun ha pubblicato una patch da applicare al pacchetto nvidia-390-dkms. Ho applicato la patch al pacchetto, fatto gli aggiornamenti e tutto è filato liscio come l’olio. Vi spiego cosa ho fatto, così rimane traccia anche per me e magari può servire a qualcuno.

Quello che faremo è creare una patch aggiuntiva — oltre a quelle già presenti — per il pacchetto nvidia-390-dkms e applicarla, in attesa che questo venga fatto nel pacchetto presente in AUR.

Creazione e applicazione della patch

Creazione del file .patch

Da terminale scarichiamo il pacchetto da AUR senza installarlo:

paru -G nvidia-390xx-dkms

Spostiamoci nella directory appena creata:

cd nvidia-390xx-utils

Creiamo il file per la patch dedicata a gcc 15:

nano gcc-15.patch

Incolliamo questo contenuto, vale a dire la patch che risolve il problema:¹

diff --git a/kernel/Kbuild b/kernel/Kbuild
index 85aa267..baa6986 100644
--- a/kernel/Kbuild
+++ b/kernel/Kbuild
@@ -61,6 +61,7 @@ $(foreach _module, $(NV_KERNEL_MODULES), \
 # $(EXTRA_CFLAGS) to ccflags-y for compatibility.
 #

+EXTRA_CFLAGS += -std=gnu17
 EXTRA_CFLAGS += -I$(src)/common/inc
 EXTRA_CFLAGS += -I$(src)
 EXTRA_CFLAGS += -Wall -MD $(DEFINES) $(INCLUDES) -Wsign-compare -Wno-cast-qual -Wno-error
diff --git a/kernel/conftest.sh b/kernel/conftest.sh
index 4da7588..1106ea5 100755
--- a/kernel/conftest.sh
+++ b/kernel/conftest.sh
@@ -151,7 +151,7 @@ test_headers() {
 }

 build_cflags() {
-    BASE_CFLAGS="-O2 -D__KERNEL__ \
+    BASE_CFLAGS="-std=gnu17 -O2 -D__KERNEL__ \
 -DKBUILD_BASENAME=\"#conftest$$\" -DKBUILD_MODNAME=\"#conftest$$\" \
 -nostdinc -isystem $ISYSTEM \
 -Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-incompatible-pointer-types"

Salviamo e chiudiamo.

Modifica di PKGBUILD

Ora dobbiamo modificare il file PKGBUILD per far sì che questo, durante la compilazione, consideri la patch appena creata. Anziché dirvi cosa modificare a mano, creeremo un altro file .patch, così senza sforzo né errori lo modificheremo. Creiamo questo file:

nano PKGBUILD.patch

e incolliamo queste righe:

--- nvidia-390xx-utils/PKGBUILD	2025-05-09 21:57:08.271353078 +0200
+++ PKGBUILD	2025-05-09 18:23:07.990867041 +0200
@@ -31,7 +31,8 @@
         kernel-6.12.patch
         kernel-6.13.patch
         kernel-6.14.patch
-        kernel-4.16+-memory-encryption.patch)
+        kernel-4.16+-memory-encryption.patch
+        gcc-15.patch)
 b2sums=('8e24aea70b139185bd682b080d32aeda673e6e92b45a90e6f6e0d736674180400bc8bd1aa5c66b8d033fc9d5e0cfffed456a87298bd93a3afbbc30b8dc48c4e9'
         'c1da4ce5784e43385465913a95053a3e54f800aac6f1b49f33e2a77504d76da5e6db6ec7074fbe7ba5f52dcef9e1ebaa620942c33ff825a56caba5c9c8b0d1be'
         '67e32932eeddda8fef667d25c34faf7b3a02f01cf9c15a97e5613bd44a0e8dcf7396e25399a52701f55dd18054c689720f237bb07d5bd580394d8dc8c9d05534'
@@ -49,7 +50,8 @@
         'aaa0597ab9d33be3c6e020fab0d54890d32f32c5ce70571e2bc989a788dbe2317e826475966bc1026bf7f7ff6672bd9a2f7f8e48dcebd2f91d33d9181eee1208'
         '8e5502a6668bf3981d1e9cc6cdad428fcfdd221b51850b0fde74d631faa379d965b97a87e845eda2bc0e99a0aa9bf58642444bdea9f976cafcd12edf0e20f5db'
         '21b87918e9b9b0475ab4fb548be6daadd6921566fb03a3f96cffff5296f9fa1bccdabe7c4671aba2a1dc455248b7a96e5a088c48ab922305213bc714e4a39d6c'
-        'a8234f542c2324ad698443e3decf7b6eacf3cb420b7aded787f102a8d32b64c2a8d45ea58e37a5e3b6f2f060f0cccd63d3a182065f57c606006d0ff8c7f6bb05')
+        'a8234f542c2324ad698443e3decf7b6eacf3cb420b7aded787f102a8d32b64c2a8d45ea58e37a5e3b6f2f060f0cccd63d3a182065f57c606006d0ff8c7f6bb05'
+        '488c1381c371efaa18aa68424560d5a5145d25dea79ae44c30fa771bdd097b43125a7b6d553ac823a304d5a681ee5e958291a2334f4be8bba79754fdb5ff80a2')
 
 create_links() {
     # create soname links
@@ -105,6 +107,9 @@
     # From Joan Bruguera (https://gist.github.com/joanbm/d0cb8790ca610fbd2c2e43f30707ce18)
     patch -Np1 -i ../kernel-6.14.patch
 
+    # From bufferunderrun (https://aur.archlinux.org/packages/nvidia-390xx-dkms#comment-1022658)
+    patch -Np1 -i ../gcc-15.patch
+
     cd kernel
 
     sed -i "s/__VERSION_STRING/${pkgver}/" dkms.conf

Salviamo e chiudiamo. Ora applichiamo le modifiche al file PKGBUILD:²

patch PKGBUILD < PKGBUILD.patch

Compilazione e installazione del driver con la patch

Installiamo ora il driver contenente la patch per gcc:

makepkg -si

Il sistema ora compilerà il driver con tutte le patch presenti nel pacchetto, compresa gcc-15.patch che abbiamo creato poco fa.

Una volta che avrà finito — si spera — senza errori, procederemo a installare il nuovo kernel e gcc ultima versione. Se, come avevo fatto io, avevate bloccato gli aggiornamenti del kernel e di gcc, sbloccateli. Quindi aggiorniamo il sistema:

sudo pacman -Syu

Non dovremmo vedere alcun problema segnalato nei messaggi del terminale. A questo punto possiamo riavviare e goderci gli aggiornamenti appena installati.

Ringrazio infinitamente tutti coloro che hanno contribuito a questa risoluzione e che mi consentono di continuare ad usare questa vecchia macchina con Arch Linux.

Come detto, la patch è ripresa interamente da questo commento di bufferunderrun. ↩︎
Una volta applicata la patch, possiamo anche eliminare il file PKGBUILD.patch, perché non ci serve più. Ad ogni modo questo file non sarà considerato da PKGBUILD stesso durante la compilazione perché non è presente nella lista delle patch da applicare a gcc. ↩︎

Downgrade del kernel in Arch

Aldo Latino (aldolat@gmail.com) — Thu, 01 May 2025 07:39:14 +0200

Nel mio ormai vetusto computer, che monta una più che obsoleta scheda nVidia, sono costretto a usare i vecchi driver versione 390 prelevati da AUR, come ho già avuto modo di scrivere.¹ Questo comporta che, se i driver non sono compatibili con una nuova versione del kernel, questi non verranno compilati correttamente e, al successivo riavvio, avrei un computer che molto probabilmente non partirà.

Nell’ultima sessione di aggiornamento della mia Arch ho riscontrato nuovamente questo problema. Dopo aver dato il solito:

sudo pacman -Syu

questo l’output, dove ho tolto un po’ di righe che non ci interessano:

:: Sincronizzazione dei database in corso...
 core    117,0 KiB   355 KiB/s 00:00 [##################] 100%
 extra     7,8 MiB  6,26 MiB/s 00:01 [##################] 100%
:: Aggiornamento del sistema in corso...
risoluzione delle dipendenze in corso...
ricerca dei pacchetti in conflitto in corso...

Pacchetti (94) [...]

Dimensione totale dei pacchetti da scaricare:   1018,12 MiB
Dimensione totale dei pacchetti da installare:  3481,25 MiB
Dimensione netta dell'aggiornamento:              10,62 MiB

:: Vuoi procedere con l'installazione? [S/n]
:: Download dei pacchetti in corso...
[...]
(11/21) Install DKMS modules
==> dkms install --no-depmod nvidia/390.157 -k 6.14.4-arch1-2

Error! Bad return status for module build on kernel: 6.14.4-arch1-2 (x86_64)
Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information.
==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.14.4-arch1-2' exited 10
(12/21) Restarting cronie for libc upgrade...
(13/21) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img
==> Starting build: '6.14.4-arch1-2'
  -> Running build hook: [base]
  [...]
  -> Running build hook: [fsck]
==> ERROR: module not found: 'nvidia'
==> ERROR: module not found: 'nvidia_modeset'
==> ERROR: module not found: 'nvidia_uvm'
==> ERROR: module not found: 'nvidia_drm'
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.14.4-arch1-2'
  -> Running build hook: [base]
  [...]
  -> Running build hook: [fsck]
==> ERROR: module not found: 'nvidia'
==> ERROR: module not found: 'nvidia_modeset'
==> ERROR: module not found: 'nvidia_uvm'
==> ERROR: module not found: 'nvidia_drm'
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
==> WARNING: errors were encountered during the build. The image may not be complete.
errore: l'esecuzione del comando non è riuscita correttamente
[...]

Il driver non è compatibile col nuovo kernel e serve un’altra patch.² Vado su AUR e trovo (ovviamente!) un commento di un altro utente: non essendoci ancora la patch disponibile, l’unico modo per risolvere temporaneamente è disinstallare la versione nuova del kernel o, per meglio dire con termine tecnico, “downgradare” il kernel, tornando quindi alla versione che stiamo usando in questo momento, visto che non abbiamo ancora riavviato.

I pacchetti da retrocedere di versione sono linux, linux-headers, gcc, gcc-libs, come indicato dall’utente su AUR.

Analisi della situazione

In base a quanto detto, vediamo quali sono i pacchetti e le versioni che abbiamo appena installato con l’aggiornamento e quali sono le versioni da ripristinare:

Pacchetti installati da retrocedere: linux-6.14.4.arch1-2; linux-headers-6.14.4.arch1-2; gcc-15.1.1+r7+gf36ec88aa85a-1; gcc-libs-15.1.1+r7+gf36ec88aa85a-1

Vediamo quali erano le versioni precedenti dei pacchetti guardando la cache di pacman. Cominciamo con linux:

$ ls -l /var/cache/pacman/pkg/linux-6.14.4.arch1-*
-rw-r--r-- 1 root root 145830356 26 apr 03.05 /var/cache/pacman/pkg/linux-6.14.4.arch1-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root       119 26 apr 03.06 /var/cache/pacman/pkg/linux-6.14.4.arch1-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 145998435 29 apr 12.05 /var/cache/pacman/pkg/linux-6.14.4.arch1-2-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root       215 29 apr 12.05 /var/cache/pacman/pkg/linux-6.14.4.arch1-2-x86_64.pkg.tar.zst.sig

Quindi il pacchetto è linux-6.14.4.arch1-1-x86_64.pkg.tar.zst.

Ora passiamo a linux-headers:

$ ls -l /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-*
-rw-r--r-- 1 root root 52859906 26 apr 03.05 /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      119 26 apr 03.06 /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 52895857 29 apr 12.06 /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-2-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      215 29 apr 12.06 /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-2-x86_64.pkg.tar.zst.sig

Qui il pacchetto è linux-headers-6.14.4.arch1-1-x86_64.pkg.tar.zst.

Ora gcc e gcc-libs:

$ ls -l /var/cache/pacman/pkg/gcc*
-rw-r--r-- 1 root root 56596007 29 apr 09.16 /var/cache/pacman/pkg/gcc-15.1.1+r7+gf36ec88aa85a-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      215 29 apr 09.16 /var/cache/pacman/pkg/gcc-15.1.1+r7+gf36ec88aa85a-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 37645039 29 apr 09.21 /var/cache/pacman/pkg/gcc-libs-15.1.1+r7+gf36ec88aa85a-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      215 29 apr 09.21 /var/cache/pacman/pkg/gcc-libs-15.1.1+r7+gf36ec88aa85a-1-x86_64.pkg.tar.zst.sig

Come si vede dall’output, per questi due pacchetti non ho in cache la versione precedente, per cui li prenderemo dall’archivio di Arch:

https://archive.archlinux.org/packages/

Basta entrare nelle rispettive directory g/gcc e g/gcc-libs: da lì prendere gli indirizzi dei due pacchetti.

Nel nostro caso questi sono i pacchetti da ripristinare per gcc e gcc-libs:

gcc-14.2.1+r753+g1cd744a6828f-1-x86_64
gcc-libs-14.2.1+r753+g1cd744a6828f-1-x86_64

Ricapitolando, questi sono gli indirizzi che daremo in pasto a pacman per l’installazione:

/var/cache/pacman/pkg/linux-6.14.4.arch1-1-x86_64.pkg.tar.zst
/var/cache/pacman/pkg/linux-headers-6.14.4.arch1-1-x86_64.pkg.tar.zst
https://archive.archlinux.org/packages/g/gcc/gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst
https://archive.archlinux.org/packages/g/gcc-libs/gcc-libs-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst

Due saranno quindi prelevati dalla cache di pacman e due dall’archivio di Arch.

Avvio del downgrade

Lanciamo (senza paura!) l’‘aggiornamento’ di tutti i pacchetti (che in realtà è una retrocessione) dando in un colpo solo:

sudo pacman -U \
  /var/cache/pacman/pkg/linux-6.14.4.arch1-1-x86_64.pkg.tar.zst \
  /var/cache/pacman/pkg/linux-headers-6.14.4.arch1-1-x86_64.pkg.tar.zst \
  https://archive.archlinux.org/packages/g/gcc/gcc-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst \
  https://archive.archlinux.org/packages/g/gcc-libs/gcc-libs-14.2.1+r753+g1cd744a6828f-1-x86_64.pkg.tar.zst

Adesso pacman eseguirà l’installazione di queste versioni sostituendo quelle più recenti. Lascio l’output completo del comando:

:: Download dei pacchetti in corso...
 gcc-14.2.1+r753+g1cd744a6828f-1-x86_64                 51,1 MiB  5,00 MiB/s 00:10 [################################################] 100%
 gcc-libs-14.2.1+r753+g1cd744a6828f-1-x86_64            35,0 MiB  4,28 MiB/s 00:08 [################################################] 100%
caricamento dei pacchetti in corso...
attenzione: installazione in corso di una versione meno recente del pacchetto linux (6.14.4.arch1-2 => 6.14.4.arch1-1)
attenzione: installazione in corso di una versione meno recente del pacchetto linux-headers (6.14.4.arch1-2 => 6.14.4.arch1-1)
attenzione: installazione in corso di una versione meno recente del pacchetto gcc (15.1.1+r7+gf36ec88aa85a-1 => 14.2.1+r753+g1cd744a6828f-1)
attenzione: installazione in corso di una versione meno recente del pacchetto gcc-libs (15.1.1+r7+gf36ec88aa85a-1 => 14.2.1+r753+g1cd744a6828f-1)
risoluzione delle dipendenze in corso...
ricerca dei pacchetti in conflitto in corso...

Pacchetti (4) gcc-14.2.1+r753+g1cd744a6828f-1  gcc-libs-14.2.1+r753+g1cd744a6828f-1  linux-6.14.4.arch1-1  linux-headers-6.14.4.arch1-1

Dimensione totale dei pacchetti da installare:  720,47 MiB
Dimensione netta dell'aggiornamento:            -10,92 MiB

:: Vuoi procedere con l'installazione? [S/n]
(4/4) verifica delle chiavi presenti nel portachiavi                               [################################################] 100%
(4/4) verifica dell'integrità dei pacchetti                                        [################################################] 100%
(4/4) caricamento dei file dei pacchetti                                           [################################################] 100%
(4/4) controllo dei conflitti in corso                                             [################################################] 100%
(4/4) controllo dello spazio disponibile sul disco                                 [################################################] 100%
:: Esecuzione degli hook di pre-transazione...
(1/2) Removing linux initcpios...
(2/2) Remove DKMS modules
:: Elaborazione delle modifiche al pacchetto...
(1/4) downgrade in corso gcc-libs                                                  [################################################] 100%
(2/4) downgrade in corso linux                                                     [################################################] 100%
(3/4) downgrade in corso linux-headers                                             [################################################] 100%
(4/4) downgrade in corso gcc                                                       [################################################] 100%
:: Esecuzione degli hook di post-transazione...
(1/5) Arming ConditionNeedsUpdate...
(2/5) Updating module dependencies...
(3/5) Install DKMS modules
==> dkms install --no-depmod nvidia/390.157 -k 6.14.4-arch1-1
==> depmod 6.14.4-arch1-1
(4/5) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img
==> Starting build: '6.14.4-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [resume]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: '6.14.4-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [resume]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
(5/5) Updating the info directory file...

Al riavvio il computer è tornato perfettamente funzionante. Chiaramente, se diamo un:

sudo pacman -Syu

pacman proporrà l’aggiornamento dei pacchetti appena retrocessi:

:: Sincronizzazione dei database in corso...
 core è aggiornato
 extra è aggiornato
:: Aggiornamento del sistema in corso...
risoluzione delle dipendenze in corso...
ricerca dei pacchetti in conflitto in corso...

Pacchetti (4) gcc-15.1.1+r7+gf36ec88aa85a-1  gcc-libs-15.1.1+r7+gf36ec88aa85a-1  linux-6.14.4.arch1-2  linux-headers-6.14.4.arch1-2

Dimensione totale dei pacchetti da installare:  731,38 MiB
Dimensione netta dell'aggiornamento:             10,92 MiB

:: Vuoi procedere con l'installazione? [S/n]

Al che risponderemo n perché dobbiamo attendere la patch. Un’alternativa è quella di bloccare l’aggiornamento di questi quattro pacchetti indicandolo nel file di configurazione di pacman,³ ma preferisco per ora non fare aggiornamenti in attesa della risoluzione del problema.

Come ho scritto in un altro post,¹ questo è l’unico problema che ho riscontrato in Arch da quando lo uso, vale a dire la gestione del vecchio driver nVidia. Certo, basterebbe cambiare la scheda con una più recente, ma ormai questo relitto informatico ha i suoi anni e ha troppi acciacchi oltre a questo. Non ne vale la pena.

Aggiornamento del 11/05/2025.

Il buon @Lone_Wolf sul forum di Arch mi ha consigliato che c’è un modo più sicuro per fare questa operazione:

That will break all applications that require gcc-libs 15.1 .

Use How to restore all packages to a specific date to pin everything on your system to the state they had just before the switch to gcc 15.

Sapevo che pacman può fare ciò anche se non l’ho mai provato, ma ho pensato che la soluzione del problema era alle porte: per tale motivo ho deciso di attendere la patch prima di fare altri aggiornamenti.

Ne ho parlato sia in Come mi trovo con Arch Linux dopo quasi 3 anni che in Driver nVidia 390 su kernel 6.0 in Arch Linux. ↩︎ ↩︎
Al momento della stesura del post, queste sono le patch incluse nel pacchetto nvidia-390xx-dkms: kernel-6.2.patch, kernel-6.3.patch, kernel-6.4.patch, kernel-6.5.patch, kernel-6.6.patch, kernel-6.8.patch, kernel-6.10.patch, kernel-6.12.patch, kernel-6.13.patch, kernel-6.14.patch ↩︎
Ne ho parlato in KRDC 24.01.80-1 ha qualche problema di connessione. ↩︎

Inserire note a piè di pagina fuori numerazione in LaTeX

Aldo Latino (aldolat@gmail.com) — Tue, 18 Mar 2025 19:16:22 +0100

Mi è capitato in questi giorni di dover inserire in un documento LaTeX una nota aggiuntiva ma fuori numerazione. La nota da inserire si trovava, tra l’altro, dopo alcune note a piè di pagina già presenti. Fare questa operazione è molto semplice.

Come si fa

Detta in poche parole, si tratta di inserire questa riga prima del blocco di testo dove mettere la nota fuori numerazione:

\renewcommand*{\thefootnote}{\fnsymbol{footnote}}

A seguire va inserito il blocco di testo con la nota fuori numerazione:

Duis tempor nulla non commodo maximus.\footnote[2]{Lorem ipsum
dolor sit amet, consectetur adipiscing elit. Maecenas
sollicitudin, turpis vitae venenatis tempor, magna metus
pulvinar justo, eu tempus purus leo a nisl. Aenean dictum
purus nec massa fringilla tincidunt. In vitae tincidunt ante.
Nunc eu augue leo. Ut elit dui, euismod ut semper et,
efficitur et risus. Phasellus finibus non elit a facilisis.}
Nunc nec mattis nulla...

E, subito dopo, va inserita un’altra riga che dice a LaTeX di riprendere la numerazione normalmente:

\renewcommand*{\thefootnote}{\arabic{footnote}}

Un esempio

Vediamo un esempio di un file minimo compilabile:

 1\documentclass[
 2  a4paper,
 3  11pt,
 4]{article}
 5
 6\usepackage[utf8]{inputenc}
 7\usepackage{fontenc}
 8
 9\author{Paolino Paperino}
10\title{Note fuori numerazione}
11
12\begin{document}
13
14\maketitle
15
16\section{Sezione 1}
17
18Nunc nec mattis nulla, quis efficitur est. Phasellus ut mollis
19nulla, molestie consequat est. Pellentesque nisl
20ex,\footnote{Nunc nec mattis nulla, quis efficitur est.
21Phasellus ut mollis nulla, molestie consequat est.} porttitor
22ac velit sed, vulputate hendrerit dui.\footnote{Molestie
23consequat est.} Pellentesque imperdiet dolor lectus. Mauris ac
24euismod nunc. Donec varius est lorem, at malesuada dolor
25facilisis eget.
26
27% Imposta la numerazione delle note con simboli.
28\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
29
30\section{Sezione 2}
31
32Duis tempor nulla non commodo maximus.\footnote[2]{Lorem ipsum
33dolor sit amet, consectetur adipiscing elit. Maecenas
34sollicitudin, turpis vitae venenatis tempor, magna metus
35pulvinar justo, eu tempus purus leo a nisl. Aenean dictum
36purus nec massa fringilla tincidunt. In vitae tincidunt ante.
37Nunc eu augue leo. Ut elit dui, euismod ut semper et,
38efficitur et risus. Phasellus finibus non elit a facilisis.}
39Nunc nec mattis nulla, quis efficitur est. Phasellus ut mollis
40nulla, molestie consequat est. Pellentesque nisl ex, porttitor
41ac velit sed, vulputate hendrerit dui. Pellentesque imperdiet
42dolor lectus. Mauris ac euismod nunc. Donec varius est lorem,
43at malesuada dolor facilisis eget.
44
45% Reimposta la numerazione standard delle note.
46\renewcommand*{\thefootnote}{\arabic{footnote}}
47
48\section{Sezione 3}
49
50Phasellus rhoncus viverra risus\footnote{Nunc nec mattis
51nulla, quis efficitur est. Phasellus ut mollis nulla, molestie
52consequat est.} non feugiat. Aliquam aliquam porttitor
53condimentum. Vivamus congue velit nunc,\footnote{Pellentesque
54imperdiet dolor lectus. Mauris ac euismod nunc. Donec varius
55est lorem, at malesuada dolor facilisis eget.} auctor
56pellentesque sem volutpat sed. Maecenas semper tincidunt enim,
57facilisis hendrerit nibh laoreet id. Aenean sit amet nisl ac
58neque auctor efficitur sit amet eget ex. Etiam lacinia maximus
59dictum.
60
61\end{document}

Questo l’aspetto della pagina dopo la compilazione:

La pagina compilata con la nota fuori numerazione.

Come si vede, la nota fuori numerazione si trova nella sezione 2, immersa tra altre note. Inoltre, ha il numero 2 specificato come opzione: con questo numero potete dire a LaTeX quale simbolo deve usare. Sono nove i simboli disponibili:

Codice	Simbolo
`1`	*
`2`	†
`3`	‡
`4`	§
`5`	¶
`6`	∥
`7`	**
`8`	††
`9`	‡‡

Tabella 1. La corrispondenza tra il codice interno di LaTeX e il simbolo prodotto.

Creazione di un comando personalizzato

Chiaramente è possibile rendere molto più semplice l’inserimento di queste note fuori numerazione creandosi un comando ad hoc. Il comando, che va inserito nel preambolo, può essere strutturato in questo modo:

% Crea una nota a piè di pagina fuori numerazione.
\newcommand{\nota}[2][8]{%
  \renewcommand*{\thefootnote}{\fnsymbol{footnote}}%
  \footnote[#1]{#2}%
  \renewcommand*{\thefootnote}{\arabic{footnote}}%
}

È possibile usare un altro nome per il comando al posto di \nota ed è anche possibile impostare un simbolo predefinito al posto di [8] (che equivale a ††).

L’uso è molto semplice e lo si può fare in due modi.

Senza specificare il simbolo

Duis tempor nulla non commodo maximus.\nota{Testo della nota.} Nunc nec mattis nulla...

Qui LaTeX userà come simbolo quello che abbiamo predefinito nel comando personalizzato, ossia nel nostro caso il n. 8, come da tabella 1. Come già detto, è possibile scegliere un altro simbolo predefinito al posto di [8].

Specificando quale simbolo usare

Duis tempor nulla non commodo maximus.\nota[4]{Testo della nota.} Nunc nec mattis nulla...

In questo caso bisogna specificare tra parentesi quadre il numero del simbolo. Nel nostro esempio abbiamo usato il n. 4, che equivale a §.

Monitorare i cambiamenti in una directory in Linux

Aldo Latino (aldolat@gmail.com) — Sat, 15 Mar 2025 07:54:00 +0100

Recentemente mi è capitato di dover tenere sotto controllo le modifiche fatte in una directory nella mia home. Per questo scopo mi sono servito di inotifywait presente nel pacchetto inotify-tools. Questo programma restituisce proprio le informazioni che mi servivano, ad esempio:

/path/to/dir/.git/objects/info/ CREATE commit-graph.lock
/path/to/dir/.git/objects/info/ MODIFY commit-graph.lock
/path/to/dir/.git/ DELETE gc.pid
/path/to/dir/.git/ CREATE index.lock
/path/to/dir/.git/ DELETE index.lock
/path/to/dir/.git/refs/remotes/origin/ CREATE master.lock
/path/to/dir/.git/refs/remotes/origin/ MODIFY master.lock
/path/to/dir/.git/logs/refs/remotes/origin/ MODIFY master

La directory sotto controllo era /path/to/dir/, comprese le sue sotto directory, e — com’è evidente — su ogni riga il programma mostra in sequenza:

la directory dov’è avvenuta la modifica;
l’azione eseguita;
il file interessato.

Installazione

Installiamo anzitutto il pacchetto inotify-tools:

sudo pacman -Syu inotify-tools

Esecuzione

Eseguiamo inotifywait:

inotifywait -m -r -e modify,create,delete /percorso/alla/directory

Le opzioni fornite significano:

-m (o anche --monitor): Rimane in ascolto delle modifiche;
-r (o anche --recursive): Controlla anche le sotto directory;
-e (o anche --event): Controlla quali eventi deve monitorare. Se non specificato, controlla tutti gli eventi.

Nel manuale di inotifywait possiamo vedere quali siano gli eventi disponibili per il monitoraggio:

Evento	Descrizione
`access`	file or directory contents were read
`attrib`	file or directory attributes changed
`close`	file or directory closed, regardless of read/write mode
`close_nowrite`	file or directory closed, after being opened in read-only mode
`close_write`	file or directory closed, after being opened in writable mode
`create`	file or directory created within watched directory
`delete`	file or directory deleted within watched directory
`delete_self`	file or directory was deleted
`modify`	file or directory contents were written
`move`	file or directory moved to or from watched directory
`moved_from`	file or directory moved from watched directory
`moved_to`	file or directory moved to watched directory
`move_self`	A watched file or directory was moved.
`open`	file or directory opened
`unmount`	file system containing file or directory unmounted

Tabella 1. Gli eventi disponibili in inotifywait per il monitoraggio.