[PLDWWW] page changed: pl:docs:instalacjazapomocachroota
[Rozpakowanie gotowca] --- https://www.pld-linux.org/pl/docs/instalacjazapomocachroota?rev=1231954745 +++ https://www.pld-linux.org/pl/docs/instalacjazapomocachroota @@ -44,9 +44,9 @@ == Rozpakowanie gotowca == - * ściągamy gotowego chroota [[ftp://ftp.pld-linux.org/people/undefine/chroot/ac|od Undefined (Ac i Th)]] lub [[ftp://ftp.titanium.pld-linux.org/people/hawk/cri/chroots/|od Hawka (Ti i Th)]] + * ściągamy gotowego chroota [[ftp://ftp.pld-linux.org/people/undefine/chroot/ac|od Undefined (Ac i Th)]] * rozpakowujemy go (na przykład tar xvfj chroot-i686.tar.bz2) == Psucie nowego systemu == Diff URL: https://www.pld-linux.org/pl/docs/instalacjazapomocachroota?do=diff&r1=1231954745&r2=1396966880 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: packages:xulrunner
--- https://www.pld-linux.org/packages/xulrunner?rev=1253356814 +++ https://www.pld-linux.org/packages/xulrunner @@ -2,9 +2,9 @@ /* page was renamed from xulrunner */ = XULRunner upgrade procedure = - PLD Ac, Th and Titanium are using custom builds of [[http://developer.mozilla.org/en/docs/XULRunner|XULRunner]] to provide libraries for all applications using Gecko engine (except Iceweasel, Icedove and [[:Packages:Iceape|Iceape]]). Since Firefox 3.0 was released XULRunner may (and even should) be built from Firefox sources. Be sure to include CVE notes when updating this and other Mozilla packages. You may obtain them from [[http://www.mozilla.org/projects/security/known-vulnerabilities.html|http://www.mozilla.org/projects/security/known-vulnerabilities.html]]. + PLD Ac and Th are using custom builds of [[http://developer.mozilla.org/en/docs/XULRunner|XULRunner]] to provide libraries for all applications using Gecko engine (except Iceweasel, Icedove and [[:Packages:Iceape|Iceape]]). Since Firefox 3.0 was released XULRunner may (and even should) be built from Firefox sources. Be sure to include CVE notes when updating this and other Mozilla packages. You may obtain them from [[http://www.mozilla.org/projects/security/known-vulnerabilities.html|http://www.mozilla.org/projects/security/known-vulnerabilities.html]]. Following specs must be rebuild after XULRunner upgrade on all PLD distros: @@ -17,10 +17,10 @@ * blam.spec * liferea.spec - PLD Titanium and PLD 3.0 (Th): + PLD 3.0 (Th): * gnome-web-photo.spec * python-gnome-extras.spec Diff URL: https://www.pld-linux.org/packages/xulrunner?do=diff&r1=1253356814&r2=1396966674 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: people:glen
[Inner Wiki links] proper TLD name, feel free to drop this link if it bothers someone in PLD --- https://www.pld-linux.org/people/glen?rev=1370863021 +++ https://www.pld-linux.org/people/glen @@ -5,9 +5,9 @@ = Inner Wiki links = * [[:packages:pear|PEAR Info]] - * [[http://www.tld-linux.org/|Linux Titanium info]] + * [[http://www.tld-linux.org/|TLD Linux (former PLD Titanium) info]] * [[:docs:vserver|PLD Linux Vserver pages]] * [[::developingpld|Developing PLD Linux]] * [[:developingpld:acrequestsrules|AC builder notes]] * [[:developingpld:ackernelbuildernotes|building Ac kernel packages notes]] Diff URL: https://www.pld-linux.org/people/glen?do=diff&r1=1370863021&r2=1396966793 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: about
Titanium is history --- https://www.pld-linux.org/about?rev=1370245713 +++ https://www.pld-linux.org/about @@ -17,12 +17,9 @@ |PLD Ra/1.0|22.11.2002|stable, EOL now| |[[:AcInfo|PLD Ac/2.0]]|01.04.2007|stable| |[[:ThInfo|PLD Th/3.0]]| |stable, in endless development| - = Unofficial Releases = - |**version**|**status**| - |[[http://wiki.tld-linux.org/|PLD Titanium]]|stable, in endless development| = Current Status = Current versions of PLD support the following architectures: Diff URL: https://www.pld-linux.org/about?do=diff&r1=1370245713&r2=1396966622 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: people:hawk
No point in keeping this page. --- https://www.pld-linux.org/people/hawk?rev=1396965829 +++ https://www.pld-linux.org/people/hawk @@ -1,51 +1 @@ - - - == Marcin Król == - - - = Short FAQ = - Q1: How may I contact you?\\ A1: Send me an e-mail (hawk@pld...). You may be sure that I'll read it and will try to answer it ASAP (if required).\\ A2: Jabber me (hawk@pld...). Note: if your message will arrive while I'm busy/in work/etc I may forgot about it and it will remain unanswered. In such case please send your message again or refer to A1.\\ A3: Catch me on irc (#pld @ freenode). Note: I'm not checking IRC on daily basis. Your message may be answered in few days or not anserwed at all. Please don't use IRC for sending some important informations/requests. Check A1 before you'll send me some vital info via IRC. - - Q: I have some other question...\\ A: goto Q1 - - - - = Inner Wiki links = - - * [[:packages:xulrunner|XULRunner upgrade procedure]] - - - = PLD 1.0/1.1 (Ra) information = - PLD Ra has reached EOL (End of Life). It will not be updated anymore. It is strongly recommended to upgrade to Ac, Th or Titanium as soon as possible! - - - - = PLD 2.0 (Ac) information = - I gave up maintaining this version of PLD. I wasn't able to do some necessary changes without breaking stability. I've chosen to create PLD Titanium instead. - - - - = PLD installer = - PLD 2.0 Ac is the last one using old, text based installer. I'm not planning any updates of existing installer code. This project has reached EOL. Future versions of PLD will probably use Anaconda or no installer at all. - - - - = CRI - ChRoot Installer = - Long time ago I was planning to create console based installer that will fit on floppy and will use chroot + previously prepared tarball with system to perform installation. Theoretically this should allow installation of any Linux distribution in any configuration. I've finally managed to release such bootdisks. Check [[http://cri.pld-linux.org/|http://cri.pld-linux.org/]] for more details. - - - - = Useful information = - I cannot guarantee that: - - - * I'll accept and/or commit changes/patches you've sent to me - * I'll respond to your e-mail in acceptable time (mail me again or jabber me if something is urgent) - * I'll take care of all PLD related problems - * I'll have something done in specified time (I'll do my best, but please understand that I also have life, work etc.) - - - - [[::categoryhomepage|CategoryHomepage]] - - + Please delete this page. Diff URL: https://www.pld-linux.org/people/hawk?do=diff&r1=1396965829&r2=1396966517 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: people:hawk
[Inner Wiki links] --- https://www.pld-linux.org/people/hawk?rev=1350165538 +++ https://www.pld-linux.org/people/hawk @@ -11,9 +11,8 @@ = Inner Wiki links = - * [[::titanium|PLD Titanium page]] * [[:packages:xulrunner|XULRunner upgrade procedure]] = PLD 1.0/1.1 (Ra) information = Diff URL: https://www.pld-linux.org/people/hawk?do=diff&r1=1350165538&r2=1396965829 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
[PLDWWW] page changed: links
[Official:] old CRI is dead, new will not support PLD --- https://www.pld-linux.org/links?rev=1225955890 +++ https://www.pld-linux.org/links @@ -11,9 +11,8 @@ * [[http://forum.pld-linux.org/|http://forum.pld-linux.org/]] - PLD Linux forum * [[http://livecd.pld-linux.org/|http://livecd.pld-linux.org/]] - Live CD * [[http://rescuecd.pld-linux.org/|http://rescuecd.pld-linux.org/]] - RescueCD * [[http://ppcrcd.pld-linux.org/|http://ppcrcd.pld-linux.org/]] - RescueCD for PPC - * [[http://cri.pld-linux.org/|http://cri.pld-linux.org/]] - ChRoot Installer * [[http://pld-users.org/|http://pld-users.org/]] - Users' wiki = Unofficial: = Diff URL: https://www.pld-linux.org/links?do=diff&r1=1225955890&r2=1396965783 -- This mail was generated by DokuWiki at https://www.pld-linux.org/ ___ pld-cvs-commit mailing list pld-cvs-commit@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
Re: BR-s and R-s policy
> User sends request for: libcrap, few seconds later for appX appY. libcrap > installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with > new libcrap and with old libcrap on i686. Whoops. True, but only difference is that RM will have to delete appX and appY for i686 and user or RM will need to resend it using auto- tag. I'd prefer to have correct version deps and fix such issues myself than doesn't have that issues but have to create and maintain additional branches where they aren't needed. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
>> The only good thing from bumping version I see is that when upgrade on >> builders will fail user will be unable to build dependant stuff till >> I'll fix it. > > It happens from time to time and this is exactly the problem I was referring > to. (and user can fix the problem himself and resend) Correct me if I'm wrong, but users don't have access to send commands to builders (at least for Ac). How they're supposed to say builder to perform upgrade which has failed on dependencies? They are usually sending mails about failed upgrades and then RM has to fix problem manually. So "fixing" will look exactly the same way without dependecies. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
> Not only RM has rights to send packages to builders. I don't get it. If someone will send some package it will be automagically upgraded on builders. If such upgrade will fail on deps I'll usually know about it quite soon and will have to fix it manually anyway. If someone will send something that I'll reject from moving to main tree I'll have to downgrade it manually too. The only good thing from bumping version I see is that when upgrade on builders will fail user will be unable to build dependant stuff till I'll fix it. I had such situation only once since RMing Ra and Ac and it was piece of cake to fix (manual poldek upgra, rel++, stbr). I still don't see any advantage in bumping those versions. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
> It's used to ensure that there are latest packages on the builders. That's > the > only reason I know. I always thought its RM job to maintain builders. But what do I know... :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: BR-s and R-s policy
> So is this some kind of policy, to require newest packages possible at > the time of upping spec? It seems so. Its stupid IMO to bump version to highest possible ignoring real requirements. For example many specs from HEAD are building perfectly on Ac after dropping unecessary version requirements. In Ac case it leads to creating and maintaining unecessary Ac branch. But well, most of developers says thats good idea. I remember some discussion about it but unfortunatelly I don't remember any arguments why it is good solution to bump version everytime something gets updated. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Unclear Firefox situation
> I think Debian does allow it, but I don't even remember those package > names. BTW: iceweasel.spec contains obsolete version of package, with > well known security bugs. Those Debian patches seems to simply replace logos and some texts in source. After removing debian specific chunks from patches it would be simple cp of current specs + one more patch + replacing software names in specs. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Unclear Firefox situation
> Older versions of Firefox used "Bon Echo" branding which is permitted > to all parties. Now it seems official branding is back. Any particular > reason? Are we allowed to do that? We can use "community edition" > instead of "Bon Echo" but I doubt we are allowed to ship it as > "Firefox." I didn't used 2.0.0.7 yet but 2.0.0.6 was BonEcho on both Ac and Th. Quick look at changelog says that it still should be BonEcho or I missed something. Anyway, problem is more complex. We can't use branding for Thunderbird and SeaMonkey as well. Last one is problematic as it doesn't matter if you do official build or not, its always branded. Maybe we should use Debian patches and change software names, logos etc to Iceweasel, Iceape and Icedove? Does Debian allows use of these patches in other distros? I have it in my looong todo but with low priority. BTW: if I remember correctly license also disallows use of terms "mozilla firefox" and "mozilla thunderbird" anywhere in package including executable file names. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Bind i defaultowe allow-query...
> Przydaloby sie moze jakies > info podczas upgradu, ze zmienilo sie to dosc powazne ustawienie i > ewentualnie rozwiazaniem moze byc dopisanie do konfiga klas lub: Szybki rzut oka na sume md5 tarballa z konfigami mowi mi ze od daawna nie byly one zmieniane. > allow-query { any; }; Raczysz chyba zartowac? Pomijajac, ze taki wpis sprzyja DNS cache poisoning to konfiguracja domyslna jest po to aby administrator dostosowal ja do swoich potrzeb, a nie na odwrot. Skoro upgrade podmienil twoja konfiguracje to znaczy, ze jej nigdy nie modyfikowales bo w specu stoi jak byk "%config(noreplace) %verify(not md5 mtime size)" M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: maly problem z tar-em
> Probuje uzyc opcji "--ignore-failed-read", ale cos mi nie wychodz: > > tar: --ignore-failed-read: Nie można stat: Nie ma takiego pliku ani katalogu > tar: Zakończenie z błędem z powodu uprzednich błędów > > a robie tak: > > tar zcfv cos.tar.gz ktos --ignore-failed-read Od ktorejs tam wersji tara zmienila sie kolejnosc parametrow. Zajrzyj w man tar. Powinno byc tak: tar zcvf cos.tar.gz --ignore-failed-read plik1 plik2 M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: SPECS: postfix.spec - up to 2.4.5 - new VDA patch - build-tested only
> Nie, wogole nie uzywalem ani nie uzywam tej fukcjonalnosci. > Ale jak widac na defaultach nic nie psuje. Owszem psuje. Zmienia sie sposob dzialania zwyklych wirutali przez co wlasciciele "zwyklych" konfiguracji moga sie obudzic z reka w nocniki. Szczegolow nie znam, ale pamietam, ze ktos pisal o tym na listach dosc dawno temu. A moze to byl IRC? Nie udalo mi sie w kazdym razie znalezc w archiwum list. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: postfix.spec - up to 2.4.5 - new VDA patch - build-tested only
> Rozumiem ze mowisz o Ac, a czy w Th tez jest konieczne wlaczenie tej > latki? W Th to by musial zdecydowac RM Th :) Co do samej laty to moje zdanie o niej jest takie samo jak autora postfixa. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: postfix.spec - up to 2.4.5 - new VDA patch - build-tested only
> I to nie pierwszy raz shadzik odwrócił bconda vda, mimo obecności > krytycznych komentarzy co do tej łaty w commitlogach. Odwrocenie bconda moglo akurat nie byc zamierzone bo z tego co widze to AC-branch zostal po prostu przesuniety na rewizje 1.282, a w Th vda jest od dawna wlaczone. Oczywiscie vda bedzie wylaczone ASAP. BTW tematu Ac to nie powinno sie juz zdarzyc, aby paczki w ready lezaly krocej niz 48 godzin. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: OK: gcc.spec
> maybe a separate list (pld-logs-ti?) should be set up? Or I may simply remove list address from builder configs for now. There may be quite big traffic there in next two months or so. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: postfix-2.3.12-4
> Bo (zgaduje): do updates Ac trafiaja rzeczy, ktore odlezaly jakis czas w > ready/ i nikt w tym czasie nie zglosil do nich zastrzezen... Dokladnie tak to wyglada. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ti] (no subject)
> Mam nadzieję, że ze względu na ogólną dostępność Ti nie skończy się na > "i tyle" ale wrzucisz też gdzieś informację, żeby uważać przy upgradzie > - może na blogu w kategorii Ti żeby wszyscy zainteresowani mogli > wcześniej przeczytać co ich czeka przy upgradzie... Raczej na pewno bede gdzies zamieszczal takie informacje, zwlaszcza jezeli wiecej osob by mialo zamiar korzystac z Ti. A sadzac po mailach i jabberze przynajmniej kilku chetnych bedzie. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ti] (no subject)
> A moze nadac temu jakis nr, np. 2,5 i uoficjalnic ? Wolal bym nie. Gdyby mnie to urzadzalo robil bym to oficjalnie jako 2.1 (Ti) tak jak planowalem z poczatku. Chce miec jednak mozliwosc robienia pewnych zmian, ktorych nie moge robic w takim na przyklad Ac typu dodawanie/usuwanie architektur, wlasny kernel, wlasne konfiguracje niektorych paczek jezeli bede mial taka potrzebe itp. Nie chce tez wydawania kolejnej wersji i calego zamieszania typu instalator czy generowanie isos. Chce tez utrzymywac to w ciaglym rozwoju, czyli jak wyjdzie nowy PostgreSQL i go bede potrzebowal (a bede na pewno) to nie patrze, ze trzeba recznie zrobic dump/restore i ZU sobie nie poradza tylko go wrzucam na buildery i tyle. Wiem, ze to jest prywata i moze sie komus nie podobac. Nikogo nie mam zamiaru zmuszac do prac nad nia czy do uzywania tego wynalazku. Ciesze sie natomiast niezmiernie, ze wlasciciele wybranej czesci PLDowej infrastruktury raczyli mi uzyczyc zasobow na ten cel bo dzieki temu projekt bedzie publicznie dostepny. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ti] (no subject)
> A o tym, że to miało lądować w dists > to ja nie pamiętam, żeby była jakaś wzmianka - correct me if i'm > wrong. Nie bylo wzmianki. Pojawil sie za to katalog ti w dists. Zalozyl go na moja prosbe arekm. Moze jednak faktycznie powinien on razem z innymi okolo PLDowymi projektami wyladowac w jakims osobnym katalogu. Tak po prawdzie to na pewno tam wyladuje, kwestia tylko nazwy. Poki co stanelo na "branches". M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ti] (no subject)
> Że zależność pomiędzy ac, ti i th jest niejasna? A to akurat fakt. Więc imho > najlepszym rozwiązaniem jest zrobić jakiś podkatalog na ftpie, nazwać go, nie > wiem 'non-mainline', czy coś w ten deseń ('branches'? ktoś ma lepsze > propozycje?). Tam lądowałoby wszystko, co jest pld, ale nie jest tym > oficjalnym numerkowanym pld (czyli tam wylądowałoby dawne dc, obecne ti, > rescue, live, czy kto tam jeszcze co wydłubie). > > Hawk, komentarze? Dla mnie jest obojetne gdzie Ti bedzie lezec. Mozna faktycznie by zgrupowac wszystkie "inne" PLD w osobnym katalogu na ftp. "non-mainlaine" jakos do mnie nie przemawia :) Jak juz to jestem za "branches" chyba, ze ktos wymysli cos ciekawszego. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Buildery AC - co z nimi jest? Prognozy dot. AC 2.1.
> Wyglada na to, ze przyjdzie ci poczekac na Ti. Moze niedlugo... Buildery juz sa. Jeszcze tylko jeden drobiazg wstrzymuje mnie przed rozpoczeciem "mielenia". M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Fwd: ERRORS: mozilla-firefox.spec
> The old amd64 builder is not running. Builder account on previous > machine is empty. At least I was told so. We have third amd64 builder? :) I'll answer myself. Yes, we may have third builder. The very old one in old jajcus workplace. However I can't check if its there. Machine is up but ssh is either not running or firewalled. Jajcus, any chances that this theory is true? M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Fwd: ERRORS: mozilla-firefox.spec
> hey > > please bring down this secondary *outdated* ac-amd64 builder whoever put it > online or *fix* it! The old amd64 builder is not running. Builder account on previous machine is empty. At least I was told so. We have third amd64 builder? :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Postfix 2.2.11
> bo jeśli już to właśnie zrobię update do wersji 2.3.x w AC. Glowy nie dam, ale czy nie chodzilo o to, ze w 2.3 byly zmiany w konfiguracji tudziez funkcjonalnosci, co spowodowalo by nie dzialanie lub bledne dzialanie tej wersji na konfigach od wersji 2.2? Pamietaj, aby to sprawdzic :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Kernel 2.6.16.52-1 a Kernel 2.6.22.2 i problemy z r8169
> Posiadam laptopa z kartą sieciową rozpoznawaną jako realtek 8168. Realtek 8168 jest obslugiwany przez modul r8169 bodajze od kernela 2.6.19. Na wczesniejszych kernelach musisz uzyc modulu r1000 (kernel-net-r1000.spec). Od razu dodam jednak, ze na wersji 1.05 tego modulu i dystrybucyjnym jajku ta karta w ogole nie dzialala. Na wersji 1.04 dzialala za to bardzo stabilnie. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Buildery AC - co z nimi jest? Prognozy dot. AC 2.1.
> Od kiedy można znowu do Th ładować niestabilne wersje programów? Mozna czy nie mozna, takie rzeczy tam sa i nie znikaja. Z tego co widze po kojece builderow jak i po listach Th ciagle cierpi na przypadlosci wczesnej fazy rozwoju. Wiekszosc developerow traktuje Th jak poligon (ja nie ukrywajac tez) gdzie mozna sobie poslac na builder praktycznie cokolwiek, nie dbac o dobudowywanie zaleznosci, wprowadzac drastyczne tudziez innowacyjne zmiany... Wybacz, nie mozna czegos takiego nazwac stabilnym. Dla mnie stabilnosc nie mierzy sie dniami uptime'u tylko iloscia problemow/bledow/awarii wynikajacych z dystrybucji, a nie z moich dzialan oraz czasem/brakiem reakcji na nie. Mierzac ta miara Th osiagnie obecna stabilnosc Ac moze za dwa lata. Bo poki co miast stabilizacji Th jest nadal pogonia za cyferkami i nowinkami. A czemu tak jest? Bo inaczej ludzie straca zainteresowanie i nikt przy Th nie bedzie chcial juz pracowac bo mu na tym najnowszy beryl nie ruszy itp. To zas w prostej linii doprowadzilo by Th do tego samego stanu jaki kiedys osiagnelo Ra i jaki obecnie osiaga Ac - brak aktualizacji oraz brak zainteresowania ta linia ze strony szerszego grona developerow. O "PLD zawsze w rozwoju" i dwoch liniach stabilnej oraz "robta co chceta" nie bede po raz n-ty pisal. Nie chce mi sie po prostu. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Buildery AC - co z nimi jest? Prognozy dot. AC 2.1.
> U mnie ciągle jest konto starego buildera ac-amd64 (ten który kiedyś > wypadł) i awaryjnie mogę udostępnić te zasoby ponownie - z resztą > chyba ciągle macie dostęp. > Maszyna lubi złapać load tak kolo 2-4 w szczycie, ale w nocy mielić by > mieliła na pewno dobrze. A ten builder nie dziala aby? Bo mialem zgloszenie iz sa dwa buildery ac-amd64 online, i ze oba miela paczki. Jak bedzie potrzeba to bede pamietal. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: upgrade postfix'a i zależności
> poldka miałem: > > [EMAIL PROTECTED] poldek]# rpm -qa|grep poldek > poldek-0.21-0.20070703.00.2 > poldek-libs-0.21-0.20070703.00.2 Do Ac nigdy taki nie trafil. Jakis snapshopt wersji 0.21 byl przez krotka chwile w ready, ale zawieral zbyt wiele bledow i zostal wycofany. > Jeśli chodzi o dopisanie ignore... to raczej obejście problemu prawda ? Owszem. Problem jest glebszy i byl chyba poruszany na listach. Na inne rozwiazanie nie ma co liczyc poki co. Po szczegoly odsylam do archiwum. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Buildery AC - co z nimi jest? Prognozy dot. AC 2.1.
> O ile wiem buildery powinny juz wrocic do stanu funkcjonowania. > Tyle, ze niestety padl nam totalnie jeden z serwerow i w kazdej chwili moze > byc potrzebna maszyna na ktorej buildery chodza. A wtedy buildery pa-pa. Au. Zle wiesci. > Sa jakies propozycje nowych lokalizacji? rhea.pld-linux.org dla x86 i oberon dla athlona? amd64 tez mozna by przeniesc na oberona. Tam mialy byc buildery dla wersji 2.1. No chyba, ze arekm sie nie zgodzi :) W razie czego poprosze o tarballe z istniejacymi builderami. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: upgrade postfix'a i zależności
> mogę sie dowiedzieć jakie są przyczyny tego, że od dłuższego czasu w AC > utrzymuje się taki stan: Bylo juz chyba z kilkanascie razy na listach. Blad jest poprawiony od ponad 3 tygodni. Uaktualnij najpierw poldka, a potem rob upgrade i powinno byc OK. Albo recznie dopisz w konfiguracji poldka w zrodle ac: ignore = msmtp-sendmail* M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Buildery AC - co z nimi jest? Prognozy dot. AC 2.1.
> Chciałem się zapytać dlaczego od ponad 3 tygodni buildery AC (i386-i686 > i ac-athlon) nie działają? O ile wiem awaria sieci na PG. Ankry probowal interweniowac, ale ze sezon ogorkowy to nikogo wladnego nie zlapal. Mam jednak cicha nadzieje, ze po weekendzie buildery rusza i jak wroce z urlopu za tydzien to juz bedzie mozna cos dzialac. > Drugie moje pytanie dotyczy planów wydania AC 2.1. Nie bedzie czegos takiego jak Ac 2.1. Jezeli juz bedzie to PLD 2.1 Ti jak kiedys wspominalem. Ac to 2.0 i przewidywany EOL tej linii to poczatek roku 2008 (z braku chetnych do utrzymywania). > Swego czasu release > manager od AC mówił, że nie dopuści do zapuszczenia tego wydania i > zamierza uaktualnić bazę programów do nowszych wersji. Release manager sam jeden nie uciagnie calej dystrybucji, a chetnych do (jakichkolwiek) uaktualnien na AC-branch mozna policzyc na palcach rak. Ja nikogo do pracy zmuszal nie bede, a sam w pierwszej kolejnosci robie to co mi jest potrzebne. Uprawnienia do budowania paczek ma oprocz mnie 14 osob. Uprawnienia do przenoszenia paczek ma oprocz mnie jedna osoba. O ilosci uprawnionych do robienia uaktualnien na AC-branch nawet nie wspominam (hint: CVSROOT/users). > Czy już coś wiadomo na ten temat? Jaki kernel będzie obrany za defaultowy w > 2.1? Wersja 2.1 (Ti) jeszcze nie ruszyla bo: 1) mialem -ENOTIME na postawienie builderow 2) glen chial pomoc przy stawianiu builderow, ale polegl 3) w miedzyczasie wyszlo stabilne gcc 4.2 i zaczal sie sezon urlopowy 4) poniewaz glibc, gcc, xorg mialy by byc w tych samych wersjach co w Th zaczalem sie zastanawiac nad sensem calego pomyslu (Ti od Th roznilo by sie tylko tym, ze w Ti tak jak w Ac byly by zabronione wersje alfa/beta/RC itp, z drobnymi wyjatkami oczywiscie) Kernel byl by "im nowszy tym lepiej". Linie Ti chcial bym utrzymywac w ciaglym rozwoju wliczajac w to nawet drastyczne upgrade'y ze snapshotami co jakis czas. Warunkiem oczywiscie byla by odpowiednia ilosc zainteresowanych do pracy przy PLD 2.1. Sadzac po Ac uwazam, ze tu byl by najwiekszy problem. To tez powoduje, ze zastanawiam sie nad sensownoscia calego pomyslu. Poki co wersja 2.1 wisi w martwym punkcie, a ja znow co jakis czas mysle o forku we wlasna robiona na wlasne potrzeby mini wersje PLD. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: VMware
> Problem w tym (jak już wspomniałem), że wydali wersję 6.0 i nie bardzo mogę > znaleźć na ich stronce archiwum z progamem. Jest tylko wersja 6.0. Chyba, że > ślepy jestem w takim razie proszę o nakierowanie;) http://www.vmware.com/download/ws/ws5.html trafiasz tam przez Downloads -> VMware workstation -> Download -> Workstation Archive Page M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: VMware
> Eeee... to jakim cudem ja cały czas działam na vmware-server? Jak zainstalujesz recznie z oryginalnego tarballa to dziala, bo uzywa bibliotek i perla/modulow perlowych przychodzacych w tym tarballu czyli tych z ktorymi bylo to kompilowane. Mi chodzilo o wersje ze speca. Ona uzywa PLDowych bibliotek i jest zonk. Ktos co prawda twierdzil kiedys, ze udalo mu sie przerobic speca tak aby wszystko dzialalo, ale na maila z prosba o przeslanie owego poprawionego speca odpowiedzi juz nie otrzymalem. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: VMware
> Jaki jest stan VMware teraz? Generalnie interesuje mnie VMware-workstation > lub > VMware-server na AC. Jak nie działa i działać nie będzie ani jedno ani drugie > na AC to czy działa to chociaż na TH (może się wtedy skuszę do przesiadki;))? Wersja 5.x dziala na Ac od wiekow, na Th nie wiem. Wersja 6.x na Ac nie bedzie dzialac - za stary glibc. Na Th jw. VMware-server nie bedzie dzialal. Problem lezy w perlowych badziewiach. Na PLDowym perlu nie dzialaja, na zalaczonych perlowych bibliotekach bledy znikaja i odpala sie konsola, ale na tym dzialanie sie konczy. > Co do VMware-server to ktoś kiedyś napisał, ze odpalił to na AC ale chyba > zapomniał sie w końcu podzielić łatką:D :( Nie trzeba zadnej latki. Wystarczy zbudowac z CVS pod swoj kernel i zainstalowac z --nodeps (z powodu libsexy) oraz zrobic symlink co by VMware myslalem, ze ma starsza wersje libsexy. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: slaby transfer na sambie
> co moze byc przyczyna tego ze transfer po ftp miedzy dwoma maszynami jest na > poziomie 9,5MB/s, a po smb tylko 3MB/s. Montujesz jako smbfs? Jezeli tak przejdz na cifs. U mnie swego czasu dalo sporego kopa. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: rpm bug?
> not sure how to put this in proper words, but querying binheader results > this, > one should query srcheaders. Anyone brave enough to make requried changes into builder script? :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rpm bug?
Hello. I'm not good in uderstanding how rpm internally works so don't blam me if I'm writing obvious things :) I think I've found bug in .spec processing. I'll show that on example. Our builder script is using following command to get package name and version for auto- CVS tag: rpmbuild --macros /usr/lib/rpm/macros:/usr/lib/rpm/i686-linux/macros:/etc/rpm/macros.*:/etc/rpm/macros:/etc/rpm/i686-linux/macros:~/etc/.rpmmacros:~/.rpmmacros:/home/users/krol/.builder-rpmmacros --nodigest --nosignature --nobuild --define 'prep %{echo:dummy: PACKAGE_NAME %{name} }%dump' --nodeps mozilla-firefox.spec Main package in mozilla-firefox.spec has version 2.0.0.5 however above command returns PACKAGE_VERSION = 0.8.4.0 which is version of mozilla-firefox-tidy subpackage. Since it is last subpackage defined in spec it seems like rpm just take last "Version: something" as package version instead of using version of main package. Maybe this is feature required for something else to work, I don't know. For me its a bug which should be nailed :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Problemy z POSTIXEM i saslem - PILNE
> Skonfigurowalem serwer wg opisu na stronie pl.docs... wszystko ladnie > dzialalo. Dzisiaj aktualizowalem serwer. Przy aktualizacji amavisd-new > dorzucilo Sprawdz czy masz msmtp zainstalowane. Jezeli tak to wywal z --nodeps, sciagnij poldkiem lub recznie postfixa (ale nie instaluj) i zainstaluj go recznie uzywajac rpm. Byly bledy w zalelznosciach, ktore przy kazdym upgrade serwerow smtp wciskaly na sile msmtp przez co sie poczta calkiem wywalala. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: SPECS: sendmail.spec, postfix.spec, courier.spec, exim.spec, msmtp...
> Author: arekmDate: Fri Jul 13 20:37:39 2007 GMT > Module: SPECS Tag: HEAD > Log message: > - don't provide /usr/lib/sendmail. It's already provides; see rpm -q > --fileprovide. Niby tak: # rpm -qf /usr/lib/sendmail postfix-2.2.5-12 Ale ten problem pasowalo by jakos rozwiazac: # poldek -tU --force postfix Loading [pdir]ac... Loading [pdir]ac-updates... Loading [pdir]ac-supported... Loading [pdir]ac-ready... 16425 packages read Removed 41 duplicate packages from available set warn: postfix: ambiguous name Processing dependencies... postfix-2.2.5-12 obsoleted by postfix-2.2.5-12 orphaned amavisd-new-2.4.5-2 marks msmtp-sendmail-1.4.10-1 (cap /usr/lib/sendmail) msmtp-sendmail-1.4.10-1 marks msmtp-1.4.10-1 (cap msmtp = 1.4.10-1) There are 3 packages to install (2 marked by dependencies), 1 to uninstall: I postfix-2.2.5-12 D msmtp-1.4.10-1, msmtp-sendmail-1.4.10-1 R postfix-2.2.5-12 Need to get 1.4MB of archives (1.4MB to download). After unpacking 3.5MB will be used. Dawniej to nie wystepowalo. Wszystkie maszyny gdzie jest amavis i postfix tudziez inny MTA stana sie po najblizszym upgrade tegoz MTA nieuzywalne. Zaznaczam od razu ze bez --force jak i przy --upgrade-dist jest to samo. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Nowy postfix i problemy
> AC, postfix 2.2.5-12. > > Przy instalacji : > > 'osierocony' amavisd-new-2.4.5-2 zaznaczył msmtp-sendmail-1.4.10-1 > (wł. /usr/lib/sendmail) msmtp-sendmail-1.4.10-1 zaznaczył > msmtp-1.4.10-1 (wł. msmtp = 1.4.10-1) > > Czyli - z postfixa wyleciał link /usr/lib/sendmail. Mialem to samo po --upgrade-dist ponad tydzien temu, a wiec przed postfixem 2.2.5-12. Winny jest poldek, ktory szukajac co dostarcza /usr/sbin/sendmail wpakowal mi do systemu msmtp pomimo, ze byl juz zainstalowany postfix nadpisujac pliki tegoz. Odinstalowanie msmtp i poldek -U --force postfix rozwiazalo problem. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
geninitrd a raid5
Hello. Nasz geninitrd wymieka gdy root jest na programowym raid5. Stwierdza, ze nie ma modulu raid5. I slusznie, bo nie ma takiego, to jest tylko alias do modulu raid456. Majac taki system mozna latwo wyedytowac geninitrd zeby sobie poradzil, ale przydalo by sie jakies koszerne rozwiazanie, ktore bedzie dzialalo zarowno ze starszymi kernelami (modul raid5) jak i nowszymi (modul raid456 i alias raid5). Ma ktos pomysl na taka poprawke? M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Ac poldek indexes are now fixed
EN: Correction. Full indexes of ac-updates for i686 have been recovered. PL: Poprawka. Pelne indeksy ac-updates dla i686 zostaly odtworzone. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Ac poldek indexes are now fixed
EN: Correction. Full indexes of ac-updates for i686 have been recovered. PL: Poprawka. Pelne indeksy ac-updates dla i686 zostaly odtworzone. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Ac poldek indexes are now fixed
EN: Short backstory: between June 18th and June 21st all Ac poldek indexes for following trees: updates, supported, ready and test were deleted (instead of being updated) and regenerated from scratch using snapshot of poldek 0.21. Unfortunately these new indexes were somehow broken because both stable and snapshot poldek were occasionally throwing "floating point exception" when using them. Today all indexes were deleted again and regenerated from scratch using stable version of poldek. Since we have no backups of our ftp and all mirrors are syncing to often to serve as ones we lost all incremental diffs for all architectures. The only exception is i686: ac-updates indexes for i686 were partially recovered, following diffs were lost: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz so if you were updating your indexes on or after June 12th you must do poldek --upa now. ac-supported indexes for i686 were completly recovered. Sorry for any inconvenience this situation may cause. PL: Krotka historia: w dniach miedzy 18 a 21 czerwca wszystkie indeksy poldka dla drzewek Ac: updates, supported, ready, test zostaly usuniete (zamiast uaktualnione) i przegenerowane od zera z uzyciem snaphsotu poldka 0.21. Niestety nowe indeksy wygladaly na uszkodzone poniewaz zarowno stabilny poldek jak i snapshot okazyjnie rzucaly na ekran bledem operacji zmiennoprzecinkowych w czasie korzystania z indeksow. Dzis wszystkie indeksy zostaly ponownie usuniete i przegenerowane od zera z uzyciem stabilnej wersji poldka. Poniewaz nie ftp nie jest backupowany, a mirrory synchronizuja sie zbyt czesto aby robic za backup stracilismy wszystkie inkrementowane diffy dla wszystkich architektur. Wyjatkiem jest i686: Indeksy ac-updates dla i686 udalo sie czesciowo odtworzyc. Stracone zostaly tylko diffy: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz tak wiec jezeli ktos uaktualnia indeksy 12 czerwca lub pozniej musi zrobic poldek --upa. Indesky ac-supported dla i686 zostaly odzyskane w calosci. Przepraszam za wszelkie niedogodnosci jakie moga wynikac z tej sytuacji. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Ac poldek indexes are now fixed
EN: Short backstory: between June 18th and June 21st all Ac poldek indexes for following trees: updates, supported, ready and test were deleted (instead of being updated) and regenerated from scratch using snapshot of poldek 0.21. Unfortunately these new indexes were somehow broken because both stable and snapshot poldek were occasionally throwing "floating point exception" when using them. Today all indexes were deleted again and regenerated from scratch using stable version of poldek. Since we have no backups of our ftp and all mirrors are syncing to often to serve as ones we lost all incremental diffs for all architectures. The only exception is i686: ac-updates indexes for i686 were partially recovered, following diffs were lost: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz so if you were updating your indexes on or after June 12th you must do poldek --upa now. ac-supported indexes for i686 were completly recovered. Sorry for any inconvenience this situation may cause. PL: Krotka historia: w dniach miedzy 18 a 21 czerwca wszystkie indeksy poldka dla drzewek Ac: updates, supported, ready, test zostaly usuniete (zamiast uaktualnione) i przegenerowane od zera z uzyciem snaphsotu poldka 0.21. Niestety nowe indeksy wygladaly na uszkodzone poniewaz zarowno stabilny poldek jak i snapshot okazyjnie rzucaly na ekran bledem operacji zmiennoprzecinkowych w czasie korzystania z indeksow. Dzis wszystkie indeksy zostaly ponownie usuniete i przegenerowane od zera z uzyciem stabilnej wersji poldka. Poniewaz nie ftp nie jest backupowany, a mirrory synchronizuja sie zbyt czesto aby robic za backup stracilismy wszystkie inkrementowane diffy dla wszystkich architektur. Wyjatkiem jest i686: Indeksy ac-updates dla i686 udalo sie czesciowo odtworzyc. Stracone zostaly tylko diffy: packages.ndir.dscr.i18n.2007.06.16-20.39.12.gz packages.ndir.dscr.i18n.2007.06.14-23.55.56.gz packages.ndir.dscr.i18n.2007.06.14-13.51.54.gz packages.ndir.dscr.i18n.2007.06.13-23.11.13.gz packages.ndir.dscr.i18n.2007.06.12-12.24.47.gz tak wiec jezeli ktos uaktualnia indeksy 12 czerwca lub pozniej musi zrobic poldek --upa. Indesky ac-supported dla i686 zostaly odzyskane w calosci. Przepraszam za wszelkie niedogodnosci jakie moga wynikac z tej sytuacji. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [update] Looking for full mirror of PLD 2.0!
> LOL 3,5MB ściąga się na modemie całe dwanaście minut, Prawie pietnascie trwalo. Kwadrans siedzenia i patrzenia w sufit, podczas gdy za owe 15 minut mogl bym byc u kolejnego klienta. Po 4 klientach z podobnymi instalacjami jestes godzine w plecy. A co jak masz ich wiecej? Czasami czas jest wazny. Do domu lubie wracac przed polnoca. > co chciałbyś > aktualizować w systemie jeśli nie możesz poczekać na ściągnięcie > indeksów? Jak masz upgrade sprawdzony w srodowisku testowym to mozesz go puscic i wyjsc. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [update] Looking for full mirror of PLD 2.0!
> Ale co to za problem wygenerować indeksy od nowa? Indeksy wlasnie zostaly wygenerowane od nowa (a stare skasowane) i diffy za prawie 4 miesiace poszly w kosmos. Nie mam zamiaru w lokacjach z modemem, ktorymi sie opiekuje siedziec i czekac az 3.5 MB splynie bo komus sie zachcialo testowac snapshoty poldka. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[update] Looking for full mirror of PLD 2.0!
EN: ac-supported indexes got smoked too :( ac-updates i686 will be soon restored to state from June 13th. If you wasn't updating your poldek indexes after that day you are lucky. Other people will need to do --upa. If you had bad luck and updated your indexes today or yesterday you have to do --upa for second time. My apologies for that. I'm still searching for other indexes. PL: Indeksy ac-supported tez poszly w kosmos :( Indeksy ac-updates dla i686 beda niebawem odtworzone do stanu z 13 czerwca. Jezeli nie uaktualniales swoich lokalnych indeksow poldka po tej dacie masz szczescie. Pozostale osoby beda musialy zrobic --upa. Jezeli masz pecha byc wsrod osob, ktore uaktualnialy swoje indeksy dzis lub wczoraj bedziesz musial zrobic --upa po raz drugi. Przepraszam za problemy. Ciagle poszukuje pozostalych indeksow. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[update] Looking for full mirror of PLD 2.0!
EN: ac-supported indexes got smoked too :( ac-updates i686 will be soon restored to state from June 13th. If you wasn't updating your poldek indexes after that day you are lucky. Other people will need to do --upa. If you had bad luck and updated your indexes today or yesterday you have to do --upa for second time. My apologies for that. I'm still searching for other indexes. PL: Indeksy ac-supported tez poszly w kosmos :( Indeksy ac-updates dla i686 beda niebawem odtworzone do stanu z 13 czerwca. Jezeli nie uaktualniales swoich lokalnych indeksow poldka po tej dacie masz szczescie. Pozostale osoby beda musialy zrobic --upa. Jezeli masz pecha byc wsrod osob, ktore uaktualnialy swoje indeksy dzis lub wczoraj bedziesz musial zrobic --upa po raz drugi. Przepraszam za problemy. Ciagle poszukuje pozostalych indeksow. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Looking for full mirror of PLD 2.0!
EN: Hello, I'm looking for full mirror of PLD 2.0 which wasn't updated after June 20th. I need to restore ac-updates indexes (the were deleted). If any one has such mirror (official ones have already resynced) please disable its synchronization and mail me ASAP. P.S. Partial mirrors are welcome too. Maybe I'll collect all indexes that way. PL: Witam, Poszukuje pelnego mirrora PLD 2.0, ktory nie byl aktualizowany po 20 czerwca. Potrzebuje odtworzyc indexy ac-updates (zostaly usuniete). Jezeli ktos posiada taki mirror (oficjalne niestety sie juz zsynchronizowaly) prosze o wylaczenie jego synchronizacji i jak najszybszy kontakt mailowy ze mna. P.S. Czesciowe mirrory tez mile widziane. Moze w ten sposob zbiore wszystkie indeksy. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Looking for full mirror of PLD 2.0!
EN: Hello, I'm looking for full mirror of PLD 2.0 which wasn't updated after June 20th. I need to restore ac-updates indexes (the were deleted). If any one has such mirror (official ones have already resynced) please disable its synchronization and mail me ASAP. P.S. Partial mirrors are welcome too. Maybe I'll collect all indexes that way. PL: Witam, Poszukuje pelnego mirrora PLD 2.0, ktory nie byl aktualizowany po 20 czerwca. Potrzebuje odtworzyc indexy ac-updates (zostaly usuniete). Jezeli ktos posiada taki mirror (oficjalne niestety sie juz zsynchronizowaly) prosze o wylaczenie jego synchronizacji i jak najszybszy kontakt mailowy ze mna. P.S. Czesciowe mirrory tez mile widziane. Moze w ten sposob zbiore wszystkie indeksy. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: PRO/1000 PT Quad Port Server Adapter by Intel
> Powiadasz, że karty Pro/1000 PT masz od paru lat? A wydawało mi się, że > niecały rok są na rynku :) Ups! Nie poppatrzylem na model :) Moje to MT, stary sprzet w sumie :) M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: PRO/1000 PT Quad Port Server Adapter by Intel
> mam problem z kartą czteroportową intela ibmie x3250 - w sumie jest > sześć portów eth dwa wbudowane działają, cztery dodatkowe nie. moduły są > załadowane, odpowiednie aliasy(tg3 i e1000) w modules.conf również. > jądro 2.6.16.52-1smp. append="pci-routeirq" w lilo.conf nie pomogło. Co mowia logi (przy ladowaniu modulu i potem przy podnoszeniu interfejsu)? Co masz w plikach konfiguracyjnych tych interfejsow? Mam kilka takich kart i wszystkie od dobrych paru lat dzialaja prawidlowo. Uzywalem ich jak jeszcze nie bylo sterownika e1000 w jajku. Aha. Zawsze mozesz uzyc oryginalnego intelowego sterownika. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Niekompatybilności BINDa 9.4
> 8.2 łykał - miałem takie nazwy w plikach stref i nie było problemu - a > na pewno nie odrzucał całego pliku strefy, odpowiadając SERVFAIL na > wszystkie zapytania tej strefy dotyczące. 8.2 to byl w Ra :) 9.2 z takimi nazwami w strefie w ogole nie startowal. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: SOURCES (AC-branch): poldek-ignorecaps.patch - update to poldek-0....
> where should i commit it then? it's USABLE for AC, as it fixes (hopefully > when > more tested) long-lasting pain on multiarch, making total pita upgrading > packages on those arches. Snapshots have bad habbit of making things not working :/ As I see it few threads above those snapshots still contain lots of bugs. Since these snapshot shouldn't go to ready until 99% sure that all known issues were fixed they should be IMO put on devel. If we will need for example poldek rebuild in few days we will be blocked :/ M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES (AC-branch): poldek-ignorecaps.patch - update to poldek-0....
> Author: glen Date: Tue Jun 19 11:12:32 2007 GMT > Module: SOURCES Tag: AC-branch > Log message: > - update to poldek-0.20.1-cvs20070618.11 Snapshot on AC-branch? I hope you've good reasons like security fixes :) M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: postfix, deferred z poczta.onet.pl
> Jun 17 21:30:06 serwer postfix/smtp[14606]: 662C45FC8A: > to=<[EMAIL PROTECTED]>, relay=mx.poczta.onet.pl[213.180.130.86], delay=5, > status=deferred (host mx.poczta.onet.pl[213.180.130.86] said: 450 4.7.1 W > chwili obecnej nie mozesz wyslac listu do: <[EMAIL PROTECTED]>, sprobuj > za chwile [0400.-1] / At the moment you cannot send a message to > <[EMAIL PROTECTED]>, try again later [0400.-1] (in reply to RCPT TO > command)) To normalne w przypadku onetu. > po czym postfix zwraca to do nadawcy i zakancza sprawe (nie probuje > ponownie). To juz nie jest normlane. Moj postfix ladnie trzyma w kolejce i probuje wysylac co wskazany czas. Zobacz postconfem jakie masz ustawienia dotyczace ponawiania wysylki i czasu trzymania maili w kolejce w przypadku niemoznosci ich dostarczenia. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ...
> "vanilla" means "unmodified". And you are changing that kernel. Doesn't > matter if it's cosmetics or not. No matter if it's patch or sed. Yes. I know all that. By my previous mail I was trying to say: "then it was never vanilla kernel" as sed was used to modify makefile since the first revision. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ...
> But it's not vanila now :D How about replacing with sed instead of using patch? :) sed was used on makefiles anyway (for extraversion). M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (AC-branch): kernel-vanilla.spec - fix for PPC failing when ...
>> +# build fix for intel network drivers for PPC >> +Patch0: linux-2.6-ppc-ICE-hacks.patch > > It's not vanilla now ;P Yeah, true, but vanilla doesn't build on PPC :( M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: samba.spec - nie buduje się na AC
> Poprawka - budowane z: > --without ads,krb5,ldap,cups,python Hm. Może jakiś brakujący BR? Bo: [EMAIL PROTECTED] SPECS]$ ./builder -r AC-branch samba.spec --without ads,krb5,ldap,cups,python ... Checking for unpackaged file(s): /usr/lib/rpm/check-files /tmp/samba-3.0.25a-root-hawk warning: Installed (but unpackaged) file(s) found: /usr/bin/smbspool /usr/share/man/man8/smbspool.8.gz /usr/share/man/man8/vfs_cacheprime.8.gz /usr/share/man/man8/vfs_catia.8.gz /usr/share/man/man8/vfs_commit.8.gz /usr/share/man/man8/vfs_extd_audit.8.gz /usr/share/man/man8/vfs_full_audit.8.gz /usr/share/man/man8/vfs_gpfs.8.gz /usr/share/man/man8/vfs_notify_fam.8.gz /usr/share/man/man8/vfs_prealloc.8.gz Wrote: /home/users/hawk/rpm/SRPMS/samba-3.0.25a-0.1.src.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-swat-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-client-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-common-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-winbind-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/nss_wins-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/pam-pam_smbpass-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/libsmbclient-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/libsmbclient-devel-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/libsmbclient-static-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-devel-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/smbget-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-audit-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-cap-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-default_quota-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-expand_msdfs-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-fake_perms-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-netatalk-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-recycle-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-readahead-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-readonly-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-shadow_copy-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-antivir-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-clamav-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-fprot-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-fsav-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-kavp-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-mcafee-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-mks-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-openantivirus-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-sophos-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-symantec-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-vfs-vscan-trend-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-doc-html-3.0.25a-0.1.i686.rpm Wrote: /home/users/hawk/rpm/RPMS/samba-doc-pdf-3.0.25a-0.1.i686.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.54560 + umask 022 + cd /home/users/hawk/rpm/BUILD + cd samba-3.0.25a + rm -rf /tmp/samba-3.0.25a-root-hawk + exit 0 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: samba.spec - nie buduje się na AC
> collect2: ld returned 1 exit status > make: *** [smbwrapper.so] Error 1 > błąd: Błędny status wyjścia z /var/tmp/rpm-tmp.81128 (%build) smbwrapper zostal wyrzucony z samby i wpakowany do examples. Mialem zamiar go calkowicie wywalic ze speca, ale powstrzymalo mnie, ze rzekomo jest potrzebny (a przynajmniej jego pliki naglowkowe) do zbudowania samba-pdbsql. Nie wiem czy tak jest czy nie, wiec na wszelki wypadek go zostawilem. Swoja droga smbsh nie byl paczkowany w ostatnim wydaniu samby dla Ac. Nie wiem jak w poprzednim, nie chcialo mi sie sprawdzac. Moze faktycznie trzeba go wywalic skoro stwarza problemy. Poza tym spec ma rel 0.1 :) Jest o krok blizej do spaczkowania wersji 3.0.25a. Swoja droga to wesja 3.0.25 wyszla rowno miesiac temu i chociaz poprawiala IMO raczej powazne bledy security nikt nie kwapil sie do jej spaczkowania. Smutne to, ale zaczynamy sie zblizac do Microsoftu jezeli chodzi o czas reakcji na bledy :-( Co do speca to z domyslnymi bcondami buduje sie i jak narazie u mnie dziala. Puszczene tego ASAP do update'ow jest dla mnie wazniejsze niz sprawdzanie budowania z kazda mozliwa konfiguracja bcondow. Proponuje dodac do TODO, moze ktos w wolnej chwili zrobi. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Zlot PLD 2007
> Klamka zapadla 7-8 lipca, Warszawa Ble. Nie dosc, ze w czasie urlopu to kaawal drogi :/ Zrobcie zlot w Krakowie. Akurat powinienem tam byc albo 7-go albo 8-go :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (AC-branch): kernel-vanilla.spec - updated to 2.6.21.4
>> Author: hawk Date: Sat Jun 9 07:39:17 2007 GMT >> Module: SPECS Tag: AC-branch >> Log message: >> - updated to 2.6.21.4 >> >> Files affected: >> SPECS: >>kernel-vanilla.spec (1.43.2.4 -> 1.43.2.5) > > errr?? > > why updating AC-branch? > > why not follow kernel.spec/mysql.spec schema that you update branch > (LINUX_2_6 / LINUX_2_6_21) and later just move AC-branch tag? Because shadzik was about to port HEAD to news-style macros. I don't know if he did it or not, I'm not checking HEAD. M. 1.42 Sun Mar 25 0:31:18 2007 by shadzik - linux-2.6.20.4 - it's still old-style, till now I will try to adapt it to new-style macros so it's rather your last chance to build this on AC ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: bind.spec - remove Obsoletes:nameserver
> Znając tyle przypadków, podejrzewam, że może być ich sporo więcej. > Dlatego uważam, że w PLD zasadą powinno być umożliwienie instalowania > wielu różnych serwerów tych samych usług. Nie ważne, że w domyślnej > konfiguracji wszystkie razem się nie uruchomią (chociażby problem > jednego portu TCP) -- od tego jest admin, żeby sobie to skonfigurować. > Niech mu tylko dystrybucja nie przeszkadza. +1 i dodatkowo rozdzielenie katalogow z konfiguracja, tylko prosze, nie taki burdel jak w debianie, ze wszystko jest bezposrednio w /etc, ale niech bedzie pogrupowane po rodzaju uslugi np /etc/mail/postfix, /etc/mail/sendmail itp. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Chyba zepuste uClibc na TH - lvm2 i device-mapper
> $ i486-uclibc-gcc -static -Os -g -o c c.c > $ gdb c > (gdb) r > Starting program: /home/areq/rpm/BUILD/c > > Program received signal SIGSEGV, Segmentation fault. > 0x in ?? () > (gdb) bt > #0 0x in ?? () > #1 0x08048377 in __uClibc_main () > #2 0x08048159 in _start () > (gdb) quit Dawno temu (dokladnie 2 lata, prawie co do dnia) mialem ten sam problem z uClibc 0.9.26 gdy do kompilacji uzywal on naglowkow kernela 2.6. Powrot do naglowkow 2.4 rozwiazal wtedy problem. Moze twoj uClibc cierpi na nowsza odmiane tego samego problemu? Upewnij sie, ze to nie problem linux-libc-headers np linkujac tymczasowo prawdziwe zrodla kernela czy to 2.4 czy 2.6 i kompilujac od nowa. Mnie juz kilka razy linux-libc-headers przyprawialo o bol glowy. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: RCD na TH - co się nie buduje
> Zabrałem się za przygotowanie RCD na TH. Uhm. Eee. A to obecne RCD nie bylo na Th? Moze pytam o rzeczy oczywiste (nigdy w zyciu nie uzywalem RCD to nie wiem), ale w obecnym RCD na pewno sa rzeczy niekompatybilne z Ac, vide nowszy kernel i wybikajace z niego "problemy" userow z dyskami hdX widocznymi jako sdX. Chyba, ze kernel byl jedyna roznica. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
> Masz radiatory na pamięciach w swoim PC? Tak. > No i dalej się będę upierał, że ilość powietrza tłoczonego > przez zestaw CPU/Pamięci jest dalece większa w serwerze niż w > najbardziej wypasionym PC :) To juz chyba wynika z ilosci i sily ciagow wentylatorow w zasilaczach serwerowych :) Stojac za kupka pecetow ulozonych jeden na drugim co najwyzej poczujesz lekki ruch powietrza. Stojac za szafa z serwerami wlosy Ci beda latac na wszystkie strony (chyba ze ktos jest ostrzyzony na jeza) :-) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
> To, że Tobie wydaje zimniejsza > może wynikać jedynie z faktu, że w desktopie nie masz sensownego obiegu > powietrza Blad. Obieg powietrza w desktopie mam z pewnoscia lepszy niz niektore low endowe serwery, a co najmniej porownywalny do sredniej klasy serwerow. Nie kazdy ma zwykle obudowy typu "mydelniczka". > serwer bez takowego dosyć szybko zakończyłby swój żywot, To rzecz oczywista. W koncu cos musi nadrabiac brak wentylatorow na prockach :) > Co z tego, że Intel ma teraz CPU o > niższym poborze mocy w porównaniu do AMD, skoro nadrabia to z nawiązką > właśnie na owych pamięciach i chipsecie. Nie jestem tu az takim specjalista. Czy cos sie bardziej grzeje czy nie oceniam na podstawie czujnikow temperatury lub "recznie" :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
> Wady serwerów > intelowskich to niesamowicie grzejąca się pamięć FB-DIMM Hm. W Dellach nie zauwazylem zbytniego nagrzewania sie pamieci. W porownaniu do DDR 2 w desktopach to pamieci z serwerkow sa zimniutkie. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
On 2007-05-28 20:27, Artur Flinta wrote: > Marcin Król wrote: >> temacie. Wychodzi na to, ze tylko Itanium jest prawidziwie 64-bitowym >> prockiem. >> Opteron podobnie jak AMD64 czy Pentium/Core2 to wszystko rozszerzenia badz > > Doprawdy? Alpha już nie jest? W domysle pisalem o prockach, ktore padly w dyskusji czyli Athlon64 (X2), Opteron, Itanium i intelowe z rozszerzeniami EMT64. Chyba przyznasz, ze zaden z nich nie jest alpha? > bez sensu ta cała dyskusja o wyższości jednego nad drugim. Dlatego w poprzednim mailu prosilem o zakonczenie watku. > bazy SQL czy też obliczenia wysokiej precyzji zyskiwały na migracji. Zgadza sie. Jak pisalem, czesc traci, czesc zyskuje. To jak? EOT? M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
> O ciekawe rzeczy prawisz :) Powiedz mi proszę czym się w takim razie > różni implementacja 64 bitów Opterona od tej z Athlona 64 i nowszych > Sempronów? Dobra. Zrewidowalem w googlach swoja przestarzala badz co badz wiedze w tym temacie. Wychodzi na to, ze tylko Itanium jest prawidziwie 64-bitowym prockiem. Opteron podobnie jak AMD64 czy Pentium/Core2 to wszystko rozszerzenia badz emulacja, ale ze to OT to skonczmy watek albo przejdzmy na inna liste. Hm. Chyba zadna sie nie nada :) Piszac maila mialem jedynie zamiar zorientowac sie czy Beron wie, iz tylko niektore programy czy aplikacje tudziez rodzaje obliczen skorzystaja z 64bitowych rozszerzen procka podczac gdy inne zamiast zyskac na wydajnosci to straca. Uprzedzajac pytanie, ktore zyskaja, a ktore straca odsylam do googla. Pelno tam benchmarkow 32bit vs 64bit poczawszy od gier, przed kodowanie i obrobke audio/wideo do baz SQLowych i tym podobnych. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac64] Stan
> Będę się właśnie przesiadał na maszynę 64bit i wolę wiedzieć co mnie czeka :) Z ciekawosci: chcesz przejsc na 64 bit z jakichs konkretnych powodow czy "ot tak, bo to 64 bit"? IMO na desktopie, ba, nawet na niektorych serwerach (zalezy od uslug) optymalizacja pod i686 da Ci minimalnie szybszy system niz ta pod amd64. No chyba, ze owa maszyna to bedzie prawdziwe 64 bit czyli AMD Opteron albo Intel Itanium. Inne procki to nadal 32 bity + rozszerzenia. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [AC] alsa a /dev/dsp
> załadowałem snd-pcm-oss i zadziałało, dźwięk w UT jest ale są dwa problemy: > większy - dźwięk w UT przerywa i jest to bardzo uciążliwe U mnie dzwiek kiedys rwal gdy mialem siec i dzwiekowke dzielaca to samo przerwanie. Podobna sytuacje spotkalem u znajomego gdy przerwanie bylo wspoldzielone z kontrolerem IDE. > mniejszy - jeśli z /dev/dsp korzysta np. UT to nic innego oprócz niego nie > może Twoja karta dzwiekowa nie wspiera miksowania sprzetowego. Jezeli uzywasz KDE wlacz serwer dzwieku. Powinno pomoc. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: ImageMagick
> 1. przerzucic cala do glownego pakietu > 2. wydzielic pakiet -doc > 3. poszatkowac rozdzielajac pomiedzy -devel a pakiet glowny >(chyba sie tego nie da zrobic porzadnie). > Ja sie sklaniam ku 1. > > Konstruktywne obiekcje? Owszem :) Pakiet -doc juz istnieje wiec nie ma sensu pchac dokumentacji do glownej paczki. IMO punkt 2 przemianowany na "dodac do pakietu -doc". M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: AC 2.0 & Opteron 2210 x 2 & Płyta Tyan n6650W & Dysk SAS
> Dodałem. > Wykrył ten ostatni procesor ale zatrzymał się przy następnym kroku: > > Brought up 4 CPUs > testing NMI watchdog ... OK. [i znów wisi] Tym razem sprobuj dodac nmi_watchdog=0 Jest w kernelowej bugzilli, ze niektore systemy nie wstaja gdy ta opcja jest wlaczona. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: SPECS: qt4.spec - up to 4.3.0beta - raw, without patches - NFY but...
>> Maszyna produkcyjna na PLD Th Initial Development ? Hu ha, miłej >> pracy. > -bash-3.2# uptime > 19:54:58 up 257 days, 10:50, 5 users, load average: 0.12, 0.12, 0.09 > więc nie widzę w tym nic śmiesznego. Hm. Tak sie zawsze zastanawialem, jak z uptime'u mozna wyczytac czy system dziala stabilnie? Uptime co najwyzej pokazuje, ze kernel i sprzet dzialaja stabilnie. Nie da sie z niego wyczytac czy _caly_ system dziala stabilnie, wiec uzywanie go w tym celu jest IMO bez sensu. Dobra, koncze bo OT :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [AC] X11-driver-nvidia.spec i kernel 2.6.20.7
> Właśnie zauważyłem hawk, że sobie tam poczyniasz :) Będziesz to jakoś > wg własnych możliwości uaktualniał na AC-branch? Tak. Uzywam na swoich workstacjach wiec co jakis czas bede odswiezal :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [AC] X11-driver-nvidia.spec i kernel 2.6.20.7
> :/ A który z serii 2.6.20 mogę sobie bez zbędnego kombinowania zbudować? kernel-vanilla.spec:AC-branch (2.6.21.1) albo mojego kernel.spec:hawk-LINUX_2_6 (2.6.20.7, tez prawie vanilla, ale masz bcondy grsec_full i vserver). M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: ftp2 kaput ?
> ftp2 kaput ? Niestety. Szkoda, bo dzis by byly juz isos na glownym ftp, a tak to trzeba jeszcze poczekac :( 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
> 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
> 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 Dla mnie oopsy wystepujace czesciej niz raz na rok sa nie do przyjecia :( Przez jakis czas bylo ok, teraz nie jest, wniosek: to musi byc ktorys z patchy. Ale mnie w sumie to nie interesuje bo i tak uzywam wlasnego builda. Innym widocznie nie przeszkadza (albo dziala) bo nie marudza :) > Ja bardzo polecam 2.6 Ja tez. Mam go prawie wszedzie. Ale nie ten :) 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
> 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
> "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
>> 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: straszne spowolnienia sieci
> Mam jajko 2.6.18.1-4 pld AC+AC-ready dosc aktualne. Takiego jajka w Ac nie ma i nie bylo :) > Dzis mnei tknelo i polozylem interfejs sieciowy podnioslem i nadalem > routing do bramy. > Jak reka odjal. > Nie sprawdzilem tylko jeszcze jednej sieciowki (mam dwie) czy na niej > tez laguje. Nie wiem czy dobrze Cie zrozumialem. Masz jakis linuxowy routerek i on Ci laguje, a jak ze swojego kompa wychodzisz bezposrednio na bramke (nie przez routerek) to lagi znikaja, tak? > ps. modul do karty to 8139too a ta nie sprawdzona to via-rhine. 1. Sprawdz poziom ruchu na tych sieciowkach. Obie sa bardzo niskich lotow i przy wiekszych transferach zaczynaja lagowac. Jezeli masz staly ruch powyzej 10 mbit to radzil bym sie rozgladnac za innymi kartami. Intela 100 kupisz za niecale 10 PLN, a wydajnoscia bije na glowe wszystkie realteki, via, sis i tym podobne badziewia. 2. Sprawdz komunikacje bezposrednio po numerach IP oraz responsywnosc DNS z ktorego korzystasz. Czesto bywa tak, ze net dziala szybko tylko DNS laguje, zwlaszcza jezeli uzywasz tepsianego lub podobnych. 3. Jakie masz urzadzenia sieciowe? Niektore bezfirmowe switche maja tak malutka wewnetrzna tablice arp ze przy 10+ klientach po prostu zaczynaja ciac ruch. 4. Jezeli switch Ci na to pozwala sprawdz konfiguracje dupleksu. Sieciowki potrafia baaardzo mulic gdy sa ustawione na full, a switch wymusza half lub odwrotnie. 5. Sprobuj inny kernel, np skompiluj vanilliowy i zobacz czy problem zniknie. 6. Jezeli masz inne sieciowki, switche, sprobuj podmienic na chwile. Jak przez to przebrniesz to albo znajdziesz przyczyne, albo bedziesz bardziej zorientowany w ktorym miejscu dalej drazyc. M. ___ pld-users-pl mailing list [EMAIL PROTECTED] http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: PowerDNS z MySQL i administracja
> Poza tym pdns to w miarę świeża produkcja i do niedawna nie potrafił > działać samodzielnie. Ponowie swoją tezę, że dla dużej ilości domen i > częstych zmian jest bardzo dobrym rozwiązaniem. Jak nie jednym z > najlepszych. Pdns mnie ostatnio zawiodl przy bardzo duzej ilosci zapytan (kilka tysiecy na minute). Choc bym nie wiem jak kombinowal z konfiguracja pdns w takim przypadku po prostu przestawal wyrabiac i dawal timeouty. Bind natomiast pod takim obciazeniem odpowiadal wolniej (duzo wolniej), ale caly czas odpowiadal. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Request for developers + info for mirror admins
> jak mniemam, chodzi głównie o bezproblemowy update z X11 na > xorg ? Mniej wiecej. Wspomnialem o jaki upgrade chodzi w innym mailu w tym watku. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Request for developers + info for mirror admins
> Zauważ, że to co w gcc4 wprowadzono to głównie middle i back-end. Na > poważną zmianę we front-endzie C++ poczekamy pewnie do 2009 roku > (jeśli się komitet wyrobi). Skoro jak sam piszesz nie bylo powaznych zmian, czemu nie wskoczyc w 4.1? Poza tym wez pod uwage, ze zakladany termin pol roku dla Ac 2.1 jest, jak by to ujac, _bardzo_ optymistyczny :) Wszyscy wiemy ile razy mialo wyjsc Ac i nic z tego nie wyszlo. Zalozmy, ze Ac 2.1 wyjdzie w polowie 2008 roku, a Th dajmy na to w polowie 2009. Czy jest sens wtedy tkwic w gcc 3.x? > Tylko dlaczego Ac a nie Th stable 1. ;) Th czeka na stabilne gcc 4.2, poza tym daleko mu do stabilnosci Ac. Odpowiadajac na pytanie: "kazdy RM sobie rzepke skrobie?" :) M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Request for developers + info for mirror admins
> To Th przecież :D > Czym się będzie różniło, Chyba tylko gcc :) > skoro wspominałeś kiedyś, że nawet upgrade nie > będzie czysty? Bede sie staral, aby jednak byl mozliwy czysty upgrade. Przez "czysty" rozumiem tu, ze przy domyslnych konfigach ze starej wersji po upgrade nowa wersja bedzie dzialac "out of the box". Wsparcie modyfikowanych czy recznie tworzonych konfigow nas nie interesuje. >Bardziej to by pasowało na 3.0 niż 2.1. Coz. Mysle o tym tak: jezeli PLD mialo by kiedys faktycznie przejsc na "zawsze w rozwoju ze snapshotami" bedziemy mieli gotowe srodowisko stabilne (Ac) i devel (Th), a Ac 2.1 bedzie moglo zostac pierwszym snapshotem, po ktorym zapewne w dosc krotkim czasie bedziemy w stanie wydac nastepny, oparty juz o Th. A poza tym, nie owijajac w bawelne. Bez takich ruchow Ac umrze duzo szybciej niz Ra. Nie chce tego. Bede ciagnal ta linie tak dlugo jak dam rade (czytaj: tyle ile mi bedzie potrzebna). M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Request for developers + info for mirror admins
> Z ciekawości (w wątku na pld-discuss też nie widziałem uzasadnienia) > dlaczego 4.1 zamiast 3.4.6 (pytam zważywszy na liczbę regresji w gcc4 i > łatwość przeskoku z 3.3)? Powodow jest kilka, mniej i bardziej waznych. Oprocz tego co napisal juz Jakub: - nie chce z Ac robic krypty a'la Ra. Ac 2.1 jezeli faktcznie by mialo wyjsc za pol roku czy rok to powiedzmy szczerze, bedzie to czas gdy gcc z serii 3.x zacznie blokowac mozliwosc budowy coraz wiekszej ilosci rzeczy podobnie jak kiedys w Ra gcc 2.95 - gdy Ac juz faktycznie wyzionie ducha, latwiej bedzie z gcc 4.1 w Ac przeskoczyc na Th, czy nawet na nastepna wersje - poza nowszym glibc, gcc 4.x bylo najczesciej wymieniana rzecza, ktora userzy chcieli by miec w Ac M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Request for developers + info for mirror admins
Hello. EN: Since Ac has reached stable state we now need to maintain it for some time. That means we need... ok, I need more than 5+ people working on AC-branch. Unfortunately I'll not pay you for your work :( To make maintaining a bit easier UTF specs will be allowed on AC-branch and in updates tree (go and thanks blues for that if you want). However please do not use UTF on AC-branch yet. Wait for iso images arrival (next week). If you are doing some updates on HEAD, please do them on AC-branch too (and vice versa). You'll make Ac live a bit longer :) Now about Ac 2.1. Yes, there will be one (I hope) and it would be nice to release it ASAP. Therefore I'm looking for people who will agree to prepare following things for Ac 2.1: - backport of modular xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 + related stuff like netfilter - newer glibc (a big question here because it will be death sentence for i386, I didn't decided yet if that will happen) - any other newest hottest stuff you would like to see in Ac, but stable releases only Things above will need new branch (AC-devel?) and also new builders. So if you can run Ac 2.1 builder, let me know. They're not needed yet, but they will be needed in the future. First thing that should be accomplished is GCC 4.1.x. Now promised info for ftp mirror admins. All packages in Ac main tree will be signed. That means that whole contents of Ac will be retransfered to all mirrors. Signing should be done in next few days. PL: Poniewaz Ac jest juz oficjalnie stabilne musimy go przez jakis czas utrzymywac. Potrzeba do tego... dobra, ja potrzebuje aby na AC-branch pracowalo wiecej niz 5+ osob. Niestety nie bede w stanie placic tym, ktorzy zechca pracowac nad Ac. Aby troszke ulatwic zycie spece w UTF beda dozwolone na AC-branch i w drzewku updates (kto chce, moze za to podziekowac bluesowi). Prosze jednak nie konwertowac jeszcze calego AC-branch na UTF. Poczekajmy az iso trafia na ftp. Jezeli robisz jakis update na HEAD, prosze, zrob go tez na AC-branch (i vice versa). Dzieki temu Ac pozyje chwilke dluzej. A teraz o Ac 2.1. Tak, bedzie taka wersja (mam nadzieje) i bylo by milo aby wyszla ona najszybciej jak to mozliwe. Dlatego tez poszukuje osob, ktore zgodza sie przygotowac nastepujace rzeczy dla Ac 2.1: - backport modularnego xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 i okolice (netfilter) - nowsze glibc (tutaj wielki znak zapytania bo bedzie to oznaczac kasacje architektury i386, jeszcze nie zdecydowalem czy to nastapi) - inne nowiutkie, swiezutkie oprogramowanie, ktore chcial bys miec w Ac, tylko stabilne wersje Powyzsze rzeczy beda wymagaly nowego brancha (AC-devel?) jak i nowych builderow. Dlatego tez jezeli masz sprzet, ktory moglby pracowac za builder dla Ac 2.1, daj znac. Nie sa potrzebne od zaraz, ale w przyszlosci beda. Pierwsza rzecza jaka powinna zostac przygotowana jest GCC 4.1.x. A teraz obiecano info dla administratorow mirrorow. Wszystkie paczki w glownym drzewku Ac zostana podpisane. To oznacza, ze cala zawartosc Ac zostanie ponownie przetranferowana na wszystkie mirrory. Podpisywanie pakietow bedzie mialo miejsce w najlblizszych dniach. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Request for developers + info for mirror admins
Hello. EN: Since Ac has reached stable state we now need to maintain it for some time. That means we need... ok, I need more than 5+ people working on AC-branch. Unfortunately I'll not pay you for your work :( To make maintaining a bit easier UTF specs will be allowed on AC-branch and in updates tree (go and thanks blues for that if you want). However please do not use UTF on AC-branch yet. Wait for iso images arrival (next week). If you are doing some updates on HEAD, please do them on AC-branch too (and vice versa). You'll make Ac live a bit longer :) Now about Ac 2.1. Yes, there will be one (I hope) and it would be nice to release it ASAP. Therefore I'm looking for people who will agree to prepare following things for Ac 2.1: - backport of modular xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 + related stuff like netfilter - newer glibc (a big question here because it will be death sentence for i386, I didn't decided yet if that will happen) - any other newest hottest stuff you would like to see in Ac, but stable releases only Things above will need new branch (AC-devel?) and also new builders. So if you can run Ac 2.1 builder, let me know. They're not needed yet, but they will be needed in the future. First thing that should be accomplished is GCC 4.1.x. Now promised info for ftp mirror admins. All packages in Ac main tree will be signed. That means that whole contents of Ac will be retransfered to all mirrors. Signing should be done in next few days. PL: Poniewaz Ac jest juz oficjalnie stabilne musimy go przez jakis czas utrzymywac. Potrzeba do tego... dobra, ja potrzebuje aby na AC-branch pracowalo wiecej niz 5+ osob. Niestety nie bede w stanie placic tym, ktorzy zechca pracowac nad Ac. Aby troszke ulatwic zycie spece w UTF beda dozwolone na AC-branch i w drzewku updates (kto chce, moze za to podziekowac bluesowi). Prosze jednak nie konwertowac jeszcze calego AC-branch na UTF. Poczekajmy az iso trafia na ftp. Jezeli robisz jakis update na HEAD, prosze, zrob go tez na AC-branch (i vice versa). Dzieki temu Ac pozyje chwilke dluzej. A teraz o Ac 2.1. Tak, bedzie taka wersja (mam nadzieje) i bylo by milo aby wyszla ona najszybciej jak to mozliwe. Dlatego tez poszukuje osob, ktore zgodza sie przygotowac nastepujace rzeczy dla Ac 2.1: - backport modularnego xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 i okolice (netfilter) - nowsze glibc (tutaj wielki znak zapytania bo bedzie to oznaczac kasacje architektury i386, jeszcze nie zdecydowalem czy to nastapi) - inne nowiutkie, swiezutkie oprogramowanie, ktore chcial bys miec w Ac, tylko stabilne wersje Powyzsze rzeczy beda wymagaly nowego brancha (AC-devel?) jak i nowych builderow. Dlatego tez jezeli masz sprzet, ktory moglby pracowac za builder dla Ac 2.1, daj znac. Nie sa potrzebne od zaraz, ale w przyszlosci beda. Pierwsza rzecza jaka powinna zostac przygotowana jest GCC 4.1.x. A teraz obiecano info dla administratorow mirrorow. Wszystkie paczki w glownym drzewku Ac zostana podpisane. To oznacza, ze cala zawartosc Ac zostanie ponownie przetranferowana na wszystkie mirrory. Podpisywanie pakietow bedzie mialo miejsce w najlblizszych dniach. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: PowerDNS z MySQL i administracja
> Nie- rozumiem niepodniesienie się. Jak uzywam binda od bodaj 7 lat tak nigdy niczego takiego nie zaobserwowalem, nawet w najbardziej wymyslnych/rozbudowanych konfiguracjach i przy najprzerozniejszych bledach w sterfach (z zapisaniem strefy binarnym smieciem wlacznie). Jest tak jak napisal Stacho. Bind podniesie sie zawsze*, co najwyzej nie dziala uszkodzona strefa, wszystkie pozostale dzialaja. *) zawsze jezeli pozostala czesc konfiguracji (nie strefy) jest poprawna i bez bledow. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: bootkietki - kiedy będą nowe?
> Czy kto[ wie kiedy bd uaktualnione bootkietki? Jak je skoncze uaktualniac :) Troche to potrwa, conajmniej kilka dni. > PróbowaBem zainstalowa PLD2.0 przez sie i wywala na "...MARK: > kernel-grsecurity" z informacj |e takiego pakietu nie ma. > Mo|na to jako[ obej[? wykluczajc instalacj z CD-ROMu. Zainstaluj z kernelem 2.4, zadziala. Potem juz z poziomu systemu zmienisz sobie kernel. M. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl