Prosíme přihlašte se nebo zaregistrujte.

Přihlašte se svým uživatelským jménem a heslem.

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - JirkaZ

Stran: [1] 2
1
Tipy a triky pro Linux / PDF XFA formuláře podruhé
« kdy: 07 Říjen 2021, 23:20:02 »
Navazuji na https://forum.ubuntu.cz/index.php?topic=84928.0 a dodávám dnešní novinku:

Firefox 93 nově umí ve svém interním prohlížeči PDF souborů pracovat s Adobe XFA formuláři. Jinými slovy: kdo je odkázán na bolševika nebo mu dobrovolně leze do zadku, tak má ode dneška šanci zpracovávat jeho slinty nativně v Linuxu...

Nevím sice, jak to v Mozille udělali, ale možná by se tím mohli inspirovat i v Okularu apod. (převzít open source jádro té věci). Ne že bych nahrával nepříteli, ale někdy je ty zprasy nezbytné zpracovat. Linuxový Adobe Reader 9 přitom stále stárne a třeba v nějaké nové verzi či distribuci Linuxu už nepůjde nainstalovat. Widlous verze nějakého AR taky nemusí vždy ve wine fungovat...

Edit:
tak jsem to přidal do KDE bug trackeru: https://bugs.kde.org/show_bug.cgi?id=443472

2
Tipy a triky pro Linux / LibreOffice 7.2.1 rc2 - pozor na něj
« kdy: 20 Září 2021, 21:04:24 »
Tak se mi dnes v rámci aktualizací v Kubuntu 18.04 LTS instalovala i poslední (nestabilní) verze LibreOffice, a to 7.2.1 rc2. Mám mimo jiné přidán PPA s LO fresh a tak je to přirozené.

Až doteď jsem s tím neměl žádné problémy... Dnes jsem si to ale vychutnal: v Draw z ničeho nic nejdou kreslit tvary (ani ikona skupiny tvarů se nezmění na ten příslušně zvolený - kdo chce, může k tomu shlédnout video z přílohy), v Calcu nejde měnit barva písma....

No: dál už jsem to neřešil, PPA změnil na LO still, LO 7.2.1 rc2 odinstaloval a instaloval verzi 7.1.6 rc2. Nevím proč, ale obvykle běžně funkční vynucení verze balíku v Synapticu tentokrát nefungovalo, takže proto odinstalace a instalace starší stabilní verze...

Poučení (a vím to léta, v 99% to dělám, jen ne úplně vždy):
nepoužívat novinky, ať už v hw, nebo sw.

3
Obecná podpora / WINEDLLPATH - jak nejlépe uložit permanentně?
« kdy: 10 Únor 2021, 15:00:25 »
K běhu programu (aby Wine nalezlo potřebné knihovny) potřebuju nastavit systémovou proměnnou WINEDLLPATH.

Jednorázově (do rebootu) to bez problémů jde příkazem

Kód: [Vybrat]
export WINEDLLPATH="/usr/lib/i386-linux-gnu/wine/"
Jak toto nastavení ale udělat permanentní?

Četl jsem mj. návrh na přidání do souboru /home/uzivatel/.bashrc - je to správně? Pokud ano, tak se prostě do něj přidá řádek s výše uvedeným obsahem, nebo je to nějak jinak?

Případně má někdo jiné návrhy na permanentní nastavení WINEDLLPATH?

Díky

4
Potřeboval bych zase po dlouhé době poradit, bohužel s M$ bazmekem zvaným Teams, ale nevybral jsem si to dobrovolně, ani se to nenalézá přímo u mě, takže tím se předem omlouvám za případný komunikační šum...

O co jde: pokud v mailovém klientovi ve Widlows kliknu na doručený odkaz na schůzku, tak se mi otevře www browser a v dalším okně se objeví dotaz, zda chci browseru povolit otevřít ten odkaz přímo v Teams. Je to docela pochopitelné, protože mrtwošrot Bůh ví proč nezvolil separátní protokol (formát odkazu), ale je to běžný URL ve tvaru https://teams.microsoft.com/l/meetup-join....atdblebleble

Když totéž udělám v Ubuntu, pouze se otevře www browser a v něm je dotaz, zda chci instalovat Teams (přestože ten už je nainstalovaný). V samotné aplikaci Teams přitom netuším, kam link na schůzku vložit (přes schránku) - tedy pokud to vůbec jde...

Evidentně v Ubuntu chybí nějaká vazba přes MIME či něco podobného.

K problému jsem zatím našel tyto dva prameny:

https://github.com/IsmaelMartinez/teams-for-linux/issues/47

https://docs.microsoft.com/en-us/answers/questions/5713/how-to-join-teams-meetings-from-linux-client.html

Doposud jsem nic z tam navrhovaných postupů nezkoušel (jak píšu výše, tak nejde o moje zařízení a tak k tomu teprve dojde), nicméně uvítám už teď konkrétní zkušenosti někoho odtud.

Díky.


