NevemTeve blogja

Hagyományos észjárással azt gondolnánk, hogy adhatna legalább valami warningot a szoftver, de nem. Ha én a 25-ös év naptárárát kérem, akkor akkor azt is kapom, talán történész vagyok, vagy mi.

Vagy nagyobb.

-rw-r--r-- 1 nevem teve 18346056 Feb 13 12:45 openssl-3.4.1.tar.gz
-rw-r--r-- 1 nevem teve 53136912 Apr  8 15:14 openssl-3.5.0.tar.gz

Mint egy falat kenyér, úgy hiányzott. Most emiatt nem tudok megnézni egy `*.deb` fájlt, mert az `ar` kibont ugyan belőle pár *.zst fájlt, viszont azokba már nem tudok belenézni a korszerűtlen rendszeremben. Persze tudom, telepítsem forrásból a függőségek fügőségeivel kezdve. Azért ilyenkor elgondolkozom, hogy a derék fejlesztők matyirgálnak eleget? Vagy milyen defektus okozza, hogy mindig beleb_armoljanak már működő dolgokba?

NSS = Network_Security_Services Nyilván nem lesz könnyű a fordítása, például CFLAGS-ot és LDFLAGS-ot nem óhajt átvenni, a következő egyszerű és praktikus ötletem van:

export CC="gcc $CFLAGS $LDFLAGS"
export CXX="g++ $CXXFLAGS $LDFLAGS"

A jó hír(?) az, hogy a configure-ral nincs gondom, mivel az nincs is, a make-val kezdődik a történet.

Valamiért át akartam adni a gcc által hívott collect2-nek a --save-temps opciót. De sikerült?!
Igen, elannyira, hogy ő maga is továbbadta a ld-nek, aki joggal mondta rá, hogy
ld: unrecognized option '--save-temps'

In file included from fnmatch.c:39:
./uchar.h:691:53: error: macro "_Static_assert" requires 2 arguments, but only 1 given
  691 | static_assert (sizeof (char32_t) == sizeof (wchar_t));

Nem hiába mondják, hogy két nehéz dolog van a programozóiparban: a találó elnevezések, a dátumok kezelése, és az off-by-one hibák. Na itt csak annyi történt, hogy a makróhívásnál az argumentumokat kicsit felületesen számolta meg a fejlesztő kolléga.

Szerk (2025.02.04.): ennek a végén mond valaki valami hasznosat (naná, én írtam):
https://github.com/coreutils/gnulib/pull/16

`cronolog` barátunknak azt mondtam, hogy hetente kezdjen új fájlt: log.%Y_%W. A derék program most is írja a log.2024_53 nevű fájlt. (Természetesen el lehet rontani a dolgot, ha hónapot és hetet is teszünk a mintába, akkor lesz belőle 2025 nulladik hete.)

YaSql> select 'árvíztűrő tüköfúrógép' from duale;

select 'árvíztűrő tüköfúrógép' from duale
ORA-00942: table or view does not exist (DBD ERROR: error possibly near <*> indicator at char 36 in
'select 'árvíztűrÅ� tüköfúrógÃ<*>©p' from duale')

Pedig azt hallottam, hogy az UTF8 bevezetése mindent megold.

Szerk:
https://stackoverflow.com/questions/79309127/does-perl-c-api-have-an-ut…
https://github.com/lzsiga/DBD-Oracle/commit/3aaf6d206cf5d4b3b40ac876607…

TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1

Ezt találtam a Firefoxban, és állítólag ez valódi CA, csak török. Hát biztos.

Akarom mondani, jó lenne tudni, hogy a 2025.01.01-es drágulás érinti-e a kis cégünk forgalmát, erről itt lehet nemtájékozódni:
https://www.posta.hu/static/internet/download/Lapdijszabas_20240701-Hun…
https://www.posta.hu/static/internet/download/Lapdijszabas_20241101-Hun…
https://www.posta.hu/static/internet/download/Lapdijszabas_20250101-Hun…
 

Itt az igazi 2025.01.01-től érvényes:
https://www.posta.hu/static/internet/download/Lapdijszabas_2024-Hun_A4_…
(Gondolom, nemrégiben Macóka helyett Lacóka lett a webművész, és muszáj volt valahogy kifejeznie az önálló személyiségét.)

Ezt most nem akarom sokat ragozni, aki nem tudja, hogy miről van szó, annak röviden: már külön sportolni kell ahhoz, hogy a Samsung telefonon a kikapcsológomb kikapcsológombként működjön, ne pedig a segítőprogramot indítsa el.

