Nell'aggiornamento di ieri sera mi si è installato e attivato dunst completamente a caso. WTF?

Edit: potrebbe essere stato portato dentro da qualche altro pacchetto preso da AUR tipo timeshift, però mi sembra strano ho controllato le dipendenze...

Potrei avere una chicca potente per i possessori di ArchLinux

Edit: per tutti i possessori Linux che hanno installato un certo pacchetto gendesk

Provate ad aprire il file
/usr/share/pixmaps/default.png

Attendo risposte

Nel frattempo...

Credo di avere troppi symlink sparsi non più funzionanti, mi sa che dovrò farmi uno noscript per passare ogni singolo file cercando per IntxLNK e ricrearli tutti

Also

Per cambiare target velocemente con SystemD da sistema avviato, sono disponibili i comandi

systemctl poweroff
systemctl emergency
systemctl rescue
systemctl default
systemctl reboot

Ecco, meglio fare logout a mano dal proprio account prima di andare in un'altra modalità - non volete che il vostro DE e le varie app non salvino correttamente i loro stati

EXCUSE ME?

Quindi volendo posso fare l'avvio di un'altra partizione senza riavviare?

Ok initial ram disks, però forse funziona anche con sistemi già avviati

Ebbene

> nell'ultimo aggiornamento di KDE noto che hanno migliorato il selettore delle icone
> noto una nuova categoria "Altro"
> vedo l'icona di rainbow dash, chiamata "default" per giunta
> wtf.exe

> cerco di scoprire l'origine di quell'icona, da dove inizio?
> innanzitutto mi serve il percorso del file, e purtroppo l'unico modo per ottenerlo è ...assegnare l'icona

> ok ho il percorso, e ora?
> suppongo a priori che l'icona appartenga a qualche pacchetto da AUR, e in questi non è possibile usare pkgfile / pacman -F
> cerco nel log di pacman per vedere cos'ho installato in data di modifica del file
> vedo solo un aggiornamento di sistema
> how.png
> interrompo le ricerche

> fast-forward a ieri
> parlando con un amico, collego che se l'icona è presente significa che il suo pacchetto sarà quasi sicuramente installato

$ pacman -Qo /usr/share/pixmaps/default.png
/usr/share/pixmaps/default.png è contenuto in gendesk 1.0.8-1

> ho il nome del pacchetto, vediamo da dove proviene

$ pacman -Ss gendesk
community/gendesk 1.0.8-1 [installato]
    Utility for generating desktop files

> ah ... quindi mi stai dicendo che ... l'icona di rainbow dash proviene da un pacchetto in community...

> https://github.com/xyproto/gendesk/blob/83d82f5c35fe83aaa3c6eb3f36b5e469acffe65d/release.sh#L7
> https://roboticoverlords.org/images/default.png


Conclusione: chiunque abbia installato il pacchetto gendesk (è molto probabile che lo si abbia per preparare pacchetti da AUR), si ritroverà nella root un'icona di rainbow dash default.png 50x50.

Update: alla fine il pacchetto dunst l'avevo installato io a mano mesi fa per utilizzare il comando dunstify, che permette di inviare notifiche desktop interattive da terminale (necessario per un mio progetto chiamato HTTP Hook).

Il dubbio che rimane è come il suo servizio si sia attivato da solo.

Altro problema nel passare a ntfs3:
questo driver - al contrario degli altri - riesce effettivamente a mappare i permessi di singoli files e cartelle, quindi potrebbe succedervi che pur impostando owner:group giusti dalle opzioni di mount vi capitino dei Permissions denied.

Per risolvere basta assegnare i permessi giusti con chmod 👍🏻
[e poi fare refresh se state usando Dolphin]
(consiglio chmod u=rwx,g=rx,o=rx ...)

In teoria è possibile aggirare il problema impostando varie opzioni kernel sulla sicurezza (fs.protected_...); non cambiatele, altrimenti aprireste varie brecce di sicurezza nel sistema.


