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... :( przeciez bylo ogloszenie request for developers mialo byc zamkniete i rozwijane 2.1 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 pozdrawiam ChomAr -- Arkadiusz Chomicki Władysławowo ___ 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 wtorek, 17 kwietnia 2007, Pawel Golaszewski napisał: On Tue, 17 Apr 2007, Marcin Król wrote: A co masz do zarzucenia dystrybucyjnemu 2.6 ? [...] Marudzisz :) Jakiś czas temu miałem jeden problem z 2.6, ale u mnie z kolei 2.4 gorzej chodzą, z większymi problemami, niż _wszystkie_ 2.6 Ja bardzo polecam 2.6 U mnie na kilku maszynkach ostatnim działającym 2.6 był 2.6.8-4 :/ -- Łukasz [DeeJay1] Jernaś ___ 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 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: 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: 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: 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: 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: 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
Mrożenie Ac
Cześć 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. 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 =?utf-8?q?Mr=C3=B3z?= 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 ? Cos sie jeszcze w Ac zmienia? -- === 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
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. 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
