Mármint nem a rómaiakról van itten szó, hanem Nyomosek Bobó kollégánkról [kitalált név, korábban más volt itt]
Ide töltöttem fel: http://lzsiga.users.sourceforge.net/stevejr.html

Szerk: köszönöm a hibajelzéseket, igyekszem átvezetni őket.

Magyarításról egy pont: http://lzsiga.users.sourceforge.net/stevejr.html#Q0034

Meg egy másik: http://lzsiga.users.sourceforge.net/stevejr.html#Q0035

Ékezetes fájlnevek:
http://lzsiga.users.sourceforge.net/stevejr.html#Q0036

Semmi köze semmihez, csak éppen megemlítem, hogy mi szépet ír a 'man timegm':

For a portable version of timegm(), set the TZ environment variable  to
UTC, call mktime(3) and restore the value of TZ.

Hát persze hogy nem. Mert hiányzik neki a TVision. És az fordul? Naná, hogy nem. És miért? Mert C++. Na jó, most megbuktam, ugyszintén a programozó kolléga:

static
unsigned iSqr( unsigned i )
{
    unsigned res1 = 2;
    unsigned res2 = i/res1;
    while( abs( res1 - res2 ) > 1 )
        {
        res1 = (res1 + res2)/2;
        res2 = i/res1;
        }
    return res1 < res2 ? res1 : res2;
}

Ezen a ponton az 'abs' felesleges, hiszen két 'unsigned' különbsége is 'unsigned'.

Nem fontos, csak megtetszett a neve. Nyilván nagyon megkönnyíti az internetes bankolást egy ilyen piwikpro.

2018.10.28. 10:03 Egyelőre csak egy emlékeztető magamnak: Egy debuggolási lehetőség olvasható itt: https://jvns.ca/blog/2017/09/03/debugging-netlink-requests/

