NevemTeve blogja

GeoClue -- i've no clue about it

20161007.1127
Ma leszedtem a 'dleyna-renderer' és 'dleyna-server' nevű komponenseket. Kár értük, jó ügynökök voltak.

20160909.1216
Szintén kitörlöm a /etc/passwd-ből, /etc/group-ból és /var/lib/dpkg/statoverride-ból.

20160909.1207
Nem jó, apt-get bedurcizik a hiánya miatt. Akkor újratelepítem, és kézileg törlöm a fájljait.

Miért van nekem ilyen geoclue a debian8-amban? Persze nyilván ezrével vannak komponensek, amiknek nem értem a jelentőségét, de legalább ezt most leszedem, aztán megnézem, összedől-e a ház...

iconv az iconv ellen (Kramer contra Kramer)

Pontosabban mondva: ha van egy /usr/local/include/iconv.h meg egy /usr/include/iconv.h,
akkor ki fog nyerni? Mondjuk egy PHP fordítás során?

Nyilván az egyik a libc része (libc6-dev), a másik a külön telepített libiconvé.

Gondolom, az természetes, hogy semerről sem kompatibilisek... a libc ilyen szimbóleumokat exportál:
iconv
iconv_close
iconv_open

a /usr/local/lib/libiconv.so meg ilyeneket:
_fini
_init
_libiconv_version
iconv_canonicalize
libiconv
libiconv_close
libiconv_open
libiconv_open_into
libiconv_set_relocation_prefix
libiconvctl
libiconvlist

Szerk: Mondjuk az lehet, hogy ha lenne /usr/local/lib64/libiconv.so, és a PHP-fordítás rá is találna, akkor ez se lenne gond...

Emlékeztető: mit is kell megkérdezni a panaszos ügyféltől.

Nevét.
Telefonszámát.
Beosztását.
Saját maga tapasztalta-e a hibát, vagy másvalaki? Utóbbi esetben át tudná adni az illetőnek a telefont?
Saját maga hogyan sorolná be a gondját: hibabejelentés, segítségkérés, jogosultsági/bejelentkezési probléma, fejlesztési/változtatási igény, egyedi lekérdezés/feldolgozás kérése [pl.: Pistának hívják és Balmazújvárosban lakik, mi a telefonszáma?], egyéb.
Helyi rendszergazdával beszélt már? Miért nem?
Mikor működött utoljára? (Ha egyáltalán.)
Azóta mit telepítettek?
Helyi hálózatot felkavarták mostanában?
Frissítettek valamilyen szoftvert, ami 'garantáltan nem okoz kompatibilitási problémát'?
Milyen lemezhely fogyott el?
Milyen vírusfertőzés volt mostanában?
Elolvasta a hibaüzenetet? Megjegyezte? Leírta? Rögzített képernyőképet? Miért nem?
Tudja a gépe IP-címét? Vagy a szerverét? Vagy bármi ilyesmit? [Nem hát.]
A mellette ülő Jucusnak megy?
Van a jelszavában ékezetes betű? z/y?
Esetleg többen dolgoznak egy accounton?
Itt járt mostanában valakinek a kisfia és játszott a gépen?
Megnézné az alábbiakat, hogy úgy állnak-e, ahogy szoktak: CapsLock, NumLock, billentyűzetkiosztás, bal-/jobbkezes egér, területi és nyelvi beállítások.
Áramszünet van/volt?
Volt nagytakarítás mostanában? Takarítónő mit kapcsolt ki, milyen kábelt húzott ki, melyik készülékbe öntött vizet?
A hiba egy olyan fájllal kapcsolatban jelentkezik, amelynek a neve "Éves Beszámoló — 2016.doc"? Ha átnevezi "EvesBeszamolo2016.doc"-ra, megjavul?
Van valamilyen szabályosság a hiba jelentkezésben? Reggelenként jelentkezik? Nagy fájloknál jelentkezik? Hosszú nevű ügyfeleknél jelentkezik? Esetleg amikor elmegy a vonat az ablak előtt és láthatóan rezeg az asztal?

OpenSSL-1.1.0 elközeleg

De tényleg, előbb-utóbb kell vele foglalkozni. Egyelőre az 1.1.0-pre6 próbálható ki.

