Re: Teclat catala i accents volats
2024-04-26, 14:45 (+0200); Xavier De Yzaguirre i Maura escriu: > Doncs sí, a la consola (CTRL+ALT+F2, ja que l'F1 l'ocupa la sessió gràfica) > puc escriure les vocals amb accent obert, tancat i dièresi. > > Per tant, és un problema de l'entorn gràfic. Per tant, com dius és un > problema del mètode d'entrada. Que m'aconselles? Em sembla que només hi ha dues alternatives pel que fa a mètodes d'entrada: ibus i xim. Ibus és el configurat per defecte. Si vols utilitzar xim, en entorns GTK, hauries de definir aquesta variable d'entorn GTK_IM_MODULE=xim (en el fitxer /etc/environment per exemple) Salutacions.
Re: Teclat catala i accents volats
2024-04-23, 13:11 (+0200); Xavier De Yzaguirre i Maura escriu: > Doncs, Ernest i companyia, es molt curios, t'ensenyo el que em surt: > > [...] > > Al pas 5 identifica correctament la a amb accent greu i al pas sis em dona > pel sac. > > No se, estic perdut. No, no, és correcte. A mi em diu exactament el mateix, i escriu els caràcters correctament. Em fa pensar que el problema potser és del mètode d'entrada. A la consola Linux (Ctrl+Alt+F?) pots escriure accents? Salutacions.
Re: Teclat catala i accents volats
2024-04-10, 13:49 (+0200); Xavier De Yzaguirre i Maura escriu: > Fa uns dies que no trobo els accents, he reconfigurat els locales, pero no > hi ha forma de poder escriure una vocal accentuada. > > Utilitzo un portatil msi configurat amb el teclat generic de 86 tecles Pots mirar la sortida de xev -event keyboard Et diu el codi de la tecla i el caràcter associat. Si premo la tecla de l'accent obert, i després la tecla "a" em diu KeyPress event, serial 28, synthetic NO, window 0x4e1, root 0x6b5, subw 0x0, time 1388160400, (89,38), root:(640,473), state 0x10, keycode 34 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 28, synthetic NO, window 0x4e1, root 0x6b5, subw 0x0, time 1388160472, (89,38), root:(640,473), state 0x10, keycode 34 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x4e1, root 0x6b5, subw 0x0, time 1388162432, (89,38), root:(640,473), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XmbLookupString gives 1 bytes: (61) "a" XFilterEvent returns: True KeyPress event, serial 28, synthetic NO, window 0x4e1, root 0x6b5, subw 0x0, time 1388162432, (89,38), root:(640,473), state 0x10, keycode 0 (keysym 0xe0, agrave), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 2 bytes: (c3 a0) "à" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x4e1, root 0x6b5, subw 0x0, time 1388162472, (89,38), root:(640,473), state 0x10, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False Sembla que surtin repetits però no, un bloc és "KeyPress" quan prems la tecla, i l'altre "KeyRelease" quan deixes de prémer. Em diu que tecla de l'accent obert genera el símbol "dead_grave" i la tecla "a" genera el símbol "a", i els dos símbols combinats generen el símbol "agrave". Salutacions.
Re: Carpeta /lib/modules/
2024-03- 9, 12:28 (+0100); Xavier De Yzaguirre i Maura escriu: > Per tant, crec que amb conservar les carpetes corresponents a les versions > 6.0.1-17 i 6.0.1-18 n'hauria de tenir prou, oi? > > El que em porta a la qüestió, > > Em puc desempallegar dels fitxers corresponents a imatges que no tinc > instal·lades? Pots utilitzar dpkg --search per veure a quin paquet pertany un determinat fitxer ernest@doriath:~$ dpkg --search /lib/modules/4.19.0-8-amd64 linux-image-4.19.0-8-amd64: /lib/modules/4.19.0-8-amd64 i després dpkg -l per veure l'estat del paquet ernest@doriath:~$ dpkg -l linux-image-4.19.0-8-amd64 Desitjat=desconegUt/Instal·la/elimina(R)/Purga/retín(H) | Estat=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Estat,Err: majúsc.=dolent) ||/ NomVersióArquitectura Descripció +++-==-=--=> rc linux-image-4.19.0-8-amd64 4.19.98-1+deb10u1 amd64Linux 4.19 for 64> e 'rc' indica que el paquet s'ha desinstal·lat, però que els fitxers de configuració s'han conservat. Suposo que aquest directori es considera un fitxer de configuració, per això segueix existint al sistema de fitxers. Per eliminar-lo, la manera de fer-ho és purgant el paquet doriath:/home/ernest# apt-get purge linux-image-4.19.0-8-amd64 > I mes genèricament, com feu neteja d'andròmines, carpetes i fitxers vells > que no serveixen ja i que ocupen un espai que ens es útil per altres > menesters? En general, no et recomano eliminar cap fitxer del sistema directament, sinó fer-ho a través del sistema de gestió de paquets. Salutacions.
Re: Filtrar comodins/regex de les línies
2024-01-17, 08:39 (+0100); Narcis Garcia escriu: > Bones, > > Tinc un fitxer de text, com podria ser per exemple una llista de números de > telèfon (coneguts.txt): > 972123456 > 97233 > 97234 > 97235 > 97236 > 972789012 > però m'agradaria representar-hi rangs compatibles (expressions regulars) per > abreviar: > 972123456 > 972.. > 972789012 Hi ha una cosa que no entenc. El patró "972.." representa els números 97200, 97201, 97202, ..., 97298, 97299. Mentre que a la teva llista només hi tens el 97233, 97234, 97235, i el 97236. Si substitueixes aquests números pel patró "972.." el resultat és un conjunt de números que és DIFERENT de l'original. Salutacions
Re: tecles mortes en aplicacions GTK
Hola, 2024-01- 5, 15:23 (+); Carles Pina i Estany escriu: > Ho haig de provar (ho he provat via /etc/environment.d/90carles.conf > però no m'ha canviat, faig echo $GTK_IM_MODULE a una consola gràfica i > encara em surt ibus) Jo poso tot les variables d'entorn en el fitxer ~/.environment, i les llegeixo des de ~/.xsessionrc i desde ~/.profile, d'aquesta manera s'estableix l'entorn tant en sessions X, com en sessions de terminal. > Per altre banda, per aquí [1] (ni idea de qui escriu, ni si és correcte) > diu: > > Now what about XIM? XIM is a pretty obsolete input method protocol which > both ibus and fcitx implement for legacy support reasons only. There is > no real reason why you would want to use XIM nowadays over any of those > two > El mètode d'entrada ibus és on han implementat la previsualització de les tecles mortes. Els desenvolupadors han dit que no tenen previst afegir una opció per desactivar la funcionalitat. Per tant, només queda l'opció de xim, per molt obsolet que sigui. (No sé si el mètode fcitx podria ser una alternativa, aparentment és per llengües asiàtiques.) He estat utilitzant el mètode xim durant una setmana i l'única cosa estranya és que Alt Gr + ñ genera un caràcter ~ mort. Per exemple Alt Gr + ñ seguit de "e" genera el caràcter ẽ. Si vols el caràcter ~ has de teclejar Alt Gr + ñ i espai. En canvi Alt Gr + 4 funciona correctament. Salutacions
tecles mortes en aplicacions GTK
Hola, Des de l'actualització a Bookworm, les tecles mortes (accents i dièresi) generen una previsualització, que posteriorment desapareix quan la tecla morta es combina amb el caràcter següent. En algunes pàgines web, com Reddit, crea problemes. Si preferiu tornar al comportament anterior, es pot aconseguir establint la següent variable d'entorn GTK_IM_MODULE=xim (Cal re-iniciar la sessió de l'usuari després de modificar l'entorn.) Salutacions
Re: llenguatge de l'IU del Firefox
2023-12-25, 11:27 (+0100); Manuel Fauvell escriu: > A mí m'ha passat alguna vegada una cosa pareguda. Normalment es perquè > el locals no s'ha generat correctament. > > Per provar que costa poc: > > dpkg-reconfigure locales > > I a vore que passe. Gràcies a tots per les idees... s'ha solucionat, però no estic segur com. Sembla que ha sigut sortint de la sessió i tornant a entrar. Salutacions
llenguatge de l'IU del Firefox
Hola, Acabo d'instal·lar el paquet firefox-esr-l10n-ca, però la interfície d'usuari em segueix apareixent en anglès. A les preferències no surt l'opció català. El local del meu usuari és el ca_ES. Alguna suggerència? Salutacions
Re: wine virtualbox ...
2023-11- 3, 08:08 (+0100); Narcis Garcia escriu: > Ei Marc, has escrit amb un xifrat (suposo que per a la clau d'en Jordi), > però amb còpia a la llista. Et refereixes a aquest bloc? > > -BEGIN PGP PRIVATE KEY BLOCK- > > Version: GnuPG v2 > > > > lQPGBFh3b4wBCADcg72dc5yZ09XfZbMbDI/bkssf4We5Zb1y6gagJ6wx/hQxp5yI Sembla que no és un text xifrat, sinó més aviat una clau privada. Salutacions
enregistrament d'àudio amb el xip Realtek ALC1220
Hola, Fa més de 3 anys que estic intentant enregistrar àudio amb el xip de so integrat Realtek ALC1220 i encara no ho he aconseguit. Concretament és el xip que porta la placa mare X470 Taichi d'Asrock. Algú està familiaritzat amb aquest maquinari i ha aconseguit enregistrar so? He provat de tot, però només aconsegueixo enregistrar silenci o soroll estàtic. Un cop vaig enregistrar la sortida. Però l'entrada mai. Salutacions
Re: mail --> mutt
2023-07- 8, 07:20 (+0200); Xavier Drudis Ferran escriu: > El Fri, Jul 07, 2023 at 01:39:30PM +0000, Ernest Adrogué deia: > > 2023-07- 7, 09:59 (+0200); Narcis Garcia escriu: > > > Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»: > > > MUA (Mutt) -> MTA local -> MTA públic > > > > > > Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a > > > Internet com a fiable per als filtres anti-brossa. > > > > En aquest cas ho trobo una complicació innecessària. > > > > L'MUA es pot connectar directament a l'MTA públic, sense necessitat de > > passar per l'MTA local, que no aporta res, o pràcticament res. > > > > Si ho tens clar ja ho tens clar. > > Però un MTA local pot aportar cues (esperar a poder enviar) i > lliurament a adreces locals que no existeixen al MTA públic. > > Segur que li pòts buscar més coses, però aquestes són les principals > que em passen pel cap. Crec que l'Alex ja anava per aquí. En el meu missatge recomano utilitzar un MTA local per permetre l'enviament de correu a adreces locals. Per tant, no estic recomanant no utilizar MTAs locals, en general. Només recomano no utilitzar-los per enviar correu a adreces externes (a no ser que siguis una organització que tingui la infrastructura necessària). El fet que l'MTA tingui una cua interna de missatges (a diferència d'un MUA), no veig que sigui gaire rellevant, ja que l'únic que fa l'MTA local és connectar-se a l'MTA extern (és l'escenari que estavem discutint). En aquest escenari, qui gestiona la cua de missatges és l'MTA extern. Per altra banda, quin MTA extern penseu utilitzar? No hi ha gaires alternatives. Gmail? Penseu que és bona idea forçar tot el correu que s'origina localment a través de l'MTA de Gmail? Jo crec que no, jo crec que és una idea terrible. La decisió de quin MTA extern utilitzar és millor deixar-la en mans de l'usuari. Un altre problema, si no recordo malament, és que alguns MUAs afegeixen una advertència quan l'adreça que s'autentica a l'MTA extern no coincideix amb l'adreça del destinatari. El destinatari veu dos remitents, i un text que diu que el missatge l'envia un remitent per compte de l'altre. Pot generar confusió, i a més revela informació que potser és millor no revelar. > Si això no et convé, o no et compensa, no tens perquè tenir MTA local, > com menys coses millor, només és una idea que t'han donat. Exacte, només és una idea, i com qualsevol idea té arguments a favor i arguments en contra, i això és el que estem debatent. Salutacions.
Re: mail --> mutt
2023-07- 7, 09:59 (+0200); Narcis Garcia escriu: > Em sembla que l'Alex es referia a aquest recorregut per a «smarthost»: > MUA (Mutt) -> MTA local -> MTA públic > > Amb això, el servidor públic de correu-e és el què ha d'acreditar-se a > Internet com a fiable per als filtres anti-brossa. En aquest cas ho trobo una complicació innecessària. L'MUA es pot connectar directament a l'MTA públic, sense necessitat de passar per l'MTA local, que no aporta res, o pràcticament res. Salutacions.
Re: mail --> mutt
2023-07- 5, 21:51 (+0200); Alex Muntada escriu: > Hola, Ernest: > > > No és recomanable utilitzar postfix per enviar correu a > > internet. El més pràctic és utilitzar el postfix (o un altre > > MTA) per enviar correu localment al mateix ordinador, i si els > > usuaris volen enviar correu a internet que utilitzin un client > > de correu (com el mutt) que permeti enviar correu a través d'un > > servidor de correu remot (com Gmail). > > M'havia quedant pendent de respondre aquest tema: això depèn de > les necessitats particulars. En concret, és molt habitual tenir > un MTA configurat amb un smarthost per processar tot el correu > que no és local, sobretot als servidors. > > Per exemple, si enlloc de deixar en local els missatges que > t'envia el cron, els vols rebre a una altra bústia remota, el > MTA local ho pot fer perfectament via smarthost. > > Tenir un MTA local, a més a més, pot ser útil per encuar els > missatges de sortida quan no tens connexió a internet. Potser > alguns MUA ho reintentaran, però d'altres no (per exemple, Mutt > ha començat a reintentar connexions des de fa poc) i el MTA local > fa de coixí. Tinc entès que les mesures anti-spam fan que aquest sistema no sigui viable a la pràctica. Per exemple: l'MTA local pot enviar correu sense problemes quan el domini de l'adreça del remitent no coincideix amb el domini de l'MTA, o en aquests casos l'MTA del destinatari tendeix a rebutjar el correu? Salutacions.
Re: mail --> mutt
2023-06-15, 10:29 (+0200); Jordi escriu: > Ja fa un temps vaig voler configurar postfix i alguna altra cosa i no > me'n vaig sortir, el que tinc ara son aplicacions que envien > notificacions o redirigeixo la sortida a mail o a mutt segons si vull > local o remotament. Vols dir que amb el mail envies correu a adreces locals i amb el mutt a adreces d'internet? > Amb això, segons les configuracions de les aplicacions si fico que > enviïn el correu per exemple a jomat...@correumeu.cat simplement no > envien res. > > Mai he aconseguit configurar correctament postfix perquè enviï el > correu al mateix ordinador, la mateixa xarxa o internet segons les > meves necessitats. Tampoc vull deixar un servidor de smtp accessible > des d'internet. No és recomanable utilitzar postfix per enviar correu a internet. El més pràctic és utilitzar el postfix (o un altre MTA) per enviar correu localment al mateix ordinador, i si els usuaris volen enviar correu a internet que utilitzin un client de correu (com el mutt) que permeti enviar correu a través d'un servidor de correu remot (com Gmail). Llavors, per llegir el correu jo el que tinc és un servidor IMAP local (dovecot) i d'aquesta manera puc utilitzar qualsevol client de correu que em vingui de gust. Les bústies locals estan sincronitzades amb les bústies remotes allotjades al meu proveïdor de correu mitjançant un programa que es diu offlineimap. D'aquesta manera està tot integrat. Tant el correu local com el d'internet va a parar a les mateixes bústies, i puc treballar indistintament amb les bústies locals com amb les remotes (per exemple, amb webmail) ja que totes tenen el mateix correu. Salutacions.
Re: mail --> mutt
2023-06-14, 11:02 (+0200); Jordi escriu: > Bon dia, ja sé que em donareu altres opcions però voldria redirigir > determinats correus locals a mutt de forma automàtica. > > És a dir correu llegit amb mail que compleixi determinades condicions, > redirigir-lo a mutt. Em podeu orientar ?? No em queda clar què vols aconseguir. mutt és un programa client de correu, que obté el correu de bústies locals, o d'un servidor. No és possible "redirigir el correu a mutt", perquè mutt no és una bústia. Salutacions.
Re: (deb-cat) Firefox ESR: out of memory
2022-11-17, 10:11 (+0100); Leopold Palomo-Avellaneda escriu: > $ apt-cache policy firefox-esr > firefox-esr: > Instal·lat: 102.4.0esr-1~deb11u1 > Candidat: 102.5.0esr-1~deb11u1 > Taula de versions: > 102.5.0esr-1~deb11u1 500 > 500 http://deb.debian.org/debian-security bullseye-security/main > amd64 Packages > *** 102.4.0esr-1~deb11u1 100 > 100 /var/lib/dpkg/status > 91.13.0esr-1~deb11u1 500 > 500 http://debrob.upc.edu/debian bullseye/main amd64 Packages > > Potser no està actualitzat el web Ah... la versió 102 és a debian-security. Per això no apareix en el llistat de paquets de la distribució estable. Salutacions
Re: (deb-cat) Firefox ESR: out of memory
2022-11-17, 09:32 (+0100); Àlex escriu: > És estrany, per que a la pàgina web de paquets Debian diu que encara estem > amb la versió 91 quan portem molt de temps amb la 102: > > https://packages.debian.org/search?keywords=firefox-esr=names=stable=all Sí, és estrany. No sé d'on heu tret la versió 102, al repositori estable només hi ha la 91. Salutacions
Re: Comportament de clear al konsole
2022-09-16, 09:51 (+0200); Narcis Garcia escriu: > > Ara veig que la última Debian a la què el desplaçament del TTY > > funcionava per defecte fou la versió 8 (jessie). > > He cercat una mica, i no trobo una manera assequible de carregar el > > mòdul de nucli fbcon que s'ocupa d'això. > > Ara veig que amb aquest paràmetre d'arrencada: nomodeset > aleshores hi ha desplaçament a TTY. El què no sé és si això afecta > negativament al mode gràfic per a escriptori, i si es pot millorar la > resolució de terminal. El paràmetre 'nomodeset' desactiva el KMS (kernel mode setting). Probablement et quedaràs sense acceleració gràfica. $ glxinfo |grep ^dir direct rendering: Yes Salutacions
Re: Comportament de clear al konsole
2022-09-15, 21:11 (+0200); Narcis Garcia escriu: > El 15/9/22 a les 21:05, Eloi ha escrit: > > A consola pura directament no puc retrocedir (em sonava que abans podia) > > És veritat, ara ho he provat amb Debian 11 (Stable) i no em retrocedeix. > Es feia mantenint la majúscula (shift) i pujant amb RetrocedirPàgina > (PageUp). La funció de scroll del tty de Linux la van eliminar fa segles. Els emuladors de terminals de X11 no fan servir el tty per res. No té cap relació un problema amb l'altre. Salutacions
Re: Com deshabilitar actualitzacions automàtiques
2022-07-20, 10:20 (+0200); Joan escriu: > No sé si és possible, però m'agrada saber si es poden deshabilitar les > actualitzacions automàtiques temporalment. No em refereixo a que no > s'executin, sinó sobretot a que no es descarreguin. Bàsicament per quan > estàs tirant de dades del mòbil per servir la wifi del portàtil. Has provat això? https://wiki.debian.org/UnattendedUpgrades Tingues en compte que és diferent segons si utilitzes cron o systemd. Salut
Re: Errors traduccions en català a Debian
Hola, 2022-06-28, 19:27 (+0100); Carles Pina i Estany escriu: [...] > El tema és que els llistats aquest son en anglès així que si teniu > paraules que heu vist malament a traduccions (com ara el meu "tamany") i > m'ho envieu ho miro. I si apareixen moltíssims errors ja demanaria ajuda > per enviar les correccions :-) Pots buscar un llistat de barbarismes, però en aquests llistats només trobaràs la forma canònica. Pensa que la morfologia de l'anglès és molt més simple que la del català. En català, la majoria d'adjectius tenen 4 formes, i els verbs més de 50. Cada cop que afegeixis una paraula al llistat hauries de generar totes les flexions possibles de la paraula (cosa gens trivial), si no corres el risc de no detectar l'errada. Per altra banda, aprofito per comentar que fa temps vaig fer unes simples modificaciones al meu Emacs, per afegir la funcionalitat de passar el corrector ortogràfic a les cadenes traduïdes dels fitxers PO. Si hi ha algú que utilitza el mode PO de l'Emacs i l'hi interessa, podeu trobar la configuració aquí: https://github.com/nfdisco/emacs.d#gettext-po-mode Salutacions
Re: (OT) subscripcions a la llista de correu (Era: Frenar bitacoles del sistema)
2022-04-11, 19:15 (+0200); Alex Muntada escriu: > > La suma de tots dos ens fa estar travats de forma poc raonable. > > Si et plau, no generalitzis un problema teu cap a la resta de > membres de la llista. +1
Re: (deb-cat) Hemeroteca de la llista al Google
2022-01-28, 10:38 (+0100); Narcis Garcia escriu: > Al peu dels missatges, i a les pàgines informatives de les llistes, s'hauria > d'advertir de a on es publiquen les cartes de forma automàtica. > Es dóna massa per suposat que tothom accepta les condicions d'ús i > emmagatzematge de les GAFAM. https://en.wikipedia.org/wiki/X-No-Archive FYI
Re: pregunta sobre el nucli Linux
2021-10- 3, 03:12 (+0200); Jordi Miguel escriu: > Si estàs pensant que el oom-killer hauria d'haver matat el Firefox, > segons el que ens expliquen probablement hauria d'haver passat, però > també és possible que no s'hagués exhaurit tota la memòria sinó que > s'ha quedat a prop del límit però sense arribar-hi i per tant no s'ha > arribat a cridar el oom-killer. En aquest escenari el Firefox > intentava funcionar amb la RAM+swap, lo qual és molt lent però es algo > que ha decidit l'usuari de la màquina. El problema és quan el sistema es queda sense memòria i comença a fer servir swap el funcionament es s'alenteix tant que el sistema queda inutilitzable, fins al punt que no és possible ni tan sols matar el procés manualment. Suposo que si t'esperes suficientment l'oom-killer l'acabaria matant, però jo mai he tingut tanta paciència. Personalment he optat per no tenir swap, per evitar aquestes situacions. Salutacions.
Re: Debian 11 estable en poques hores
2021-10- 2, 21:05 (+0200); Josep Lladonosa escriu: > i he descobert que, a més de les abreviacions de mes, n'indiquen símbols de > dues lletres: > > GN, FB, MÇ, AB, MG, JN, JL, AG, ST, OC, NV, DS > > i de llargada fixa! Potser es podrien usar aquestos? Es podrien usar símbols de 2 lletres. Personalment, crec que és millor utilitzar 3 caràcters, perquè el local per defecte "C" utilitza 3 caràcters (tant pels mesos, com pels dies). Si mantenim la mateixa llargada que el local "C", és menys probable que després els programes no funcionin com s'espera que funcionin i s'hagin d'adaptar, cosa que comporta un cost. Però estic d'acord que haurien de ser símbols, i no abreviacions. El document que enllaces defineix un símbol com "la representació convencional d’un concepte (una paraula, un sintagma o un valor), normalment mitjançant un element gràfic" i diu que "no porten mai punt abreviatiu". Per exemple - 1.000.000 d'eur. - 1.000.000 EUR el primer cas és una abreviació, i el segon un símbol. En un llistat de directori, i altres situacions similars, opino que és més convenient utilitzar símbols que abreviacions. Salutacions.
Re: Debian 11 estable en poques hores
2021-10- 2, 20:39 (+0200); Eduard Selma escriu: > + 1 altre a favor de les 3 lletres (GEN, FEB, MAR, ABR, MAI, JUN, JUL, AGO, > SET, OCT, NOV i DES). Com als datadors de goma. Tan difícil és? Difícil no és. L'únic que fa falta és la voluntat de fer-ho per part de les persones que s'encarreguen de mantenir el local. Però són les mateixes persones que van canviar les cadenes originals de tres lletres per la versió abreviada actual. Salutacions
Re: Debian 11 estable en poques hores
2021-10- 2, 15:47 (+0200); Aleix Vidal i Gaya escriu: > Fixa't en els parèntesis: "quan s'apliqui". Diria que la solució de > compromís encara no s'ha aplicat, per tant entenc que estàs valorant una > situació que no es correspon a la que deia en Joan. Estic valorant la solució proposada, independentment de si s'ha aplicat o no. Aquesta solució no soluciona el problema, perquè el problema també afecta a altres programes, com ja havia apuntat anteriorment, a banda de la utilitat 'ls'. La estratègia d'anar adaptant un a un tots els programes que puguin estar afectats no és realista, tenint en compte el que hem vist: que després de més de quatre anys arrossegant aquesta situació encara no n'hem aconseguit adaptar ni un. A més, sobre qui recaurà el cost de fer totes aquestes adaptacions? Salutacions.
Re: Debian 11 estable en poques hores
2021-09-14, 20:52 (+0200); Joan Montané escriu: > Què vull dir amb això? > Debian és molt més que el terminal. > Canviar les abreviatures dels mesos a «ls» afecta a tot el sistema. A quin altre lloc s'utilitzen els mesos de l'any en format abreviat? Algun programa d'interfície gràfica en concret? Jo no n'he trobat cap. Que jo sàpiga, aquest format només té sentit en programes de terminal de text, on l'espai és limitat. I en un context on hi ha una limitació d'espai, no és desitjable malgastar aquest espai amb preposicions i puntuació innecessària. Tres caràcters per identificar el mes de l'any és suficient i adequat, i evita els previsibles problemes de falta d'alineació. És el que fan tots els altres idiomes. Algun altre idioma utilitza abreviatures de mes de llargada variable? > L'opció triada és una solució de compromís que no és ideal, però és > millor (quan s'apliqui) que la situació dels darrers 4 anys. No és veritat que això sigui una solució de compromís. Compromís vol dir que les parts que estan en desacord renuncien a alguna de les seves pretensions. Mentre que, aquí, una part no ha renunciat a cap de les seves pretensions, i en canvi ha aplicat tot de canvis al local unilateralment, i l'altra part ha estat obligada a acceptar aquests canvis sense que se l'hagi tingut en compte. Salutacions.
Re: Debian 11 estable en poques hores
Hola, 2021-08-22, 11:34 (+0200); Joan Montané escriu: > 1.- bullseye soluciona el problema que tenia «ls» en l'ordre de dates, > ara pot mostrar «dia mes» [1] si el fitxer de traducció ho indica. > 2. Amb això [1], ara sí que s'aplica la línia de format de la > traducció (en el cas català indica mes dia), però la traducció de > coretutils de bullseye usa %Ob (mes abreujat sense preposició, p. ex. > «ag.»), però «ls» no ho parseja internament i per això queden les > columnes desquadrades. > 3. Per a evitar el desquadrament del punt anterior es va optar per una > solució de compromís, i canviar la traducció perquè uses %b (mes > abreujat amb preposició, p. ex. «d'ag.»), però que «ls» parseja > internament per a quadrar les columnes). > 4. Què ha passat, doncs? Que el canvi en la traducció es va fer per a > coreutils 8.31.90 [2], última versió que consta al Translation > Project, però bullseye usa 8.32 [3], que no apareix a TP. I la 8.32 > encara té %Ob a la traducció. Primer de tot vull agrair la feina que fa tota la gent que contribueix a la localització de programari GNU a la llengua catalana. En segon lloc, no vull semblar negatiu, però jo segueixo pensant que la preposició sobra en els llistats de directori. I, desafortunadament, ls no és l'únic programa afectat. systemd mostra les dates d'aquesta manera d’ag. 22 11:56:16 doriath offlineimap[1492]: Syncing Trash: IMAP -> MappedIMAP d’ag. 22 11:56:17 doriath offlineimap[1492]: *** Finished account 'Posteo.…:03 Hint: Some lines were ellipsized, use -l to show in full. El dmesg igual: [dg. d’ag. 22 10:37:23 2021] usb 1-8: device descriptor read/64, error -71 [dg. d’ag. 22 10:37:23 2021] usb 1-8: device descriptor read/64, error -71 [dg. d’ag. 22 10:37:23 2021] usb usb1-port8: attempt power cycle En definitiva, han passat 4 anys des de que es va "modernitzar" el local ca_ES, i després de 4 anys jo penso que ja podem afirmar que la experiència de l'usuari amb el local nou és pitjor que amb el local anterior. Crec que la comunitat d'usuaris de GNU/Linux catalano-parlants ens hem de plantejar si volem mantenir el local "modernitzat" que no funciona, o si preferim tornar al local anterior. Evidentment hi ha arguments a favor i en contra de les dues alternatives. Personalment, m'inclino per la segona. En fi, jo crec que hi hauria d'haver un debat i una votació sobre aquest tema. Què en penseu vosaltres? Salutacions.
Re: Debian 11 estable en poques hores
2021-08-15, 22:17 (+0200); Josep Lladonosa escriu: > Us escric ja des d'una Debian 11 escriptori xfce4 actualitzada des de > Debian 10.10. Jo igual, les úniques coses que he trobat - el mutt refusa connectar-se per IMAP si no és amb ssl, si vols connectar sense ssl has d'afegir les opcions unset ssl_starttls unset ssl_force_tls - l'inici automàtic d'aplicacions d'xfce inicia les aplicacions abans que el servidor X hagi arrencat (???) i això pot fer fallar algunes aplicacions, concretament conky (per sort conky té una opció '-p' per retrassar l'inici uns segons, i amb això s'ha solucionat) A part d'això, els altres problemes són cosmètics (temes, icones...). Salutacions
Re: (deb-cat) Alentiment de processos amb les hores i els dies
2021-08-18, 17:37 (+0200); Narcis Garcia escriu: > No trobo cap indici del problema en processos que corren, ni res de res. > Només se m'acudeis que pot ser un defecte del nucli Linux (potser les > mitigacions per a Intel?), ja que arrencant amb els nuclis més antics > (4.9 i 4.19) la cosa és més exagerada. Però amb el Linux 5.10 no me'n > lliuro. > > Algú sap com esbrinar el problema? Has comprovat l'ús de memòria, cpus, discs, i freqüència del rellotge? Aquestes serien les primeres coses que miraria... i òbviament la sortida de dmesg. Salutacions
Re: Debian 11 estable en poques hores
2021-08-18, 01:46 (+0200); jordi P. escriu: > He seguit amb un minipc Acer Veriton que tinc connectat per HDMI a una tv. > > M'he trobat que els drivers propietaris per la tarja nvidia "legacy-340xx" > els han suprimit per alguna collonada de seguretat. > Ara per força has d'utilitzar el nouveau, que en el meu cas funciona molt > malament i no és comunica amb la tv. > > De fet la versió live de la 11 no arrenca amb aquesta maquina. > > M'ha costat moltes hores de tenir l'entorn gràfic funcionant. Personalment, em plantejaria descartar Nvidia d'ara en endavant, independentment de la qualitat del maquinari, i només utilitzar components AMD o Intel, empreses que com a mínim tenen una política de col·laboració amb els desenvolupadors de drivers de programari lliure. El resultat és que les targetes d'AMD o Intel estan, generalment, ben suportades pels drivers lliures inclosos en el kernel, contràriament al que passa amb el maquinari de Nvidia. Salutacions.
Re: Debian 11 estable en poques hores
2021-08-12, 22:35 (+0200); a...@probeta.net escriu: > Sembla que tindrem nova Debian estable aquest dissabte, 14 d'agost, en unes > hores. > Agraïments a tots els qui hi hagueu contribuit.
Re: Editar arxius al postinst d'un paquet debian
2021-06-21, 20:04 (+0200); Daniel escriu: > Quina es la forma elegant de fer-ho? O alguna guia una mica avançada > de crear paquets debs per scripts (només he trobat per crear paquets > compilats, i les que estan orientades a fer-ho de manera manual son > molt bàsiques) No tinc gaire experiència en això, però jo crec que l'estratègia més habitual és utilitzar un makefile, tant si és un script com un programa compilat. Llavors els scripts que construeixen el paquet Debian simplement fan make & make install i empaqueten el resultat. L'únic que has de fer és crear el fitxer control i changelog, que són els únics específics per al teu paquet, la resta tenen un contingut genèric i pots re-ciclar els d'altres paquets. Et poso un exemple d'un paquet que instal·la un script shell, tot i que no sé et servirà gaire perquè també compila i instal·la uns mòduls, però si elimines el directori module/ i els fitxers guile.am, pre-inst-env.in, i edites el configure.ac per eliminar les referències a GUILE i als fitxers que has eliminat, hauria de quedar un paquet amb un simple script: https://github.com/nfdisco/csv2sc Salutacions.
Re: Mesurar rendiment d'una aplicació
Hola, 2021-06- 2, 08:13 (+0200); Leopold Palomo-Avellaneda escriu: > Però és una passada perquè el CPU time hauria de ser més o menys constant i > no ho és. Nosaltres hem trobat variacions de fins al un 10%. Però un 10% quant és en termes absoluts? No és el mateix 30 segons que 500 milisegons. A les llistes de computació científica, la gent sempre reporta estadístiques sobre el temps d'execució, mai un únic temps d'execució. O sigui el que fan és executar el programa o funció repetidament moltes vegades i calculen la mitjana. De fet tenen eines d'anàlisi de rendiment que ho fan automàticament. Salutacions.
Re: Detectar salvapantalles o blocatge d'escriptori
2021-05-31, 09:12 (+0200); Narcis Garcia escriu: > M'agradaria programar que, quan no estic utilitzant l'ordinador, aquest > faci una sèrie de tasques que em molestarien si les faig mentre hi treballo. > > Hi ha alguna manera de detectar amb Shell Scripting si l'escriptori està > blocat o bé amb el salvapantalles en marxa? No n'hi ha prou amb saber si l'escriptori està blocat. Algun usuari podria estar utilizant l'ordinador remotament mentre l'escriptori està blocat, per exemple. Aquestes situacions es poden detectar amb l'eina loginctl que forma part de systemd. L'opció list-sessions imprimeix un llistat amb les sessions obertes i l'opció session-status et diu si la sessió està activa. Per exemple, $ loginctl list-sessions SESSION UID USER SEAT TTY 2 1000 ernest seat0 246 1000 ernest pts/3 2 sessions listed. loginctl session-status 2 | grep '^\s*State:' State: active "Activa", mentre que quan l'escriptori està blocat diu "online". Salutacions
Re: / plena
2021-05-11, 10:34 (+0200); Jordi Vila escriu: > He probat el du amb diversos paràmetres i no hi veig res. > > La 'unica cosa seria amb el home, però en principi està en particions > diferents. Si has vist que tens 100G a / > > > /dev/sda1 110G 100G 4,1G 97% / vol dir que la suma dels directoris a la partició / ha de ser 100G Jo revisaria que to tinguis alguna cosa a /mnt, a part d'això no veig res > 77G /mnt
Re: / plena
2021-05-11, 10:08 (+0200); Jordi escriu: > Bon dia, de cop i volta m'he trobat amb un problema prou important i no > m'ensurto. > > > Com veieu en aquestes dues linies, hi ha poques hores de diferència > entre les dues. > > /dev/sda1 110G 33G 72G 32% / > > /dev/sda1 110G 100G 4,1G 97% / > > La veritat que que la segona arribava al 100% d'ocupació però he > netejat /var/log /tmp i s'ha quedat així, però no trobo de cap manera > els fitxers que sobren ara. En tot cas no seran fitxers massa grans > però segurament si que hi haurà mols, però no els trobo. Has provat amb du? Per exemple: # du -s -h -x /* 12M /bin 124M/boot 0 /dev 30M /etc 5.2T/home 0 /initrd.img 0 /initrd.img.old 673M/lib 4.0K/lib64 16K /lost+found 12K /media 8.0K/mnt 4.0K/opt du: cannot read directory '/proc/858/task/858/net': Invalid argument du: cannot read directory '/proc/858/net': Invalid argument du: cannot access '/proc/24548/task/24548/fd/4': No such file or directory du: cannot access '/proc/24548/task/24548/fdinfo/4': No such file or directory du: cannot access '/proc/24548/fd/4': No such file or directory du: cannot access '/proc/24548/fdinfo/4': No such file or directory 0 /proc 4.6M/root 150M/run 16M /sbin 4.0K/srv 0 /sys 40M /tmp 16G /usr 82G /var 0 /vmlinuz 0 /vmlinuz.old Salutacions
Re: article
2021-02-26, 11:49 (+0100); Narcis Garcia escriu: > Allò que arriba a la seva fi és, en realitat, la percepció il·lusòria de > què els grans taurons transnacionals utilitzen o utilitzaran el > programari lliure per raons ètiques per davant de lucratives. No crec que gaire gent tingués aquesta percepció. La majoria de persones entenen la diferència entre una empresa i una organització sense afany de lucre. Salutacions.
Re: (deb-cat) Desfragmentacio de l'arrencada
2021-02-24, 11:16 (+0100); Jordi Miguel escriu: > Si ho proves ja ens comentes l'experiència, i si la feina de muntar > aquestes coses val la pena per estalviar-se comprar un SSD per un > sistema antic. Amb el preu d'un SSD avui dia sembla difícil de > justificar el temps per configurar i mantenir aquestes artesanies, > però sempre és divertit pels amants de la tecnologia. Exacte... jo també tinc curiositat per saber en quin % es redueix el temps d'arrencada, amb aquest sistema, però m'imagino que deu ser un % molt baix. I per altra banda em pregunto si té sentit fer totes aquestes optimitzacions i després no recompilar el nucli i tots els paquets del sistema amb codi màquina optimitzat. Salutacions.
Re: [OT] Sector laboral - Ús de Debian/Software Lliure
2021-02-12, 10:34 (+0100); Joan escriu: > Jo vaig començar a usar linux a finals dels 90. Potser una KDE que > devia sortir en un CD d'alguna d'aquelles revistes tipus "sololinux" o > similars... Jo a principis dels 00, Debian 'potato' que ocupava 3 CDs. Però el primer Unix que va funcionar al meu ordinador no era Linux, era una altra cosa, probablement Minix. Tot el sistema cabia en un disquet de 3.5. Salutacions.
Re: [OT] Sector laboral - Ús de Debian/Software Lliure
2021-01-27, 19:54 (+0100); Joan Albert escriu: > Fa temps que tinc curiositat sobre el sector on > treballem/investiguem/estudiem els integrants d'aquesta llista, > i saber si allà utilitzem o no la nostra estimada distribució, > software lliure en general o no és el cas. Doncs, no, on jo treballo, que és al sector financer, no he vist mai programari lliure i encara menys ningú que utilitzi GNU/Linux. En feines anteriors, tot i utilitzar Windows, podia fer servir programes com Emacs, R, Python, fins i tot Latex, però en aquesta institució financera on estic ara funciona tot a través d'un escriptori remot a on és impossible instal·lar cap programa propi i que funcioni. Tot està centrat al voltant del Microsoft Office, i altres programes propietaris. Els ordinadors centrals són mainframes de IBM que funcionen amb alguna mena de Unix, tot i que la majoria del personal només hi accedeix a través de interfície web.
Re: [OT] Feedback (era Re: Algú vol col·laborar en aquest projecte?)
2021-01-30, 23:15 (+0100); Orestes Mas escriu: > Si ho apliquem al benefici econòmic que pot rendir una inversió, ho > veig bé. Res a dir. Però d'això els anglesos no en diuen "feedback". La terminologia econòmica es "rendiment" i no retorn. Per exemple, "la llei dels rendiments decreixents". Si dius retorn també t'entendran però sona estrany.
Re: Algú vol col·laborar en aquest projecte?
2021-01-21, 10:16 (+0100); Alex Muntada escriu: > Bé, a Debian volem que tots els espais siguin segurs perquè > tothom s'hi senti còmode. Però si fins i tot l'Obama va dir que estava contra els espais segurs perquè infantilitzen la societat! > Els espais segurs el que fan és generar la confiança suficient perquè > eventualment aquestes persones puguin fer millores en la seva > autoestima i inseguretat, al ritme que els vagi bé, no al que imposin > els altres. Penso que no té sentit que pretenguis que ens comportem com si tothom tingués una depressió o un problema de falta d'autoestima. La crítica forma part de la interacció normal entre persones i en aquesta llista hem de poder interactuar normalment. Salutacions.
Re: Algú vol col·laborar en aquest projecte?
2021-01-20, 09:25 (+0100); Leopold Palomo-Avellaneda escriu: > Per acabar, una reflexió personal de que he interpretat d'aquests correus. > Realment voleu una societat que no accepti la crítica? S'ha de protegir tant > a la gent els frustraríem i ai pobrets? Exacte. Als països anglo-saxons han arribat a l'extrem de crear "espais segurs", espais on no està permès utilitzar certes paraules o parlar de certs temes, amb l'objectiu que les persones a qui aquestes paraules o temes fan sentir incòmodes s'hi puguin estar i no s'hagin de sentir incòmodes. En lloc d'ensenyar a aquestes persones a afrontar les crítiques i els temes incòmodes, el que fan es crear espais perquè no els hagin d'afrontar. Per cert, evitar criticar algú perquè penses que "no ho pot fer millor" no és l'insult més fort que pots fer?
Re: Algú vol col·laborar en aquest projecte?
2021-01-20, 08:17 (+0100); Joan escriu: > També vull posar en valor, però, malgrat la millora que comenteu sobre > la positivitat, la feina del Leopold, que de fet és qui ha fet uns > suggeriments més útils per en Baptista, si no te en compte les > asprors del missatge. No només ha fet els suggeriments més útils, sinó que és l'únic que ha fet suggeriments!
Re: Algú vol col·laborar en aquest projecte?
2021-01-20, 16:22 (+0100); Alex Muntada escriu: > En Joan no feia aquestes preguntes i no demanava una mirada crítica > explícitament. Potser ho he interpretat malament, però jo diria que ha demanat ajuda perquè veu que el programa no té gaires usuaris ni troba gent que es vulgui involucrar en el projecte. Quin altre plantejament hi pot haver, per tal d'ajudar a resoldre aquesta situació, que no sigui analitzar precisament els motius que provoquen aquesta falta d'interès? > Això és un judici: atribuir la responsabilitat d'una observació > a algú quan podria ser cosa de la meva configuració d'escriptori, > de les meves versions o vés a saber què més. Pot ser un defecte > del programa o pot ser un defecte del meu sistema que afecta el > programa. O sigui, entenc que tu t'abstindries de comentar cap defecte o mancança del programa que pugui ser atribuïble al seu autor, per por que aquest se senti ofès. Per exemple, no qüestionaries l'elecció del llenguatge de programació, o el fet de no seguir les pràctiques habituals en l'àmbit dels projectes de programari lliure, tot i ser saber que això redueix enormement les probabilitats que altres persones vulguin participar en el projecte. De veritat tu creus que d'aquesta manera estàs ajudant aquesta persona? > En qualsevol cas, Debian aposta explícitament per la diversitat. > Les regles de la comunitat són clares i la llibertat d'expressió > no és una d'elles. Hi ha gent de la comunitat que no hi està > d'acord, però són les regles del joc i s'han de respectar si hom > vol formar-ne part. No trobo cap regla que parli de diversitat. L'únic que he trobat és una declaració de diversitat [1] que diu que el projecte està obert a les contribucions de gent de qualsevol àmbit. Pel que fa al codi de conducta aplicable a les llistes [2], diu que no utilitzem llenguatge malsonant i que intentem no fer "flames". No diu res de no jutjar o de no opinar sobre la feina dels altres, ni que el dret dels altres a no ser ofesos ha de prevaldre per sobre del dret a expressar la pròpia opinió. [1] https://www.debian.org/intro/diversity [2] https://www.debian.org/MailingLists/#codeofconduct
Re: Algú vol col·laborar en aquest projecte?
--text follows this line-- Hola, Àlex 2021-01-19, 09:14 (+0100); Alex Muntada escriu: > > Concretament, què és el que trobes inadequat de la seva > > resposta? Sembla que dius que li falta "empatia" i > > "comprensió", però jo no veig ni una cosa ni l'altra. > > Per exemple, dir que són errors greus haver triat sourceforge > i visual basic com a llenguatge de programació; dir que el codi > està mal cuidat i que el formulari principal és infumable. D'acord, suposo que tenim idees diferents del que significa tenir falta d'empatia i/o comprensió. > L'empatia es basa en posar-se en el lloc i el context de la > persona a qui va dirigit el missatge. En valorar quin pot ser > el seu estat d'ànim (el missatge d'en Joan donava algunes pistes > en aquest sentit) i ajustar el to per fer-lo més adient. També > es basa en no jutjar la feina (tenint en compte que tothom fa el > que pot amb els coneixements i els recursos que té) i ajustar-se > al que s'està demanant. Ajustar el to, d'acord, però no jutjar? Tots "jutgem" i tenim opinions sobre el que fan els altres, és impossible no fer-ho. Suposo que, quan dius que no hem de jutjar la feina dels altres, vols dir que no hauriem de fer públiques aquestes opinions. No hi estic d'acord! > En Joan no ha demanat que es critiqui la seva feina ni que es > qüestionin les seves decisions. Demana ajuda per millorar-la, > que no és ben bé el mateix. No, no és ben bé el mateix. Però si ens preguntem per quins motius el programa en qüestió 1) té pocs usuaris, i 2) hi ha poca gent disposada a col·laborar en el projecte, és necessari que fem una mirada crítica a aquest programa, per intentar entendre per què està passant això. Si no vols fer aquesta crítica, no esperis entendre res, i no esperis que res millori, perquè com vols que una cosa millori si d'entrada no vols veure els problemes que té? > Per exemple, quan he provat el programa, al formulari principal > se solapen alguns dels camps i el text blanc en fons gris amb > l'enllaç de la imatge ISO té poc contrast. Dient-ho així, a banda > de ser més concret i donar pistes de com resoldre-ho, no estic > jutjant la feina d'en Joan. Doncs jo crec que sí que l'estàs jutjant, i que estàs qüestionant les seves decisions... si no per què comentes que una imatge té poc contrast i que el text està mal alineat? Algú és responsable que la imatge tingui poc contrast i que el text estigui mal alineat, i tu (subtilment) li estàs dient que a aquesta persona no ho ha fet prou bé. > Això d'haver de tenir la pell dura era un fet acceptat fa temps > en moltes comunitats i justificava moltes faltes de respecte que > allunyava força persones d'aquestes comunitats, fent-les menys > diverses i més endogàmiques. > > Avui en dia ja no és així. La majoria de comunitats no defensen > que calgui tenir la pell dura, ben al contrari, demanen tenir > sensibilitat i comprensió per a la gran diversitat que persones > que hi ha, fins i tot a costa de l'excel·lència tècnica que > tinguin les persones que defensen tenir la pell dura. Vols dir que et preocupa que algú deixi aquesta comunitat per culpa de gent expressa opinions que poden ferir la sensibilitat d'algú? Potser hi haurà altra gent que s'allunyarà de la comunitat si senten que no poden expressar les seves opinions amb llibertat. En tots dos casos el resultat és una comunitat menys "diversa". Per tant no crec que es pugui dir que restringir la llibertat d'expressió afavoreixi la diversitat. En tot cas tampoc crec que la diversitat sigui una cosa desitjable (o indesitjable), o que sigui bona idea afavorir-la a costa de restringir la llibertat d'expressió. Salutacions.
Re: Algú vol col·laborar en aquest projecte?
2021-01-18, 15:37 (+0100); Alex Muntada escriu: > Encara que en el fons potser estigui d'acord amb tu en algunes > de les observacions que has fet, la forma en què les has fet > em genera mal esperit, sobretot tenint en compte que les has > fet públicament en aquesta llista. Em preocupa que hi hagi > persones (com el mateix Joan) que deixin de fer preguntes i > de demanar feedback dels seus projectes o idees per por als > comentaris que facin alguns membres d'aquesta llista. > > Amb això no vull dir que deixeu de respondre i opinar; el que us > demano, si us plau, és una mica més d'empatia i comprensió cap a > la diversitat de persones que conformem aquesta comunitat. Doncs a mi m'ha semblat una resposta molt adequada i respectuosa. Jo mateix estava a punt d'escriure una resposta semblant, però quan vaig veure la resposta del Leo vaig pensar que tot el que volia dir ja ho havia dit tot ell i molt millor que jo. Concretament, què és el que trobes inadequat de la seva resposta? Sembla que dius que li falta "empatia" i "comprensió", però jo no veig ni una cosa ni l'altra. I si algú deixa de demanar l'opinió sobre els seus projectes per por de rebre una opinió negativa, personalment veig molt més preocupant el fet que no sàpiguen afrontar les crítiques i les opinions negatives, que el fet que deixin de preguntar. Salutacions.
Re: Píndoles de DebianCat
2021-01- 8, 09:29 (+0100); Àlex escriu: > Trobo que és molt bona iniciativa, però no sé amb quines píndoles podria > contribuir. Els conneixements que tinc més que ser de Debian són de > Linux en general. > Jo penso el mateix, ho trobo bona idea però potser la temàtica dels articles és una mica limitada. Aquesta idea de les píndoles em fa recordar la docuemntació "HOWTO" [1] que existia abans, però orientat específicament a l'administració o ús de sistemes Debian. [1] https://www.ibiblio.org/pub/Linux/docs/howto/
Re: Format de data incorrecte de «ls -l»
2020-12-24, 13:22 (+0100); Joan Montané escriu: > Caldria veure l'impacte del canvi que indiques. Per exemple en > aplicacions de calendari. Això també trencaria l'alineament amb el > CLDR. Qui va proposar els canvis al CLDR? He intentat investigar-ho, però no he aclarit res. > No tot funcionava perfectament abans del 2016. Aquests canvis són el > que permeten tenir el format de data correctament escrit, amb la > preposició "de" apostrofa quan cal. Per exemple al calendari de > l'escriptori. Em vaig fer un fart de veure "xxx de abril...". > Considero que sí, s'havien de fer. Probablement no calia modificar el local per solucionar un problema al calendari del Gnome. I en el cas improbable que l'única solució fos modificar el local, era previsible que aquests canvis comportarien problemes a altres programes. Les mateixes persones que van fer els canvis s'haurien d'haver responsabilitzat de fer les adaptacions necessàries als programes afectats per tal que seguissin funcionant normalment. Si no estaven disposades a fer-ho, no haurien d'haver modificat el local. No em sembla bé fer modificacions i després desentendre's de les conseqüències negatives d'aquestes modificacions. > Ara hem detectat 2 problemes completament diferents, i és important > diferenciar-los. > > Problema 1: aquest és general. Si un programa usa %b o %B en el format > de data, des del 2016 (en producció des del 2018?) això retorna mesos > amb preposició. Ha canviat la cadena del locale. En aquests casos > només cal corregir la traducció perquè usi %Ob o %OB. Forma part de la > feina de traducció/localització. En canviar els valors %b i %B es va > assumir que hi hauria un temps de transició on les traduccions no es > veurien bé (apareixeria la preposició duplicada o sense preposició). > La majoria de traduccions ja s'ha adaptat a usar %Ob i %OB. En queda > algun? Doncs es corregeix en la traducció. És el que caldria fer a > mutt. És que, a part de la preposició, els noms abreviats dels mesos han passat de tenir tres caràcters a tenir una llargada variable (amb punt inclòs). Aquestes dades del local no semblen adequades per a programes informàtics. Els programes d'interfície de text estan pensats per funcionar en terminals de 80 columnes. 80 columnes vol dir que l'espai és extremadament limitat i que la informació textual ha de ser minimalista. Si comencem a incloure punts, caràcters innecessaris i textos de llargades variables que trenquen l'alineació, l'usuabilitat d'aquests programes es degrada tant que els usuaris probablement no tindran més alternativa que emprar un altre local. Salutacions.
Re: Format de data incorrecte de «ls -l»
Hola, 2020-12-24, 09:41 (+0100); Joan Montané escriu: > En fi, que segueixo pensant que la solució de compromís és usar %b i > tenir la columna de mesos amb preposició, però ben enquadrada. Crec que no té sentit incloure la preposició en els noms mesos abreviats. Si utilitzem la versió abreviada és que volem estalviar espai, i si volem estalviar espai, la preposició sobra completament. Per altra banda, 'ls' no és l'únic programa afectat. Un altre programa afectat és el 'mutt'. Probablement n'hi ha d'altres. Aquests programes funcionaven perfectament fins que van modificar el text dels noms dels mesos en el local ca_ES, l'abril de 2016 [1]. Aquests canvis són l'origen de tots aquests problemes. Tenint en compte que, després de 4 anys, ni estan resolts, ni tenim clar com resoldre'ls, em sembla que ens hem de plantejar seriosament revertir els canvis al local i deixar els noms dels mesos com estaven. Un altre argument a favor de revertir el canvis és que el local ca_ES actual utilitza extensions que no figuren a l'estàndard POSIX (almenys jo no trobo cap referència als elements 'ab_alt_mon' i 'alt_mon' a l'especificació POSIX [2]). És un problema perquè a l'hora d'adaptar els programes per tal funcionin amb aquest local, al mateix temps estarem introduint una dependència a aquestes extensions que no formen part de POSIX. [1] https://sourceware.org/git?p=glibc.git;a=blobdiff;f=localedata/locales/ca_ES;h=d9a29d10a26acd58a711c7a8774ae31a0f35c396;hp=6c0105dd3085094ef7421147436be2116b66162f;hb=refs/heads/master;hpb=2e7a46132898c861785cb3da575033936d18fc4e [2] https://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html#tag_07_03
Re: Problemes amb automysqlbackup combinat amb un "locale" en català
2020-12-20, 10:40 (+0100); Joan Montané escriu: > Anem a pams, que potser s'estan barrejant temes. > > Els canvis a la glibc es van per fer coincidir els formats de data amb el > CLDR. Objectivament, aquests canvis permeten escriure les dates > correctament. És a dir, la iniciativa original no va ser des de Softcatalà, > però sí a la glibc. > En castellà no apostrofen els mesos, per això en el format de data tenen > "hardcoded" la preposició "de". > En francès no usen la preposició "de" en les dates (sospito que en el seu > dia van triar fer-ho així per a evitar el problema de l'apostrofació) > > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o > majúscula) en el format de date perquè usi el format sense proposició. > Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB" > retorna "abril" (sense preposició). > > El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb > això. És un altre problema que se suposa ja està corregit i tard o d'hora > arribarà tothom [1] Gràcies per l'aclariment.
Re: Problemes amb automysqlbackup combinat amb un "locale" en català
2020-12-20, 03:51 (+0100); Toni Mas Soler escriu: > Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única > llengua que es troba en aquesta situació? > > Com a primer plantejament caldria considerar la correcció del locale per > tal que un date +%B retorni el mes sense preposició. Exacte, el problema és el local ca_ES. Mireu aquest fil de fa 2 anys: https://lists.debian.org/debian-user-catalan/2018/10/msg0.html Pel que sembla, des de Softcatalà, van promoure un canvi al local ca_ES, que és el que provoca que ara apareguin els mesos amb preposició en llocs on no hi ha d'haver preposició. Ni el francès [1], ni el castellà [2], ni l'italià [3], que utilitzen els mesos igual que el català, han fet cap canvi similar en els respectius locals [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c [2] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c Jo ja fa temps vaig canviar el local a "C" perquè no podia soportar més els llistats de 'ls -l' amb els noms dels mesos equivocats. Salutacions.
Re: (deb-cat) Intervencio externa sobre actualitzacions del Firefox
2020-11-19, 10:59 (+0100); Joan escriu: > Jo diria que és impossible que el Firefox d'una debian s'actualitzi > sense que ho autoritzi un administrador, no? > > Hauria de modificar fitxers pels que els usuaris normals no tenen dret > a modificar... Exacte, és impossible que s'actualitzi sol.
Re: M'aconselleu? client git gràfic i senzill
2020-11-14, 08:42 (+0100); Àlex escriu: > Soc nou amb git. A partir d'ara haurè de fer unes tasques bàsiques: > editar fitxers locals en markdown i pujar-los a Github, i pujar algún > pdf també. > > Dels clients gràfics i senzills de git, quin recomaneu? Gitg? El pluguin > de Git de Geany? No hi ha cap editor de markdown on alhora pugui veure > el resultat (WYSIWYG) i alhora pujar canvis via Git? vscode? Emacs té un frontal pel git que es diu magit. Molt fàcil d'utilitzar i àgil. Pots utilitzar el mode text per escriure Markdown, juntament amb el mode grip per visualitzar el resultat en un navegador web. A Youtube hi ha videos de demostració.
Re: dubtes XOrg
2020-06-17, 12:41 (+0200); Àlex escriu: > Anant al gra ... He volgut modificar el fitxer xorg.conf però no l'he > trobat. Al final he creat aquest fitxer ... > > $ sudo nano /etc/X11/xorg.conf.d/90-monitor.conf > > Section "Monitor" > Identifier "" > DisplaySize 395 695 # In millimeters > EndSection > > Però en reiniciar el sistema xranr encara hem diu que la meva pantalla > és d'11 polzades, 160mm x 90 mm > > Teniu idea de què estic fent malament? El que pots fer és deixar que el servidor X generi un fitxer xorg.conf amb la configuració auto-detectada, i llavors editar la part del monitor i deixar la resta com està. Per fer això has d'aturar el servidor X. Vol dir que has d'anar a una consola Linux, aturar el servidor X amb el systemctl i llavors executes l'ordre X -configure. Això crea un fitxer xorg.conf en el directori on siguis. El copies a /etc/X11, fas els canvis que creguis convenients, i tornes a iniciar X amb el systemctl.
Re: Sobre traduccions a Linux Debian
qAOXOMOXOAp writes: > 2. També estaria interessat en un bon tutorial sobre com traduir > programes de Linux al català, mitjançat el Poedit, sobre els fitxers > de traducció .pot, .po i .mo. Segons diuen, és molt senzill, però no > puc arribar a entendre com es fa. Necessitaria un tutorial que t'ho > expliqués d'una forma clara i comprensible. No concec cap tutorial, però normalment les instruccions bàsiques per als traductors es troben en el fitxer TRANSLATORS (o un nom semblant) que es troba en el directori arrel del projecte. També pots mirar la documentació del gettext. El fitxer que has de traduir és un fitxer en format PO, que conté les frases del programa. En principi aquest fitxer el pots editar amb qualsevol editor de text, respectant el format, tot i que el més més pràctic és utilitzar un editor especialitzat com Poedit o Emacs. La principal dificultat és que no tens els context de les frases que has de traduir, i això porta a errors. Per tant, és important mirar que totes les traduccions tinguin sentit en el context del programa (copies el fitxer de missatges compilat (en format MO) en el directori adequat (a Debian és /usr/share/locale/ca/LC_MESSAGES/) i vas obrint tots els menús i fent totes les accions possibles per comprovar que tots les traduccions són correctes, no ocupin massa espai, etc.).
Re: Problemes amb la captura d'àudio
Enric writes: > Doncs torno al tema audio. > Em vau proposar fer això > # arecord -D hw:0,0 -f cd -t wav fitxer.wav > I em donava un error d'Entrada i Sortida. > En canvi, si ho faig amb > # arecord -D hw:0,0 -f data -t wav fitxer.wav > > no em dóna error. L'única diferència entre "-f cd" i "-f dat" (suposo que volies dir "dat", i no "data") és que l'opció "cd" llegeix dades amb una freqüència de 44100Hz i l'opció "dat" amb una freqüència de 48000Hz. Per tant podria ser que el teu xip d'audio només suporti lectura a 48000Hz. > El més curiós és que si endollo un micro, de fet, haig d'endollar uns > auriculars amb micro que només tenen una > entrada minijack, perquè el portàtil (Lenovo Tinkpad X220), només accepta una > entra d'audio. És a dir, si endollo un > micro no funciona, el pavucontrol detecta que he endollat un micro i tampoc > grava. > Per tant, entenc que si hi ha un problema de hardware és de la part de la > captura d'audio de la targeta de so, no pas > del micro intern. Però l'arecord amb l'opció -f dat enregistra alguna cosa o no? Mira bé que no tinguis l'entrada silenciada amb l'alsamixer a la targeta corresponent. (Per fer aquest tipus de comprovacions només hauries d'utilitzar arecord, aplay i alsamixer, que són els programes que interactuen directament amb ALSA.)
Re: Capturar i imprimir pantalla
Narcis Garcia writes: > El problema no és que sigui possible utilitzar una impressora per a > imprimir, sinó que a partir de la captura ja s'enviï a impressora, sense > obrir ni un terminal ni noves accions: Capturar && trobar-ho en paper. > > També ho podria resoldre si la drecera de teclat executés una comanda, > amb la qual jo ja automatitzaria Captura+Impressió. XFCE té un applet per executar programes amb un clic. El programa pot ser un fitxer executable o una ordre de l'intèrpret Unix. També permet configurar tecles per executar programes. Per exemple, la tecla PrntScr per defecte executa el programa xfce4-screenshooter. Es pot canviar per tal que executi una altra cosa. Si això ho pot fer XFCE, que és una versió minimalista de Gnome, m'imagino que Gnome també ho ha de poder fer.
Re: Capturar i imprimir pantalla
2020-04-11, 20:26 (+0200); Narcis Garcia escriu: > Ja m'ho deies bé: Acabo de provar la configuració que havia establert fa > dies (amb reinicis d'ordinador pel mig) i fa efecte allò que li vaig > establir aleshores (compte amb la sintaxi de la ruta): > $ gsettings get org.gnome.gnome-screenshot auto-save-directory > 'file:///home/usuari/Imatges' > > Ara les captures parcials les hi trobo, que abans no. Potser canvia > entre porta-retalls i fitxer segons si el paràmetre està configurat o > buit (?) > Visca la immensa documentació de Gnome! (perdó; la immensa manca) > > Ara seria fantàstic que l'esdeveniment portés aparellada l'execució > d'una instrucció. Si preténs imprimir automàticament la captura de pantalla, per què no envies la imatge directament a lp a través d'una canonada? xwd | convert xwd:- png:- | lp Personalment, em sembla que és malgastar paper, però això és un altre tema.
Re: Problemes amb la captura d'àudio
2020-03-25, 22:09 (+0100); Enric escriu: > Em diu el següent: > > # arecord -D hw:0,0 -f cd -t wav fitxer.wav > Recording WAVE 'fitxer.wav' : Signed 16 bit Little Endian, Rate 44100 > Hz, Stereo > arecord: pcm_read:2145: read error: Error d'Entrada/Sortida > > Això fa pinta d'error de Hardware, no? D'entrada diria que sí, però suposo que també podria ser un bug. Si dius que abans et funcionava jo provaria una versió anterior del kernel. Salut.
Re: Problemes amb la captura d'àudio
2020-03-25, 17:50 (+0100); Enric escriu: > ARECORD > > List of CAPTURE Hardware Devices > card 0: PCH [HDA Intel PCH], device 0: CX20590 Analog [CX20590 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 Diu que tens un dispositiu d'enregistrament a la targeta número zero, i que el dispositiu és el número zero. Per enregistrar amb aquest dispositiu pots provar arecord -D hw:0,0 -f cd -t wav fitxer.wav
Re: Instalar 'hostname'
2020-03-20, 17:15 (+0100); Narcis Garcia escriu: > $ hostname -f > hostname: Name or service not known > > [...] > > 2. Hi ha algun servei o fitxer del qual depèn aquest error sobre FQDN? Diuen [1] que probablement et falta afegir el nom del host a /etc/hosts [1] https://unix.stackexchange.com/questions/283550/i-got-error-hostname-name-or-service-not-known-when-checking-ip-of-hostname
Re: Format numeric local
2019-12- 7, 11:23 (+0100); Narcis Garcia escriu: > Algú sap com és que, amb Debian 10, no em funcionen els exemples > documentats al final d'aquesta pàgina? > https://www.gnu.org/software/coreutils/manual/html_node/numfmt-invocation.html > > També provo altres exemples trobats arreu del web sobre printf, però la > separació de milers no em fa ni cas. Hi ha un error en el fitxer ca_ES. Aplicant el següent canvi ja funciona --- /usr/share/i18n/locales/ca_ES.orig 2019-12-07 12:05:29.988128644 +0100 +++ /usr/share/i18n/locales/ca_ES 2019-12-07 12:05:48.056228594 +0100 @@ -88,7 +88,7 @@ LC_NUMERIC decimal_point"," thousands_sep"." -grouping 0;0 +grouping 3;3 END LC_NUMERIC LC_TIME $ LC_ALL=ca_ES.utf8 numfmt --grouping 1,01 1.000.000.000.000,01
Re: xfce amb... wayland o x11? Problemes amb anydesk
2019-11-29, 19:41 (+); Ricard Pradell escriu: > Entenc doncs que si tinc xorg funcionant, no hi ha cap possibilitat que ho > estigui fent wayland, oi? Totalment. > Vist tot això, sembla clar que el problema amb anydesk no té a veure amb > wayland. El cas és que des de la darrera versió per linux que em funciona > correctament (2.9.5) no hi ha hagut cap altra que m'anés bé, i van per la > cinc i pico. El que no sé és si la culpa la té xfce, que li falti alguna > cosa que anydesk necessita per funcionar, o què. Si en teniu alguna idea o > suggeriment, serà benvingut. No et puc ajudar, mai he fet servir aquest programari. Salut.
Re: xfce amb... wayland o x11? Problemes amb anydesk
Hola Ricard, 2019-11-29, 12:03 (+); Ricard Pradell escriu: > La sortida per tty7 no dóna res, però ho vaig fer per tty1, que és on > startx s'executa, i em dóna el següent: > > 1179 tty1 00:00:00 login > 1566 tty1 00:00:00 bash > 1628 tty1 00:00:00 startx > 1650 tty1 00:00:00 xinit > 1651 tty1 01:53:02 Xorg > 1664 tty1 00:00:00 sh > 1693 tty1 00:00:00 dbus-launch > 1704 tty1 00:00:23 xfce4-session > 1713 tty1 00:02:35 xfwm4 > 1715 tty1 00:00:00 Thunar > 1717 tty1 00:00:32 xfce4-panel > 1720 tty1 00:00:26 xfdesktop > 1793 tty1 00:00:00 panel-2-actions > 1796 tty1 00:00:00 panel-6-systray > > A ulls d'un profà i assumint que potser dic una animalada, sembla que el > procés Xorg s'inicia aquí, o sigui que res de wayland, pel que veig. Exacte, Xorg és el servidor X, i és a tty1 perquè has executat startx en aquesta consola (em pensava que canviava automàticament a tty7 però veig que no...) > Dedueixo que faig servir x11, no? Llavors no entenc perquè "echo > $XDG_SESSION_TYPE" surt en blanc... Teniu alguna explicació a això? Aquesta variable descriu el tipus de sessió de l'usuari, i el tipus de sessió de l'usuari depèn de com l'usuari ha entrat al sistema. Si entres fent login en una consola, hauria de dir "tty". Per què no tens aquesta variable definida, ni idea... tampoc sé si és important. Si vols detalls sobre la sessió pots utilitzar el programa loginctl $ loginctl list-sessions SESSION UID USER SEAT TTY 200 root seat0 tty1 258 1000 ernest seat0 tty2 3 1000 ernest seat0 $ loginctl show-session 258 Id=258 User=1000 Name=ernest Timestamp=Thu 2019-11-28 19:48:45 CET TimestampMonotonic=447956893037 VTNr=2 Seat=seat0 TTY=tty2 Remote=no Service=login Scope=session-258.scope Leader=10089 Audit=258 Type=tty Class=user Active=no State=online IdleHint=no IdleSinceHint=1575035008359871 IdleSinceHintMonotonic=486721825059 LockedHint=no
Re: xfce amb... wayland o x11? Problemes amb anydesk
2019-11-28, 16:46 (+); Ricard Pradell escriu: > El meu coneixement sobre entorns gràfics és molt limitat, o sigui que > agrairia el vostre ajut. Per concretar: > > 1- Com puc saber quin gestor gràfic estic utilitzant? $ ps -e | grep tty7 > 2- Com puc forçar l'ús de x11 al iniciar l'entorn des de consola amb > "startx"? No cal que forcis res perquè startx no inicia res més que el servidor X. $ apropos startx startx (1) - initialize an X session > 3- I lligat amb l'anterior, com puc deshabilitar wayland en el cas que > sigui aquest el que s'inicii per defecte amb startx? Pots desinstal·lar els paquets de Wayland, però com et dic no cal perquè el programa startx inicia X. Wayland s'inicia d'una altra manera. Salut.
Re: (deb-cat) Participacio a Gnome
2019-10- 3, 10:11 (+0200); Narcis Garcia escriu: > No tinc problema en enregistrar (i utilitzar) un compte a gitlab.com per > a utilitzar els recursos allotjats a gitlab.com D'acord, doncs jo crec que han quedat clares les alternatives que hi ha per participar al projecte Gnome. > El què veuràs amb aquesta proliferació de credencials, és l'increment i > descontrol del «phising». > A) La pesca tradicional, on un web et dirà «pots iniciar sessió amb > nosaltres utilitzant el teu compte de Google» (ja no t'hauran de mentir > sobre una incidència o verificació de dades). > B) El pixing nou, on una clàusula del teu contracte amb Paypal els > permeti utilitzar PSD2 per a què Paypal accedeixi als teus comptes bancaris. > Serà fantàstic; ja no et caldrà tenir saldo a Paypal per a fer compres, > perquè serveis privats com aquest podran «embargar-te» diners d'altres > llocs. > > ...i evidentment la ignorància de la gent que no entén ni un borrall en > TIC serà la més rentable de la història (més que a l'edat mitjana). No acabo de veure això que dius. Vols dir que Paypal no ha pogut accedir sempre als teus comptes bancaris? És la idea en què es basa, de fet: fer pagaments amb el saldo que tens al compte bancari. Potser se m'escapa alguna cosa... Salut.
Re: (deb-cat) Participacio a Gnome
2019-10- 2, 21:16 (+0200); Narcis Garcia escriu: > És que no m'agrada el trasvàs de dades personals entre empreses. > [...] > A tot arreu el què faig és enregistrar un compte específic. La majoria de projectes de PL són a gitlab o github, no tenen una plataforma específica on puguis obrir un compte. Qualsevol persona que tingui intenció de participar en projectes de PL, normalment el que fa és obrir un compte a un d'aquests dos llocs. > Ja veuràs tu quan a La Caixa es pugui iniciar amb el compte de Google o > de Paypal... Què veuré, exactament?
Re: (deb-cat) Participacio a Gnome
2019-10- 2, 13:52 (+0200); Narcis Garcia escriu: > Com reportar una incidència del programari de Gnome? > > Tenen un repositori de codi a gitlab.gnome.org però no hi ha registre de > nous usuaris. > Allà fan referència al centre (LDAP) account.gnome.org que es veu que > està gestionat per RedHat, però tampoc no s'hi ofereix manera > d'enregistrar un nou compte. Acabo d'anar a gitlab.gnome.org i veig que hi pots entrar sense problemes utilitzant un compte de gitlab, github o google. Suposo que si vols un compte a gnome.org l'hauries de demanar a algú (no sé com funciona) però d'entrada per informar de bugs i/o fer contribucions no el necessites.
Re: L'actualització del kernel no arrenca
2019-09-29, 19:17 (+0200); Jordi Fontich escriu: > elementaryOS 5.0 està muntat sobre Ubuntu 18.04.2 LTS. El meu CPU és > Celeron N2840 a 2.16GHz. No és cap meravella, però em sembla que tampoc és > tan antic com per ser incompatible. Sí, suposo que no deu ser això... > On puc trobar els errors? On son els logs habitualment? En el moment de l'arrencada els logs van a la pantalla, hauries de veure una cosa com Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2 (2019-08-28) Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 root=UUID=0f81cfe8-cd43-43e1-9bcf-ad7feb9ec71a ro quiet x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' . . . i en algun moment "Kernel panic", que vol dir que no pot continuar i s'atura. Si no veus res és que el nucli no s'arriba a executar, o que tens la pantalla mal configurada. Salut
Re: L'actualització del kernel no arrenca
Hola, 2019-09-29, 16:56 (+0200); Jordi Fontich escriu: > El sistema ha anat actualitzant els nuclis, però ha arribat un moment > que els nuclis han deixat d'arrencar. > Ja porto tres nuclis actualitzats amb els que no puc arrencar el > sistema i no sé com resoldre-ho. L'única cosa que se'm acudeix és que hagin compilat els nuclis més recents amb optimitzacions que són incompatibles amb el teu CPU. > Entenc que no és un problema d'elementaryos, sinó de Linux. Si creieu > que aquest no és el lloc per aquesta mena de dubtes ho entendré. > Només cerco suport tècnic. Pots preguntar en aquesta llista però és difícil esbrinar res si no diu cap error. Salut.
Re: debconf20 sera a Israel (!!??)
2019-09- 3, 19:48 (+0200); Narcis Garcia escriu: > I'm using this express-made address because personal addresses aren't > masked enough at this mail public archive. Public archive administrator > should fix this against automated addresses collectors. > El 3/9/19 a les 18:12, Ernest Adrogué ha escrit: > > 2019-09- 3, 07:16 (+0200); Àlex escriu: > >> I molta gent tindrà prohibida l'entrada a Israel per anar a la Debconf. > > > > D'acord, això és un argument més sòlid. (Si és cert, que ho desconec.) > > Estava començant a fer recerca sobre les traves del govern israelià cap > a persones de fora amb antecedents ideològics concrets, però, llegint > sobre el tema, he decidit deixar de qüestionar els afers polítics > d'Israel públicament, tenint a més aquesta llista una hemeroteca de tot > allò què s'escriu i amb el nom de cadascú. > > Vivim en un món complex, i la majoria de nosaltres som com formigues que > hem de treballar molt per menjar. No crec que sigui tan complex el món, de fet és bastant simple. Si et preocupa que algú investigui les teves opinions, no escriguis opinions signant amb el teu nom. Si et preocupa que algú descobreixi qui ets, tot i no signar amb el teu nom, utilitza un sistema de comunicació anònima (el problema està resolt tecnològicament des de fa dècades). El 1994, l'administrador del remailer anon.penet.fi deia això: «It's important to be able to express certain views without everyone knowing who you are. [...] Living in Finland, I got a pretty close view of how things were in the former Soviet Union. If you actually owned a photocopier or even a typewriter there you would have to register it and they would take samples of what your typewriter would put out so they could identify it later.» Però, vaja... em sembla que el tema d'aquesta llista és Debian i el programari lliure, no crec que sigui el lloc adequat per discutir sobre la política de l'orient mitjà. Sobre el Debconf, algú de vosaltres realment hi pensava anar i s'ha fet enrere? Personalment, com que no estic involucrat amb Debian, només sóc un usuari, la veritat és que no m'afecta gaire per no dir gens.
Re: debconf20 serà a Israel (!!??)
2019-09- 3, 07:16 (+0200); Àlex escriu: > I molta gent tindrà prohibida l'entrada a Israel per anar a la Debconf. D'acord, això és un argument més sòlid. (Si és cert, que ho desconec.) Salut.
Re: debconf20 serà a Israel (!!??)
2019-08- 3, 12:11 (+0200); Pedro escriu: > Algú que hagi anat a la debconf19 o que estigui més al cas ens pot > explicar com un projecte que treu pit per inclusivitat [1] com debian > accepti fer la seva trobada anual en un país que està fent una ocupació > forçada i assetjament continu contra el poble palestí, poble originari > d'allà des de fa molts anys (per tant una situació colonialista i > recent). Debian ha fet o farà un comunicat al respecte? > > La verificació final de les persones i les organitzacions són els fets, > no les paraules. Com se suposa que jo m'he de prendre això? Debian és una organització que es dedica al programari lliure. Sembla clar que el que uneix la gent al voltant de Debian és unes idees en relació al programari lliure. De punts de vista sobre altres temes, com ara la geopolítica, cada u té els seus. Debian no té una política definida sobre aquests temes (que jo sàpiga), ni l'ha de tenir. Voler-ho vincular amb el concepte de "inclusivitat" ho veig una mica forçat. Salut.
Re: Format de la data en Buster
2019-07-13, 12:15 (+0200); Robert Marsellés escriu: > Pista? No sé què vols dir. Puc garantir que no estàs sol però. > > Jo he estat usant "testing" (ara buster) + GNOME des de fa ~1 any i > juraria que sempre ho he vist així. Pel que sembla, en algun moment van canviar el local "ca" en el CLDR, de manera que els noms dels mesos ara apareixen en genitiu (precedits per la preposició "de") en lloc de nominatiu (sense preposició) com abans. Després, aquests canvis els van incorporar al local "ca" de la biblioteca GNU Lib C, que és la biblioteca que implementa els locals en els sistemes operatius GNU/Linux. Resulta que ara s'han d'anar adaptant tots els programes, però no és tan fàcil com semblava. Alguns detalls: https://sourceware.org/bugzilla/show_bug.cgi?id=22848 Potser fins que tots aquests problemes no estiguin resolts, seria millor seguir utilitzant la versió anterior del local ca. Per altra banda, he mirat els altres locals i ni l'italià, ni l'espanyol ni el francès tenen els mesos en genitiu, tot i que gramaticalment funcionen igual que el català. Els únics que utilitzen la versió en genitiu són el txec, el grec i el català. Salut
Re: Format de la data en Buster
2019-07-13, 11:29 (+0200); Eduard Selma escriu: > L'odre $ date dóna: > > ds. de jul. 13 11:22:32 CEST 2019 > > Teniu alguna pista? Mira aquest fil d'octubre de 2018 https://lists.debian.org/debian-user-catalan/2018/10/msg0.html Llavors l'Eloi deia que el problema ja estava solucionat a "testing" (actual Buster), però es veu que no està ben solucionat, l'ordre dels elements a la frase segueix estan malament. Salut.
Re: Accents
2019-07- 5, 10:40 (+0200); Jordi escriu: > Efectivament les aplicacions llançades amb GTK_IM_MODULE=gtk-im- > context-simple mostren els accents correctament. Vaig intentar fer els > canvis permanents a /etc/profile però l'única cosa que vaig aconseguir > va ser que a part dels accents també perdés els símbol # i | entre > d'altres. No sé, mai havia tingut tants de problemes amb un "putu" > teclat. Faré l'actualització a Buster i veure que passa. Si em pots > avançar com fer GTK_IM_MODULE=gtk-im-context-simple permanent i global, > t'ho agrairé. /etc/profile només és per sessions "login" de bash, no té cap efecte en altres contexts, com ara quan entres a un entorn gràfic directament sense passar per bash. On ho hauries de posar és a /etc/environment, si no m'equivoco. Salut.
Re: Accents
2019-07- 4, 21:16 (+0200); Jordi escriu: > > Doncs tens rao, a l'xterm els accents si que van be. Pero a la resta > d'aplicacions que faig servir, gnome-terminal, firefox, evolution, > libreoffice, etc etc > no van be. Per aixo he instal·lat Xfce4 que crec, que no es un fork de > gnome2 i pensava que podria tenir una solucio. Sembla que anem pel bon > cami, pero ja se m'escapa. Això sembla indicar que el problema no és del sistema X Window, ja que xterm funciona bé i xterm només fa crides a X, per tant probablement és alguna cosa relacionada amb la biblioteca GTK (tant Gnome com Xfce fan servir GTK) Una cosa que pots provar és obrir alguna d'aquestes aplicacions forçant el mètode d'entrada "simple" i mirar si et deixa escriure accents, per exemple des d'un terminal $ GTK_IM_MODULE=gtk-im-context-simple firefox Salut
Re: Accents
2019-07- 4, 19:18 (+0200); Jordi escriu: > > Després de tancar sessió > > [...] > KeyPress event, serial 28, synthetic NO, window 0x2e1, > root 0x1d9, subw 0x0, time 1068673, (136,87), root:(1621,829), > state 0x2000, keycode 0 (keysym 0xe0, agrave), same_screen YES, > XLookupString gives 0 bytes: > XmbLookupString gives 2 bytes: (c3 a0) > "à"<-- > XFilterEvent returns: False Llavors, entenc que quan prems la tecla d'accent obert i "a" a la finestra de l'xev, el terminal mostra el caràcter "à" correctament, però en aquest mateix terminal quan prems les mateixes tecles mostra "`a" enlloc de "à"? Si és així, en un xterm (no el terminal de Gnome o XFCE), també fa el mateix o va bé? Salut
Re: Accents
2019-07- 4, 10:47 (+0200); Jordi escriu: > > Bones, no hi ha cap diferencia en la sortida de setxkbmap -query entre > la primera sessio i la segona: > > setxkbmap -query > rules: evdev > model: pc105 > layout: es > variant:cat > options:lv3:ralt_switch,terminate:ctrl_alt_bksp > > per`o si que m'he quedat sense accents: `a `e I què diu xev quan prems i deixes anar la tecla d'accent obert "`"? El símbol adequat per aquesta tecla és dead_grave $ xev -event keyboard ... KeyPress event, serial 28, synthetic NO, window 0x401, root 0x4ad, subw 0x0, time 3387497, (325,285), root:(876,721), state 0x0, keycode 34 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XmbLookupString gives 0 bytes: XFilterEvent returns: True KeyRelease event, serial 28, synthetic NO, window 0x401, root 0x4ad, subw 0x0, time 3387536, (325,285), root:(876,721), state 0x0, keycode 34 (keysym 0xfe50, dead_grave), same_screen YES, XLookupString gives 1 bytes: (60) "`" XFilterEvent returns: False Salut
Re: Accents
2019-07- 2, 17:07 (+0200); Jordi escriu: > El problema es el seguent : Primer les lletres accentuades surten be, > pero despres durant el dia es canvien a: `a `e `i `o `u ´a´e´i´o´u > ¨a¨e¨i¨o¨u, no se que fer per poder localitzar el problema, ja que com > dic, al principi va be, pero despres no se perque es canvia. Faig > servir el cinnamon i, o sento, els controladors nvidia privatius. > > A les pantalles F1, F2 ... els accents surten be, i al cinnamon amb > diferents usuaris malament. Alguna ajuda? Mira la sortida de "setxkbmap -query" o "localectl status" en el primer login i si canvia quan surts i tornes a entrar. Per anar bé, t'hauria de dir layout "es" $ setxkbmap -query rules: evdev model: pc105 layout: es variant:cat options:ctrl:nocaps,compose:rctrl Salut.
Re: (deb-cat) Arrencada 'single' sense root login
2019-06-30, 20:30 (+0200); Narcis Garcia escriu: > Per tal d'utilitzar fsck directament (per exemple per a revisar blocs > defectuosos) he provat amb break=mount i em va bé per a utilitzar fsck > des de initramfs sobre les particions, però la comanda poweroff no funciona. És que no té gaire sentit iniciar la seqüència d'apagada quan encara estàs al mig de la seqüència d'arrencada. Potser deixa que acabi d'arrencar (sortint de l'intèrpret amb "exit" o Control-D), i llavors, si de cas, apaga. Salut.
Re: (deb-cat) Arrencada 'single' sense root login
2019-06-30, 18:53 (+0200); Narcis Garcia escriu: > Per a reparar fsck no hi ha més remei, ja que Systemd impedeix l'ús de > l'arrel en només-lectura. Hi ha diverses opcions. Una és arrencar amb l'opció fsck.mode=force https://www.freedesktop.org/software/systemd/man/systemd-f...@.service.html Una altra és fer-ho manualment des de initramfs. https://wiki.debian.org/InitramfsDebug
Re: (deb-cat) Arrencada 'single' sense root login
2019-06-30, 17:15 (+0200); Narcis Garcia escriu: > Si, ja veig que amb init=/bin/bash s'esquiven dos problemes: un > l'esmentat, i l'altre el muntatge de l'arrel amb escriptura que provoca > Systemd. Ara ja sé com utilitzar fsck sobre la partició del sistema, de > forma senzilla, o sense la interferència de Systemd. > La primera pega que he trobat és què la comanda «shutdown» no shuta. Si arrenques amb init=/bin/bash no tens procés init, que és el procés que controla els runlevels, i per tant no pots apagar el sistema de manera correcta. Per aquest motiu el paràmetre init=/bin/bash normalment només es fa servir com a últim recurs, per exemple quan has perdut la contrasenya root. Canvies la contrasenya i surts. No s'hauria de d'utilitzar per fer fscks ni per res més que no sigui arreglar el problema que t'impedeix fer login. Però vaja, cada u que faci el que cregui convenient... Salut.
Re: (deb-cat) Arrencada 'single' sense root login
2019-06-30, 14:58 (+0200); Narcis Garcia escriu: > Aleshores, a Ubuntu ho fan millor quan permeten el mode monousuari sense > contrasenya. Permeten obrir una sessió shell amb UID 0 sense contrasenya, sempre que tinguis accés físic a la màquina. Però això ho permeten totes les distribucions, només has d'arrencar el kernel amb l'opció init=/bin/sh Salut.
Re: (deb-cat) Arrencada 'single' sense root login
2019-06-30, 12:23 (+0200); Josep Lladonosa escriu: > Imagino que a causa d'aquesta "complexitat" inicial (i potser més) sudo no > està implantat (inicialitzat?) en el cas del mode de recuperació imagino > que perquè l'entorn inicial és molt bàsic. Exacte, el mode monousuari és per reparar el sistema en cas de mal funcionament. Per ser efectiu com a eina de reparació no pot dependre de components que no són essencials per fer tasques de recuperació. Els usuaris diferents de root no són essencials per fer aquestes tasques. Sudo tampoc. Salut.
Re: provant debian 10!: swap/file
2019-06-25, 08:44 (+0200); Alex Muntada escriu: > A la feina havia administrat servidors amb molta RAM i algun cop > havíem considerat que no calia posar-los swap. Fins que un dia > un procés es va menjar tota la RAM en pocs segons i el sistema es > va congelar deixant a tots els usuaris del servei penjats. A mi, utilitzant swap, quan algun procés s'ha descontrolat sempre se m'ha congelat el sistema. Es relentitza tot fins al punt que tardes 15 minuts en obrir un TTY i fer login i matar el procés. Val la pena? Jo crec que no, per això ara ja no utilitzo swap. La millor solució és tenir una bona quantitat de memòria de manera que mai et quedis sense (amb 16Gb, em sembla que mai he superat el 20% d'utilització), i en el cas improbable que et quedis sense deixar que l'OOM killer faci la seva feina, i s'ha acabat la història! Salut.
Re: definir temporalment variable per a l'ordre actual
2019-05-16, 17:21 (+0200); Josep Lladonosa escriu: > El que puc aportar és que si es vol un valor de variable permanent després > de sortir de l'embolcall es fa: > > export foo=1; sh > $ echo $foo > 1 > $ exit > $ echo $foo > 1 Sí, però en aquest cas el que volia és el contrari: modificar l'entorn d'aquella ordre en concret i prou. De totes maneres punts extra per utilitzar la paraula embolcall ;) Salut
Re: definir temporalment variable per a l'ordre actual
2019-05-16, 18:11 (+0200); Eloi escriu: > En aquest cas no funciona perquè la comanda echo no està realment > accedint a l'entorn sinó que és el propi shell qui fa la substitució > *abans* d'executar la comanda. Sí, exacte... amb aquest exemple que havia posat no es pot veure si es modifica o no l'entorn. Salut.
Re: definir temporalment variable per a l'ordre actual
2019-05-16, 16:59 (+0200); tictacbum escriu: > foo=1 ; echo $foo > > creac que cal el punt i coma perquè avaluï l'assignació Amb punt i coma és com fer-ho en línies separades, no es destrueix l'assignació: $ echo $foo $ foo=1 ; echo $foo 1 $ echo $foo 1 $ > si crides un script en comptes de echo si que funciona perquè crea una > subshell em sembla.. potser algú sap millor que passa realment Doncs, sí, tens raó... $ foo=1 sh $ echo $foo 1 $ exit $ echo $foo $ pot ser que crei un entorn per al procés fill, però com que echo no s'executa en un altre procés, en aquest cas no fa cap efecte. Salut
definir temporalment variable per a l'ordre actual
Em pensava que si feies una assignació de variable a línia d'ordres seguida d'una ordre, aquella assignació només tenia efecte per a l'ordre en qüestió. Per exemple, segons això, $ foo=1 echo $foo hauria d'escriure "1". Però estic veient que no fa l'assignació... Ha canviat recentment, o és que mai ha funcionat així? Salut
Re: (deb-cat) Preparar retroces en actualizacions
Narcis Garcia writes: > En un ordinador amb Debian (9) Stable hi volia actualitzar un joc, però > resulta que la versió actualitzada només està al repositori «testing». > Si l'habilito (testing) i li faig actualitzar el joc amb apt-get, > aleshores em fa actualitzar altres paquets, que em fa por que > comprometin la Stabilitat de la resta. > > Puc fer algun preparatiu per poder revertir tot plegat després? > > $ sudo apt-get install springlobby > S'està llegint la llista de paquets… Fet > S'està construint l'arbre de dependències > S'està llegint la informació de l'estat… Fet > S'instal·laran els següents paquets extres: > libboost-atomic1.67.0 libboost-system1.67.0 libboost-thread1.67.0 > libc-bin libc-dev-bin libc-l10n libc6 libc6:i386 libc6-dev libcom-err2 > libcom-err2:i386 libcomerr2 libcomerr2:i386 libcurl3-gnutls > libgnutls-openssl27 libgnutls30 libgnutls30:i386 libgssapi-krb5-2 > libgssapi-krb5-2:i386 libhogweed4 libhogweed4:i386 libidn2-0 > libidn2-0:i386 libk5crypto3 libk5crypto3:i386 libkrb5-3 libkrb5-3:i386 > libkrb5support0 libkrb5support0:i386 libnettle6 libnettle6:i386 > libp11-kit0 libp11-kit0:i386 libtasn1-6 libtasn1-6:i386 libunistring2 > libunistring2:i386 libwxbase3.0-0v5 libwxgtk3.0-0v5 locales > p11-kit-modules > Paquets suggerits: > glibc-doc glibc-doc:i386 locales:i386 gnutls-bin gnutls-bin:i386 > krb5-doc krb5-user krb5-doc:i386 krb5-user:i386 > S'instal·laran els paquets NOUS següents: > libboost-atomic1.67.0 libboost-system1.67.0 libboost-thread1.67.0 > libcom-err2 libcom-err2:i386 libidn2-0:i386 libunistring2 libunistring2:i386 > S'actualitzaran els paquets següents: > libc-bin libc-dev-bin libc-l10n libc6 libc6:i386 libc6-dev libcomerr2 > libcomerr2:i386 libcurl3-gnutls libgnutls-openssl27 libgnutls30 > libgnutls30:i386 libgssapi-krb5-2 libgssapi-krb5-2:i386 libhogweed4 > libhogweed4:i386 libidn2-0 libk5crypto3 libk5crypto3:i386 libkrb5-3 > libkrb5-3:i386 libkrb5support0 libkrb5support0:i386 libnettle6 > libnettle6:i386 libp11-kit0 libp11-kit0:i386 libtasn1-6 libtasn1-6:i386 > libwxbase3.0-0v5 libwxgtk3.0-0v5 locales p11-kit-modules springlobby > 34 actualitzats, 8 nous a instal·lar, 0 a suprimir i 2650 no actualitzats. > S'ha d'obtenir 30,1 MB d'arxius. > Després d'aquesta operació s'empraran 28,1 MB d'espai en disc addicional. > Voleu continuar? [S/n] El preparatiu es baixar tots els paquets que necessitis de 'testing' i les versions corresponents de 'stable'. Instal·les els paquests de 'testing' amb el dpkg. Quan vulguis tornar a 'stable', desinstal·les un a un els paquets de 'testing'. Els que satisfan dependències d'altres paquets de 'stable' no els podràs desinstal·lar. Aquests els has de substituir per la versió del paquet de 'stable' que has baixat prèviament. Tot això amb el dpkg, mai apt. Tenint en compte que hauràs d'actualitzar paquets importants del sistema, com el libc, és una mica arriscat si no saps molt bé et que fas. Salutacions. els paquets de 'stable' amb el dpkg utilitzant l'opció per forçar la instal·lació.
Re: (deb-cat) Adreces al descobert a l'hemeroteca de la llista
Narcis Garcia writes: > Us podeu imaginar que, els recolectors d'adreces de correu electrònic > (robots), de ben pocs llocs han pogut obtenir aquesta meva adreça. > Doncs aquest mes ja hi he començat a tenir assetjament publicitari (spam). > > És manifest que, la publicació literal de les adreces de correu a les > pàgines-arxiu de la llista, és molt mala política. Ja ho hem discutit més d'una vegada. L'argument és que, com que tothom (inclosos els robots que recol·lecten adreces) es pot subscriure a aquesta llista i d'aquesta manera obtenir la teva adreça, no serveix de res amagar-la quan es publica a l'arxiu. Per cert, per què poses "(deb-cat)" a l'assumpte dels missatges? No li veig la utilitat. Si és per classificar el correu, la manera de fer-ho és amb les capçaleres List-* o X-Mailing-List. Salutacions.
Re: Em podeu donar un cop de ma amb un bug?
Àlex writes: > Sí així vaig fer. Vaig descarregar el nucli 4.9 de la Debian estable i > el vaig instal.lar, i quan vull veure vídeo arrenco amb aquest nucli. > Des de la versió 4.14 a la 4.19 la cosa ha anat malament i no sé si amb > el temps es corregirà, però sempre puc canviar de hardware gràfic. > > A internet vaig llegir usuaris de Linux amb problemes semblants que > comentaven que encara guardaven la partició de Windows per poder veure > vídeos, i em va sabre greu. A vegades hi ha algun problema, però en general les targetes AMD estan ben suportades a Linux. Un dels motius és que AMD col·labora amb els programadors dels drivers oberts, a diferència d'altres fabricants. Fa bastant temps vaig tenir un problema semblant al teu. Al final els de Xfce em van recomanar que utilitzés el driver X11 "modesetting" en lloc del "radeon", i es va solucionar. Tampoc tinc gaire idea de com funciona el sistema gràfic de Linux, però em sembla entendre que actualment el driver de X11 és un driver genèric per a totes les targetes (el tal "modesetting"), i el driver específic per a cada targeta ara es troba integrat en el kernel. L'usuari no ha de configurar res. Si ho tens de l'altra manera, es van trencant coses perquè els drivers antics de X11 actualment ja no es desenvolupen.
Re: Em podeu donar un cop de ma amb un bug?
Hola, 2019-01-12, 12:40 (+0100); a...@probeta.net escriu: > Fins al nucli 4.13 tot anava bé, però en actualitzar al nucli 4.14 > l’escriptori Gnome es «congelava» cada pocs minuts. A tots els següents > nuclis fins el 4.19 el problema persisteix. A aquest enllaç hi ha els canvis > que aporta el nucli 4.14 a Radeon, però no els sé interpretar: > https://kernelnewbies.org/Linux_4.14#Graphics > > Pista: Es congelava Gnome amb Xorg, però no Gnome amb Wayland > > Pista: no es congelava XFCE > > Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot tornava a funcionar > > Vaig treure Gnome i vaig continuar amb XFCE i amb Mate, però algunes > aplicacions importants es continuen congelant cada pocs minuts: VLC, > Mplayer, Chromium, però no Firefox > > Pista: fent CTRL+ALT+F8 i després CTRL+ALT+F7 tot torna a funcionar > > Pista: no apareix res als logs amb «dmesg», ni als logs de Xorg, ni als > logs de VLC > > Pista potser gran: en realitat he descobert que les aplicacions «no es > congelen». Continuen funcionant bé, però ja no es «dibuixen» a la finestra, > el que fa semblar que l’aplicació «s’ha congelat». Pel que dius, semblaria un problema del compositor, que no actualitza l'estat de la pantalla correctament. Ara bé, si et passa amb Gnome i també amb Xfce, que utilitzen compositors diferents, aleshores m'inclino a pensar que és una altra cosa. > Resum: del kernel 4.14 en endavant, amb targetes gràfiques Radeon, i amb > Xorg però no amb Wayland, alguna cosa fa que aleatòriament les finestres de > VLC, Mplayer, Chromium es deixin de dibuixar («es congelin») malgrat > aquestes aplicacions estiguin funcionant perfectament. Tot torna a funcionar > fent CTRL+ALT+F8 seguit de CTRL+ALT+F7 > > No sé ni per on començar. Algun consell? Els problemes que tenen a veure amb el sistema gràfic són difícils de solucionar pel teu compte, a no ser que siguis un expert en el tema. Si el bug és reproduïble (és a dir es produeix sempre que fas alguna cosa concreta), pots anar provant diferents versions del programari sospitós de causar-lo i veure exactament quina versió introdueix el problema. Amb aquest mètode podries veure fins i tot quina línia de codi és la culpable, però clar, si has d'anar compilant versions i sub-versions del kernel, o de altres components complexos, és una feinada considerable. Probablement és més pràctic tornar a una versió anterior que saps que funciona i posar-la en estat "hold", i esperar que solucionin el problema a les versions més recents. Salut.
Re: (deb-cat) Recuperar directoris
2018-12-18, 19:25 (+0100); Narcis Garcia escriu: > No tinc un espai així de gran on volcar 3TB per fer experiments. No crec que es tracti de fer experiments. Si vols 3TB per emmagatzematge, això vol dir que necessites 6TB. 3TB per les dades i 3TB per la còpia de seguretat. A mi m'ha passat més d'un cop, però al final ho he après. Els discs durs fallen i has d'estar preparat. Salut.
Re: bug a l'X session?
Alex Muntada writes: > Anava a suggerir-te que per aquestes coses provis el shellcheck > però veig que la recomanació que dóna és diferent: > > In gpg-tty.sh line 2: > export GPG_TTY=$(tty) >^-- SC2155: Declare and assign separately to avoid masking return > values. > > No tinc clar si t'hauria ajudat a trobar el problema però a mi > m'ha estat d'ajuda en diverses ocasions fer cas de les seves > recomanacions. Gràcies... no coneixia aquesta eina. Aquest cop ho he trobat activant l'opció set -x a l'inici de l'script. Aquesta opció mostra l'expansió de la línia d'ordres abans d'executar-se, i amb això he vist de seguida on era l'error.