6
Tímto příspěvkem navazuji na https://forum.ubuntu.cz/index.php/topic,85086.msg571864.html#msg571864 a předkládám workaround. Úmyslně to nazývám takhle, protože podle mě fakt není normální, aby systém za pár dnů vygeneroval kern.log a syslog o velikosti řádově 10GB... Jen ještě poznamenávám, že problém se projevil jak v Kubuntu 20.04 LTS, tak v Xubuntu 20.04 LTS (jiné odnože jsem netestoval).

Tedy: např. podle https://askubuntu.com/questions/184949/how-do-i-limit-the-size-of-my-syslog (sekce "Limit the size of the current syslog") se dá upravit velikost ukládaných logů. Funguje to tak, že pokud by velikost měla přesáhnout nastavenou mez (je udávána vždy v Byte), tak rsyslog už nic neukládá. Úpravy logrotate by v tomto případě moc nepomohly, protože je té bejkárně třeba zatnout tipec hned u kořene (prostě aby ty obří soubory vůbec nevznikaly)...

Konkrétní příklad pro omezení velikosti souborů kern.log a syslog na 1 MB (1048576 B):


Původní soubor etc/rsyslog.d/50-default.conf_original (takto se nazývá po přejmenování coby záložní a je zde pouze počáteční část, které se to týká):
Kód: [Vybrat]
#  Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log

Upravený soubor etc/rsyslog.d/50-default.conf (opět pouze počáteční část, které se to týká):
Kód: [Vybrat]
#  Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.* /var/log/auth.log
$outchannel mysyslog,/var/log/syslog,1048576
*.*;auth,authpriv.none  :omfile:$mysyslog
#*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
$outchannel mykernlog,/var/log/kern.log,1048576
kern.*  :omfile:$mykernlog
#kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log

Pro názornost je v příloze i screenshot z porovnávače (tam jsou vidět celé obsahy).

V praxi bych uvažoval o omezení velikosti na cca desítky až max. málo stovek MB. Ale: je to tak, že když je systém OK, tak logy mají stovky kB a naopak když není OK, tak rostou "nade všechny meze" a omezením výše se pouze předejde přeplnění HDD/SSD, logy samotné jsou spíš k ničemu...

Jiným možným řešením zcela "natvrdo" pak je odinstalace balíčku rsyslog, který zajišťuje logování. Ortodoxním linuxákům se to právem nebude líbit, ale upřímně řečeno na desktopu si člověk logy prohlíží jen málokdy (BFU vůbec nikdy), takže to za určitých okolností může být jednoduchá možnost, jak se zbavit potíží...

7
V návaznosti na https://forum.ubuntu.cz/index.php/topic,85086.msg571864.html#msg571864 jsem po mnoha dalších pokusech dospěl k názoru, že problém bude v KDE Plasma, možná i v kombinaci s konkrétním PC. Takže jsem nainstaloval Xubuntu 20.04...

Zatím většina věcí funguje. Co se možností nastavení týče: není to taková hrůza (to v Lubuntu, které jsem taky zkoušel, nejde nastavit skoro nic), ale co mě fakt vytáčí, je požadavek na heslo po jakémkoliv zafungování display power managementu, screensaveru apod.

Používám https://docs.xfce.org/xfce/xfce4-power-manager/preferences#security (mimochodem: aby tam byla karta security, tak je nutno doisnstalovat balíček light-locker). Ať si hraju s jeho nastaveními jakkoliv, tak se vždycky po znovuzapnutí displaye objeví požadavek na zadání hesla.

Jak to odstranit?

Po zapnutí mám nastavené přihlašování bez hesla, to funguje normálně...

Za léta práce s KDE jsem odvykl takovým potížím, ale tady ho holt asi používat nemůžu...

Díky za smysluplné odpovědi.

8
O fóru / Firefox - 403 Forbidden
« kdy: 08 Červenec 2020, 12:17:04 »
Od cca půlnoci ze včerejška na dnešek mám problém s přístupem na toto fórum. Projevuje se to pouze v jednom konkrétním Firefoxu (62.0.3 64 bitů) na Kubuntu 18.04. Hláška je "403 forbidden".

Nepomohlo smazání cache, cookies, ani selektivní smazání přihlašovacích údajů. Nepomohl ani test se zakázanými doplňky.