Bizonyos jelek [lásd a Makefile-t] arra utalnak, hogy a fejlesztők úgy képzelik, hogy az 1 a major verziószám és az 1.0-pre6 a minor. (Vagy csak az 1, és a .0-pre6 nem is számít. Legalábbis a shared object nevébe nem kerül bele.)

Namostan ezt mérések nem támasztják alá, default fordítás után:


# readelf -d /usr/local/lib64/libssl.so
 0x000000000000000e (SONAME)             Library soname: [libssl.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.1]

Hát én ezt úgy mondanám, hogy az 1.1 a major, és minort nem sikerült adni neki.

detencode -- mi a gond vele?

Ugye az alapgondolat zseniális: írjuk bele a fájl elején kommentbe a fájl kódolását, pl:


/* HelloVilag.java */
/* encoding: ISO-8859-2 */

Aztán valahogy így fordítsunk:


$ javac -encoding $(detencode HelloVilag.java) HelloVilag.java
# javac -encoding ISO-8859-2 HelloVilag.java -- ez lesz belőle

Ez így csudállatiasan jó.

Lenne.

Ha most kezdődne a világ, és mindenki szépen alkalmazkodna ehhez a szokványhoz. És persze a fájl örökké úgy maradna, ahogy volt, az esetleges módosítások során pedig tiszteletben tartanák az eredeti beállítást.

detencode -- van ilyen?

Biztos van már ilyesmi, arról lenne szó, hogy egy kis program beleolvas egy forrásprogramba, és az első pár sorban olyasmi kommentet keres, hogy encoding="valami" vagy encode: másvalami
Kicsit értelmesebben:


$ head Foo.java
/* Foo.java encoding="ISO-8859-2" */
$ detencode Foo.java
ISO-8859-2
$ javac -encoding $(detencode Foo.java) Foo.java

Persze ha nem talál ilyen kommentet, akkor megprólbálhat utf8 validságot ellenőrizni, vagy a LC_CTYPE-ból kiindulni (bár jobban belegondolva ez elég hülye ötletnek hangzik: valaki valahol valamikor írt előállított egy forrásprogramot valamilyen kódolással, de mi köze annak ahhoz, hogy itt és most az én terminálemulátorom hogy van beállítva?)

ya, sql -- csak hogy legyen valami

Mármint yasql kellene nekem AIX-on.
Egy 6.1-re fel is erőltettem (függőségestül), de most az 5.3-on dacoskodik a Term-ReadLine-Gnu-1.32
Már eleve az sem volt triviális, hogy lebeszéljem cc_r használatáról, de a sed(1) elég sokszori alkalmazása azért segítetett.
Most jön ez:


gcc -c   -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE   -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -maix32 -D_LARGE_FILES  -O   -DVERSION=\"1.32\" -DXS_VERSION=\"1.32\"  "-I/usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE"  -DHAVE_STRING_H -DTRG_READLINE_VERSION=0x0603 Gnu.c
In file included from /usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE/op.h:497:0,
                 from /usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE/perl.h:2754,
                 from Gnu.xs:17:
/usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE/reentr.h:776:21: error: field '_srandom_struct' has incomplete type

share_mode_stale_pid: PID 10158134 (index 0 out of 1) does not exist anymore

(frissítés az elején)

20160923.1619
És íme: https://www.samba.org/samba/history/samba-4.4.6.html
Igaz, hogy a legvégén, és igaz, hogy a problémának nincs köze a hexás/oktális számokhoz, de benne van a 4.4.6-ban a javítás!

20160101.1557


share_mode_stale_pid: PID 10158134 (index 0 out of 1) does not exist anymore

Szegény processz, nem létezik már. Ami kicsit kellemetlenné teszi a dolgot, az az, hogy az a procesz, ami ezt kiírta, az ez volt:


$ bs2stat 10158134
%PID:      10158134   PPID:  10354856   NOW: 2016-06-01.15:53:32
%USERID:   root       GROUP: system     ELAPSED:           05:41
%STATION:  pts/3      PRI:   60 20      CPU-USED:       00:00:00
%SIZE(KB): 4004       %MEM:  0.0        %CPU:  0.0
%STATE:    A Active                     WCHAN: -
%CWD:      /home/projects/
%CMD:      /usr/local/sbin/smbd -i -d2

A feljentő embertípus (nem politikai)

Mármint a feljelentő program, esetünkben:


$ java -V
JVMJ9VM007E Fel nem ismert parancssori paraméter: -V
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
$ tail /var/log/warning.log
May 14 20:36:03 machine user:err|error IBM Java[6094884]: JVMJ9VM007E Fel nem ismert parancssori paraméter: -V

Meg tudnák vajon mondani IBM-ék, hogy egy hibás opciót miért kell (error-ként, vagy bárhogy) syslogolni? (Pláne magyarul, de erről már volt szó.)

Az időutazás korlátai, avagy hogyan kerüljük el saját korábbi énünket?

Na jó, ennyire nem izgalmas a téma, igazából azon gondolkozom, hogy amikor az X program 4.4.3-as verzióját fordítom forrásból, akkor a derék linker (ld(1)) ne a már telepített /usr/local/lib64/libX.so -ra találjon rá, hanem a /usr/local/src/X-4.4.3/bonyolult_path/libX.so-ra.

Természetesen nem állítom, hogy ez önmagában bármilyen hibának az oka, de mindenesetre egy olyan apróság, ami zavar, és szeretném kiszűrni.

Például a gdb-nek van egy ilyen ötlete (Makefile részlet):


SHARED_LIBADD = -Wl,/usr/local/src/gdb-7.10/bfd/.libs/libbfd.so

Ennek egy továbbfejlesztése az lenne, ha leszednénk az elejét:


SHARED_LIBADD = /usr/local/src/gdb-7.10/bfd/.libs/libbfd.so

Ez már a Winux, vagy még csak félút?

$ gnome-terminal
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.Terminal exited with status 8

Értem, hogy systemd, freedesktop, hal, udev, dbus, pangocairo, istencsodája; de végülis nem kellene mindennek még működnie is? Szinte új Debian8 ez még...

20160427.1033: Értelmesebb hibaüzenet a /var/log/messages-ből:


Apr 27 10:33:12 hostname org.gnome.Terminal[1453]: Non UTF-8 locale (ISO-8859-2) is not supported!

akkor most működik a samba-4.4.2?

No, nagy nehezen fordult, települt, elindult. Akkor most jól működik? Természetesen nem, nyilvánvaló módon.


[2016/04/25 07:49:40.816250,  0] ../source3/smbd/smbXsrv_session.c:1387(smbXsrv_session_update)
  smbXsrv_session_update: global_id (0xf89437c2) store failed - NT_STATUS_INVALID_PARAMETER
[2016/04/25 07:49:40.816455,  0] ../source3/smbd/sesssetup.c:388(reply_sesssetup_and_X_spnego)
  smb1: Failed to update session for vuid=5802 - NT_STATUS_INVALID_PARAMETER

20160428.0746.Szerk: Becsépeltem ide is, hogy megmaradjon.

A fény az alagút végén...

Szóval, a derék Samba a 'make install' hatására szétszórja rengeteg shared libjét a fájlrendszerben, gondosan ügyelve arra, hogy mindenhová jusson (na jó, mondjuk a /dev-be most nem tett, talán majd a következő verzióban).

Mivel közben írja, hogy mit csinál, kapunk egy esélyt, hogy megállapítsuk azt a '-rpath' értéket, amit a fordításkor kellett volna a libtool-nak megadni. (Illetve az export-fájlba belegyógyítni)

Kieg: mondjuk az érdekelne, hogy ha nem keletkezik libdnsserver-common.so, de a python-dsdb_dns.so használja (használná, pontosabban), azzal kell-e valamit ténykedni...

registry a sambában?

Ezt én csodálatosan jó dolognak tartom, támogatom és helyeslem; egyetlen apróságot szeretnék csak ezzel kapcsolatban megemlíteni: azt, hogy én nem kérek belőle. Namostan természetesen nem indult el az új Samba a gépemen, ez nyilvánvalóan így is van rendjén, de a /var/log/warning.log-beli üzenetek kicsit nyugtalanítóak:


Apr 20 18:30:45 host daemon:err|error smbd[6881382]: [2016/04/20 18:30:45.657482,  0] ../lib/util/util.c:220(directory_create_or_exist) 
Apr 20 18:30:45 host daemon:err|error smbd[6881382]:   mkdir failed on directory : No such file or directory 
Apr 20 18:30:45 host daemon:err|error smbd[6881382]: [2016/04/20 18:30:45.657914,  0] ../source3/registry/reg_init_basic.c:36(registry_init_common) 
Apr 20 18:30:45 host daemon:err|error smbd[6881382]:   Failed to initialize the registry: WERR_NOMEM 
Apr 20 18:30:45 host daemon:err|error smbd[6881382]: [2016/04/20 18:30:45.658101,  0] ../lib/util/become_daemon.c:111(exit_daemon) 
Apr 20 18:30:45 host daemon:err|error smbd[6881382]:   STATUS=daemon failed to start: Samba cannot init registry, error code 13 

