Re: Mrożenie Ac
On Mon, 16 Apr 2007, Daniel Mróz wrote: On Monday 16 April 2007, Andrzej Krzysztofowicz wrote: Tak się zastanawiam... Może zanim zamrozimy Ac rozwiążemy problem z udev-initrd? Obecnie, bez dorobienia linku do /sbin/initrd-udev nie można wygenerować initrd z udev. Co to znaczy zanim zamrozimy Ac ? No, Ac jest niby zamrożone. Czyli nie wprowadzamy rewolucyjnych poprawek. Cos sie jeszcze w Ac zmienia? Siakieś bugfiksy. Szkoda że nie przeszedł pomysł by Ac było wiecznie niedomknięte - bo tak to grozi że za chwilę będzie bezużyteczne niczym swego czasu Ra... :( Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 To nie logika, to polityka (c) Kabaret pod Wydrwigroszem 2006___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: boost.spec - rebuild to fix libstdc++ implementation change...
pluto pisze: Author: plutoDate: Mon Apr 16 19:27:21 2007 GMT Module: SPECS Tag: HEAD Log message: - rebuild to fix libstdc++ implementation change (_ZNSo9_M_insertEPKcl). To ja jeszcze poproszę przebudować z tego samego powodu vdrift vdrift: relocation error: vdrift: symbol _ZNSo9_M_insertEPKcl, version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference pozdrawiam -- Jaroslaw Kruk : [EMAIL PROTECTED] [EMAIL PROTECTED] GPG key Id : 0x78730F33 GPG FingerPrint : FD00 0082 DFBD 65AE 2FD9 A13F B879 7FB0 7873 0F33 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x78730F33 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tuesday 17 of April 2007 08:14:10 Jacek Osiecki wrote: Co to znaczy zanim zamrozimy Ac ? No, Ac jest niby zamrożone. Czyli nie wprowadzamy rewolucyjnych poprawek. Cos sie jeszcze w Ac zmienia? Siakieś bugfiksy. Szkoda że nie przeszedł pomysł by Ac było wiecznie niedomknięte - bo tak to grozi że za chwilę będzie bezużyteczne niczym swego czasu Ra... :( Ale jest już Th unstable. Mrożenie jest konieczne, aby mieć punkt, w którym wszystko w dystrybucji jest przetestowane i (teoretycznie) działa. Pamiętaj, że są osoby, które nie instalują w środowisku produkcyjnym niczego, co nie jest oficjalnie naznaczone etykietką final, czy stable. Nie sądzę też, aby skusili się oni na dystrybucję semistable, quasistable, always in development czy always unstable :) Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED] http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: boost.spec - rebuild to fix libstdc++ implementation change...
Jaroslaw Kruk napisał(a): pluto pisze: Author: plutoDate: Mon Apr 16 19:27:21 2007 GMT Module: SPECS Tag: HEAD Log message: - rebuild to fix libstdc++ implementation change (_ZNSo9_M_insertEPKcl). To ja jeszcze poproszę przebudować z tego samego powodu vdrift vdrift: relocation error: vdrift: symbol _ZNSo9_M_insertEPKcl, version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference poki co to ep09 jest przeciazona i moje requesty z wczoraj jeszcze wisza w kolejce do przetworzenia. ktos moze dolac wody do lokomotywy? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tue, 17 Apr 2007, Daniel Mróz wrote: On Tuesday 17 of April 2007 08:14:10 Jacek Osiecki wrote: Szkoda że nie przeszedł pomysł by Ac było wiecznie niedomknięte - bo tak to grozi że za chwilę będzie bezużyteczne niczym swego czasu Ra... :( Ale jest już Th unstable. Tak, ale na maszynie produkcyjnej - do tego zdalnej - nie bardzo da się na niego przejść bez bólu z AC... Mrożenie jest konieczne, aby mieć punkt, w którym wszystko w dystrybucji jest przetestowane i (teoretycznie) działa. OK, pod warunkiem że to co zamrożone będzie pielęgnowane - a nie jak Ra, gdzie poważne dziury leżały i czekały na exploita... Pamiętaj, że są osoby, które nie instalują w środowisku produkcyjnym niczego, co nie jest oficjalnie naznaczone etykietką final, czy stable. Takie osoby nie używają raczej PLD, bo musiałyby siedzieć na Ra :) Nie sądzę też, aby skusili się oni na dystrybucję semistable, quasistable, always in development czy always unstable :) Mi w zupełności wystarcza AC bez ready, z własnymi dodatkami i własnoręcznie kompilowanym kelnerem :) No i przy każdym większym upgradzie robię snapshota - tzn. archiwizuję wszystkie zainstalowane RPMy, żeby można było do nich wrócić jeśli nowe mają coś spsute. Gdyby dało się to zorganizować firmowo w dystrybucji - byłaby jak dla mnie dystrybucją idealną :) Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 To nie logika, to polityka (c) Kabaret pod Wydrwigroszem 2006___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tue, Apr 17, 2007 at 10:27:02AM +0200, Jacek Osiecki wrote: [...] Mi w zupełności wystarcza AC bez ready, z własnymi dodatkami i własnoręcznie kompilowanym kelnerem :) No i przy każdym większym upgradzie robię snapshota - tzn. archiwizuję wszystkie zainstalowane RPMy, żeby można było do nich wrócić jeśli nowe mają coś spsute. Gdyby dało się to zorganizować firmowo w dystrybucji - byłaby jak dla mnie dystrybucją idealną :) rpm ma repackage (tworzenie *.rpm z odinstalowywanych pakietów). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Dnia 17-04-2007, wto o godzinie 10:27 +0200, Jacek Osiecki napisał(a): Gdyby dało się to zorganizować firmowo w dystrybucji - byłaby jak dla mnie dystrybucją idealną :) A chciałem tak zapytać - a jeżeli PLD przeszło by na always-current i dodatkowo posiadało mechanizm, który opisałeś powyżej. Czy w takiej sytuacji wraz z wyraźnie określoną polityką lądowania paczek w main (po jakimś tam przetestowaniu) uznałbyś takie środowisko za produkcyjne? [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tue, 17 Apr 2007, Cezary Krzyzanowski wrote: Dnia 17-04-2007, wto o godzinie 10:27 +0200, Jacek Osiecki napisał(a): Gdyby dało się to zorganizować firmowo w dystrybucji - byłaby jak dla mnie dystrybucją idealną :) A chciałem tak zapytać - a jeżeli PLD przeszło by na always-current i dodatkowo posiadało mechanizm, który opisałeś powyżej. Czy w takiej sytuacji wraz z wyraźnie określoną polityką lądowania paczek w main (po jakimś tam przetestowaniu) uznałbyś takie środowisko za produkcyjne? No, zdaje się że właśnie to napisałem ;) Używam AC na kilku serwerach produkcyjnych o różnych priorytetach, + jeden typu poligon na którym sprawdzam czy nowe pakiety zachowują się w miarę poprawnie. Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 To nie logika, to polityka (c) Kabaret pod Wydrwigroszem 2006___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tuesday 17 of April 2007 10:27:02 Jacek Osiecki wrote: Szkoda że nie przeszedł pomysł by Ac było wiecznie niedomknięte - bo tak to grozi że za chwilę będzie bezużyteczne niczym swego czasu Ra... Ale jest już Th unstable. Tak, ale na maszynie produkcyjnej - do tego zdalnej - nie bardzo da się na niego przejść bez bólu z AC... No dobrze, to w takim razie jak wyobrażasz sobie wprowadzanie dużych zmian, np. nowe gcc, nowe glibc etc.? Model rozwoju proponowany przez Ciebie charakteryzuje się także ciągnięciem za sobą wad Ac. Mrożenie jest konieczne, aby mieć punkt, w którym wszystko w dystrybucji jest przetestowane i (teoretycznie) działa. OK, pod warunkiem że to co zamrożone będzie pielęgnowane - a nie jak Ra, gdzie poważne dziury leżały i czekały na exploita... Wszystko powoli umiera. Czy ktoś jeszcze rozwija wczesne wersje RH? Pamiętaj, że są osoby, które nie instalują w środowisku produkcyjnym niczego, co nie jest oficjalnie naznaczone etykietką final, czy stable. Takie osoby nie używają raczej PLD, bo musiałyby siedzieć na Ra :) Powiedz to Ethanakowi ;) Nie sądzę też, aby skusili się oni na dystrybucję semistable, quasistable, always in development czy always unstable :) Mi w zupełności wystarcza AC bez ready, z własnymi dodatkami i własnoręcznie kompilowanym kelnerem :) Na jak długo? No i przy każdym większym upgradzie robię snapshota - tzn. archiwizuję wszystkie zainstalowane RPMy, żeby można było do nich wrócić jeśli nowe mają coś spsute. Przy stabilnej dystrybucji nie musisz tego robić. Instalujesz - działa. Aktualizujesz (security, general) - działa. Oczywiście, po pewnym czasie aktualizacje znikną, ale wtedy Th będzie tak stabilne jak Ac pół roku temu i przejście na nią będzie mniej bolesne. Ja z Ac długo zwlekałem, głównie dlatego, że były też problemy z przejściem Ra-Ac, a ja nie mam w domu stałego dostępu do Internetu żeby naprawiać ewentualne rozjazdy. Po pewnym czasie przestały one być aktualne i zmiana była bezbolesna (aktualizacje dla Ra jeszcze się pojawiały w tym czasie). Z Ac będzie pewnie tak samo, chociaż zastanawiam się nad wcześniejszym przeprowadzeniem tej operacji ze względu na prace w HEAD, w którym obowiązuje już Th. Gdyby dało się to zorganizować firmowo w dystrybucji - byłaby jak dla mnie dystrybucją idealną :) Ciekawy pomysł. Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED] http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [TH] poldek
Jakub Bogusz napisał(a):
On Mon, Apr 16, 2007 at 09:28:29AM +0200, Tomasz Mateja wrote:
strace jeszcze nie potrafie zbudowac ;-(, na sparc64 tez Memory fault ale
gdb sie nie buduje...
strace już się buduje na ac-sparc*, gdb na rivendell (~th-sparc64) też.
Oo dzieki dzieki dzieki. Końcówka strace z poldka poniżej.
A na rivendell jest jakiś builder postawiony czy po prostu w tym
chroocie budujesz pakiety? Jeśli nie to czy są jakieś przeciwskazania
żeby postawić tam dwa buildery (sparc i sparc64). Z tego co mam
pobudowane można by sie pokusić o podstawowy chroot. Gaussus coś kiedyś
wspominal o builderze na tej maszynie. U mnie na ultrze 60 @ 450MHz gcc
buduje sie ~24h ;P
sparc:
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
time(NULL) = 1176796013
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x70bde000
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x70c0
munmap(0x70c0, 139264) = 0
mremap(0x70bde000, 139264, 8192, MREMAP_MAYMOVE) = 0x70bde000
stat64(/etc/rpm/sysinfo, {st_mode=S_IFREG|0644, st_size=61, ...}) = 0
open(/etc/rpm/sysinfo, O_RDONLY|O_LARGEFILE) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x70024000
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
gettimeofday({1176796013, 134917}, NULL) = 0
read(3, Filelinktos:\n\t/proc/self/fd\n\t/de..., 8192) = 61
gettimeofday({1176796013, 136928}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
gettimeofday({1176796013, 138728}, NULL) = 0
read(3, , 8131) = 0
gettimeofday({1176796013, 140547}, NULL) = 0
time(NULL) = 1176796013
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 4655 detached
sparc64:
gettimeofday({1176796071, 56659}, NULL) = 0
gettimeofday({1176796071, 57543}, NULL) = 0
gettimeofday({1176796071, 58678}, NULL) = 0
gettimeofday({1176796071, 59779}, NULL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xf803c000
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xf805e000
munmap(0xf805e000, 139264) = 0
mremap(0xf803c000, 139264, 8192, MREMAP_MAYMOVE) =
0xf803c000
stat64(/etc/rpm/sysinfo, {st_mode=0, st_size=0, ...}) = 0
open(/etc/rpm/sysinfo, O_RDONLY) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xf8024000
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
gettimeofday({1176796071, 70053}, NULL) = 0
read(3, Filelinktos:\n\t/proc/self/fd\n\t/de..., 8192) = 61
gettimeofday({1176796071, 71961}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 1000) = 1
gettimeofday({1176796071, 73739}, NULL) = 0
read(3, , 8131) = 0
gettimeofday({1176796071, 81372}, NULL) = 0
gettimeofday({1176796071, 82274}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 4738 detached
--
T.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Jacek Osiecki wrote: On Mon, 16 Apr 2007, Daniel Mr=F3z wrote: On Monday 16 April 2007, Andrzej Krzysztofowicz wrote: Tak si=EA zastanawiam... Mo=BFe zanim zamrozimy Ac rozwi=B1=BFemy probl= em z udev-initrd? Obecnie, bez dorobienia linku do /sbin/initrd-udev nie mo= =BFna wygenerowa=E6 initrd z udev. Co to znaczy zanim zamrozimy Ac ? No, Ac jest niby zamro=BFone. Czyli nie wprowadzamy rewolucyjnych poprawe= k. Cos sie jeszcze w Ac zmienia? Siakie=B6 bugfiksy. Szkoda =BFe nie przeszed=B3 pomys=B3 by Ac by=B3o wiecznie niedomkni=EAte= - bo tak to grozi =BFe za chwil=EA b=EAdzie bezu=BFyteczne niczym swego czasu Ra... = Wieczne niedomkniecie nie pozwala na porzucenie tony triggerow/Provides itp potrzebnych do upgrejdu z wielu wczesniejszych wersji. A tak w Th nie trzeba sie zupelnie przejmowac co bylo we wczsnych wersjach pre-Ac i jak przeprowadzic z nich upgrejd. Heh, moze sie skusze i zupgrejduje ostatnie maszyny na Ra... -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Cos sie jeszcze w Ac zmienia? Siakieś bugfiksy. Ac jest zamkniete i do main nic juz nie trafi. Wyjatki, ktore trafialy do main byly w 90% poprawkami koniecznymi do poprawnego wygenerowania isos i dzialania instalatora. Wszelkie poprawki, ktore w tej chwili sa w ready trafia juz do updates. Obrazy iso pojawia sie jak tylko podpisze wszystkie paczki w main. Wszystko juz jest praktycznie gotowe do ich generowania. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Wieczne niedomkniecie nie pozwala na porzucenie tony triggerow/Provides itp potrzebnych do upgrejdu z wielu wczesniejszych wersji. Pomysl dystrybucji zawsze w rozwoju zakladal wypuszczanie snapshotow z drzewka stable oraz co jakis czas mile stones opartych o duze zmiany brane z drzewka devel. Od obecnego sposobu rozwoju roznilo by sie to tym, ze zniknelo by mrozenie, zabawy z instalatorem i wogole wszelkie ceregiele zwiazane z wydawaniem kolejnych wersji. Po prostu co pol roku by sie z zawartosci drzewka stable generowalo obrazy iso i tyle. A nawet ten punkt by sobie mozna darowac i zostac tylko i wylacznie przy instalacjach sieciowych czy chrootowych. Bo co tak naprawde dalo wydanie Ac? Cos sie zmienilo? Jedynie tyle ze: a) mamy etykietkie stable b) brak niespelnionych zaleznosci (wg poldka) c) paczki zamiast do main beda trafiac do updates Heh, moze sie skusze i zupgrejduje ostatnie maszyny na Ra... Warto :) Choc dystrybucyjnego 2.6 nie polecam :( 2.4 jest w porzadeczku. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Marcin Król wrote:
[...]
Warto :) Choc dystrybucyjnego 2.6 nie polecam :( 2.4 jest w porzadeczku.
A co masz do zarzucenia dystrybucyjnemu 2.6 ?
I któremu ?
Sas.
--
{Wojciech 'Sas' Cieciwa} {Member of PLD Team }
{e-mail: [EMAIL PROTECTED], http://www2.zarz.agh.edu.pl/~cieciwa}
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
A co masz do zarzucenia dystrybucyjnemu 2.6 ? Panikuje co jakis czas wieszajac system na sztywno. I nie jest to wina sprzetu, juz to wykluczylem. Osobiscie uwazam, ze jest przeladowany patchami. Swego czasu byla akcja czyszczenia kernel.spec z nadmiaru patchy. Wszystkie kernele sprzed tej akcji oopsowaly. Po czystkach przez jakis czas byl spokuj, zaczely nawet dzialac na maszynach smp z nie-intelowymi chipsetami. Potem znow sie zaczelo dodawanie patchy i wrocilismy do punktu wyjscia. Taka przynajmniej jest moja teoria. Aha. Zrzutow oopsow nie posiadam. Gdy dawalem dystrybucyjnemu 2.6 szanse na produkcji, podniesienie maszyny mialo priorytet nad zdumpowaniem oopsa. Obecnie mam go juz tylko na domowym serwerku i niestety zazwyczaj zawisa gdy mnie nie ma w domku, a wtedy po prostu jest rebootowany. I któremu ? Temu co jest w Ac, wraz z kilkunastoma poprzednimi jego wersjami. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tuesday 17 of April 2007 12:51:21 Marcin Król wrote: Wszystko juz jest praktycznie gotowe do ich generowania. A co z problemem poruszonym przeze mnie w tym wątku? Czym zakończyły się kłótnie /sbin/init-udev vs. zmiana w geninitrd? Obecnie każda instalacja systemu z udev nie generuje initrd, a próba samodzielnego stworzenia takowego kończy się błędem i koniecznością wykonania dowiązania symbolicznego. Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED] http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tue, 17 Apr 2007, Marcin Król wrote: Wieczne niedomkniecie nie pozwala na porzucenie tony triggerow/Provides itp potrzebnych do upgrejdu z wielu wczesniejszych wersji. Pomysl dystrybucji zawsze w rozwoju zakladal wypuszczanie snapshotow z drzewka stable oraz co jakis czas mile stones opartych o duze zmiany brane z drzewka devel. Od obecnego sposobu rozwoju roznilo by sie to tym, ze zniknelo by mrozenie, zabawy z instalatorem i wogole wszelkie ceregiele zwiazane z wydawaniem kolejnych wersji. Po prostu co pol No i możliwość upgrade'u... Z Ra do AC praktycznie nie dało się bezboleśnie przejść na maszynie z dostępem remote-only... Tzn. pewnie się jakoś dało, ale było to zdecydowanie zbyt ryzykowne :( Bo co tak naprawde dalo wydanie Ac? Cos sie zmienilo? Jedynie tyle ze: a) mamy etykietkie stable b) brak niespelnionych zaleznosci (wg poldka) c) paczki zamiast do main beda trafiac do updates OK... Na razie TH się nie tykam - zobaczę jak się będzie dalo upgrade'ować ;) Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 To nie logika, to polityka (c) Kabaret pod Wydrwigroszem 2006___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 2 x libtorrent
2007/4/16, Jakub Bogusz [EMAIL PROTECTED]: On Mon, Apr 16, 2007 at 09:09:09PM +0200, Bart wrote: Witam wszystkich Chcialbym zrobic speca do libtorrent z http://www.rasterbar.com/products/libtorrent/ rb_libtorrent.spec Od razu mi się kojarzy z ruby albo rails. A biblioteka w C++ napisana. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tuesday 17 April 2007, Marek Guevara Braun wrote: A co z problemem poruszonym przeze mnie w tym wątku? Czym zakończyły się kłótnie /sbin/init-udev vs. zmiana w geninitrd? Obecnie każda instalacja systemu z udev nie generuje initrd, a próba samodzielnego stworzenia takowego kończy się błędem i koniecznością wykonania dowiązania symbolicznego. Cytuję glena: why are you using udev on initrd on ac? it never worked there, or does it do anything for you? (wątek na pld-devel-en z 2007-03-20) - temat na 2.1/updates ? To w takim razie usuwamy paczkę udev-initrd i wpis USE_UDEV w /etc/sysconfig/geninitrd? Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED]http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Daniel Mróz wrote: On Tuesday 17 April 2007, Marek Guevara Braun wrote: Cytuję glena: why are you using udev on initrd on ac? it never worked there, or does it do anything for you? (wątek na pld-devel-en z 2007-03-20) - temat na 2.1/updates ? To w takim razie usuwamy paczkę udev-initrd i wpis USE_UDEV w /etc/sysconfig/geninitrd? Jeśli rzeczywiście to nie działa out-of-the-box to pewnie było by to najlepsze rozwiązanie [*]. O ile samo podniesienie wersji udev (u mnie w środowisku prawie Ac działa udev-initrd-105-1) załatwiło by generowanie bootowalnego initrd, to nadal pozostawało by jeszcze podniesienie wersji busybox-initrd (niby z tym z Ac działa, ale brakuje mu kilku rzeczy, czego prawdopodobnie efektem ubocznym jest pozostawianie zamontowanego /initrd, co z kolei przeszkadza w instalacji/upgradzie pakietu filesystem), zmiany w geninitrd (co w Ac dostarcza geninitrd - jakoś nie widzę geninitrd w poldku w ac?) co rozszerza zakres fix-a o wszystko co jest budowane z busyboxem, testy, zależności itd... - za dużo (IMO) jak na właśnie zamkniętą wersję dystrybucji. [*] Być może lepszym szybkim rozwiązaniem było by dorobienie linka, o którym pisałeś, ew. poprawka w geninitrd, ale tu się nie wypowiem, bo nie sprawdzałem tego. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: boost.spec - rebuild to fix libstdc++ implementation change...
--- Jaroslaw Kruk [EMAIL PROTECTED] wrote: pluto pisze: Author: plutoDate: Mon Apr 16 19:27:21 2007 GMT Module: SPECS Tag: HEAD Log message: - rebuild to fix libstdc++ implementation change (_ZNSo9_M_insertEPKcl). To ja jeszcze poproszę przebudować z tego samego powodu vdrift vdrift: relocation error: vdrift: symbol _ZNSo9_M_insertEPKcl, version GLIBCXX_3.4.9 not defined in file libstdc++.so.6 with link time reference btw. hackerzy zajmujący się boost.spec powinni zwrócić uwagę, że z powodu brakującego debug-symbolson tworzy się pusty debuginfo. -- Fryderyk Dziarmagowski ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Dnia 17-04-2007, wto o godzinie 15:17 +0200, Marek Guevara Braun napisał(a): Cytuję glena: why are you using udev on initrd on ac? it never worked there, or does it do anything for you? I tak było również w TH. Poprawki które wprowadziłem w geninitrd sprawiły, że udev zadziałał podczas initrd - wcześniej uruchamiał się tylko program, który nic nie robił. Ktoś przeniósł od razu tego geninitrd prosto do AC nie testując i zaczęły się buraki. Dodatkowo z racji, że wszedł nowy udev, który już nie buduje udev, a jedynie udevd, pojawiły się dalsze problemy na szybko łatane przez bodajże Arka, które okazały się jeszcze bardziej niezgodne z AC i do pewnego stopnia z TH. Nie mam nigdzie AC żeby to poprawić. IMHO z racji, że nic tak na prawdę nie korzysta z udeva w initrd, z AC powinno to wylecieć (epoch i wcześniejsze geninitrd?). Z racji, że nie ma co babrać się z udevem, którego nie ma (czyli uruchamianie /sbin/udev), to w TH zostanie /sbin/udevd. Zdrawiam [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
On Tuesday 17 April 2007, Marek Guevara Braun wrote: Cytuję glena: why are you using udev on initrd on ac? it never worked there, or does it do anything for you? (wątek na pld-devel-en z 2007-03-20) - temat na 2.1/updates ? To w takim razie usuwamy paczkę udev-initrd i wpis USE_UDEV w /etc/sysconfig/geninitrd? Jeśli rzeczywiście to nie działa out-of-the-box to pewnie było by to najlepsze rozwiązanie [*]. Nie wiem niestety czy to jest przyczyną nietworzenia initrd przy instalacji. Problem pojawia się przy próbie ręcznego odpalenia geninitrd, ale po ustawieniu USE_UDEV. Oczywiście, skoro initrd nie korzysta z udev, wystarczy w takim przypadku nie ustawiać USE_UDEV w /etc/sysconfig/geninitrd, jednakże obecność takiej opcji jest myląca. O ile samo podniesienie wersji udev (u mnie w środowisku prawie Ac działa udev-initrd-105-1) załatwiło by generowanie bootowalnego initrd, to nadal pozostawało by jeszcze podniesienie wersji busybox-initrd (niby z tym z Ac działa, ale brakuje mu kilku rzeczy, czego prawdopodobnie efektem ubocznym jest pozostawianie zamontowanego /initrd, co z kolei przeszkadza w instalacji/upgradzie pakietu filesystem), zmiany w geninitrd (co w Ac dostarcza geninitrd - jakoś nie widzę geninitrd w poldku w ac?) Myślę, że nie ma co kombinować i wystarczy albo usunąć USE_UDEV albo zmodifikować geninitrd z Ac aby ignorował ten parametr, nawet po cichu. W takim przypadku istnienie paczki udev-initrd pozbawione jest sensu. co rozszerza zakres fix-a o wszystko co jest budowane z busyboxem, testy, zależności itd... - za dużo (IMO) jak na właśnie zamkniętą wersję dystrybucji. Może być dirty hack. Chodzi o to, aby nie wprowadzać użytkowników w błąd. [*] Być może lepszym szybkim rozwiązaniem było by dorobienie linka, o którym pisałeś, ew. poprawka w geninitrd, ale tu się nie wypowiem, bo nie sprawdzałem tego. Link załatwia sprawę, zresztą initrd podobno i tak z tego nie korzysta. Dodanie dowiązania do paczki zlikwiduje błąd przy generowaniu initrd, a niczego nie zepsuje. Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED]http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
A co z problemem poruszonym przeze mnie w tym wątku? Czym zakończyły się kłótnie /sbin/init-udev vs. zmiana w geninitrd? Nie wiem, nie bralem w nich udzialu. Obecnie każda instalacja systemu z udev nie generuje initrd, a próba samodzielnego stworzenia takowego kończy się błędem i koniecznością wykonania dowiązania symbolicznego. Nie uzywam udev wiec nie podejme sie poprawiania tego bledu :( M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Mrożenie Ac
Daniel Mróz wrote: A co z problemem poruszonym przeze mnie w tym wątku? Czym zakończyły się kłótnie /sbin/init-udev vs. zmiana w geninitrd? Obecnie każda instalacja systemu z udev nie generuje initrd, a próba samodzielnego stworzenia takowego kończy się błędem i koniecznością wykonania dowiązania symbolicznego. Cytuję glena: why are you using udev on initrd on ac? it never worked there, or does it do anything for you? (wątek na pld-devel-en z 2007-03-20) - temat na 2.1/updates ? Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[Ac] Zwalone pakiety?
Cześć Poldkowanie: error: apr-1.2.8-1.i686.rpm: headerRead failed error: apr-util-1.2.8-2.i686.rpm: headerRead failed Czyżby znowu dysk padał na FTP? Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED]http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[Ac] kernel-misc-thinkpad?
Cześć Paczka tpctl krzyczy przy instalacji o konieczności instalacji pakietu kernel-misc-thinkpad, który nie istnieje. Tak ma być? Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED]http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac] Zwalone pakiety?
On Tue, Apr 17, 2007 at 08:34:04PM +0200, Daniel Mróz wrote: Cześć Poldkowanie: error: apr-1.2.8-1.i686.rpm: headerRead failed error: apr-util-1.2.8-2.i686.rpm: headerRead failed Czyżby znowu dysk padał na FTP? Który serwer? (host ftppld-linux.org) -- http://www.mysza.eu.org/ | Everybody needs someone sure, someone true, PLD Linux developer| Everybody needs some solid rock, I know I do. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac] Zwalone pakiety?
On Tuesday 17 April 2007, Adam Gołębiowski wrote: Czyżby znowu dysk padał na FTP? Który serwer? (host ftppld-linux.org) Hmmm... Sprawdziłem i jest juz OK. Chyba się wstrzeliłem w podpisywanie pakietów. Pozdrawiam Beorn -- Daniel 'Beorn' Mróz [EMAIL PROTECTED]http://127.0.0.1/beorn [GIT d s:- a-@ C UL$ P+ L E--- W+ N+++ o? K- w---] [O- M- V! PS+ PE++ Y+ PGP++ t- 5 X R !tv b+ DI D++ G++ e h*] [ r++ y+ ] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 2 x libtorrent
On Mon, Apr 16, 2007 at 09:09:09PM +0200, Bart wrote:
Witam wszystkich
Chcialbym zrobic speca do libtorrent z
http://www.rasterbar.com/products/libtorrent/
W CVS pod nazwa libtorrent.spec mamy inna biblioteke ... z
http://libtorrent.rakshasa.no/
Co z tym fantem zrobic, jaka nazwe wybrac dla speca ?
Proponuje libTorrent.spec choc powinno byc chyba odwrotenie patrzac na
naglowki na stronach.
a jaka nazwa biblioteki ?
[EMAIL PROTECTED] ~]$ rpm -ql libtorrent
/usr/lib/libtorrent.so.10.0.3
jeśli tamta ma taką samą to będzie więcej mieszania niż tylko nazwa
paczki
--
Sparky{PI] -- Przemyslaw _ ___ _ _ ... LANG...Pl..Ca..Es..En
/) ___ ___ _ _ || Iskra | | _ \| | | : WWWppcrcd.pld-linux.org
\\| -_)'___| ||^'||//\\//| _/| | | : JID..sparkyatjabberes.org
(/|| (_-_|_|| ||\\ || |_ |_| |_| _| : Mailsparkyatpld-linux.org
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 2 x libtorrent
17-04-07, Przemyslaw Iskra [EMAIL PROTECTED] napisał(a): On Mon, Apr 16, 2007 at 09:09:09PM +0200, Bart wrote: Witam wszystkich Chcialbym zrobic speca do libtorrent z http://www.rasterbar.com/products/libtorrent/ W CVS pod nazwa libtorrent.spec mamy inna biblioteke ... z http://libtorrent.rakshasa.no/ Co z tym fantem zrobic, jaka nazwe wybrac dla speca ? Proponuje libTorrent.spec choc powinno byc chyba odwrotenie patrzac na naglowki na stronach. a jaka nazwa biblioteki ? [EMAIL PROTECTED] ~]$ rpm -ql libtorrent /usr/lib/libtorrent.so.10.0.3 jeśli tamta ma taką samą to będzie więcej mieszania niż tylko nazwa paczki Nom, jakis -SONAME.patch by sie zdał wtedy. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac] kernel-misc-thinkpad?
17-04-07, Daniel Mróz [EMAIL PROTECTED] napisał(a): Cześć Paczka tpctl krzyczy przy instalacji o konieczności instalacji pakietu kernel-misc-thinkpad, który nie istnieje. Tak ma być? Spec jest, wystarczy zbudować. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