2018.10.28. 12:00 Azért nem tökéletesen tökéletes:
python decoder.py pyroute2.netlink.nl80211.nl80211cmd message
Egy rész van benne, ami olvasható: {'attrs': [('NL80211_ATTR_REG_RULES',
Talán kezdetnek jó.

2018.10.28. 12:38 Azt vélem látni, hogy a netlink.h-ban definiált 'nl_wait_for_ack'-ból jön a -7 mint hibakód.

"Az adatvédelmi jogszabályoknak való megfelelés érdekében arra kérjük, hogy szánjon rá néhány percet, és tekintse át a Google adatvédelmi irányelveinek főbb pontjait."

Feltétlenül át fogom tekinteni, mihelyt időm lesz rá, addig is: https://www.ecosia.org/

Akarom mondani, a haladás nem áll meg, tehát az sshd-t már a systemd indítja a kis laptopomon. És az is állítja meg. Kb. 30 másodperc után. Mert valamiért úgy érzi, hogy nem indult el. Tök jó, hogy ilyen rendes szoftverek vannak, amik gondoskodnak debuggolnivalóról...

Mondjuk egy zavaros pontot azért látok a dologban: ha azt hiszi, hogy nem indult el, akkor mit állít le? Szóval azért tudja, hogy 'jé van itt egy process, amit én indítottam', csak valamiért nem vagyok elégedett vele, hát leállítom'

Mármint az OpenSSL-1.1.1 és az OpenSSH-7.9p1 között. Még nem tökéletes a dolog, de valami megmozdult.

http://mek.oszk.hu/12500/12517/12517.htm
Mondta a bennszülött miniszter országa egyetlen fehér lakójának.

Hát most a tomcat-native!configure van úgy vele, hogy neki $JAVA_HOME/include/jni_md.h nélkül nem sors a sorsa.

Az semmiképpen sem az ő hibája, hogy egyes implementációkban ugyanez $JAVA_HOME/include/jniport.h néven létezik, továbbá hogy ő ezt a fájlt igazából nem is használja, csak a $JAVA_HOME/include/jni.h-t, ami aztán valahogy gondoskodik a többiről.

Ez itt túl nehéz feladat a 'mcview'-nek, belefagy:

mcview /usr/java5/include/jni.h

Szerk: aljas rágalom, a 'file' utility döglött meg (akit a mcview hívott meg). Innen már kezd halványan ismerős lenni a történet, mindjárt visszakeresgélek...

Szerk: ez volt az előzmény: https://hup.hu/node/155854, ott a file-5.29 volt a gond, most a file-5.32, hátha azóta van újabb.

Szerk: Innen próbálkozom az 5.34-gyel: ftp://ftp.astron.com/pub/file/

Szerk: Hát ezzel is.

Előzmény itt: libcrypto.so.1.0.2: no version information available
Akkor abban maradtam, hogy jó, Debianék biztos valamilyen jócselekedtképpen másképp linkelik az OpenSSL-t, mint a gyártó, ezért az én házilag fordított OpenSSL-em nem jó a Debian-os binárisoknak.

Nomost itt az 1.1.1, amire ismerős üzenetet kapok:

Ha semmi más nem, de a pip aztán végképp arra való, hogy megkönnyítse az életemet. Rögtön itt az első megkönnyítés:

Akarom mondani, amikor 2017. júliusában a gcc-4.9.4-et forrásból telepítettem, akkor Istvánunk úgy látta, hogy a /usr/include/openssl/bn.h nem jól kvarálodik a zengével, ezért neki javított változatot kell létrehoznia, és elhelyezni a könnyen megtalálható /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.4/include-fixed/openssl könyvártban.

Az már semmiképpen sem az ő hibája, hogy azóta a világ haladt, az OpenSSL-1.1.1 is elérkezett, és az ő áldásosan megjobbított, de egyébként elavult fájlja miatt nem fordult a tomcat-native-1.2.17...

Kértem én ezt, vagy csak úgy feltelepítődött?
.config/autostart/zeitgeist-datahub.desktop

Egyelőre nincs béke, valameddig eljut a PHP fordítása, aztán azt mondja, hogy:

[17-Sep-2018 10:16:52 UTC] PHP Fatal error:  Unable to start pcre module in Unknown on line 0

Legalábbis olyan értelemben nem, hogy 'jobb két libz, mint egy'. Ezt most linuxon tudtam előadni, valószínűleg az openssl segítő jószándéka, a 'zlib-dynamic' van mögötte:

OpenSSL-1.1.1 megérkezett! Persze egyből jó is, ugye?
Madjnem.
A certificate-request-generálásnál megáll, ha a 'STate' vagy az 'OrganizationUnit' üres:

1:error:0D07A098:asn1 encoding routines:ASN1_mbstring_ncopy:string too short:crypto/asn1/a_mbstr.c:100:minsize=1

https://github.com/openssl/openssl/issues/7215

Szerk: Azt a jótanácsot kaptam, hogy teljesen hagyjam ki a "subject"-ből az üres részeket (SUBJ=/C=HU/.../ST=/.../OU=/...), akkor jó lesz. Kipróbáltam, jó lett.

Ki lehet a hibás, ha ilyen üzenet van a mod_jk.log fájlban:

[Thu Sep 06 10:40:14.221 2018] [942126:1] 
[emerg] jk_servlet_normalize::jk_util.c (2188): [*] does not start with '/'.

httpd: Apache/2.4.34
mod_jk: tomcat-connectors-1.2.44

Ugyebár beérkezik a klienstől, hogy "OPTIONS *", erre a httpd konzultál a mod_jk-val, hogy az óhajt-e valamit kezdeni vele, a mod_jk meg elsősorban arra panaszol, hogy mit csináljon ő egy csillaggal, amikor eddig abban hitben élt, hogy ottan egy path-név jön, /perjellel kezdve.

http://php.net/archive/2018.php#id2018-08-02-1
https://downloads.php.net/~cmb/php-7.3.0beta1.tar.xz

Ami nem változott alfa4 óta:
https://bugs.php.net/bug.php?id=73002

Ami változott:
bővítményeket (pl imagick) újra kell fordítani:

Na, működik elsőre?

Azért szégyen, hogy megfosztom a szegény mod_lbmethod_byrequests.so-t a betevő ap_proxy_balancer_get_best_worker-től. Ez valószínűleg a httpd-2.4.34 újdonsága, mert eddig nem volt ilyen panasz.

20180719.1117: Annyit már látok, hogy a mod_proxy.so exportálja ezt a szimbóleumot.

subversion-1.10.0 fordítása során merült fel némi gond, ami végül ahhoz a kérdéshez vezetett el, hogy mit kellene csináljon ez a shell-utasítás:

echo "`Unused_variable=" $random_variable"`"

Ebben ott vélem a gondot látni, hogy a "macskakörmön" belül van a `backtick`, és azon belül van az újabb "macskaköröm". Mindenesetre nincs gond, ha ha `backtick` helyett $(cmd) van, vagy ha a belső macskakörmön belül nincs szóköz. Vagy ha a bash/dash/zsh shellt használunk.

Köszönöm a Teremtőnek, hogy olyan könnyű munkát osztott rám, mint az ékezetes betűkkel való kínlódás... Mindig van új varázslat, valahogy sosem ér véget a dolog. Most éppen egy ilyen shell-scriptem van:

Ugye ez nem száz százalékban jó:

$ date -d "1941-04-07 23:59:59" +%s  -906771601
$ date -d "1941-04-08 00:00:00" +%s  date: invalid date '1941-04-08 00:00:00'
$ date -d "1941-04-08 00:59:59" +%s  date: invalid date '1941-04-08 00:59:59'
$ date -d "1941-04-08 01:00:00" +%s  -906771600

Ugyebár a mi Istvánunk mindenre képes, hogy segítsen nekünk, például kitalálta, hogy a compiler "kioptimalizálhatja" a memset-et. Namostan István persze nem gondolhat mindenre (vagy bármire a saját kis perspektíváján kívül), tehát filmszínházunk bemutatja: explicit_memset