Kigyókkal táncoló...

Vagy valami ilyesmi... ahhoz, hogy a latin táncok egyik jeles képviselőjét fordíthassam, egy veszélyes kígyó is kellene az AIX-omba. (Ha nagyon filozofikus alkat lennék, most még a python2 vs python3 kérdésén is elgondolkoznék, de most ezt passzolom, és maradok a python=python2 egyenletnél)


$ ./configure --help >help.configure
./configure[16]: python:  not found

Szerk: mondjuk a Python nem is volna Python, ha nem használná önmagát a saját fordításához, így aztán amikor azt keresem, hogy hol jött be a zavaró tényező (esetünkben egy -L/usr/local/lib, amikor nekem -L/usr/local/lib64 van), akkor nem elég csak a Makefile-okat átnézni, hanem mindenféle dist.py szerű fájlokban is kell vadászni...

linuxban nincs registry

Ezt persze mind tudjuk. Csak egy adatbázis-szerűség van, amit a freedesktop-társaság üzemeltet a /usr/share/app* könyvtárakban, és ami tulajdonképpen olyan, mint egy registry, csak nem annak hívjuk (kivéve a /usr/share/application-registry-t, amit úgy hívnak).

Például, ha a firefox nem tud mit kezdeni egy swf fájllal (lokális fájlról van szó, mert a http-n érkező swf-fájlra rá tudja küldeni az illetékes plugint), akkor egyesek szerint az az application/vnd.adobe.flash.movie és application/x-shockwave-flash mime-type-ok közötti igazságos háború következménye, és a megoldáshoz valamelyik ilyen nemregistry-fájlban valami meg kell piszkálni valahogy így:

libevent+memcached on AIX

Elnézést, egy pillanatra félre kell tegyen a saját PC-m ügyeit holmi céges projektek kedvéért... Borzasztó...

Naszóval, legyen libevent. Lett is, egy kis változást eszközöltem benne: a libevent.so gyárilag nem dependál a libevent_core.so-ra, hanem közös részeik vannak, így aztán már a saját tesztprogramjai szerkesztésekor panaszol a ld(1). Ezt megfixáltam, tehát nálam a -levent után kell egy -levent_core is, ezt majd igyekszem elfelejteni; kb ennyi az érdekes rész:

[code]
echo '
libevent.la: LIBS += libevent_core.la
libevent_extra.la: LIBS += libevent_core.la
libevent_pthreads.la: LIBS += libevent_core.la -lpthreads
libevent_openssl.la: LIBS += libevent_core.la
' >>Makefile

as: assem tudtam, mi hiányzik nekem...

Hát az, hogy ne forduljon az OpenSSL-1.0.2g az új Debian/Jessie-n 64-biten.

cd /usr/local/src/openssl-1.0.2g/crypto/md5
# as --64 md5-x86_64.s
md5-x86_64.s: Assembler messages:
md5-x86_64.s:43: Error: 0xd76aa478 out range of signed 32bit displacement
...
md5-x86_64.s:633: Error: 0xeb86d391 out range of signed 32bit displacement
# as -V
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.25

a régi gépen 2.20.1 az as verziószám, ott fordul.

Kieg: na de a source is különbözik. Amit egy perl-script generál... jajj de ismerős ez valahonnan...
http://hup.hu/node/141733

dtelnet-ben az AltGr megint bekavart

Emlékeztető önmagamnak: kedves én, az AltGr+7 megszűnt működni, pontosabban Alt+Ctrl+7 ként működik.

A legutóbbi fejlesztés pont az volt, hogy


Ctrl+2 -> ^@ 0x00
Ctrl+3 -> ^[ 0x1b
Ctrl+4 -> ^\ 0x1c
Ctrl+5 -> ^] 0x1d
Ctrl+6 -> ^^ 0x1e
Ctrl+7 -> ^_ 0x1f
Ctrl+8 -> ^? 0x7f