Jiné browsery na stejném PC, případně Firefox a jiné browsery na jiných PC (ze stejné IP adresy) jsou OK. Už delší dobu se mi totéž děje na fóru Linux Mint (https://forum.linux-mint-czech.cz/).

Není to nějaké opatření na serveru odmítající tuto konkrétní verzi FF? Pokud ne, co s tím (kromě změny verze FF)?

Díky.

9
Po delší době zase mám dotaz, nebo spíš podnět k diskusi...

Na ntb se SSD jsem zkusil instalovat Kubuntu 20.04 LTS a to tak, že / je jeden oddíl ext4 (sda1), /home další oddíl ext4 (sda2) a /swap je jako poslední. Swap bych na SSD normálně nepoužil, ale ntb má málo RAM, takže je nutný a ošetřilo se to pomocí vhodného nastavení hodnoty swapiness.

Oddílu / jsem vyhradil 14 GB v bláhové naději, že to bude stačit (podotýkám, že jde o standardní instalaci pouze s několika málo přidanými nenáročnými programy). Vždycky dříve to v Kubuntu tak fungovalo, dokonce tuším cca s poloviční velikostí....

No, rozežranost dnešního sw nicméně nezklamala a po cca druhé či třetí aktualizaci systém už nenabootoval, protože těch 14 GB je prostě málo a disk byl plný. Pro základní oživení pomohlo purge ze záchranného režimu, nicméně na / nyní zbývá pouze cca 760 MB, takže nepoužitelné...

Nyní k věci: jde bez přeinstalace systému zvětšit velikost / (sda1) ? Můžu zmenšit /home (sda2) a vytvořit tak volné místo, ale myslím, že třeba takový Gparted nedokáže volné místo přesunout na jiný oddíl...

Nějaké užitečné nápady?

Díky.

Update 7.7.2020:

tak příběh se opakoval, přestože jsem mezitím zvětšil systémový oddíl na "pouhých" 33,3GB. Příčina? Opět zcela zaplněný systémový disk.

No a příčina příčiny?

Jsou dvě a jmenují se /var/log/kern.log a /var/log/syslog.1, upřesnění je zřejmé z obrázku v příloze. Jak můžou log soubory při běžném a bezproblémovém cca dvoutýdenním využití (a to zdaleka ne každodenně) nabýt takové velikosti, to vědí asi jen v Canonicalu...

Už jsem nechtěl věc zkoumat pomocí tail apod., takže oba šly pomocí live do pryč a vše budu nadále sledovat a analyzovat... Jo a tady

https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/115774

je hlášený bug, přičemž v https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/115774/comments/39 se píše, že přetrvává i v *buntu 20.04...

10
Tak se zase po delší době ocitám v roli tazatele...

O co mi jde: viz http://www.electroons.com/blog/know-how-using-wilar-sp200s-enhanced-device-programmer/#comment-3810904583

z toho cituji:

Citace
You must write two scripts and make links to serial port.
If you are familiar with Linux, you will understand when you read bellow :

root@Lenovo-G40-30:~# cat ~/.bin/willar

#!/bin/bash
if [ -e /dev/ttyUSB0 ]
then
/root/.bin/setserial.py
exec wine '/root/.wine/drive_c/Program Files/WLPRO_V220_SETUP/WLPRO.exe'
else
echo "Error : /dev/ttyUSB0 not exist"
fi

root@Lenovo-G40-30:~# cat ~/.bin/setserial.py

Nemůžu si pomoct, ale:

1) kde tam jsou nějaké dva skripty? Vidím jeden...

2) kde tam jsou nějaké (sym?)linky na sériové porty?

3) kde v Kubuntu 18.04 vezmu program setSerial.py? Že by existoval jen v Ubuntu 16.04? Mám instalovaný Python 2.7.17 a balík python-serial 3.4.2.

Nevím, zda jsem zmatený já, nebo autor příspěvku... Připouštím to první, protože - marná sláva - pořád i po letech jsem jen "předělaný DOSák a Windowsák" ;-)

Díky za konkrétní rady.

11
Dnes jsem objevil něco pro "hračičky" (možná někteří budou znát):

https://distrotest.net

Vzdáleným přístupem se na onom serveru spustí QEMU a v něm zvolená distribuce...

Je to tak trochu jak "ze snu", prostě virtuální live Linux v okně prohlížeče ;-)

Samozřejmě, reakce jsou pomalé a obraz rozmazaný, nicméně pro zcela základní náhled na to, jak dotyčná distribuce vůbec vypadá, to stačí. Takto si lze "předvybrat" třeba před tím, než budu stahovat live verzi...

Edit: rozmazaný obraz lze odstranit nastavením VNC klienta (menu pod šipkou vlevo na obrazovce s virtuálním OS) na Nastavení => Přizpůsobení velikosti => Vzdálené. Rozlišení se pak přizpůsobí a nedochází k rozmazání obrazu převzorkováním...

12
Hardware / AMD Ryzen 5 a Ubuntu (nebo obecně Linux)
« kdy: 20 Leden 2020, 10:48:56 »
Provozoval jsem kdysi AMD (K6-2 450), pak přešel na Intel a od té doby po několik generací CPU a MB žádná změna...

Teď potřebuju zkompletovat jedno nové lepší kancelářské PC, přičemž a) Intely Core i5-8400 (co bych chtěl) moc nejsou, b) se u Intelu objevuje jedna bezpečnostní chyba za druhou.

Začal jsem tedy pošilhávat po AMD a jako logická volba mi vychází AMD Ryzen 5.

Provozuje to někdo s Ubuntu, popřípadě jinou linuxovou distribucí? Pokud ano, s jakou základní deskou (vybírat budu něco od Asusu, Gigabyte nebo MSI)?

Ptám se hlavně proto, že jsem našel dost informací zmiňujících různé problémy typu "Linux vůbec nelze nabootovat", "chce to aktualizaci na nejnovější BIOS" apod.

Neřešme zde výkon apod. (poradím si sám), jde mi skutečně jen o problematiku AMD versus Linux.

Díky za věcné odpovědi a zejména konkrétní zkušenosti.