Automatico, ricorsivo - da eseguire nella cartella montata:
sudo find ! -perm 755 -exec chmod -v u=rwx,g=rx,o=rx '{}' \;

Update: a quanto pare da un decennio a questa parte il driver ntfs originario non è mai utilizzato, viene utilizzato un symlink per utilizzare sempre il driver ntfs-3g e questo mi ha confuso le idee.

$ file /sbin/mount.ntfs
/sbin/mount.ntfs: symbolic link to /usr/bin/ntfs-3g

https://serverfault.com/a/304356

Sto fixando tutti i symlink con questo piccolo noscript che ho fatto. Accetta un argomento opzionale di root iniziale.

No warranties

Mi sono appena reso conto che la creazione di symlinks da Dolphin è eseguita sempre con percorsi assoluti, il che mi fa incazzare non poco - dato che di tanto in tanto sposto le cartelle...

Da qualche mese ormai, ho notato che tutto a un tratto i file HTML sono associati ad un MIME type diverso: prima era text/html, ora è application/x-extension-html.

Il problema di ciò è che tutti i software hanno un'associazione default a text/.. e non ad application/..
...quindi di default mi chiede sempre con quale app aprire questi HTML, dato che non esiste alcuna associazione.

Sono abbastanza sicuro che qualche mantainer abbia rotto il MIME type; solo che non riesco a trovare quali files di sistema/locali possano c'entrare con il problema; ho già cercato con

grep -ri 'x-extension-html' /usr/share/mime

ma non trova nulla...

Inoltre, dalle impostazioni di KDE non posso eliminare quel mimetype 😩

Ho un punto di partenza

> esiste un tool cli (xdg-mime) che permette di controllare quale mimetype è associato ad un dato file

$ xdg-mime query filetype dummy.html
application/x-extension-html

> controllo il tipo di file del tool

$ file "$(which xdg-mime)"
/usr/bin/xdg-mime: POSIX shell noscript, ASCII text executable

> oh no è uno noscript gigante

> apro con KWrite
> faccio folding automatico di tutte le funzioni
> ok a quanto pare questo noscript non è altro che un wrapper gigante per ogni DE
> XDG_UTILS_DEBUG_LEVEL hmm

$ export XDG_UTILS_DEBUG_LEVEL=10
$ xdg-mime query filetype dummy.html
Running kmimetypefinder5 "/.../dummy.html"
application/x-extension-html

> kmimetypefinder5 hmm

$ kmimetypefinder5 dummy.html
application/x-extension-html
$ kmimetypefinder5 -c dummy.html
text/html

> interessante, solo leggendone il contenuto restituisce il mimetype corretto

> controllo il tipo di file di quest'altro tool
$ file "$(which kmimetypefinder5)"
/usr/bin/kmimetypefinder5: ELF 64-bit LSB pie executable [...]
> chissà quali files leggerà
> magari i percorsi sono hard-coded?

$ strings "$(which kmimetypefinder5)" | less

> no
> tracciamo i files aperti a runtime

$ strace -f -t -e trace=file kmimetypefinder5 dummy.html
[...]
00:33:17 statx(AT_FDCWD, "/home/micro/.local/share/mime", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0755, stx_size=330, ...}) = 0
[...]

> come? esiste una cartella mime anche per l'utente? tra tutte le ricerche che ho fatto non ne ho mai sentito parlare

$ grep -ri 'x-extension-html' .local/share/mime
.local/share/mime/packages/user-extension-html.xml:
<mime-type type="application/x-extension-html">

.local/share/mime/application/x-extension-html.xml:
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/x-extension-html">

.local/share/mime/globs:
application/x-extension-html:*.html

.local/share/mime/globs2:
50:application/x-extension-html:*.html

.local/share/mime/types:
application/x-extension-html

grep: .local/share/mime/mime.cache: il file binario corrisponde

> beccati?

$ xdg-mime uninstall --mode user .local/share/mime/packages/user-extension-html.xml
$ grep -ri 'x-extension-html' .local/share/mime

> Ø

I FUCKING DID IT