Re: procps-4.0.4-2 ( w = Naruszenie ochrony pamięci )
Krzysztof Mrozowicz wrote: > Hej, jak zerkniesz na ten wątek to zobaczysz, że ta łata pomogła > -https://lists.pld-linux.org/mailman/pipermail/pld-users-pl/2024-June/079859.html > Jesteś pewien, że jesteś na wersji 4.0.4-2? Być może pomogła, ale jeśli nawet, to tylko dla systemów z systemd. Większość ludzi nie wyobraża sobie sytuacji że nie ma systemd, przez co nie sprawdzają innych przypadków, a podatność nadal istniała pomimo łaty. Maciej Kędzierski wrote: > Tak, to ta wersja4.0.4-2, dziś upgradowałem na 2 serwerach i na obu "w" nie > działa. > Tam gdzie mam nadal 4.0.4-1, "w" działa normalnie. > > PS. Nie używam systemd w PLD. Nadal SysV. Może to ma jakieś znaczenie? Tak, ma. Sprawdź 4.0.4-3. Przed chwilą zakomitowałem z drobną poprawką. Testowane na systemie z SysV i wydaje się działać. Musisz chyba zbudować samodzielnie bo stbr nie wysyła z automatu paczki do repozytorium th-test (kiedyś chyba to tak działało, albo coś mi się już pomieszało). ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
git clone po https
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
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
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
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/
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
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
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
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
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
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
Ł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
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
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
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?
Ł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?
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?
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?
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?
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?
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?
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?
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/
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
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
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
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
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
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
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
$ 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)
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
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
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
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
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
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
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/
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
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
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/
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
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
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
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.*
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?)
Ł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
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
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
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.
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ć?
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ć?
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ć?
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?
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?
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?
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?
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
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
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
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
# 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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