13
Obecná podpora / Viditelnost HDD apod. v Linuxu a Windows
« kdy: 25 Prosinec 2019, 23:22:09 »
...vsetko je v poriadku,toto malé nedorozumenie medzi linux a win som vyriesil davno...má to jednoduché riesenie...nehladajte ani vo filesysteme,ani v názvoch...zalohy fotiek neni surné vyriesit,a som zvedavy na vase riesenia a napady... :o :o :o
...tak hladajte dalej...buduci tyzden dam foto...pokial disk ale nebude vytvoreny vo win,bude pouzitelna len v linuxe,a vo win budu len odkazy...bude vytvoreny vo win,bude pouzitelny v obidvoch OS...
...juwa-tu teraz neriesime oddiely,ale pouzitelnost disku v oboch OS...... :o :o :o
...chyba sa stala vtedy,ked HDD bolo vytvorene v linuxe...ako vieme od zaciatku-linux vidi win,aleee win nevidi linuxa...HDD treba vytvorit vo win,a bude šecko oké...pritom ked pozres v gparted win tam spravi taky maly oddielik,ty to tam nemas...pozri pred vytvorenim v gparted terajsie rozlozenie,potom ked HDD vytvoris vo win,zas pozri...bude rozdiel,ale HDD bude fungovat v obidvoch OS...mám pár takych diskov zámerne spravenych... ;D ;D ;D

Tak jsem se jen chtěl přesvědčit, jak velká je tohle pitomost - pochopitelně při respektování obecně známé skutečnosti, jak to je s viditelností či spíš použitelností filesystémů v obou zmiňovaných OS (Linux vs. Windows).

Vzal jsem zcela nový USB SSD Transcend (240GB), výrobcem formátovaný jako jeden oddíl ve fs exfat. V Kubuntu 18.04 jsem otevřel Gparted, celý exfat oddíl smazal a místo něj vytvořil a zformátoval dva primární NTFS oddíly s názvy enteefes_01 a enteefes_02.

Následně jsem SSD sw i hw odpojil, restartoval PC, nabootoval do Windows 7, SSD fyzicky připojil a otevřel složku disků. Oba pokusné oddíly na SSD jsou pochopitelně vidět zcela bez problémů, viz obrázek.

Zcela stejně by to dopadlo s řadou dalších formátů, viz přehled na konci.

Takže citované je dle očekávání skutečně úplná blbost. Ono totiž samozřejmě nejde o to, kde (v jakém OS) ten disk vytvořím, ale jaký pro onen disk použiju filesystem... Čili psát "disk vytvořený v..." je nonsens, protože je nutné napsat "disk s filesystémem xyz...".

Abych to ještě konkretizoval pro BFU: Linux je dnes schopen nativně pracovat s naprostou většinou běžně používaných filesystémů, Windows bez dalších speciálních programů se pak tváří, že existují jen FAT, FAT32, EXFAT nebo NTFS.

Jinak řečeno: pokud nejsem blb a nepředpokládám nativní použitelnost ext, reiserfs a jiných linuxových filesystémů ve Windows, pak nemám problém.

Blíže viz třeba https://en.wikipedia.org/wiki/Comparison_of_file_systems#OS_support

14
Hardware / Programátor TL866 v Linuxu
« kdy: 16 Prosinec 2019, 22:21:54 »
Na základě dobrých referencí jsem se rozhodl koupit čínský programátor a tester TL866, konkrétně v poslední verzi - tedy TL866II Plus. Samozřejmý požadavek pro mě byl, aby ovládací software pracoval v Linuxu. Když ne nativně, tak alespoň pod Wine, u mě pak v Kubuntu 18.04 LTS 64bit.

Přístroj dnes dorazil. Pominu-li skutečnost, že k pořizovací ceně cca necelých 2.600,- Kč (programátor + 15 adaptérů) si ještě sosnul přepravní globalizátor necelých 600,- peněz (za pár kliknutí nazvaných "zajištění proclení") a více než 600,- peněz bolševik (za DPH), tak jinak proběhlo vše OK.

32bitový ovládací software Xgpro verze 9 je k dispozici zdarma na stránkách výrobce. Při kontrole přes Virus Total se u něj sice objevuje několik (cca 3 z více než 60?) pozitivních výsledků, ale jde převážně o nějaké okrajové antiviry, takže snad planý poplach... Instalační program nabízí výběr umístění pracovního adesáře. Po instalaci se vytvoří pracovní adresář (defaultně nazvaný xgpro9), v něm je kromě jiného i vlastní ovládací program. Zdá se, že ovládací program je schopen funkce i při prostém zkopírování či přesunu celého pracovního adresáře jinam, než se původně instaloval. Z toho vyvozuji, že by (možná) fungoval i jako portable...

Ovládací progam (alespoň zatím) běží zcela bez problémů pod Wine 3.0-1 (32bit). K úspěšné funkci je po instalaci ještě třeba udělat dvě věci:

1) do pracovního adresáře programu (zde tedy výše uvedený xgpro9) je nutné nahrát knihovnu setupapi.dll (viz odkazy na konci tohoto příspěvku)

2) pro přístup k USB rozhraní programátoru je nutné vytvořit soubor /etc/udev/rules.d/51-minipro.rules s obsahem
Kód: [Vybrat]
SUBSYSTEMS=="usb", ATTRS{idVendor}=="a466", ATTRS{idProduct}=="0a53", GROUP="plugdev", MODE="0666" a restartovat PC, nebo alespoň udev příkazem
Kód: [Vybrat]
sudo udevadm trigger Uživatel by přitom - jak plyne z kódu - měl být ve skupině plugdev.

