git clone po https

2023-03-17 Wątek Adam Osuchowski
Czy byłaby możliwość, żeby wystawić repozytorium na git.pld-linux.org
również po https? Wystraczyłoby w sumie tylko read-only, żeby przy
anonimowym dostępie nie trzeba było klonować po tym plain-tekstowym
podstawowym protokole.

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: błąd "signature verification failed" podczas instalacji pakietów

2023-03-17 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz via pld-devel-pl wrote:
> Zrobione w main.

Dzięki wielkie, jest zdecydowanie lepiej.

Przy okazji jeszcze pytanie, czy można by było zmienić klucze PGP do
podpisywania paczek na bardziej współczesne? Obecne są sprzed 15 lat
i mają trochę stare parametry (1024-bitowe DSA i RSA). Poza tym, klucz
RSA chyba w ogóle nie jest używany, bo z tego co widzę, to chyba
wszystkie paczki są podpisane kluczem DSA.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: błąd "signature verification failed" podczas instalacji pakietów

2023-03-12 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz via pld-devel-pl wrote:
> Jako brzydki workaround spróbuj odinstalować nasz klucz gpg, bodaj:
> 
> rpm -q gpg-pubkey
> rpm --erase --allmatches  gpg-pubkey-xyz

No właśnie, on jest brzydki. Równie dobrze mogę ustawić poldkowi signed=off
a w /usr/lib/poldek/pm-command.sh dodać rpmowi --nosignature. Tylko to
chyba nie tędy droga, żeby pozbywać się podpisów pakietów i ich weryfikacji.
Z tego co sprawdziłem to ok. 1/3 pakietów w repozytorium nie ma prawidłowo
weryfikowalnej sygnatury, więc dość sporo, a ostatni taki ze starym podpisem
jest z 22 lutego 2021 r. Jak się też okazuje, można to łatwo naprawić przez
`rpm --delsign' / `rpm --addsign', bez konieczności rebuilda całego pakietu.
Można liczyć na przeprowadzenie takiej masowej operacji w repozytorium?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


błąd "signature verification failed" podczas instalacji pakietów

2023-03-05 Wątek Adam Osuchowski
Od jakiegoś czasu nie da się zainstalować starych pakietów z repozytorium
(tj. takich zbudowanych 2-3 lata temu albo dawniej). Problem dotyczy wielu
różnych pakietów, ale ich wspólną cechą chyba jest właśnie wiek. Poldek
krzyczy, że "signature verification failed", ale co ciekawe, pozwala pobrać
taką paczkę.

poldek:/all-avail> install --force filesystem-4.1-15.x86_64
Processing dependencies...
filesystem-4.1-15.x86_64 obsoleted by filesystem-4.1-15.x86_64
There are 1 package to install, 1 to remove:
U filesystem-4.1-15.x86_64
filesystem-4.1-15.x86_64.rpm: digests OK
Need to get 33.0KB of archives.
filesystem-4.1-15.x86_64.rpm: digests OK
filesystem-4.1-15.x86_64.rpm: DIGESTS SIGNATURES NOT OK
error: filesystem-4.1-15: signature verification failed
There were signature verification errors. Proceed? [N/y] n
There were errors
poldek:/all-avail> get filesystem-4.1-15.x86_64
th::filesystem-4.1-15.x86_64.rpm [33.0K (33.0K/s)]
filesystem-4.1-15.x86_64.rpm: digests OK

rpmowi też się to nie podoba:

root@pld:~# rpm -Uvh --force filesystem-4.1-15.x86_64.rpm
Verifying...  # [100%]
Preparing...  # [100%]
package filesystem-4.1-15.x86_64 does not verify: no digest

Wygląda na to, że nie podoba mu się brak sygnatury SHA256:

root@pld:~# rpm -K filesystem-4.1-15.x86_64.rpm 
filesystem-4.1-15.x86_64.rpm: DIGESTS SIGNATURES NOT OK
root@pld:~# rpm -Kvv filesystem-4.1-15.x86_64.rpm
D: loading keyring from rpmdb
D: PRAGMA secure_delete = OFF: 0
D: PRAGMA case_sensitive_like = ON: 0
D:  read h#   2 Header sanity check: OK
D: added key gpg-pubkey-e64e7bf7-47b35206 to keyring
D:  read h#   3 Header sanity check: OK
D: added key gpg-pubkey-e4f1bc2d-47b351f0 to keyring
filesystem-4.1-15.x86_64.rpm:
Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: OK
Header SHA1 digest: OK
Payload SHA256 digest: NOTFOUND
Payload SHA256 ALT digest: NOTFOUND
RSA signature: NOTFOUND
DSA signature: NOTFOUND
MD5 digest: OK

bo dla nowszych pakietów, które już ją mają, nie krzyczy:

root@pld:~# rpm -K bash-5.2.15-1.x86_64.rpm
bash-5.2.15-1.x86_64.rpm: digests signatures OK
root@pld:~# rpm -Kvv bash-5.2.15-1.x86_64.rpm
D: loading keyring from rpmdb
D: PRAGMA secure_delete = OFF: 0
D: PRAGMA case_sensitive_like = ON: 0
D:  read h#   2 Header sanity check: OK
D: added key gpg-pubkey-e64e7bf7-47b35206 to keyring
D:  read h#   3 Header sanity check: OK
D: added key gpg-pubkey-e4f1bc2d-47b351f0 to keyring
bash-5.2.15-1.x86_64.rpm:
Header V4 DSA/SHA1 Signature, key ID e4f1bc2d: OK
Header SHA256 digest: OK
Header SHA1 digest: OK
Payload SHA256 digest: OK
MD5 digest: OK

Jak się domyślam, to pewnie jest efekt uboczny przejścia z rpm5 na rpm4.

Czy można prosić w związku z tym o przebudowanie możliwie jak największej
liczby paczek, których aktualne wersje z repozytorium zostały zbudowane
2 września 2020 r. lub wcześniej (to była najpóźniejsza data budowy paczki,
którą znalazłem, że ma ten problem)? Trochę utrudnia to instalację, jako że
poldek nie ma opcji ignorowania podpisów podczas instalacji (czego zresztą
nie chciałbym i tak robić). Zdaję sobie sprawę, że może być problem z
budową jakichś starych paczek sprzed lat, bo mogą się np. już nie kompilować,
ale może chociaż dałoby się spaczkować jeszcze raz same rpmy, albo tylko
je podpisać po nowemu, bez zmiany samych plików ze środka?

Alternatywnie zostaje zapatchować rpma i/lub poldka, żeby nie zwracał uwagi
na brak sygnatury SHA256 jeżeli SHA1 weryfikuje się poprawnie.

Z góry dzięki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


katalog /usr/lib/.build-id/

2021-11-17 Wątek Adam Osuchowski
Czy katalog /usr/lib/.build-id i jego bezpośrednie podkatalogi nie
powinny raczej należeć do pakietu FHS lub filesystem zamiast do każdej
z budowanych paczek? Potem poldek ciągnie jakieś egzotyczne zależności,
bo znalazł tam np. /usr/lib/.build-id/fe.


root@pldtest:~# ipoldek 'search -f /usr/lib/.build-id' | wc -l
802
root@pldtest:~# ipoldek 'search -f /usr/lib/.build-id/*' | wc -l
801
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem z poldkiem i repo po zmianie na openssl 3.0

2021-11-16 Wątek Adam Osuchowski
Adam Osuchowski wrote:
> Poza tym coś sie musiało właśnie zmienić, bo te pliki ściągnięte przed
> chwilą dwa razy w odstępie paru minut zmieniły się.

Było tak:

packages.ndir.dscr.gz   2021-11-16 14:042.3M
packages.ndir.gz2021-11-16 14:0418M  

a jest tak:

packages.ndir.dscr.gz   2021-11-16 21:492.3M
packages.ndir.gz2021-11-16 21:4918M

Ale cokolwiek zmieniłeś, teraz jest ok:

root@pldtest:~# ipoldek 'ls openssl*' 
openssl-3.0.0-2.x86_64
openssl-devel-3.0.0-2.x86_64
openssl-engine-pkcs11-0.4.11-2.x86_64
openssl-static-3.0.0-2.x86_64
openssl-tools-3.0.0-2.x86_64
openssl-tools-perl-3.0.0-2.x86_64
6 packages

Dzięki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem z poldkiem i repo po zmianie na openssl 3.0

2021-11-16 Wątek Adam Osuchowski
Jan Rękorajski wrote:
> On Tue, 16 Nov 2021, Adam Osuchowski wrote:
> 
> > Próba aktualizacji openssl do 3.0 nie powodzi się. Poldek cały czas widzi,
> > że jest stary openssl, mimo że faktycznie w repo już jest trójka. Do tego
> > próba ściągnięcia tego pakietu wysypuje poldka. Wywalenie cache'a baz nic
> > nie daje. Sytuacja w pełni powtarzalna. System był aktualny wg stanu na
> > 12 listopada. Konfiguracja poldka domyślna z paczki.
> 
> Na co masz ustawione repo w /etc/poldek/repos.d/pld.conf?
> Na ftp nie ma w main openssl-1, indeksy sa swieze.

Tak, jak pisałem, defaulty z paczki:

_pld_main_prefix = https://ftp.th.pld-linux.org/dists/th

A czy tak ma być, że pliki:

https://ftp.th.pld-linux.org/dists/th/PLD/x86_64/RPMS/packages.ndir.gz
https://ftp.th.pld-linux.org/dists/th/PLD-openssl1/x86_64/RPMS/packages.ndir.gz

mają taką samą zawartość, podobnie jak:

https://ftp.th.pld-linux.org/dists/th/PLD/x86_64/RPMS/packages.ndir.dscr.gz
https://ftp.th.pld-linux.org/dists/th/PLD-openssl1/x86_64/RPMS/packages.ndir.dscr.gz

skoro w tych katalogach są rózne pakiety?

Poza tym coś sie musiało właśnie zmienić, bo te pliki ściągnięte przed
chwilą dwa razy w odstępie paru minut zmieniły się.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


problem z poldkiem i repo po zmianie na openssl 3.0

2021-11-16 Wątek Adam Osuchowski
Próba aktualizacji openssl do 3.0 nie powodzi się. Poldek cały czas widzi,
że jest stary openssl, mimo że faktycznie w repo już jest trójka. Do tego
próba ściągnięcia tego pakietu wysypuje poldka. Wywalenie cache'a baz nic
nie daje. Sytuacja w pełni powtarzalna. System był aktualny wg stanu na
12 listopada. Konfiguracja poldka domyślna z paczki.


root@pldtest:~# rpm -q openssl
openssl-1.1.1l-1.x86_64
root@pldtest:~# rpm -q poldek
poldek-0.42.2-7.x86_64
root@pldtest:~# rm -rf ~/.cache/poldek
root@pldtest:~# poldek --upa
th::packages.ndir.gz [17.8M (17.8M/s)]  
th::packages.ndir.dscr.gz [1.2M (1.2M/s)]  
th::packages.ndir.gz [17.6M (2.5M/s)]   
th::packages.ndir.dscr.gz [2.3M (2.3M/s)]  
root@pldtest:~# ipoldek 'ls openssl*'
openssl-1.1.1l-1.x86_64
openssl-devel-1.1.1l-1.x86_64
openssl-engine-pkcs11-0.4.10-1.x86_64
openssl-engines-1.1.1l-1.x86_64
openssl-static-1.1.1l-1.x86_64
openssl-tools-1.1.1l-1.x86_64
openssl-tools-perl-1.1.1l-1.x86_64
7 packages
root@pldtest:~# ipoldek 'get openssl'
Loading [pndir]th...
Loading [pndir]th...
30648 packages read
error: openssl-1.1.1l-1.x86_64.rpm: not an rpm package

Something wrong, something not quite right with 0.42.2 (stable)
Assertion 'cn->proto == VCN_PROTO_HTTP' failed, vfffmod.c:272
Please report this bug to: https://github.com/poldek-pm/poldek/issues/new

Aborted
root@pldtest:~# 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Problem iproute2 od wersji 5.1

2020-02-05 Wątek Adam Osuchowski
Marcin Krol wrote:
> On 05-Feb-20 14:23, Maciej Kędzierski wrote:
>> Witam.
>>
>> Po aktualizacji iproute2, od wersji 5.1 wzwyż, pojawił się problem z
>> działaniem sieci po restarcie usługi "network". Zwyczajnie sieć nie
>> działa, chociaż wszystko restartuje się poprawnie, nie ma błędów.
>
> Używasz rc-scripts z tego co widzę? Miałem ten problem w TLD. Zmienił się 
> nieco output polecenia ip i potrzebna jest drobna zmiana. Bez niej usuwane 
> są domyślne reguły routingu i nie masz ruchu. Poprawka jest w git TLD:
>
> https://git.tld-linux.org/?p=rc-scripts.git;a=commitdiff;h=21e610d89da09c31ff36b575dea6ddb20988e1db

Tak, też to miałem. Restart powoduje usunięcie wszystkich reguł
routingu (ip rule) włącznie z tymi domyślnymi, które zawsze powinny
być. Chodzi o spację w regexpie. Zakomitowałem poprawkę 2 miesiące
temu, ale jeszcze widać nie trafiła na produkcję:

https://git.pld-linux.org/?p=projects/rc-scripts.git;a=blobdiff;f=lib/functions.network;h=867c2d6e2d803a69f89d9aecda2a9240b5ff3080;hp=86bc978a61734475637ba2b7e10157ecf7886ea5;hb=2bbccb79d846ac4106e503a82648395ad6360260;hpb=2843ac0cd9c3e7185709a752a2d3c52fd46e1e01
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Zmiana nazwy pakietu

2019-12-30 Wątek Adam Osuchowski
Peri Noid wrote:
> To nie zadziałało:
> 
> $ ssh g...@git.pld-linux.org mv kio-extras kf5-kio-extras
> bad command: mv kio-extras kf5-kio-extras

Bo chyba nie `mv' tylko `move'.

$ ssh git.pld-linux.org help
You have access to the following commands:
info
expand
checkgithub
copy
create
move
ro
rw
sskm
stbr
trash

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Przypomnijcie proszę, jak wysyłać coś na buildery

2019-10-06 Wątek Adam Osuchowski
Łukasz Maśko wrote:
> Baaardzo przepraszam za zawracanie głowy. Trochę mi wstyd, że się muszę 
> zapytać ale... nie pamiętam.
> 
> Czy mógłby mi ktoś przypomnieć, jak obecnie wysyła się zlecenia przebudowania 
> paczek na builderach? Koszmarnie dawno to robiłem a teraz mam potrzebę. Prawa 
> powinienem wciąż mieć. W każdym razie aktualizację SPEC-ów wciąż mogę i daję 
> radę zrobić.

Kiedyś to się robiło tak:

$ ssh g...@git.pld-linux.org stbr pakiet

ale czy działa dalej to nie wiem.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Brak nowych repozytoriów i branchy na liście refów

2019-07-24 Wątek Adam Osuchowski
Od jakiegoś czasu (wg moich ustaleń od ok. 8-12 kwietnia 2019 r.) nowe
repozytoria i nowe branche w już istniejących nie pojawiają się na
liście generowanej przez polecenie:

$ git archive --format tgz --remote git://git.pld-linux.org/Refs HEAD

a tym samym przez 'slug.py list`. Na stronie https://git.pld-linux.org/
nie ma aktualnej listy pakietów od jeszcze dawniej. Ktoś coś wie na ten
temat i może to poprawić?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: KDE4 and KDE3 going away

2019-03-01 Wątek Adam Osuchowski
Jan Rękorajski wrote:
> Nie patrz na to co jest w th-main tylko na to co jest w th-test.
> Jak nowe biblioteki przejdą z test do main to stare znikną i się
> zależnośći rozjadą.
> 
> > Zresztą np. kde4-kdebase-runtime buduje się i z exiv2 0.26 i 0.27.0a.
> > Wysypuje się gdzie indziej ale to nie ma nic wspólnego z zależnością od
> > exiv2.
> 
> Może i się buduje, ale nie jest w stanie exiv2 0.27 wykryć, żaden z tych
> pakietów nie jest.

Problem z exiv2 jest chyba spowodowany kwestią wielkości liter (Exiv2 vs.
exiv2) w nazwach pakietów podawanych w plikach cmake'a. Wg dokumentacji
do funkcji find_package():