Ennek a derék függvénynek az első paramétere egy string, amit feldolgoz, egy további paramétere pedig egy olyan string, ami az első string kódolását tartalmazza, hogy pl. 'UTF-8'. Megkérdeztem, hogy mivel csak ASCII karakaterekkel dolgozik a függvény, minek ez a további paraméter.

Azt mondták, ez azért jó, mert lehet [egy esetleges jövőbeli állapotban], hogy az első string nem is ASCII-kompatibilis [mint amilyen az ISO-8859-x vagy az UTF-8]. Namostan azt mondja meg valaki őszintén, hogy ha ez egy valós opció, akkor nem kellene-e egy mégtovábbi paraméter, ami a második paraméter kódolását tartalmazza? És persze így tovább a végtelenségig.

Szerintem minél gyorsabban töröljük az ilyen fájlt, annál jobb. De azért kicsit keresgéltem, és azt véltem hallani, hogy egy sun.jnu.encoding nevű beállításnak is van valamilyen szerepe az ügyben.

De tényleg, pl. ennél mi egyszerűbb: írjunk ki n tételt c hasábban, úgy, hogy az első c-1 hasáb tele legyen, az utolsóban legyen a maradék. Ehhez tényleg nem kell más, csak az alsó és felső egészrész, és/vagy a maradékos osztás ismerete.

Akkor most fussunk neki az n=18, c=7 vagy n=18, c=8 esetnek.

Could not parse Strict-Transport-Security header

A számos ok közül, amiért nem tudta parszolni, az az, hogy nem volt ilyen header. Ez egy wget-1.21.3; eddig nem láttam ezen nyomorogni, most vajon mi történt?

Kiszerelik az OCI8-at, ha jól látom, alapvetően az érdeklődés hiánya miatt.
Valamiféle PECL-ben lesz majd, bármi is legyen az. https://pecl.php.net/package/oci8

Szerk: kijött a 8.4.1, máris kitolom élesbe, meglátjuk, mi lesz.
https://www.php.net/ChangeLog-8.php#PHP_8_4

Azt mondják éber programok, hogy 1.2.38 vagy újabb kellene, innen lehet letölteni az 1.2.39-et: https://dlcdn.apache.org/tomcat/tomcat-connectors/native/ Ja, hogy innen ugyan nem. Nem baj, nyilván nem lesz inkompatibilitás az 1.3.1-gyel sem.

https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/class…
Tippeljük meg, mi történik, ha a 150-es sorban lévő socketRead0 (aki egy natív metódus) dob egy Exceptiont, ami valamiért nem ConnectionResetException, hanem más. (Megjegyzés: adott esetben az is lehet, hogy Aix-on más errno értékek is előfordulhatnak, mint amire a derék coder felkészült Linuxos tapasztalatai alapján).

Egy egyszerű kérdést vizsgálunk, mit csinál ez a programka:

echo 101 202 lonc | read A B C
printf 'A="%s" B="%s" C="%s"\n' "$A" "$B" "$C"

https://www.openwall.com/lists/oss-security/2024/07/01/3
Ha jól értem, a kulcsgondolat az, hogy signal-handler-ből free(3)-t hívunk. És ezt egyszer már kijavították, de később visszarakták.

Perl-hez van egy Oracle-DBD, abban egy ilyen jóság:

Akarom mondani, egyes komponenseket a /usr/local/lib64/python3.12-be telepít, másokat a /usr/local/lib/python3.12-ba. A tényleges programindulásnál persze joggal neheztel, hogy Could not find platform dependent libraries <exec_prefix>
kb. egyetlen dolog biztos: hogy én vagyok a hibás, amiért azt mondtam neki, hogy --libdir=/usr/local/lib64

Cannot load libexec64/apache2/libphp.so into server: /usr/local/libexec64/apache2/libphp.so: cannot allocate memory in static TLS block

Egyesek szerint a gomp-nak köszönhetjük ezt az érdekességet, mások szerint a sors nem kegyes. Modern világunkban ilyenkor jön a kikapcs+bekapcs, ha attól megjavul, akkor nem nyomozunk tovább.

Csak ebből a debugüzenetből gondolom:

  log does not need rotating (log has been already rotated)considering log /var/log/kern.log
  log does not need rotating (log has been already rotated)considering log /var/log/messages

Na jó, nem is az a fő gond, hogy nem találta a soremelést a derék fejlesztő, inkább az, hogy végül is nem is rotálta meg a kern.log-ot. Sem semmit. Ja és a copyright szerint az a 3.8.6-os verzió, 2001-ből.

rsyslog-8.2402.0-t próbálom ./configure-olni, de ez a kódrészlet (15664-es sor) túl nehéz a shell-nek:

 for flag in     ; do

De tényleg, ezt a ciklust most hányszor kellene végrehajtani, nullaszor?