Poznámka: postup vytvoření /etc/udev/rules.d/51-minipro.rules uvedený na stránce dole - cituji:

Add the following rule to the udev subsystem:
open terminal and as root type:
#echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="a466", ATTRS{idProduct}=="0a53", GROUP="plugdev", MODE="0666"' > /etc/udev/rules.d/51-minipro.rules


nefunguje!

Co funguje, je třeba toto:

Kód: [Vybrat]
echo 'SUBSYSTEMS=="usb", ATTRS{idVendor}=="a466", ATTRS{idProduct}=="0a53", GROUP="plugdev", MODE="0666"' | sudo tee -a /etc/udev/rules.d/51-minipro.rules
Nebo lze soubor vytvořit klasicky (třeba rootovským správcem souborů) a do něj doplnit výše uvedený obsah. Možností je víc, nemá smysl zde uvádět všechny...

Jediné, co mi pod Wine nefunguje, je spuštění kalkulátoru jeho ikonou v ovládacím programu. Zatím jsem to nestudoval blíž, ale pravděpodobně se má spustit kalkulačka z Windows (?), což ve Wine samozřejmě nativně chybí...

Edit: ano, stačí do /home/uzivatel/.wine/drive_c/windows/ přidat calc.exe (ona kalkulačka z Windows). A nemusí to být ani MS originál - funguje třeba open source Precise Calculator z http://preccalc.sourceforge.net/download.shtml , kde se preccalc.exe přejmenuje na calc.exe a vše včetně příslušných složek a jejich obsahu se opět přidá do /home/uzivatel/.wine/drive_c/windows/.

Stránka výrobce: http://www.autoelectric.cn/en/tl866_main.html

Stránka výrobcem doporučovaného dealera (spíš též výrobce?): http://www.xgecu.com/en/TL866_main.html

Edit:  aha, ona to bude jedna a ta samá firma, jen prostě má stránky po dvěma různými doménami...

Stránka autora úprav pro běh na Linuxu: https://github.com/radiomanV/TL866 a konkrétněji pro popisovaný model pak https://github.com/radiomanV/TL866/tree/master/wine/TL866II

15
Používal jsem docela dlouho tuto barevnou laserovku v Kubuntu 14.04. Od počátku jsem musel řešit dilema mezi dvěma možnými způsoby instalace:

1) ovladač hplip (ať už z normálních repozitářů, nebo ze stránky autorů https://developers.hp.com/hp-linux-imaging-and-printing) + následná instalace proprietárního pluginu: program je sice značně velký jako nakonec cokoliv od nějakého globalizátora (údajně to má na svědomí dnešní "klikací" způsob programování a nezájem o datovou úspornost), na druhou stranu ale má spoustu možností nastavení tiskárny, vlastní diagnostiku atd. Tiskový výstup má i geometricky (míním tím rasterizaci) dobrou kvalitu, ale všechny barvy jsou posunuté do zelena. Nikde jsem nenašel způsob, jak to řešit...

2) ovladač foo2zjs (http://foo2zjs.rkkda.com/) - vše funguje, výstup je barevně neutrální, ale možností nastavení tiskárny je mnohem méně a rasterizace je bohužel nevyhovující (někdy až moiré efekty ve větších jednobarevných plochách apod.). Navíc u tohoto ovladače se mi pravidelně stávalo, že tiskárna po tisku prvního dokumentu přestala přijímat další úlohy a pomohlo buď vytažení a zasunutí USB konektoru, nebo celkový reset. V hledání či vymýšlení nějakého řešení jsem nebyl úspěšný (po pravdě jsem to zase až tak "nehonil")...

Až teď s přechodem na Kubuntu 18.04 a opakováním výše popsaných problémů s hplip mě napadlo oba ovladače zkombinovat. Jak? No, normálně nainstalovat hplip a v jeho nastavení pak upravit nastavení tiskárny tak, že bude využívat *.ppd soubor z foo2zjs ;-)

Výsledek? Překvapivě kvalitní tisk, zachoval si všechny dobré vlastnosti z hplip, ale jako bonus zmizel ten nádech do zelena... Skoro bych řekl, že kvalita tisku fotek je srovnatelná s nějakým průměrným inkjetem - to je u laseru co říct, přitom používám "alternativní" toner od Tonersypu...

16
Po přechodu z Kubuntu 14.04 na Kubuntu 18.04 mi možná nejvíc vadí jedna věc, a to je doslova děsivé grafické téma zvané Breeze... Bohužel je v Plasmě 5 jako defaultní a prostě to nejde změnit (myslím tím úplně odinstalovat a nahradit něčím normálním), jen v určitých případech se to dá nějak ovlivnit.

Tuhle skutečnost vymyslel nepochybně nemocný člověk (a spousta dalších mu z neznámých příčin tleská), ale to teď nebudu rozebírat.

K věci:

Za normální téma považuju třeba Oxygen (díky tvůrcům, že stále žije).

První na řadě byl Synaptic. Současný Synaptic v Kubuntu používá nastavení GTK3 aplikací (dříve to bylo GTK2), ale pro root práva. Definiční soubor je /root/.config/gtk-3.0/settings.ini a lze ho přepsat souborem /home/uzivatel/.config/gtk-3.0/settings.ini (tedy souborem pro uživatelské nastavení chování GTK3 aplikací v KDE).

Momentálně mi není zcela jasná vazba na instalovaná témata GTK3 pro roota - zejména ale jde o to, aby v /root/.config/gtk-3.0/settings.ini nebyly nastaveny volby Breeze. Synaptic pak použije svoje vlastní, docela podařené ikony.

Původní (škodlivý) soubor může vypadat takto:

Kód: [Vybrat]
[Settings]
gtk-font-name=Noto Sans 10
gtk-theme-name=Breeze
gtk-icon-theme-name=breeze
gtk-fallback-icon-theme=gnome
gtk-toolbar-style=GTK_TOOLBAR_ICONS
gtk-menu-images=1
gtk-button-images=1
gtk-primary-button-warps-slider=0

a nový (upravený, resp. zkopírovaný postupem popsaným výše) třeba takto:

Kód: [Vybrat]
[Settings]
gtk-application-prefer-dark-theme=false
gtk-button-images=1
gtk-cursor-theme-name=Breeze_Snow
gtk-fallback-icon-theme=gnome
gtk-font-name=Ubuntu Regular 10
gtk-icon-theme-name=oxygen
gtk-menu-images=1
gtk-primary-button-warps-slider=0
gtk-theme-name=Default
gtk-toolbar-style=GTK_TOOLBAR_BOTH

Přidávám screenshot Synapticu s původními idiotskými ikonami Breeze a nově po změně tak, aby mohl používat svoje vlastní, které má (resp. po své instalaci si je přidá) v /usr/share/icons/hicolor/ a příslušných podadresářích (podrobněji viz třetí screenshot).

Další k řešení byl Krusader. Jak známo, tak jako jeden z mála souborových správců umožňuje i v Kubuntu 18.04 spuštění jako root (má to přímo v menu).

O vhodnosti či nevhodnosti spouštění GUI aplikací pod rootem se vedou rozsáhlé diskuse. Odpůrci argumentují "bezpečností", z čehož se dnes už stala zhovadilá obsese či buzzword (stejně to nikdy nejde vyřešit 100% a umřeme nakonec všichni). Ale to zase nebudu momentálně víc rozvádět; faktem je, že zásahy s root právy jsou čas od času potřeba a já jsem si prostě za léta s Linuxem zvykl, že mi k tomu Krusader poskytuje příslušný komfort.

Nicméně ve správcovském režimu má v Kubuntu 18.04 defaultně opět tu hrůzu Breeze.  V distribuci nezaložené na Debianu (třeba openSUSE) bych si prostě spustil root relaci a tam nastavil prostředí KDE, což by ovlivnilo všechny KDE aplikace spouštěné s root právy. Ale co v Kubuntu?

Tentokrát jsem řešení nevymyslel převážně sám (jako u Synapticu), ale našel hotový postup na https://forum.kde.org/viewtopic.php?f=225&t=140091 .

Z toho vybírám podstatu:

1) v konzoli napsat a "odentrovat"

Kód: [Vybrat]
sudo kwriteconfig5 --file /root/.config/kdeglobals --group Icons --key Theme oxygen
(taky by se ta změna dala v souboru /root/.config/kdeglobals udělat editorem, ale takhle je to jednodušší a rychlejší)

2) smazat soubor /root/.cache/icon-cache.kcache

čímž by mělo být hotovo a Krusader s root právy (pochopitelně přinejmenším po jeho vlastním restartu) zase vypadá normálně...

17
Tipy a triky pro Linux / Instalace Eagle 6.6.0 do Kubuntu 18.04 LTS
« kdy: 07 Květen 2019, 20:23:31 »
Jsem letitým uživatelem a majitelem licence k návrhovému SW Eagle. Verze jsem postupně několikrát upgradoval až do doby, než začali experimentovat s cloudem, pravidelně placeným pronájmem licence a podobnými hrůzami. To mě přimělo zůstat u verze 6.6.0...

Ta šla zcela bez problémů instalovat a provozovat v Kubuntu 14.04 LTS. Problém nastal po přechodu na Kubuntu 18.04 LTS. Při pokusu o novou instalaci (nebo zkopírování staré) se objevily hlášky typu

Kód: [Vybrat]
Ensure the following libraries are available:
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found

nebo

Kód: [Vybrat]
./eagle: symbol lookup error: ./eagle: undefined symbol: CRYPTO_num_locks
Po kratším hledání a úvaze jsem si potvrdil, že problém způsobuje nepřítomnost staré knihovny libssl.1.0.0, přičemž nepomáhá ani vytvoření symlinků na novější verzi (libssl.1.1) - to vyvolá onu druhou chybovou hlášku.

