start-vservers odmontowuje fs-y pod systemd
Zauważyłem że przy starcie vserverów w systemie z systemd zaczynają się problemy z komunikacją po dbus, a dokładniej odmontowywaych jest większość filesystemów poza / /dev /var, u mnie są to m.in. /home i /usr w efekcie czego komponenty systemd przestają się komunikować po dbus - wszystko niby działa - można podmontować brakujące fs-y z powrotem, ale systemd zreanimować mi się nie udało. Problematyczne jest wywołanie: /usr/lib64/util-vserver/start-vservers -j 1 --all --start w skrypcie /etc/rc.d/init.d/vservers jest to wiersz: $_START_VSERVERS -j $NUMPARALLEL --all --start w sekcji start. Czy komuś działają vserwery na hoście z systemd? # rpm -q systemd util-vserver systemd-206-8.x86_64 util-vserver-0.30.216-1.pre3038.4.x86_64 # uname -srom Linux 3.9.11-1 x86_64 PLD Linux Pozdrawiam, Marek Guevara Braun ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
start-vservers odmontowuje fs-y pod systemd
Zauważyłem że przy starcie vserverów w systemie z systemd zaczynają się problemy z komunikacją po dbus, a dokładniej odmontowywaych jest większość filesystemów poza / /dev /var, u mnie są to m.in. /home i /usr w efekcie czego komponenty systemd przestają się komunikować po dbus - wszystko niby działa - można podmontować brakujące fs-y z powrotem, ale systemd zreanimować mi się nie udało. Problematyczne jest wywołanie: /usr/lib64/util-vserver/start-vservers -j 1 --all --start w skrypcie /etc/rc.d/init.d/vservers jest to wiersz: $_START_VSERVERS -j $NUMPARALLEL --all --start w sekcji start. Czy komuś działają vserwery na hoście z systemd? # rpm -q systemd util-vserver systemd-206-8.x86_64 util-vserver-0.30.216-1.pre3038.4.x86_64 # uname -srom Linux 3.9.11-1 x86_64 PLD Linux Pozdrawiam, Marek Guevara Braun ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
start-vservers odmontowuje fs-y pod systemd
Zauważyłem że przy starcie vserverów w systemie z systemd zaczynają się problemy z komunikacją po dbus, a dokładniej odmontowywaych jest większość filesystemów poza / /dev /var, u mnie są to m.in. /home i /usr w efekcie czego komponenty systemd przestają się komunikować po dbus - wszystko niby działa - można podmontować brakujące fs-y z powrotem, ale systemd zreanimować mi się nie udało. Problematyczne jest wywołanie: /usr/lib64/util-vserver/start- vservers -j 1 --all --start w skrypcie /etc/rc.d/init.d/vservers jest to wiersz: $_START_VSERVERS -j $NUMPARALLEL --all --start w sekcji start. Czy komuś działają vserwery na hoście z systemd? # rpm -q systemd util-vserver systemd-206-8.x86_64 util-vserver-0.30.216-1.pre3038.4.x86_64 # uname -srom Linux 3.9.11-1 x86_64 PLD Linux Pozdrawiam, Marek Guevara Braun ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: OT: Czym monitorujecie serwery?
W dniu 8 lutego 2012 14:11 użytkownik Jacek Osiecki jos...@hybrid.pl napisał: To że monitorować można to wiem. Chodzi o to, że nagios może tylko powiedzieć że coś się stało (lub dzieje), natomiast pełny monitoring jaki się robi np. przy użyciu cacti pozwala na dokładną analizę. Przykład: przestaje działać strona WWW. Nagios nas o tym poinformuje, zobaczymy że było OK i jest CRITICAL, ew. jakiś WARNING po drodze. Nawet jeśli inne testy (mysql, obciążenie dysków, ramu) miały po drodze warningi nadal jest to korelacja 0/1. Nie wiemy nic o tym czy np. ilość zapytań do mysqla nagle wzrosła o 300% czy rosła aż do punktu X gdzie został przekroczony próg krytyczny, pamięć się skończyła, system wlazł na swapa, mysql przestał odpowiadać na zapytania itd... Pluginy nagiosowe mogą (i niektóre to robią) zwracać tzw. performance data i mogą być to właśnie informacje na temat quality typu tranzakcje/s, wartość load, zajętość pamięci czy cpu. Performance data jest zwracane w tekście opisowego wyniku plugina po | - dokumentacja http://nagios.sourceforge.net/docs/3_0/perfdata.html Wykresy a'la Cacti z danych performance robi np. PNP4Nagios http://sourceforge.net/projects/pnp4nagios/ 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: geninitrd i luks na sda2
2011/5/22 Andrzej Zawadzki zawa...@gmail.com: Zrobiłem aktualizację uśpionego ;-) serwera i... initrd nie ma ani obsługi 03:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 04) ani wsparcia dla zaszyfrowanego /dev/sda2 (LUKS) (na nim są wolumeny LVM) # geninitrd -f -v /boot/initrd-2.6.38.6-8.gz 2.6.38.6-8 [...] geninitrd: find_tool: found /sbin/lspci geninitrd: Using modprobe -c to get modules config geninitrd: Finding SATA modules (class=0x0106) geninitrd: Using /dev/vg_system/root as device for rootfs geninitrd: Finding modules for device path /dev/vg_system/root geninitrd: is_luks: /dev/vg_system/root is not device mapper name geninitrd: LVM: /dev/vg_system/root is LVM node geninitrd: LVM VG for /dev/vg_system/root: vg_system geninitrd: LVM PV for vg_system: /dev/mapper/lvm geninitrd: Finding modules for device path /dev/mapper/lvm geninitrd: is_luks: /dev/mapper/lvm is not cryptsetup luks geninitrd: LVM v2 enabled geninitrd: Building initrd... geninitrd: + cp /usr/lib64/initrd/busybox Na działającej maszynie mam: geninitrd: find_tool: found /sbin/lspci geninitrd: Using modprobe -c to get modules config geninitrd: Finding SATA modules (class=0x0106) geninitrd: Using /dev/vg0/piglet as device for rootfs geninitrd: Finding modules for device path /dev/vg0/piglet geninitrd: is_luks: /dev/vg0/piglet is not device mapper name geninitrd: LVM: /dev/vg0/piglet is LVM node geninitrd: LVM VG for /dev/vg0/piglet: vg0 geninitrd: LVM PV for vg0: /dev/mapper/piglet geninitrd: is_luks: /dev/mapper/piglet is cryptsetup luks geninitrd: Finding modules for device path /dev/mapper/piglet geninitrd: is_luks: /dev/mapper/piglet is cryptsetup luks geninitrd: Finding modules for device path /dev/sda geninitrd: is_luks: /dev/sda is not device mapper name geninitrd: Finding SCSI modules using scsi_hostadapter geninitrd: LVM v2 enabled geninitrd: Building initrd... geninitrd: + cp /usr/lib64/initrd/busybox /root/tmp/initrd.fL1ZFi/bin/busybox Czyli po LVM PV for vg... jest sprawdzanie is_luks Zawartość /etc/crypttab: lvm /dev/sda2 none U mnie w crypttab bez none (ale sprawdziłem, że z none też sprawdza is_luks): # grep ^piglet /etc/crypttab piglet /dev/sda Konfig geninitrd: # grep -v -e ^# -e ^$ /etc/sysconfig/geninitrd BASICMODULES=usbhid ehci-hcd uhci-hcd ohci-hcd PREMODS=jbd COMPRESS=xz INITRDFS=initramfs USE_UDEV=yes PROBSTATICMODULES=yes USE_SUSPEND=no USE_TUXONICE=no PROBESCSI=yes PROBEIDE=yes PROBERAID=yes DEBUGINITRD=sh BOOT_SPLASH=no Pomysłów brak. U mnie działa. Może do BASICMODULES dodać ręcznie mptsas ? Czy w /etc/fstab / też jest /dev/vg_system/lvm ? 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: [kernel] modulowe ciekawostki...
Paweł Sikora pisze: w celu poszukiwan bisectem commita dodajacego oopsa do 2.6.31 wzialem pld-owy konfig, przestawilem tylko zwalona kompresje lzma na gzip, zbudowalem czysta vanille, zmontowalem initrd tak jak w pld i sie nie bootuje. blizej nieznany problem z /dev/md0 jak na obrazku[...] A odpalony z jakiegoś innego kernela/rescuecd/usb ten md0 składa się bez problemu? Miałem kiedyś problem (chyba podobny, ale na kernelu o dwa lata starszym) przy źle działającym jednym dysku. mdassemble potrafi też się burzyć jeśli typ partycji nie jest fd (czy jaki tam powinien być dla raida). 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: OpenSWAN.spec
Tomasz Pala pisze:
%{name}-enable_des.patch
tu z kolei nie wiem, dlaczego zostało to w ogóle zmienione,
niech się autor wytłumaczy - mguevara?
# should we include all manner of known to be broken/weak?
# use this only if you are building some kind of a testing
# device. Normal use does not need any of this.
Niektóre urządzenia VPN nie miały wtedy (~2007) obsługi niczego poza DES
(albo 3DES i AES był za grube $$$), łatka ta włączała właśnie obsługę
tego algorytmu szyfrowania. Być może obecnie coś jeszcze rozmawia
starym DES-em? Prawdopodobnie gatunek na wymarciu.
P,
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Please test initramfs-tools
Jan Rekorajski wrote: I would appreciate if other devilopers could test other cases (lvm, cryptroot, dmraid, mdadm), all required packages have initramfs support added via -initramfs subpackage. Nie zadziałało dla mojego / na lvm - niestety próbowałem to na prawdziwym sprzęcie i nie zrobiłem notatek. Generalnie wygląda tak że nie potrafiło aktywować grupy wolumenowej na którym m.in. był root filesystem. Wywaliło mnie do shella initrd w którym z powodzeniem mogłem wykonać vgchange -a y vg00 i juz root filesystem zaczął być widoczny, ale nie domyśliłem się jak kontynuować boot i uruchomiłem maszynę na starym initrd. Co zainstalowane: poldek:/all-avail ls -I *initramfs* cryptsetup-luks-initramfs-1.0.6-8.i686 dmraid-initramfs-1.0.0-0.rc15.3.i686 initramfs-tools-0.93-1.i686 lvm2-initramfs-2.02.44-5.i686 mdadm-initramfs-2.6.8-2.i686 multipath-tools-initramfs-0.4.8-9.i686 openct-initramfs-0.6.15-4.i686 opensc-initramfs-0.11.6-3.i686 udev-initramfs-138-8.i686 9 packages W plikach konfiguracyjnych mkinitramfs nic nie zmieniałem. Jako parametr kernela w grubie mam root=/dev/vg00/root Pozdrawiam, Marek PS. W najbliższym czasie będę stawiał system z / na szyfrowanym lvm-ie, także będzie okazja do sprawdzenia mkinitramfs. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [TH] geninitrd x86_64 vs. v86
Paweł Sikora pisze:
poniewaz w /usr/include/klibc, /usr/lib64/klibc nie ma
elementow biblioteki x86emu, a tam wlasnie ich szuka klcc.
to co lezy w /usr/include, /usr/lib64 jest zbudowane
na bazie glibca.
przydalo by sie wyprodkowac jeszcze pakiety klibc-x86emu{,-devel}
przy budowaniu x86emu.spec --with klibc i wtedy bedzie wypasik.
Na razie dodałem bconda klibc do x86emu - jeśli z nim zbudujemy, to
pakiet x86emu-devel dostarcza x86emu-devel(klibc), a biblioteki i
headery lecą odpowiednio do /usr/lib64/klibc (na razie nie patrzyłem na
x86) i /usr/include/klibc - więc nie powinny sie kłócić (po pdpowiednich
zmianach :) z wersjami z glibc.
v86d budowany z klibc i x86emu wymaga teraz x86emu-devel(klibc) - na
x86_64 ładnie się buduje i jak sprawdziłem działa - z initrd ustawia
konsolkę uvesafb (w końcu :)
moze wprowadzimy jakies %{_alt_libc} wzorem kernela? :-)
Zobaczę jeszcze jak to działa dla x86. Jakieś %{_alt_libc} w nazie było
by całkiem dobre - mniej zamieszania dla budowniczych i łatwiej się nie
pomylić przy jakimś upgrade.
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: quo vadis jajku?
Wojciech Błaszkowski pisze: Rozumiem, że jeśli experimental działa, to po wydaniu go przez vserwerowych ludzi do stable nasze paczki nie są przerabiane ? Stable jest linia 2.2, linia 2.3 to development - i to ona jest (domyślnie) w kernelach serii LINUX_2_6. ZTCW ostatnie 2.2 to patch-2.6.22.19-vs2.2.0.7.diff - czyli pewnie jeszcze dla LINUX_2_6_22 można zbudować kernel z --with vs22. 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: SOURCES (LINUX_2_6_25): linux-2.6-vs2.3.patch .14
arekm pisze: Author: arekmDate: Fri Aug 1 23:37:48 2008 GMT Module: SOURCES Tag: LINUX_2_6_25 Log message: .14 [...] --EXTRAVERSION = .13 -+EXTRAVERSION = .13-vs2.3.0.34.14 +-EXTRAVERSION = .14 ++EXTRAVERSION = .14-vs2.3.0.34.14 BTW. cały kawałek dotyczący EXTRAVERSION w patchach vs można wywalić bo dalej w specu go nadpisujemy. 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: podpakiet pcmcia w kernelu 2.6.24.3-0.1 (branch:LINUX_2_6)
Paweł Sikora wrote: przed chwila wlasnie probowalem sie zabootwac z w.w. jajka skompilowanego przy uzyciu gcc-4.3.0 i spotkala mnie mala niespodziewajka. otoz moduly od usb (na ktorych mam klawiature i myszke) odmowily wspolpracy. pobiezny (-A100 z modinfo) grep wykazal, ze moduly: filename: /lib/modules/2.6.24.3-0.1/kernel/drivers/hid/usbhid/usbhid.ko.gz filename: /lib/modules/2.6.24.3-0.1/kernel/drivers/hid/usbhid/usbmouse.ko.gz filename: /lib/modules/2.6.24.3-0.1/kernel/drivers/hid/usbhid/usbkbd.ko.gz filename: /lib/modules/2.6.24.3-0.1/kernel/drivers/hid/hid.ko.gz [...] zaleza od modulow *pcmcia*. w zaistanialej sytuacji chyba bezsensowne staje sie utrzymywanie osobnego podpakietu pcmcia jak i tak glowny oraz sound jej wymagaja. Ja mam tak: poldek:/installed ls -I kernel-pax-grsecurity-*2.6.24.3-0.1.i686 kernel-pax-grsecurity-2.6.24.3-0.1.i686 kernel-pax-grsecurity-sound-alsa-2.6.24.3-0.1.i686 kernel-pax-grsecurity-sound-oss-2.6.24.3-0.1.i686 3 pakiety $ uname -r -m 2.6.24.3-pax-grsecurity-0.1 i686 Klawiatura i mysz na USB, dźwięk jest, ale PCMCIA brak, jak i sam pakiet *pcmcia* nie zainstalowany. Środowisko Ac z gcc 3.3.6. Jądro budowane na carme-ac-i686. 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: [TH] vserver build problem
Arkadiusz Patyk wrote: ale teraz: Executing vrpm-preload --install -vh --root /vservers/php --noorder... New network context is 2 Adding Preparing...error: cannot open Basenames index using db3 - No such file or directory (2) /usr/sbin/chbind: line 135: 3376 Segmentation fault [EMAIL PROTECTED] [EMAIL PROTECTED] -- $@ vpoldek failed on vserver '/etc/vservers/php' with errorcode 1 Potwierdzam. Mam tak samo. Marek ___ 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.22.5-0.2 i ipv6
Zbyniu Krzystolik wrote: baggins, mguevara - może jednak 2.2.0 do czasu, aż będzie możliwość zrobienia modułu ipv6? Główne różnice między 2.2 i 2.3 wyrzucenie LEGACY i dodanie wsparcia dla ipv6. Dodałem bcond vs22 (domyślnie wyłączony), który zmienia vserver z 2.3 na 2.2 i zmienia ustawienie CONFIG_IPV6 z powrotem na m. kernel-vserver.config został uzupełniony o opcje wymagane przez 2.2 (ustawione na is not set btw). Zapraszam do testów, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Rozróżnienie między modułami ok ołoernelowymi grsecurity i normal
Cezary Krzyzanowski wrote: Halo, ale ja nie pisałem nic o *budowaniu*. Pokazałem sytuację, w której poledek *psuje* system -- 'ugraduje' sterownik, co pociąga zmianę kenrela z 'grescurity' na 'dist' tak od sobie...EVIL(tm) Czy odpowiedni hold kernel* w pliku konfiguracyjnym nie zablokuje takiego upgrade? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SOURCES (LINUX_2_6): sqlzma2k-3.2-r2.patch (NEW) - lzma for squash...
Przemyslaw Iskra wrote: On Tue, May 08, 2007 at 03:48:29PM +0200, mguevara wrote: Author: mguevara Date: Tue May 8 13:48:29 2007 GMT Module: SOURCES Tag: LINUX_2_6 Log message: - lzma for squashfs from http://www.squashfs-lzma.org/dl/sqlzma3.2-r2b.tar.bz2 ++ sqlzma_fin(p-un); ten patch jest jakiś niekompletny, poza tym wygląda jakby był niekompatybilny z squashem na zlibie Na razie wycofałem go ze speca. Co do niekompletności to reszta jest w pozostałych plikach w tar.bz2 - prace trwają nad mergem tego. Ponoć jest jeszcze jakiś zewnętrzny spec ze squashem z lzma - nie patrzyłem na to jeszcze. 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: SOURCES (LINUX_2_6): kernel-i386.config - initial update for 2.6.2...
Przemyslaw Iskra wrote: - experimentally introduced NO_HZ (aka dynticks) and HZ=1000 Podobno na smp HZ_1000 potrafi zfloodowac maszyne tak ze jej osiagniecia beda znacznie gorsze niz z zadszymi przerwaniami. Nie bez powodu HZ_100 jest rekomendowane dla laptopow i maszyn SMP. Dla laptopów to głównie ze względu (ZTCW) na baterie. Czy NO_HZ pozwala na reczne ograniczenie ticksow w razie potrzeby, czy zmienia zawsze jak sam uwaza ? Jesli jest to jedynie automat to wielu ludziom moze on uprzykrzyc zycie. A jesli pozwala na reczne ograniczenie to raczej powinno byc zalozone by-default, a jak ktos potrzebuje to je zdejmie. O dyntickach (aka CONFIG_NO_HZ) można poczytać w LWN http://lwn.net/Articles/223185/ oraz w ramach listy zmian w 2.6.21 na kernelnewbies http://kernelnewbies.org/Linux_2_6_21 (Dynticks and Clockevents) W teorii ma robić dobrze, jak jest w praktyce - trzeba zobaczyć. Jak na razie w 2.6.21 NO_HZ jest to tylko dla i386, ale i tak powinno to dać jakiś obraz jak to działa. 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
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
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
Re: SPECS: iptables.spec - fix build (mguevara please test if packages...
shadzik wrote: Author: shadzik Date: Fri Apr 6 09:52:55 2007 GMT Module: SPECS Tag: HEAD Log message: - fix build (mguevara please test if packages build after your changes) [...] - libipt_set.so libipt_statistic.so libipt_stealth.so \ + libipt_set.so libipt_statistic.so \ Oczywiście przetestowałem *przed* commitnięciem i SOA#1 - ale u mnie (Ac) a nie na carme (Th): rpm -ql iptables |grep stealth /usr/lib/iptables/libipt_stealth.so Gdzie się ten libipt_stealth.so nie buduje (jaka wersja kernela itp., nagłówków llh, czy na builderze, czy u Ciebie) Może nie ma jakiegoś BR bo u mnie to powstaje. I mam nawet /usr/sbin/iptables -m stealth --help |tail -2|head -1 stealth v1.3.7 takes no options Marek PS. Na moim builderze mam zainstalowane: kernel-pax-grsecurity-libc-headers-2.6.20.4-1 kernel-pax-grsecurity-source-2.6.20.4-1 gcc-3.3.6-4 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: rake.spec - rel 2, uncommented BA noarch
Jakub Bogusz wrote: On Thu, Apr 05, 2007 at 06:41:22PM +0200, mguevara wrote: Author: mguevara Date: Thu Apr 5 16:41:22 2007 GMT Module: SPECS Tag: HEAD Log message: - rel 2, uncommented BA noarch [qboosh ~]$ rpm --eval '%ruby_rubylibdir' /usr/lib/ruby/1.8 [EMAIL PROTECTED] ~]$ rpm --eval '%ruby_rubylibdir' /usr/lib64/ruby/1.8 To nie jest noarch. ok zmienie ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
[cvs.pld-linux.org] leży ?
Coś się wyłączyło ? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [cvs.pld-linux.org] leży ?
Marek Guevara Braun wrote: Coś się wyłączyło ? O, już działa :-) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: X11-driver-nvidia-legacy2.spec (NEW) - revived nvidia 96xx ...
Marcin Król wrote: Np. ja używam X11-driver-nvidia z HEAD razem z 2.6.20, z którym AC-branch już nie halo, a na 7.2/Th mi nie spieszno. Czemu nie halo? Ja od wczoraj uzywam nvidii z 2.6.20.4 z mojego brancha i wszytko biega. Wyraziłem się nieprecyzyjnie - powinienem napisać że razem z 2.6.20 z brancha LNUX_2_6_20, z którym ... :-) Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: X11-driver-nvidia-legacy2.spec (NEW) - revived nvidia 96xx ...
Jakub Bogusz wrote: X11*.spec na HEAD w ogóle ma jeszcze rację bytu? Np. ja używam X11-driver-nvidia z HEAD razem z 2.6.20, z którym AC-branch już nie halo, a na 7.2/Th mi nie spieszno. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: xorg-driver-video-nvidia.spec - update rpmbuild(macros) and...
rotom wrote:
Author: rotomDate: Thu Mar 22 23:52:55 2007 GMT
Module: SPECS Tag: HEAD
Log message:
- update rpmbuild(macros) and macros
- remove whole smp stuff
[...] *
* NOTE: *
* You must install: *
- * kernel(24)(-smp)-video-nvidia-%{version} *
+ * kernel(24)-video-nvidia-%{version} *
Czy na kernelach 2.4 da się to po tych zmianach zbudować? I btw. czy w
Th będzie wspierana linia 2.4 ?
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: xorg-driver-video-nvidia.spec - update rpmbuild(macros) and...
Bartosz Świątek wrote:
*
* You must install: *
- * kernel(24)(-smp)-video-nvidia-%{version} *
+ * kernel(24)-video-nvidia-%{version} *
[...]
Nigdy nie była i o ile wiem nie będzie, więc zmiany jak najbardziej poprawne.
kernel(24)-video-nvidia-%{version} - kernel-video-nvidia-%{version}
:-)
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - rel 0.5 - mainly for ppc64 tes...
Przemyslaw Iskra wrote: dla obu ppc i ppc64 używane jest arch/powerpc z kernela, i aż tak znacznie się nie różnią OK. to zrobie jszcze jedno podejście z generacją konfigów na bazie tego co jest w LINUX_2_6_19 lub starszym. natomiast arch/ppc zostawili dla architektur które jeszcze nie przeportowali do arch/powerpc, niestety do tego napsuli, i arch/ppc jest raczej nieużywalne Czyli dla nas ten target (linuksowy) nie jest interesujący. Przynajmniej się dobrze krosskompilowało :) Jeszcze jedno czy ktoś używający PPC mógłby podesłać działające/sprawdzone pliki .config dla wszystkich rodzajów architektur PPC? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Moduły kernelowe po zmianach na L INUX_2_6_20 (th will use only smp)
Patryk Zawadzki wrote: kernel-2.6.20.3-0.4: modprobe ndiswrapper: ndiswrapper: unknown symbol _proxy_pda modprobe fuse: fuse: unkown symbol _proxy_pda # modprobe -v fuse insmod /lib/modules/2.6.20.3-0.1smp/kernel/fs/fuse/fuse.ko.gz (ale to z mojego i686 z gcc-3.3.6) i podobnie kilkanaście innych podułów, z czego wszystkie - poza ndiswrapperem - budowane wewnątrz drzewa kernela. Tego jeszcze nie stwierdziłem (ale ndiswrapera nie testowałem). To wygląda na rozwiązanie problemu z gcc-4.2: http://www.ussg.iu.edu/hypermail/linux/kernel/0702.0/0713.html No to jest juz trzecie rozwiązanie :) Zobacz(my) czy tego już nie mamy wcześniej gdzieś zaaplikowanego (vide komentarze wewnątrz kernel-proxy-pda.patch) - Paweł Sikora też aplikował jakiegoś (innego) fix-a. Ponieważ nie miałem tego problemu to mu się jeszcze nie przyglądałem. 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: Moduły kernelowe po zmianach na L INUX_2_6_20 (th will use only smp)
Marek Guevara Braun wrote:
Patryk Zawadzki wrote:
To wygląda na rozwiązanie problemu z gcc-4.2:
http://www.ussg.iu.edu/hypermail/linux/kernel/0702.0/0713.html
No to jest juz trzecie rozwiązanie :) Zobacz(my) czy tego już nie mamy
wcześniej gdzieś zaaplikowanego
$ grep -A 1 -B 1 _proxy_pda arch/i386/kernel/vmlinux.lds.S \
arch/x86_64/kernel/vmlinux.lds.S
arch/i386/kernel/vmlinux.lds.S-jiffies = jiffies_64;
arch/i386/kernel/vmlinux.lds.S:_proxy_pda = 0;
arch/i386/kernel/vmlinux.lds.S-
--
arch/x86_64/kernel/vmlinux.lds.S-jiffies_64 = jiffies;
arch/x86_64/kernel/vmlinux.lds.S:_proxy_pda = 0;
arch/x86_64/kernel/vmlinux.lds.S-PHDRS {
Czyli jest już zaaplikowane.
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - rel 0.5 - mainly for ppc64 tes...
Jakub Bogusz wrote:
On Mon, Mar 19, 2007 at 02:46:10PM +0100, mguevara wrote:
+ExclusiveArch: %{ix86} alpha %{x8664} ia64 ppc ppc64 powerpc sparc
sparc64 arm
Ale dla rpm-a to się nazywa ppc64.
powerpc dla rpm-a to jakiś podtyp albo alias dla ppc, nie ppc64.
W takim razie w specu do usunięcia - w każdym razie nie psuje budowy dla
32-bitowego ppc - testowane dla crossppc-gcc na x86-64. Z drugiej strony
próbuje wyłapać problem na rzeczywistym builderze ppc64 dla Th -
oglądając logi z nieudanej budowy nie widzę tam jednego seda który
powinien zadziałać dla architektury ppc64 - stąd to powerpc.
Dzięki,
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - rel 0.5 - mainly for ppc64 tes...
Jakub Bogusz wrote:
On Tue, Mar 20, 2007 at 12:08:45AM +0100, Marek Guevara Braun wrote:
[...] Z drugiej strony
próbuje wyłapać problem na rzeczywistym builderze ppc64 dla Th -
oglądając logi z nieudanej budowy nie widzę tam jednego seda który
powinien zadziałać dla architektury ppc64 - stąd to powerpc.
Jakiego seda?
Od pewnego czasu dla wszystkich PPC (ppc i ppc64) był wspólny
kernel-ppc.config, a dla ppc64 sed podmieniał opcję CONFIG_PPC64:
sed -i s:# CONFIG_PPC64 is not set:CONFIG_PPC64=y:
arch/%{_target_base_arch}/defconfig
Ten sed mi się nie pojawiał w logach.
Nie znam backgroundu - dlaczego ppc i ppc64 miało ten sam konfig
w każdym razie konfigi dla kernelowych targetów ppc (dla rpm ppc?) i
powerpc (dla rpm ppc64?) znacznie się różnią - być może był to config
tylko dla PPC64?
Plik .config dla ppc64 powinien się nazywać kernel-ppc64.config .
OK. Widzę.
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Moduły kernelowe po zmianach na L INUX_2_6_20 (th will use only smp)
Jakub Bogusz wrote: On Sun, Mar 18, 2007 at 09:09:01PM +0100, Arkadiusz Miskiewicz wrote: On Sunday 18 of March 2007, Arkadiusz Patyk wrote: Kernel w TH ma mieć tylko SMP. Pluto już dokonał tego na LINUX_2_6_20 + zmiany rpm-build-macros Nie poprawiaj - te zmiany pluta są do revertnięcia. Nie mam pojęcia po co zmieniają one rpmowe makra zamiast tylko wyłaczyć/wywalić UP w kernel.spec Raczej wywalić/wyłączyć smp i zmienić konfigurację podstawowego. Nie ma sensu trzymać wszędzie przyrostka -smp, jeśli jest to jedyny kernel. Tak właśnie jest teraz zrobione dla LINUX_2_6_20. Teraz tylko problematyczne będzie budowanie czegokolwiek dla nowego jądra dla środowiska Ac (bo Th pewnie prędzej czy później zmigruje do nowych makr). Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac/ready] openoffice.org-2.1. 0-0.m6.7 nie działa wcale!
Łukasz Maśko wrote: Po dzisiejszym update openoffice.org z ready przestało totalnie działać. SOA#1 - na 2 komputerach. Aktywny PaX może ubijać javę - poza tym działa. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [Ac/ready] openoffice.org-2.1. 0-0.m6.7 nie działa wcale!
Łukasz Maśko wrote: Po dzisiejszym update openoffice.org z ready przestało totalnie działać. [...] W międzyczasie pojawia się bootsplash (pasek nawet nie drgnie), po czym okienko z teścią Uruchomienie aplikacji nie jest możliwe. Wystąpił wewnętrzny błąd. Jeszcze mi się coś przypomniało - dziś przy instalacji tej wersji na notebooku zapchał mi się dysk - gdy próbowałem odpalić załącznik xls z poczty to dostałem podobny komunikat. Po usunięciu kilku gb z dysku i zrobieniu upgrade openoffice.org* --reinstall problem znikł. Na drugiej maszynie instalowanej wczoraj wieczorem miałem jakieś niespełnione zależności dla starszej wersji OOo - najpierw zrobiłem uninstall openoffice.org* a potem dopiero zainstalowałem nowszą wersję. Być może przy zwykłym upgrade nie są usuwane jakieś pliki ? 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: [Ac] Popsuty mozilla-firefox-2.0.0.2-2.
Piotr Karbowski wrote: Witam! Po upgradze mozilla-firefox z 2.0.0.2-1 do 2.0.0.2-2 firefox konczy zycie przy starcie z memory fault. SOA#1 ale za to po przesiadce z mozilla-thunderbird-1.5.0.10 na 2.0 beta cośtam 5 musiałem ponownie wrócić do 1.5.0.10 bo sie przestało uruchamiać. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (AC-branch): snort.spec - don't pack header and source files...
shadzik wrote: Author: shadzik Date: Fri Mar 9 16:01:10 2007 GMT Module: SPECS Tag: AC-branch Log message: - don't pack header and source files unless there is a -devel subpackage (which will, as I suppose, never exist) [...] -%attr(640,root,root) /usr/src/snort_dynamicsrc/* Docelowo należy to wydzielić do podpakietu -devel, a nie usuwać. Może być potrzebne do tego: http://snort.org/docs/snort_htmanuals/htmanual_261/node313.html 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: Packages to be removed from Ac
Marcin Król wrote: EN: Following packages doesn't build on current Ac and will be removed from distribution if no one will fix them till 10th of March 2007. PL: Nastepujace pakiety nie buduja sie na aktualnym Ac i zostana usuniete z dystrybucji jezeli ktos nie poprawi ich do 10 marca 2007. [...] snort.spec:AC-branch Wersja 2.4.5-3 snort.spec powinna się już budować - zdeaktywowałem wsparcie dla clamav, które w międzyczasie zmieniło funkcje wykorzystywane do skanowania - to w patchu dostosowane jest do starszej wersji clamava. 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: SOURCES: xorg-driver-video-fglrx-2.6.20-init_work_macro.patch
Paweł Sikora wrote: Author: vip Date: Fri Feb 23 12:07:33 2007 GMT ++#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20) ++INIT_WORK((thread_obj-work), routine); ++#else + INIT_WORK((thread_obj-work), routine, pcontext); [...] mistrzu, work-data dla = 2.6.20 tez trzeba ustawic. inaczej moze sie taka zabawa brzydko skonczyc ;-) Ja tu jeszcze widzę inny problem - dla nowego INIT_WORK (2.6.20) drugi argument - routine powinien być wskaźnikiem funkcji, której jedynym argumentem jest wskaźnik do struct work_struct. Dla starego INIT_WORK ( 2.6.20), routine również jest wskaźnikiem do funkcji, ale jej argumentem jest jakaśtam inna struktura danych (która nawiasem mówiąc posiada pole wskaźnika do struct work_struct). W obydwu przypadkach wskaźnik do tej funkcji ląduje jako pole func zmiennej/struktury wskazywanej przez pierwszy argument INIT_WORK. Dalej w toku zmagań na wysokości pliku kernel/workqueue.c w funkcji __run_work (2.6.20) lub run_workqueue (2.6.20) wywoływana jest ta funkcja z argumentem work (2.6.20) lub data (w naszym wypadku pcontext) (dla 2.6.20) Co ciekawsze funkcja przekazywana jako routine jest (z mojego pobieżnego przejrzenia kodu) definiowana w ramach dostarczanego binarnego bloba (a przynajmniej samo przekazywanie wskaźnika do tej funkcji jest tylko w blobie) - tu zakładam że zaimplementowana jest w starej formie tj. argumentem jej jest wskaźnik do czegoś innego niż struct work_struct. No i dochodzimy do sedna - w 2.6.20 po wywołaniu __run_work wywoływana jest funkcja routine z nieoczekiwanym argumentem - BUM ? To tyle dywagacji, ale może funkcja przekazywana jako wskaźnik routine jest gdzieś zdefiniowana w postaci źródłowej i można ją przedefiniować ? 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: 2.6.20 i firegl
Tomasz Witek wrote: Matkor w swoim mejlu http://lists.pld-linux.org/mailman/pipermail/pld-cvs-commit/Week-of-Mon-20070226/144567.html zasugerowal ze to moze dzialac, ale ... Jakiś czas temu Paweł Sikora na pld-kernel pisał o problemach z jądrem smp 2.6.20 i sterownikami firegl [1]. Przy budowie sterownika można zauważyć ostrzeżenia o niewłaściwych wskaźnikach - odnoszące się do funkcji mającej związek z przerwaniami (irq_...cośtam - w tej chwili nie pamiętam) - w starszych jądrach funkcje te miały trzy argumenty, w 2.6.20 tylko dwa - ATI w swoich funkcjach zakłada przekazywanie trzech argumentów - jest to coś czemu warto się przyjrzeć, bo potencjalnie może być źródłem problemu. (EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed (/usr/lib/xorg/modules/dri/fglrx_dri.so: undefined symbol: __driCreateNewScreen_20050727) (EE) AIGLX: reverting to software rendering (II) GLX: Initialized MESA-PROXY GL provider for screen 0 Dzialac dziala. Troche smieci po ekranie ale pracowac sie da. Ale ja bym chcial czasem jakiegos beryla albo cóś :) A to wygląda na coś innego. Pozdrawiam, Marek [1] http://lists.pld-linux.org/mailman/pipermail/pld-kernel/2007-February/001390.html ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 2.6.20 i firegl - handler
Marek Guevara Braun wrote: Przy budowie sterownika można zauważyć ostrzeżenia o niewłaściwych wskaźnikach - odnoszące się do funkcji mającej związek z przerwaniami (irq_...cośtam - w tej chwili nie pamiętam) - w starszych jądrach funkcje te miały trzy argumenty, w 2.6.20 tylko dwa - ATI w swoich funkcjach zakłada przekazywanie trzech argumentów - jest to coś czemu warto się przyjrzeć, bo potencjalnie może być źródłem problemu. A tu artykuł na temat - http://lwn.net/Articles/202449/ W sumie powinno to być już w 2.6.19, a same sterowniki ati niby do 2.6.19 są dostosowane (bo tak piszą w release notes do poprzedniej wersji sterowników) - jak pamiętam odpowiednie funkcje ati używają trzech argumentów dla tych handlerów - być może coś przeoczyłem, albo zmiana weszła w jakimś 2.6.19.x. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: TH - madwifi - problem z binutils ?
Paweł Sikora wrote: On Tuesday 27 of February 2007 00:32:44 Marek Guevara Braun wrote: Pawel Nogas wrote: Dzisiaj zglosilem Zgłoszenie http://madwifi.org/ticket/1140 i386-elf.hal.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), ^^^ binutils jest ok. To FreeBSD jest OK. HAL jest binarką z FreeBSD - ta sama wersja jest używana w systemach BSD jak i Linuksie. Czy też masz binutils-2.17.50.0.10 lub nowsze? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [PATCH] kernel-x86_64.config - mały updat e dla kernela z brancha LINUX_2_6_20
[EMAIL PROTECTED] wrote: Zgadza się, buduję bez grsec, a na desktopie gdzie mam jednego urzytkownika nie jest mi potrzebne, zapomniałem o tym wspomnieć. Jak to w takim razie rozwiązać? Zbudować jeszcze raz - odpowiednie zmiany w plikach konfiguracyjnych powiny być już w CVS-ie. Ew. pobrać wersję 2.6.20.1-0.11 z grsec_minimal z http://217.149.245.118/~mguevara/x86_64_RPMS/ :-) 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: Jądro i wrr - dlaczego nie ma tego modułu?
Arkadiusz Machoł wrote: Dlaczego w oficjalnym jądrze dla AC (późniejszych chyba też to dotyczy) nie ma włączonej obsługi schedulera wrr? Czy powodował błędy że z niego zrezygnowano w domyślnej konfiguracji czy co? Wystarczy w konfigu dopisać linijkę: CONFIG_NET_SCH_WRR=m aby został dodany jako moduł. Jeśli to nie problem to proszę jakiegoś developera o dodanie tej funkcjonalności. Domyślnie schedulera WRR nie ma w kodzie jądra - należy zaaplikować odpowiednią łatkę z http://www.zz9.dk/wrr . Testowo dodałem odpowiednią łatkę do wersji 2.6.20.1-0.8 z brancha LINUX_2_6_20 - na razie jest w bcondzie (przy budowaniu trzeba dać opcję '--with wrr'). 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: Jądro i wrr - dlaczego nie ma tego modułu?
Marek Guevara Braun wrote: Testowo dodałem odpowiednią łatkę do wersji 2.6.20.1-0.8 z brancha LINUX_2_6_20 - na razie jest w bcondzie (przy budowaniu trzeba dać opcję '--with wrr'). Do testów http://217.149.245.118/~mguevara/RPMS/ lub http://217.149.245.118/~mguevara/x86_64_RPMS/ 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: [PATCH] kernel-x86_64.config - mały update dl a kernela z brancha LINUX_2_6_20
[EMAIL PROTECTED] wrote: Bez załączonej poprawki kernel z brancha LINUX_2_6_20 nie ma prawa się zbudować na arch x86_64-up. [...] +# CONFIG_PROC_KCORE is not set Budowałeś z --without grsecurity? Domyślnie aktywne jest grsec_minimal które dodaje do .config opcję CONFIG_GRKERNSEC_PROC_ADD=y, a w zależnościach PROC_KCORE mamy: depends on PROC_FS MMU !GRKERNSEC_PROC_ADD Stąd, w domyślnej konfiguracji opcja CONFIG_PROC_KCORE nie powinna być potrzebna, bo domyślnie jest deaktywowana przez CONFIG_GRKERNSEC_PROC_ADD=y, gdy jednak do .config nie dołączymy zawartości kernel-grsec.config (co ma miejsce gdy budujemy z --without grsecurity) to rzeczywiście może brakować opcji PROC_KCORE. 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: TH - madwifi - problem z binutils ?
Pawel Nogas wrote: Dzisiaj zglosilem Zgłoszenie http://madwifi.org/ticket/1140 Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: IMQ_BEHAVIOR w LINUX_2_6_20
Robert Graużenis wrote: Marek Guevara Braun pisze: W każdym razie już to zmieniłem - zadam pytanie na users, której wersji ustawień używają. Warto jeszcze zwiększyć CONFIG_IMQ_NUM_DEVS=2 do maksymalnej wartości czyli 8 chyba. Liczbę urządzeń, jak sprawdziłem maks. 16 - od imq0 do imq15, można ustawić przy ładowaniu modułu imq używając parametru numdevs: modprobe -v imq numdevs=16 Czyli odpowiedni wpis options w /etc/modprobe.conf powinien załatwić resztę. 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: IMQ_BEHAVIOR w LINUX_2_6_20
Robert Graużenis wrote: Czy CONFIG_IMQ_BEHAVIOR_BA=y w jądrze z LINUX_2_6_20 to celowe? Z tego co sobie przypominam od wieków używaliśmy CONFIG_IMQ_BEHAVIOR_AB=y by default. Nie jest celowe i jeśli uprzednio było AB to można/trzeba zmienić. Podejrzewam że BA to domyślne ustawienie IMQ. Pozdrawiam, Marek PS. Zmienić ? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: IMQ_BEHAVIOR w LINUX_2_6_20
Arkadiusz Miskiewicz wrote: On Friday 23 of February 2007, Marek Guevara Braun wrote: Robert Graużenis wrote: Czy CONFIG_IMQ_BEHAVIOR_BA=y w jądrze z LINUX_2_6_20 to celowe? Z tego co sobie przypominam od wieków używaliśmy CONFIG_IMQ_BEHAVIOR_AB=y by default. [...] PS. Zmienić ? Nie wiadomo. W jednych PLDowych jajkach jest AB, w innych BA :/ W każdym razie już to zmieniłem - zadam pytanie na users, której wersji ustawień używają. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: X11-driver-firegl.spec - Version 8.34.8. Fails to bouild on...
Piotr Budny wrote: Dnia piątek, 23 lutego 2007, matkor napisał: $Log$ +Revision 1.145 2007/02/23 09:59:31 matkor +- Version 8.34.8. Fails to bouild on 2.6.20 from LINUX_2_6 branch. Problem da się rozwiązać za pomocą drobnych modyfikacji źródeł fglrx, teraz pytanie, czy dodawać tego patcha, aby poprawnie się budowało na 2.6.20 (i chyba 2.6.19)? Zastanawiam się, bo może to zepsuć budowanie na kernelach niższych. Do 2.6.19 budować powinna się już wcześniejsza wersja sterowników (w 8.33.6 dodano wsparcie dla 2.6.19) Aby nie zepsuć budowania na niższych kernelach warto łatany kod opakowywać w if-y: #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20) ... tu nowy kod ... #else ... tu stary kod ... #endif Pozdrawiam, Marek PS. Oczywiście dodawać! ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: layer7
Marek Guevara Braun wrote: Do poprawy dla SMP są jeszcze TARPIT, ROUTE i ip6t_ROUTE - dla UP powinno być OK. Ha, zmienił się wykorzystywany lock ze spinlock na seqlock, a funkcje zostały dla spinlock-ów ... damy radę. Poprawione. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: layer7
Wojciech Sas Cieciwa wrote:
Charles wrote:
Sorry, ale nie bardzo.
2.6.16.x używam na kompach, gdzie nie mogę sobie pozwolić na testowanie.
Dodałem l7, bo taka się pojawiła potrzeba na jednym z nich (a nadal linia
2.6.16 obowiązuje w AC).
Zdecydowanie wspomniana wcześniej linia 2.6.20 z brancha LINUX_2_6_20
jest linią, testową. W stosunku do standardowej funkcjonalności kernela
z PLD jeszcze tam sporo brakuje (np. nie ma całkowicie grsecurity,
ale przede wszystkim jest to nadal bardzo świeży kernel i nie wszystko
jeszcze tam okrzepło, no i na razie konfigi zaktualizowane tylko dla
i{3,5,6}86).
Osobiście używam tej linii na 2 produkcyjnych komputerach (jednej
maszynie obsługującej vsrvery i na laptopie) oraz na maszynie wirtualnej
VMware. Są to jednak maszyny, które jestem sam w stanie szybko odtworzyć
w razie niespodziewanej awarii.
Obowiązuje, bo tuż przed wydaniem 2.6.17 w modułach netfilter-a została
zrobiona czystka i bardzo wiele z nich zostało usuniętych bez
jakichkolwiek zamienników.
Dla linii 2.6.20 (a w zasadzie robiłem to dla 2.6.19) pododawałem (nie
wszystkie) standardowo niebudujące/niedziałające od .17/.18 rzeczy z
pom-ng, imq, l7 - testowałem z tego tylko connlimit - stąd zachęcam do
sprawdzenia takich rzeczy około-netfilterowych jak: IPV4OPTSSTRIP,
ipv4options, set, u32, ROUTE, TARPIT, mms-conntrack-nat, rsh, IPMARK,
connlimit, geoip, ipp2p, time oraz layer7, imq i esfq.
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: layer7
Wojciech Sas Cieciwa wrote: Marek Guevara Braun wrote: [...] zachęcam do sprawdzenia takich rzeczy około-netfilterowych jak: IPV4OPTSSTRIP, ipv4options, set, u32, ROUTE, TARPIT, mms-conntrack-nat, rsh, IPMARK, connlimit, geoip, ipp2p, time oraz layer7, imq i esfq. Rozumiem, że da tych których niema juz w oficjalnym repo netfiltera przepisywałeś cały kod ? Przygotowałem tylko wyżej wymienione, pochodzące z base, extra jak i external - w większości była to kosmetyka w postaci usunięcia z kodu nieużywanych argumentów funkcji match/target, w connlimit zrobiłem zmianę z ip_conntrack na nf_conntrack - nie było to oczywiście przepisanie całego kodu, a jedynie zmiana odwołań do odpowiedników funkcji/atrybutów z nf_conntrack (a kod nf_conntrack jest wzięty właśnie z ip_conntrack), w layer7 pamiętam że był problem z zapisywaniem stanu w skbufie w funkcji typu match, która miała mieć argument typu const - myślałem żeby klonować skbuf, ale później doszedłem do wniosku że nie było by to najmądrzejsze i nadal modyfikujemy przekazywany do funkcji skbuf. W kilku miejscach używany kod zastąpiony został wydzielonymi funkcjami - ale nie było to nic czego diff i grep nie potrafiły by odnaleźć, a lwn.net opisać. Bo oficjalnym powodem czystek była zmiana NET API i brak ludzi utrzymujących poszczególne moduły up-to-date. Zmiana ta (przynajmniej dla conntracka) to odejście od dublujących się, specyficznych dla ipv4 i ipv6 funkcji na bardziej ogólne, które mogły by być niezależne od protokołu. Co do czystki w pom-ng to się nie wypowiem, ale kiedyś modułów było trochę więcej - czy część z nich nie przeszła do oficjalnego kernela? 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: layer7
Marek Guevara Braun wrote: pom-ng, imq, l7 - testowałem z tego tylko connlimit - stąd zachęcam do sprawdzenia takich rzeczy około-netfilterowych jak: IPV4OPTSSTRIP, ipv4options, set, u32, ROUTE, TARPIT, mms-conntrack-nat, rsh, IPMARK, connlimit, geoip, ipp2p, time oraz layer7, imq i esfq. Odszczekuje layer7 - mam to dla 2.6.19.1 - na 2.6.20 jeszcze nie. Z rzeczy które były w pom-ng w 2.6.20 nie ma jeszcze: * conntrack_nonat - ale on potrzebuje nieznanego conntrack_locking * mms-conntrack-nat - jak sprawdziłem dla 2.6.19.1 mi sie budowało dla 2.6.20 automagicznie nie - pewnie to samo co z connlimitem - zależność od niebudującego się ip_conntrack * quake3-conntrack-nat * rpc * rtsp-conntrack * talk-conntrack-nat Do poprawy dla SMP są jeszcze TARPIT, ROUTE i ip6t_ROUTE - dla UP powinno być OK. 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: layer7
Marek Guevara Braun wrote: Odszczekuje layer7 - mam to dla 2.6.19.1 - na 2.6.20 jeszcze nie. Huh. to już poprawione :-) Z rzeczy które były w pom-ng w 2.6.20 nie ma jeszcze: * conntrack_nonat - ale on potrzebuje nieznanego conntrack_locking Tu nie mam pomysłu - zastępuje go NOTRACK ? * mms-conntrack-nat - jak sprawdziłem dla 2.6.19.1 mi sie budowało dla 2.6.20 automagicznie nie - pewnie to samo co z connlimitem - zależność od niebudującego się ip_conntrack Dokładnie, po wyborze nf_conntrack wszystko co miało zależności od ip_conntracka po cichu się wyłączyło podczas make oldconfig, a mnie umknął brak kilku pozycji w kernel-netfilter.config. * quake3-conntrack-nat * rpc * rtsp-conntrack * talk-conntrack-nat Tu pewnie trzeba by trochę posiedzieć. Do poprawy dla SMP są jeszcze TARPIT, ROUTE i ip6t_ROUTE - dla UP powinno być OK. Ha, zmienił się wykorzystywany lock ze spinlock na seqlock, a funkcje zostały dla spinlock-ów ... damy radę. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: layer7
Charles wrote: Dnia czwartek 15 lutego 2007, Przemysław Backiel napisał: czy layer 7 bedzie w kernelu? czy wyleciał na dobre? jednak brakuje go :) Wrócił do 2.6.16.40 Możesz przetestować również wersję 2.6.20 z http://217.149.245.118/~mguevara/RPMS/ W 2.6.19 również powinien być. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - new vserver patch (based on vs...
Krystian Tomczyk wrote: Miałbym jeszcze jedną prośbę - jakby tonie był duży kłopot to bym prosił o xorg-driver-video-nvidia-1.0.9746-2.i686.rpm lub [EMAIL PROTECTED] bo brakuje mi do kompletu... Niestety na moim builderze nie mam zależności do budowania xorg z Th. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - new vserver patch (based on vs...
Krystian Tomczyk wrote: Ja mam takie coś # /etc/rc.d/init.d/vprocunhide start Fixing vservers /proc entries visibility...[ BUSY ]chdir(): Invalid argument lstat(): No such file or directory ... lstat(): No such file or directory Też tak mam. Trzeba się będzie temu przyjrzeć. # vserver apache-ac build --context 3 -m poldek -n apache-ac -- -d pld-ac [ DONE ] [...] error: Failed dependencies: /etc/localtime is needed by tzdata-2006p-1.noarch vpoldek failed on vserver '/etc/vservers/apache-ac' with errorcode 1 U mnie jest ok. A vserver pld-th rzuca takim czymś ERROR: ld.so: object '/usr/lib/util-vserver/rpm-fake.so' from LD_PRELOAD cannot be preloaded: ignored. i potem mam wiszące procesy (i to całe mnóstwo) 3169 ?Z 0:00 [rpm-fake-resolv] defunct Kernel z http://217.149.245.118/~mguevara/RPMS/ Przed chwilą wrzuciłem tam wersję 0.5 z vserverem 2.2.0-pre3. W tej wersji poprawione są wspomniane wcześniej rzeczy związane z usuwaniem procesów. # uname -a Linux kamionet 2.6.20-0.4 #1 Thu Feb 8 02:54:53 CET 2007 i686 AMD_Athlon(tm)_XP_1500+ PLD Linux util-vserver-lib-0.30.212-4.i686 util-vserver-0.30.212-4.i686 util-vserver-init-0.30.212-4.i686 util-vserver-build-0.30.212-4.i686 # uname -r 2.6.20-0.5 Reszta troche starsza: util-vserver-lib-0.30.212-1 util-vserver-0.30.212-1 util-vserver-init-0.30.212-1 util-vserver-build-0.30.212-1 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: kernel 2.6.20 i vserver
Marek Guevara Braun wrote: [source] name = kernel-test type = pndir path = http://217.149.245.118/~mguevara/RPMS/ Pod ww. zasobem umieściłem wersję 2.6.20-0.5 z poprawioną wersją vservera. Podobnie jak poprzednio wersja budowana z opcjami --without grsecurity --with vesafb_tng -r LINUX_2_6_20 Marek PS. Wersje źródłowe znajdują się w naszym cvs/distfiles oraz http://217.149.245.118/~mguevara/SRPMS/ ___ 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.20 i vserver
Marek Guevara Braun wrote: Marcin Kierus wrote: Wygląda na to że coś jest nie tak z patchami vserver dla kernel'i od 2.6.20rc6 (LINUX_2_6_20) w górę. Nie działa zupełnie kill co skutkuje tym że nie da się zabić żadnego procesu, nawet z -9. [...] obecnie testowo buduje wersję vs2.2.0-pre1 z 6 lutego 2007 (czyli chyba nowszą niż vs2.2.0-rc11) - jeśli się wszystko powiedzie jutro rano zrobię krótkie testy i wystawie pakiety z 0.4 na ftp/http. Wersja ta się ładnie zbudowała i jak widzę nie ma wspomnianej wyżej przypadłości. Funkcjonalności samego vservera nie nie miałem okazji jeszcze sprawdzać. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - new vserver patch (based on vs...
Jan Rekorajski wrote: - new vserver patch (based on vs2.2.0pre1 instead of vs2.3.0.6) To bardzo zly pomysl. Wystarczy popatrzec w Kconfig. A dokładnie brak jakiej funkcjonalności Cię tak niepokoi? Marek ___ 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.20 i vserver
Marek Guevara Braun wrote: wersję vs2.2.0-pre1 z 6 lutego 2007 (czyli chyba nowszą niż vs2.2.0-rc11) - jeśli się wszystko powiedzie jutro rano zrobię krótkie testy i wystawie pakiety z 0.4 na ftp/http. Wersja ta się ładnie zbudowała i jak widzę nie ma wspomnianej wyżej przypadłości. Funkcjonalności samego vservera nie nie miałem okazji jeszcze sprawdzać. Dla zainteresowanych testami: [source] name = kernel-test type = pndir path = http://217.149.245.118/~mguevara/RPMS/ Jest tam wersja zbudowana dla i686 z opcjami --without grsecurity --with suspend2 --with vesafb_tng -r LINUX_2_6_20 Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - new vserver patch (based on vs...
Jan Rekorajski wrote: On Thu, 08 Feb 2007, Marek Guevara Braun wrote: A dokładnie brak jakiej funkcjonalności Cię tak niepokoi? W tej chwili ci nie powiem (ale roznice sa), bardziej mnie niepokoi zmiana lini uzywanej przez nasze kernele. Tego sie nie robi zwlaszcza jak sietego nie uzywa (bo domyslam sie ze z vservera nie kozystasz?). Ależ używam - z tym że wersja bazująca na 2.3.0.6 miała, zgłaszny na tej liście, feler związany z nie usuwaniem zabijanych procesów (zarówno wewnątrz, jak i na zewnątrz vservera) - niby wszystko działało, ale procesów przyrastało. Wyglądająca na bardziej aktywnie rozwijaną wersja bazująca na 2.2.0-pre1 usunęła ten problem dla normalnego systemu - choć wewnątrz vserverów kilowane procesy nadal odkładają sie jako defunct (i jak na razie widzę że jest to jedyny feler tej wersji). Obecnie sprawdzam wersję opartą na 2.2.0-pre3 - różnice wyglądają dobrze. Jeśli będzie ok, to zmiany można będzie przenieść do 2.3.0.6/8. BTW juz dawno byla mowa (tutaj) ze vserver i suspend2 wlaczamy _bez_ bcondow. I są one domyślnie włączone - bcondy dodałem gdy nie mieliśmy działających ani suspend2 ani vserver, by móc doprowadzić moduły z patch-o-matic do stanu używalności. Teraz można je pewnie usunąć, ale z tym bym się nie spieszył. 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: kernel 2.6.20 i vserver
Marcin Kierus wrote: Hej, Wygląda na to że coś jest nie tak z patchami vserver dla kernel'i od 2.6.20rc6 (LINUX_2_6_20) w górę. Nie działa zupełnie kill co skutkuje tym że nie da się zabić żadnego procesu, nawet z -9. Z jednej strony potwierdzam (kilowanie daje mi w efekcie wiszący proces wyświetlany przez ps w []) z drugiej strony na przykładzie apache (wewnątrz vservera) `service httpd stop` kończy się niepowodzeniem, pozostaje mi wiszący jeden proces httpd root-a - te użytkownika http znikają. Co ciekawe mogę ponownie uruchomić httpd i działa - choć każdy restart dodaje po jednym wiszącym procesie (jak robię pkill -9 httpd.prefork to dostaje również wiszące wszystkie procesy potomne) to nie blokują one np. socketów. Z innych rzeczy niezabijalnych a działających po restarcie sprawdzałem dhcpd, hostapd i wpa_supplicant (i prawdę mówiąc nie wpadłem na to że to kernel/vserver jest źródłem problemów - cały czas myślałem że to efekt mojej walki z madwifi-ng i old-openhal) W każdym bądź razie vserver który jest w 2.6.20 - do rel 0.3 bazuje na starym patchu vs2.3.0.6 z 29 grudnia 2006 - obecnie testowo buduje wersję vs2.2.0-pre1 z 6 lutego 2007 (czyli chyba nowszą niż vs2.2.0-rc11) - jeśli się wszystko powiedzie jutro rano zrobię krótkie testy i wystawie pakiety z 0.4 na ftp/http. Pozdrawiam, Marek PS. Z komercyjnych rzeczy działających mi na 2.6.20 mam vmware-server (chyba pod rc6) a z lokalnego tutorialu Javy macha mi taki trójkątny ludzik-applet w Firefoxie (pod pełną wersją 0.3 obecnie). rpm -q java-sun java-sun-1.6.0-1 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: TH - madwifi - problem z binutils ?
Pawel Nogas wrote: Problem pojawil sie w binutils-2.17.50.0.10, poprzednie wersje dzialaja prawidlowo. Zgłaszałeś to może na http://madwifi.org/wiki/TicketSubmissionGuidelines ? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kernel-i386-smp.config
Paweł Sikora wrote: Author: mguevara Date: Wed Jan 31 00:03:50 2007 GMT Module: SOURCES Tag: LINUX_2_6_20 Log message: - irqbalance disabled poniewaz? Opieram się na opinii bluesa, że zamiast tego lepiej używać irqbalance z irqbalance.spec. http://lkml.org/lkml/2006/7/31/216 - nadal aktualne ? Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: wanpipe.spec - 2.3.4-4
areq wrote: SPECS: wanpipe.spec (1.36 - 1.37) Jak to się ma w stosunku do pozycji wanpipe z listy TODO w kernel.spec na LINUX_2_6 (i innych z tej rodziny) - zastępuje, jest uzupełnieniem ? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 2.6.20rc5 na TH
Marek Guevara Braun wrote: Testowo podniosłem u siebie wersję binutils do 2.17.50.0.9 z HEAD i jeszcze raz puściłem budowanie na Ac. Dla gcc 3.3.6 i binutils 2.17.50.0.9 budowane w środowisku Ac 2.6.20-rc5 robi się i działa, tak że wspomniane wyżej problemy nie są spowodowane wersją ld, a raczej tak jak pisze arekm, najnowszym gcc 4.2. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - rel 0.3 or 2.6.20-0.rc4.0.3 - ...
Michal Abramowicz wrote: Zdaje się, że ja mam slmodem, w dellu. Jakby co mogę sprawdzić. slmodem powinien być już poprawiony na HEAD w cvs. Budowałem go z opcją --without smp. 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: 2.6.20rc5 na TH
Lukasz Glebicki wrote: On Monday 15 January 2007 00:46, Arkadiusz Patyk wrote: undefined! [...] Pytanie retoryczne? Nie do końca, bo na gcc 3.3.6 i ld z binutils 2.15 nie są już takie undefined - wszystko ładnie sie buduje (na Ac). Starsza wersja ld z binutils 2.17 ponoć wycinała jakieś symbole, ale 2.17.50.0.9 miała być ok. Testowo podniosłem u siebie wersję binutils do 2.17.50.0.9 z HEAD i jeszcze raz puściłem budowanie na Ac. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6_20): kernel.spec - rel 0.3 or 2.6.20-0.rc4.0.3 - ...
Arkadiusz Miskiewicz wrote: On Wednesday 10 January 2007 02:38, mguevara wrote: - adds linux-2.6.20_i386_regparm_off.patch for compatibility with some HAL Działa np. z slmodem? Przetestuj lepiej z modułami binarnymi dla tych pakietów które trafiły do ac (to i trafią do Th)... Zdaje się, że zabawa z regparm jest albo w jedną albo drugą stronę - obu na raz się nie pogodzi. nvidia (9631) działa w obydwu trybach, madwifi-ng tylko dla wyłączonego regparm - co jak do tej pory było domyślną konfiguracją ustawianą przez opcję CONFIG_REGPARM którą mieliśmy 'not set'. Zakładam, że jeśli mamy jakieś bloby, które działały z naszymi starymi kernelami to działały w starym trybie - nawet stare sterowniki nvidii kiedyś nie chciały działać w nowym trybie. W 2.6.20-rc... dla i386 domyślnie jest ustawione regparm=3 w opcjach budowania jądra, a CONFIG_REGPARM wyleciało jako niepotrzebne. Ze sprzętu który mam, mogę jeszcze sprawdzić nvidia-legacy (choć to jest też nowe i też pewnie będzie działało w obydwu trybach) no i ati, ale ati na razie się nie buduje bo używa makr _syscall2 i _syscall3, które też wyleciały z 2.6.20. Mogę zbudować slmodem, ale bez sprzętu trudno będzie coś przetestować - dla madwifi-ng jedyną oznaką niekompatybilności z nowym trybem jest niewykrywanie sprzętu przez załadowany moduł. Pozdrawiam, Marek PS. A co do madwifi to w ich svn-ie jest ciekawie wyglądajacy brach dadwifi-openhal i pliczek madwifi-free z OpenHALem z OpenBSD. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: nvidia-97xx
havner wrote: Legacy nie ma tej poprawki bezpieczenstwa o ktorej glosno bylo, Wersja legacy nie potrzebowała tej poprawki (o ile piszemy o tym samym błędzie) - tak przynajmniej twierdzi nvidia. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: rpm-build-macros-1.341-1 - napewno jest OK ?
Arkadiusz Patyk wrote: $ cat /usr/src/linux/include/linux/utsrelease.h #define UTS_RELEASE 2.6.19.1-0.1smp czy to nie to: http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/kernel.spec?r1=1.441.2.1659r2=1.441.2.1660 dodalem sed -i 's:smp::' include/linux/utsrelease.h.save co powinno zalatwic ten problem dla modułów budowanych jako pakiety. Nie wiem czy nie zepsuje czegoś dla modułów budowanych ręcznie w środowisku smp. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6): kernel.spec - 2.6.19 work in progress - not yet...
Jan Rekorajski wrote: Nie masz najbledszego pojecia co robisz. Poszukaj w archiwum list, AFAIR Wojtek pisal na czym polega problem. Hint: netfilter API Hint2: to ze cos jest w p-o-m-ng nie znaczy ze jest aktualne No to ciekawe co piszesz, a u mnie w międzyczasie zbudowały się moduły netfilter takie jak: net/ipv4/netfilter/ipt_IPMARK.ko net/ipv4/netfilter/ipt_IPV4OPTSSTRIP.ko net/ipv4/netfilter/ipt_ROUTE.ko net/ipv4/netfilter/ipt_TARPIT.ko net/ipv4/netfilter/ipt_connlimit.ko net/ipv4/netfilter/ipt_geoip.ko net/ipv4/netfilter/ipt_ipp2p.ko net/ipv4/netfilter/ipt_ipv4options.ko net/ipv4/netfilter/ipt_layer7.ko net/ipv4/netfilter/ipt_set.ko net/ipv4/netfilter/ipt_time.ko net/ipv4/netfilter/ipt_u32.ko Oczywiście musiałem trochę pogrzebać po patchach wygenerowanych z pom-ng, ale sorry większość zmian to kosmetyka typu zmiana funkcji skb_ip_make_writable na skb_make_writable dla IPV4OPTSSTRIP, czy też masowe wywalenie nieistniejącego #include linux/config.h. Zresztą zobacz moje dzisiejsze zmiany patchy nie tylko około netfilterowych na LINUX_2_6. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6): kernel.spec - 2.6.19 work in progress - not yet...
Jan Rekorajski wrote: Bo widzisz, problem nie polega na tym ze te moduly sie nie kompiluja. Problem polega na tym ze one maja zle interfejsy i proba ich uzycia w najlepszym przypadku spowoduje ze modprobe cie opluje, a w najgorszym oops i zwis. Zwroc uwage na warningi jakie sa przy ich kompilacji, akurat w przypadku netfiltra mozna je spokojnie traktowac jako bledy. Popatrz na naglowki metod target/match np. TARPIT i LOG. set i geoip wyglądają dobrze reszta z pom-ng i l7 jeszcze nie. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [LINUX_2_6] section mismatch warnings dla 2.6.19.1
Bartosz Świątek wrote: drivers/atm/fore_200e.o drivers/atm/horizon.o drivers/atm/lanai.o drivers/atm/zatm.o drivers/char/istallion.o drivers/net/rrunner.o drivers/net/sis900.o drivers/net/sunhme.o drivers/net/tokenring/3c359.o drivers/net/tulip/de2104x.o Na alphie się one w ogóle nie zbudują wywołując błędy. Ze względu na wspomniane błędy, czy też nie są w ogóle przygotowane dla alphy? To może je wyłączyć w konfigach dla tej architektury? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS (LINUX_2_6): kernel.spec - 2.6.19 work in progress - not yet...
Jan Rekorajski wrote: Popatrz na naglowki metod target/match np. TARPIT i LOG. Wrzuciłem jeszcze poprawki do ipp2p i layer7 - to ostatnie może niezbyt optymalne, bo stosuje skb_copy dla sk_buff w match by zapewnić aby argument funkcji był const - standardowe zachowanie layer7 to mazanie po tej strukturze na lewo i prawo. Do zastanowienia się zastosowaie skb_clone albo po prostu rzutowania na zmienną nie const. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: X11-driver-nvidia-legacy.spec - workaround for builder auto...
hawk wrote:
+%bcond_with grsec_kernel# build for kernel-grsecurity
+#
+%if %{with kernel} %{with dist_kernel} %{with grsec_kernel}
+%define alt_kernel grsecurity
+%endif
Czyli dla innych alt_kernel trzeba będzie też dodawać odpowiednie bcondy?
Pozdrawiam,
Marek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: moc.spec - up to 2.4.1
Jakub 'teodor' Krajniak wrote: On 11/8/06, Marek Guevara Braun [EMAIL PROTECTED] wrote: teodor wrote: Author: teodor Date: Tue Nov 7 14:16:08 2006 GMT Module: SPECS Tag: HEAD Log message: - up to 2.4.1 Czy poza killed by SIGSEGV (2 maszyny z AC) nowy mocp ma jakąś ciekawą funkcjonalność ? http://moc.daper.net/changelog#2.4.1 na Th się kompiluje i działa, hm a jak on się na AC-branch dostał to /me nie wie ok. doszedłem - jak user nie ma ustawionego HOME_ETC to funkcja void options_init () wykonuje char* moc_dir = getenv(HOME_ETC); i przypisuje NULL, następnie wykonujemy strcat(moc_dir,/.moc); i mamy SIGSEGV :-) ustawienie HOME_DIR pomaga. Pewnie patch do poprawy: jak getenv(HOME_ETC) da NULL to brać $HOME... Pozdrawiam, Marek PS. Czy strcat(moc_dir,/.moc) nie nadpiszemy kolejnych wpisów zmiennych środowiskowych ? Nie boli nas to ? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: moc.spec - up to 2.4.1
Marek Guevara Braun wrote: ustawienie HOME_DIR pomaga. - HOME_ETC oczywiście ___ 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): X11-driver-nvidia.spec - 1.0-8776-0.1
Marek Guevara Braun wrote: bartosz swiatek wrote: 06-10-21, Marek Guevara Braun [EMAIL PROTECTED] napisał(a): Jak ktoś(TM) sprawdzi to pewnie podbije rela i usunie banery. Ten(TM) kto(TM) podbija wersję, powinien sprawdzić czy baner jest aktualny, prawda ? Nie - sprawdzi czy exploit działa. Tj chciałem napisać SOD#1 ___ 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): X11-driver-nvidia.spec - 1.0-8776-0.1
bartosz swiatek wrote: - 1.0-8776-0.1 X11-driver-nvidia.spec (1.78.2.4 - 1.78.2.5) Hmm. A czy tu nie powinien już zostać usunięty ten banner ? Nie jest to wersja bugfixowa do poprzedniej ? Jak ktoś(TM) sprawdzi to pewnie podbije rela i usunie banery. Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: xorg-driver-video-nvidia.spec - 1.0-9626 - rel 0.1 `cause i...
shadzik wrote: Author: shadzik Date: Wed Oct 18 19:07:46 2006 GMT Module: SPECS Tag: HEAD Log message: - 1.0-9626 - rel 0.1 `cause it's still beta Pomimo że wersji 1.0-9626 nie ma na oficjalnej stronie ze sterownikami NVIDIA to myślę że nie jest to już beta - sterowniki mają własną stronę, z tym że są tam prezentowane jako NVIDIA Quadro Plex Driver, a nie jako dotychczasowe Linux Display Driver: http://www.nvidia.com/object/linux_display_ia32_1.0-9626.html Strona ta jest wskazywana na stronie Linux Display Driver Archive http://www.nvidia.com/object/linux_display_archive.html PS. Oczywiście poza wpisem pracownika NVIDII na forum, nikt się oficjalnie nie przyznaje do naprawienia ostatniego buga. Pozdrawiam, Marek PS2. Trzeba by sprawdzić jak wygląda splashscreen - ponoć sterowniki beta mają napis beta na splashu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: xorg-driver-video-nvidia.spec - 1.0-9626 - rel 0.1 `cause i...
Marek Guevara Braun wrote: http://www.nvidia.com/object/linux_display_ia32_1.0-9626.html Jako uzupełnienie podam, że strona wersji 1.0-9626, jest dostępna z oficjalnej strony sterowników http://www.nvidia.com/content/drivers/drivers.asp w menu START HERE: Graphics Driver - Quadro - Linux IA32 - Go! A potem na stronie pod nagłówkiem Quadro Plex. Można też zajrzeć na ftp://download.nvidia.com/XFree86/Linux-x86/ Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: odwrócenie bconda pax w glibc
Zbyniu Krzystolik wrote: Mniej wiecej Thu, Sep 28, 2006 at 12:49:11AM +0200, zainteresowany Marek Guevara Braun rzekl: Arkadiusz Miskiewicz wrote: On Wednesday 27 September 2006 21:43, Paweł Gołaszewski wrote: Bo wtedy nikt nie miałby myślę nic przeciwko temu. Domyślne działanie softmode jest takie, że bez opcji pax_softmode=1 pax jest aktywowany (tj. domyślny jest pax_softmode=0). Dopiero po podaniu 1 dla tej opcji funkcje PaX są wyłączone. Tak to sobie PaX Team wymyślił. Zmiana tego zachowania powinna być trywialna, nie sprawdzałem, ale na na pierwszy rzut oka łatka z załącznika powinna wystarczyć. Zapewnie to by wystarczyło, ale wolałbym by opcja ładowania jądra pax_softmode i wartości w /proc/sys/kernel/pax/softmode miały oryginalne (choć i tak słabo udokumentowane) znaczenie. Z drugiej strony, po krótkim zastanowieniu nie jestem przekonany, czy softmode == 1 całkowicie deaktywuje PaX - np. dla architektury z aktywnym SEGMEXEC (32-bit x86) mamy 1/2 przestrzeni adresowej dla procesu - ponieważ softmode (o ile jest skonfigurowane) można w(y)łączyć w dowolnej chwili oznaczało by to możliwość gwałtownego zwiększenia/zmniejszenia przestrzeni adresowej procesu - co raczej nie ma miejsca. Nawet jeśli odwołania do niewłaściwego segmentu nie będą powodować zabicia aplikacji to więcej pamięci IMO nie uzyskamy. Podobnie z opcjami dotyczącymi przestrzeni adresowej samego jądra - tego podejrzewam nie da się przełączyć w biegu (ale u nas i tak jest to domyślnie wyłączone/nietestowane, choć podobno już działa z modułami). Dla PAGEEXEC nie mam pojęcia - dla architektur z bitem NX podobno nie ma nawet różnicy w wydajności *), a przetrzeń adresowa procesu powinna być cała - być może w tym przypadku softmode == 1 jest dokładnym odpowiednikiem braku PaX-a. Pozdrawiam, Marek *) http://www.pjvenda.org/linux/doc/pax-performance/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: odwrócenie bconda pax w glibc - upgrade do glibca bez wsparcia dla pax
Piotr Zięcik wrote: 1. Glibc bez PaX na maszynie bez PaX: Działa. 2. Glibc bez PaX na maszynie z PaX: Nie działa. 3. Glibc z PaX na maszynie bez PaX: Działa. Łata powoduje ignorowanie błędu EACCES wywołania mprotect(). Wg. dokumentacji na systemie bez PaX taki błąd może być zwrócony w zasadzie tylko na życzenie użytkownika: The memory cannot be given the specified access. This can happen, for example, if you mmap(2) a file to which you have read-only access, then ask mprotect() to mark it PROT_WRITE. 4. Glibc z PaX na maszynie z PaX: Działa. Problem jest w wypadku, gdy z glibc'a ktoś usunie się tą łatę i punkt (4) redukuje się do (2) ze skutkiem natychmiastowym. Właśnie sprawdziłem na maszynie z aktywnym PaXem z 2.6.17.13-3 - zdowngradowałem poldkiem glibc do wersji bez poprawki paxowej i: - system nadal pracuje, - mogę dalej używać poldka (zupgradowałem openssh-*) - nie mogę się zalogować na konsoli :-( - nie mogę się zalogować via ssh :-( - działa moja stara sesja ssh - nadal jestem zalogowany :-) - działa moja stara sesja na konsoli :-) - przy restarcie sshd nowy daemon jest ubijany :-( - o ile nie próbuje zrestartować sshd to ten nadal działa :-) - mogę wyjść z poldka i przejść do shella - nie mogę ponownie uruchomić poldka - mogę na uprzednio zalogowanej sesji aktywować softmode via echo 1 /proc/sys/kernel/pax/softmode - z aktywnym softmode mogę się logować lokalnie i via ssh (o ile nie restartowałem sshd), uruchomić poldka i przywrócić dobrego glibca. - po instalacji dobrego glibca mogę ponownie wyłączyć softmode echo 0 /proc/sys/kernel/pax/softmode Czyli o ile zbyt szybko nie opóścimy shella w którym jesteśmy zalogowani upgradując glibca to możemy włączyć softmode i uratować system. 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: odwrócenie bconda pax w glibc - upgrade do glibca bez wsparcia dla pax
Miało być tak: Czyli o ile zbyt szybko nie opuścimy shella w którym jesteśmy zalogowani upgradując glibca to możemy włączyć softmode i uratować system. 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: odwrócenie bconda pax w glibc - upgrade do glibca bez wsparcia dla pax
Piotr Zięcik wrote: O ile mamy skompilowaną obsługę soft mode i sysctli grsec'a. Co więcej te ostatnie musza być odblokowane (a w przypadku ich istnienia zaleca się je zablokować po ustawieniu parametrów). Można jeszcze sprawdzić gradma - czy da się przejść w tryb administracyjny przy podmienionym glibcu (nawiasem mówąc instalki/upgrady warto chyba robić po przejściu w tryb administracyjny w via gradm, bo normalnie podmiana softu też może/powinna być blokowana przez RBAC). 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: odwrócenie bconda pax w glibc
Piotr Zięcik wrote: 3. Glibc z PaX na maszynie bez PaX: Działa. [...] O i o to mi chodziło - dzięki. Problem jest w wypadku, gdy z glibc'a ktoś usunie się tą łatę i punkt (4) redukuje się do (2) ze skutkiem natychmiastowym. Warning w specu zostanie umieszczony. Poza tym trzeba będzie zwiększyć czujność rewolucyjną. 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: odwrócenie bconda pax w glibc
Piotr Zięcik wrote: Owszem. Ale po takim upgradzie maszyny nie zrestartujesz (ba, w ogóle nie wykonasz żadnego polecenia). A ja mam maszyny 60 km od siebie ... Jeśli mamy własny kompilat glibca, zbudowany z opcją --with pax, a domyślnie ta opcja byłaby wyłączona, to i tak nie można w ciemno upgradować takiej maszyny, bo np. za chwilę pojawi się w poldku nowy release danej biblioteki i po upgrade system nie działa. Rozwiązania tu widzę raczej administracyjne (1) dodanie glibca, zlib i ew. paxctl do listy hold w poldku (2) dodanie do poldka tylko własnych punktów dystrybucji/builderów, które produkują dobre pakiety (3) dodanie jakiegoś watchdoga/zdalnego resetu do serwerów, albo lepiej karty zdalnego dostępu do poziomu BIOS maszyny (można edytować gruba przy starcie) (4) zainwestowanie w większy dysk, vmware serwer i testowanie upgradów przed zdalną implementacją. Nawet gdy --with pax było by dalej (tak jak jest obecnie) domyślnie wyłączone, nic nie stoi na przeszkodzie, że ktoś edytując speca wywali/zepsuje odpowiednią łatkę, albo odpowiednio skompilowana, nowa wersja będzie po prostu błędna. Pozdrawiam, Marek PS. Pewnym ułatwieniem, byłoby dodanie jakiegoś provides do glibca i zliba --with pax, ale nie za bardzo widzę co musiało by mieć odpowiednie requires - bo kernel-pax to trochę bez sensu, a paxctl, to pewnie by się automatycznie odinstalowało :-) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: odwrócenie bconda pax w glibc
Arkadiusz Miskiewicz wrote: On Wednesday 27 September 2006 21:43, Paweł Gołaszewski wrote: Bo wtedy nikt nie miałby myślę nic przeciwko temu. Domyślne działanie softmode jest takie, że bez opcji pax_softmode=1 pax jest aktywowany (tj. domyślny jest pax_softmode=0). Dopiero po podaniu 1 dla tej opcji funkcje PaX są wyłączone. Tak to sobie PaX Team wymyślił. Tak jak z grsecurity ? ;) Takiego rozwiązania brakuje nieco w Spenderowym RBAC-u (aka grsecurity). Z moich obserwacji softmode całkowicie deaktywuje pax-a - od 2 miesięcy używam 2 systemów na 2.6.16.27 z PaX w soft_mode, uruchamiałem na nich stare X-y (6.9), mplayera, javę, firefoxa z flashem, asemblerowego zliba, glibca bez wsparcia dla pax, VMware Server z Windows XP, oraz Linuksem 2.6.16.28 z aktywnym paxem, kilka maszyn pod VServerem i nie zauważyłem żadnych problemów - nic się nie kilowało, itp. 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: odwrócenie bconda pax w glibc
Kosmo wrote: Cytowanie Marek Guevara Braun [EMAIL PROTECTED]: Czy są jakieś przeciwwskazania odnośnie domyślnej aktywacji łatek PaX w glibc? 1. Wymaganie paxctl do budowania (da się ominąć ustawiając glibc-pax-build.patch jako bcond) Tak by było lepiej. 2. TAAAKI zonk, jak komuś się nie będzie chciało updateować patchy i je wywali z glibc'a - system po prostu staje i trzeba go ratować z rescue Jeżeli PaX jest zbudowany ze wsparciem dla softmode (a tak jest dla LINUX_2_6_16 z --with pax i tak też chce zrobić dla LINUX_2_6_17) to przy starcie kernela grub/lilo/etc można dodać opcję pax_softmode=1 i wtedy wszelkie ustawienia MEMPROTECT które powodują niewstawanie systemu z niepaxowymi zlib i glibc są domyślnie wyłączone - tj. system jako taki wstanie, ale bez ochrony PaX (o ile nie włączymy jej paxctl dla wskazanych binarek). instalując poprzednią wersję glibc'a (a jak nie ma na FTP to trzeba kompilować). Niestety taki wypadek w PLD już był i kosztawał mnie całkiem sporo: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/glibc.spec.diff?r1=1.568;r2=1.569;f=h aż miło popatrzeć ;-) Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
odwrócenie bconda pax w glibc
Czy są jakieś przeciwwskazania odnośnie domyślnej aktywacji łatek PaX w glibc? Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: PLD-Linux Wiki.
Piotr Karbowski wrote: ... stad pomysl przeniesienia calego pl.docs.pld-linux.org http://pl.docs.pld-linux.org na Wiki tak by kazdy mogl dodac cos od siebie, cos na wzor gentoo-wiki. SOD#1 ... to moze zrobic odzielne pl.wiki.pld-linux.org http://pl.wiki.pld-linux.org ? Zapewne wiele osob pomagalo by przy tworzeniu wiki spolecznosci PLD-Linux i jeszcze wiekszej liczbie uzytkownikow pomoglo by rozwiazywac problemy. www.pld-linux.org to wiki. Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: wifi problem z ipw2200 kontra d wl-ag650 (DŁUGIE)
Michal Abramowicz wrote: odpalam tutaj według opisów: [EMAIL PROTECTED] ~]# wpa_supplicant -i eth1 -c wpa_supplicant.conf -Dipw ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported Failed to set encryption. Spróbuj: wpa_supplicant -i eth1 -c wpa_supplicant.conf -Dwext ^ Pozdrawiam, Marek PS. Teraz dopiero sobie przypomniałem - miałem tak samo - bodajże ipw jest obsolete - nie obsługuje WPA, zastępuje go ogólny wext. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: licencja kodeków AMR 3GPP
Jakub Bogusz wrote: W amrnb.spec pojawiło się LGPL wzięte chyba z sufitu, w ffmpeg.spec some kind of public domain with patent restrictions, z kolei w źródłach ffmpeg napisane unclear[...] Z tego wynikałoby, że PLD nie ma prawa tego rozprowadzać bez pisemnej zgody 3GPP. Być może trzeba będzie dać jakieś NoSource, with license_agreement i odwrócić bconda amr w ffmpeg i mplayerze - amrnb nie dotykałem, więc nie wiem. Co do LGPL to z tego co pamiętam interfejs łączący ffmpeg (a co za tym idzie i mplayer) z bibliotekami amr/3gpp jest właśnie na LGPL - z tym że sam kod amr/3gpp już takiej informacji licencyjnej nie posiada (w samym kodzie amr/3gpp nie ma bodajże żadnej wzmianki licencyjnej). Spróbuje się jeszcze przyjrzeć zawartości plików .doc. - być może trzeba by usunąć odpowiednie zipy z distfiles :-( 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: wifi problem z ipw2200 kontra d wl-ag650 (DŁUGIE)
Michal Abramowicz wrote: mam apka dwl-2100AP, ustawione z wpa-psk [...] 2. laptop z ipw2200 na pokładzie [...] jeszcze gdzies wypatrzyłem, żeby dać w modprobe.conf tak: alias eth1 ipw2200_current options ipw2200_current hwcrypto=0 FYI: co prawda używam 2.6.16.16-2, ale ipw2200 z kernela z WPA2 mi działa - w razie czego służę configiem. AP mam na D-Linkowym Atherosie na PCI i madwifi-ng. 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: popsute cdrtools-2.01.01a10.
havner wrote: To chyba na odwrot bylo, od dev=ATAPI sie odchodzi na rzecz dev=/dev/xxx w 2.6 Ja tylko ustosunkowałem się do: Warning: Open by 'devname' is unintentional and not supported. 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: popsute cdrtools-2.01.01a10.
Paweł Sikora wrote: najnowsze cdrtools z head nie działa. przy próbie wypalenia obrazu iso na płytce cd-rw wyskakują jakieś błędy związane z ioctl-ami. [...] Warning: Open by 'devname' is unintentional and not supported. [...] cdrecord command: --- /usr/bin/cdrecord -v gracetime=2 dev=/dev/hdc speed=10 -dao driveropts=burnfree -data /home/users/pluto/incoming/rescue.iso A jak dajesz dev=ATAPI:0,1,0 (lub to co podaje opcja dev=ATAPI -scanbus lub dev=ATA -scanbus) to też nie działa? Może to feature nowej wersji ? Pozdrawiam, Marek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