Ha ehhez még Alt-os is nyomunk, akkor teszünk elé egy ESC-et. Ezzel szemközt az AltGr pont úgy csinál, mintha Ctrl és Alt is lenne nyomva... már nem emlékszem a részletekre, de van egy olyan érzésem, hogy nem lesz fáklyásmenet a kettő megkülönböztetése. Vagy lehetne azt mondani, hogy az új fejlesztés ne működjön Alt+Ctrl esetén? Pl. Alt+Ctrl+5 maradjon ° csak sima Ctrl+5 legyen ^]

Major és minor a gyakorlatban

Hát tisztelettel, ha eddig még nem lett volna világos, hogy mikor kell a major verziószámot növelni, és mikor a minor-t, azt most az OpenSSL-1.0.2g megmagyarázta: a legminorabb verziószám (vagyis az utolsó betű) nőtt csak, de inkompatibilis változás történt az ABI-ban ([default opciókkal fordítva] megszűnt létezni a SSLv2_server|client_method), emiatt eddig működő programok (curl, wget, php) nem-indíthatóvá váltak.

Végre valami nyomoznivaló: #error unsupported size of off_t

Ezt mondja a php-5.6.18 egy AIX6.1-en


/usr/local/src/php-5.6.18/ext/zip/lib/zipint.h:118:2: error:
#error unsupported size of off_t

Egyelőre fogalmam sincs, hogy ez mi lehet, akár még az is lehet, hogy az egyik komponens római számot vár (VIII), a másik meg azt adja, hogy "EIGHT", ezért nem találkoznak...

20160208.1354: Nem egészen, azt írta valami nagyon okos script a main/php_config.h-ba, hogy:


/* The size of `off_t', as computed by sizeof. */
#define SIZEOF_OFF_T 0

20160208.1402: Jaja, configure írta is:


checking size of long long... (cached) 8
checking size of off_t... 0
checking size of size_t... (cached) 8

mc-4.8.15: előre a nem-fordíthatóság útján

Mottó: 'némely emberi agy egészen másképp működik, mint ahogy azt józan ésszel gondolkodva elvárnánk...' (Váncsa István)

Most éppen azt találták ki, hogy tákoltak egy 'config/compile' nevű scriptet, azzal, hogy Wrapper for compilers which do not understand '-c -o'

Eddig valahogy elvegetáltunk ilyen wrapper nélkül, de mostanra bizonyára szükségessé vált.

Persze azon túl, amit ígér, mást is csinál, nevezetesen belebarmol a libtool --mode=compile működésébe.

Ugyebár normálisan három fájl keletkezik: valami.lo, valami.o, .libs/valami.o (a két .o közüli az előbbi a normál, az utóbbi PIC)

Őrnagy Őrnagy Őrnagy.

A 22-es csapdájában van egy ilyen nevű szereplő, akit egy IBM számítógép rögtön őrnagyi rangba helyezett a hadseregben. Na ő jutott eszembe, amikor a glib-2.26.1 fordítása megállt az alábbi üzenettel:


libtool: linking shared object: gcc -shared -Wl,-G -Wl,-bernotok -Wl,-bexport:.libs/libgio
ld: 0711-317 ERROR: Undefined symbol: .major
ld: 0711-317 ERROR: Undefined symbol: .minor
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

Egyébként van egy olyan érzésem, hogy én leszek valamiféleképpen a hibás, ugyanis én szoktam a *.la fájlokba olyanokat írni, hogy major='ennyi' minor='annyi' -- de hogy hogyan lehetett ebből extern symbol, azt még nem értem...

Lázadó gabona: -usr-include-arpa-nameser_compat.h

Csak nem megint AIX-en akarok fordítani valamit, amit a fene se szánt AIX-on fordításra? A termék neve glib-2.26.1, a hibaüzenet (mármint az első):


/usr/include/arpa/nameser_compat.h:210:2: error: unknown type name 'u_short'

Ez az 'u_short' a sys/types-ból kellene jöjjön, de csak akkor, ha az be is van inkludálva, és a különféle _*_SOURCE define-ok jól állnak.

Szerk: ezt még meg lehetne fixálni az alábbi header-rel:
[code]
/* /usr/local/include/arpa/nameser_compat.h */

#ifndef _H_ARPA_NAMESER_COMPAT_

#include <sys/types.h>
#include_next <arpa/nameser_compat.h>