Řešením je doinstalace naštěstí stále existující knihovny libssl1.0.0_1.0.2n-1ubuntu5.3_i386.deb (viz https://pkgs.org/download/libssl1.0.0). I na 64bit systému přitom je nutné použít 32bit verzi, protože Eagle 6.6.0 je 32bit aplikace.

Konkrétní odkaz k datu editace tohoto příspěvku je https://ubuntu.pkgs.org/18.04/ubuntu-updates-main-i386/libssl1.0.0_1.0.2n-1ubuntu5.3_i386.deb.html resp. přímo balíček http://archive.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5.3_i386.deb - časem se adresa pochopitelně může změnit či úplně zaniknout.

18
O fóru / Nejdou vkládat přílohy do příspěvku
« kdy: 30 Duben 2019, 11:34:55 »
Normálně napíšu odpověď na příspěvek (update: nebo zkusím založit nové téma) a při pokusu o vložení obrázku do přílohy (png, desítky kB) dostanu pokaždé hlášku:

"Není možno přistoupit k adresáři s přílohami!"

Práva k dotyčnému adresáři jsou přitom OK (jde o standardní pracovní plochu).

Prostý text odpovědi (bez příloh) lze uložit normálně. Problém jsem poprvé zaregistroval dnes, ale je možné, že už existuje déle (naposledy jsem posílal přílohu cca před několika měsící)...

Díky za odpověď/vysvětlení.

19
Tipy a triky pro Linux / Spojení několika videí do jednoho
« kdy: 12 Únor 2019, 14:24:14 »
Možná nesu dříví do lesa, ale potřeboval jsem narychlo spojit několik videí do jednoho a ověřil jsem přitom následující, zcela triviální postup s pomocí programu ffmpeg:

1) všechna videa nakopíruju do jednoho adresáře

2) změním názvy na souvislou vzrůstající číselnou řadu (např. v Krusaderu Soubor -> přejmenovat více položek a příslušné postupy). Změna názvu není nutná - jde o to, aby se videa ve výsledku správně časově  seřadila, nejlépe vyzkoušet, případně prohlédnout soubor mylist.txt zmiňovaný dále.

