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
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
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ć
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ć
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
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 je
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 p
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
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.
>
>
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
Ł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
>
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
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
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
Ł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
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
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
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
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
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
>
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
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
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
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
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ę
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
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
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
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ę
$ 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
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
>
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
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.
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ść
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)
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...
___
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
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
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
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
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).
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 /
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
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
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
Łukasz Maśko wrote:
> Z jakiegoś powodu jest tak:
> poldek:/all-avail> desc libgcrypt-1.6.4-1.x86_64
>
>
>
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
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]
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
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
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
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
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
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
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
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.
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
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)
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
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
# service php56-fpm start
Starting PHP FastCGI Process Manager (php56-fpm)
service[
BUSY ]*** Error in `/usr/sbin/php56-fpm': free(): invalid pointer:
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
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
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
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ż
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
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:
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.
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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ę
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
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
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ż
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
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 ..
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:
#
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
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
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ę
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
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
Trochę dziwna sprawa, ale po rpmie 5 już wszystkiego się mogę spodziewać.
rpm zwisa na weryfikacji pakietu ntpd-4.2.6p5-5. Po wydaniu komendy
`rpm -V ntpd' w środku operacji, po wypisaniu niezgodności md5ek kilku
plików (niezależny problem, patrz inny wątek) proces zawisa i zeżera
całego procka.
1 - 100 z 170 matches
Mail list logo