The command searches for a file called Config.cmake or
-config.cmake for each name specified. 

Pakiety z kde4 szukają Exiv2, a tymczasem u nas jest:

$ ls /usr/share/exiv2/cmake/
exiv2Config-pld.cmake  exiv2Config.cmake

i find_package(Exiv) nie dopasowuje ich do powyższych wzorców.

Można by było poprawić to raz w exiv2, ale nie wiem czy się coś innego
przy okazji nie rozjedzie, więc poprawiłem to w pakietach kde4-*, które
wskazałeś.

Przy okazji, plik exiv2Config.cmake wydaje się być błędnie wygenerowany
i na tyle, na ile rozumiem cmake'a, nie pozwala na kompilację. Natomiast
ten exiv2Config-pld.cmake jest ok, ale go cmake nie wykrywa, więc
podmieniłem mu nazwę na exiv2Config.cmake. Jak ktoś ogarnia cmake'a
bardziej, to niech rzuci okiem czy nie można tego lepiej zrobić.

Zobacz proszę czy te poprawki coś pomogły i co teraz go boli.

Co do problemów kde4-kdebase-workspace z dbusem, to postaram się na to
spojrzeć i spróbować poprawić.

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: KDE4 and KDE3 going away

2019-02-26 Wątek Adam Osuchowski
Jan Rękorajski wrote:
> Until someone fixes build problems with kde packages that are currently broken
> according to http://ep09.pld-linux.org/~pldth/main-ready-test.txt, I am
> going to remove ALL kde4 and kde3 packages and everything that depends on
> them.

Spokojnie, spokojnie... Możesz przybliżyć, co go dokładnie boli, bo:

# ipoldek --sn th -q search -p 'libexiv2.so.26()(64bit)'
exiv2-libs-0.26-1.x86_64
# ipoldek --sn th -q search -p 'libqalculate.so.5()(64bit)'
libqalculate-0.9.7-4.x86_64

Zresztą np. kde4-kdebase-runtime buduje się i z exiv2 0.26 i 0.27.0a.
Wysypuje się gdzie indziej ale to nie ma nic wspólnego z zależnością od
exiv2.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Gdzie się podziały źródła do icedtea8?

2019-01-29 Wątek Adam Osuchowski
Łukasz Maśko wrote:
> Dnia wtorek, 29 stycznia 2019 22:59:15 Łukasz Maśko pisze:
> > Szukam w naszym GIT paczek icedtea8 i nie mogę znaleźć... Jest wersja 6,
> > jest 7, ale 8-ki nie ma. Jak to się teraz nazywa?

Chodzi Ci o https://git.pld-linux.org/?p=packages/icedtea8.git czy nie
zrozumiałem Twojego pytania?

> Chyba, że strona git.pld-linux.pl nie jest zsynchronizowana z zawartością 
> GITa, bo nie wyświetla tej paczki na liście. Ale jak wpiszę z palca adres to 
> jest OK. Nie kumam...

Nie od dzisiaj. Zgłaszałem to już kiedyś:

https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2016-October/157288.html

Najbardziej wiarygodne jest bezpośrednie odpytanie gita, np. za pomocą slug.py:

$ slug.py list | grep icedtea
icedtea-sound
icedtea-web
icedtea6
icedtea7
icedtea8
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-18 Wątek Adam Osuchowski
Jakub Bogusz wrote:
> Nie powinno być w ogóle znacznika "BuildArch: ..." innego niż noarch
> - nie nie jest noarch, jest w architekturze głównego pakietu.
> ".x86_64" też nie powinno się znaleźć w nazwie (pod)pakietu.

Faktycznie, istotna uwaga. Po poprawce w kodzie jest lepiej. Oby to był
jedyny problem.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-18 Wątek Adam Osuchowski
Tomasz Pala wrote:
> Tylko widzisz, sam Jeff twierdzi, że rollback powinien być realizowany
> poprzez cofnięcie się do odpowiedniego snapshota (bo triggery mogą
> modyfikować pliki). Zresztą nie wiem nawet, czy nie twierdził również, że
> obecny rollback został tylko ze względu na PLD (albo przynajmniej tak
> zrozumiałem), no i w związku z tym on jej nie rozwija i nie naprawia.
> Więc wcale bym się nie zdziwił, gdyby któregoś dnia rpm5
> również pozbył się tej funkcji albo koncertowo przestała działać.

Jak już pisałem, ja to wiem i rozumiem, ale potrzebuję przynajmniej
podstawową funkcjonalność złożenia do kupy aktualnych plików wchodzących
w skład pakietu, bo po nieudanym upgradzie może się okazać, że jest to
jedyna kopia działającej wersji. Oczywiście, pozostaje backup, ale to
jest co innego -- daje gołe pliki bez tagów rpmowych i brak możliwości
aktualizacji bazy rpmowej.

> Właśnie rpmrebuild miałem na myśli, oglądałem go kiedyś i o ile mnie
> pamięć nie myli, wyglądało to dość rozsądnie (łącznie z podpisywaniem
> powstałych pakietów), przy czym raczej podpiąć by to trzeba na poziomie
> poldka, więc w razie ręcznego operowania rpmem trzeba także ręcznie
> sobie zadbać o 'cofkę'.

Z ciekawości odpaliłem:

$ rpmrebuild bash
error: line 31: Only "noarch" sub-packages are supported: BuildArch: x86_64
error: Package has no %description: .x86_64
/usr/lib/rpmrebuild/rpmrebuild.sh: ERROR: package 'bash' build failed

Jak na początek to słabo... Nie wiem dlaczego subpakiety mogą być tylko
noarch. Czyli jak jest cośtam i cośtam-libs to już koniec, bo zapewne
-libs nie jest noarch. Tym błędem sypnął /usr/bin/rpmbuild czyli część
samego rpma. W kodzie źródłowym rpm4 i rpm5 ten fragment wygląda podobnie
więc jest spora szansa, że czwórka też się w ten sposób wysypie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-18 Wątek Adam Osuchowski
Jacek Konieczny wrote:
> Feature-request do Poldka. Nie musi przecież to być w samym RPMie.

Nie musi, ale im bliżej niego tym lepiej, bo nie zawsze się poldka
używa wprost. Wystarczyłoby, żeby było makro w rpmie określające jakie
zewnętrzne polecenie uruchomić przed upgradem/usuwaniem i żeby rpm
go odpalał gdy potrzeba.

> To takie rzeczy najlepiej jakimś ansiblem robić, to zawsze można
> wszystko od zera odtworzyć.

To też armata na muchę... Ansible, chefy czy inne puppety sprawdzają się
przy dużej skali.

> Ale tego nie da się zrobić dobrze nie pozbywając się %pre, %post i
> %trigger. Nie zagwarantujesz powrotu do stanu sprzed zainstalowania
> pakietu jeśli przy jego instalcji i deinstalacji może się wykonywać
> jakiś dodatkowy kod i to jeszcze zależny od innych pakietów
> zainstalowanych w systemie.

Ja to wiem i akceptuję to. Obecny repackage też tego nie robi. Raczej
chodzi o to, żeby mieć aktualne pliki wchodzące w skład danego pakietu,
poskładane do jednej instalowalnej paczki. Ew. problemy poboczne z
post/pre (których nota bene nie doświadczyłem za wiele przy aktualnym
repackage) są do przyjęcia, bo i tak to jest na wypadek problemów po
upgradzie po których i tak trzeba zazwyczaj ręcznej interwencji. 

> Ja z lenistwa nigdy się w weryfikację pakietów nie bawiłem. Zakładam, że
> pakiety biorę zawsze z zaufanego źródła. Jakby mi zależało na
> weryfikacji, to pewnie bym to sprawdził??? i się rozczarował.

Co z tego, że źródło jest zaufane, jak ciągniesz je z niebezpiecznego
ftpa? Poza tym, dochodzi do tego jeszcze kwestia ew. kompromitacji
serwera na którym są składowane. Podpis powinien być integralną częścią
pliku z paczką, a sama paczka być niezależna od tego skąd i jak się ją
pobrało. To jest coś, co w dzisiejszym świecie jest całkowicie naturalne
(no chyba, że się jest Google Playem), co podobało mi się w rpmie i brak
czego mnie zawsze denerwował w dystrybucjach z paczkami w formacie .deb.
Tam zapewnienie integralności paczek zostało przesunięte do osobnych
plików i potem z tego wychodzą dziwne kontrukcje w stylu tego całego PPA.

> Mnie się nie wydaje, żeby akurat repackage było takie istotne.

Co kto lubi. Ja wolę (chociaż w zasadzie powinienem napisać, że muszę)
mieć wyjście awaryjne, gdy po jakimś upgradzie będzie wtopa i trzeba się
będzie na szybko cofnąć.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-16 Wątek Adam Osuchowski
Tomasz Pala wrote:
> Dla mnie również jest to ważne, ale w realnym świecie dzisiaj rozwiązuje
> się to inaczej. Znam przynajmniej 3 metody, żadna nie tak wygodna, ale
> Jeff wielokrotnie mówił, że repackage w rpm5 też jest skopane, bo nie
> potrafi wycofać zmian zrobionych triggerami, a poza tym nie zgadzają się
> sumy kontrolne w takim repakietowanym archiwum:
> 
> 1. zachowując kopię instalowanych pakietów podczas ich pobierania,

Musiałoby to być robione automatycznie podczas instalacji paczki, żeby
było wygodne. Bo mirrorowanie wszystkich pakietów we wszystkich możliwych
wersjach wyszło mi już kiedyś bokiem. Poza tym, tak jak sam zauważyłeś,
brak tu jest zachowania lokalnych zmian, co dla mnie jest sporą wadą, bo
jak coś modyfikuję, to po to, żeby tak właśnie było, a nie, żeby to było
nadpisane. No i nie tylko pliki z /etc się modyfikuje, czasami trzeba
i co innego, żeby dopasować.

> 2. używając snapshotów na poziomie systemu plików,

Łoo... to jest zdecydowany overkill. Trzeba mieć LVMa albo jakiś btrfs
(tudzież inny fs ze wsparciem do snapshotów), a to w czasach powszechnej
wirtualizacji i zewnętrznego storage'u często jest zbędnym balastem. Poza
tym nie potrzeba mi robić snapshota z całości systemu tylko z pakietu
i wracanie z tym jest praktycznie niewykonalne. To nie tak powinno się
robić, możliwość rollbacku powinna być zaimplementowana możliwie
najbliżej samego mechanizmu zarządzania pakietami.

> 3. używając zewnętrznych narzędzi do wyłuskania plików i złożenia z nich
> nowego rpma.

To jest najsensowniejsze z rozwiązań bo jest najbliższe temu, co robi
teraz repackage tylko za pomocą zewnętrznego narzędzia. W sumie to nawet
jest już takie narzędzie -- rpmrebuild. Nie używałem go od lat więc nie
wiem na ile jeszcze robi to co repackage, ale jeśli robi, to jest to
światełko w tunelu. Jedyne co, to potrzeba, żeby to było uruchamiane
automatycznie przy usuwaniu/podmianie pakietu, bo ręczne grzebanie się
z tym jest, co najmniej, podatne na ludzkie błędy (a to się zapomni
tego zrobić, a to się skasuje zrobioną paczkę, itp.).
Wiesz może na ile mozliwe jest, żeby to zautomatyzować w przypadku rpm4
i na ile sensowne (dające się potem zainstalować i działające) paczki
robi rpmrebuild?

> Wreszcie metoda 4 - skorzystanie z backupu jako podstawy do 2+3.

W przypadku pakietów to jest wyjście ostatniej szansy bo dostajesz
wyłącznie gołe pliki, a nie instalowalny pakiet. Przydaje się to w
przypadku totalnej katastrofy, gdy priorytetem jest ponowne uruchomienie
systemu/usługi/whatever, a nie eleganckie popaczkowanie softu.

> Dla mnie osobiście istotną cechą repackage było zachowanie zmian, jakie
> wprowadziłem lokalnie (np. w plikach konfiguracyjnych albo wprost
> podmieniając jakiekolwiek inne).

True. Absolutnie się z tym zgadzam.

> Chyba, że nie zachowuje się całkiem stabilnie i np. rozsypie się db.
> Albo w jakiś pokraczny sposób "radzi" sobie z --root cośtam.

Od dłuższego czasu mi się to już nie zdarzyło, ale ok, nie będę
polemizował, bo też miewałem tak, że coś tylko u mnie się posypało,
a nikt inny nie miał problemów.

> > i w zasadzie jedyne co, to teraz mnie tylko zaskoczył tym kompletnym
> > brakiem wsparcia do weryfikacji podpisów paczek.
> 
> Czyli mamy niebezpieczne pakiety,

No, to jest coś co mnie przeraziło biorąc pod uwagę, że rpm5 jest od
ładnych paru lat i prawdopodobnie od początku był z tym problem. Pluję
sobie w brodę, bo trzeba było to już dawno sprawdzić, a nie naiwnie
zakładać, że jak zaimportuję rpmowi klucze publiczne, a w poldku ustawię
"signed = yes" to będzie bezpiecznie. Coś ewidentnie z tym trzeba zrobić,
niezależnie od wersji rpma, która będzie w przyszłości w PLD.

> masy własnych pakietów, a mimo to używamy jako podstawy całej
> dystrybucji pakietu rozwijanego przez jedną osobę z jakimś aspergerowym
> syndromem w kontrze do reszty świata - nie widzisz tu problemu o wadze,
> odważę się stwierdzić, egzystencjalnej?

No, to prawda, z tym człowiekiem ciężko się komunikuje...

> Fajnie, że daliśmy mu szansę, ale minęły LATA i zapaść się pogłębia.
> Osobiście nie jestem w stanie budować wszystkich pakietów, jakich
> potrzebuję - posiłkuję się innymi dystrybucjami w nspawnie albo
> dockerem, ale tak również długo się nie da. Wolałbym na żywca próbować
> instalować obce pakiety poldkiem, choćby z jakimś wydzielonym --root.
> Szczególnie, gdy jest to jakiś prosty lib, który mi blokuje możliwość
> zbudowania pakietu (a łańcuszek zerwanych zależności skutecznie
> zniechęca do pracy). Nawet Debian wdrożył systemd - my będziemy się
> bardziej kurczowo niż oni trzymać ślepej drogi ewolucji?

Ok, tylko musi być jakaś alternatywa. Jeżeli jesteśmy w stanie aktualne
ficzery rpma 5 (albo przynajmniej te istotne, jak repackage) ogarnąć w
rpm 4 to ok, ale jeżeli to ma być upadek z deszczu pod rynnę, to nie
opłaca się ta cała zabawa z migracją bo będziemy tak samo w dupie, tylko
może w innym jej zakątku.
___
pld-devel-pl mailing list

Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-15 Wątek Adam Osuchowski
Tomasz Pala wrote:
> Do rpm4 się nie "cofasz" - to jest aktywnie rozwijany projekt.

Wiem, ale w PLD to jest cofnięcie bo już tam byliśmy. Lub jak bardzo Ci
się to słowo nie podoba to niech będzie "migracja do rpm4".

> Pozostając przy rpm5 mamy gwarancję stagnacji w imię jakichś tyrad nad
> strukturą nagłówka, wersją db czy teorią atomowego upgrade'u/rollbacku.
> rpm4 to jest inżynierska praktyka - może z jakimiś kompromisami, ale do
> przodu z rozwiązywaniem _realnych_ problemów.

Dla mnie repackage to jest bardzo fajna i ważna funkcjonalność i
rozwiązuje mi to często realne problemy w PLD, kiedy po upgradzie
coś jednak nie działa i trzeba się cofnąć. Jak to ogarnąć w rpm4?
Da się w ogóle zrobić sensownie rollback nie posiadając oryginalnej
paczki z poprzednią wersją?

Mnie rpm5 już przestał wkurzać i uważam, że jest ok. Owszem, na
początku było z nim kiepsko ale teraz zachowuje się w całkiem stabilnie
i w zasadzie jedyne co, to teraz mnie tylko zaskoczył tym kompletnym
brakiem wsparcia do weryfikacji podpisów paczek.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: W jaki sposób rpm weryfikuje podpisy pakietów?

2018-10-15 Wątek Adam Osuchowski
Paweł A. Gajda wrote:
> Da się to dostostosować - pytanie czy się nie narobię na próżno? Jeżeli
> zrobię port, to przejście na rpm.org już będzie bezbolesne/wykonalne/etc?