3) příkazem (v konzoli otevřené v adresáři s videi - třeba v Krusaderu, když stojím v popisovaném adresáři, tak Nástroje -> Spustit zde terminál nebo rovnou tlačítkem F2):
Kód: [Vybrat]
printf "file '%s'\n" ./*.mp4 > mylist.txtvytvořím seznam s názvem mylist.txt

4) příkazem (ve stejné, stále otevřené konzoli):
Kód: [Vybrat]
ffmpeg -f concat -safe 0 -i mylist.txt -c copy output.mp4spojím všechna videa z adresáře a ze seznamu do jednoho s názvem output.mp4

Předpokladem je nainstalovaný program ffmpeg. Příklad je pro videa *.mp4 (nejčastěji z mobilu), ale funguje i pro jiné formáty. V příkazech je pak pochopitelně nutno změnit extenzi
Kód: [Vybrat]
mp4 na jinou (aktuální). Videa musejí být ve stejném rozlišení a orientaci (opět typicky pro několik videí natočených v různých okamžicích stejným zařízením). Prostě když chci z jednotlivých záběrů udělat "film"...

Zdroj: https://trac.ffmpeg.org/wiki/Concatenate

Celá věc se pochopitelně dá udělat i v nějakém grafickém videoeditoru, ale když chci rychlý a jednoduchý postup, tak dva příkazy v konzoli (které by se dokonce zřejmě daly sloučit do jednoho) jsou bezkonkurenční.

20
Obecná podpora / PF 2019
« kdy: 31 Prosinec 2018, 14:07:04 »
Všem PF 2019....jistou ruku a přesnou mušku.

21
Obecná podpora / Ubuntu (Kubuntu) a scannery Epson - ŘEŠENÍ
« kdy: 14 Září 2018, 11:54:48 »
Kdyby se někomu přihodilo, že má scanner Epson a nefunguje mu s oficiálními drivery v novějších verzích *buntu (pravděpodobně 17.x a 18.x), tak viz https://www.linuxexpres.cz/hardware/skenery-epson-v-linuxu#post28667.

Pro jistotu zde cituji tam uvedený postup:

1) instalace driverů: na http://download.ebz.epson.net/dsc/search/01/search/ (tam zvolit typ a OS) je ke stažení *.tar.gz, který se rozbalí (kdovíproč?) do složky s názvem *.deb. V ní mimo jiné je skript install.sh, který se dá spustit. ALE: v Kubuntu 18.04 mi skript ANI OMYLEM nenainstaloval příslušné tři balíčky, přitom nic nehlásil... Stav instalace lze ověřit třeba Synapticem nebo jiným správcem systému.

Řešení: osamostatnit ony tři *.deb balíčky z hlavní složky a podsložek a nainstalovat je ručně (v konzoli nebo některou grafickou aplikací, jak je popsáno výše).

2) ani po úspěšné instalaci driverů scanner nefunguje, přestože pomocí lsusb je vidět. Nefunguje ani pod rootem (ani xsane, ani skanlite, ani iscan). Po zadání do velkého bratra vyskočilo toto: https://askubuntu.com/questions/1034528/epson-gt-s50-scanner-not-working-after-upgrade-to-18-04-from-16-04

Řešení z uvedeného odkazu funkční i pro V200 Photo (nutno použít krok a a následně b, pak restart PC):

a) vytvořit symbolický odkaz příkazem v konzoli

Kód: [Vybrat]
sudo ln -sfr /usr/lib/sane/libsane-epkowa* /usr/lib/x86_64-linux-gnu/sane
b) v adresáři /etc/udev/rules.d/ vytvořit soubor s názvem 55-epson-libsane.rules a tímto obsahem:

Kód: [Vybrat]
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE=="0666"
SUBSYSTEM=="usb_device", MODE=="0666"

ATTRS{manufacturer}=="EPSON", DRIVERS=="usb", SUBSYSTEMS=="usb", ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="*", MODE="0666"

ATTRS{idVendor}=="04b8", ATTRS{idProduct}=="0137", MODE="0666", GROUP="scanner", ENV{libsane_matched}="yes"

Pak už by mělo všechno fungovat normálně. Jen je zajímavé, že vyhledávání scanneru trvá mnohonásobně déle, než v 14.04 (ale to může být spuštěním systému z externího USB HDD namísto standardního interního SSD)...

22
Obecná podpora / LibreOffice 5.4.5 a soubory mimo /home/user
« kdy: 27 Únor 2018, 12:45:45 »
Tentokrát píšu nikoliv otázku, ale rovnou radu ;-)

Kdyby se někdo divil, proč mu po update LibreOffice na poslední stabilní verzi 5.4.5 nejde otevírat žádný soubor, který je mimo /home/user (je tedy třeba na externím disku, na usb klíčence, na ntfs partition interního disku, v jakémkoliv jiném adresáři domovské partition než /home/user (i když se změněnými právy!) apod.), tak je to opět spíš feature a nikoliv bug.

Prostě pomatený vývojář usoudil, že v Linuxu přece všechna uživatelská data jsou v /home/user a nic víc neřešil. Nápadně mi to připomíná doby, kdy opravdu neexistovalo nic než Windows, Windows nebo Windows, jen v obráceném smyslu.

Důvod problému: může za to AppArmor a jeho nastavení pro LibreOffice.

Workaround, než se vynuceně opravená verze LO dostane do repozitářů: https://bugs.documentfoundation.org/show_bug.cgi?id=115987 a tam citované prameny.

Neboli: v konzoli napsat a odeslat

Kód: [Vybrat]
sudo ln -s /etc/apparmor.d/usr.lib.libreoffice.program.* /etc/apparmor.d/disable/

23
Rád bych zjistil, jak na tom u jiných uživatelů je Skypeforlinux verze vyšší než 8.11.0.4 na Kubuntu 14.04 LTS... Mně osobně nefunguje nic od verze 8.13.0.2 včetně a výše (tedy momentálně ani 8.14.0.10 a 8.15.0.4).

Aplikace se "nějak" spustí, ale k dispozici je pouze bílé okno s nabídkou nahoře, kde se při jednotlivých volbách neděje vůbec nic. Jako perlička na dortu pak vyskakuje hlášení o pádu aplikace... Případně mohu doplnit screenshot, ale myslím, že to je celkem zbytečné.

Poslední funkční verze z řady 8 je výše zmíněná 8.11.0.4. Zkoušel jsem i ručně mazat profily atd. - bez efektu. Uvedená chyba se dá najít různě po webu (https://www.google.cz/search?&q=skype+for+linux+white+screen), ale řešení nikde. A to se vleče už přes tři verze...

Ještě že se v Synapticu dá zamknout verze, ale do budoucna to určitě není vhodný způsob. Nejraději bych celý Skype poslal do (I), ale vendor-lock u okolní "většiny" je děsivý...

Díky za reakce.

24
Prosím znalejší přítomné o radu: od včerejška se mi v Kubuntu 14.04 LTS 64bit najednou v rámci update balíčků začal nabízet nechtěný downgrade Thunderbirdu z verze 52 na verzi 38 (viz přiložený screenshot ze Synapticu).

Mohl bych zamknout verzi TB, ale to není systémové a hlavně to není řešení. Mě by spíš zajímalo, jak se může stát, že o tolik starší verze je najednou považována za novější?

Jde o nějakou chybu v repozitářích, nebo něco jiného?

Díky za smysluplné rady.

25
Obecná podpora / Poškozené fonty v Java aplikaci
« kdy: 13 Leden 2017, 16:20:20 »
Prosím o radu či tipy v následující záležitosti: při běhu Java aplikace v Kubuntu 14.04 LTS se v ovládacích prvcích aplikace zobrazují některé položky jako "rozsypaný čaj" namísto normálního písma.

Problém se vyskytuje při běhu v OpenJDK 6, v OpenJDK 7 i v Oracle JRE 7. Při testu stejné aplikace ve Windows 7 a Oracle Java je vše v pořádku...

Screenshoty jsou v příloze.

V systému mám všechny běžné i neběžné fonty včetně MS core fonts.

Aplikace je dostupná coby archiv http://www.falstad.com/circuit-java/circuit.zip na http://www.falstad.com/circuit-java/ (běhový soubor je circuit.jar a je mu nutné změnit atribut na spustitelný).

Díky za smysluplné reakce.

Stran: [1] 2