Re: Popsuty upower 0.9.23-1?
On Tuesday 22 of October 2013 15:02:38 Łukasz Maśko wrote: Po aktualizacji upower do powyższej wersji monitor baterii KDE przestaje odczytywać stan baterii. Wszystko jest OK na 0.9.21-2. Tylko u mnie czy u kogoś jeszcze też? glib2 masz nowe? ___ 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 glib2-2.38.0.
On Friday 11 of October 2013 08:53:04 Łukasz Maśko wrote: Dnia czwartek, 10 października 2013 19:44:13 Paweł Sikora pisze: [...] wiec cos przestalo reagowac na te sygnaly. ktos ma pomysl co jeszcze moge sprawdzic? (lid.sh.post z google nie dziala). A ja się tak przewrotnie zapytam - a co działało? dzialalo to co bylo zainstalowane w systemie bez tworzenia zadnych skryptow. logowalem sie do kde, close-lid i spi. open-lid i kde wracalo. zrobilem hurtowa aktualizacje th i ten flow przestal dzialac. jak pokazuja testy kernel/acpi/upower poprawnie zglaszaja open/close-lid, suspend wywolany recznie z pm-utils lub z menu kde tez usypia system, wiec chyba przestalo dzialac cos co przenosilo informacje do kde. dbus? Arek M. twierdzi, ze u niego dziala, ale on uzywa systemd, a ja wciaz jade na klasycznym rc-scripts+udev. na google wyczytalem tez ze w innych dystrybucjach usunieto z gnome-settings-daemon jakas funkcjonalnosc w tej okolicy i trzeba sobie w /etc/acpi/local stworzyc skrypt lid.sh.post, ktory sprawdzi jakis tam plik w /proc/acpi i zawola w razie potrzeby pm-suspend. aczkolwiek nie wiem, czy gnome-settings-daemon ma znaczenie jesli uzywam kde? w kazdym razie ten trick z lid.sh.post tez u mnie nie zadzialal. Bo ja mam np. własne skrypty podpięte pod acpid (w /etc/acpid). mozesz je przedstawic swiatu? ___ 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 glib2-2.38.0.
On Tuesday 08 of October 2013 09:29:50 Paweł Sikora wrote: witam, wczoraj po czesciowym upgrejdzie th na domowym laptopie, plasmoid kde stwierdzil, ze systemi nie posiada baterii oraz przestalo dzialac usypianie laptopa poprzez zamykanie dekielka. szukanie w logach po omacku doprowadzilo mnie do .xsession-errors, w ktorym wydlubalem informacje (warningi) wskazujace na wewnetrzne problemy upower i faktycznie 'upower -e' wypluwalo tylko na konsole jakies warningi z glib2. wyglada na to, ze binarki upower zbudowane w otoczeniu glib2-devel-2.38.0 nie dzialaja poprawnie z glib2-2.36.4. dopiero aktualizacja glib2 przywrocila upower do zycia. wyglada tez, ze cos innego przestalo przy tej okazji dzialac - usypianie poprzez zamykanie dekielka. sprawdzilem, reczne wywolanie suspend z menu kde usypia system, a dekielek nie. sprawdzilem jeszcze czy kernel widzi dekielek i wyglada ze tak: $ while [ true ]; do cat /proc/acpi/button/lid/LID/state; sleep 1; done state: open state: open state: open state: open state: open state: open state: closed state: closed state: closed state: open state: open state: open 'upower -d' takze widzie zamkniecie dekielka: Daemon: daemon-version: 0.9.21 can-suspend: yes can-hibernate: yes on-battery: no on-low-battery: no lid-is-closed: yes lid-is-present: yes is-docked: yes wiec cos przestalo reagowac na te sygnaly. ktos ma pomysl co jeszcze moge sprawdzic? (lid.sh.post z google nie dziala). -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
problemy z glib2-2.38.0.
witam, wczoraj po czesciowym upgrejdzie th na domowym laptopie, plasmoid kde stwierdzil, ze systemi nie posiada baterii oraz przestalo dzialac usypianie laptopa poprzez zamykanie dekielka. szukanie w logach po omacku doprowadzilo mnie do .xsession-errors, w ktorym wydlubalem informacje (warningi) wskazujace na wewnetrzne problemy upower i faktycznie 'upower -e' wypluwalo tylko na konsole jakies warningi z glib2. wyglada na to, ze binarki upower zbudowane w otoczeniu glib2-devel-2.38.0 nie dzialaja poprawnie z glib2-2.36.4. dopiero aktualizacja glib2 przywrocila upower do zycia. wyglada tez, ze cos innego przestalo przy tej okazji dzialac - usypianie poprzez zamykanie dekielka. sprawdzilem, reczne wywolanie suspend z menu kde usypia system, a dekielek nie. ile jeszcze innych rzeczy po cichu przestalo dzialac, to nie wiem, ale zachowanie glib2 jest skandaliczne... ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: grub-install z grub2-2.00-2.i686 wywala sie z double free or corruption (fasttop), da się wydobyć miejsce w kodzie na rzecz bugreportu?
On Friday 13 of September 2013 12:37:02 Mateusz Korniak wrote: Błąd objawia się po wykonaniu: bash -x grub-install /dev/sda Da się wydobyć więcej pełniejszy backtrace niż [1]? skompiluj z opcja -fsanitize=address i pod gdb sie zaczep breakpointem na __asan_report_error. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Xvfb - wywraca się przy próbie odpalenie ffoxa
On Monday 05 of August 2013 12:33:19 Jacek Osiecki wrote: Xvfb: symbol lookup error: Xvfb: undefined symbol: pixman_glyph_cache_create Jakiś pomysł z czego to może wynikać? Może da się w jakiś sposób to ominąć? masz aktualne wersje pakietow? u mnie ten symbol jest eksportowany przez pixmana. $ readelf -sW /usr/bin/Xvfb|grep pixman_glyph_cache_create 279: 0 FUNCGLOBAL DEFAULT UND pixman_glyph_cache_create $ readelf -sW /usr/lib64/libpixman-1.so.0.30.0|grep pixman_glyph_cache_create 173: 000573e072 FUNCGLOBAL DEFAULT 12 pixman_glyph_cache_create -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: th apache 2.4 i perl 5.18.0
On Wednesday 31 of July 2013 15:48:18 gal01 wrote: W dniu 2013-07-31 14:52:08 użytkownik Jan Rękorajski bagg...@pld-linux.org napisał: W logach też nic nie ma? Spróbuj go puścić z debugiem (-e level -X) może coś powie. Wylatuje komunikat: memory fault mozesz zmodyfikowc skrypt odpalajacy apacha i puscic go przez gdb (przyklad nizej) i przeslac nam gdb.log? gdb -ex='set logging overwrite on' -ex='set logging on' -ex=r -ex=bt -ex='set confirm no' -ex=q --args tu binaraka apacza z argumentami oczywiscie, zeby backtrace byl czytelny musisz doinstralowac pakiety debuginfo dla apacza i innych, ktorych uzywasz w konfiguracji. -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
iceweasel-22.x vs. pgnig.
witam, najnowszy iceweasel sprawia, ze e-bok pgnige (https://ebok.koog.pgnig.pl/) wyswietla mi blad pt. pana przegladarka jest za stara. rollback do wersji 20.x i znow wszystko dziala. ktos zna tego powody? wadliwe skrypty pgnige, czy jakas zmiana sygnatury w zimnej lasiczce? -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: OT: jak namierzyć przyczynę wysokiego load?
On Wednesday 13 of March 2013 16:56:32 Tomasz Pala wrote: On Wed, Mar 13, 2013 at 16:02:27 +0100, Jacek Konieczny wrote: Wysokie wskazania load average to może być, po prostu, taki urok Twojej konfiguracji. Zapisy do DRBD są serializowane, procesy więc ustawiają się w kolejce do zapisu i nawet jak kolejka idzie tak szybko, że nie jest problemem, to ty ją ???widzisz??? właśnie w tych wskazaniach load-average. Monitorowanie loadu wg mnie jest w ogóle bezużyteczne - nie spotkałem jeszcze ani jednego przypadku, gdyby wartość LA miała jakiekolwiek znacznenie inne niż 'o w mordę, ale przytkało' - monitorować należy bezpośrednio I/O, bezpośrednio RAM/swap i bezpośrednio CPU, a nie jakąś tam wypadkową. ja mam taki przypadek, gdzie avgload wystarcza i jest rozwiazniem wystarczajacym. mam farme obliczeniowa na serwerach 2x opteron (8 rdzeni kazdy), ktora zjada glownie procesor, sporo ramu (tu akurat h/w ma zapas, brak swapa) i znikome ilosci i/o (odpalenie binarek z nfs-a raz na kilkadziesiat minut + zapis wynikow po kilku godzinach obliczen). w moim przypadku, przy optymalnie obciazonej maszynie avgload z ostatnich 5/15 minut skaluje sie ladnie w.g. manuala do ~ilosci rdzeni. i wlasnie odpowiedni avgload wstrzymuje wpuszczanie kolejnych zadan obliczeniowych na wezel farmy. jest to rozwiazane tak prosto jak sie da, ale nie prosciej. do tego jeszcze numactl (zeby zadania nie skakaly miedzy procesorami i nie migrowaly stron pamieci) i wszystko bangla jak talalala. -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
kde - gpfy... (cale stada).
dzisiaj po upgrejdzie do najnowszego th (main+ready+test) kde wylatuje w roznych miejscach. najlatwiej to powtorzyc na kmail probojac dodac zalacznik do nowego maila. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f344700 (LWP 29306)] 0x7f34bea7b9db in QUrl::QUrl(QUrl const) () from /usr/lib64/libQtCore.so.4 (gdb) bt #0 0x7f34bea7b9db in QUrl::QUrl(QUrl const) () from /usr/lib64/libQtCore.so.4 #1 0x7f34bd46b31d in QListQUrl::append(QUrl const) () from /usr/lib64/libattica.so.0.4 #2 0x7f34c0e6f27d in Herqq::Upnp::HControlPointPrivate::buildDevice(QUrl const, int, QString*) () from /usr/lib64/libHUpnp.so.1 #3 0x7f34c0e7aa02 in Herqq::Upnp::DeviceBuildTask::run() () from /usr/lib64/libHUpnp.so.1 #4 0x7f34be9c03ad in ?? () from /usr/lib64/libQtCore.so.4 #5 0x7f34be9cca0c in ?? () from /usr/lib64/libQtCore.so.4 #6 0x7f34bbfa1fe4 in start_thread (arg=0x7f344700) at pthread_create.c:308 #7 0x7f34be17397d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:110 #8 0x in ?? () ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kde - gpfy... (cale stada).
On Friday 01 of March 2013 12:12:51 Andrzej Zawadzki wrote: On 01.03.2013 11:31, Łukasz Maśko wrote: Dnia piątek, 1 marca 2013 10:56:28 Mateusz Korniak pisze: On Friday 01 March 2013 10:22:05 Paweł Sikora wrote: dzisiaj po upgrejdzie do najnowszego th (main+ready+test) kde wylatuje w roznych miejscach. najlatwiej to powtorzyc na kmail probojac dodac zalacznik do nowego maila. Na i686 w.w. KDE działa mi bez GPFów od nastu dni, ale nie mam upgrejdniętego całego systemu do(main+ready+test, tylko KDE. Mi na i686 też chodzi w miarę poprawnie. Jak już zacznie. Mam problem z plasmą przy starcie, zwykle muszę startować KDE 2-3 razy bo przy pierwszym np. nie pokazuje ikon na pulpicie (zabijam wtedy przez Alt+Ctr+BckSp) albo całkiem się wywala. Ze 2 razy zaobserwowałem też wywrotkę kded podczas pracy, ale to mogło być na skutek jakiegoś upgrade'u. Problemy z kmailem (czasami nie może się dogadać z Akonadi i trzeba go zrestartować) zrzucam na ciągle niedorobiony program. W tej chwili wydaje się działać stabilnie. Aha, mam system w pełni aktualny (pakiety z Th+test+ready). i686 wszystko z test. Nie używam Kmaila i Akonadi. W sumie to ostatnio działa zadziwiająco stabilnie. ;-) ok, podejzewam pewna specyficzna sytacje. w momencie gdy obserwowalem te wyloty na QUrl, to mialem laptopa w pracy podlacznego do kabla @ eth0 oraz niezalogowanym wifi @ wlan0. gdy wrocilem do domu i mam tylko aktywny wlan0 (kabel eth0 odpiety) wszystko dziala bez wylotow. bede badal sprawe w tym kierunku... -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: git status/push w packages
On Friday 01 of March 2013 17:37:37 Tomasz Pala wrote:
Mam 3 pytania:
1. czy mogę jakoś z poziomu ~/rpm/packages sprawdzić, w których pakietach mam
coś do wypchnięcia (bez łażenia ręcznego ani skryptowego)?
generalnie z poziomu repozytorium (w naszym przypadku pakietu)
mozna to sprawdzic dosc prosto:
git remote show origin
* remote origin
(...)
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (fast-forwardable)
jesli masz lokalne commity,
to bedzie tu cos roznego od '(up tu
date)'
byc moze da sie to jakos ladniej rozwiazac, ale nigdy nie mialem takiej
potrzeby.
1a. jak zobaczyć treść (komentarz+zmiany) commitów, które wyjdą jak zrobię
push?
konsolowo, np: git log -p origin/master..master, ewentualnie przez klikanie w
'gitk'
--
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kde - gpfy... (cale stada).
On Friday 01 of March 2013 18:04:59 Tomasz Pala wrote: On Fri, Mar 01, 2013 at 17:57:16 +0100, Paweł Sikora wrote: ok, podejzewam pewna specyficzna sytacje. w momencie gdy obserwowalem te wyloty na QUrl, to mialem laptopa w pracy podlacznego do kabla @ eth0 oraz niezalogowanym wifi @ wlan0. gdy wrocilem do domu i mam tylko aktywny wlan0 (kabel eth0 odpiety) wszystko dziala bez wylotow. bede badal sprawe w tym kierunku... A strony świata, czy ekran był zwrócony na północ? ekran ma generalnie zawsze w pionie :-) P, ale jak czytam, jak to się sypie, to NMSP;) jak znam rozna tworczosc gosci od wszelakich gui i ich optymistyczne zalozenia, to smiem twierdzic, ze np. taki wicd przestawiajacy trasy rutingu miedzy interfejsami, moze wyslac w kosmos algorytmy kde. -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Jak prawidłowo wymusić aby dany pakiet wymagał danej linii kde ?
On Wednesday 27 of February 2013 17:45:23 Mariusz Mazur wrote: On Fri of February 22 2013, Mateusz Korniak wrote: Jak prawidłowo wymusić aby dany pakiet wymagał danej linii kde ? Np chcemy KDE 4.10.x: R: kde4-kdelibs = 4.10 R: kde4-kdelibs 4.11 A jesteś pewien, że wymaga konkretnie danej linii? Ja np. używam nadal dwuletniego kmaila z kde 4.4, a mam kde 4.9, biblioteki kde raczej są kompatybilne w górę. i na jakiej podstawie tak sadzisz? przeciez tam nie ma ani wersjonowania symboli, ani zadnej polityki co do kompatybilnosci abi (no chyba, ze gdzies to jest opisane malym druczkiem na tym fajnym wiki). jak dotad, to widzialem na wlasne oczy rozne wyloty kde-decoration, kwin, plasma i kilku innych elementow na zestawie pakietow z wymieszanych wersji. -- A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [OT] Podpowiedzcie proszę, gdzie należy wysyłać takie zgłoszenia błędów
On Tuesday 12 of February 2013 08:39:01 Łukasz Maśko wrote: Dnia środa, 30 stycznia 2013 12:21:05 Arkadiusz Miśkiewicz pisze: On Wednesday 30 of January 2013, Tomasz Pala wrote: 2. aby choć odrobinę zmniejszyć pewność olania, musisz sam namierzyć psujący commit - git bisect, To ważne :-) 3. zamiast się frustrować, trzymasz swoje łaty na kernela u siebie (ja utrzymywałem przez długi czas do VGA, digital beep na laptopie, ciągle mam jakiegoś quirka do ACPI, MTD oraz VLAN stripping). Osobiście wolę jednak pchać do upstreamu - potem spokój, a nie ciągłe dbanie o łatki (chyba, że to takie 1 linijkowe). 4. jedyna pewna droga, aby się przebić, to zostać klientem jakiegoś dużego gracza i zgłosić problem komercyjną drogą. Ciekaw jestem jak to działa jak masz np. serwery bez certyfikatu dużego gracza, o desktopach, laptopach nie wspominając - nie odpiszą, sorry, unsupported? Udało się wyizolować problem, dzięki jednemu z hakerów kernela mam patch, dzieki któ©emu wraca stara funkcjonalność (czyli kilka niegroźnych komunikatów w logach, ale czytnik działa). duzy to patch? jesli on naprawia regresje w kontekscie takim, ze sprzet znow dziala, to ja bym to probowal popchnac do stable zeby najblizszy 3.7.y/3.8.y bylyb lepsze niz wydanie x.y.0. I teraz pytanie. Czy wprowadzić to do naszego kernela jako łatkę, czy też pomęczyć się samemu, bo odpowiednie kody mają być włączone już (!) do jądra 3.9? 3.9 to jeszcze kawalek czasu... ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: screen - problem z ponownym podpieciem.
On Tuesday 22 of January 2013 14:43:14 Paweł Sikora wrote:
witam,
ostatnio cos nie dziala mi 'screen -Urd'.
po normalnym odpieciu:
(...)
[detached from 17935.pts-29.hal]
ponownie przypiecie sie sypie:
$ screen -Urd
There is a screen on:
17935.pts-29.hal(Dead ???)
Remove dead screens with 'screen -wipe'.
There is no screen to be detached.
$ ps aux|grep -i screen
pawels3010 0.0 0.0 123652 936 pts/29 S+ 14:25 0:00 grep -i
screen
pawels 17935 0.0 0.0 144476 4148 ?Ss 12:54 0:00 SCREEN -U
$ rpm -q screen
screen-4.1.0-3.x86_64
$ ls -l ~/.screen
total 0
prw--- 1 pawels users 0 Jan 22 14:24 17935.pts-29.hal
przebudowalem z debugiem i oto log:
*
opendebug: done.
-- screen debug started screen (4.01.00devel (GNU516d8fe) 2-May-06)
POSIX
TERMIO
NAMEDPIPE
Window size changing enabled
SETREUID
USEBCOPY
UTMPOK
LOADAV
NETHACK
TERMINFO
SHADOWPW
NAME_MAX = 255
secopen(/dev/pts/5, 0x802, )
attach_tty is /dev/pts/5, attach_fd is -1
SockPath: /ahome/pawels/.screen SockMatch: NULL
screen -r: - is there anybody out there?
Attach: how=2, tty=/dev/pts/5
- ..
- 20816.pts-5.hal
stat /ahome/pawels/.screen/20816.pts-5.hal
uid = 1074, gid = 500
euid = 1074, egid = 500
S_ISFIFO?
st.st_uid = 1074, real_uid = 1074
has mode 0600
store it.
secopen(/ahome/pawels/.screen/20816.pts-5.hal, 0x801, )
MakeClientSocket() open /ahome/pawels/.screen/20816.pts-5.hal failed (6)
MakeClientSocket failed, unreachable? 0 0
- .
Msg('There is a screen on:') (0);
Msg('Remove dead screens with 'screen -wipe'.') (0);
Panic('There is no screen to be detached.'); display=0 displays=0
eexit
*
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
screen - problem z ponownym podpieciem.
witam, ostatnio cos nie dziala mi 'screen -Urd'. po normalnym odpieciu: (...) [detached from 17935.pts-29.hal] ponownie przypiecie sie sypie: $ screen -Urd There is a screen on: 17935.pts-29.hal(Dead ???) Remove dead screens with 'screen -wipe'. There is no screen to be detached. $ ps aux|grep -i screen pawels3010 0.0 0.0 123652 936 pts/29 S+ 14:25 0:00 grep -i screen pawels 17935 0.0 0.0 144476 4148 ?Ss 12:54 0:00 SCREEN -U $ rpm -q screen screen-4.1.0-3.x86_64 $ ls -l ~/.screen total 0 prw--- 1 pawels users 0 Jan 22 14:24 17935.pts-29.hal ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: screen - problem z ponownym podpieciem.
On Tuesday 22 of January 2013 14:43:14 Paweł Sikora wrote:
witam,
ostatnio cos nie dziala mi 'screen -Urd'.
po normalnym odpieciu:
(...)
[detached from 17935.pts-29.hal]
ponownie przypiecie sie sypie:
$ screen -Urd
There is a screen on:
17935.pts-29.hal(Dead ???)
Remove dead screens with 'screen -wipe'.
There is no screen to be detached.
$ ps aux|grep -i screen
pawels3010 0.0 0.0 123652 936 pts/29 S+ 14:25 0:00 grep -i
screen
pawels 17935 0.0 0.0 144476 4148 ?Ss 12:54 0:00 SCREEN -U
$ rpm -q screen
screen-4.1.0-3.x86_64
$ ls -l ~/.screen
total 0
prw--- 1 pawels users 0 Jan 22 14:24 17935.pts-29.hal
z ciekawostek dodam, ze w logu strace jest taki flood:
(...)
getrlimit(RLIMIT_NOFILE, {rlim_cur=64*1024, rlim_max=64*1024}) = 0
close(65535)= -1 EBADF (Bad file descriptor)
close(65534)= -1 EBADF (Bad file descriptor)
close(65533)= -1 EBADF (Bad file descriptor)
close(65532)= -1 EBADF (Bad file descriptor)
(...)
close(6)= -1 EBADF (Bad file descriptor)
close(5)= -1 EBADF (Bad file descriptor)
close(4)= -1 EBADF (Bad file descriptor)
close(3)= -1 EBADF (Bad file descriptor)
a potem juz sam zglaszany blad:
(...)
openat(AT_FDCWD, /ahome/pawels/.screen,
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, /* 3 entries */, 32768) = 88
stat(/ahome/pawels/.screen/17935.pts-29.hal, {st_mode=S_IFIFO|0600,
st_size=0, ...}) = 0
geteuid() = 1074
getegid() = 500
open(/ahome/pawels/.screen/17935.pts-29.hal, O_WRONLY|O_NONBLOCK) = -1 ENXIO
(No such device or address)
geteuid() = 1074
getegid() = 500
geteuid() = 1074
getegid() = 500
getdents(3, /* 0 entries */, 32768) = 0
close(3)= 0
fstat(1, {st_mode=S_IFREG|0644, st_size=4801921, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f9a61785000
geteuid() = 1074
getegid() = 500
write(1, There is a screen on:\r\n\t17935.pt..., 130There is a screen on:
17935.pts-29.hal(Dead ???)
Remove dead screens with 'screen -wipe'.
There is no screen to be detached.
) = 130
exit_group(1)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
/var/lib/git
witam, pakiet git-core-daemon-standalone jest skonfigurowany na uzycie /var/lib/git natomiast np. suvbersion-svnserve na /home/services/subversion/repos. jest jakas dominujaca polityka co do umiejscowienia domyslnego katalogu dla danych roznych uslug? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
stale nfs handle.
witam, czasami przy pradopadzie, albo jakiejs innej awarii sieci/nfs-a na koncowkach klienckich pojawia sie blad 'stale nfs handle' przy probie zamontowania zasobu. restartowanie uslug eksportujacych po stronie serwera nie zawsze pomaga, poniewaz nie kasuja one np. popsutego pliku /var/lib/nfs/rmtab. czy ktos bedzie mial cos przeciwko jesli 'service nfs restart' bedzie kasowac wspomniany plik? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: stale nfs handle.
On Saturday 05 of January 2013 17:35:07 Jacek Konieczny wrote: On Sat, 05 Jan 2013 15:43:43 +0100 Paweł Sikora pl...@agmk.net wrote: czasami przy pradopadzie, albo jakiejs innej awarii sieci/nfs-a na koncowkach klienckich pojawia sie blad 'stale nfs handle' przy probie zamontowania zasobu. restartowanie uslug eksportujacych po stronie serwera nie zawsze pomaga, poniewaz nie kasuja one np. popsutego pliku /var/lib/nfs/rmtab. czy ktos bedzie mial cos przeciwko jesli 'service nfs restart' bedzie kasowac wspomniany plik? A czy to nie spowoduje, że upgrade nfs-utils (i restart nfs z tym związany) popsuje wszystkie aktywne połączenia? rmtab służy właśnie do przechowywania informacji na czas restartu. a gdzie wyczytales, ze rmtab ma przechowywac informacje na czas restartu serwisu? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
mount.nfs - cannot allocate memory.
witam, po serii updejtow th w ostatnich miesiacach na maszynach testowych pojawily mi sie zawirowania (problemy z montowaniem) na laczu nfs, ktore przez pewien czas byly maskowane dzialaniem autofs-a, ale w koncu wyizolowalem maly przyklad. od strony klienta czasami mam taki objaw: # mount.nfs -v 192.168.2.100:/home/atest/farm-local /mnt mount.nfs: timeout set for Thu Jan 3 09:25:30 2013 mount.nfs: trying text-based options 'vers=4,addr=192.168.2.100,clientaddr=192.168.2.103' mount.nfs: mount(2): Cannot allocate memory mount.nfs: Cannot allocate memory w dmesgu po obu stronach cisza, zadnych oopsow. w logach tez nic specjalnie nie widac. jakis podpowiedzi? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/uClibc] - rel 5; turn verbose on; filterout stack protector options (we didn't use that earlier, appared in
On Thursday 03 of January 2013 11:09:40 arekm wrote:
+%define filterout -fstack-protector
--param=ssp-buffer-size=4
i think that '%define _ssp_cflags %{nil}' looks better.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/dracut] - up to 024
On Thursday 27 of December 2012 23:29:49 gzohop wrote: commit c236c1ded8d438dda62a78903ea30ef9adb3f958 Author: Grzegorz Pycia / PLD gzo...@carme-pld-i686.pld-linux.org to chyba nie jest prawidlowy adres kontaktowy? ___ 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?
On Tuesday 04 of December 2012 12:28:27 Jacek Osiecki wrote: On Tue, 4 Dec 2012, Adam Osuchowski wrote: 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ą. To zwróć uwagę na moje podkreślenie :) Zainstalowane jest jedno rc-scripts. cache poldka sie rozjechal z rzeczywistoscia. jak go skasujecie, to sie z bazy rpm-a wczyta poprawny stan. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld-shutdown vs. ups :(
On Thursday 08 of November 2012 22:47:01 Jacek Konieczny wrote: On Thu, Nov 08, 2012 at 09:40:50PM +0100, Paweł Sikora wrote: dzis np. podpinalem nowe ups-y i testowe przejscie na baterie zawislo na the system is halted. http://imgbin.org/index.php?page=imageid=10238 Jak zrobiłeś 'halt' to dokładnie zrobił co potrzeba. dokladnie, to z nut-a wolane jest 'upsmon -c fsd' (forced shutdown). Masz systemd? SysVinit i upstart na polecenie 'halt' robiły poweroff, systemd robi to, o co się go prosi. Więc zwykle trzeba poprawić skrypty w których jest 'halt' zamiast 'poweroff'. wciaz SysVinit. z systemd sa tylko jakies podpakioety wciagniete przez zaleznosci. $ rpm -qa|egrep 'SysV|systemd|upstart'|sort systemd-libs-187-4.x86_64 systemd-units-187-4.x86_64 SysVinit-2.88-9.x86_64 SysVinit-tools-2.88-9.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: pld-shutdown vs. ups :(
On Friday 09 of November 2012 11:22:13 Jacek Konieczny wrote:
On Fri, Nov 09, 2012 at 10:29:02AM +0100, Paweł Sikora wrote:
On Thursday 08 of November 2012 22:47:01 Jacek Konieczny wrote:
On Thu, Nov 08, 2012 at 09:40:50PM +0100, Paweł Sikora wrote:
dzis np. podpinalem nowe ups-y i testowe przejscie na baterie zawislo
na the system is halted.
http://imgbin.org/index.php?page=imageid=10238
Jak zrobiłeś 'halt' to dokładnie zrobił co potrzeba.
dokladnie, to z nut-a wolane jest 'upsmon -c fsd' (forced shutdown).
Spróbuj dodać 'set -x' do /etc/rc.d/rc.shutdown, w okolicach:
show The $_rebootwhat is halted; ok
Po 'the system is halted' jeszcze parę rzeczy jest robione, w
szczególności komunikacja z UPSem. Więc może to nut nawala.
'set -x' jest masakryczne, bo debuguje mi te kropczeki co sie wszerz ekranu
maluja :)
ale zaobserwowalem jeszcze kilka rzeczy w trakcie kilku prob normalnego
restartowania
maszyny ($ reboot).
1).
akcja sending kill czasami ma problem i konczy z bledem (sending term
zawsze jest ok).
2).
odmontowanie filesystemow czasami przymulila i czeka, by w koncu tylko na r/o
przepiac.
3).
raz juz po komunikacie sending kill zaczelo co kilka sekund rzucac na konsole
cos w stylu cannot stat file /proc/$pid/fd/{1,2}, ale finalnie po 'system
halted'
poszedl powerdown.
4).
raz przy okolicznosciach podobnych do pkt 3. dostalem kernel panic
i system sie nie zamknal :)
http://imgbin.org/index.php?page=imageid=10253
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld-shutdown vs. ups :(
On Friday 09 of November 2012 14:31:59 Paweł Sikora wrote: On Friday 09 of November 2012 11:22:13 Jacek Konieczny wrote: On Fri, Nov 09, 2012 at 10:29:02AM +0100, Paweł Sikora wrote: On Thursday 08 of November 2012 22:47:01 Jacek Konieczny wrote: On Thu, Nov 08, 2012 at 09:40:50PM +0100, Paweł Sikora wrote: dzis np. podpinalem nowe ups-y i testowe przejscie na baterie zawislo na the system is halted. http://imgbin.org/index.php?page=imageid=10238 Jak zrobiłeś 'halt' to dokładnie zrobił co potrzeba. dokladnie, to z nut-a wolane jest 'upsmon -c fsd' (forced shutdown). Spróbuj dodać 'set -x' do /etc/rc.d/rc.shutdown, w okolicach: show The $_rebootwhat is halted; ok Po 'the system is halted' jeszcze parę rzeczy jest robione, w szczególności komunikacja z UPSem. Więc może to nut nawala. 'set -x' jest masakryczne, bo debuguje mi te kropczeki co sie wszerz ekranu maluja :) ale zaobserwowalem jeszcze kilka rzeczy w trakcie kilku prob normalnego restartowania maszyny ($ reboot). 1). akcja sending kill czasami ma problem i konczy z bledem (sending term zawsze jest ok). zdebugowalem to, i killall5 czasami zwraca kod 1 (manual: unable to find any processes). 2). odmontowanie filesystemow czasami przymulila i czeka, by w koncu tylko na r/o przepiac. http://imgbin.org/index.php?page=imageid=10261 jak widac na obrazku, nie mozna odmontowac /dev z powodu /dev/vg_storage/lv_root, swoja droga, chyba to wyrazenie w awku powinno z /proc/mounts wylowic lvm do odpiecia. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mesa z ready
On Thursday 08 of November 2012 10:57:57 Paweł Gołaszewski wrote: Mesa-libEGL-9.0-2 Powoduje problemy, na przykład: $ gnome-terminal gnome-terminal: symbol lookup error: /usr/lib/libEGL.so.1: undefined symbol: wl_registry_interface Nie startuje nic co ma cokolwiek wspólnego z gnome. Powrót do 9.0-1 naprawia problemy. potrzebny update pakietu wayland / odpowiednie R: w mesa. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
pld-shutdown vs. ups :(
witam, ostatnimi miesiacami zachowanie pld przy zamykaniu systemu zaczyna mnie coraz bardziej irytowac. ztcw, to w zaleznosci od nie wiem czego, rc-scripts maja problem z odmontowaniem filesystemow, co w szczegolnosci konczy sie twardym padem (wyczerpany akumulator upsa) i czasochlonnym fsck + resync TB macierzy. zjawisko obserwuje zarowno na laptopie (problemy z odmontowaniem / oraz /dev) jak i na serwerach (/, /dev/, /home/users, itp.) dzis np. podpinalem nowe ups-y i testowe przejscie na baterie zawislo na the system is halted. http://imgbin.org/index.php?page=imageid=10238 nie wiem, czy moje konfiguracje sa jakies ekstremalne, ze pld sobie z nimi nie radzi? z reguly mam / na macierzy raid1 (md0) oraz /home/* na podmacierzach roznych typow. w /remote/* mam montowane przez autofs-a zasoby nfs (nie dotyczy laptopa). $ cat /proc/mounts rootfs / rootfs rw 0 0 /dev/md0 / ext3 rw,relatime,errors=continue,commit=5,barrier=1,data=writeback 0 0 run /run tmpfs rw,relatime 0 0 none /proc proc rw,relatime,gid=17,hidepid=2 0 0 sysfs /sys sysfs rw,relatime 0 0 securityfs /sys/kernel/security securityfs rw,relatime 0 0 devtmpfs /dev devtmpfs rw,relatime,size=32953464k,nr_inodes=8238366,mode=755 0 0 /dev/md1 /home/atest ext4 rw,noatime,stripe=512,data=ordered 0 0 /dev/md2 /home/users ext4 rw,noatime,stripe=512,data=ordered 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 nfsd /proc/fs/nfsd nfsd rw,relatime 0 0 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 /etc/autofs/auto.alison /remote/alison autofs rw,relatime,fd=6,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.dragon /remote/dragon autofs rw,relatime,fd=12,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.dyzio /remote/dyzio autofs rw,relatime,fd=18,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.krzysieks /remote/krzysieks autofs rw,relatime,fd=24,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.seler /remote/seler autofs rw,relatime,fd=36,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.whitebox /remote/whitebox autofs rw,relatime,fd=48,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.nexus /remote/nexus autofs rw,relatime,fd=54,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 /etc/autofs/auto.hal /remote/hal autofs rw,relatime,fd=60,pgrp=1918,timeout=60,minproto=5,maxproto=5,indirect 0 0 dragon:/home/users/ /remote/dragon/ahome nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.0.2.121,mountvers=3,mountport=45251,mountproto=udp,local_lock=none,addr=10.0.2.121 0 0 nexus:/R10/ /remote/nexus/R10 nfs4 rw,noatime,vers=4.0,rsize=32768,wsize=32768,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=10,sec=sys,clientaddr=10.0.2.92,local_lock=none,addr=10.0.2.28 0 0 nexus:/R0/ /remote/nexus/R0 nfs4 rw,noatime,vers=4.0,rsize=32768,wsize=32768,namlen=255,soft,proto=tcp,port=0,timeo=600,retrans=10,sec=sys,clientaddr=10.0.2.92,local_lock=none,addr=10.0.2.28 0 0 odnosze wrazenie, ze rc-scripts nie radza sobie z wylaczeniem nfs/autofs/innych-sieciowych-fs oraz ze podwojne montowanie rootfs / i /dev/md0 / jest nie do przeskoczenia. jesli ktos ma kontruktywna porade, chetnie wyslucham :) dodam, ze maszyny dzialajce pod nadzorem centos nie maja problemow z shutdown ;) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
ffmpeg-libs-1.0-2 vs. libilbc.
witam, najnowszy updejt ffmpeg wymaga doinstalowania kodeka ilbc. ktory jest koszerny? webrtc-libilbc, czy libilbc? ___ 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
On Wednesday 24 of October 2012 13:51:11 Karol Krenski wrote: W dniu 24.10.2012 00:23, Jan Rękorajski pisze: 1. jest koszmarnie wolny i zżera całe zasoby (odczuwalne szczególnie przy większej ilości paczek do instalacji/deinstalacji). Zauważyłem coś dokładnie odwrotnego, wyliczanie zależności przez poldka/rpm trwa teraz o kilka rzędów wielkości szybciej, sama instalacja tak samo jak na rpm4. OK. Testujemy. Dwa chrooty ze środowiskiem do budowania (repackage wyłączone): 1. poldek-0.30-1.rc6.4.i686 rpm-5.4.10-22.i686 2. poldek-0.30-1.rc5.14.i686 rpm-4.5-69.i686 Ewentualny wpływ dysku można pominąć - oba środowiska na SSD Przygotowanie: ./builder -nn -bp VirtualBox -R cat .VirtualBox.INSTALLED_PACKAGES | wc -l 183 poldek -e `cat .VirtualBox.INSTALLED_PACKAGES` Mamy 183 paczki do instalacji/deinstalacji, a więc do dzieła. a) time poldek -i --noask `cat .VirtualBox.INSTALLED_PACKAGES` 1. real0m18.439s user0m9.995ssys 0m1.348s 2. real0m14.332s user0m10.515s sys 0m1.204s b) time poldek -e --noask `cat .VirtualBox.INSTALLED_PACKAGES` 1. real0m24.764s user0m11.831s sys 0m0.716s 2. real0m4.839s user0m1.813ssys 0m0.590s Druga próba dla wine: cat .wine.INSTALLED_PACKAGES | wc -l 254 a) time poldek -i --noask `cat .wine.INSTALLED_PACKAGES ` 1. real0m27.784s user0m13.720s sys 0m1.446s 2. real0m22.117s user0m15.226s sys 0m1.067s b) time poldek -e --noask `cat .wine.INSTALLED_PACKAGES ` 1. real0m21.437s user0m5.385ssys 0m0.574s 2. real0m7.168s user0m1.924ssys 0m0.483s Podsumowanie? rpm-5.4.10 + poldek jest wolniejszy - szczególnie to widać przy deinstalacji paczek. wniosek jest taki, ze nie wiadomo co jest wolniejsze (poldek, rpm, db) bo pod spodem dzialaja jeszcze dwie rozne wersje bazy danych. ___ 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
On Wednesday 24 of October 2012 17:58:10 Karol Krenski wrote: W dniu 24.10.2012 17:44, Paweł Sikora pisze: wniosek jest taki, ze nie wiadomo co jest wolniejsze (poldek, rpm, db) bo pod spodem dzialaja jeszcze dwie rozne wersje bazy danych. A jakie to ma znaczenie praktyczne dla użytkownika? Tak jak wspomniałem... Aktualny tandem poldek + rpm jest wolniejszy. krotka analiza logu strace wykazala, ze nalezy uzyc opcji 'rpm --nofsync' by pozbyc sie masakrycznej ilosci synchronizacji (fdatasync). ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
poldek - popsute 'particle install'
przy domyslnie wlaczonej opcji particle-install aktualizacja lezy, mimo iz --test pokazuje ze bledow sie nie spodziewa. poldek:/all-avail upgrade * --test Przetwarzanie zależności... SysVinit-tools-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-tools-2.88-9.x86_64 SysVinit-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-2.88-9.x86_64 coreutils-8.16-1.x86_64 zostanie zastąpiony przez coreutils-8.19-1.x86_64 libblkid-2.21.2-3.x86_64 zostanie zastąpiony przez libblkid-2.22.1-1.x86_64 util-linux-2.21.2-3.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 eject-2.1.5-4.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 libmount-2.21.2-3.x86_64 zostanie zastąpiony przez libmount-2.22.1-1.x86_64 fsck-2.21.2-3.x86_64 zostanie zastąpiony przez fsck-2.22.1-1.x86_64 mount-2.21.2-3.x86_64 zostanie zastąpiony przez mount-2.22.1-1.x86_64 Jest 8 pakietów do instalacji, 9 do usunięcia: I SysVinit-2.88-9.x86_64 SysVinit-tools-2.88-9.x86_64 coreutils-8.19-1.x86_64 fsck-2.22.1-1.x86_64 libblkid-2.22.1-1.x86_64 I libmount-2.22.1-1.x86_64 mount-2.22.1-1.x86_64 util-linux-2.22.1-1.x86_64 R SysVinit-2.88-7.x86_64 SysVinit-tools-2.88-7.x86_64 coreutils-8.16-1.x86_64 eject-2.1.5-4.x86_64 fsck-2.21.2-3.x86_64 libblkid-2.21.2-3.x86_64 R libmount-2.21.2-3.x86_64 mount-2.21.2-3.x86_64 util-linux-2.21.2-3.x86_64 This operation will use 2.0MB of disk space. Potrzeba pobrać 5.9MB archiwów. poldek:/all-avail upgrade * Przetwarzanie zależności... SysVinit-tools-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-tools-2.88-9.x86_64 SysVinit-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-2.88-9.x86_64 coreutils-8.16-1.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 util-linux-2.21.2-3.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 eject-2.1.5-4.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 błąd: fileutils jest wymagany przez zainstalowany pakiet rc-scripts-0.4.5.4-2.x86_64, poddaję się Installing set #2 Przetwarzanie zależności... coreutils-8.16-1.x86_64 zostanie zastąpiony przez coreutils-8.19-1.x86_64 coreutils-8.19-1.x86_64 zaznaczył util-linux-2.22.1-1.x86_64 (wł. util-linux = 2.22) util-linux-2.21.2-3.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 eject-2.1.5-4.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 libblkid-2.21.2-3.x86_64 zostanie zastąpiony przez libblkid-2.22.1-1.x86_64 libmount-2.21.2-3.x86_64 zostanie zastąpiony przez libmount-2.22.1-1.x86_64 fsck-2.21.2-3.x86_64 zostanie zastąpiony przez fsck-2.22.1-1.x86_64 util-linux-2.22.1-1.x86_64 zaznaczył SysVinit-tools-2.88-9.x86_64 (wł. SysVinit-tools = 2.88-9) SysVinit-tools-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-tools-2.88-9.x86_64 zachłanna aktualizacja SysVinit-2.88-7.x86_64 do 2.88-9.x86_64 (niespełnione SysVinit-tools = 2.88-7) SysVinit-2.88-7.x86_64 zostanie zastąpiony przez SysVinit-2.88-9.x86_64 Jest 7 pakietów do instalacji (3 zaznaczone pośrednio), 8 do usunięcia: I coreutils-8.19-1.x86_64 fsck-2.22.1-1.x86_64 libblkid-2.22.1-1.x86_64 libmount-2.22.1-1.x86_64 D SysVinit-2.88-9.x86_64 SysVinit-tools-2.88-9.x86_64 util-linux-2.22.1-1.x86_64 R SysVinit-2.88-7.x86_64 SysVinit-tools-2.88-7.x86_64 coreutils-8.16-1.x86_64 eject-2.1.5-4.x86_64 fsck-2.21.2-3.x86_64 libblkid-2.21.2-3.x86_64 R libmount-2.21.2-3.x86_64 util-linux-2.21.2-3.x86_64 This operation will use 2.0MB of disk space. Potrzeba pobrać 5.7MB archiwów. Uruchamianie rpm --upgrade -vh --root /... error: Niespełnione zależności: libmount = 2.21.2-3 jest wymagany przez (zainstalowany) mount-2.21.2-3.x86_64 Installing set #3 Przetwarzanie zależności... mount-2.21.2-3.x86_64 zostanie zastąpiony przez mount-2.22.1-1.x86_64 mount-2.22.1-1.x86_64 zaznaczył libmount-2.22.1-1.x86_64 (wł. libmount = 2.22.1-1) libmount-2.21.2-3.x86_64 zostanie zastąpiony przez libmount-2.22.1-1.x86_64 libmount-2.22.1-1.x86_64 zaznaczył libblkid-2.22.1-1.x86_64 (wł. libblkid = 2.22.1-1) libblkid-2.21.2-3.x86_64 zostanie zastąpiony przez libblkid-2.22.1-1.x86_64 zachłanna aktualizacja util-linux-2.21.2-3.x86_64 do 2.22.1-1.x86_64 (niespełnione libblkid = 2.21.2-3) coreutils-8.16-1.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 util-linux-2.21.2-3.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 eject-2.1.5-4.x86_64 zostanie zastąpiony przez util-linux-2.22.1-1.x86_64 błąd: fileutils jest wymagany przez zainstalowany pakiet rc-scripts-0.4.5.4-2.x86_64, poddaję się błąd: libmount-2.22.1-1.x86_64: nie znaleziono wymaganego libblkid.so.1()(64bit) błąd: libmount-2.22.1-1.x86_64: nie znaleziono wymaganego libblkid.so.1(BLKID_1.0)(64bit) błąd: libmount-2.22.1-1.x86_64: nie znaleziono wymaganego libblkid.so.1(BLKID_2.15)(64bit) błąd: libmount-2.22.1-1.x86_64: nie znaleziono wymaganego libblkid.so.1(BLKID_2.17)(64bit) błąd: mount-2.22.1-1.x86_64: nie znaleziono wymaganego libmount.so.1()(64bit) błąd: mount-2.22.1-1.x86_64: nie
Re: [RFD] wersja rpm
On Wednesday 24 of October 2012 21:22:36 Karol Krenski wrote: W dniu 24.10.2012 19:06, Paweł Sikora pisze: krotka analiza logu strace wykazala, ze nalezy uzyc opcji 'rpm --nofsync' by pozbyc sie masakrycznej ilosci synchronizacji (fdatasync). Dzięki. Jest _troszkę_ lepiej. cat .wine.INSTALLED_PACKAGES | wc -l 254 a) time poldek -i --noask --pmopt=--nofsync `cat .wine.INSTALLED_PACKAGES` rpm5. real0m24.365suser0m13.338s sys 0m1.571s rpm4. real0m22.117suser0m15.226ssys 0m1.067s b) time poldek -e --noask --pmopt=--nofsync `cat .wine.INSTALLED_PACKAGES ` rpm5. real0m16.314s user0m4.974ssys 0m0.658s rpm4. real0m7.168suser0m1.924ssys 0m0.483s no to popatrz jak to dziala na klasycznym 500GB dysku w laptopie: # time rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force 0,32s user 0,11s system 7% cpu 5,778 total # time rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force 0,29s user 0,12s system 9% cpu 4,280 total # time rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force --nofsync rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force --nofsync 0,28s user 0,08s system 88% cpu 0,410 total # time rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force --nofsync rpm -i xorg-xserver-server-1.13.0-2.x86_64.rpm --force --nofsync 0,29s user 0,08s system 48% cpu 0,771 total real-time (total) bez synchronizacji filesystemu jest znaczaco lepszy dla klasycznego dysku podczas, gdy user/system-cputime sa zblizone. nie mam dysku ssd, ale podejzewam ze fizyka dysku ssd nie zgrywa sie z algorytmami kernela/filesystemu. ___ 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
On Tuesday 23 of October 2012 16:31:55 Jakub Bogusz wrote: [ ] rpm5 rozwijanego w archaicznym środowisku i masochistycznych warunkach [ ] rpm4 rozwijanego pod patronatem RH (a niech zaryzykuję - community-driven) (no dobra, trochę te pytania wskazują na odpowiedź - przepraszam) Ewentualnym biznesofobom przypomnę, że większość kodu kernela jest sponsorowana. Pytanie co jest tańsze - utrzymywanie własnego forka rpm5 czy rpm.org? Upstream w przypadku rpm.org powinien być stabilniejszy, ale nie wiemy, czy bardziej otwarty (bez sprawdzenia - jestem sceptyczny). Poziom community-driven można przetestować próbując nakarmić łatkami z PLD (choćby tymi, które w rpm5 już są - można zidentyfikować śledząc historię począwszy od 4.4.2, kiedy nastąpiło rozgałęzienie). Z czysto technicznych różnic, które wychwyciłem przeglądając listę zmian, mających IMO większe znaczenie: - zaletą rpm.org jest obsługa file capabilities, nowy atrybut plików %caps() - dużą wadą brak repackage (cała obsługa wycięta na samym początku tworzenia wersji 4.6) powiem szczerze, ze nigdy nie uzylem repackage (mimo wielu sytuacji awaryjnych ktore dostarczylo mi th-test uzywane na desktopie i testowych serwerach). zawsze downgrade poldkiem/rpm do poprzedniej wersji lezakujacej w main/ready/.archive dawal szybki i wystarczajacy efekt. natomiast problemow z repackage mialem kilka (out-of-memory + kill aktualizacji na maszynach bez swapa, powolne aktulizacje duzych zestawow paczek, zapchane /var/ u uzytkownikow, itp. jesli ten ficzer zniknie, a w zamian bedziemy miec uzywane i *rozwijane* wersje rpm-4.x, to wcale plakac nie bede. oczywiscie jesli te *rozwijane* nie beda akceptowac slusznych latek pld, bo nie sa redhat/suse-way, to tez nie ma sie co na sile uszczesliwiac i chyba lepiej wrocic do tego co bylo. 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. ___ 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
On Tuesday 23 of October 2012 20:08:20 Tomasz Pala 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. A to ma jakieś znaczenie praktyczne? w przypadku pakietow/bibliotek napisanych w c++ ma. obecnie coraz wieksza ich ilosc zaczyna sie kompilowac ze swoim wybranym wariantem c++ (np. 0x, 11) i pojawiaja sie roznice w abi produkowanych binarek, np. biblioteka X kompiluje sie z std=c++0x@gcc4.6 a jakis czas pozniej program Y (uzywajacy X) kompiluje sie z std=c++0x@gcc-4.7. poniewaz wspracie dla 0x/11 jest wciaz i nadal experimental, wiec zdarzaja sie zmiany, ktore powoduja rozne dziwne wyloty na wspolpracujacych binarkach kompilowanych roznymi wersjami gcc. dla swietego spokoju lepiej wszystko przemielic jedna linia od zera i tak wlasnie robi fedora w swoim mass(ive) rebuild. druga sprawa, mniej istotna (bo dokladajaca nam roboty), to wychwycenie pakietow, ktore sie nie kompiluja na nowej wersji gcc. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Zwis rpma na weryfikacji pakietu ntpd
On Tuesday 16 of October 2012 22:06:50 Artur Frysiak wrote: 2012/10/16 Adam Osuchowski ad...@zonk.pl Jest to powtarzalne na kilku moich niezależnych instalacjach, bez różnicy czy odpalane z roota czy ze zwykłego usera i występuje zarówno na x86 jak i x86-64. Czy ktoś może to potwierdzić (kolejny bug w rpmie?) i ew. spróbować coś więcej zdiagnozować? Potwierdzam na x86_64 $ rpm -q rpm ntpd rpm-5.4.10-22.x86_64 ntpd-4.2.6p5-5.x86_64 problem wystepuje tez przy instalacji ntpd i wyglada na jakis bug w rpm-ie, ktory kreci sie w kolko wewnatrz sprawdzania roznych zaleznosci pakietu. (...) #11 0x7f8be518bb11 in checkDependentConflicts (ts=ts@entry=0x1fc09f0, depName=depName@entry=0x1fc1310 ntp) at depends.c:1878 #12 0x7f8be518bdc9 in _rpmtsCheck (ts=0x1fc09f0) at depends.c:1966 #13 0x7f8be51a73ea in rpmcliInstallCheck (ts=ts@entry=0x1fc09f0) at rpminstall.c:346 #14 0x7f8be51a8168 in rpmcliInstall (ts=ts@entry=0x1fc09f0, ia=ia@entry=0x7f8be53cd900, argv=optimized out) at rpminstall.c:742 #15 0x004031db in main (argc=optimized out, argv=optimized out) at ./rpmqv.c:996 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: avahi-daemon z avahi- wywraca się przy starcie (winne libgcc)
On Monday 15 of October 2012 19:49:09 Artur Frysiak wrote: 2012/10/15 Łukasz Maśko e...@yen.ipipan.waw.pl Dnia sobota, 13 października 2012, Łukasz Maśko napisał: Dnia sobota, 13 października 2012, Łukasz Maśko napisał: avahi-daemon nie startuje. Dostaje segfaulta, który się objawia w dmesgu i logach: Aha, avahi-0.6.31-4.i686 I winne jest libgcc-4.7.2-3, na *-1 problem nie występuje. U mnie (x86_64) kręci się w libssp: (gdb) where #0 0x7f6d019776f3 in __vsnprintf_chk () from /lib64/libssp.so.0 #1 0x7f6d02633e0a in vsnprintf (__ap=optimized out, __fmt=optimized out, __n=256, __s=0x7fff398275d0 0w\202\071\377\177) at /usr/include/bits/stdio2.h:77 #2 avahi_log_ap (level=level@entry=AVAHI_LOG_INFO, format=format@entry=0x416db0 Found user 'avahi' (UID %lu) and group 'avahi' (GID %lu)., ap=ap@entry=0x7fff398276f8) at log.c:38 #3 0x7f6d02634174 in avahi_log_info (format=format@entry=0x416db0 Found user 'avahi' (UID %lu) and group 'avahi' (GID %lu).) at log.c:77 #4 0x0040650e in drop_root () at main.c:1305 #5 main (argc=optimized out, argv=optimized out) at main.c:1600 na x86-64 sie kreci w kolko i wypala stos, a na i686 ze wzgledu na inny sposob przekazywania argumentow jest po chwili przepelnienie stosu. tak czy siak nie jest tu winne libgcc, tylko sam optymalizator i sprawa wyglada bardzo podobnie jak http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50916 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
ldconfig: Nie można wykonać mmap pliku /usr/lib64/libgomp.so.
witam, dzisiejszy upgrejd th przynioslo nowe ciekawostki: # ldconfig ldconfig: Nie można wykonać mmap pliku /usr/lib64/libgomp.so. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
error: skrypt Lua nie powiódł się: [string %pretrans(filesystem-4.0-13.x86_64)]:2: attempt to index global 'posix' (a nil value)
poldek:/all-avail upgrade filesystem-4.0-13.x86_64 Przetwarzanie zależności... filesystem-4.0-12.x86_64 zostanie zastąpiony przez filesystem-4.0-13.x86_64 Jest 1 pakiet do instalacji, 1 do usunięcia: I filesystem-4.0-13.x86_64 R filesystem-4.0-12.x86_64 Potrzeba pobrać 18.6KB archiwów (18.6KB do pobrania). Pobieranie th-test::filesystem-4.0-13.x86_64.rpm... .. 100.0% [18.6K (18.6K/s)] Uruchamianie rpm --upgrade -vh --root /... error: skrypt Lua nie powiódł się: [string %pretrans(filesystem-4.0-13.x86_64)]:2: attempt to index global 'posix' (a nil value) Przygotowywanie... ### [100%] 1:filesystem ### [100%] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
filesystem-4.0-13.x86_64 marks FHS-2.3-35.x86_64 (cap //)
dzisiejszy upgrade i zonk: poldek:/all-avail upgrade * Processing dependencies... filesystem-4.0-12.x86_64 obsoleted by filesystem-4.0-13.x86_64 filesystem-4.0-13.x86_64 marks FHS-2.3-35.x86_64 (cap //) error: FHS-2.3-35.x86_64: equal version installed, give up ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
rpm -qV
witam,
zauwazylem, ze nowy rpm jakby nie zauwazal zmiany pliku nalezacego do pakietu.
[root@src ~]# rpm -qf /etc/rc.d/init.d/svnserve
subversion-svnserve-1.7.6-1.x86_64
[root@src ~]# grep user /etc/rc.d/init.d/svnserve
daemon --user builder svnserve ${SVNSERVE_OPTIONS} -r ${SVNSERVE_PATH}
^^^ domyslnie jest svn
[root@src ~]# rpm -qV subversion-svnserve
[root@src ~]#
jak dotad --verify zglaszalo roznice w md5.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: rpm -qV
On Saturday 22 of September 2012 14:19:30 Tomasz Pala wrote: On Sat, Sep 22, 2012 at 14:05:29 +0200, Paweł Sikora wrote: [root@src ~]# rpm -qV subversion-svnserve jak dotad --verify zglaszalo roznice w md5. A samo -V? bez roznicy. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
rpm vs. debuginfo.
witam, przy probie aktualizacji qt4-debuginfo zaskoczyl mnie blad: There are 2 packages to install, 2 to remove: I qt4-debuginfo-4.8.3-1.x86_64 qt4-qmake-4.8.3-1.x86_64 R qt4-debuginfo-4.8.2-11.x86_64 qt4-qmake-4.8.2-11.x86_64 This operation will use 217.0KB of disk space. Need to get 700.6MB of archives. Executing rpm --upgrade -vh --root /... error: Failed dependencies: /usr/src/examples/qt4/opengl/pbuffers2/pbuffers2 is needed by qt4-debuginfo-4.8.3-1.x86_64 /usr/src/examples/qt4/draganddrop/draggableicons/draggableicons is needed by qt4-debuginfo-4.8.3-1.x86_64 (...) mamy tu chyba do czynienia z nadpobudliwoscia rpm-a, bo oczywiste jest, ze pliki zrodlowe nie sa wymagane do debugowania binarki. moga sie przydac, ale konieczne nie sa. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Th development plans
On Tuesday 04 of September 2012 12:20:56 Jan Rękorajski wrote: Hi, After making a snapshot, and having (development wise) stable package set, I want to start refreshing the distribution. This means big changes in the near future to get PLD back to being modern (or at least up-to-date) wrt current Linux world. Below I present a plan (a.k.a The Roadmap) for Th: - db 5.3 as default system BerkeleyDB - rpm 5.4.x - perl 5.16.x - apache 2.4.x - full systemd support (provide systemd units, but still support SysV scripts - at least until vserver will be able to run systemd) - drop *-initrd packages, building them is becoming a RPITA, and the net gain is not worth the pain - grsecurity support in our kernels will be dropped, until someone volunteers to keep that patch up-to-date - kernel 3.4.x will become the new -longterm Of course, the always-in-development model stays, other non-conflicting changes are welcome, and if you have any comments and proposals please say so. i'm thinking about one idea - compiling linux distro with clang into platform idenpendent bitcode (somthing like .rpm.noarch) and providing platform specific ll-virtual-machine but currently there's a serious limitation - no shared bitcode linking :/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
/dev/bus/usb/...
witam, ktos moze wie jak skonfigurowac pld, aby uzytkownik bedacy w grupie usb, zalogowany lokalnie (consolekit itp.) mial dostep do /dev/bus/usb/...? potrzebuje tego, by qemu mialo dotep do urzadzen hosta (konkretnie gpsa). dawniej bylo /proc/bus/usb, a teraz jest lipa :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: xorg-driver-video-intel / sna crash.
On Thursday 19 of July 2012 07:58:30 Paweł Sikora wrote: witam, przy wylogowaniu uzytkownika kde4 via kdm, xserver zalicza zgon na skutek drivera intela z ta nowoscia pt. sna. Program received signal SIGSEGV, Segmentation fault. ShmDestroyPixmap (pPixmap=0x1b3b580) at shm.c:272 272 pScreen-DestroyPixmap = screen_priv-destroyPixmap; (gdb) bt #0 ShmDestroyPixmap (pPixmap=0x1b3b580) at shm.c:272 #1 0x7ff52a9a3c86 in sna_glyphs_create (sna=sna@entry=0x7ff52e0d5010) at sna_glyphs.c:227 #2 0x7ff52a97e479 in sna_accel_create (sna=sna@entry=0x7ff52e0d5010) at sna_accel.c:12963 #3 0x7ff52a9a1add in sna_create_screen_resources (screen=0x1cf28a0) at sna_driver.c:197 #4 0x0049e6c7 in xf86CrtcCreateScreenResources (screen=0x1cf28a0) at xf86Crtc.c:704 #5 0x0042320c in main (argc=7, argv=0x7fff6a1507d8, envp=optimized out) at main.c:215 najnowsza wersja 2.20.7 wraz z nowym xserverem wydaja sie znow dzialac poprawnie. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: cryptopp 5.5.2 i gcc 4.7
zrobilem updejt calosci, ale cos distfiles nie poradzily sobie z sf.net. jak ktos bedzie mial ochote z tym powalczyc, to mozna to puscic na buildery. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
gnutls-3.1.0 - sigsegv @ trousers-libs.
witam, aktualizacja gnutls z 3.0.22 do 3.1.0 powoduje wylot przy starcie np. mplayera. Program received signal SIGSEGV, Segmentation fault. host_table_init () at rpc/hosttable.c:27 (gdb) bt #0 host_table_init () at rpc/hosttable.c:27 #1 0x7fffe61c43ab in my_init () at rpc/hosttable.c:45 #2 0x77de9a26 in call_init (env=0x7fffdf68, argv=0x7fffdf58, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7fffdf58, env=0x7fffdf68) at dl-init.c:34 #4 0x77de9b0a in _dl_init (main_map=0x77ffe188, argc=1, argv=0x7fffdf58, env=0x7fffdf68) at dl-init.c:133 #5 0x77ddc66a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 $ valgrind --leak-check=full /usr/bin/mplayer ==11453== Memcheck, a memory error detector ==11453== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==11453== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==11453== Command: /usr/bin/mplayer ==11453== ==11453== ==11453== Process terminating with default action of signal 11 (SIGSEGV) ==11453== Bad permissions for mapped region at address 0xDA439A0 ==11453==at 0x1678937D: host_table_init (hosttable.c:27) ==11453==by 0x167893AA: my_init (hosttable.c:45) ==11453==by 0x400EA25: call_init (in /lib64/ld-2.16.so) ==11453==by 0x400EB09: _dl_init (in /lib64/ld-2.16.so) ==11453==by 0x4001669: ??? (in /lib64/ld-2.16.so) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: gnutls-3.1.0 - sigsegv @ trousers-libs.
On Sunday 02 of September 2012 19:27:02 Łukasz Maśko wrote: Dnia niedziela, 2 września 2012, Jakub Bogusz napisał: [...] Może przebudowanie trousers coś pomoże... U mnie nie pomogło. fixed @ trousers-0.3.9-2 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
czy leci z nami moderator?
witam, ostatnio probowalem odswiezyc subskrybcje pld-cvs-commits bez wiekszego skutku. jak doniosly mi dobrze poinformowane zrodla moje proby utknely na moderatorze w osobie Zbynia. czy ktos ma kontakt z owa osoba, bo na maila mi nie odpisal? AdamG, list administrator tez milczy... ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: czy leci z nami moderator?
watek juz nieaktualny, moderator sie objawil. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Th snapshot
On Tuesday 28 of August 2012 09:38:07 Lukasz Glebicki wrote: On Monday 27 of August 2012 20:15:48 Jan Rękorajski wrote: Do you remember by any chance what the offending packages were? And please report such cases in the future. As a fan of a brillinat film Back to the future: From my .poldek history, I did some uninstall/install to upgrade my kde packages. 1) gwenview uninstall kde4-kdegraphics-gwenview-4.6.5-3.x86_64 install kde4-gwenview-4.9.0-1.x86_64 2) ksnapshot uninstall kde4-kdegraphics-ksnapshot-4.6.100-1.x86_64 install kde4-gwenview-4.9.0-1.x86_64 3) kfile uninstall kde4-kdegraphics-kfile-4.6.100-1.x86_64 This package has no successor or I don't know exacly what had this package inside. 4) svgpart, kruler, kolorpaint,kgamma uninstall kde4-kdegraphics-svgpart-4.6.100-1.x86_64 kde4-kdegraphics- kruler-4.6.100-1.x86_64 kde4-kdegraphics-kolourpaint-4.6.100-1.x86_64 install kde4-kgamma-4.8.4-1.x86_64 kde4-kolourpaint-4.8.4-1.x86_64 kde4- svgpart-4.9.0-1.x86_64 uninstall kde4-kdegraphics-kgamma-4.6.100-1.x86_64 install kde4-kgamma-4.8.4-1.x86_64 kde4-kolourpaint-4.8.4-1.x86_64 kde4- svgpart-4.9.0-1.x86_64 install kde4-kruler-4.9.0-1.x86_64 5) kamera uninstall kde4-kdegraphics-kamera-4.6.100-1.x86_64 install kde4-kamera-4.8.4-1.x86_64 6) kate, kwrte uninstall kde4-kdesdk-kate-4.6.100-1.x86_64 kde4-kdebase- kwrite-4.6.100-1.x86_64 install kde4-kate-4.9.0-1.x86_64 7) kcolorchooser uninstall kde4-kdegraphics-kcolorchooser-4.6.100-1.x86_64 install kde4-kcolorchooser-4.9.0-1.x86_64 8) install kde4-kgpg-4.8.4-1.x86_64 install kde4-kwallet-4.9.0-1.x86_64 install kde4-printer-applet-4.9.0-2.x86_64 9). no upgrade path for kde4-splash-Default-4.8.x and others. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Th snapshot
On Tuesday 28 of August 2012 10:28:17 Jan Rękorajski wrote: 9). no upgrade path for kde4-splash-Default-4.8.x and others. kde-kdebase-artwork O:kde4-splash-Default others AFAIR should be obsoleted by kdebase ok, one more issue (probably missed requires): click: menu - settings - system settings - multimedia - phonon without phonon-backend-* there's a segmentation fault. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
libc @ initrd.
witam, czy ktos zna jakies powody by nadal budowac na sile rozne narzedzia idace do initrd za pomoca fikusnych implementacji libc (uclibc, klibc, itp) ? obecnie niektore bez latania nie chca sie skompilowac, a niektore sa budowane ze statycznym glibc-em. efekt jest taki, ze w initrd sa wymieszane rozne statyczne kompilaty i calosciowo wcale to takie minimalistyczne nie jest. moze jednak wezmiemy dynamiczny glibc do initrd i odpuscimy ta dziwna walke o kilobajty? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Th snapshot
On Monday 20 of August 2012 12:39:46 Jan Rękorajski wrote: Hi, On september 1st I will make snapshot of Th line, named 2012. it will contain the current state of main/ready/test tree (with probable exception of KDE 4.9 as it is not fully updated). So if you know of any problems in current package set please report and/or fix them. kde-4.9 upgrade is almost completed. there're few todos: - split kde4-mutlimedia packages (http://comments.gmane.org/gmane.comp.kde.releases/5660) - add kde4-sweeper package (+obsoletes for kde4-kdeutils-sweeper-4.7.x.) - announce kde4-ksecrets ftp removal (buggy/unfinished/removed from kde). ___ 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 licencja
On Thursday 23 of August 2012 18:07:46 Kacper Kornet wrote: Jak należy postępować gdy razem ze źródłem programu nie ma żadnego pliku COPYING, LICENSE itp., natomiast w jednym z plików źródłowych jest coś takiego: * Audacious playlist format plugin Copyright 2011 John Lindgren * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions, and the following disclaimer in the * documentation provided with the distribution. * * This software is provided as is and without any warranty, express or * implied. In no event shall the authors be liable for any damages * arising from the use of this software. wyglada jak BSD-like, w szczegolnosci: http://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29 ___ 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 licencja
On Thursday 23 of August 2012 19:20:00 Kacper Kornet wrote: On Thu, Aug 23, 2012 at 07:07:03PM +0200, Paweł Sikora wrote: On Thursday 23 of August 2012 18:07:46 Kacper Kornet wrote: Jak należy postępować gdy razem ze źródłem programu nie ma żadnego pliku COPYING, LICENSE itp., natomiast w jednym z plików źródłowych jest coś takiego: * Audacious playlist format plugin Copyright 2011 John Lindgren * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions, and the following disclaimer in the * documentation provided with the distribution. * * This software is provided as is and without any warranty, express or * implied. In no event shall the authors be liable for any damages * arising from the use of this software. wyglada jak BSD-like, w szczegolnosci: http://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29 Bardziej mi chodziło jaka jest praktyka spełnienie warunku must reproduce the above copyright notice. Wydzielać ten tekst do osobnego pliku COPYING i go pakować, czy jakieś inne podejście. oidp, to nie pakujemy plikow ze standardowym tekstem licencji, tylko wpisujemy odpowiednie wartosci w .specu w polu license. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: w32codec updated
On Tuesday 14 of August 2012 17:17:15 Artur Frysiak wrote: 2012/8/7 Bartosz Taudul wolf@gmail.com: Ponieważ Bartek cały czas jest żywotnie zainteresowany rozwojem dystrybucji i aktywnie przyczynia się do wprowadzania zmian, proponuję aby dać mu dostęp RW do repozytorium. Zanim Bartek dostanie ponownie RW to myślę, że osoby które dają mu +1 powinny robić review jego kodu. A dzięki temu że mamy teraz gita to myślę, że można to zorganizować to tak, że Bartek będzie podsyłał patche (git format-patch) swoim mentorom a oni będą aplikować te patche przez git am --signoff no to zabiłeś klina :) Po pewnym czasie, gdy patche Bartka nie będą powodować problemów Bartek mógłby dostać RW. bez zbiorowego khatarsis się nie obejdzie :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: w32codec updated
On Sunday 12 of August 2012 21:54:40 Bartlomiej Zimon wrote: +1 W sumie to kazdy powinien miec szanse sie zrehabilitowac. Za to co mi sie nasuwa najbardziej, to to ze chlopaki znajac glowne problemy i niedociagniecia w PLD, wykorzystali je do zabawy na listach w berka ;) Czasem to wygladalo naprawde zabawnie ale na dluzsza mete robilo sie niesmaczne. Mysle ze jest teraz okazja ponownego polaczenia sil, a nie boczenia sie. i podbicie numerka Z w pakiecie wersjonowanym przez X.Y.Z, to ma byc wielka rehabilitacja developera po tych wszystkich polemikach i rzyganiu po dystrybucji? takie rzeczy (+test build) powinien wykonywac automat, a nie ludzie - tu jest pole do popisu. poki co, -1 z mojej strony. perspektywa ratingu niezdefiniowana. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
mdadm boot @ kernel-3.5.0.
witam, proba zabootowania pld na czystym jajku 3.5.0 zakonczyla sie padaczka: http://pluto.agmk.net/kernel/DSC_0188.jpg na pierwszy rzut oka wyglada to tak jakby mdassemble sie nie podnioslo i dalej to juz wszystko leglo. moje punkty montowania ukladaja sie tak: [root@localhost ~]# cat /proc/mdstat Personalities : [raid10] [raid1] md0 : active raid1 sda1[0] sdb1[1] 497856 blocks [2/2] [UU] md1 : active raid10 sda2[0] sdb2[1] 487886848 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU] unused devices: none [root@localhost ~]# df -h System plików rozm. użyte dost. %uż. zamont. na rootfs 16G 11G 5,0G 68% / /dev/vg_storage/lv_root 16G 11G 5,0G 68% / run 5,9G 300K 5,9G 1% /run devtmpfs5,9G 0 5,9G 0% /dev /dev/md0471M 29M 443M 6% /boot /dev/mapper/vg_storage-lv_home 403G 250G 153G 62% /home none5,9G 0 5,9G 0% /dev/shm cgroup 5,9G 0 5,9G 0% /sys/fs/cgroup grub laduje system z mirrora md0 (/boot) i dalej powinnien sie podniesc raid10 z lvm-em. na jajku 3.4.6 wsio dziala, a na 3.5 zonk. przy 3.4 kernel sypal warningami nt. ioctl() wykonywanych na partycjach, moze w 3.5 ucieli ten temat definiywnie? ktos sie z czyms takim spotkal? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: mdadm boot @ kernel-3.5.0.
On Thursday 26 of July 2012 20:57:28 Artur Frysiak wrote: 2012/7/26 Paweł Sikora pl...@agmk.net: witam, proba zabootowania pld na czystym jajku 3.5.0 zakonczyla sie padaczka: http://pluto.agmk.net/kernel/DSC_0188.jpg na pierwszy rzut oka wyglada to tak jakby mdassemble sie nie podnioslo i dalej to juz wszystko leglo. udev w initrd/initramfs jest? Czym generowaleś initrd? udev jest, initrd generowane klasycznie przez geninitrd. [root@localhost ~]# geninitrd -f -v /boot/initrd-3.5.0.gz 3.5.0 geninitrd: # $Revision: 12530 $ $Date:: 2012-03-30 14:41:13 + #$ (geninitrd) geninitrd: find_tool: found /usr/lib64/initrd/busybox geninitrd: find_tool: found /usr/lib64/initrd/lvm geninitrd: find_tool: found /usr/lib64/initrd/mdassemble geninitrd: find_tool: found /sbin/mdadm geninitrd: find_tool: found /usr/lib64/initrd/blkid geninitrd: Finding USB keyboard modules geninitrd: Finding SATA modules (class=0x0106) geninitrd: find_tool: found /sbin/lspci geninitrd: Using /dev/vg_storage/lv_root as device for rootfs geninitrd: Finding modules for device path /dev/vg_storage/lv_root geninitrd: LVM: /dev/vg_storage/lv_root is LVM node geninitrd: LVM VG for /dev/vg_storage/lv_root: vg_storage geninitrd: LVM PV for vg_storage: /dev/md1 geninitrd: Finding modules for device path /dev/md1 geninitrd: Finding RAID details using mdadm for rootdev=/dev/md1 geninitrd: md: found rootdev=/dev/md1 on device /dev/md1 with devices list /dev/sda2 /dev/sdb2 geninitrd: Finding modules for device path /dev/sda2 geninitrd: Finding SCSI modules using scsi_hostadapter geninitrd: Finding modules for device path /dev/sdb2 geninitrd: Finding SCSI modules using scsi_hostadapter geninitrd: LVM v2 enabled geninitrd: Building initrd... geninitrd: + cp /usr/lib64/initrd/busybox /root/tmp/initrd.8bxQl2/bin/busybox geninitrd: Loading module [video] geninitrd: Loading module [i2c-core] geninitrd: Loading module [intel-gtt] geninitrd: Loading module [button] geninitrd: Loading module [i2c-algo-bit] geninitrd: Loading module [intel-agp] geninitrd: Loading module [drm] geninitrd: Loading module [drm_kms_helper] geninitrd: Loading module [i915] geninitrd: Loading module [scsi_mod] with options [scan=sync ] geninitrd: Loading module [libata] geninitrd: Loading module [libahci] geninitrd: Loading module [ahci] geninitrd: Loading module [md-mod] geninitrd: Loading module [raid10] geninitrd: Loading module [crc-t10dif] geninitrd: Loading module [sd_mod] geninitrd: Loading module [scsi_wait_scan] geninitrd: Loading module [dm-mod] geninitrd: Loading module [crc16] geninitrd: Loading module [jbd2] geninitrd: Loading module [mbcache] geninitrd: Loading module [ext4] geninitrd: Adding BLKID support to initrd geninitrd: + cp /usr/lib64/initrd/blkid /root/tmp/initrd.8bxQl2/bin/blkid geninitrd: Setting up mdadm... geninitrd: + cp /usr/lib64/initrd/mdassemble /root/tmp/initrd.8bxQl2/bin/mdassemble geninitrd: Setting up array (/dev/md1 = /dev/sda2 /dev/sdb2) geninitrd: + cp /dev/sda2 /root/tmp/initrd.8bxQl2/dev/sda2 geninitrd: + cp /dev/sdb2 /root/tmp/initrd.8bxQl2/dev/sdb2 geninitrd: + cp /dev/md1 /root/tmp/initrd.8bxQl2/dev/md1 geninitrd: + cp /dev/sda /root/tmp/initrd.8bxQl2/dev/sda geninitrd: + cp /dev/sda1 /root/tmp/initrd.8bxQl2/dev/sda1 geninitrd: + cp /dev/sdb /root/tmp/initrd.8bxQl2/dev/sdb geninitrd: + cp /dev/sdb1 /root/tmp/initrd.8bxQl2/dev/sdb1 geninitrd: Adding LVM support to initrd geninitrd: + cp /usr/lib64/initrd/lvm /root/tmp/initrd.8bxQl2/bin/lvm.static geninitrd: Adding rootfs finding based on kernel cmdline root= option support. geninitrd: + mkdir -p /root/tmp/initrd.8bxQl2/dev/vg_storage geninitrd: + cp /dev/vg_storage/lv_root /root/tmp/initrd.8bxQl2/dev/vg_storage/lv_root geninitrd: image size: 7168 KiB (/root/tmp/initrd.8bxQl2) geninitrd: Creating initramfs image /root/tmp/initrd.img-P4tu2t geninitrd: finding compressor: lzo gzip xz lzma bzip2 (via yes) geninitrd: using gzip for compressor (fallback) geninitrd: Compressing /boot/initrd-3.5.0.gz with gzip ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: mdadm boot @ kernel-3.5.0.
On Thursday 26 of July 2012 21:36:32 Artur Frysiak wrote: On Thu, Jul 26, 2012 at 9:06 PM, Paweł Sikora pl...@agmk.net wrote: On Thursday 26 of July 2012 20:57:28 Artur Frysiak wrote: 2012/7/26 Paweł Sikora pl...@agmk.net: witam, proba zabootowania pld na czystym jajku 3.5.0 zakonczyla sie padaczka: http://pluto.agmk.net/kernel/DSC_0188.jpg na pierwszy rzut oka wyglada to tak jakby mdassemble sie nie podnioslo i dalej to juz wszystko leglo. udev w initrd/initramfs jest? Czym generowaleś initrd? udev jest, initrd generowane klasycznie przez geninitrd. [root@localhost ~]# geninitrd -f -v /boot/initrd-3.5.0.gz 3.5.0 W logach nie widać udev. Wygeneruj tak: geninitrd -f -v --with-udev /boot/initrd-3.5.0.gz 3.5.0 okazalo sie, ze mialem use_udev=yes w sysconfig/geninitrd, ale brakowalo w systemie pakietu udev-initrd i generacja initrd przechodzila bez bledu. doinstalowalem paczke, regen i 3.5 wstalo. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
xorg-driver-video-intel / sna crash.
witam, przy wylogowaniu uzytkownika kde4 via kdm, xserver zalicza zgon na skutek drivera intela z ta nowoscia pt. sna. Program received signal SIGSEGV, Segmentation fault. ShmDestroyPixmap (pPixmap=0x1b3b580) at shm.c:272 272 pScreen-DestroyPixmap = screen_priv-destroyPixmap; (gdb) bt #0 ShmDestroyPixmap (pPixmap=0x1b3b580) at shm.c:272 #1 0x7ff52a9a3c86 in sna_glyphs_create (sna=sna@entry=0x7ff52e0d5010) at sna_glyphs.c:227 #2 0x7ff52a97e479 in sna_accel_create (sna=sna@entry=0x7ff52e0d5010) at sna_accel.c:12963 #3 0x7ff52a9a1add in sna_create_screen_resources (screen=0x1cf28a0) at sna_driver.c:197 #4 0x0049e6c7 in xf86CrtcCreateScreenResources (screen=0x1cf28a0) at xf86Crtc.c:704 #5 0x0042320c in main (argc=7, argv=0x7fff6a1507d8, envp=optimized out) at main.c:215 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/strigi] - release 3
po co ten i cale stado innych podbitych releasow? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/strigi] - release 3
On Tuesday 10 of July 2012 14:26:03 you wrote: po co ten i cale stado innych podbitych releasow? Do przebudowy pakietów z nowymi bibliotekami. Tak. W TLD. Rozumiem, że Was to boli i najchętniej zabronilibyście komukolwiek spoza PLD korzystania z zasobów PLD. Pierw auto-tagi przeszkadzają, teraz podbijanie releasów, tagi sa z boku ale nie powoduja widocznej zmiany w specach, ktora NIC nie wnosi. podbijanie releasow w glownej linii tylko po to, zeby cos prywatnie przebudowac (czy to jest tld, czy inny wewnatrzfirmowy fork), to juz robienie zbednego smietnika czemu jest przeciwny. jutro pewnie wszystkie moje commity będą przeszkadzać (albo już przeszkadzają), wszystkie smietnikowe beda przeszkadzac, a wszystkie rozsadne beda mile widziane. a pojutrze będzie wniosek o -rw? najpierw moze posprzataj git-revertem to co narobiles? bez rw bedzie ci ciezko :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 15:41:16 Kacper Kornet wrote:
On Mon, Jul 09, 2012 at 03:24:22PM +0200, Marcin Krol wrote:
I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy
spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam
git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych
notatek nie ma.
U mnie też changelogi są złe. Przykład:
$ rpm -qp --changelog smartmontools-5.42-8.x86_64.rpm
* Tue Apr 17 2012 Jan R?korajski bagg...@pld-linux.org c5f0a95
* Tue Mar 13 2012 Elan Ruusam?e g...@pld-linux.org eed5f88
* Tue Mar 13 2012 Elan Ruusam?e g...@pld-linux.org 7b9f1c2
* Mon Feb 27 2012 Artur Frysiak ar...@frysiak.net 492fa92
* Wed Feb 22 2012 Arkadiusz Mi?kiewicz ar...@maven.pl 34c4735
* Tue Feb 14 2012 Jan R?korajski bagg...@pld-linux.org 7e7806e
* Fri Dec 02 2011 Bart?omiej Zimo? cac...@pld-linux.org 8fc3262
* Tue Oct 25 2011 Jakub Bogusz qbo...@pld-linux.org 2161cb3
Brak polskich literek nie wynika z copy/paste czy kodowania maila.
Tak jest faktycznie w changelogu i jest to faktycznie pytajnik
(0x3F), a nie konwersja kodowania czy coś.
Czy ktoś z osób co widzę ten błąd może dostawić set -x na początku funkcji
nsert_gitlog() w builder (powinna być linijka 441) i podesłać mi?
[pawels@odra /home/users/pawels/packages/ftdi_eeprom]$ builder *.spec
builder: SMP make flags are set to -j8
Already up-to-date.
Available branches: master
ftdi_eeprom-0.3.tar.gz having proper md5sum already exists
+ tempdir
+ tempfile
+ tempfile
+ typeset SPECFILE=ftdi_eeprom.spec specdir=builder.7p7cqg
gitlog=/ahome/pawels/tmp/builder.AaSc2t speclog=/ahome/pawels/tmp/builder.TNCKQf
+ rpm -E %{?_buildchangelogtruncate}
+ typeset log_entries=20
+ git rev-list -20 HEAD
+ /ahome/pawels/tmp/builder.AaSc2t
+ read sha1
+ typeset logfmt=%B%n
+ /dev/null
+ logfmt=%N
+ git notes list 91306a1ca4c6e7f24369684449628be02eef0ef6
+ git log -n 1 91306a1ca4c6e7f24369684449628be02eef0ef6 --format=format:* %ad
%an %ae %h%n%N%n --date=raw
+ sed /^$/q
error: No note found for object 91306a1ca4c6e7f24369684449628be02eef0ef6.
+ read sha1
+ typeset logfmt=%B%n
+ /dev/null
+ logfmt=%N
+ git notes list 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b
+ git log -n 1 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b --format=format:* %ad
%an %ae %h%n%N%n --date=raw
+ sed /^$/q
error: No note found for object 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b.
+ read sha1
+ typeset logfmt=%B%n
+ /dev/null
+ logfmt=%N
+ sed /^$/q
+ git log -n 1 f4a56f57a28c4e5911bc0a4be2a75f94d00b0667 --format=format:* %ad
%an %ae %h%n%N%n --date=raw
+ git notes list f4a56f57a28c4e5911bc0a4be2a75f94d00b0667
error: No note found for object f4a56f57a28c4e5911bc0a4be2a75f94d00b0667.
+ read sha1
+ gawk /^\* /{printf(* %s %s\n, strftime(%a %b %d %Y, $2), substr($0,
length($1)+length($2)+length($3)+4)); next}{print}
/ahome/pawels/tmp/builder.AaSc2t
+ /ahome/pawels/tmp/builder.TNCKQf
+ LC_ALL=C
+ sed /^%changelog/,$d ftdi_eeprom.spec
+ sed -e ${
a%changelog
r /ahome/pawels/tmp/builder.TNCKQf
}
+ builder.7p7cqg/ftdi_eeprom.spec
+ rm -f /ahome/pawels/tmp/builder.AaSc2t /ahome/pawels/tmp/builder.TNCKQf
+ echo builder.7p7cqg
Building target platforms: x86_64-linux
error: no description in %changelog
Error: package build failed. (no more info)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 15:54:08 Kacper Kornet wrote: On Mon, Jul 09, 2012 at 03:51:22PM +0200, Marcin Krol wrote: Mam. Czy Wy wszyscy nie macie przypadkie pdksh jako shell? Nope. Ja używam basha. Źle sformułowane pytanie. Chodziło mi o to czym jest /bin/sh /bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. zas sam uzytkownik ma shell ustawiony na zsh. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 04:19:47 Kacper Kornet wrote: On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: Due to git migration, write access to packages in CVS will be disabled in around 45 minutes. So the official repositories of PLD packages are now in git: git://git.pld-linux.org/packages/* ssh://g...@pld-linux.org/packages/* The builders, distfiles, commit list and ciabot seem to work. Please let me know if you encounter any problems. try to click the '(rpm-build-tools.spec -r master)' hyperlink on http://src.th.pld-linux.org/queue.html results: An Exception Has Occurred Python Traceback Traceback (most recent call last): File /usr/share/viewvc/lib/viewvc.py, line 4452, in main File /usr/share/viewvc/lib/viewvc.py, line 394, in run_viewvc File /usr/share/viewvc/lib/viewvc.py, line 2394, in view_log File /usr/share/viewvc/lib/vclib/ccvs/bincvs.py, line 302, in itemlog File /usr/share/viewvc/lib/vclib/ccvs/bincvs.py, line 918, in _file_log Error: Invalid tag or revision number master ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Friday 06 of July 2012 10:50:30 Tomasz Pala wrote: On Fri, Jul 06, 2012 at 10:37:01 +0200, Kacper Kornet wrote: Ona nie jest generowana online. To co gitweb robi, to sprawdza czy każdy katalog na jego liście jest repozytorium git. Ale to nie powinno zająć bardzo długo. Jak masz pecha to po stronie serwera zajmuje to jakieś 2 min - na dole strony powninna być wyświetlona ilość czasu jaką mu to zajęło. Jak wszystko na serwerach siedzi w buforach to zajmuje kika sekund. To co naprawdę determinujeu mnie czas wyświetlania się, to lokalny rendering przez przeglądarkę. I to nie mam pomysłu jak poprawić. Nie do końca prawda - ja oglądam lynxem i czekam ponad 30 sekund, z czego połowę lecą dane z prędkością ok. 125 KB/s, a dopiero później przyspiesza do 2000 KB/s (a jeszcze pierwsze 3 sekundy czeka na odpowiedź serwera). Jak to przyspieszyć napisałem poprzednio - zrobić skrócony listing. Choć w tej pierwszej połowie to lynx nie wyrabia (i brzydko pokazuje dane), to jednak całość ma 9 MB, z wgeta: 9,352,126 1.58M/s in 5.9s Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera (na swoim łączu wyciągam lekko ponad 10 MB/s). moze wystarczy wlaczyc kompresje http? mod_gzip zrobi z tego jakies 850kB. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[th-update] iceape-1.x lezy.
testowa aktualizacja th (main+ready) na jednej maszynie zakonczyla sie zle dla pakietu iceape-1.1.18-9 - binarka sie nie uruchamia, a przyczyna sa niespelnione zaleznosci w runtime: $ LANG=C LD_DEBUG=bindings iceape log $ grep 'error:' log 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [th-update] iceape-1.x lezy.
On Wednesday 04 of July 2012 13:19:59 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: testowa aktualizacja th (main+ready) na jednej maszynie zakonczyla sie zle dla pakietu iceape-1.1.18-9 - binarka sie nie uruchamia, a przyczyna sa niespelnione zaleznosci w runtime: $ LANG=C LD_DEBUG=bindings iceape log $ grep 'error:' log 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) Weź to wywal, toż to zabytek ;) W th-test leży aktualny, działający iceape 2.10.1. akurat 2.x nie zmigrowal profilu, a 1GB danych uzytkownikowi lezy na sercu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [th-update] iceape-1.x lezy.
On Wednesday 04 of July 2012 13:28:21 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: On Wednesday 04 of July 2012 13:19:59 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: testowa aktualizacja th (main+ready) na jednej maszynie zakonczyla sie zle dla pakietu iceape-1.1.18-9 - binarka sie nie uruchamia, a przyczyna sa niespelnione zaleznosci w runtime: $ LANG=C LD_DEBUG=bindings iceape log $ grep 'error:' log 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) Weź to wywal, toż to zabytek ;) W th-test leży aktualny, działający iceape 2.10.1. akurat 2.x nie zmigrowal profilu, a 1GB danych uzytkownikowi lezy na sercu. Może go nie znalazł? Mi wciągnął jakiś zabytkowy profil z thunderbirda, gdzie ten profil u tego użytkownika leży? ~/.mozilla/default/87mlf835.slt odpalenie iceape-2.x z opcja wizardowania nic nie robi. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [th-update] iceape-1.x lezy.
On Wednesday 04 of July 2012 13:46:31 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: On Wednesday 04 of July 2012 13:28:21 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: On Wednesday 04 of July 2012 13:19:59 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: testowa aktualizacja th (main+ready) na jednej maszynie zakonczyla sie zle dla pakietu iceape-1.1.18-9 - binarka sie nie uruchamia, a przyczyna sa niespelnione zaleznosci w runtime: $ LANG=C LD_DEBUG=bindings iceape log $ grep 'error:' log 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) Weź to wywal, toż to zabytek ;) W th-test leży aktualny, działający iceape 2.10.1. akurat 2.x nie zmigrowal profilu, a 1GB danych uzytkownikowi lezy na sercu. Może go nie znalazł? Mi wciągnął jakiś zabytkowy profil z thunderbirda, gdzie ten profil u tego użytkownika leży? ~/.mozilla/default/87mlf835.slt odpalenie iceape-2.x z opcja wizardowania nic nie robi. Spróbuj: ln -s ~/.mozilla ~/.thunderbird albo mkdir ~/.thunderbird ln -s ~/.mozilla/default/87mlf835.slt ~/.thunderbird/87mlf835.default albo mkdir ~/.mozilla/seamonkey ln -s ~/.mozilla/default/87mlf835.slt ~/.mozilla/seamonkey/87mlf835.default zrobilem kopie profilu w tym stylu i ruszylo, ale trzeba przyznac, ze to kupa jakas :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [th-update] iceape-1.x lezy.
On Wednesday 04 of July 2012 13:19:59 Jan Rękorajski wrote: On Wed, 04 Jul 2012, Paweł Sikora wrote: testowa aktualizacja th (main+ready) na jednej maszynie zakonczyla sie zle dla pakietu iceape-1.1.18-9 - binarka sie nie uruchamia, a przyczyna sa niespelnione zaleznosci w runtime: $ LANG=C LD_DEBUG=bindings iceape log $ grep 'error:' log 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: nspr_use_zone_allocator (fatal) 18411: /usr/lib64/iceape/iceape-bin: error: symbol lookup error: undefined symbol: gtk_widget_device_is_shadowed (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) 18411: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so: error: symbol lookup error: undefined symbol: g_module_unload (fatal) Weź to wywal, toż to zabytek ;) W th-test leży aktualny, działający iceape 2.10.1. tak, juz na koniec, to trzeba usunac ten zabytek 1.x z ftp, bo mimo, iz sie instaluje, to jest nieuzywalny. nawet walka z pakietami z .archive nie pomogla : ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma swój numerek lub nazwę upstream. Może tak, może nie. Zobacz jak to teraz działa w CVS. Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od razu po gitowemu. Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. Jak coś zostało zmergowane do master, to branch jest usuwany. A Twoim podejściu jego nazwa zostaje na zawsze w repo Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak się jego nazwę usunie... Dla jasności. Niech mamy historię jak tutaj: A---B---C \ X---Y---Z gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i DEVEL do master i mamy historię: A---B---C--D \/ X--Y--Z W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z na zawsze? dlaczego po merge devel-master, nie mozna niby zrobic merge master-devel? w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi bajerami. * 03dbac5 (HEAD, master) f | * 09354a5 (devel) e |/ * 6b690f7 d |\ | * 2ddc926 z | * 0754883 y | * 74a4198 x * | f31db31 c * | c22b088 b |/ * 59ee956 a no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego nurtu pld-th? 1). dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak pokazalem wyzej) i nie nadpisujemy/kasujemy devel. 2). dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do jakiegos next-X.Y (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi (kasacja?). chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban, bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok dzialania. nastepna kwestia, to galezie dla rozwijania jakis dziwnych ficzerow - przyjmujemy jakies ramy dzialania ws. nazewnictwa/kasowania/nadpisywania, czy dajemy wolna reke? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: ssh keys
On Friday 22 of June 2012 21:47:08 Kacper Kornet wrote: (Polska wersja w drugiej częście wiadomości:) In git repositories authentication will be based on ssh keys. Therefore I would like to ask developers with RW access to CVS to upload their public ssh keys to SSH-keys directory in CVS. how long do you plan to keep this ssh-keys-upload window open? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Friday 29 of June 2012 21:14:50 Kacper Kornet wrote: On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma swój numerek lub nazwę upstream. Może tak, może nie. Zobacz jak to teraz działa w CVS. Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od razu po gitowemu. Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. Jak coś zostało zmergowane do master, to branch jest usuwany. A Twoim podejściu jego nazwa zostaje na zawsze w repo Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak się jego nazwę usunie... Dla jasności. Niech mamy historię jak tutaj: A---B---C \ X---Y---Z gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i DEVEL do master i mamy historię: A---B---C--D \/ X--Y--Z W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z na zawsze? dlaczego po merge devel-master, nie mozna niby zrobic merge master-devel? w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi bajerami. * 03dbac5 (HEAD, master) f | * 09354a5 (devel) e |/ * 6b690f7 d |\ | * 2ddc926 z | * 0754883 y | * 74a4198 x * | f31db31 c * | c22b088 b |/ * 59ee956 a no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego nurtu pld-th? 1). dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak pokazalem wyzej) i nie nadpisujemy/kasujemy devel. Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować DEVEL. A dokładnie trzeba wykonać coś takiego: git checkout master git merge DEVEL git checkout DEVEL git reset --hard master (dalsze komity na master i DEVEL). Jak zrobisz krzyżowy merge: git checkout master git merge DEVEL git checkout DEVEL git merger master to dostaniesz historię: A--B--C--D-I--K--(master) \/ \ E--F--GJ--L--(DEVEL) To ja wolę historię z pierwszego wariantu. zeby osiagnac to co wrzucilem (git log --graph), nie uzylem zadnego reset/hard. prosty krzyzowy merge master/devel wystarczyl. nie wiem skad ta krawedz grafu miedzy G-J w twoim szkicu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: subdirs under packages/
On Monday 25 of June 2012 18:52:32 Jan Rękorajski wrote: Small suggestion - add ability to slug.py to work with package(s) in a one level hash directories based on the first letter of package name, like this: packages/[0-9A-Za-z]/package dir Rationale: having entire packages checked out is RPITA, entering/listing packages/ directory is painfully slow - much slower than with CVS. One level hash will greatly speedup things. this is a bad workaround. the core problem is in glibc's readdir() which calls getdents syscall multiple times with small 32k buffer. e.g, for rpm/packages, `ls -1` produces: (...) getdents(3, /* 913 entries */, 32768) = 32760 getdents(3, /* 911 entries */, 32768) = 32744 getdents(3, /* 914 entries */, 32768) = 32736 getdents(3, /* 906 entries */, 32768) = 32760 getdents(3, /* 919 entries */, 32768) = 32752 getdents(3, /* 919 entries */, 32768) = 32768 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 919 entries */, 32768) = 32744 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 907 entries */, 32768) = 32728 getdents(3, /* 915 entries */, 32768) = 32736 getdents(3, /* 918 entries */, 32768) = 32752 getdents(3, /* 918 entries */, 32768) = 32744 getdents(3, /* 921 entries */, 32768) = 32752 getdents(3, /* 907 entries */, 32768) = 32752 getdents(3, /* 465 entries */, 32768) = 16784 getdents(3, /* 0 entries */, 32768) = 0 (...) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: subdirs under packages/
On Monday 25 of June 2012 19:43:42 Paweł Sikora wrote: On Monday 25 of June 2012 18:52:32 Jan Rękorajski wrote: Small suggestion - add ability to slug.py to work with package(s) in a one level hash directories based on the first letter of package name, like this: packages/[0-9A-Za-z]/package dir Rationale: having entire packages checked out is RPITA, entering/listing packages/ directory is painfully slow - much slower than with CVS. One level hash will greatly speedup things. this is a bad workaround. the core problem is in glibc's readdir() which calls getdents syscall multiple times with small 32k buffer. e.g, for rpm/packages, `ls -1` produces: (...) getdents(3, /* 913 entries */, 32768) = 32760 getdents(3, /* 911 entries */, 32768) = 32744 getdents(3, /* 914 entries */, 32768) = 32736 getdents(3, /* 906 entries */, 32768) = 32760 getdents(3, /* 919 entries */, 32768) = 32752 getdents(3, /* 919 entries */, 32768) = 32768 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 919 entries */, 32768) = 32744 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 907 entries */, 32768) = 32728 getdents(3, /* 915 entries */, 32768) = 32736 getdents(3, /* 918 entries */, 32768) = 32752 getdents(3, /* 918 entries */, 32768) = 32744 getdents(3, /* 921 entries */, 32768) = 32752 getdents(3, /* 907 entries */, 32768) = 32752 getdents(3, /* 465 entries */, 32768) = 16784 getdents(3, /* 0 entries */, 32768) = 0 (...) ...and the major performance issue is the `mc` listing algorithm for custom view with the 'size' column. it finally calls the lstat() for each entry (~15k times). ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma swój numerek lub nazwę upstream. Może tak, może nie. Zobacz jak to teraz działa w CVS. Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od razu po gitowemu. Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. Jak coś zostało zmergowane do master, to branch jest usuwany. A Twoim podejściu jego nazwa zostaje na zawsze w repo Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak się jego nazwę usunie... Dla jasności. Niech mamy historię jak tutaj: A---B---C \ X---Y---Z gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i DEVEL do master i mamy historię: A---B---C--D \/ X--Y--Z W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z na zawsze? dlaczego po merge devel-master, nie mozna niby zrobic merge master-devel? w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi bajerami. * 03dbac5 (HEAD, master) f | * 09354a5 (devel) e |/ * 6b690f7 d |\ | * 2ddc926 z | * 0754883 y | * 74a4198 x * | f31db31 c * | c22b088 b |/ * 59ee956 a ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Saturday 23 of June 2012 10:23:32 Jacek Konieczny wrote: On Fri, Jun 22, 2012 at 11:32:37PM +0200, Paweł Sikora wrote: w sprawie migracji do gita, mam jeszcze jedno pytanie - w jaki sposob planujemy eliminowac totalnie psujace commity uzytkownikow? czy bedziemy uzywac 'git revert'. czy moze od strony administracyjnej bedziemy jechac z 'git reset --hard' ? Nie, tylko nie git reset… wtedy stracimy główny zysk z użycia gita, bo wszystkie forkowane repozytoria się rozjadą. Trudno, najwyżej będą śmieci w historii – to i psuj zostanie napiętnowany. Jak dorośnie będzie się wstydził ;) Jak ktoś będzie regularnie psuł, to straci prawo commitów i już. ok, zatem proponuje by zrezygnowac z mozliwosci poprawiania historii (takze push --force na galeziach) i ustawic dla kazdego repo dwie opcje: receive.denyNonFastforwards=true receive.denyDeletes=true ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: changelog format.
czesc, nasunelo mi sie jeszcze jedno przemyslenie co do formatowania changeloga w nowym repo. proponuje, aby changelog zawieral w pierszym wierszu krotki opis zmian, pozniej wiersz odstepu i ewentualny obszerny opis jesli takowy jest potrzebny. wszystko po to, aby przegladanie historii we wszelakich gui, czy konosli (git log --oneline) bylo czytelniejsze. jesli na to przystaniemy, to potrzeba bedzie poprawic nieco skrypt relup.sh i adapter, zeby tego pilnowal. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Wybory nowego RM-a
On Wednesday 20 of June 2012 14:48:53 Tomasz Pala wrote: On Mon, Jun 18, 2012 at 20:54:47 +0200, Jacek Konieczny wrote: 5). jesli ktos chce, aby cos trafilo do th-ready, to niech podsyla osobie mogacej przenosic pakiety gotowa liste. I fajnie, żeby było można łatwo znaleźć ???osobę mogącą przenosić pakiety?? i żeby zasady tego były jasne. Bo na razie to dla mnie była magia ??? wrzuciłem coś na buildery, to się pojawiało w test??? potem może w ready, a czasem nawet kiedyś w main i nie bardzo wiedziałem od czego to zależy??? ;) Ja często szukałem jeszcze w .test-builds;) zapomniales o .archive :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Wybory nowego RM-a
On Monday 18 of June 2012 11:06:39 Mariusz Mazur wrote: On Fri of June 15 2012, Mariusz Mazur wrote: Osoby zainteresowane prosimy o zgłaszanie się, może być w tym wątku. Ej, no ale nie bądźcie nieśmiali. Przecież nawalanka w arkam, żeby sobie dał siana, a potem formalizacja wyboru RM-a przez CDG, to nie były tylko losowe ruchy bez sensu, ale elementy jakiejś przemyślanej, spójnej wizji zmian w distro. Także parę dni już odczekanych, pozory skromności zachowane, teraz czas się ujawnić. no, to na poczatek zrobmy kilka rzeczy: 1). potrzebuje uprawnien @ep09 do przenoszenia pakietow @ftp, bo za chwile jakis automat wykasuje z th-test rzeczy, ktore za dlugo tam lezakuja. 2). ustalmy oficjalnie regule, ze jak ktos cos puszcza do th-test, to powstale .rpm-y nie trafia do th-ready jesli ktos nie wyprostuje niespelnionych zaleznosci widocznych na http://ep09.pld-linux.org/~pldth/ 3). trzeba wyczyscic liste problemow http://ep09.pld-linux.org/~pldth/ i zrobic jakis snapshot ftpa. 4). trzeba zmienic automatyke przenoszenia paczek / strukture ftp, tak aby katalogi test/ready/main zawieraly tylko symlinki do wlasciwych paczek lezacych w jednym miejscu. dzieki temu rsync ftp po przenosinach paczek nie bedzie bolesnym kolkiem w pupie dla klientow na waskich laczach (zwlaszcza mam tu na mysli pakiety debuginfo). 5). jesli ktos chce, aby cos trafilo do th-ready, to niech podsyla osobie mogacej przenosic pakiety gotowa liste. 6). trzeba okreslic reguly przenoszenia paczek z th-ready do th-main. jakis anons na listach + czas na testy wdrozeniowe? 7). trzeba w koncu (jesli gotowa) odpalic migracje cvs-git, bo piescimy sie z tym juz ruski rok. 8). ktos obeznany z systemd powinien napisac krotki podrecznik konfigurowania zaleznosci i odpalania uslug, tak by instalacja pld na fikusnych mutacjach lvm/raid/luks byla prosta, latwa i pzyjemna. i nie mam tu na mysli 'skompiluj sobie taki szpej do udev', co emuluje cos tam na potrzeby systemd ;) 9). spotkac sie przy piwie i ustalic nastepne punkty planu :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Brak możliwości otwarcia zaszyfrowanego dysku po aktualizacji
On Saturday 26 of May 2012 14:47:33 kamil.li...@klecza.pl wrote: Z rescue działa. Nie mam pomysłu co tu jest nie tak. Próbowałem innego kernela z main (longterm) próbowałem zdowngradeować device-mapper (2.02.94-2) i to samo. Nie mam pomysłu gdzie szukać/która paczka mogła namieszać. Ktoś ma jakieś pomysły? Lista zaktualizowanych paczek: http://pastebin.com/uvL9DcGi [root@localhost ~]# dmsetup targets striped v1.4.0 linear v1.1.0 errorv1.0.1 [root@localhost ~]# modprobe dm-crypt [root@localhost ~]# dmsetup targets cryptv1.11.0 striped v1.4.0 linear v1.1.0 errorv1.0.1 moze po prostu brakuje ci zaladowanego modulu dm-crypt gdzies na etapie initrd? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [zgłoszenie/ostrzeżenie] Kernel 3.3.4 wywraca się
On Saturday 28 of April 2012 12:54:42 Łukasz Maśko wrote: Zainstalowałem dzisiaj powyższe, system wytrzymał kilkanaście minut po czym nastąpił segfault i twardy zwis. Po restarcie - to samo. W obu przypadkach wywrotka była przy próbie swapowania, chociaż aktywny proces był różny (nie proces zawinił lecz kernel, więc to dla mnie jasne). Wróciłem do 3.3.3, który jest stabilny, przynajmniej jak dla mnie. Tak więc jakby ktoś chciał sobie zainstalować, to ostrożnie. masz screenshot z oopsem? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
th-x32 - czy chcemy sie w to bawic?
witam, chcialem sie zabytac czy beda chetni do rozwijania kompilacji pld-th pod x32? x32, to software-owa mutacja architektury x86-64, w ktorej wskazniki/przestrzen adresowa aplikacji jest 32-bitowa, natomiast same instrukcje procesora sa 64-bitowe. efekt jest taki, ze otrzymujemy kod, ktorego apetyt na pamiec(struktury danych) jest taki jak w starych dobrych i686, ale dostajemy pelen wachlarz instrukcji nowszych cpu. gcc akceptuje w takim przypadku opcje -m64/-m32/-mx32. zeby to dzialalo wymagane jest swieze srodowisko (kernel-3.4rc1, gcc-4.7+, binutils nowe juz chyba bedzie mialo scalone zmiany, glibc-next). tak wiec jest to poki co temat na za kilka miesiecy. temat fajny zarowno dla uzytkownikow laptopow o ograniczonej pamieci jak i dla serwerowocow, ktorzy odpalaja duzo procesow, ktore nie potrzebuja wiecej niz 4GB pamieci. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: th-x32 - czy chcemy sie w to bawic?
On Friday 06 of April 2012 13:38:10 Jacek Konieczny wrote:
On Fri, Apr 06, 2012 at 11:53:59AM +0200, Paweł Sikora wrote:
chcialem sie zabytac czy beda chetni do rozwijania kompilacji pld-th pod
x32?
x32, to software-owa mutacja architektury x86-64, w ktorej
wskazniki/przestrzen
adresowa aplikacji jest 32-bitowa, natomiast same instrukcje procesora sa
64-bitowe.
efekt jest taki, ze otrzymujemy kod, ktorego apetyt na pamiec(struktury
danych)
jest taki jak w starych dobrych i686, ale dostajemy pelen wachlarz
instrukcji
nowszych cpu. gcc akceptuje w takim przypadku opcje -m64/-m32/-mx32.
Nie widzę sensu. Do czasu zanim ten port będzie w pełni gotowy, to ilość
pamięci w przeciętnej maszynie się podwoi. Tak, to wciąż będzie jakaś
oszczędność, ale jeszcze mniejsza niż teraz i IMHO nie warta zachodu.
implementacja jest *gotowa* na gitowych galeziach i teraz jest na etapie
scalania z upstream-em glibc/binutils/gdb (gcc/kernel sa juz scalone).
w zasadzie to sam support od strony th-x86_64 jest prosty, bo do istniejacego
multiliba {/lib,/lib64} dojdzie jeszcze /libx32 zeby ewentualnie mozna bylo
testowo kompilowac sobie kod, a jak kiedys bedzie wola i moce, to mozna z tego
wyprowadzic osobny builder x32.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: regresja w lvm2-2.02.94?
On Friday 06 of April 2012 17:13:17 Jan Rękorajski wrote: On Thu, 05 Apr 2012, Jan Rękorajski wrote: On Thu, 05 Apr 2012, Paweł Sikora wrote: na wersji 2.02.84 tworzenie snapshota dziala: root@src ~]# lvcreate -s -n lv_backup -l 100%FREE /dev/vg_home/lv_services /dev/mapper/vg_home-lv_backup not set up by udev: Falling back to direct node creation. The link /dev/vg_home/lv_backup should had been created by udev but it was not found. Falling back to direct link creation. Unable to find dmeventd. Unable to find dmeventd. vg_home-lv_backup: event registration failed: No such process vg_home/snapshot0: snapshot segment monitoring function failed. Logical volume lv_backup created /dev/mapper/vg_home-lv_services-real not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_services-real: mknod for vg_home-lv_services-real failed: File exists /dev/mapper/vg_home-lv_services-real: open failed: No such file or directory /dev/mapper/vg_home-lv_backup-cow not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_backup-cow: mknod for vg_home-lv_backup-cow failed: File exists /dev/mapper/vg_home-lv_backup-cow: open failed: No such file or directory /dev/mapper/vg_home-lv_services-real not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_services-real: mknod for vg_home-lv_services-real failed: File exists /dev/mapper/vg_home-lv_services-real: open failed: No such file or directory aktualizacja do 2.02.94 (bez restartu maszyny / regenreacji initrd): [root@src ~]# lvcreate -s -n lv_backup -l 100%FREE /dev/vg_home/lv_services /dev/vg_home/lv_backup: not found: device not cleared Aborting. Failed to wipe snapshot exception store. Regresja polega na tym że lvm przestał udawać że wszystko działa jak mu udev nie tworzy symlinków w /dev. Jak puścisz to z -v to zobaczysz o co mu chodzi. Niestety jeszcze mi się nie udało znaleźć skąd to się bierze, może ktoś ma pomysł? Ok, pytanie pomocnicze - czy używasz tam systemd? nie. Zainstaluj tam kernel 3.3.1-2 lub 3.0.27-2 (oba się właśnie budują) i daj znać czy pomogło. w chwili testu mialem tam 3.3.0, zrobilem upgrejd do 3.3.1-1 + lvm 2.02.9*5* i snapshot znow zaczal dzialac. [root@src ~]# lvcreate -s -n lv_backup -l 100%FREE /dev/vg_home/lv_services -v Setting logging type to disk Setting chunksize to 8 sectors. Finding volume group vg_home Archiving volume group vg_home metadata (seqno 422). Creating logical volume lv_backup Creating volume group backup /etc/lvm/backup/vg_home (seqno 423). Found volume group vg_home activation/volume_list configuration setting not defined: Checking only host tags for vg_home/lv_backup Creating vg_home-lv_backup Loading vg_home-lv_backup table (254:2) Resuming vg_home-lv_backup (254:2) Clearing start of logical volume lv_backup Creating logical volume snapshot0 Found volume group vg_home Found volume group vg_home Creating vg_home-lv_services-real Loading vg_home-lv_services-real table (254:3) Resuming vg_home-lv_services-real (254:3) Loading vg_home-lv_services table (254:1) Creating vg_home-lv_backup-cow Loading vg_home-lv_backup-cow table (254:4) Resuming vg_home-lv_backup-cow (254:4) Loading vg_home-lv_backup table (254:2) Suspending vg_home-lv_services (254:1) with filesystem sync with device flush Suspending vg_home-lv_services-real (254:3) with filesystem sync with device flush Found volume group vg_home Loading vg_home-lv_services-real table (254:3) Suppressed vg_home-lv_services-real identical table reload. Loading vg_home-lv_backup-cow table (254:4) Suppressed vg_home-lv_backup-cow identical table reload. Resuming vg_home-lv_services-real (254:3) Resuming vg_home-lv_backup (254:2) Resuming vg_home-lv_services (254:1) Monitoring vg_home/snapshot0 Creating volume group backup /etc/lvm/backup/vg_home (seqno 424). Logical volume lv_backup created ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
regresja w lvm2-2.02.94?
na wersji 2.02.84 tworzenie snapshota dziala: root@src ~]# lvcreate -s -n lv_backup -l 100%FREE /dev/vg_home/lv_services /dev/mapper/vg_home-lv_backup not set up by udev: Falling back to direct node creation. The link /dev/vg_home/lv_backup should had been created by udev but it was not found. Falling back to direct link creation. Unable to find dmeventd. Unable to find dmeventd. vg_home-lv_backup: event registration failed: No such process vg_home/snapshot0: snapshot segment monitoring function failed. Logical volume lv_backup created /dev/mapper/vg_home-lv_services-real not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_services-real: mknod for vg_home-lv_services-real failed: File exists /dev/mapper/vg_home-lv_services-real: open failed: No such file or directory /dev/mapper/vg_home-lv_backup-cow not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_backup-cow: mknod for vg_home-lv_backup-cow failed: File exists /dev/mapper/vg_home-lv_backup-cow: open failed: No such file or directory /dev/mapper/vg_home-lv_services-real not set up by udev: Falling back to direct node creation. /dev/mapper/vg_home-lv_services-real: mknod for vg_home-lv_services-real failed: File exists /dev/mapper/vg_home-lv_services-real: open failed: No such file or directory aktualizacja do 2.02.94 (bez restartu maszyny / regenreacji initrd): [root@src ~]# lvcreate -s -n lv_backup -l 100%FREE /dev/vg_home/lv_services /dev/vg_home/lv_backup: not found: device not cleared Aborting. Failed to wipe snapshot exception store. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: GCC generuje błędny asm
On Wednesday 28 of March 2012 16:27:45 Bartosz Świątek wrote:
W dniu 28 marca 2012 16:23 użytkownik Paweł Sikora pl...@agmk.net napisał:
On Wednesday 28 of March 2012 15:36:47 Bartosz Świątek wrote:
Cześć,
taki oto najprostszy program:
int $12 = 0;
int main() {
return $12;
}
mam kaprys nazwać sobie zmienną $12, bo niby czemu nie.
$ gcc -Wall t.c -S -pedantic
t.c:1:5: warning: '$' in identifier or number [enabled by default]
Aj no, jakieś -Wall i jeszcze -pedantic, to łaskawie _warning_
napisało, ciągle jednak nie ma errora. Tylko teraz nie mów, że jak
jeszcze -Werror dorzucisz, że to jest rozwiązanie :P
jak ci sie niepodoba, to co dopuszcza standard na wlasne ryzyko
uzytkownika, to bys chociaz trolu przeczytal manual i uzyl sobie
opcjii -fno-dollars-in-identifiers -fno-extended-identifiers.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Walnięty geninitrd-12517-1
On Thursday 29 of March 2012 17:11:02 Bartosz Świątek wrote: W dniu 29 marca 2012 17:08 użytkownik Arkadiusz Miśkiewicz ar...@maven.pl napisał: On Thursday 29 of March 2012, Łukasz Maśko wrote: geninitrd w powyższej wersji wydaje się być walnięty. To jest fixnięte w rel 2 ale widzę na buildery nie poszło. did not found też w rel 2? Czy ten błąd tak zlekceważysz jak ten w gcc? ;) czy nie wytlumaczyli ci juz w bugzilli gcc tego problemu? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: lvm2 i snapshot
On Wednesday 28 of March 2012 06:04:41 Adam Sobieraj wrote:
Witam
Próbując dziś pobawić się shapshot-ami napotkałem na kilak problemów:
1. W pliku lvm.conf parametr executable jest domyślnie ustawiony na
/usr/sbin/dmeventd ale plik dmeventd znajduje się /sbin/dmeventd.
2. dmeventd nie może załadować libdevmapper-event-lvm2snapshot.so,
biblioteka owszem jest ale nie pod ścieżka np /usr/lib64 tylko
/usr/lib64/device-mapper więc ldconfig jej nie dodaje do cache-u...
Pakiety z th-ready:
lvm2-2.02.94-2.x86_64
device-mapper-2.02.94-2.x86_64
Na koniec pytanie czy ktoś już coś robi czy path-a trzeba samemu
napisać?
problem zgloszony dawno temu https://bugs.launchpad.net/pld-linux/+bug/795644
trzeba poprawic lvm by szukal sobie pluginow w %{_libdir}/device-mapper/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: GCC generuje błędny asm
On Wednesday 28 of March 2012 15:36:47 Bartosz Świątek wrote:
Cześć,
taki oto najprostszy program:
int $12 = 0;
int main() {
return $12;
}
mam kaprys nazwać sobie zmienną $12, bo niby czemu nie.
$ gcc -Wall t.c -S -pedantic
t.c:1:5: warning: '$' in identifier or number [enabled by default]
Kto poprawi? Bo inaczej ftp move wywali nam gcc i czym potem se
pajtona skompilujemy?
to niech sie ludzie od pytona naucza pisac w C.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: GCC generuje błędny asm
On Wednesday 28 of March 2012 16:39:24 Bartosz Świątek wrote: http://en.wikipedia.org/wiki/Naming_convention_(programming)#C_and_C.2B.2B, które też nic nie wspomina, że nie wolno mieć $ jako początek nazwy zmiennej. www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf - rozdzial 6.4.2.1 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[RFT] gcc-4.7.0.
witam, w th-test pojawil sie (narazie bez aktualizacji na builderach) nowy kompilator. zapraszam wszystkich do testowania i zglaszania bledow, tak aby w 4.7.1 miec juz ewentualne poprawki, bo 4.7.1 bedzie nastepnym kompilatorem w th. przy aktualizacji libstdc++ trzeba sobie dla juz istniejacych aplikacji zainstalowac pakiecik compat-libstdc++-4.6-4.6.3-1. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: poldek i wiele sciaganych plikow na raz
a jakies bugi w poldku bedziecie jeszcze poprawiac, czy juz tylko nowe ficzery? bo jam mam taki niuans na maszynach x86-64, ktory mnie dreczy: poldek:/all-avail lli glibc* package build date size glibc-2.15-7.i686 2012/03/16 00:47 7.3 MB glibc-2.15-7.x86_64 2012/03/16 00:50 8.3 MB glibc-devel-2.15-7.i686 2012/03/16 00:47 90.0 KB glibc-devel-2.15-7.x86_64 2012/03/16 00:50 104.0 KB glibc-devel-utils-2.15-7.x86_64 2012/03/16 00:50 66.0 KB glibc-headers-2.15-7.x86_64 2012/03/16 00:50 2.1 MB glibc-libcrypt-2.15-7.i6862012/03/16 00:47 41.0 KB glibc-libcrypt-2.15-7.x86_64 2012/03/16 00:50 42.0 KB glibc-localedb-all-2.15-7.x86_64 2012/03/16 00:50 110.3 MB glibc-misc-2.15-7.x86_64 2012/03/16 00:50 52.0 KB 10 packages, 128.4 MB poldek:/all-avail install glibc-localedb-all-2.15-7.i686 --test Processing dependencies... glibc-localedb-all-2.15-7.x86_64 obsoleted by glibc-localedb-all-2.15-7.i686 There are 1 package to install, 1 to remove: I glibc-localedb-all-2.15-7.i686 R glibc-localedb-all-2.15-7.x86_64 This operation will use 217.3KB of disk space. Need to get 2.4MB of archives. ja wiem, ze just-install, ale to powinno isc gladko bez kombinowania. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: glibc 2.15 psuje libGL z NVidii
On Sunday 11 of March 2012 00:09:25 Lukasz Glebicki wrote: On Thursday 05 of January 2012 19:57:54 Arkadiusz Miśkiewicz wrote: Ten nie powinien się u nas objawiać. Odgrzeje starego kotleta, U mnie wszystko było ok, do wczoraj. Wczoraj smplayer nie potrafił sobie sciągnąć poprawnie napisów. vlc wywala się segv na nvidii. #0 0x7fa3a9efdc0f in _nv022tls () from /usr/lib64/nvidia/libnvidia- tls.so.295.20 do zgloszenia https://bugzilla.redhat.com/show_bug.cgi?id=797905 jest zalaczony dosc dokladny backtrace, ktory wylecial w tym samym miejscu nvidii. niestety nie da sie tego zdebugowac, bo binarny fragment nvidii nie ma symboli. sugueruje uderzyc z tym na forum producenta. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