Ja z kolei siadłem nad tym, żeby dorobić do rpm5 porządną weryfikację
podpisów paczek bazując częściowo na rpm4, bo jak zajrzałem w kod to się
za głowę złapałem -- tam praktycznie nie ma żadnej sensownej weryfikacji
podpisów więc bezpieczeństwo aktualnych paczek to jest teraz jedna wielka
partyzantka o praktycznie zerowym poziomie wiarygodności.

Nie wiem co jest obecnie bardziej sensowne i mniej pracochłonne: cofnąć
się do rpm4 czy jednak poprawić to crypto w rpm5. Mimo wszystko wg mnie
chyba lepiej poprawić rpm5. Jak coś z tym wykombinuję to dam znać.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


W jaki sposób rpm weryfikuje podpisy pakietów?

2018-09-27 Wątek Adam Osuchowski
Pytanie może trochę dziwne, ale coś mi się nie zgadza.

Jeżeli podczas budowania pliku z paczką nie zostało wymuszone podpisywanie
(rpmbuild bez --sign), to rpm generuje na poczekaniu całkowicie nową parę
kluczy, publiczny umieszcza w budowanej paczce, a prywatnym podpisuje
całość. Taki plik całkowicie poprawnie się weryfikuje (rpm -K) mimo, że
taki podpis (self-sign) ma oczywiście zerową wartość. Czy da się jakoś
sprawić, by rpm nie uznawał za właściwie podpisane tego typu paczki?
Jak zmusić go, żeby pokazywał poprawną sygnaturę tylko wtedy, gdy jest
prawidłowo podpisana kluczem, który jest zainstalowany?

Poldek, który korzysta z bibliotek librpm*, zachowuje się oczywiście tak
samo. W zasadzie to chodzi tu głównie o niego, bo że działa instalacja
rpmem niepodpisanej paczki bezpośrednio z pliku to wiadomo (chociaż, tu
też mogłaby być robiona weryfikacja).

Jestem prawie pewny, że kiedyś (być może za czasów rpm 4) to działało,
to znaczy, że rpm weryfikował poprawnie tylko pakiety podpisane znanym
(czytaj: zainstalowanym) kluczem. Potem tego nie sprawdzałem i coś się
musiało zmienić (co najmniej to, że rpm 4 uruchamiał zewnętrzne gpg do
operacji crypto, a 5-tka ma to builtin). W tej sytuacji instalacja
jakichkolwiek paczek z sieci jest dosyć mało wiarygodna i bezpieczna.

Czy ktoś jest w stanie to potwierdzić, bo już zaczynam podejrzewać, że
to moja instalacja ma coś skopane?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Problem z OCSP na https://www.pld-linux.org/

2018-09-21 Wątek Adam Osuchowski
Czy ktoś władny mógłby sprawdzić co się dzieje z serwerem www
dla https://www.pld-linux.org/ ? Najwyraźniej ma on problem z
pobraniem tokenu OCSP, dzięki czemu wejście na stronę powoduje
że przeglądarka dłuuugo czeka na odpowiedź. openssl też wisi
ponad minutę, a potem mówi:

$ openssl s_client -connect www.pld-linux.org:443 -status < /dev/null
[...]
OCSP response:
==
OCSP Response Data:
OCSP Response Status: trylater (0x3)
[...]
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [packages/freerdp2] - up to 20180809

2018-09-04 Wątek Adam Osuchowski
arekm wrote:
> commit 196569ba2a63c99181a586e562e6f152c6604966
> Author: Arkadiusz Miśkiewicz 
> Date:   Sun Aug 12 14:24:55 2018 +0200
> 
> - up to 20180809
> 
>  freerdp-gsm.patch   | 12 ++--
>  freerdp-nla-KB4088776.patch | 24 
>  freerdp-sse.patch   | 20 
>  freerdp2.spec   | 14 --
>  4 files changed, 10 insertions(+), 60 deletions(-)

Czy możemy się cofnąć do poprzedniej wersji? Ta wersja nie działa.
Niby patche poprawiające błędy w poprzedniej wersji zostały wsadzone
do upstreama, ale nadal jest ten sam problem co poprzednio. Tyle,
że tym razem nawet nie wiadomo do końca co i jak poprawić bo pozmieniało
się również w masie innych miejsc. Problemy są nawet z najnowszą wersją
z upstreamowego gita.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


rc-scripts

2018-08-23 Wątek Adam Osuchowski
Czy nie lepiej byłoby zamiast dokładać patche do
https://git.pld-linux.org/?p=packages/rc-scripts.git zrobić
nową wersję tarballa rc-scripts (0.4.17?) z oryginalnego repozytorium
(http://git.pld-linux.org/?p=projects/rc-scripts.git)?

Od czasu 0.4.16 doszło w upstreamowym repozytorium trochę poprawek,
a nie wszystkie są w postaci patcha do budowania.

___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


problem z dostępem do git.pld-linux.org po IPv6

2018-06-27 Wątek Adam Osuchowski
Od paru godzin obserwuję problem z dostępem do git.pld-linux.org po IPv6
(2a01:390:a:0:216:3eff:fe00:1909). Po IPv4 śmiga bez zarzutów. Może ktoś
uprawniony sprawdzić czy coś się nie popsuło?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Problemy z syslog-ng-3.14.1-1

2018-05-21 Wątek Adam Osuchowski
stacho wrote:
> Po zainstalowaniu syslog-ng-3.14.1-1 "rzuca" się że
> config ma niekompatybilny i faktycznie mimo że to wersja 3.14
> to w /etc/syslog-ng/syslog-ng.conf pierwsza linia wygląda tak:
> =
> @version: 3.12
> @include "scl.conf"
> =

No to popraw to w tym pliku. Najwyraźniej miałeś poprzednio wersję 3.12
i robiłeś upgrade do 3.14, a konfig jak to konfig nie jest przez rpma
nadpisywany.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


poldek się sypie

2018-01-04 Wątek Adam Osuchowski
Poldek 0.32.2-3 na x86-64:


# ipoldek --sn th-i686 --sn th 'freshen -t --greedy *'
Loading [pndir]th-i686...
Loading [pndir]th...
Loading [pndir]th...
46475 packages read
error: openssl-1.0.2n-1.x86_64: refusing to upgrade held package
error: openssl-tools-1.0.2n-1.x86_64: refusing to upgrade held package
error: openssl-engines-1.0.2n-1.x86_64: refusing to upgrade held package
Processing dependencies...
[...]
error: openssl-1.0.2n-1.x86_64: refusing to upgrade held package
Something wrong, something not quite right with 0.32.2 (stable)
Assertion '!i3_is_marked(ictx, pkg)' failed, process.c:187
Please report this bug to: http://bugs.launchpad.net/poldek

Aborted


W pełni powtarzalne. Warunki, które muszą zajść, żeby to wywołać:
- parametry `--sn th-i686 --sn th' (podanie tylko jednego z tych źródeł
  nie generuje wyjątku)
- opcja `hold = openssl-*' w /etc/poldek/poldek.conf
- openssl w systemie musi być starszy niż w repo (poldek chce go podnieść)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


dwa dzisiejsze problemy w repo

2017-12-03 Wątek Adam Osuchowski
1. Zniknął postgresql 10, który był jeszcze parę dni temu. Powoduje to
takie problemy:

postgresql-9.6.6-1.x86_64 marks postgresql-libs-9.6.6-1.x86_64 (cap 
postgresql-libs = 9.6.6-1)
error: postgresql-libs-9.6.6-1.x86_64: newer version installed, give up

Downgrade? Jak tak, to może by epokę podnieść?

2. Niespójność w pakietach ruby:

poldek:/all-avail> upgrade ruby-minitest-5.8.5-2.3.5.4.noarch 
Processing dependencies...
ruby-minitest-4.7.5-1.noarch obsoleted by ruby-minitest-5.8.5-2.3.5.4.noarch
error: ruby-minitest-5.8.5-2.3.5.4.noarch (cap ruby-minitest = 5.8.5-2.3.5.4) 
conflicts with installed ruby-arel-3.0.3-3.noarch (ruby-minitest >= 5.0)

$ rpm -q --conflicts ruby-arel
ruby-hoe >= 4.0
ruby-minitest >= 5.0
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


profile.py i cProfile.py w różnych pakietach

2017-11-12 Wątek Adam Osuchowski
$ rpm -qf /usr/lib64/python3.6/cProfile.py
python3-modules-3.6.3-1.x86_64
$ rpm -qf /usr/lib64/python3.6/profile.py
python3-devel-tools-3.6.3-1.x86_64
$ grep ^import /usr/lib64/python3.6/cProfile.py
import _lsprof
import profile as _pyprofile
$ 


Nie wiem w którym pakiecie powinny być pliki cProfile.py i profile.py,
żeby było zgodnie ze sztuką, ale tak jak jest teraz to jest źle bo
python3-modules nie zależy od python3-devel-tools (i raczej nie powinien).

Można prosić autora tego ułożenia o odpowiednie przeniesienie do
właściwych pakietów?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: ngrep nie działa (patch na spec)

2017-07-03 Wątek Adam Osuchowski
Bartlomiej B. wrote:
> Jest teraz tak:
> # ngrep -tMpqld eth0 -W byline 'host x.x.x.x' ''  
> interface: eth0 (x.x.x.x/255.255.255.0)
> ngrep: symbol lookup error: ngrep: undefined symbol: pcap_restart
> # rpm -q ngrep libpcap
> 
> ngrep-1.45-4.x86_64
> libpcap-1.8.1-1.x86_64
> 
> Dodanie opcji configure --disable-pcap-restart rozwiązuje problem. Opcja ta 
> jest używana
> np. w Gentoo [1] czy Debianie [2].
> 
> [1] 
> https://gitweb.gentoo.org/repo/gentoo.git/tree/net-analyzer/ngrep/ngrep-1.45-r3.ebuild?id=61b861acd7b49083dab687e133f30f3331cb7480
> [2] 
> https://anonscm.debian.org/cgit/users/rfrancoise/ngrep.git/tree/debian/rules
> 
> Diff poniżej.

Zaaplikowane. Dzięki za poprawkę.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: 64-bitowe binarki w /usr/lib

2017-07-03 Wątek Adam Osuchowski
Tomasz Pala wrote:
> Ale jak wprowadził bałagan? Skoro już ustaliliśmy, że jest bez
> znaczenia, czy będzie lib czy lib64, to poziom bałaganu się tym commitem
> nie zmienił. A gdyby to przenieść do libexec, to by się zmniejszył - bo
> od razu byś wiedział, gdzie te pliki być POWINNY.

Nie ustaliliśmy tylko Ty ustaliłeś i to dopiero teraz. Ja chciałem się
tylko dowiedzieć dlaczego w PLD raz jest tak a raz inaczej, czemu dwa
różne pakiety w tej samej sytuacji (binarki do użytku wewnętrznego,
wykorzystywane wyłącznie przez daną aplikację; a o .so w ogóle nic nie
mówiłem) mają te pliki w dwóch różnych katalogach i od czego (lub kogo)
to zależy, a nie coś zmieniać. Ale ok, niech będzie, że jest w porządku,
nie będę kolejny raz tłumaczył o co mi chodzi. Przyjmuję do wiadomości
odpowiedź ,,bo tak'' i niech każdy pakiet ma to gdzie bądź.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: 64-bitowe binarki w /usr/lib

2017-06-30 Wątek Adam Osuchowski
Tomasz Pala wrote:
> No i powiedz mi, gdzie jest 'prawidłowiej'?

IMHO w /usr/lib64 ale to wyłącznie ze względu na multiliba. Na systemie
64-bit only osobiście mógłbym mieć wszystko w /usr/lib. Przynjamniej
dopełnianie w shellu byłoby prostsze.

> W takim razie ta lokalizacja jest bez znaczenia.

Owszem, z dokładnością do multiliba, jak wyżej. I pytanie co oznacza,
że jest bez znaczenia: że każdy może sobie wybrać co mu się podoba czy
że wybieramy którąś z nich ale jedną, żeby było spójnie?

> No, rozróżnianie po 'ważności' to już przesada. Nawet wyznacznik
> techniczny: 'system ma wstać bez dostępu do /usr', jest już mocno
> dyskusyjny, a co dopiero jakiśtam rpm.

Chyba nie rozumiem. Sam stwierdziłeś, że na rpmie się multiliba nie robi.
Zgoda. Ale skoro ,,ważność'' nie jest istotna, to na niczym się w takim
razie nie powinno robić.

> To nie jest jeszcze jeden potencjalny, a zupełnie inny - tam trafiają
> prywatne moduły, a nie biblioteki współdzielone. Funkcjonalne
> wydzielenie czegoś nie może zwiększać bałaganu...

Pisząc tu ,,współdzielone'' masz na myśli ogólnie biblioteki .so czy te,
które są używane przez więcej niż jeden pakiet? Bo jeżeli to drugie, to
w przypadku gita czy dovecota te binarki to są właśnie dokładnie własne
moduły i dlatego jakby był jeszcze możliwy trzeci katalog na ich
umiejscowienie (poza lib i lib64) to bałagan byłby jeszcze większy.

> Poza tym miałem na myśli coś jeszcze innego - mianowicie, jeżeli libexec
> jest używany w innych dystrybucjach, to jest obsługiwany przez
> buildsystemy aplikacji. Osobiście pamiętam kilka przypadków, gdy
> musiałem rzeźbić prefix aplikacji, żeby pasował %_libdir zależny od
> architektury. Czyli robić dodatkową robotę tylko dlatego, że nie mamy
> libexec. Prawdopodobnie ktoś tej dodatkowej roboty z gitem nie wykonał i
> w efekcie moduły gita zmieniły lokalizację, jak to właśnie zauważyłeś.

Ja bym powiedział raczej, że było dobrze i w pewnym momencie ktoś ten
bałagan celowo wprowadził:

https://git.pld-linux.org/?p=packages/git-core.git;a=blobdiff;f=git-core.spec;h=ad97d6bf6d5d1780af42cef74059fd5e76c3cdcd;hp=ef53117014cd23cbf07dae6cf3a611874876bb6f;hb=6743dd7eda7fdf45a0e70c079ac80440814754e9;hpb=ad39aec1a27ea283c19a4c450fa18d37ab0a7d28
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


64-bitowe binarki w /usr/lib

2017-06-27 Wątek Adam Osuchowski
Dlaczego w systemie 64-bitowym binarki wchodzące w skład gita są w /usr/lib
a nie w /usr/lib64? Pytanie dotyczy nie tylko gita bo niektóre inne pakiety
też tak mają, ale to jest dobry przykład. Jest jakiś konkretny powód, że
w niektórych przypadkach tak jest czy też po prostu to jakaś zaszłość albo
bałagan? Chociaż akurat w przypadku gita to raczej nie jest zaszłość bo
dawniej było /usr/lib64, a na /usr/lib zmieniło sie w lutym zeszłego roku.
Jak rozumiem nadal trzymamy się rozdziału /usr/lib i /usr/lib64?


$ uname -m
x86_64
$ file /usr/lib/git-core/* | grep 'ELF 64-bit LSB executable' | cut -f1 -d:
/usr/lib/git-core/git
/usr/lib/git-core/git-credential-cache
/usr/lib/git-core/git-credential-cache--daemon
/usr/lib/git-core/git-credential-store
/usr/lib/git-core/git-daemon
/usr/lib/git-core/git-fast-import
/usr/lib/git-core/git-http-backend
/usr/lib/git-core/git-http-fetch
/usr/lib/git-core/git-http-push
/usr/lib/git-core/git-remote-http
/usr/lib/git-core/git-remote-testsvn
/usr/lib/git-core/git-sh-i18n--envsubst
/usr/lib/git-core/git-shell
/usr/lib/git-core/git-show-index
/usr/lib/git-core/git-upload-pack
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


libmozsandbox.so w firefoksie

2017-05-17 Wątek Adam Osuchowski
Czemu firefox ze źródeł wymaga binarnego mozilla-firefox-bin skoro
oba zawierają libmozsandbox.so, a co więcej, firefox używa swojego,
a nie tego z mozilla-firefox-bin?


firefox-53.0-2.x86_64: required "libmozsandbox.so()(64bit)" is provided by the 
following packages:
a) mozilla-firefox-bin-53.0-1.x86_64
b) thunderbird-52.0.1-3.x86_64
Which one do you want to install ('Q' to abort)? 
[mozilla-firefox-bin-53.0-1.x86_64]
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem z indeksami poldka

2017-01-02 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
> zlib != 1.2.9-1 ? Jak nie to upgrade/downgrade

$ rpm -q zlib
zlib-1.2.9-2.x86_64

Na tej wersji są problemy. Downgrade do 1.2.8-2 pomógł. 1.2.9-1 nie
sprawdzałem. Ale to znaczy, że zlib dalej jest skopany...
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


problem z indeksami poldka

2017-01-02 Wątek Adam Osuchowski
Budowanie indeksu, które od daaawna robię zawsze tym samym poleceniem
pospuło się:

$ rpm -q poldek
poldek-0.32.2-3.x86_64
$ rm -rf packages.*
$ poldek -s `pwd` --mkidxz --mt pndir 
Creating pndir index of /home/users/builder/public_html/RPMS/ (type=dir)...
Loading [dir]/home/users/builder/public_html/RPMS/...
Writing /home/users/builder/public_html/RPMS/packages.ndir.gz...
$ poldek -s `pwd` --mkidxz --mt pndir 
Creating pndir index of /home/users/builder/public_html/RPMS/ (type=dir)...
error: /home/users/builder/public_html/RPMS/packages.ndir.gz: broken file
Loading [dir]/home/users/builder/public_html/RPMS/...
Writing /home/users/builder/public_html/RPMS/packages.ndir.gz...

Jak widać, pierwsze odpalenie jest ok, ale drugie sypie błędem.
Ale nawet jak tylko raz puszczę tworzenie indeksu, to i tak później
`poldek --up' sypie tym samym błędem i nie ładuje zawartości.
Strace pokazuje, że poldek nie może znaleźć pliku packages.ndir.gz.md5
(bo sam go nie tworzy) ale nawet ręczne utworzenie nie pomaga. Jest za
to plik packages.ndir.md, który zawiera jakąś 160-bitową sygnaturę (SHA1?)
która nie pasuje do żadnego pliku packages.* (może to jest problem?):

$ cat packages.ndir.md ; echo
7380d013862098c1eefe1a5232b9b155454b482b brand-new

Nie wiem od kiedy tak się dzieje bo już nie pamiętam kiedy ostatni raz
generowałem indeks, ale to jest kwestia góra 2-3 miesięcy. Zamiana
--mkidxz na --mkidx też nic nie daje.

Jednocześnie widzę, że indeksy z oficjalnego repo są ok. Czy coś w takim
razie robię źle przy odpalaniu poldka? Jakieś parametry nie tegez?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: lista pakietów na https://git.pld-linux.org/

2016-10-17 Wątek Adam Osuchowski
Jan Palus wrote:
> Skoro już jesteśmy przy temacie git.pld-linux.org... wiadomo może
> dlaczego przy wyszukiwaniu np 'firefox' nie znajduje pakietu o dokładnie
> takiej nazwie pomimo że ręcznie do jego repo można się dostać? Druga
> rzecz to czy byłaby możliwość zmiany wyszukiwania na case-insensitive?

Najprawdopodobniej z tego samego powodu, dla którego nie pojawia się na
liście na głównej stronie git.pld-linux.org, bo pewnie wyszukiwarka bazuje
na tej samej liście.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Błąd w zależnościach

2016-10-13 Wątek Adam Osuchowski
Jacek Osiecki wrote:
> A którego masz harfbuzza? Bo podejrzewam że nowszego niż 0.9.30???
> Ja miałem 0.9.40 i z nim był problem - dopiero po upgrade do 1.3.0 zaczęło 
> działać.

Ten symbol (hb_buffer_set_cluster_level) pojawił się dopiero od wersji
0.9.42, a że między 0.9.40 i 1.3.0 nie zmieniła się wersja soname
libharfbuzz.so (nic dziwnego, skoro w zasadzie 1.3.0 jest kompatybilne
w dół) to rpm nie bardzo miał szanse wykryć, że należy podnieść
bibliotekę. Dodatkowo w kodzie pango jest taki kawałek:

#if HB_VERSION_ATLEAST(1,0,3)
  hb_buffer_set_cluster_level (hb_buffer, 
HB_BUFFER_CLUSTER_LEVEL_MONOTONE_CHARACTERS);
#endif

Widać więc, że pakiet pango, który masz zainstalowany był budowany na
systemie z nowszym harfbuzzem. IMHO najsensowniejszym rozwiązaniem jest
tu podnieść w pango zależność od harfbuzz do 1.0.3 (obecnie jest 0.9.30).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Błąd w zależnościach

2016-10-13 Wątek Adam Osuchowski
Jacek Osiecki wrote:
> walczyłem przez pół dnia z niedziałającym inkscape.
> Wywalało cały czas, że brakuje symbolu:
> 
> inkscape: symbol lookup error: /usr/lib64/libpangoft2-1.0.so.0: undefined 
> symbol: hb_buffer_set_cluster_level
> 
> jakimś cudem znalazłem że to chodzi o harfbuzz??? tylko że on był 
> zainstalowany.
> Okazało się, że po upgradzie z wersji 0.9.40-1 do najnowszej (1.3.0-1) 
> problemy minęły.
> 
> Nie widzę by inkscape (0.91-10) wymagał harfbuzz więc pewnie to jest w 
> jakichś głębsze zależności (podejrzewam pango).
> 
> Ktoś ma pomysł jak to rozwiązać? Bezpośrednim wymaganiem konkretnej wersji 
> przez inkscape, wymaganie przez pango
> (czy cokolwiek go wymagało) konkretnej wersji zawierającej 
> hb_buffer_set_cluster_level?

$ rpm -q inkscape
inkscape-0.91-10.x86_64
$ rpm -q pango
pango-1.40.2-1.x86_64
$ rpm -qR inkscape | grep pango
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0()(64bit)
libpangoft2-1.0.so.0()(64bit)
libpangomm-1.4.so.1()(64bit)
$ rpm -qR pango | grep harfbuzz
harfbuzz >= 0.9.30
libharfbuzz.so.0()(64bit)
$ nm -D /usr/lib64/libharfbuzz.so.0 | grep hb_buffer_set_cluster_level
ae50 T hb_buffer_set_cluster_level

Jak widać, łańcuch zależności jest prawidłowy. Nie był to czasami
problem nie odświeżonego cache'a od ld.so? Mnie się czasami też tak
działo (już od dłuższego czasu się nie zdażyło) i pomagało odpalenie
ldconfiga.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


lista pakietów na https://git.pld-linux.org/

2016-10-11 Wątek Adam Osuchowski
Lista pakietów na stronie https://git.pld-linux.org/ wydaje się być
nieaktualna. Dotyczy to w zasadzie głównie wszystkich nowo tworzonych
pakietów (sprawdziłem te, które zostały utworzone w przeciągu ostatnich
2 lat ale problem chyba jest starszy), ale też i niektórych starych
(jak np. adapter). Wygląda to tak, jakby jakiś automat aktualizujący
tę listę nie działał. Brakujących pakietów jest trochę ponad 500.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: ImageMagick i tekst z pliku

2016-06-05 Wątek Adam Osuchowski
Adam Osuchowski wrote:
> Po ostatniej burzy i "rewelacjach" pod wielce medialną nazwą ImageTragick
> przestała działać możliwość renderowania tekstu z pliku lub stdina:
> 
> convert -font verdana.ttf -pointsize 72 label:@tekst.txt tekst.png
> 
> Zmieniłem wpis w /etc/ImageMagick-6/policy.xml na:
> 
> 
> 
> ale to nic nie pomogło. Nie pomogło też wywalenie tej linii w ogóle, jak
> również wywalenie całego policy.xml. W przykładach na stronie ImageMagicka
> nadal podają m.in. `label:@-' więc jak widać ich dokumentacja nie nadąża
> za rzeczywistością.
> 
> Czy ktoś wie jak teraz, po tych regresyjnych "usprawnieniach", przywrócić
> funkcjonalność renderowania tekstu z pliku? Może jednak trzeba coś
> poprawić w policy.xml tylko inaczej?

Jak się okazało, ta funkcjonalność jest domyślnie całkowicie wyłączona i
trzeba ją włączyć przy kompilacji (configure --enable-indirect-reads).
Dodatkowo jest błąd w oryginalnym configure.ac uniemożliwiający użycie
tej opcji. Zakomitowałem poprawkę, proszę o przebudowanie i wystawienie
na ftp rel 2.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


octave vs. octave-gui

2016-02-21 Wątek Adam Osuchowski
octave-4.0.0-1 nie wymaga octave-gui-4.0.0-1. Jednakże zainstalowanie tylko
tego pierwszego powoduje, że w graficznym środowisku jest taki efekt:

$ octave 
octave: failed to exec 
'/usr/lib64/octave/4.0.0/exec/x86_64-pld-linux-gnu/octave-gui'
$ octave --help
octave: failed to exec 
'/usr/lib64/octave/4.0.0/exec/x86_64-pld-linux-gnu/octave-gui'
$ octave --no-gui
octave: failed to exec 
'/usr/lib64/octave/4.0.0/exec/x86_64-pld-linux-gnu/octave-gui'

Przy braku zmiennej środowiskowej DISPLAY dopiero coś się pojawia:

$ unset DISPLAY ; octave --help
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
GNU Octave, version 4.0.0
Copyright (C) 2015 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
[...]

Trochę to dziwne i niewygodne, że octave nie pokaże nawet helpa bez gui,
skoro bez zmiennej DISPLAY potrafi się odpalić w trybie tekstowym.

IMHO w tej sytuacji albo nie ma sensu separacji octave i octave-gui albo
należałoby to zapatchować, żeby przy braku octave-gui uruchamiał się tryb
tekstowy niezależnie od zmiennej DISPLAY. Ja osobiście wybrałbym opcję
z patchem. Jakieś inne propzycje?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: opensmtpd

2016-02-12 Wątek Adam Osuchowski
stacho wrote:
> Obecna wersja z repo opensmptd "wywala" się w obecności openssl-1.0.2f .
> Poniżej "rozwiązanie" tego problemu, buduje się i działa, sprawdzone.

Podniesione.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: iptables-*.vserver.*

2016-01-31 Wątek Adam Osuchowski
Bartek Szady wrote:
> Co oznacza vserver w wersji pakietu iptables?
> Czy niesie to jakieś skutki dla tych którzy vserverów nie używają?

Moduł owner w wersji vserverowej dodatkowo obsługuje jeden parametr (xid)
przez co struktura w kodzie ma inny rozmiar. Userspaceowy moduł musi
być zgodny z tym w kernelu. Jeżeli nie używasz ownera, to nie ma znaczenia,
którą wersję wybierzesz.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: dbus-libs-1.10.6-1.i686 + multilib = problem z libgcrypt (mogę poprosić o spójne przebudowanie?)

2016-01-17 Wątek Adam Osuchowski
Łukasz Maśko wrote:
> Z jakiegoś powodu jest tak:
> poldek:/all-avail> desc libgcrypt-1.6.4-1.x86_64  
>   
>   
>   
>   
>   
> Package:libgcrypt-1.6.4-1.x86_64
> [...]
> Built:  2015/09/08 21:07 at ymir-builder
> Size:   1005.0 KB (1029664 B)
> Package size:   381.0 KB (390385 B)
> Path:   ftp://ftp.pld-linux.org/dists/th/PLD/x86_64/RPMS
> Source package: libgcrypt-1.6.4-1.src.rpm
> File:   libgcrypt-1.6.4-1.x86_64.rpm
> [...]
> poldek:/all-avail> desc libgcrypt-1.6.4-1.i686 
> 
> Package:libgcrypt-1.6.4-1.i686
> [...]
> Built:  2015/09/09 07:54 at nereid-builder
> Size:   754.0 KB (772966 B)
> Package size:   336.0 KB (345061 B)
> Path:   ftp://ftp.pld-linux.org/dists/th/PLD/i686/RPMS
> Source package: libgcrypt-1.6.4-1.src.rpm
> File:   libgcrypt-1.6.4-1.i686.rpm
> 
> Zostały zbudowane na różnych builderach i w różnych porach. I spakowane 
> manuale różnią się od siebie co do długości o 2 bajty (że o sumach 
> kontrolnych 
> nie wspomnę:
> na i686:
> $ ls -l /usr/share/man/man1/hmac256.1.gz
> -rw-r--r-- 1 root root 706 09-09 07:54 /usr/share/man/man1/hmac256.1.gz
> $ md5sum /usr/share/man/man1/hmac256.1.gz
> 41bba58f370caaa731d13b4ef2c0e4c6  /usr/share/man/man1/hmac256.1.gz
> 
> a na x86-64:
> $ ls -l /usr/share/man/man1/hmac256.1.gz
> -rw-r--r-- 1 root root 708 09-08 21:07 /usr/share/man/man1/hmac256.1.gz
> $ md5sum /usr/share/man/man1/hmac256.1.gz
> cf9c0bc87ffbf9144c35c99df1ced68d  /usr/share/man/man1/hmac256.1.gz
> 

Jak się rozgzipuje te spakowane manuale to różnica jest następująca:


--- i686/usr/share/man/man1/hmac256.1   2016-01-17 20:46:39.459810909 +0100
+++ x86-64/usr/share/man/man1/hmac256.1 2016-01-17 20:46:44.524789763 +0100
@@ -1,5 +1,5 @@
 .\" Created from Texinfo source by yat2m 1.0
-.TH HMAC256 1 2015-09-09 "Libgcrypt 1.6.4" "Libgcrypt"
+.TH HMAC256 1 2015-09-08 "Libgcrypt 1.6.4" "Libgcrypt"
 .SH NAME
 .B hmac256
 \- Compute an HMAC-SHA-256 MAC


Różnią się w dacie wyprodukowania pliku manuala. Daty te pokrywają się
z datami budowania paczek na builderach.

> Trzeba by to jeszcze raz spójnie przebudować i podbić wersję - mogę poprosić?

To nie jest rozwiązanie. Jak będą zbudowane w różnych dniach (a zawsze
się tak może zdarzyć), to problem pozostanie. To jest kwestia dołączonego
do źródeł libgcrypt programu yat2m, którym konwertowane jest texi do
manualowego troffa i który, nie wiadomo po co, dołącza do wynikowego pliku
aktualną datę. Chyba jego trzebaby poprawić, żeby tego nie robił.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


prośba o przebudowanie i wrzucenie libxml2 na ftp

2016-01-13 Wątek Adam Osuchowski
perl-XML-LibXML jest zlinkowany z nowszym libxml2 niż jest na ftpie:

Warning: XML::LibXML compiled against libxml2 20903, but runtime libxml2 is 
older 20902

Proszę o przebudowanie i wrzucenie na ftp.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


poldek się sypie

2015-11-23 Wątek Adam Osuchowski
Powtarzalnie:

$ poldek -s `pwd` --mkidxz --mt pdir
[...]
*** stack smashing detected ***: /usr/bin/poldek terminated
=== Backtrace: =
/lib64/libc.so.6(+0x73316)[0x388b90a0316]
/lib64/libc.so.6(__fortify_fail+0x37)[0x388b9128a17]
/lib64/libc.so.6(__fortify_fail+0x0)[0x388b91289e0]
/usr/lib64/libpoldek.so.2(+0x1abe7)[0x388b9a64be7]
/usr/lib64/libpoldek.so.2(+0x4ced0)[0x388b9a96ed0]
/usr/lib64/libpoldek.so.2(+0x4e087)[0x388b9a98087]
/usr/lib64/libpoldek.so.2(+0x3fbe2)[0x388b9a89be2]
/usr/lib64/libpoldek.so.2(pkgdir_save_as+0x5c2)[0x388b9a8b782]
/usr/lib64/libpoldek.so.2(+0x3ee2d)[0x388b9a88e2d]
/usr/lib64/libpoldek.so.2(source_make_idx+0xb0)[0x388b9a89330]
/usr/lib64/libpoclidek.so.0(+0x1058d)[0x388b9ce158d]
/usr/bin/poldek[0x404999]
/usr/bin/poldek[0x402848]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x388b904d690]
/usr/bin/poldek[0x402af9]


Pod gdb:

Program received signal SIGABRT, Aborted.
0x0388b9060888 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x0388b9060888 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x0388b9061d8a in __GI_abort () at abort.c:89
#2  0x0388b90a031b in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x388b9197ee4 "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x0388b9128a17 in __GI___fortify_fail (msg=msg@entry=0x388b9197ecc 
"stack smashing detected") at fortify_fail.c:31
#4  0x0388b91289e0 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x0388b9a64be7 in pkguinf_store_rpmhdr () from /usr/lib64/libpoldek.so.2
#6  0x0388b9a96ed0 in ?? () from /usr/lib64/libpoldek.so.2
#7  0x0388b9a98087 in ?? () from /usr/lib64/libpoldek.so.2
#8  0x0388b9a89be2 in ?? () from /usr/lib64/libpoldek.so.2
#9  0x0388b9a8b782 in pkgdir_save_as () from /usr/lib64/libpoldek.so.2
#10 0x0388b9a88e2d in ?? () from /usr/lib64/libpoldek.so.2
#11 0x0388b9a89330 in source_make_idx () from /usr/lib64/libpoldek.so.2
#12 0x0388b9ce158d in ?? () from /usr/lib64/libpoclidek.so.0
#13 0x00404999 in ?? ()
#14 0x00402848 in ?? ()
#15 0x0388b904d690 in __libc_start_main (main=0x402590, argc=6, 
argv=0x392ac60a8b8, init=, fini=, 
rtld_fini=, stack_end=0x392ac60a8a8)
at libc-start.c:289
#16 0x00402af9 in ?? ()


Co ciekawe, z `--mt pndir' się nie sypie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Bug w poldku

2015-10-21 Wątek Adam Osuchowski
W poldku 0.30.1 jest bug. Po wpisaniu jakiejs komendy, która instaluje
pakiety i naciśnięciu CTRL-C przed naciśnięciem entera pojawia się:

Something wrong, something not quite right with 0.30.1 (stable)
Assertion 'pkgs == NULL' failed, install.c:295

Spodowodowane jest to nie zwalnianiem struktury. Właściwy patch na to
w załączniku (o ile dobrze odczytałem ze źródeł intencje autora). Proszę
o założenie bo nie mam dostępu do repozytorium ze źródłami. BTW, dane
na stronie http://poldek.pld-linux.org/devel.html są trochę nieaktualne
(Gitorious został zamknięty).
diff -ruNp poldek-0.30.1.orig/install3/preinstall.c 
poldek-0.30.1/install3/preinstall.c
--- poldek-0.30.1.orig/install3/preinstall.c2014-03-25 23:32:25.0 
+0100
+++ poldek-0.30.1/install3/preinstall.c 2015-10-21 21:53:10.190934930 +0200
@@ -199,8 +199,10 @@ int i3_pre_ts_install(struct poldek_ts *
 if (!pkg_is_marked(ts->pms, pkg))
 continue;
 
-if (sigint_reached())
+if (sigint_reached()) {
+n_array_cfree(pkgs);
 return -1;
+}
 
 installable = i3_is_pkg_installable(ts, pkg, 1);
 
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Aktualizacja glibc do 2.22-7 (i686) = system nie wstaje.

2015-10-17 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
> Jest też alternatywne rozwiązanie - pozbycie się localedb-src, glibc-localedb-
> all i włączenie bibliotek locale do głównej paczki glibc. Dla mnie takie 
> rozwiązanie jest ok ale być może nie dla wszystkich.

IMHO to nie jest dobre rozwiązanie. glibc-localedb-all to paczka ok. 120 MB
danych, zawierająca prawie 400 języków i ich odmian, których większość przez
użytkowników większości instalacji nie jest nigdy wykorzystywana. Fakt, że
to jest jeden plik więc albo są zainstalowane wszystkie albo żaden, ale
w razie potrzeby zawsze można wygenerować sobie z localedb-src tylko
potrzebne wersje, a w niektórych przypadkach wystarczają nawet same locale
C i nie ma potrzeby trzymania wszystkich możliwych.

> W sumie nie ma co czekać. rel glibc-2.22-9 zawiera tą łatkę (poszło na
> buildery). Uprasza się o testy.

Działa. Przy podnoszeniu z 2.22-4 do 2.22-9 jest ok, nie ma żadnych
warningów i nic się nie wysypuje (a przynajmniej nie tak od razu i w
oczywisty sposób jak to było z 2.22-8). Wymuszenie downgradu
glibc-localedb-all do 2.22-4 przy reszcie glibcowych pakietów 2.22-9
też nie powoduje problemów więc IMHO należy to tak zostawić.

Zresztą spójności pomiędzy składowymi glibc pilnują zależności rpmowe,
a problem pojawia się tylko chwilowo po instalacji glibc a przed
instalacją glibc-localedb-all więc można to przeżyć na patchu, który
zaaplikowałeś.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: php55-fpm - kiedy będzie działać?

2015-10-08 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
> Jakbyś mógł jeszcze:
> 
> 10:17 < glen> i don't have time to work on this now. so ask the reporter to 
> open bugs.pld-linux.org item, and include backgtrace with -debuginfo symbols

https://bugs.launchpad.net/pld-linux/+bug/1504026
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: php55-fpm - kiedy będzie działać?

2015-09-21 Wątek Adam Osuchowski
Jacek Osiecki wrote:
> Albo nie widzę, albo faktycznie nikt nie odpisał.
> Czy w ogóle nikt tutaj nie używa php-fpm?
> Świeżo stworzony vserver, wrzucone do niego php55, w tym php55-fpm.

Problem jest też z PHP 5.6 i chyba jest powiązany z grsecurity w kernelu
(chyba, że u Ciebie występuje na nie-grsecowym). Mnie pomaga patch
(w załączniku), którego sobie sam wystrugałem na własne potrzeby ale nie
wiem czy należałoby go pchać do repozytorium.

Co do problemu, to wg mnie wygląda to tak. Pamięć, która jest zwalniana
przez to zakomentowane free() jest alokowana przez emalloc() (wewnętrzna
funkcja php do zarządzania pamięcią). Powinna więc być zwolniona przez
efree() ponieważ te funkcje emalloc(), efree, estrdup() itd. dodają sobie
swoje własne sygnatury alokowanych kawałków i trzymają je dodatkowo w jakimś
drzewie. Użycie free() w tym miejscu jest chyba pomyłką. Ale pomimo zmiany 
tego na efree() nadal nic to nie pomogło. Przeanalizowałem jeszcze trochę
kodu ale w końcu skończyła mi się cierpliwość i czas i to zakomentowałem
w całości. Wiem, że w ten sposób powataje memory leak ale IMHO jest
niegroźny gdyż to jest wołane w funkcji php_shutdown_config(), która jest
z kolei wołana przy kończeniu się procesu php. Memory leak jest więc w
zasadzie czysto teoretyczny i tylko podczas kończenia działania, a nie
podczas normalnej pracy.

Jeżeli nie ma przeciwwskazań do zaaplikowania takiego bądź co bądź
partyzanckiego patcha to mogę go wsadzić do repozytorium.

diff -ruNp php-5.6.13.orig/main/php_ini.c php-5.6.13/main/php_ini.c
--- php-5.6.13.orig/main/php_ini.c  2015-09-03 02:02:45.0 +0200
+++ php-5.6.13/main/php_ini.c   2015-09-18 12:55:56.454284557 +0200
@@ -726,7 +726,7 @@ int php_shutdown_config(void)
 {
zend_hash_destroy(_hash);
if (php_ini_opened_path) {
-   free(php_ini_opened_path);
+// free(php_ini_opened_path);
php_ini_opened_path = NULL;
}
if (php_ini_scanned_files) {
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: php55-fpm - kiedy będzie działać?

2015-09-21 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
> Możecie sprawdzić po revertnięciu commita 
> 762ec2ebe80654582c9a5f1114691cd6d673d513 ?

Tak, pomogło.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: czemu używamy niestabilnego binutils?

2015-08-07 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 Wrzuciłem 2.25.1 (może się iceweasel zbuduje z elfhack?).

Nie buduje się. Jakieś pomysły na obejście problemu czy --disable-elf-hack?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: czemu używamy niestabilnego binutils?

2015-08-04 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 Wrzuciłem 2.25.1 (może się iceweasel zbuduje z elfhack?).
 Zostało Ci tylko doprowadzić binutils-pt_pax_flags.patch do działania.

Widzę, że zanim się zdążyłem za to zabrać, to poprawiłeś. Dzięki. :)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: czemu używamy niestabilnego binutils?

2015-08-03 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Pierwsza z brzegu
 https://www.kernel.org/pub/linux/devel/binutils/binutils-2.21.51.0.7.tar.bz2

Beta z 2.21 może i jest (są nawet i z 2.24) ale z 2.25 już nie. A ostatnia
w ogóle pojawiła się tam ponad 1,5 roku temu. Może 2.25.51.* jest jakoś
wybitnie niestabilna. Zresztą faktycznie, na starszych PLDowych nie miałem
nigdy problemów, a teraz się zaczęły. Może więc z betami z 2.25 jest coś na
rzeczy i przejście na nie to nie był dobry pomysł.

 Kiedyś używały ale potem stwierdziły to samo co Ty, np wersji linux hjl 
 używano w f19
 http://pkgs.fedoraproject.org/cgit/binutils.git/plain/binutils.spec?h=f19

F19 może i używała ale kiedy to było. Pewnie wtedy, gdy te bety były
stabilniejsze.

 Zapewne możemy jeśli tylko ktoś zrobi owe binutils FSFowe u nas w gicie.

Czyli mam rozumieć, że w zasadzie nie ma przeciwwskazań technicznych a
jedynie kwestia zrobienia tego?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


czemu używamy niestabilnego binutils?

2015-08-03 Wątek Adam Osuchowski
Pytanie jak w temacie: dlaczego w PLD binutils jest w wersji 2.25.51.0.2?
Tej wersji nie ma nigdzie w żadnym oficjalnym repozytorium ze źródłami 
(https://www.kernel.org/pub/linux/devel/binutils/,
ftp://sourceware.org/pub/binutils, http://ftp.gnu.org/gnu/binutils/),
i nie zauważyłem, żeby jakakolwiek inna większa dystrybucja jej używała.
Za to w samych jej źródłach jest wyraźnie napisane:

This is the beta release of binutils 2.25.51.0.2 for Linux, which is
based on binutils 2015 0515 master branch on sourceware.org plus
various changes. It is purely for Linux.

Czy naprawdę potrzebne jest w PLD używanie wersji beta tak istotnego
softu? Przekonałem się o tym ostatnio sam osobiście próbując przez kilka
ładnych dni dojść do tego, dlaczego sypie się kernel 3.18.12 i nowsze
z linii 3.18.*. Okazało się, że jest to wina PLDowego binutils w tej
dziwnej wersji. Pomimo tego, że kernel się zbudował, tuż po uruchomieniu
system zwisał. Użycie do zbudowania oficjalnego stabilnego binutils
pomogło natychmiast. Czy nie możemy przejść na stabilne binutilsy w wersji
2.25.1 a ew. eksperymenty robić na boku?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


prawa i właściciel/grupa do /etc/nginx

2015-07-14 Wątek Adam Osuchowski
Czemu prawa dostępu i właściciel/grupa do /etc/nginx wyglądają tak?

$ ls -ld /etc/nginx
drwxr-xr-- 5 root root 4096 May 14 11:24 /etc/nginx

Procesy potomne nginxa chodzą z usera nginx i jeżeli potrzebują coś z
tego katalogu odczytać w trakcie pracy (np. plik z danymi userów do
http basic auth) to jest problem.

Czy komuś bardzo zależy na takiej konfiguracji? IMHO powinno wyglądać to
tak:

drwxr-x--- 6 root nginx 4096 Jul 14 13:52 /etc/nginx

ewentualnie tak:

drwxr-xr-- 6 root nginx 4096 Jul 14 13:52 /etc/nginx

Jak nie będzie przeciwwskazań to zmienię bo nie widzę, żeby coś się od
tego psuło.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: prawa i właściciel/grupa do /etc/nginx

2015-07-14 Wątek Adam Osuchowski
Tomasz Pala wrote:
 No akurat 'r' na katalogu można sobie darować przy dostępie do
 konkretnych plików (wtedy sam 'x') - bez 'x' ma to średni sens.

Takie ustawienia praw dla other (r--) są w tej chwili. Nie wiem po co,
dla mnie też bez sensu ale może komuś potrzebne więc nie chciałem
całkowicie rozwalać tego co jest.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: php56-fpm się sypie

2015-04-22 Wątek Adam Osuchowski
Adam Osuchowski wrote:
 U mnie w pełni powtarzalne na kilku różnych maszynach na x86_64.
 Ktoś może potwierdzić i/lub wie o co chodzi?

Dodatkowe informacje: php55-fpm-5.5.23-1.x86_64 też się sypie.

# tail -10 /var/log/php/php55-fpm.log 
[22-Apr-2015 23:30:48] NOTICE: fpm is running, pid 28564
[22-Apr-2015 23:30:48] NOTICE: ready to handle connections
[22-Apr-2015 23:30:53] WARNING: [pool t2] child 28570 exited on signal 11 
(SIGSEGV) after 5.539321 seconds from start
[22-Apr-2015 23:30:53] NOTICE: [pool t2] child 28645 started
[22-Apr-2015 23:30:55] WARNING: [pool t2] child 28571 exited on signal 11 
(SIGSEGV) after 6.740629 seconds from start
[22-Apr-2015 23:30:55] NOTICE: [pool t2] child 28659 started
[22-Apr-2015 23:31:01] WARNING: [pool t2] child 28572 exited on signal 11 
(SIGSEGV) after 13.400088 seconds from start
[22-Apr-2015 23:31:01] NOTICE: [pool t2] child 28762 started
[22-Apr-2015 23:33:19] WARNING: [pool t2] child 28573 exited on signal 11 
(SIGSEGV) after 151.531588 seconds from start
[22-Apr-2015 23:33:19] NOTICE: [pool t2] child 1876 started

ale downgrade glibc do glibc-2.20-6.x86_64 pomaga chociaż przy starcie
i tak pojawia się ,,[FAIL]'' (procesy php-fpm działają i obsługują
żądania).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


php56-fpm się sypie

2015-04-22 Wątek Adam Osuchowski
# service php56-fpm start 
Starting PHP FastCGI Process Manager (php56-fpm) 
service[
 BUSY ]*** Error in `/usr/sbin/php56-fpm': free(): invalid pointer: 
0x02cf3de42080 ***
=== Backtrace: =
/lib64/libc.so.6(+0x722ae)[0x2cf3b7332ae]
/lib64/libc.so.6(+0x7778e)[0x2cf3b73878e]
/lib64/libc.so.6(+0x77f6b)[0x2cf3b738f6b]
/usr/lib64/libphp_common-5.6.7.so(php_shutdown_config+0x21)[0x2cf3d88a8a1]
/usr/lib64/libphp_common-5.6.7.so(php_module_shutdown+0x3e)[0x2cf3d883ece]
/usr/sbin/php56-fpm[0x412379]
/usr/sbin/php56-fpm(fpm_cleanups_run+0x56)[0x40b536]
/usr/sbin/php56-fpm(fpm_unix_init_main+0x621)[0x418471]
/usr/sbin/php56-fpm(fpm_init+0x73)[0x40a773]
/usr/sbin/php56-fpm(main+0x795)[0x407455]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x2cf3b6e18a0]
/usr/sbin/php56-fpm(_start+0x29)[0x408699]
=== Memory map: 

# rpm -q php56-fpm glibc
php56-fpm-5.6.7-1.x86_64
glibc-2.21-2.x86_64

U mnie w pełni powtarzalne na kilku różnych maszynach na x86_64.
Ktoś może potwierdzić i/lub wie o co chodzi?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


[POLDEK] Problem z wieloma protokołami w definicji zewnętrznego narzędzia do pobierania pakietów

2015-04-22 Wątek Adam Osuchowski
Wg opisu w pliku /etc/poldek/fetch.conf, przy definicji zewnętrznego
polecenia do pobierania pakietów, można podać w jednej linii wiele
protokołów:

# [fetcher]
# name  = NAME
# proto = PROTOCOL[ ,PROTOCOL... ]
# cmd   = CMD [OPTION...] DESTINATION-MACRO URL-MACRO

ale taki kawałek konfiga:

[fetcher]
proto = http,ftp,https
cmd   = wget -N --dot-style=binary -P %d %Pn

nie działa:

# poldek --upa --sn test
Retrieving test::packages.dir.mdd...
error: vfile: https://...: no external fetcher for this type of url found
Retrieving test::packages.dir.mdd...
error: vfile: https://...: no external fetcher for this type of url found

Pozostawienie pojedynczego protokołu:

[...]
proto = https
[...]

rozwiązuje problem.

Niedoróbka, bug czy dokumentacja wyprzedziła rzeczywistość?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Gdzie umieszczać katalogi z perlowych modułów?

2015-04-05 Wątek Adam Osuchowski
Załóżmy, że mamy pakiet z modułem perlowym A::B, który zawiera pliki:

/usr/share/perl5/vendor_perl/A/B.pm
/usr/share/perl5/vendor_perl/A/B/C.pm

Wówczas katalog /usr/share/perl5/vendor_perl/A/B jak również powyższe
pliki powinny należeć do pakietu perl-A-B. Ale gdzie powinien należeć
katalog /usr/share/perl5/vendor_perl/A jeżeli nie ma perlowego modułu
o nazwie A lub takowy istnieje ale A::B od niego nie zależy i w systemie
może być zainstalowany tylko A::B? Zawsze do pakietu perl-dirs czy też
stworzyć jakiś metapakiet perl-A, który by zawierał tylko ten jeden
katalog czy jeszcze inaczej? Jaka zasada obowiązuje w powyższych kwestiach
w PLD?

Pytanie to tyczy się również katalogów w /usr/lib*/perl5 ale domyślam się,
że zasada w obu miejscach obowiązuje ta sama.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: zdalny mirror ftp bez indeksów

2015-03-14 Wątek Adam Osuchowski
Krzysztof Szwaba wrote:
 Na zdalnym mirrorze ftp
 ftp://ftp.polsl.pl/pub/linux/PLD/3.0/.archive/PLD/i686/RPMS/
 nie ma indeksów packages.ndir.*

Nie ma bo to w założeniu było moje własne archiwum pakietów na wypadek
gdyby był mi jakiś potrzebny, a wyleciał już z oficjalnego ftpa.
Upubliczniłem je bo może się komuś jeszcze przydać ale jest to archiwum
nieoficjalne i od dość dawna już nie jest aktualizowane (być może wrócę
kiedyś do tego tematu jak będzie potrzeba).

 Czy jest możliwe wykorzystanie takiego zdalnego źródła jako lokalne ?

W takim stanie jak teraz nie, bo jak sam zauważyłeś brak jest indeksów.
Nie było tworzone po to, żeby go dopisywać do konfiga poldkowego jako
repozytorium tylko ściągać pojedyncze pakiety w razie potrzeby.

 Ewentualnie w jaki sposób można samemu wygenerować brakujące indeksy po
 zassaniu plików na własny serwer ftp ?

Wystawić pakiety po ftp/http w jakimś katalogu i wygenerować indeksy:

poldek -s katalog --mkidxz --mt pndir
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: rpmbuild rozwiązuje makra w zakomentowanych liniach

2015-01-07 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Tak właśnie to działa. Użyj %% do cytowania makr.

Sama zamiana % na %% powoduje błąd składni:


$ grep define test.spec
%%define makro 'ala ma kota'
$ rpmbuild -bp test.spec 
error: line 8: Malformed tag: %define makro 'ala ma kota'


Ale już takie coś działa, chociaż nie wiem czy to o to Ci chodziło:


$ grep define test.spec
#%%define makro 'ala ma kota'
$ rpmbuild -bp test.spec
Executing(%prep): /bin/sh -e /home/users/adwol/tmp/rpm-tmp.67665
+ umask 022
+ cd /home/users/adwol/rpm/BUILD
+ echo xyz
xyz
+ echo %{makro}
%{makro}
+ exit 0


I jeżeli mam być szczery to jest to dziwne...
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: rpmbuild rozwiązuje makra w zakomentowanych liniach

2015-01-07 Wątek Adam Osuchowski
Light-I wrote:
 Spróbuj double hasha (##)???

Wstawianie wielu hashy nic nie daje. Efekt jest ten sam -- dalej makro
jest interpretowane.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


rpmbuild rozwiązuje makra w zakomentowanych liniach

2015-01-07 Wątek Adam Osuchowski
Zaobserwowałem, że pomimo zakomentowania w specu linii definiujących
makra i określających początek poszczególnych sekcji, nadal są one
interpretowane. To chyba nie powinno tak działać.


$ cat test.spec 
Summary:Test
Name:   test
Version:1.0
Release:1
License:GPL v2
Group:  Test

#%define makro 'ala ma kota'

%description

#%prep echo xyz

echo %{makro}

$ rpmbuild -bp test.spec 
Executing(%prep): /bin/sh -e /home/users/adwol/tmp/rpm-tmp.36402
+ umask 022
+ cd /home/users/adwol/rpm/BUILD
+ echo xyz
xyz
+ echo 'ala ma kota'
ala ma kota
+ exit 0


Co ciekawe, zakomentowanie np. %description działa poprawnie:


$ rpmbuild -bp test.spec 
error: Package has no %description: test-1.0-1.x86_64


Błąd raczej nie siedzi w makrach z /usr/lib/rpm tylko w samym librpm,
ale nie mam zdrowia, żeby siedzieć w źródłach od tego. Może ktoś na to
spojrzeć?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: The future of i486 arch in Th

2015-01-02 Wątek Adam Osuchowski
Jacek Konieczny wrote:
 Jest chyba różnica między niezdefiniowaniem jakiegoś podejrzanego
 aliasa, którego każdy, kto potrzebuje, może sobie sam ustawić, a
 skompilowaniem całej dystrybucji tak, że u niektórych nawet nie
 zabootuje, o ile ktoś sobie całości dla swoich potrzeb nie przekompiluje.

Dlaczego podejrzanego? W czym ten alias jest bardziej podejrzany od
zmiennej z opcjami, którą się pies z kulawą nogą nie interesował, leżała
spokojnie przez całe lata i pewnie nadal by leżała nie powodując końca
świata, gradobicia i kataklizmów, gdyby nie jej porzucenie przez developera?
Jedyna różnica to taka, że była domyślnie zakomentowana, ale zakomentowany
defaultowo alias i tak pewnie by kłuł w oczy co poniektórych.

Nie chodzi mi o to, żeby na siłę ustawiać tego aliasa tylko o określenie
zasad definiowania takich aliasów (i zmiennych) na poziomie systemu.
Innymi słowy: które aliasy/zmiene są podejrzane, a które nie?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem ze spójnością bazy rpmów

2015-01-02 Wątek Adam Osuchowski
Jaroslaw Kruk wrote:
 Zobacz czy pomoże Ci rpm -e --justdb

Niestety...

# rpm -e --justdb js185-debuginfo   
error: package js185-debuginfo is not installed
# rpm -qa | grep js185-debuginfo
js185-debuginfo-1.0.0-3.x86_64
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem ze spójnością bazy rpmów

2015-01-02 Wątek Adam Osuchowski
Jaroslaw Kruk wrote:
 rpm -e --justdb --force js185-debuginfo

--force przy usuwaniu nie działa w ogóle:

# rpm -e --justdb --force js185-debuginfo
rpm: only installation, upgrading, rmsource and rmspec may be forced

Wydaje mi się, że raczej to nie jest wykonalne przy pomocy samego rpma.
Bardziej bym się skłaniał ku jakimś magicznym poleceniom operującym
bezpośrednio na plikach DB.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem ze spójnością bazy rpmów

2015-01-02 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 Zrób backup bazy, skasuj wszystkie pliki (włącznie z logami w log/)
 oprócz Packages i wykonaj 'rpm --rebuilddb'

To właśnie nie działa na rpmie 5. Nawet na spójnej bazie. Próbowałem
tego na samym początku.

# rpm --rebuilddb
rpmdb: BDB2506 file /var/lib/rpm/Packages has LSN 256/7130536, past end of log 
at 1/64
rpmdb: BDB2507 Commonly caused by moving a database from one database 
environment
rpmdb: BDB2508 to another without clearing the database LSNs, or by removing 
all of
rpmdb: BDB2509 the log files from a database environment
rpmdb: BDB0641 __db_meta_setup: /var/lib/rpm/Packages: unexpected file type or 
format
error: cannot open Packages(0) index: Invalid argument(22)
DB: Berkeley DB 5.2.42: (February 29, 2012)
error: cannot open Packages database in /var/lib/rpm

Żeby --rebuilddb działał potrzebuje plików z logami, Filepaths i Packages
ale mimo że grzebie coś po bazie to nic to nie daje. Zresztą chyba ktoś
wspominał kiedyś, że o --rebuilddb w zasadzie można zapomnieć i teraz
tylko dbX.Y_recover -ev.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: problem ze spójnością bazy rpmów

2015-01-02 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 Spróbuj jeszcze /usr/lib/rpm/bin/dbupgrade.sh

O! I to było to. Teraz jest już czysto. Dzięki wielkie za pomoc. :)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


problem ze spójnością bazy rpmów

2015-01-01 Wątek Adam Osuchowski
Sytuacja następująca: system z rpm-5.4.15-3.x86_64, podczas usuwania
jednego z dawno zainstalowanych pakietów pojawiło się:

# rpm -e js185-debuginfo-1.0.0-3.x86_64
[...]
rpmdb: /var/lib/rpm/Packages: BDB0088 DB_SECONDARY_BAD: Secondary index 
inconsistent with primary
error: db3cdel:db3.c:1574: dbcursor-del(-30972): BDB0088 DB_SECONDARY_BAD: 
Secondary index inconsistent with primary
[...]

I teraz niby go nie ma, ale występuje na liście zainstalowanych:

# rpm -q js185-debuginfo
package js185-debuginfo is not installed
# rpm -qa | grep js185-debuginfo
js185-debuginfo-1.0.0-3.x86_64

Jakieś pomysły co z tym zrobić? Jak naprawić tak skopaną bazę rpmów?
Odpalanie magicznego `db5.2_recover -ev' nic nie daje. Kiedyś (za czasów
rpma 4.x) wystarczyło usunąć wszystkie pliki z /var/lib/rpm za wyjątkiem
Packages i rebuild naprawiał większość problemów. Teraz to nie jest już
takie proste. Nie pomaga również ponowne zainstalowanie i odinstalowanie
tego pakietu (pojawia się wtedy podwójnie a usunięcie usuwa tylko jedną
instancję).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: The future of i486 arch in Th

2015-01-01 Wątek Adam Osuchowski
Jacek Konieczny wrote:
 To byłoby wypięcie się na niektórych (owszem, pojedynczych) użytkowników
 w pogoni za numerkami.

Taaa? A jeszcze niedawno twierdziłeś, że nie ma po co utrzymywać
/etc/env.d/GREP_OPTIONS lub jego funkcjonalnego odpowiednika w postaci
aliasa, tylko dla pojedynczych użytkowników. Ciekawe jak to punkt
widzenia zależy od punktu siedzenia i własnego interesu...

BTW, czy mogę się ostatecznie dowiedzieć jaki będzie los innych aliasów
ustawianych w /etc/shrc.d/*? Dlaczego jedne aliasy mogą być narzucane
użytkownikowi przez system, a inne nie (pomimo, że każdy z nich można
przecież nadpisać we własnej konfiguracji)?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Source-md5 w specach

2014-10-27 Wątek Adam Osuchowski
Jaki jest cel trzymania Source-md5 w specach? Czy chodzi tylko o rozłożenie
plików na ftpie (vide http://distfiles.pld-linux.org/distfiles/by-md5/...)
czy służy też weryfikacji integralności paczek źródłowych? Jeżeli to drugie,
to może pora na zmianę md5 na sha1 albo sha256? Gdy repozytorium było
w cvsie nie miało to większego znaczenia, ale w przypadku gita robi się
z tego łańcuch zaufania: bezpieczny dostęp do gita (ssh/https) - drzewo
obiektów identyfikowane przez sha1 - skrót pliku z paczką źródłową. Zmiana
md5 na coś bezpieczniejszego wyeliminowałoby słabe ogniwo.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Statyczne pliki nie działają na https://git.pld-linux.org/

2014-10-24 Wątek Adam Osuchowski
Kacper Kornet wrote:
 Powinno już być dobrze. Dzięki za złoszenie.

Działa. Jeszcze jakby poprawić linki:

link rel=shortcut icon href=http://www.pld-linux.org/favicon.ico; 
type=image/png /
img width=72 alt=git src=http://www.pld-linux.org/_media//wiki/logo.png; 
class=logo height=27 /

na względne to by nie problemów z cross-origin.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Suspend/hibernacja w systemach non-systemd

2014-10-23 Wątek Adam Osuchowski
Adam Osuchowski wrote:
 W upower 0.99.x zostało usunięte wsparcie do suspendu/hibernacji.
 Wyleciały m.in. dbusowe metody Suspend(), Hibernate(), CanSuspend()
 i CanHibernate(). W związku z powyższym serwis dbusowy
 org.freedesktop.PowerManagement też nie działa bo bazuje na upower.
 Jak mniemam, pm-utils, które było do tej pory wykorzystywane, jest już
 passé i teraz upower korzysta z systemd (albo mi się tylko tak wydaje).
 
 Jak w tej sytuacji powinno się usypiać/hibernować system bez systemd?
 
 Po krótkich poszukiwaniach widzę, że inni też mają z tym problem
 (np. gentoo) i go rozwiązali (albo tylko próbowali) przez stworzenie
 drugiego pakietu upower-pm-utils bazującego na ostatniej działającej
 wersji, tj. 0.9.23. Sprawdziłem to i po uruchomieniu z palca starego
 upower wszystko wraca do normy. Możnaby więc dołożyć taki pakiet dla
 systemów, które używają SyVinit. Pytanie tylko, czy jest na to jakieś
 lepsze rozwiązanie i jak to teraz powinno wyglądać?

Ponieważ nie ma odzewu, zakomitowałem upower-pm-utils 0.9.23 zastępujące
upower. upower i upower-pm-utils, co oczywiste, wzajemnie się obsoletują.
Puściłem testowe zlecenie na builder i jest ok, można puścić zwykłe i
wystawić w th-test/th-ready.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Statyczne pliki nie działają na https://git.pld-linux.org/

2014-10-23 Wątek Adam Osuchowski
Nie da się pobrać https://git.pld-linux.org/static/gitweb-site.css
i https://git.pld-linux.org/static/gitweb-site.js
Sama strona po httpsie się ładuje, ale co najmniej te 2 pliki nie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Segfaultuje nginx-light-1.7.6-1.x86_64

2014-10-21 Wątek Adam Osuchowski
Jak w temacie. Nie dość, że segfaultuje, to jeszcze jakiś jego wewnętrzny
handler obsługujący ten sygnał też się wysypuje, co powoduje lawinę: load
skacze, a log jest zasypywany wpisami postaci:

[1719586.092433] nginx-light[32376]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.093240] nginx-light[32377]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.093472] nginx-light[32378]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.093719] nginx-light[32379]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.094135] nginx-light[32380]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.094681] nginx-light[32381]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.095687] nginx-light[32382]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.096033] nginx-light[32383]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.096431] nginx-light[32384]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]
[1719586.096968] nginx-light[32385]: segfault at 0 ip 00420aa4 sp 
03e4d71534a0 error 4 in nginx-light[40+d]

U mnie występuje na 3 różnych fizycznych maszynach, więc to raczej nie
jest problem sprzętowy. Wersja 1.7.3 działa poprawnie. Ktoś może to
potwierdzić?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Suspend/hibernacja w systemach non-systemd

2014-10-21 Wątek Adam Osuchowski
W upower 0.99.x zostało usunięte wsparcie do suspendu/hibernacji.
Wyleciały m.in. dbusowe metody Suspend(), Hibernate(), CanSuspend()
i CanHibernate(). W związku z powyższym serwis dbusowy
org.freedesktop.PowerManagement też nie działa bo bazuje na upower.
Jak mniemam, pm-utils, które było do tej pory wykorzystywane, jest już
passé i teraz upower korzysta z systemd (albo mi się tylko tak wydaje).

Jak w tej sytuacji powinno się usypiać/hibernować system bez systemd?

Po krótkich poszukiwaniach widzę, że inni też mają z tym problem
(np. gentoo) i go rozwiązali (albo tylko próbowali) przez stworzenie
drugiego pakietu upower-pm-utils bazującego na ostatniej działającej
wersji, tj. 0.9.23. Sprawdziłem to i po uruchomieniu z palca starego
upower wszystko wraca do normy. Możnaby więc dołożyć taki pakiet dla
systemów, które używają SyVinit. Pytanie tylko, czy jest na to jakieś
lepsze rozwiązanie i jak to teraz powinno wyglądać?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Segfaultuje nginx-light-1.7.6-1.x86_64

2014-10-21 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Co mówi bt w gdb?

#0  ngx_event_process_posted (cycle=optimized out, posted=0xe01870 
ngx_rtmp_init_queue) at src/event/ngx_event_posted.c:31
#1  0x00490e30 in ngx_rtmp_stat_init_process (cycle=optimized out) at 
nginx-rtmp-module/ngx_rtmp_stat_module.c:118
#2  0x00425f7e in ngx_worker_process_init (cycle=cycle@entry=0x21e3a10, 
worker=worker@entry=0) at src/os/unix/ngx_process_cycle.c:981
#3  0x00426560 in ngx_worker_process_cycle 
(cycle=cycle@entry=0x21e3a10, data=data@entry=0x0) at 
src/os/unix/ngx_process_cycle.c:746
#4  0x00424f66 in ngx_spawn_process (cycle=cycle@entry=0x21e3a10, 
proc=proc@entry=0x426540 ngx_worker_process_cycle, data=data@entry=0x0, 
name=name@entry=0x4a88b6 worker process, respawn=respawn@entry=-3)
at src/os/unix/ngx_process.c:198
#5  0x00426800 in ngx_start_worker_processes 
(cycle=cycle@entry=0x21e3a10, n=5, type=type@entry=-3) at 
src/os/unix/ngx_process_cycle.c:368
#6  0x004272e0 in ngx_master_process_cycle 
(cycle=cycle@entry=0x21e3a10) at src/os/unix/ngx_process_cycle.c:140
#7  0x004077d7 in main (argc=optimized out, argv=optimized out) at 
src/core/nginx.c:407
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en

2014-10-21 Wątek Adam Osuchowski
arekm wrote:
 commit e02b6d37706201456a69b1fecd0e54304bb8d0f5
 Author: Arkadiusz Miśkiewicz ar...@maven.pl
 Date:   Mon Oct 20 19:45:36 2014 +0200
 
 - rel 2; disable unsecure protocols
 (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE)
 - enable enable-ec_nistp_64_gcc_128 on x86_64
 
 [...]

 + no-ssl2 \
 + no-ssl3 \

Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że
należy od razu wywalić dla nich support. Te opcje usuwają również możliwość
łączenia się z klienta s_client za pomocą SSL2/SSL3, a to jest potrzebne,
chociażby po to, żeby sprawdzić czy dany serwis nie obsługuje przez
przypadek SSL2/SSL3 (że nie wspomnę o tym, że część usług jeszcze chodzi
na SSL3). Zresztą w przypadku serwera wywalanie tego też jest bez sensu,
z analogicznych powodów. Ograniczanie dostępności protokołów powinno mieć
miejsce na poziomie konfiguracji aplikacji, a nie fizycznym wywaleniu
supportu z biblioteki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en

2014-10-21 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Co wcale nie oznacza, że należy ów support zostawiać.

Co najmniej psuje to w drastyczny sposób kompatybilność i stan obecny.

 Jak zwykle kwestia dyskusyjna. Część aplikacji nie ma możliwości konfiguracji 
 protokołów (np. wyszło przy okazji, że libghttp nawet nie korzystał z TLS 
 tylko jechał na SSLv2).

IMHO to wina libghttp i jego by trzeba było spatchować zamiast openssla.
Ktoś jeszcze zna jakieś takie pakiety, który zachowują się podobnie?
BTW, jak taki soft nie używa w ogóle TLSa to po wywaleniu SSLi z openssla
w ogóle przestanie działać.

 Debian np robi dokładnie w ten sposób - wyłącza na poziomie openssl tym samym 
 'wyłączając wszystkim aplikacjom.

To, że debian robi zamordyzm nie oznacza, że PLD też musi. Podałem przykład
gdzie to jest problematyczne (i mówie to z własnego doswiadczenia). Usunięcie
supportu z klienta może dać złudną nadzieję, że serwer jest poprawnie
skonfigurowany.

 Od razu mówię, że nie upieram się na siłę.
 
 Jak zwykle w PLD, jak ktoś potrzebuje to się zostawia... więc istnieje 
 możliwość powrotu do poprzedniej opcji.

To prosiłbym o przywrócenie poprzedniego stanu.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en

2014-10-21 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Commituj, rw z tego co widzę masz. Teraz wystarcza przełączyć bcondy.

Ok.

 Osobiście bym dał:
 
 zlib - wyłączone
 sslv2 - wyłączone
 sslv3 - włączone

Ja się SSL2 nie chcę pozbywać. On jest uznawany za niebezpieczny od
dawna i do tej pory jakoś z tym żyliśmy, a jest potrzebny do tego samego
co SSL3. Co do zliba to nie mam zdania. Komuś jest zlib potrzebny?
Na razie przywróciłem domyślnie tak jak było.

 ps2. do testowania publicznych serwisów https niezły jest:
 https://www.ssllabs.com/ssltest/analyze.html

Wiem, znam, ale po pierwsze, jak sam zauważyłeś jest tylko do publicznych
serwisów, po drugie potrafi tylko skanować port 443 i bez starttlsa, po
trzecie jest dość wolny bo sprawdza jeszcze wiele innych rzeczy (np. szyfry,
itp.), po czwarte nie da się go oskryptować i robić testów wsadowo/okresowo.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


apache-2.4.10-2.x86_64 sypie się przy reloadzie

2014-09-22 Wątek Adam Osuchowski
Jak w temacie. Reload apache komendą:

/usr/sbin/httpd -f /etc/httpd/apache.conf -k graceful

która jest m.in. odpalana z logrotate, powoduje dziwne zachowanie
apacha. W logu pojawiają się segfaulty:

[Mon Sep 22 10:40:26.151362 2014] [core:notice] [pid 27358] AH00052: child pid 
28348 exit signal Segmentation fault (11)

W logu strace'a wygląda to tak:

24728 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x21} ---
24728 chdir(/etc/httpd)   = 0
24728 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER|SA_INTERRUPT, 
0x2fa67f08310}, {SIG_DFL, [], SA_RESTORER|SA_RESETHAND, 0x2fa67f08310}, 8) = 0
24728 kill(24728, SIGSEGV)  = 0
24728 rt_sigreturn()= 33
24728 --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=24728, si_uid=51} 
---

Na liście procesów czasami pojawiają się zombie (defuncty), czasami
umiera główny proces (chodzący z roota) i zostają tylko potomne.
Drugi reload powoduje ubicie wszystkich procesów.

Co ciekawe, po reloadzie jest problem z połączeniem się z apachem
tylko po SSLu. Normalny http dalej działa. W trakcie łączenia się SSLowo
sesja jest normalnie negocjowana tylko zaraz po tym połączenie jest
zrywane.

Pełny restart (service httpd restart) pomaga do następnego reloadu.

Ktoś może to potwierdzić/zaprzeczyć? Nie wiem czy to jest PLD-specific
ale wersja 2.4.9 była ok.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: apache-2.4.10-2.x86_64 sypie się przy reloadzie

2014-09-22 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Bez wyniku z gdb to zgaduj zgadula.

Sypie się na dwa różne sposoby (losowo):


Program received signal SIGSEGV, Segmentation fault.
0x03681c112a99 in OBJ_bsearch_ex_ () from /lib64/libcrypto.so.1.0.0
(gdb) bt
#0  0x03681c112a99 in OBJ_bsearch_ex_ () from /lib64/libcrypto.so.1.0.0
#1  0x03681c18a385 in ?? () from /lib64/libcrypto.so.1.0.0
#2  0x03681c4cb25a in ssl_cipher_get_evp () from /lib64/libssl.so.1.0.0
#3  0x03681c4b81f5 in tls1_setup_key_block () from /lib64/libssl.so.1.0.0
#4  0x03681c4ae9b8 in ssl3_do_change_cipher_spec () from 
/lib64/libssl.so.1.0.0
#5  0x03681c4af67a in ssl3_read_bytes () from /lib64/libssl.so.1.0.0
#6  0x03681c4b089b in ssl3_get_message () from /lib64/libssl.so.1.0.0
#7  0x03681c4a3238 in ssl3_get_cert_verify () from /lib64/libssl.so.1.0.0
#8  0x03681c4a4ebe in ssl3_accept () from /lib64/libssl.so.1.0.0
#9  0x03681c4b28f4 in ssl23_accept () from /lib64/libssl.so.1.0.0
#10 0x036818495ac8 in ssl_io_filter_handshake (filter_ctx=0x412a550) at 
/usr/src/debug/httpd-2.4.10/modules/ssl/ssl_engine_io.c:1173
#11 0x0368184967e4 in ssl_io_filter_input (f=0x4132d58, bb=0x4135030, 
mode=AP_MODE_GETLINE, block=optimized out, readbytes=0) at 
/usr/src/debug/httpd-2.4.10/modules/ssl/ssl_engine_io.c:1350
#12 0x00436304 in ap_rgetline_core (s=s@entry=0x4133e40, n=8192, 
read=read@entry=0x3f810b977b8, r=r@entry=0x4133e10, fold=fold@entry=0, 
bb=bb@entry=0x4135030) at /usr/src/debug/httpd-2.4.10/server/protocol.c:229
#13 0x004383f7 in read_request_line (bb=0x4135030, r=0x4133e10) at 
/usr/src/debug/httpd-2.4.10/server/protocol.c:590
#14 ap_read_request (conn=conn@entry=0x412a0b0) at 
/usr/src/debug/httpd-2.4.10/server/protocol.c:956
#15 0x0045d5de in ap_process_http_sync_connection (c=0x412a0b0) at 
/usr/src/debug/httpd-2.4.10/modules/http/http_core.c:181
#16 ap_process_http_connection (c=0x412a0b0) at 
/usr/src/debug/httpd-2.4.10/modules/http/http_core.c:231
#17 0x00455435 in ap_run_process_connection (c=0x412a0b0) at 
/usr/src/debug/httpd-2.4.10/server/connection.c:41
#18 0x00455818 in ap_process_connection (c=c@entry=0x412a0b0, 
csd=optimized out) at /usr/src/debug/httpd-2.4.10/server/connection.c:203
#19 0x036818ac27a7 in child_main (child_num_arg=child_num_arg@entry=0) at 
/usr/src/debug/httpd-2.4.10/server/mpm/prefork/prefork.c:704
#20 0x036818ac29e6 in make_child (s=0x3f60650, slot=slot@entry=0) at 
/usr/src/debug/httpd-2.4.10/server/mpm/prefork/prefork.c:800
#21 0x036818ac3139 in prefork_run (_pconf=optimized out, plog=optimized 
out, s=optimized out) at 
/usr/src/debug/httpd-2.4.10/server/mpm/prefork/prefork.c:1051
#22 0x004322d3 in ap_run_mpm (pconf=0x3f2f0f8, plog=0x3f5c318, 
s=0x3f60650) at /usr/src/debug/httpd-2.4.10/server/mpm_common.c:94
#23 0x0042b9a6 in main (argc=3, argv=0x3f810b97cb8) at 
/usr/src/debug/httpd-2.4.10/server/main.c:777


Program received signal SIGSEGV, Segmentation fault.
0x0021 in ?? ()
(gdb) bt
#0  0x0021 in ?? ()
#1  0x032377fab1c1 in ?? () from /lib64/libc.so.6
#2  0x032377faaf12 in ?? () from /lib64/libc.so.6
#3  0x032377faaf12 in ?? () from /lib64/libc.so.6
#4  0x032377faaf12 in ?? () from /lib64/libc.so.6
#5  0x032377faaf12 in ?? () from /lib64/libc.so.6
#6  0x032377faaf12 in ?? () from /lib64/libc.so.6
#7  0x032377faaf12 in ?? () from /lib64/libc.so.6
#8  0x032377faaf12 in ?? () from /lib64/libc.so.6
#9  0x032377faaf12 in ?? () from /lib64/libc.so.6
#10 0x032377faaf12 in ?? () from /lib64/libc.so.6
#11 0x032377faaf12 in ?? () from /lib64/libc.so.6
#12 0x032377faaf12 in ?? () from /lib64/libc.so.6
#13 0x032377faaf12 in ?? () from /lib64/libc.so.6
#14 0x032377faaf12 in ?? () from /lib64/libc.so.6
#15 0x032377faaf12 in ?? () from /lib64/libc.so.6
#16 0x032377faaf12 in ?? () from /lib64/libc.so.6
#17 0x032377faaf12 in ?? () from /lib64/libc.so.6
#18 0x032377faaf12 in ?? () from /lib64/libc.so.6
#19 0x032377faaf12 in ?? () from /lib64/libc.so.6
#20 0x032377faaf12 in ?? () from /lib64/libc.so.6
#21 0x032377faaf12 in ?? () from /lib64/libc.so.6
#22 0x032377faaf12 in ?? () from /lib64/libc.so.6
#23 0x032377faaf12 in ?? () from /lib64/libc.so.6
#24 0x032377faaf12 in ?? () from /lib64/libc.so.6
#25 0x032377faaf12 in ?? () from /lib64/libc.so.6
#26 0x032377faaf12 in ?? () from /lib64/libc.so.6
#27 0x032377fab47c in qsort_r () from /lib64/libc.so.6
#28 0x03237587c32d in sk_sort () from /lib64/libcrypto.so.1.0.0
#29 0x03237587c361 in ?? () from /lib64/libcrypto.so.1.0.0
#30 0x032375bbd25a in ssl_cipher_get_evp () from /lib64/libssl.so.1.0.0
#31 0x032375baa1f5 in tls1_setup_key_block () from /lib64/libssl.so.1.0.0
#32 0x032375ba09b8 in ssl3_do_change_cipher_spec () from 
/lib64/libssl.so.1.0.0
#33 0x032375ba167a in ssl3_read_bytes () from /lib64/libssl.so.1.0.0
#34 

Re: apache-2.4.10-2.x86_64 sypie się przy reloadzie

2014-09-22 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Niestety nie jest mi znany taki problem.
 
 https://bugzilla.redhat.com/show_bug.cgi?id=879798
 tu ktoś miał podobny i okazało się, że ram mu szwankuje.
 
 Masz możliwość dla pewności puścić memtesta?

Niestety, nie. Ale to chyba nie ma znaczenia ponieważ na innej maszynie
z tymi samymi pakietami uzyskuję podobne efekty. Zrobiłem mały research
i wyszło mi, że paradoksalnie problematyczny jest pakiet apr-util-ldap.
Gdy go nie ma wszystko działa w porządku. Żeby wystąpił problem musi być
również zainstalowany apache-mod_ldap ale to dlatego, że to on wciąga
bibliotekę zawartą w apr-util-ldap (sam w sobie nie jest problematyczny).
Widzę, że apr-util jest w repo w najnowszej wersji (1.5.3) więc ew. upgrade
odpada. Na razie go wywaliłem i da się żyć ale sprawa chyba jest
bardziej powszechna.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Nowy lepszy klient mysql

2014-02-08 Wątek Adam Osuchowski
Arkadiusz Miśkiewicz wrote:
 Było opisywane. mysql 5.5 używa libedit, a nie readline. Jak ktoś przygotuje 
 patcha przywracającego używanie readline to będzie super.

Zakomitowane. Nie wiem czy jest najbardziej elegancko jak się da ale nie
znam się aż tak na cmake'u. W każdym razie, u mnie się buduje i działa.
Puściłem na buildery ale kiedy przemielą to nie wiem.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: openldap i SSL

2013-04-05 Wątek Adam Osuchowski
Andrzej Zawadzki wrote:
 ldapsearch -H ldaps://localhost -x -D '' -b dc=people,dc=test,dc=pl -LLL
 \(uid=azawadzki\)
 
 zwraca:
 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
 
 Downgrade do 2.4.33-4 i wszystko działa.
 
 Jakieś pomysły?

Ustaw w /etc/openldap/ldap.conf:

TLS_CACERTDIR /etc/openssl/certs

albo zmienną środowiskową:

LDAPTLS_CACERTDIR=/etc/openssl/certs
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Parę pytań do znawców o branche i initial commity w gicie

2013-04-01 Wątek Adam Osuchowski
Nie do końca rozumiem się jeszcze z tym narzędziem więc mam parę pytań
z prośbą o wyjaśnienie. Zauważyłem w PLDowych repozytoriach, że
w poszczególnych modułach istnieje po kilka initial commitów (bez parenta).
Część z nich jest przypisana do branchy ale niektóre nie. Np. dla coreutils:

$ git rev-list --max-parents=0 --all
9cf1593a28075883f1880131ea15f9c6e046986b
5a006e8adf4446d30b3681b146cdb35f914ef29b
a30b82d494633d30a65fa15f06b33724068ba98e
$ git branch -a --contains 9cf1593a28075883f1880131ea15f9c6e046986b
* master
  remotes/origin/DEVEL
  remotes/origin/HEAD - origin/master
  remotes/origin/RA-branch
  remotes/origin/master
$ git branch -a --contains 5a006e8adf4446d30b3681b146cdb35f914ef29b
  remotes/origin/AC-branch
$ git branch -a --contains a30b82d494633d30a65fa15f06b33724068ba98e
$

Zastanawiałem się, jak stworzyć takiego commita bez parenta i bez brancha
i udało mi się to zrobić za pomocą git-commit-tree, rzeczywiście nie ma
parenta, jednakże nie jest on pokazywany przez git-rev-list, a git-fsck
znajduje go jako sierotę: 

$ git write-tree
d936ff7c9b575ca10f16a26b6ec7ec4087f1dd44
$ git commit-tree -m test d936ff7c9b575ca10f16a26b6ec7ec4087f1dd44
bb2ef6a355614ee670a230264711a2dc53676434
$ git log --format=raw bb2ef6a355614ee670a230264711a2dc53676434 | grep 
parent
$ git rev-list --all | grep bb2ef6a355614ee670a230264711a2dc53676434
$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1225/1225), done.
dangling commit bb2ef6a355614ee670a230264711a2dc53676434
$

Mam więc w związku z tym następujące pytania:

1. Czy legalne dla gita jest wiele initial commitów w obrębie jednego brancha?
2. Czy legalne dla gita jest istnienie commitów poza branchami?
3. Czy taka sytuacja, że jest wiele initial commitów i niektóre nie są
przypisane do żadnego z branchy, a wszystkie pokazywane są przez git-rev-list
jest skutkiem migracji z cvsa (cvs2git zainicjował w taki dziwny sposób
repo) czy można ją uzyskać również normalnie?
4. Dlaczego git-rev-list --all nie pokazuje ręcznie stworzonego commita bez
parenta i co zrobić, żeby pokazywał?
5. Czy da się wylistować faktycznie wszystkie commity w repozytorium?

Z góry dzięki za wyjaśnienie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Upgrade rc-scripts - poldek/rpm widzi więcej niż jest?

2012-12-04 Wątek Adam Osuchowski
Jacek Osiecki wrote:
 poldek:/all-avail ls -I rc-*
 rc-scripts-0.4.3.8-2.x86_64
 1 package
 poldek:/all-avail upgrade rc-scripts-0.4.5.4-2.x86_64
 error: rc-scripts: multiple instances installed, give up
^
 Nothing to do
 poldek:/all-avail

 Jakież to multiple instances, skoro jest tylko jedno rc-scripts?

Nie chodzi o to ile paczek rc-scripts jest w repozytorium, tylko ile
masz ich zainstalowanych w swoim systemie. Najwyraźniej masz ich
zainstalowanych więcej niż jedną.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Instalacja PLD Th w katalogu za pomocą rpm5

2012-11-22 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 Testowałem to na th+th-ready.
 Ostatnie zmiany w rpm to praktycznie tylko kolejność czytania plików z
 makrami i drobne poprawki w makrach, więc może to rzeczywiście coś poza
 samym rpm-em. Sprawdziłem jeszcze na maszynce z rpm rel 33 i też
 zadziałało.

Czyli widać, że problem jest chyba bardziej specyficzny dla konkretnej
instalacji. Ok, spróbuję gdzieś indziej to przetrenować i zobaczę czy
też są problemy. Dzięki za pomoc.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Instalacja PLD Th w katalogu za pomocą rpm5

2012-11-21 Wątek Adam Osuchowski
Próba instalacji Th w katalogu z wykorzystaniem rpm5:

# rpm -q rpm
rpm-5.4.10-33.x86_64
# rpm -q poldek
poldek-0.30-1.rc6.4.x86_64
# mkdir /tmp/pld
# rpm -qa -r /tmp/pld
# ls -la /tmp/pld
total 44
drwxr-xr-x  3 root root  4096 Nov 21 20:33 .
drwxrwxrwt 85 root root 36864 Nov 21 20:33 ..
drwxr-xr-x  3 root root  4096 Nov 21 20:33 var
# poldek -r /tmp/pld -i FHS-2.3-35.x86_64
Loading [pndir]th...
Loading [pndir]th...
19305 packages read
Processing dependencies...
There are 1 package to install:
I FHS-2.3-35.x86_64
Need to get 53.1KB of archives.
Executing rpm --install -vh --root /tmp/pld...
Preparing...### [100%]
error: open of 
/root/.poldek-cache/ftp_ftp.th.pld-linux.org.dists.th.PLD.x86.64.RPMS/FHS-2.3-35.x86_64.rpm
 failed: No such file or directory
rpm: ./rpmio_internal.h:190: fdGetOPath: Assertion `fd != ((void *)0)  
fd-magic == 0x04463138' failed.
error: /bin/rpm terminated by signal Aborted
# 

Kolejny bug czy jest teraz jakaś inna metoda instalacji systemu od zera?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: Instalacja PLD Th w katalogu za pomocą rpm5

2012-11-21 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 A co mówi 'ls 
 /root/.poldek-cache/ftp_ftp.th.pld-linux.org.dists.th.PLD.x86.64.RPMS/FHS-2.3-35.x86_64.rpm'?

Po zakończeniu plik jest ale w normalnym /root (niechrootowanym). W środku
nie ma nawet /root więc pliku tym bardziej. Natomiast strace pokazuje
coś takiego:

# grep -e FHS-2.3-35.x86_64.rpm -e chroot rpm.stracelog
[...]
7815  
open(/root/.poldek-cache/ftp_ftp.th.pld-linux.org.dists.th.PLD.x86.64.RPMS/FHS-2.3-35.x86_64.rpm,
 O_RDONLY) = 13
7815  chroot(/tmp/pld/)   = 0
7815  chroot(.)   = 0
7815  
open(/root/.poldek-cache/ftp_ftp.th.pld-linux.org.dists.th.PLD.x86.64.RPMS/FHS-2.3-35.x86_64.rpm,
 O_RDONLY) = -1 ENOENT (No such file or directory)
7815  write(2, open of 
/root/.poldek-cache/ftp_ftp.th.pld-linux.org.dists.th.PLD.x86.64.RPMS/FHS-2.3-35.x86_64.rpm
 failed: No such file or directory\n, 134 unfinished ...
[...]

Czyli raz go otwiera dobrze, potem się chrootuje i wtedy już, co logiczne,
nie może otworzyć.

 Bo u mnie działa.

Masz release rpma wyższy o 2. Były tam jakieś istotne poprawki?
Poza tym, mój system jest w całości z th stable, a u Ciebie conajmniej rpm
jest z testa; może tu jest różnica.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [RFD] wersja rpm

2012-10-25 Wątek Adam Osuchowski
Jacek Konieczny wrote:
   [X] wszystko jedno, byle działał i nie blokował rozwoju reszty systemu

,,Takie rzeczy to tylko w Erze''.

 (np. zależnością od antycznego Berkeley-DB)

Antyczny nie znaczy zły. Poza tym, zawsze można zlinkować rpma statycznie
z db4.7 na jego własny wyłączny użytek, a w systemie mieć 5.x.

 Najchętniej wziął bym takiego, do którego nie trzeba by ładować więcej
 niż kilka łat na nasze potrzeby.

Nie ma takiego. Każdy wymaga sporych zmian.

 Rozumiem, że z rpm5 jest teraz kilka problemów, ale skoro już go mamy,
 to chyba najprościej będzie po prostu rozwiązać te problemy i już.
 Pewnie będzie to prostsze niż portowanie 4.5 do aktualnego bdb albo
 dodawanie repackage (ja osobiście mogę bez tego żyć) do RedHatowego rpm4.

No to skoro to takie proste to weź i to zrób. Jak dało się zauważyć, to
nawet nie jest tak wielki problem techniczny tylko personalny. A jak
się okaże, że którejś z łatek nie da się przepchnąć u developera to
trzeba ją będzie zrobić jako PLD-specific i lista lokalnych łat dalej
rośnie.

 baggins zrobił niezłą robotę doprowadzając zestaw
 rpm5+poldek+aktualne_db do jako-takiego działania. Jak ktoś zrobi to
 samo dla starego rpm4.5 lub nowszego rpm4, to można myśleć o przesiadce,

Dla rpm4.5 było to już zrobione. Działało i to porządnie.

 ale 'weźcie i zróbcie', albo 'PLD nie potrzebuje żadnych zmian' mówię
 nie.

Sam kawałek wyżej napisałeś to samo, więc bądź spójny w opiniach.

 Co do moich doświadczeń z rpm5, to mnie się nic nie posypało, ale
 zauważyłem że istotnie bywa wooolny w porównaniu ze starym.

Rozumiem, że u Ciebie działa weryfikacja pakietów i rpm się nie zapętla?
Ciekawe. Może w takim razie zdradzisz, jak to zrobiłeś?

Ja, mimo, że nie mam tu nic do gadania, jestem za daniem drugiej szansy
rpmowi 5, ale trzeba mu dokładnie ,,patrzeć na ręce'' i nie przeć tak ostro
do przodu z wersjami. A decyzję (jakąkolwiek) trzeba podjąć jak najszybciej
bo to nie jest jakiś popierdółkowaty niszowy pakiecik tylko kluczowe
oprogramowanie.

BTW, może mi ktoś odpowiedzieć na pytanie, dlaczego został wybrany rpm
5.4, który jest wersja rozwojową, zamiast produkcyjnej 5.3.6?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [RFD] wersja rpm

2012-10-23 Wątek Adam Osuchowski
Tomasz Pala wrote:
  Należy też wziąć pod uwagę inną, ale bardzo
  ważną, kwestię: czy da się wrócić w miarę łatwy sposób z rpm5 do rpm4?
  Da się przekonwertować bazę rpma w dół bez reinstalacji wszystkiego od
  zera?
 
 To może być istotny problem dla tych, którzy już zrobili, jednak jeśli
 nie teraz - to nigdy. Zanim jednak zejdziemy na praktyczne zagadnienia,
 dobrze wiedzieć, czy w ogóle chcemy iść tą drogą, czy rpm5 to must-have
 i jak komuś nie pasuje, to niech szuka innej piaskownicy.

Jak nie będzie do tego jakiegoś magicznego narzędzia to mogę to zrobić
odtwarzając starą bazę z backupu i kombinująć z upgradami tych pakietów,
które się w międzyczasie zmieniły (co też zajmie trochę czasu). Jednak,
jak mamy się cofnąć to jak najszybciej, bo im dłużej rpm5 jest
produkcyjnie w stabilnej wersji dystrybucji, tym trudniej będzie z niego
zejść.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [RFD] wersja rpm

2012-10-23 Wątek Adam Osuchowski
Jakub Bogusz wrote:
 rpm4 jest określeniem mocno rozmytym.
 To głos za powrotem do rpm 4.5 by PLD czy aktualną linią rpm.org?

Jeżeli już to powrót do tego co było czyli 4.5. Owszem, w kolejnym kroku
można przemyśleć pójście dalej z obrębie 4.x, ale przejście od razu do
najnowszego 4.x to trochę za dużo rewolucji na raz..
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [RFD] wersja rpm

2012-10-23 Wątek Adam Osuchowski
Jan Rękorajski wrote:
 - do rpm 4.5 nie wrócę w Th, bo ten rpm to nie utrzymywany przez nikogo 
 zabytek

A masz jakieś konkretne zarzuty co do niego? Bo to, że nikt z nim nic
nie robi jeszcze go nie dyskwalifikuje. Jeżeli spełnia swoją rolę,
a spełnia i działa stabilnie to IMHO może po prostu nie ma potrzeby
grzebania w nim, zwłaszcza jeżeli nie ma jakichś poważnych security
bugów. Chyba lepsza taka wersja niż, było nie było, wersja developerska
(wg rpm5.org ostatnia produkcyjna wersja to 5.3.6).

 - nie upieram się przy rpm5

Będąc z drugiej strony adwokatem diabła, może by jednak zostać przy rpm5
ale nie takiego bleeding edge tylko jakiejś wersji dokładniej
przetestowanej z poprawionymi rażącymi błędami (albo przez autora albo
w PLD)? Jakie są inne zarzuty oprócz tych dwóch błędów (hmac i zapętlenie
przy sprawdzaniu zależności)? Niech ci, którzy zainstalowali rpm5,
pomęczą go trochę w typowych zastosowaniach, może coś jeszcze wyjdzie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Re: [RFD] wersja rpm

2012-10-23 Wątek Adam Osuchowski
Paweł Sikora wrote:
 przy okazji watku pojawil sie problem przebudowania sporej liczby pakietow.
 otoz juz dawno powinnismy robic automatem rebuild calego zestawu przy kazdej
 zmianie gcc tak jak robi to fedora, bo to co teraz mamy na ftp, to jest 
 watpliwej
 jakosci hybryda binarek generowanych roznymi wersjami kompilatora.

Obawiam się, że to jest rozwiązanie dla dystrybucji ściśle wersjonowanej.
Dla modelu dystrybucji ciągłej jak w th, co nowy gcc do reinstalacji
byłyby wszystkie pakiety w systemie, a to już w zasadzie podpada pod
wymianę całego distro.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


Zwis rpma na weryfikacji pakietu ntpd

2012-10-16 Wątek Adam Osuchowski
Trochę dziwna sprawa, ale po rpmie 5 już wszystkiego się mogę spodziewać.

rpm zwisa na weryfikacji pakietu ntpd-4.2.6p5-5. Po wydaniu komendy
`rpm -V ntpd' w środku operacji, po wypisaniu niezgodności md5ek kilku
plików (niezależny problem, patrz inny wątek) proces zawisa i zeżera
całego procka. Strace pokazuje, że kręci się w kółko w syscallach
około-mmapowych:

1587  mremap(0x2d382925000, 135168, 4096, MREMAP_MAYMOVE) = 0x2d382925000
1587  munmap(0x2d382925000, 4096)   = 0
1587  mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2d382925000
1587  mremap(0x2d382925000, 135168, 4096, MREMAP_MAYMOVE) = 0x2d382925000
1587  munmap(0x2d382925000, 4096)   = 0
1587  mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2d382925000
1587  mremap(0x2d382925000, 135168, 4096, MREMAP_MAYMOVE) = 0x2d382925000
1587  munmap(0x2d382925000, 4096)   = 0
1587  mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2d382925000
1587  mremap(0x2d382925000, 135168, 4096, MREMAP_MAYMOVE) = 0x2d382925000
1587  munmap(0x2d382925000, 4096)   = 0
1587  mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x2d382925000

Problem zaobserowałem wyłącznie na pakiecie ntpd i jak na razie na żadnym
innym (co nie znaczy, że nie występuje na innych). Nawet na innych pakietach
budowanych z tego samego speca (np. ntpdate) jest wszystko ok. Lokalne
przebudowanie pakietu też nie pomaga. Problem występuje nawet przy
weryfikacji paczki z pliku (rpm -Vp ~/rpm/RPMS/ntpd-4.2.6p5-5.x86_64.rpm).

Inne operacje jak np. listowanie zawartości pakietu ntpd przechodzą bez
problemów. Działa nawet jego odinstalowanie, ale ponowna próba instalacji
też powoduje podobny zwis (proponuję nie odinstalowywać na produkcyjnych
systemach bo się nie da ponownie zainstalować).

`/usr/lib/rpm/bin/dbconvert --rebuilddb' i `db5.3_recover -ev' nic nie
zmieniają, jakby się kto pytał.

Jest to powtarzalne na kilku moich niezależnych instalacjach, bez różnicy
czy odpalane z roota czy ze zwykłego usera i występuje zarówno na x86 jak
i x86-64. Czy ktoś może to potwierdzić (kolejny bug w rpmie?) i ew.
spróbować coś więcej zdiagnozować?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl


  1   2   >